Googleサインイン・パーミッション

この記事は、Braveブラウザのプライバシー機能について説明する継続的な定期連載の24回目の投稿です。今回は、リサーチ＆プライバシーエンジニアのShivan Kaul Sahibが行った作業について紹介します。この投稿は、プライバシーエンジニアリングVPのPeter Snyderによる投稿の日本語訳です。

Braveバージョン1.51より、従来の（Googleアカウントでサイトにログインするために、サードパーティのCookieやその他望ましくない技術を必要とする）Googleサインインをカバーするために、ブラウザの権限システムを拡張し、ユーザーのプライバシー保護を強化します。この新機能は、Braveの既存のオプションである、レガシーなGoogleサインイン時の「許可」「拒否」設定に取って代わるものです。この機能はデスクトップとAndroidで利用できるようになり、ユーザーのプライバシーを考慮せずに設計されたWebAPIにBraveがクラス最高のプライバシー保護を追加する形の新たな機能となります。

“Googleサインイン"の良い面、悪い面

Googleは、多くの一般的なアカウントベースのサイトと同様に、Googleアカウントを使用して他のサイトにログインすることができます。この機能は、シングルサインオン（SSO）と呼ばれることもありますが、セキュリティ上の利点とプライバシー上のリスクの両方があります。

SSOシステムにはいくつか利点があります。第一に、SSOシステムはユーザーにとって非常に便利で、異なるサイトでしばしば面倒なアカウント作成プロセス不要にします。第二に、より重要なこととして、SSOシステム全般的に（“Sign in with Google” では特に）、ユーザーのセキュリティを向上させることができるということです。ユーザがユーザ名とパスワードを持つ何十、何百もの（様々なセキュリティ対策をとっているであろう）Webサイトを信頼する代わりに、ユーザはGoogleの管理ではないサイトであっても、Googleの最高のセキュリティ機能の恩恵を受けることができます。二要素認証（2FA）、高度なアカウント保護機能、業界トップクラスのセキュリティチームなど、Googleのセキュリティに対する確かな自信がうかがえます。

しかし、SSOシステムはユーザーにとってあまりよくない一面もあります。たとえば、SSOシステムの中央集権的な性質は、なにか欠陥があるとWeb全体に影響を及ぼす可能性があることを意味します¹。さらにこの投稿に関連したところでいうと、SSOシステムは構築と実装の方法によっては、ユーザーのプライバシーを危険にさらすことがあるのです。SSOシステムは必然的に、SSOプロバイダーがユーザーの他のサイトでの行動について²を知ることになり、多くのシステムはSSOプロバイダーが多くの機密情報や個人情報を知ることを可能にします。

Braveにおける"Googleサインイン"の過去と現在

ほとんどの場合、Braveはすでに、Googleサインインと連動する際に、ユーザーのプライバシーを保護しています。人々が意図的かつ明示的にGoogleアカウントを使用してサイトにログインしない限り、BraveはGoogleがそれらのサイトについて知ることをブロックします。

しかし、サイトがGoogleサインインを組み込む方法は数多くあり、その中でも最も古いものは、なんの制限もないサードパーティCookieに依存しています。これに対処するため、Braveはデフォルトで、一般的なブラウザの中で最も強力なサードパーティCookieプロテクションを適用しています。これは、堅牢でクラス最高のプライバシー保護を提供するという利点がありますが、制限のないサードパーティークッキーに依存するシステムとの互換性の問題を引き起こすという欠点もあります。

BraveがこれまでどのようにGoogleサインインを制御していたか

これまで、BraveはGoogleサインインに関する設定を、単一のグローバル設定としてbrave://settings/socialBlocking で提供していました。この設定が オフ の場合、Braveは、Web上のすべてのリクエストに対してサードパーティのクッキーをブロックするように、Googleサインインシステムに対するサードパーティのクッキーをブロックしました。しかし、この設定が オン の場合、Braveはサードパーティ・クッキー・ポリシーに1つの例外を設け、Googleのサインイン・システムがGoogleのクッキーにアクセスすることを許可していました。

この例外は、Googleのログインに使用されるURLにのみ影響し³、他のGoogleシステム（Google Analytics、Google Tag Manager、Doubleclickなど）がサードパーティCookieにアクセスできるようにはしませんでした。しかしそれとは関係なく、この例外が有効になるとデスクトップとAndroidのBraveブラウザは、この狭義のケースにおいてはサードパーティ・クッキーをGoogleに送信するようになりました。

Braveが現在どのようにGoogleサインインを制御しているか

Braveはバージョン1.51から、グローバルなオンオフによる例外設定を削除し、権限ベースのシステムに移行しました。これにより、Googleサインインが提供する利便性とセキュリティを活かしつつ、サードパーティーのクッキーがいつGoogleに送信されるかをユーザーが制御できるようになりました。Webサイトが、サインインにサードパーティCookieを使用しない新しいGoogle Identity Services for Webソリューションをすでに使用している場合、変更はありません。

