ユーザーを誤認させるChromeのサードパーティCookie強化

 (brave.com)
1 ポイント 投稿者 GN⁺ 2024-08-30 | 1件のコメント | WhatsAppで共有
  • Chromeの Related Website Sets(RWS) は、サードパーティCookie廃止後も関連サイト間での情報共有を例外的に許可し、Webプライバシー保護を弱める可能性がある
  • この機能は、ユーザーがサイト間の所有関係を見分けられるという前提に依存しているが、30人を対象とした研究では全判断の約 42% が誤答で、約 73% は少なくとも1回は間違えた
  • Chromeが「関連サイト」と分類した場合でも、ユーザーは約 37% を無関係だと判断しており、ユーザーが想定しないサイト間追跡が可能になるおそれがある
  • 関係を確認するにはまずサイトを開かなければならないため、共有ブランディングやロゴを見た時点で、すでに情報共有と追跡の機会が生じる
  • Brave、Firefox、SafariはRWSまたは旧名称の First-Party Sets に反対しており、この提案はW3C Privacy Community Groupからも削除された

RWSが変えるWebプライバシーの前提

  • Related Website Sets(RWS) は、GoogleがサードパーティCookie終了を前にChromeへ導入した機能である
  • Googleは、RWSがサイト互換性の問題を減らし、関連ドメイン間でログイン状態を維持するのに役立つと主張している
  • Braveは、RWSはユーザー利益より広告主利益を優先し、サードパーティCookie廃止後もサイト間の接続を継続的に許可する仕組みだと批判している
  • 核心となる前提は、2つのサイトが同じ組織によって運営されているなら、ユーザーは情報共有を予想でき、ブラウザがサードパーティCookie並みの遮断を適用しなくてもよいというものである
    • 例としてMetaが運営する instagram.com と facebook.com が挙げられている
  • この前提は、同一組織の所有という理由だけでサイト間追跡を許容してよいという方向へ、Webプライバシーモデルを弱体化させる

ユーザー調査: サイトの関係は当てにくい

  • 研究では、RWSの中心的な仮定である「Web利用者は2つのサイトの関係を正確に判断できるか」を検証した
  • 研究チームは、ソーシャルメディアで募集した Webユーザー30人 に対して、それぞれ Webサイト20組 を提示した
    • Webサイトの組は、Chromeの RWSリスト と人気Webサイト一覧の Tranco から無作為に選ばれた
    • 参加者は、2つのサイトが同じ組織によって運営されていると思うかどうかを判断した
    • 一部の参加者が全設問に回答しなかったため、合計 430件 のユニークなサイト組に対する判断が収集された
  • ユーザーの期待はRWSリストとしばしば食い違った
    • 約 73% の参加者が少なくとも1回は2つのサイト関係を誤って判断した
    • 全判断のうち約 42% が誤答だった
    • RWS基準で実際に関連しているサイト組であっても、ユーザーは約 37% を無関係だと見なした
  • この結果は、RWSがユーザーの想定しない状況でも、サードパーティCookieに類似した動作を再び可能にしうることを示している
  • 論文全文は arXiv論文 として公開されており、2024 Internet Measurement Conference で発表予定である

判断より先に発生する追跡機会

  • RWSの直感的な考え方は、ユーザーがサイトAとサイトBの関係を把握し、その関係を受け入れられる場合にのみサイトBを訪問するというものである
  • 実際には、ユーザーがサイトBの 共有ブランディングやロゴ を確認するには、まずサイトBを読み込む必要がある
  • ページが読み込まれた瞬間に、情報共有とサイト間追跡の機会はすでに発生している
  • したがってRWSは、ユーザーが2つのサイトの関係を判断する前に、プライバシー上の被害を生じさせうる

