アプリが権限を要求するとき、「偽データを提供」する選択肢があるべき

• アプリが権限を要求するとき、OSは単に「はい／いいえ」の回答だけを許可するのではなく、**「偽データを提供する選択肢」**をすべての権限カテゴリに追加すべき
• 連絡先を要求されたら生成された偽の連絡先を、マイクへのアクセスを要求されたらランダムな環境音を、位置情報を要求されたら5×5mの小さな島の座標を提供する方式
• アクセスを遮断するとアプリは「それなら利用できない」と拒否するが、偽データを渡せば、不要なデータを要求したサービスだけが罰を受ける構造になる
• ボイコットはユーザーに大きな個人的犠牲を求める一方、企業への打撃はわずかにとどまるため、**悪意ある遵守（malicious compliance）**のほうがボイコットより効果的だという立場
• ユーザーが自分の所有するデバイスの管理者として、アプリとシステムソフトウェアを制御できるべきだというユーザーの制御権の問題につながる

---

中核となる提案 — 権限ごとの偽データ選択肢

• OSが権限要求に対して、「はい／いいえ」に加えて**「はい、ただし偽データを提供」**という選択肢をすべてのカテゴリで提供すべき
  • 連絡先の要求 → ランダムに生成された偽の連絡先を提供
  • マイクの要求 → ランダムな環境音（random ambiance）を提供
  • 位置の要求 → 5×5mの小さな島にいると応答
• サービスが不要なデータを要求した場合、そのデータベースに役に立たない情報を入れて罰する効果がある
• アクセス遮断とは異なり、偽データはアプリに「利用不可」と対応させにくくしつつ、不要なデータ収集を無力化する

ボイコットに対する優位性の主張

• 必要なアプリをボイコットすることは、相当な個人的犠牲を払いながら、億万長者には目に見えない程度の打撃しか与えない不利な取引
  • 闘う側が最も多くを失う構造であり、ユーザーに不利
• 偽データを注入する方式のほうが、ユーザーにより大きな力を与えるという立場
• 「悪意ある遵守（malicious compliance）」はボイコットより面白い、という表現を使用

議論で言及された既存の手段

• 位置スプーフィング（location spoofing）

  • 以前の位置スプーフィングはグローバル（global）設定でのみ可能で、アプリごとの選択は難しかった
  • Androidの開発者向け設定で特定のアプリを模擬位置情報（mock location）アプリとして指定すると、グローバルに適用される
  • Firefoxにはジオロケーションなど各種データをスプーフィングする拡張機能が存在するが、スマートフォン上で動作するほうがより有用
  • Pokémon GOで偽の位置データを使った不正利用の事例があり、技術的に可能であることが確認されている

• XPrivacyLua

  • ルート化されたデバイスでユーザーが望む動作を正確に実行していたが、**Magisk（システム改変）**が必要
  • 現在はメンテナンス終了状態で、すべてのデバイスと互換性があるわけではない

• Androidの標準権限機能

  • Androidはすでにアプリごとに情報へのアクセスを選択したり、毎回確認するよう設定したりできる
  • ただしこれは遮断方式であり、偽データの提供とは異なる

拡張アイデアと事例

• AIを活用したデータ汚染

  • データマイナーに無意味な情報を再帰的に供給して無力化しようという提案
  • AIが生成したデータでAI学習用コンテンツまで汚染しようというアイデア

• 広告トラッキングへの対抗

  • 広告をブロックしつつ、すべての広告をクリックしてターゲティングデータを無力化するAdNauseam（uBlock Originのフォーク）に言及
  • 過去に試した際はリソース消費が大きかったという評価

• ブラウザ追跡プロファイルのかく乱

  • ブラウザとCookieで複数のサイトを素早く巡回し、フィンガープリンティングや追跡をかく乱するサービスが存在
  • ランダムまたはプロファイルベースのパターン（例：「エクアドルの70歳のヒッピーのように閲覧」）を選択可能
  • Mozillaが作成したTrackThisの事例に言及

