iOS 18およびmacOS 15におけるApple Photosのリモートデータ送信機能
(lapcatsoftware.com)- iOS 18とmacOS SequoiaのPhotosにEnhanced Visual Searchが追加され、筆者のiPhoneとMacではデフォルトで有効になっていた
- この機能は、写真内のランドマークや注目地点をAppleサーバーのグローバルインデックスと非公開で照合し、検索を支援する仕組み
- Appleは準同型暗号、差分プライバシー、OHTTPリレーによって写真情報が分からないようにすると説明しているが、サーバー通信そのものがプライバシー保護論争の核心となっている
- 批判の焦点はAppleの悪意ではなくソフトウェアバグの可能性にあり、Appleのセキュリティリリースノートに脆弱性が継続的に掲載されている点が根拠として挙げられている
- macOSではLittle Snitchで通信をある程度遮断できるが、iOSには同様の選択肢がなく、利用者が自力で身を守るのは難しい
Enhanced Visual Searchのデフォルト有効化
- iPhoneのPhotos設定にEnhanced Visual Searchという新しい項目が追加され、デフォルトで有効になっていた
- 同じ設定はmacOS SequoiaのPhotosにも新たに追加され、Macでもデフォルトで有効になっていた
- 筆者はスクリーンショットを撮る前にその設定を手動で無効化した
Apple文書に記された動作方式
- AppleのPhotos & Privacy文書では、Enhanced Visual Searchにより写真をランドマークや注目地点で検索できると案内している
- デバイスは写真内の場所をAppleサーバーのグローバルインデックスと非公開で照合する
- Appleはプライバシー保護のために次の技術を使うと述べている
-
準同型暗号
-
差分プライバシー
- IPアドレスを隠すOHTTPリレー
- 設定はApple文書上、iOS・iPadOSでは
Settings > Apps > Photos、MacではPhotos > Settings > Generalで無効化できる - Apple Machine Learning ResearchのCombining Machine Learning and Homomorphic Encryption in the Apple Ecosystemは2024年10月24日に公開され、iOS 18とmacOS 15の一般公開日は2024年9月16日だった
-
プライバシー保護に対する批判
- 批判の出発点は、利用者が求めていないのにAppleがデバイス内の体験をサーバー通信で強化した点にある
- 筆者の基準では、計算がすべてデバイス内で完結してこそ私的であり、メーカーのサーバーへデータが送られるなら完全に私的とは言いにくい
- Appleの実装が技術的に安全かどうかは、筆者自身も直接評価できないと述べている
- ただしAppleのセキュリティリリースノートに脆弱性が継続的に掲載されているため、Appleのプライバシー主張をそのまま信頼しにくいと見ている
- 悪意や陰謀がなくてもソフトウェアバグだけで利用者は脆弱になり得るし、Appleもバグのないソフトウェアを保証することはできないという批判
利用者の選択権と遮断ツール
- 筆者はEnhanced Visual Searchに関心がないため、機能が完璧に動作するとしてもリスクを負う利益はないと見ている
- 利用者の許可なく機能を有効にするやり方は、利用者とその選好を尊重しない行為だと批判されている
- 「What happens on your iPhone, stays on your iPhone.」というAppleの広告文句はこの事例には当てはまらないと主張している
- macOSではLittle SnitchによってAppleソフトウェアのリモート通信をおおむね遮断できる
- iOSではLittle Snitchのようなツールが許可されておらず、Appleが利用者自身を守る手段を妨げているように感じられる
続報資料
- 2025年1月1日の付録では、続報記事The internet is full of expertsとMichael Tsaiのまとめがあわせて示されている
1件のコメント
Hacker News のコメント
望んでいるのはごく単純なことだ。明示的な意図が示されるまでは、インターネットに何も送らないソフトウェアが欲しい
この機能をもっともらしくプライベートなものにしようとする工学的な取り組みは見事だし、こうした機能を実装すること自体も問題ではないが、必ずオプトインであるべきだ
ソフトウェアがエンドユーザーやそのデータ、ネットワーク接続のようなリソースをベンダーの遊び場のように扱う限り、信頼は削られ続けるだろう。ローカル端末のデータが無線インターフェースの外へ予期せず漏れ出してはならず、ローカルデータがネットワークへ出ていく機能には必ずユーザーの意図が結び付いていなければならない
Apple がなぜ単にユーザーにこの機能を有効にするか尋ねなかったのかについての皮肉な答えは、尋ねれば一部のユーザーが即座に拒否することを Apple も分かっているが、自分たちの方がそのユーザーたちよりよく分かっていると感じているからだと思う。こういう態度が嫌いだし、オプトアウト方式のテレメトリへの不満が高まっている理由も同じだと思う
ほとんどのユーザーが何も考えずに「許可」を押すダイアログをさらに増やしても、問題は解決しない
社会は事実上、第三者にデータアクセス権を渡すことを問題ないものとして受け入れてしまったのであり、そこに摩擦を追加するのは、どうせこうしたサービスを使わない 2% のために 98% を罰するようなものだ
もっと教育された大衆であれば均衡が変わる可能性もあるが、現実はそうではなく、良いユーザー体験は現実を反映すべきだ
圧倒的多数のユーザー、95% 以上はポップアップの意味を理解しておらず、読む能力自体がないように見え、常に承諾するか、常に拒否するか、より目立つボタンを押す
技術業界でも専門職・管理職層でもない家族を観察し、たった今閉じたポップアップが何で、なぜ閉じたのかを尋ねてみれば、技術とプライバシーの相互作用について最良の教訓が得られる
そのためには写真位置の緯度・経度を取得し、人間が理解できる住所に変換する逆ジオコーディング照会が必要で、これはほぼ常にグローバルな逆ジオコーディングサービスに問い合わせる方式だ
この機能もプライバシー侵害なのでオプトインが必要だと考えるのか気になる。そうでないなら、逆ジオコーディングサービスがランドマーク照会サービスよりプライベートである理由が分からない
個人的には、こうしたポップアップが何らかの目的を果たしているとは思わない。結局、Web サイトが善意で行動していることを合理的に証明できないからだ。アプリがサーバーに連絡してよいか尋ねたとしても、「いいえ」を押せば実際の追跡が防がれるという保証もない
大規模なプライバシーが、さまざまな「はい／いいえ」ボタンの組み合わせで機能すると自分に言い聞かせている様子には、いまだに驚かされる。ソフトウェアを信頼する方法は二つしかない。1. 素朴に「privacy first」とどこかに書かれているか確認する 2. 実行中のソフトウェアがどの命令を実行できるかまで理解する
権限ポップアップには粒度も足りない。連絡先リストへのアクセスを許可するとき、実際にはどの連絡先にアクセスするのか。名前だけを許可して電話番号はブロックできるのか。オフライン処理なのかオンライン処理なのか。オンラインなら、インターネットアクセスのポップアップをさらに表示すべきなのか。そうなると、どの種類のインターネット上の行為をするのかもフィルタリングできるべきなのか。こうして掘り下げていくと、最終的にはチューリング完全な権限システムにたどり着き、そうでなければ「プライバシー」には穴が残る
明らかに自分がチェックしていないチェックボックスがチェックされているのを見たこともある。こういうものはオフにして二度とオンにできないようにしたいが、ベンダーが許すはずがない。だから Linux を使っている
私の無料オープンソースアプリのユーザーは、私たちが利用パターンについてまったく洞察を持っていないという事実に驚くようです
少量の匿名テレメトリが非常に役立つ場面はありますが、手を出さないつもりです
オプトインはデータ量が大きく減るだけでなく、選ばれたデータに大きな偏りを入れるため、データを役に立たなくします。オプトインする人たちは、おそらく「典型的なユーザー」の良い標本ではないでしょう
オプトアウトは、どんな保護策や保証を提供しても一部のユーザーには受け入れられず、彼らはそれを強く伝えてくるでしょう
悪意ある行為者がテレメトリを悪用しやすく、「匿名データ」が驚くほど多様な形でまったく匿名ではないと判明し得ることは理解しています。それでも「だから良いものを持てないんだ」というような残念さを感じます
エラーが発生すると、問題解決のために分析データを共有してほしいというトーストが表示され、もちろん拒否できました。おそらく私が見た中で最も良いシステムでしたが、どのサイトだったかは覚えていません
Apple、Microsoft、Google などは分析共有を詳細なしに曖昧に扱い、どう使い、どう悪用できるのかも明確にしません。多くはオプトアウトすら提供していません。こうした組織を信頼してはいませんが、生活の中で関わらざるを得ません。Facebook や Twitter は使わなくてもよく、実際に使っていません。Steam のアンケートは受け入れています
オープンソースコミュニティが恩恵を受けるはずの分析情報不足を解決するには、合意された分析標準 RFCが一歩になり得ます。双方が合意済みのコミュニケーションに同意する方式です
私の観点では、メタデータも個人データです。ユーザーがいなければデータもメタデータも存在しません。エンドユーザーがメタデータのエントロピーなので、メタデータとデータの所有者はユーザーです
どんな偏りが加わるのかはよく分かりません
例えば「私たちはこのアプリを作っており、プライバシーを重視しています。過去1か月の利用中に収集された情報は以下の通りです。アプリ改善のためにこの情報を私たちへ送ってもよいですか？」と尋ね、収集されたデータを人間が読める形で見せる方式です
一般的には実行可能な解決策だと期待しています。オプトインしたグループが「典型的なユーザー」と異なるとしても、正直かつ倫理的に得られる最善のデータです。まったくデータがないよりは、確実にましではないでしょうか
オプトインの Cookie 同意バナーを表示するすべてのウェブサイトとアプリでは、すでに暗黙的にこうした状態が適用されています
デスクトップソフトウェアを改善するのは非常に難しく、特に Linux ユーザーは改善を可能にするパターンに敵対的な傾向があります
100%完全に同意：
「コンピューティングにおけるプライバシーを保証する唯一の方法は、データをデバイスの外に送らないことだ」
「プライバシー侵害のリスクをどの程度受け入れるかは、個々のユーザーが決めるべきだ。［...］何も尋ねずに『機能』をオンにすることで、Appleはユーザーとその選好を尊重していない。私のiPhoneがAppleのサーバーに連絡することを望んだことはない。」
機能がどれほど難読化されていようと、「安全」だろうと、その他「プライバシー保護」的であろうと、個人コンテンツから派生した何らかの情報が事前同意なしに送信されるという事実は変わらない。
情報が保護されていても、すべてのネットワーク問い合わせは情報である。特定の時刻に特定の行動をしたというタイムスタンプ、例えば新しい写真を追加した直後にこのサービスへ何かが送信されるなら、写真を撮ったという事実、その時刻の位置情報と相関させた特定の場所などが明らかになり得るし、これは氷山の一角にすぎない。明示的な同意なしにユーザーのデバイスから情報を送信することはプライバシー侵害である。
メタデータについての主張はあり得ると思うが、そこにも多くの仮定が入っている。特に、Appleが実際にはOHTTPを行っておらず、ユーザーがいつ写真を撮ったかを突き止めようと共謀している、という仮定が必要だ。事実上、数学を信頼しないなら、不確実性と疑念がどこで終わるのか分からない。
写真を撮った直後にすぐ起きるわけではないことは簡単に確認できる。第一に、ネットワークトラフィックがそれを示すはずだが、実際にはそうではない。第二に、準同型暗号はコストが大きく、そうはできない。Photosは通常すぐには同期せず、ほとんどのiPhoneユーザーはPhotosアプリで同期タイミングが示されるのを見れば分かる。コストの大きい処理はたいてい、デバイスが電源に接続されWi-Fi上にあるまでキューに積まれる。
例えば、浴槽の中の犬の写真を友人に送ったら、彼女のAirPodsがiPhone経由で「誰かが浴槽の中の犬の写真を送りました」と知らせてきた。友人もすごいと言っていたし、個人的にも便利な機能だと思う。ただ、これがどの程度デバイス外での処理を必要とするのかは分からない。
この2つの緩和策を考えると、この機能で個人データを得るには、まず対象のスマートフォンを侵害して偽の問い合わせを無効にし、続いて中継者を侵害して問い合わせを特定のIPアドレスと相関させる必要がある。
そこまでできるなら、正直そんな努力の無駄遣いは愚かだ。iOSの侵害を利用して、デバイスに位置データを直接送らせればいいからだ。対象が写真を撮るのを待ち、複数のランドマーク照会を追跡し、問い合わせごとに追加データを少しずつ集めて最終的に対象の位置を特定するような面倒なことをする必要はない。
全体としてXKCD 538を思い出させる。
https://machinelearning.apple.com/research/homomorphic-encry...
これは前回の反発の後、CSAMスキャンをゆっくり再導入するための煙幕ではないかと思う。デフォルトでオンになっている挙動が怪しい。
[1] https://www.wired.com/story/apple-photo-scanning-csam-commun...
そのようなフィンガープリントが公開ランドマークだけに安定して制限できるのかは興味深い問題で、明確でない実装の詳細に依存する。
ユーザーに見える検索が「ランドマーク」に限定されていても、その過程で、デバイス内だけであっても他の多くのもののフィンガープリントを事前に作っているのか？ そうだとすれば、一時的に有効化される非永続的なマルウェアが、本来必要だったはずのより広いアクセス権や追加処理なしに、関心のある画像を即座に見つけられるようになる。
グローバルインデックスは当然、ユーザーに返さないとしても、Appleがマッチングする価値があると見る他の目印にもマッチするだろう。
写真からランドマークを見つけるモデルもローカルで実行できるのではないかと思うが、ここは100%確信しているわけではない。
冷笑的な理由を挙げるなら、この規模のエンジニアリング機能は文書なしには計画できず、そうした文書は法廷で必ず明るみに出る。
表向きの理由は、Appleがサーバーの関与を必要とする便利な機能を本気で提供したがっているからだ。
Appleのブログ記事の技術的詳細の大半を理解できないという点については、引用された部分は理解したし、悪いけれどこの記事は楽観的な記事にもなり得た。「この素晴らしい新技術を見て！」という感じで
HN的な意味でのハッカーに反するAppleの慣行は他の人たちと同じくらい嫌いだし、そうした理由などからApple製デバイスも持っていないが、「プライバシー問題をどう解決したかは重要ではなく、私はプライベートではないと感じる」という言い方が事実を作るわけではない
引用された言葉を他のほとんどの人も理解していないし、そこまで読んだかどうかも定かではないので、これは不公平な批判に見える
当時の理解では、SUMのような演算で暗号化された数値リストの合計を計算できた。暗号化方式のおかげで復号せずに値をすべて足し合わせることができ、結果も暗号化されたままなので、所有者が復号すると既知の精度の数値が得られた
Appleが準同型暗号を正しく使っているなら、Appleがスマートフォンから受け取ったデータを見る方法はないはずだ。記事で触れられている他のものは、メタデータやサイドチャネル経由の情報漏えいを防ぐための手段だ
この機能がデフォルトでオンになっているのはあまり良くない。アップグレード後にユーザーへオンにしたいかを尋ねる機能であるべきだった
多くの人にとって、その権威はAppleではない。Appleのプライバシーポリシーを慎重に信頼してはいるが、多くの人はAppleを信頼しておらず、それには理由がある
だから、オプトインしていないAppleの機能が個人データを共有し、Appleの技術説明も理解できないとなると、プライバシーを侵害されたという感覚が強まり、それがさらに大きな不信につながる。それでも不公平な批判と言えるだろうか
私のブログ記事は、信頼を裏切られたAppleユーザーの視点で書いたものだ。安全な距離から技術が素晴らしいと思うのはよいし、実際そうかもしれないが、核心的な問題であるユーザー同意の欠如とは無関係だ
私には全体として、ユーザープライバシーを大きく考慮して実装された妥当な機能に見える。ただし、説明を信じすぎているのかもしれない
この記事は全体として怒りを誘うためのものに見え、Hacker Newsに上がるこうした記事に「釣られ」ないよう注意すべきだと思う。タブロイド紙やFacebookに怒りを誘う記事が出てくるときに注意すべきなのと似ている
記事やこのスレッドの一部の懸念は、Appleの収益にはほとんど影響しない可能性が高そうだ。実際に一部の顧客が抱き得る懸念はデータ使用量だろうが、低データモードではこの機能はオフになる可能性が高いと推測する
この種の問題は、プライバシーのデフォルトのような設定で解決できるのか気になる。記者、活動家、一部の企業IT部門、元記事のような文章を書く人たちが、OSアップデート時にネットワークとの通信を少なくする値に設定されるよう選べる方式だ。分かりやすいUIを作るのは難しそうだ。iOSにはすでに「ロックダウンモード」があるが、この設定に影響するかは分からない
UIで見える機能の動作方式からすると、そうではなさそうだ。ユーザーの行動によって機能が有効化されるなら、これもサーバーへの連絡と見るべきなのか気になる
そうしたものは、広告会社が運営するあの不快な別のOSとは違い、iPhoneの中にとどまるという話だった。Appleは絶対にデータを持ち出さず、あなたは商品ではなく、Appleはあなたを大切にしている、という話だ
こうしたことは、単独で見て妥当かどうかにかかわらず、その物語を完全に崩してしまう。巨大な広告看板でこれほど露骨に嘘をつく意思があるなら、利益が求めるときに他に何をするか分からない
iOS 18以前にはなかったような、似た検索関連の設定をたった今見た気がする
設定 -> 検索に入ると「Help Apple Improve Search」というオプションがあり、デフォルトでオンになっている
「AppleがSafari(!!)、Siri、Spotlightに入力した検索を、あなたと結び付かない形で保存することを許可して、Searchの改善を支援します。検索には一般知識の問い合わせや、音楽再生、経路案内のようなリクエストが含まれます。」
以前からあったのなら、再びオンになったということだ
Appleの保存方式が私のプライバシーを安定して保護すると信じるには、多くの詳細が必要だ。もちろん引用文はそこまで主張してはいない
参考までに、macOS では photoanalysisd サービスがバックグラウンドで実行され、Apple Photosを一度も開いていなくても写真を見て回る
SIP、つまりシステム整合性保護をオフにしない限り無効化できず、そのためには何度も再起動して警告を通過する複雑な手順が必要になる。SIPを再びオンにするとまた有効化される
Appleはどういうわけか、ユーザーが望むかどうかにかかわらず写真解析にかなり熱心なようだ
皆が自分の写真で学習したローカル画像生成器を動かし、少し壊したうえで、Appleの写真ハッシュ収集をゴミでいっぱいにしたらどうなるだろう
その次は？
とても良い洗浄作用になるはずだ。誰がどれだけ怒るかを見れば多くのことが分かる
この件は、コロナ禍におけるAppleとGoogleのプライバシー保護型曝露通知システムへの怒りを思い出させる
追跡せずに曝露を通知できるというのは直感に反するが、実際にその技術がそれを可能にした
ここでも筆者は、クライアント側ベクトル化、差分プライバシー、OHTTPリレー、準同型暗号といった技術の効果をきちんと評価しようとせず、プライバシー侵害への即座の反応に頼っているように見える
ただし、このような機能についてはAppleがまずユーザーの同意を求めるべきだという点には100%同意する
誰かがソースコードへのリンクを貼ってくれれば、インターネット上の誰かの言葉を信じるのではなく、正確に何をしているのかを見ることができる
さらに良いのは、自分でコンパイルできるようにしてくれることだ
「Appleのブログ記事の技術的詳細の大半を理解していない」という部分については、私は理解している
クライアント側ベクトル化: 写真をローカルで処理し、送信する前に不可逆なベクトル表現を用意する。意味ベースのハッシュを思い浮かべればよい
差分プライバシー: 送信前にベクトルへかなり多くのノイズを加える。ベクトルの逆引きが不可能になる程度に十分な水準だ。ここでのノイズ水準は ε = 0.8 で、プライバシーはかなり良いほうだ
OHTTPリレー: 第三者を経由して送信されるため、AppleはIPアドレスを知ることができない。内容は暗号化されているので第三者も何も学べない。「IP XがApple Photosユーザーである」程度が漏れるリスクはあるが、ライブラリの内容は分からない
準同型暗号: 検索処理は暗号化されたデータのままサーバー上で実行される。Appleはベクトルの内容や応答内容を復号できず、クライアントだけが検索結果を復号できる
これは良いプライバシー設計の姿だ。プライバシー保護が何層にも重なっており、後ろの3つのうち1つだけでもプライバシー保護には十分なはずだ
「プライバシー侵害リスクに対する各自の許容水準は個々のユーザーが決めるべきだ」という主張について、筆者はAppleのセキュリティ研究者のように見えるにもかかわらず、ここでは情報に基づいた選択ができないと言っていることになる
何が正しい判断なのかは確かではない。だが「したがってコンピューティングにおけるプライバシーを保証する唯一の方法は、データをデバイスの外に送らないことだ」という結論は事実ではない。サービスを使いながらもプライバシーを提供する道具、たとえば差分プライバシーや準同型暗号がある。非常に複雑で、ユーザーが現実的にリスクを評価することはできないが、ディスクより大きなデータセットや頻繁に変わるコンテンツが必要な機能を望むなら、こうした道具が必要になる
多くのユーザーはこうした機能に同意するかもしれない。言うとおり非常に安全なのかもしれない。だが全員がデフォルトで同意したものと見なされるべきだという点が問題なのだ
ユーザーは「この機能は、より良い検索のために写真に関するデータをAppleサーバーへ送信します」と理解するのに博士号は必要ない
プライバシー保護が複雑であることは、ユーザーの選択権を取り除く正当化にはならない。その論理なら、どんな技術機能についてもユーザーに尋ねてはいけないことになる
プライバシー意識の高い多くのユーザーは単純な原則に従っている。保護方式にかかわらず、デバイスの外へ何が出ていくのかを制御したいということだ
「説明するには複雑すぎる」という主張は、どんなプライバシー侵害的なデフォルト設定も正当化できてしまう。GPS技術の説明が複雑すぎるから位置情報サービスをデフォルトでオンにしてよい、という論理にも同じ基準を適用するのか
本当の解決策は単純だ。機能を平易な言葉で説明し、利点を強調し、プライバシー保護措置を概説したうえで、ユーザーに選ばせればよい。Appleはすでに他の多くの機能でそうしている。デフォルトオフとオプトインは、下層の保護がどれほど堅牢であっても、プライバシー尊重設計の核心的原則だ
Jeff JohnsonはAppleプラットフォーム向けアプリ、とりわけSafari拡張機能を開発し、Appleへの不満をよくブログに書いているが、セキュリティ研究者ではない