同一組織の所有は追跡許可の根拠ではない

  • RWSは、2つのサイトが関連していれば、ブラウザが両サイト間のプライバシー保護を弱めても無害、または許容可能だという考えに基づいている
  • Braveはこの前提は誤りだと見ている
    • ユーザーがFacebookアカウントとInstagramアカウントを別々のメールアドレスや情報で登録した場合、最新のブラウザは、それら2つのアカウントが同一人物の所有であることをMetaが把握できないように防げる
    • Brave、Firefox、Safariのような一般向けブラウザや、Tor Browser、Icefoxのような特定目的ブラウザも、このような保護を既定の動作として提供できる
  • 一部の企業は、リンクデコレーション や バウンストラッキング によってブラウザのプライバシー保護を回避しようとしている
  • プライバシー重視ブラウザがサイト間追跡を遮断する手法を実験している一方で、Chromeはサイト間接続を許可する機能を設計している点が中核的な違いである

ブラウザと標準化コミュニティの反応

  • RWSは一般的なWeb提案のように提示されたが、Webエコシステムのさまざまな主体がすでに検討したうえで拒否している
  • Brave、Firefox、Safari は、RWSまたは旧名称の First-Party Sets がユーザーとWebにとって望ましくないという立場を公に示している
  • この提案は W3C Privacy Community Group から削除され、W3Cのプライバシー重視グループではもはや検討されていない

所有権変更と言語の壁

  • RWSリストに入ったドメインは、後になって別の所有者へ渡る可能性がある
    • 今日A、B、Cドメインが同じ組織によって運営されているからといって、明日も同じ組織の所有である保証はない
    • 信頼されていたブラウザ拡張機能が悪意ある主体に売却されたり、人気ソフトウェアライブラリや依存関係が乗っ取られたりした事例と同種のリスクがある
    • サイトがリストに含まれた時点では意味のある関連性があっても、所有権がひそかに変わったときにそれを除外する仕組みがないという懸念が残る
  • 言語と認識の問題もある
    • 英語話者が英語サイトを評価する状況であっても、Googleが関連ありと判断したサイトをユーザーは予想できなかった
    • ユーザーが知らない言語のサイトを訪れる場合、関係判断はさらに難しくなりうる

結論

  • RWSは3つの点でWebプライバシーに有害となりうる
    • ユーザーがどのサイト同士が関連しているかを予測できるという前提が、実際のユーザー行動と一致しない
    • ユーザーが2つのサイトが同じ組織によって運営されているかを判断する前に、すでにサイト間追跡の機会が生じる
    • 同じ組織が所有するサイトであれば、その組織がサイト間でユーザーを追跡してよいという仮定をWebプラットフォームに固定化してしまう
  • プライバシーを尊重するブラウザは、所有組織に関係なく、すべてのサイトによる追跡を防ごうとする方向へ進んでいる

関連記事