指摘された限界と懸念

• ランダムな生年月日を入力すると任意の日付に誕生日祝いを受けるが、セキュリティ質問でどの日付を使ったのか分からないという問題が発生する
  • OSがユーザーに自分の偽データの値を知らせられるべきだという補足意見
• 約10年前にこれをスタートアップのアイデアとして検討したが、防御可能にする法律家を見つけられなかった
• 商用開発者たちが大きく恐れるはずなので、Googleがこれを実装する可能性はほとんどないという見通し
• GoogleとAppleのどちらも、ユーザーが制御権を持つことを望んでいないのが根本原因だという指摘

[GN⁺]

Hacker Newsの意見

• 「偽データ」というアイデアには賛成だが、アプリはユーザーが実際のデータへのアクセス権を拒否しても適切に処理することを求められるべきだ
  以前iOS開発をしていた頃は、権限拒否を理由にユーザーを罰したり exit() でアプリを終了したりしてはいけないというのがAppleのポリシーで、アプリは動作を継続しなければならなかった
  もっと前は、アプリの実行に「アカウント」を要求することもできなかった。10年以上前に会社がアカウント必須を導入したところ、App Storeで正当にリジェクトされたのを覚えている。最近はアカウント必須のアプリがどんどん増えているのを見ると、この立場は緩和されたようだ

  • 「アプリの実行にアカウントを要求してはならない」という話には大きな但し書きが抜けているか、意味を取り違えている気がする
    銀行アプリ、オンラインゲーム、最近のTwitterアプリ、Dropbox/Nextcloudのようなアプリが、アカウントなしでどう動作できるのか
    多くのアプリでアカウント要求がマーケティング上の小細工なのは事実だが、そういう一般ルールが成立するとは思えない
  • WhatsAppは連絡先へのアクセスを拒否すると、今でもユーザーを「罰する」。すべての名前を隠して電話番号だけを表示し、相手が自分のプロフィールに名前を設定している場合でも同じだ
    Facebook/Meta はひどい
  • 連絡先や写真のような偽の個人データは問題ないが、位置情報になると曖昧になる
    地図で自分の位置を表示したり、近くの店舗を検索したりする用途なら、偽データを渡してもよい
    しかし、通信会社ごとの速度を地図化するインターネット速度テストアプリや、ユーザーが地域の天気を報告して予報改善に役立てるアプリなら、「正確な位置を渡すか、まったく渡さないでほしい。偽の位置は望まない」と言えてもよいと思う
    プラットフォームは、他人に影響するユーザー投稿データを受け取るアプリに例外を与えるかどうかを判断する必要があるだろう
    Appleはこの点でかなりよい中間地点を作ったようだ。アプリに「正確な位置情報」を許可しなくてもよく、写真もシステム提供の画像ピッカーを通じて、ユーザーが選んだ写真だけをアプリに見せられる
  • iOSで最悪なのは Google Photos だ。すべての写真へのアクセスを許可しないとアプリを開くことすらできず、選択した写真だけを許可する設定も認めない
    クラウドにすでに保存された写真を見ようとするだけでも同じだ
  • 「アプリはユーザーが実際のデータへのアクセス権を拒否しても適切に処理すべきだ」と言っても、守らなければどうするのか
    技術的な問題に組織的な解決策を提案しているようなもので、機能しにくい。実用的な解決策は偽データしかない。アプリ側から見れば、権限が実際には許可されていなくても、許可されたように見える必要がある