Braveの新しいGoogleサインイン権限は、権限の持続時間の制御や、サードパーティのiframeでの権限の分割など、Chromiumの権限制御を応用したこれまでのプライバシー機能拡張に基づいて構築されています。

他のブラウザとの比較

Googleサインインに対するBraveのパーミッション型のアプローチは、様々なブラウザの中でも独特なものです。他のブラウザは、Googleサインイン（および他の類似サービス）と互換性を保つため、別のシステムを使用しています。他のブラウザが使用するアプローチは、Braveのプライバシー目標やバリューとは相容れないため、私たちは独自のパーミッションを必要とするアプローチを開発する必要がありました。

Chromeのアプローチ

ChromeはサードパーティCookieを制限する必要がないため、サードパーティCookieを用いるSSOとの互角性を保つために特段のシステムを必要としません。Chromeでは、SSOプロバイダーは、サードパーティのトラッカーや広告主がWeb上でユーザーを追跡するために使用する技術とまったく同じものを使用しています¹。 このアプローチは、Braveのプライバシー・ファーストの原則と根本的に相容れません。

Edge、Firefox、Safariのアプローチ

他のブラウザは、サードパーティCookieにいくつかの制限を適用しています。Edgeは、トラッカーのDisconnectリストに指定されているサードパーティCookieを制限し、FirefoxとSafariは、すべてのサイトでサードパーティCookieを制限（つまりパーティション）しています。これらのブラウザは、ストレージアクセスAPIと呼ばれるシステム（さらにその上に様々なヒューリスティック）を使用することにより、Googleサインインのようなシステムとの互換性を維持しています。ストレージアクセスAPIはもともとSafariで開発されたもので、ユーザーから許可を得た場合に限り、サードパーティのフレームが制限のないサードパーティのクッキーにアクセスできるようになっています。

ストレージアクセスAPIは、BraveのGoogleサインイン・パーミッションと似ているようで実は全く異なります。両者は、ユーザーが許可を与えた後、第三者がファーストパーティ・クッキーにアクセスすることを許可するだけのシステムである点で似ているのですが、ストレージアクセスAPIは、第三者がどのような目的でもアクセスを要求できる汎用APIであるのに対し、Braveのシステムは目的別であり、狭い特定の目的のためにのみサードパーティークッキーを使用可能にするという点において異なっています。

BraveはChromiumのストレージアクセスAPIを無効にしています。なぜならストレージアクセスAPIによるアプローチがWeb上のプライバシーを保護する正しい方法ではないと考えるからです。ストレージアクセスAPIは、ユーザーに理解できないプライバシーリスクの高い選択を求め、総じてユーザー自身がプライバシーに対する責任を負うことを要求します。これに対し、Braveのシステムでは、サードパーティのクッキーは、特定のわかりやすい目的のためにのみ、また非常に限られた時間（ログインプロセスを完了するのに必要な時間）だけ送信を可能にします。

ストレージアクセスAPIは、それ以前のもの（サードパーティのクッキーへの無制限のアクセスか、多くのサードパーティの統合を壊すかのどちらかを選ぶなど）に比べて、非常に大きな進歩でした。ストレージアクセスAPIの設計者と開発者は、彼らの仕事がもたらしたプライバシーの改善に大いに貢献してくれました。しかしBraveは、ストレージアクセスAPIは、一時的な応急処置のアプローチとしては最適な方法だと考えますが、同時にそれ自体が重大な欠点を持っています。Webは、エフェメラル・サードパーティ・ストレージなどの他の優れた保護機能に注目する必要があります。

より期待される未来

ありがたいことに、他の多くのブラウザは、サイト同士が通信する必要がある場合に、ユーザーのプライバシーを保護するために、限られた範囲で利用する目的別のAPIが必要であることに賛同しています。Braveでは、Federated Credential Management (FedCM) APIのような取り組みに期待しています。このAPIは、ストレージアクセスAPIのようなサードパーティ状態への広範で無制限のアクセス許可ではなく、Googleサインインなどの目的でサイト間の情報を限定的に要求することを可能にするでしょう。Braveは、現在のFedCMの提案をまだ精査している段階ですが、この取り組みには広く賛同しています。ある意味、Googleサインインを可能にするためのBraveの新しい権限ベースのアプローチは、FedCMの将来のプライバシーに関する約束を今日のWebユーザーにもたらすためのBraveの取り組みと言えます。

Braveの「Googleサインイン」許可機能は、BraveのWebプライバシーに対するアプローチの新たな一例です。現在のユーザーに対して可能な限り強力なプライバシー保護を提供する一方で、標準化団体と協力して将来のWebの方向性をよりユーザーにとって望ましいものにします。