1件のコメント

 
GN⁺ 2024-08-30
Hacker News の意見
  • 長年 Firefox を使ってきたが、大きな問題はなかった。以前、メモリが少なかった頃は Chrome のほうがメモリ使用量は少なかったが、Firefox にも HTTPS 専用モード、フォールバック経路のない暗号化 DNS、SOCKS、Encrypted Client Hello のサポートがある
    ただし Encrypted Client Hello に対応しているウェブサイトはほとんどない。メモリは単に追加で買うほうがよく、Apple 製品を使っている幸運な場合は例外かもしれない
    ブラウザはユーザーの側に立つべきで、マーケティング会社と協力すべきではない。さらに、ユーザー追跡やフィンガープリンティングを難しくすべきだ。ユーザーの閲覧履歴を追跡する必要はなく、競合製品より優れた製品を作り、レビューや比較で1位を取り、インフルエンサー広告を買えばよい
    ブラウザが Canvas データの読み取り、GPU 名の読み取り、オーディオカードの列挙、インストール済み拡張機能の検出などを防ぎ、フィンガープリンティングをさらに難しくしてくれるとよい。新しい Web API はフィンガープリントデータが増えないことを保証するか、権限の背後に隠すべきだ
    サードパーティ Cookie は RWS のような怪しげなリストではなく、それに依存する古いウェブサイトで例外的に許可するボタンをブラウザが提供すればよい。ただし、新聞、ブログ、Q&A サイトがコンテンツを見るにはボタンを押せと強要する危険はある
    • ブラウザは本来、ユーザーのために働くユーザーエージェントであるべきだった。最近は、ユーザーを犠牲にして広告会社のために働かないブラウザを見つけるのがますます難しくなっている
      Chrome の存在理由はデータ収集であり、Firefox は少なくとも今のところ、ユーザー寄りに強化設定すれば相当なフィンガープリンティングを防げる。しかし Mozilla も今や広告技術企業になり、Firefox がデフォルトでユーザーを監視し、そのデータをマーケターに売れるようにした点で、Firefox ユーザーへの敬意が欠けていることを示した
      現在は about:config で dom.private-attribution.submission.enabled を false に設定すれば、その監視をオフにできる
      https://news.ycombinator.com/item?id=41311479 と https://web.archive.org/web/20240827185708/https://make-fire... を参照。この選択肢がどれほど長く維持されるのか、アップデート後にどれほど頻繁に再び false に戻さなければならないのかは分からない
      本当にユーザーの利益のために動作する新しいブラウザが必要だ
    • 新しい Web API がフィンガープリントデータをこれ以上提供しないと保証するのは、事実上不可能だ。権限通知でユーザーが選択肢を選んだか、選んだなら何を選んだか自体が、すでにデータポイントになるからだ
      そのため、この問題の唯一の解決策は規制だという話がよく出ており、その見方にはかなり説得力がある
    • https://news.ycombinator.com/item?id=40703546 — 2か月前の内容
    • トップのブラウザが広告会社で開発されている状況では、ユーザー寄りのポリシーを実行するのはかなり難しい。さらに悪いことに、同じ会社が Firefox 財団にも貢献し、Web「標準」も主導している
      すべて談合のように見えるし、ブラウザがそれを実行する OS よりも複雑になったのも、小さなチームが盤面を揺さぶれないようにするための意図的な構造だ。意固地な解決策は、可能な限り Web を避け、人間的な規模のコンピューティングに集中することだ
    • ブラウザメーカーの最優先課題は、ユーザーのブラウザフィンガープリンティング防止であるべきだ
      Cookie をめぐるニュースや政策論議はすべて、限定的な暴露のように見える
  • こういう結果はかなり目に見えている。Related Website Sets（RWS）は、企業がサイト間の関係を宣言し、ブラウザが特定目的の限定的なサードパーティ Cookie アクセスを許可する仕組みだという
    つまり、ウェブサイトがサードパーティ Cookie ブロックを直接迂回できる「お墨付き」のドメインを宣言するようなものなのか？ 大規模ウェブサイトは、ユーザーが自分を守ろうとする試みを迂回して悪用する方法を探し続けている。こうしたサイトがこれを悪用しないと、どうして信じられるのか
    • ウェブサイトが直接宣言するわけではない。提出しなければならないマスターリストがあり、承認プロセスを経る必要がある
      しかし記事で扱われているように、予備リストの内容を見るだけでもすでに不安だ。「広告に関するあらゆることの仲裁者としての Google」という発想は失敗だ
      とはいえ代替案もよくはない。現在のサードパーティ Cookie システムは、はるかに悪いことを許している。もっと良いアイデアが必要だ
    • 詳しくは知らないが、最近 Safari で見たものに似ているのか気になる。関連する Microsoft のウェブサイトを訪れたとき、ログイン用 Cookie の共有を許可するかというポップアップが出て、承認または拒否できた
      そちらの実装のほうが良さそうに見える
  • これは難しい状況だ。ドメイン間の関係を、ユーザーが予想しない形で結び付けて追跡するために悪用できるし、実際に悪用されるだろう
    しかし正当なユースケースもある。たとえば Stack Exchange 系のサイトは明らかに関連しており、統一ブランドもあるが、異なるドメインを使っている。サードパーティ Cookie をブロックする Firefox では各ドメインごとに個別にログインしなければならず、stackoverflow.com にログインした後で superuser.com に行っても、すでにログイン済みの状態にはならない。First Party Sets が解決しようとしている問題はまさにこの部分だ
    こうしたサイトが単一の統合ドメインのサブドメインだったほうがよかったとは言える。しかしサイトが作られた当時はサードパーティ Cookie が問題なく機能していたため、そうしなければならない強い理由はなかった。アプリを別のドメインへ移しつつユーザーに問題を起こさないようにするのは、本当に苦痛でコストも非常に高くなり得る
    First Party Sets をそのまま受け入れるべきだという意味ではないが、実際の問題を解決しようとする試みではある。ユーザーのプライバシーを守りながら、実際に関連しているサイトの良い体験も維持する解決策を見つけるのは難しい、あるいは不可能かもしれない
    • stackoverflow.com にログインした後で superuser.com でも自動ログインされるようにするには、「このサイトは stackexchange.com と Cookie を共有しようとしています。ログインするには許可、永久に拒否するには拒否、後で決めるには無視を押してください」のような権限ポップアップが期待される