• root化したAndroidでは XPrivacy が7年前からこうしたことを実現できており、今どきの代替手段も一応ある。ただ、長いことスマホをroot化していないので保証はできない: https://github.com/M66B/XPrivacy
  もちろん主流のやり方ではなく、標準で内蔵されるべきだという点には同意する。だがAndroidもiOSも、地域制限アプリやDRMコンテンツのスクリーンショット禁止のようなたわごとを許しているので、簡単ではないだろう

  • こういう形で使ってみると、ユーザーとしてどれほど不利な設計になっているかを身をもって感じるし、スマホがコンピュータだという信念を捨てることになる
    スマホはベンダーのコンテンツ配信装置であり、ユーザーは彼らの裁量に委ねられている
  • XPrivacyは本当に素晴らしかったが、現代のスマホでroot化してXposedをインストールするのは、はるかに複雑になったか、もはや塞がれてしまった
    GrapheneOS は銀行アプリと相性が悪く、GoogleはAndroid BetaでMagiskによるroot化を何度も壊し、ある時点で気にしなくなってしまった
    GrapheneOSや似たようなプロジェクトなら、こうした機能を実装できるかもしれない
  • XPrivacyは優れていたが、一部の権限を拒否するとアプリがよく落ちた。結局のところ、偽データを十分うまく提供できていなかったということだ
    あまりにひどかったので、すぐに「拒否」を押さず、必ず先に「一時拒否」を押していた。アプリが動けば恒久拒否し、落ちるなら許可しなければならない最小権限セットを探す必要があった
  • この機能が工場出荷イメージやAndroid本流に入ることはないだろうが、ユーザー需要が十分にあれば LineageOS のようなプロジェクトに入る可能性はある
  • 「地域制限アプリ」というのは実際にはそういうものではなく、各アプリストアが選択した地域にのみアプリを配布できるようにする仕組みのことだ
    アプリがすべての国で良い体験を提供できるとは限らず、すべての言語にローカライズされていなかったり、その言語のコンテンツモデレーターがいなかったり、各国の法律を順守する必要があったり、著作権コンテンツの配信ライセンスが特定の国に限定されていたりするため、アプリストアにとって重要な機能だ
    DRMコンテンツのスクリーンショット防止は、映画のようなコンテンツのライセンスに関する法的要件のためにアプリ開発者が求める機能だ。映画会社は人々が映画をストリーミング配信したり録画したりするのを望まないので、アプリプラットフォームにはそのコンテンツを安全に表示する方法が必要になる

• 「誰かが尋ねる資格のない質問をするなら、あなたに真実を語る義務はない」
  — Leonard Schiffman
  出典: “Blend me in: Privacy-Preserving Input Generalization for Personalized Online Services” https://drive.google.com/file/d/10OmoqMmHFcb7PsQtaU_GW4aCAJe...

• アプリの権限要求で、OS が「はい／いいえ」だけでなく「はい、ただしアプリには偽データを与える」という選択肢も提供すべきだという主張には問題がある
  かなりの数のユーザーはメールの転送方法すら知らない
  そういう人たちが Google Maps のナビを使いながら意味も理解せずに偽データを選んだら、どんな混乱が起きるか想像してみてほしい
  Google Maps: 「右に曲がってください」
  海沿いの道を走るドライバー: 「よし」
  車: バシャン

  • それは完全にユーザー体験の問題だ
    データ偽装機能を設定の奥深くに隠し、有効化する前に平易な言葉で明確に説明し、ユーザーが自分で有効にしたプライバシー機能のためにアプリへ代替情報が提供されており、簡単に無効化できることを画面上で明確に知らせればよい
    それでも誤って有効にする人はいるだろうが、そうでない多くのユーザーには大きな価値をもたらせる
  • それは学習の機会のように見える。あるいはダーウィン的な機会かもしれない
    どちらにせよ、自ずと解決する問題だ
  • ならその設定を上級ユーザー向けの選択機能にすればよい。慣れていないユーザーには、そのオプション自体を見せなければよい
  • そういう場合なら、ドライバーが進行方向をきちんと見ていなかったのであって、それは別の問題だ
    OS は「はい」「いいえ」「カスタム」を提供するほうがよさそうだ。「カスタム」を選んだ場合、そのメニューの中で必要なら警告メッセージを表示できるが、ユーザーが望むように調整することまで妨げるべきではない
  • iOS で Google Maps をそんなに使うのか気になる。「偽データを提供する」オプションは Apple ならやりそうだが、Google がやるとはとても思えない
    Apple Maps ならこの問題はないだろう。地図を端末にダウンロードできるので、データ接続がなくてもオフラインで動作できる

