iOS 14 のクリップボード盗用騒動、プライバシーと利便性のジレンマ
なぜ多くの iOS アプリがあなたのクリップボードを読み取るのか？
Photo by Clint Patterson
⚠️ 2022/07/22 更新：iOS 16 の今後の変更点
iOS 16以降、ユーザーが主動で貼り付け操作を行わない場合、アプリが剪貼簿を読み取ろうとすると確認ダイアログが表示され、ユーザーが許可しなければアプリは剪貼簿の情報を取得できません。
UIPasteBoardのiOS 16におけるプライバシー変更
議題
クリップボードがAPPに読み取られたときの画面上部の通知メッセージ
iOS 14 から、ユーザーに対してアプリがクリップボードを読み取ったことを通知するようになりました。特に中国本土のアプリは悪名高く、メディアの過剰な報道もあって大きなプライバシー不安が生じています。しかし、実際には中国のアプリだけでなく、アメリカ、台湾、日本など世界中の大小さまざまなアプリが明らかになっています。では、なぜ多くのアプリがこれほど頻繁にクリップボードを読み取るのでしょうか？
Google 検索
セキュリティ
コピー＆ペーストボードには個人情報やパスワードが含まれることがあります。例えば、1PasswordやLastPassなどのパスワードマネージャーでパスワードをコピーした場合です。アプリが読み取れるということは、サーバーに送信して記録することも可能であり、すべては開発者の良心に委ねられます。もし確認したい場合は、中間者攻撃のスニッフィングを使用して、アプリがサーバーに送信するデータにコピー＆ペーストボードの情報が含まれているか監視できます。
背景
クリップボード API は、iOS 3（2009年）から存在しますが、iOS 14 からはユーザーに通知するポップアップが追加されました。つまり、それまでに悪意のあるアプリは十分なデータを収集している可能性があります。
なぜ
なぜ多くの国内外のアプリが起動時にクリップボードを読み取るのでしょうか？
こちらで先に定義しておきますが、私が言っているのは 「APP 起動時」 の場合であり、APP 使用中にクリップボードを読み取る場合ではありません。APP 使用中の読み取りは、Google Map がコピーした住所を自動で貼り付けるなど、APP 内の機能利用が多いですが、中にはクリップボード情報を繰り返し盗み取るAPPも考えられます。
「包丁は野菜を切ることも人を刺すこともできる、それは使う人が何に使うかによる」
APPが起動時にクリップボードを読み取る主な理由は、「iOS Deferred Deep Link」を使ってユーザー体験を向上させるためです。上記の流れのように、ある製品がウェブとAPPの両方を提供している場合、ユーザーにAPPをインストールしてもらいたい（利用継続率が高いため）ため、ウェブ版を閲覧中にAPPのダウンロードを促します。そして、ダウンロード後にAPPを開くと、ウェブで離れたページを自動的に表示させたいのです。
例：SafariでPxHomeのモバイルウェブ版を閲覧 → 気に入った商品を購入したい → PxHomeはトラフィックをアプリに誘導したい → アプリをダウンロード → アプリを開く → 先ほどウェブで見た商品を表示
もしそうしなければ、ユーザーは1. 再度ウェブページに戻ってもう一度クリックするか、2. アプリ内で再度商品を検索するしかありません。どちらの場合も購入の手間や迷いが増え、結果的に購入をやめてしまう可能性があります！
一方で、運営面では、どのソースから成功したインストールかを把握することが、マーケティングや広告予算の投資に大いに役立ちます。
なぜ必ずクリップボードを使うのか、他に代替手段はあるのか？
これはネコとネズミのゲームです。なぜなら、iOSのApple自体が開発者がユーザーの出所を逆追跡することを望んでいないからです。iOS 9以前は情報をウェブのCookieに保存し、アプリインストール後にCookieを読み取って利用していましたが、iOS 10以降はAppleによりこの方法が封じられました。行き詰まった結果、最終手段として「クリップボードで情報を渡す」方法が使われるようになり、iOS 14で再び新たな対策が取られ、ユーザーに通知が出て開発者は困惑しています。
もう一つの方法は Branch.io を使い、ユーザーのプロファイル（IP、端末情報）を記録してマッチングで情報を取得する方法です。原理上は可能ですが、バックエンド、データベース、アプリ開発など多くの人手をかけて実装を研究する必要があり、誤判定や衝突が起こる可能性もあります。
向かいの Android Google は元々この機能をサポートしており、iOSのように回りくどくする必要はありません。
影響を受けるAPP
可能多くのAPP開発者は、自分たちもクリップボードのプライバシー問題を引き起こしていることに気づいていないかもしれません。なぜなら、GoogleのFirebase Dynamic Linksサービスも同じ原理で実現されているからです：
// この文字列の理由は、AppPreviewページのJavaScriptコードによってクリップボードにコピーされたFDLリンクのみが
// コピー一意一致プロセスで認識され使用されることを保証するためです。ユーザーが自分でFDLをコピーした場合、そのリンクは
// コピー一意一致プロセスで使用されてはなりません。
// この定数はサーバーバージョンの durabledeeplink/click/ios/click_page.js にある定数と同期させる必要があります。
つまり、Google Firebase Dynamic Links サービスを利用しているすべてのアプリは、クリップボードのプライバシー問題に該当する可能性があります！
個人的見解
セキュリティの問題は確かにありますが、それは「信頼」の問題です。開発者が正しい目的で使うと信頼することが重要です。もし悪意があるなら、クレジットカード情報の盗用や本当のパスワードの記録など、もっと効果的な悪事を行う手段は他にもたくさんあります。
提示の目的は、ユーザーがクリップボードの読み取りタイミングに気づけるようにすることであり、不自然な場合は注意が必要です！
読者からの質問
Q：「TikTokがクリップボードへのアクセスはスパム行為の検出のため」という説明は正しいですか？
A：個人的にはただ世論をかわすための言い訳だと思います。抖音の意図は「ユーザーが広告メッセージをあちこちにコピー＆ペーストするのを防ぐため」でしょう。しかし、実際にはメッセージ入力完了時や送信時にフィルタリングすればよく、常にユーザーのクリップボード情報を監視する必要はありません！クリップボードに広告や「敏感」な情報があっても管理すべきですか？私はそれを貼り付けて投稿していません。
開発者ができること
もし手元に予備の端末がなくiOS 14へのアップグレードテストができない場合は、先にApple から XCode 12 をダウンロードして、シミュレーターで試すことができます。
すべてまだ新しいため、Firebase を連携する場合はまず Firebase-iOS-SDK/Issue #5893 を参考にして、最新の SDK に更新してください。
もし自分で DeepLink を実装する場合は、Firebase-iOS-SDK の #PR 5905 の修正を参考にしてください：
Swift:
if #available(iOS 10.0, *) {
if (UIPasteboard.general.hasURLs) {
//UIPasteboard.general.string
}
} else {
//UIPasteboard.general.string
}
Objective-C:
if (@available(iOS 10.0, *)) {
if ([[UIPasteboard generalPasteboard] hasURLs]) {
//[UIPasteboard generalPasteboard].string;
}
} else {
//[UIPasteboard generalPasteboard].string;
}
return pasteboardContents;
}
まず、クリップボードの内容がURLかどうかを確認します（ウェブのJavaScriptでコピーされた内容がパラメータ付きのURLである場合）。これにより、APP起動時に毎回クリップボードが読み取られることを防げます。
現在これしか方法がなく、通知は表示されますが、より焦点を絞るだけです
また、Appleは新しいAPIである DetectPattern を追加しました。これにより、開発者はクリップボードの情報が必要なものであるかをより正確に判断してから読み取り、通知を表示できます。これにより、ユーザーは安心して利用でき、開発者もこの機能を引き続き使用できます。
DetectPattern はまだベータ版で、Objective-C のみで実装可能です。
または…
-
Branch.io に切り替える
-
Branch.io の仕組みを自分で実装する
-
APPはまずカスタマイズされたアラートでユーザーに通知し、その後クリップボードを読み取る（ユーザーの安心感を高める）
-
新しいプライバシーポリシーの追加
-
iOS 14 最新の App Clips？ウェブ → App Clips 軽量利用 → 詳細操作で APP を誘導
関連記事
Post は Medium から ZMediumToMarkdown によって変換されました。
コメント