1クリックで両方の利点を享受できる。混乱を減らすには、すべてのウェブサイトが全サブサイトで共有される単一の「ファーストパーティドメイン」を持つようにし、そのファーストパーティドメインは自分自身以外のどのサイトともCookieを共有できないようにすべき

  • SafariとFirefoxはすでに何年も前からサードパーティCookieのブロックを行ってきた。Stack Overflowには「正しい」組織構造に適応し移行する時間が十分にあった
    複数ドメインで統合ログインを許可することを重要視していたなら、とっくにサブドメインモデルへ移行しているべきだった。Firefox、Safariユーザーは長い間、悪影響を受けてきたからだ
    それほど重要視していないならそれでもよいが、そうであればChromeのサードパーティCookieブロックやFirst Party Setsの議論も、彼らにはあまり関係ないはず
  • Stack Overflowは2008年に作られた。Netscapeは1997年にサードパーティCookieのブロックボタンを追加しており、ウェブは概してその機能をオンにした状態でもうまく動作してきた
  • Googleが、広告ブロッカーのような正当なユースケースがあったにもかかわらず、Manifest V3へ都合よく移行したことを思い出す。技術的にはV3のほうがより安全でユーザーにとって良い可能性もあるが、ここでは逆方向の動きのように感じる
  • 他のサイトはリダイレクトとクロスオリジンヘッダーでこの問題をうまく処理しているようだ。どこかの時点でsignin.foo.comに到達はするが、ユーザー体験としては再ログインせず認証済みに見える
  • Googleは他のブラウザが自社のリストをそのままコピーすることを期待しているのか
    それとも開発者が関連ドメインを各ブラウザに提出し、ブラウザごとに独自のリストを維持しなければならないのか
    HSTSに似て聞こえる
    [0]: https://github.com/GoogleChrome/related-website-sets/blob/ma...
  • Braveがこの話題について良い情報源、あるいは客観的な情報源であるようには見えない
    • BraveにChromeへ不満を言う商業的インセンティブがあるのは明らかだが、だからといってその不満が虚偽になるわけではない
    • Braveが競合相手だという意味なのか、それとも別の意味なのか気になる
  • そろそろ/.well-known/related-website-set.jsonをブロックし始める時期のようだ
  • 「ChromeでサードパーティCookieが廃止された後でも」という文言を見ると、この記事は数週間前に書かれたようだ
    • 説明してもらえる？
  • Firefoxを使っているので気にしない
    • Firefoxがこれをサポートするか、そうでなければ好きなウェブサイトが動作せず、結局動作するChromeへ移ることになるだろう
  • パドメ：ではBraveはもうChromeベースではなくなるんですよね？
    • BraveはChromeではなくChromium派生ブラウザだ。この状況がなぜChromium派生をやめるべきだという意味になるのか分からない
      Cookieポリシーとデフォルト値は望むように開発し配布できる
    • Braveにはソフトウェアエンジニアがいるので、Chromeエンジンの多くの部分でそうしているように、そのコード部分だけを無効にして進める計画なのだろう
  • ここがぴったりの場所ではないが、Chromeの広告Topicsに関する研究や記事を知っている人がいれば知りたい。ユーザーのプライバシーにどんな影響があるのか、サードパーティと何が共有されるのか、今はほとんど分からない