• iOS では権限を得ているかどうかを区別できないという点が、なぜ最上位コメントにないのか意外だ
  たとえばアプリが写真へのアクセスを要求すると、常に配列を受け取る。ただし権限が拒否されるとその配列は空になるので、ユーザーのライブラリが本当に空なのか、アクセスが拒否されたのかは分からない。単純でエレガントでよい
  もちろん写真の場合、ほとんどの人は何枚か写真を持っているので、ヒューリスティクスを使える。だが健康データのような他の種類では、そこまで明確ではない

  • それは正確ではない。たとえば位置情報サービスへのアクセスには CLAuthorizationStatus がある: https://developer.apple.com/documentation/corelocation/claut...
    プッシュ通知には UNAuthorizationStatus がある: https://developer.apple.com/documentation/usernotifications/...
    ヘルスデータには HKAuthorizationStatus がある: https://developer.apple.com/documentation/healthkit/hkauthor...
    連絡先には CNAuthorizationStatus がある: https://developer.apple.com/documentation/contacts/cnauthori...
    写真には PHAuthorizationStatus がある: https://developer.apple.com/documentation/photokit/phauthori...
    写真は、ユーザーがアクセス拒否・限定アクセス・フルアクセスから選べるので特殊なケースだ。アクセス拒否かどうかは分かるが、限定アクセスとフルアクセスは区別できない
  • 位置情報はどう動くのか気になる
    それに、写真フォルダが空なら、ほぼ確実に権限がないという意味だろう。写真を一度も撮ったことがない人は極めてまれだ
  • 現実的に空オブジェクトを送れない他の権限はどうなるのか
    たとえばユーザーが位置情報の閲覧権限を許可すると、アプリに渡される位置オブジェクトには当然それに関する情報が入る。OS が空の位置オブジェクトを渡したら権限拒否が明白にならないか、それとも何らかのエラーの裏に隠すのか
  • これは明らかに事実ではなく、通知へのアクセスを要求するほぼすべてのアプリで確認できる

• 「偽データを提供する」は間違ったやり方だと思う。もっとよい方法は代替ソースのデータ提供であり、その代替ソースは他のどんなプログラムでもよいようにすべきだ
  代替ソースは、空データ、ランダムデータ、偽物だが一貫したデータ、代替ファイルのデータ（例: 別の連絡先リストや、カメラの代わりにファイル内の写真）、変換済みデータ（例: カメラ写真を上下逆にひっくり返す）、フィルタリング、記録、個々のデータごとにユーザーへ問い合わせること、データの代わりにエラーコードを返してユーザーがそのエラーコードを指定できるようにすることなど、ユーザーが望む何でもあり得る。現在の日付／時刻へのアクセスまで、すべて含まれるべきだ
  これはユーザー制御を高め、テストやアクセシビリティ用途にも有用だ
  OS 設計についての私のアイデアの一つはプロキシ権限だ。権限ベースのセキュリティにプロキシ権限を含め、すべての入出力がこれを使い、UNIX パイプより優れた形でコマンドシェルから使えるようにもでき、他の方法でも使える。日付／時刻も含まれる。Yield と Quit を除き、権限キーなしではいかなるシステムコールも使えない

  • これが最良のアプローチであり、実際に動作可能な唯一のアプローチだと思う
    アプリ開発者にとって、使えない権限を適切に処理するのは非常に難しく、比較的少数のユーザーのためにテスト範囲がはるかに広くなって難しくなるので、小規模な商用アプリの多くはたいていまともに対処しようとしないだろう
    権限自体は許可しつつ、代替データソースを与える方式が、開発者とユーザーの双方にとって最も簡単だ
    もちろん、不正もやりやすくなるかもしれない。たとえば銀行は、より複雑な端末登録手順を使うようになるだろう

• わざわざ互いに意地悪をする必要はない。単純なルールは「いいえも選択肢である、本当に選択肢でない場合を除いて」ということ。
  選択肢でないなら、その理由は非常に明確であるべきで、おそらくアプリ審査の過程で示されるべきであり、そうでなければアプリは却下されるべきだ。
  たとえば TikTok/Instagram がカメラとマイクの権限を要求する場合、どちらもアプリ利用に必須ではないのだから、いいえは選択肢になる。特定の権限がなくてもアプリの一部を使えるなら、そのように動作するよう設計する責任はアプリ側にある。カメラやマイクがオフなら、その権限が必要な機能だけを条件付きで無効化すればよい。
  もっと単純に言えば、負担は要求する側にある。明確でなかったり、抜け道をうまく探ろうとしているなら、答えはいいえだ。厳しく聞こえるかもしれないが、アプリ開発者は権限を任意にすることで、この追加の手順を完全に避けられる。
  これを強制することに注力すれば、些細な軍拡競争は不要になり、人にとってもよりよい選択になる。

  • よさそうに見えるが、どうやって強制するのか。
    ここで強制できる主体は Google/Apple/Microsoft のアプリストア だけだ。彼らにこれを一貫してユーザーフレンドリーな形で執行する十分な動機があるのか、確信しにくい。あるのなら、すでにそうしていたはずだ。

• Samsung のスマートフォンには カメラアクセス とマイクアクセスのトグルがある。
  オフにすると次のようなメッセージが表示される:

  Turn off Camera access?  
  All apps will be blocked from using the camera. Apps  
  will still work, but they will only be able to access an  
  empty black screen. For example, you can still make  
  and receive video calls, but the other person won't be  
  able to see you.  
  

  • マイクアクセスの場合:

    Turn off Microphone access?  
    All apps will be blocked from using the microphone  
    Apps will still work, but they won't be able to access  
    any sounds from the microphone. For example, you  
    can still make and receive calls, but the other person  
    won't be able to hear you.  
    

• 「すべてのカテゴリに『はい、ただしアプリには偽データを提供』というオプション」よりも、アプリごとの設定 のほうがよい。
  位置データはほとんどのアプリに渡したくないかもしれないが、Google Maps や緊急通報アプリには渡してもよい。連絡先や個人データも同様だ。
  ただしそのようなアプリは、ユーザープロファイリングで利益を得ている Google や他社から強い抵抗を受けるだろう。

  • 同意するが、アプリごとであると同時に 権限カテゴリごと であるべきだ。
    たとえばあるアプリでは一つの権限に実データを与え、別の権限には偽データやユーザー指定/手動入力のデータを与え、三つ目の権限は拒否できるようにすべきだ。
    テスト目的や、現在地の天気を表示するアプリで一時的に別の場所の天気を見てから実際の位置に戻すような場合には、設定を一時的に変えたくなることもある。

• アプリが私の体験、それも 私の体験だけを改善 するために私のデータを必要としているなら、偽データを与えたときに悪くなるのは私の体験だけであるべきだ。アプリ開発者や所有者にとっては関係ないはずだ。
  しかし、多くの場合のように目的が私をデータマイニングすることなら、偽データはそれを妨げるのにうまく機能するだろう。
  もちろん WhatsApp のような場合には、あまり意味がない。人々は少しだけ良いメッセージング体験を得るために、連絡先リスト全体を喜んで Facebook/Meta と同期してしまうからだ。

  • 私もそうせざるを得ず非常に不快だったが、それは「少しだけ良い体験」というレベルではなかった。
    少なくともモバイルでは、連絡先を同期するまではアプリもサービスもかろうじて使える程度だった。