昨年、ウェブ アプリケーション用の Google ログイン JavaScript プラットフォーム ライブラリのサポート終了予定についてお知らせしました。
Google ログイン JavaScript プラットフォーム ライブラリは、2023 年 3 月 31 日に完全に提供を終了します。ウェブ アプリケーションへの影響を確認し、必要に応じて移行計画を立てていただくよう、改めてお願いします。
2022 年 4 月 30 日より、新規アプリケーションは Google Identity Services ライブラリを使う必要があります。既存のアプリケーションは、サポート終了日までプラットフォーム ライブラリを使い続けることができます。
サポートの終了による影響の有無と、Google Identity Services に移行する必要性を評価してください。 移行は 2023 年 3 月 31 日までに終えてください。この日をすぎると、プラットフォーム ライブラリはダウンロードできなくなり、非推奨の認可機能から Google API を呼び出すためにアクセス トークンを取得しているウェブ アプリケーションは、意図したとおりに動作しなくなります。
Google は、ウェブでユーザーの個人情報を守るために、アプリやサービスへのログインをデフォルトで安全なものにする取り組みを続けています。その実現に向けて、Identity API ファミリーの一員である Google Identity Services についてお知らせしました。これは、複数の ID サービスを 1 つのソフトウェア開発キット（SDK）にまとめたものです。先日、Google Identity Services ライブラリのアップデートをリリースし、OAuth 2.0 に基づいたユーザー認可とデータ共有の機能を追加しました。新しい Identity Services ライブラリでは、さまざまなセキュリティやプライバシーの改善が行われているため、古いプラットフォーム ライブラリのすべての機能との間に完全な下位互換性があるわけではありません。そのため、新しいライブラリへの移行とコードの変更が必要になります。
サポートの終了は、Google ログイン JavaScript プラットフォーム ライブラリを読み込んでいるウェブ アプリケーションと、JavaScript 用 Google API クライアント ライブラリでアクセス トークンを扱っているアプリケーションに影響します。
ウェブページで JavaScript モジュール apis.google.com/js/api.js または apis.google.com/js/client.js を使ってプラットフォーム ライブラリを読み込んでいる場合は、影響を受けますので、新しい Identity Services クライアント ライブラリを使うように既存の実装を更新する必要があります。
apis.google.com/js/api.js
apis.google.com/js/client.js
Google API クライアント ライブラリから gapi.client を使っているウェブ アプリケーションは、Google API を呼び出すためのアクセス トークンを扱う際に、まもなく非推奨となるプラットフォーム ライブラリの gapi.auth2 モジュールを暗黙的に読み込んで使用していますそのため、ウェブ アプリケーションを更新し、新しい Identity Services ライブラリを明示的に追加する必要があります。そのうえで、アクセス トークンのリクエストを管理するようにし、auth2 モジュールへの参照を、同等の機能を持つ新メソッドで置き換えます。
gapi.client
gapi.auth2
一連のアプリケーションやプラットフォームで別の手法を使って Google の認証や認可を行っている方もいるでしょう。以下は、今回のサポートの終了のお知らせの影響は受けません。
Android や iOS のネイティブ アプリ SDK Google の OAuth 2.0 または OpenID サービスを直接呼び出しているバックエンド プラットフォーム
新しい Identity Services ライブラリでは、認可機能と認証機能が明確に分かれています。
移行には、次の 2 つのガイドが役立ちます。
(1) ユーザーの認可と Google API で利用するアクセス トークンの取得をするために Google Identity Services に移行する (2) ユーザーの認証とログインをするために Google ログインから移行する
(1) ユーザーの認可と Google API で利用するアクセス トークンの取得をするために Google Identity Services に移行する
(2) ユーザーの認証とログインをするために Google ログインから移行する
認可（Google API を呼び出すため）と認証（ユーザーのアプリへのログインを管理するため）の両方を使っているウェブ アプリケーションもあるかもしれません。その場合は、両方の移行ガイドに従い、ウェブ アプリケーションでユーザーの認可フローと認証フローを確実に分離する必要があります。
2 つの移行ガイドは、新しい Identity Services ライブラリと古いライブラリの違い、変更点の内容、認証と認可を分離する方法、その変更がユーザーやコードベースに与える影響について理解できるように記述されています。
新しい Identity Services ライブラリに移行すると、さまざまな変更によるたくさんのメリットを活用できます。
ポップアップが表示されるので、ユーザーはリダイレクトされたり、サイトを離れたりすることなく、わかりやすい UX で安全にウェブ アプリケーションを認可できます。 デフォルトでプライバシーと制御が向上します。ユーザーは必要な場合にのみ個々のスコープを承認できるので、ウェブ アプリケーションと共有する機密データの範囲やタイミングが改善されます。 ID トークンとアクセス トークンという認証情報が分離されるので、ユーザーの ID とアプリケーションの機能を明確に区別できます。認証情報を分ける方が、リスクのレベルに応じた分離、管理、保存がしやすくなります。ID は、その人が誰かという情報のみを表すので、ユーザーの機密データを読み書きする機能のアクセス トークンと比べると、リスクのレベルは低くなります。 Chromium のプライバシー サンドボックスの変更と上位互換性があります。
この記事は、新しい Identity Services ライブラリによるプライバシー、セキュリティ、ユーザビリティの変更を簡潔にまとめたものです。さらに詳しい説明は、移行ガイドに掲載されています。
詳しい情報は、デベロッパー サイトに掲載されています。技術サポートを受けたい方は、Stack Overflow で google-oauth タグを確認してください。提案やフィードバックがある方は、gis-migration-feedback@google.com にメールをお送りください。
以下の変更は、7 つのフェーズに分け、オリジン トライアルのフィードバックを待ちながら、時間をかけて徐々にロールアウトする予定です。
削減の準備
フェーズ 1: Chrome 92 から（2021 年 7 月 20 日）推奨される対応（CTA）: サイトの使用方法を監査し、移行が必要になる可能性がある箇所を把握してください。 M92 より、navigator.userAgent、navigator.appVersion、navigator.platform へのアクセスに関する警告を DevTools に表示します。
navigator.userAgent
navigator.appVersion
navigator.platform
削減のロールアウト
フェーズ 5: Chrome 107CTA: サイトで削減版のデスクトップ UA 文字列と関連する JS API との互換性を確保してください。確保できない場合は、UA Client Hints に移行します。 削減版のデスクトップ UA 文字列と関連する JS API（navigator.userAgent、navigator.appVersion、navigator.platform）のロールアウトを開始します。これがロールアウトされると、デスクトップのオペレーティング システムで、デプリケーション トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。
削減の完了
1 年ほど前に、User-Agent 文字列で公開される情報の粒度を徐々に削減する計画についてお知らせしました。この文字列は、デフォルトで HTTP リクエストのたびに送信されています。その直後、COVID-19 パンデミックの初期段階でウェブのエコシステムに移行の負荷をかけないよう、この取り組みを一時的に停止することを決めました。それ以降は、多大な時間を費やしてエコシステムから貴重なフィードバックを集め、これに代わるコンテンツのネゴシエーションと検出用の仕組みとして提唱している User-Agent Client Hints API（UA-CH）への人間工学的な改善を提案したり、ウェブの互換性の修正をしました。
現在、UA-CH はデフォルトで Chrome に搭載されています（M89 以降）。また、最初のリクエストでヒントが必要になるユースケースに対処するため、両方の Client Hints Reliability の仕組み（Critical-CH と ACCEPT_CH）のロールアウトも始めました。今後予定されている User-Agent 文字列削減の変更の厳密な日程やマイルストーンはまだお知らせできませんが、この領域の取り組みを再開する準備はできています。
とは言うものの、エコシステムやデベロッパーがユースケースをテストし、フィードバックを送り、適切な場合は UA-CH に移行する十分な時間を確保できる形で作業を進めることが重要だと感じています。そのため、2021 年中は、Chrome の安定版チャンネルで User-Agent 文字列の変更は行わない予定です。この投稿の目的は、皆さんが適切な対応計画を立てられるように、早い段階で私たちの考えやロードマップを公開することです。
User-Agent ヘッダー フィールドで公開される情報の粒度を段階的に引き下げることを計画しています。navigator.userAgent、navigator.appVersion、navigator.platform JS API についても同様です。
すべての対応が終わっても、User-Agent 文字列だけでブラウザのメジャー バージョンとプラットフォーム名は確実に取得でき、デスクトップかモバイルか（またはタブレットか）も判別できます。さらに高度なユースケースでは、User Agent Client Hints API に移行する必要があります。
注 : 現時点では、Android WebView や Chrome for iOS の User-Agent 文字列を変更する計画はありませんが、変更の有無やその時期については、あらためてお知らせします。
現在の計画の概要は、以下のとおりです。
以上の変更は、7 つのフェーズに分けて、オリジン トライアルのフィードバックを待ちながら、ゆっくりと段階的にロールアウトする予定です。フェーズ 1 以降のスケジュールとマイルストーンの案については、近日中に最新情報をお知らせします。
フェーズ 1: M92 より、navigator.userAgent、navigator.appVersion、navigator.platform へのアクセスに関する警告を DevTools に表示します。
フェーズ 2: オリジン トライアルを開始し、サイトが最終形まで削減した UA 文字列でテストやフィードバックできる期間を、少なくとも 6 か月間継続します。
フェーズ 3: 移行にさらに時間を要するサイトなどのために、逆オリジン トライアルを開始して、少なくとも 6 か月間継続します。
フェーズ 4: Chrome の MINOR.BUILD.PATCH バージョン番号を削減します（ "0.0.0" ）。これがロールアウトされると、デスクトップとモバイル OS で、逆オリジン トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。
フェーズ 5: 削減版のデスクトップ UA 文字列と関連する JS API（navigator.userAgent、navigator.appVersion、navigator.platform）のロールアウトを開始します。これがロールアウトされると、デスクトップ OS で、逆オリジン トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。
フェーズ 6: 削減版の Android モバイル（とタブレット）の UA 文字列と関連する JS API のロールアウトを開始します。これがロールアウトされると、Android で、逆オリジン トライアルをオプトインしていないすべてのページの読み込みに、削減版の UA 文字列が適用されます。
フェーズ 7: 逆オリジン トライアルが終了し、すべてのページの読み込みに、削減版の UA 文字列と関連する JS API が適用されます。
詳細や、各フェーズでの User-Agent 文字列の例については、削減版の User-Agent 文字列に関する最新情報ページをご覧ください。
この計画は下位互換性を考慮しています。User-Agent 文字列の変更は慎重に行われるべきですが、ロールアウトが行われても、デベロッパーへの影響は最低限に留まると考えています（既存のパーサーは期待どおりに動作するはずです）。
サイトやサービス、ライブラリ、アプリケーションで、Chrome のマイナー バージョン、OS のバージョン番号、Android デバイスのモデルなどの User-Agent 文字列に含まれる一部の情報を使っている場合は、User Agent Client Hints API を使うように移行する必要があります。
これらの情報が必要ない場合は、変更は不要で、これまでどおり動作するはずです。
User Agent Client Hints の説明に記載しているとおり、User-Agent 文字列には 2 つの理由で問題があります。1 つ目は、HTTP リクエストのたびに、ブラウザに関する多くの情報が何もしなくても公開されることです。この情報は、フィンガープリンティングに使われる可能性があります。2 つ目は、時間とともに長く複雑になり、エラーが起こりやすい文字列の解析が必要になることです。User Agent Client Hints API は、デベロッパーにもユーザーにも優しい形で、この 2 つの問題を解決できると考えています。
ある意味、Chrome はこの点で追いつきつつあります。UA 文字列で macOS のバージョン番号を制限したのは Safari が最初で、Firefox もそれに続きました。Firefox は、Windows のバージョン番号も 10 に制限しています。
Federated Learning of Cohorts（FLoC）は、プライバシーを保護しつつ、興味ベースで広告を選択するメカニズムです。ユーザーがウェブを動き回ると、ブラウザは FLoC アルゴリズムを使って「興味コホート」を割り出します。これは、直近の閲覧履歴が似ているたくさんのブラウザで共通するものです。ユーザーのブラウザは一度に 1 つの興味コホートと関連付けられますが、コホートはユーザーのデバイスで定期的（今回の最初のオリジン トライアルの時点では、7 日ごと）に再計算されます。個々の閲覧データがブラウザ ベンダーなどの他者と共有されることはありません。
FLoC の詳細については、Federated Learning of Cohorts（FLoC）の概要をご覧ください。
トライアルは、サードパーティ オリジン トライアルとして Chrome 89 で始まる予定です（元記事公開当時。すでに開始されています）。FLoC オリジン トライアル トークンを取得するには、登録する必要があります。
自分のサイトで興味コホートのデータにアクセスするには、以下の方法のどちらかを使ってウェブページにオリジン トライアル トークンを追加します。
各ページの <head> 内のメタタグに次を含める :
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
HTTP ヘッダーに次を含める :
Origin-Trial: TOKEN_GOES_HERE
これをすると、ファーストパーティ コンテキストで FLoC を試すことができます。たとえば、サイトにアクセスしたユーザーのコホートを確認できます。
サードパーティのサイトで自分のコードから FLoC API をテストするには、メタタグにオリジン トライアル トークンを注入する必要があります。具体的な方法は、ウェブ デベロッパー向けオリジン トライアル ガイドで説明されています。
Chrome のオリジン トライアル サイトから行ってください。このフィードバックは公開されず、Chrome チームの一部のグループのみが利用します。トークンの有効期限が切れると、メールで更新リンクが送られます。トークンを更新する前に、フィードバックの送信を促すメッセージが表示されます。
FLoC API はシンプルで、Promise を返すメソッドが 1 つあるだけです。この Promise は、コホートの id と version を表すオブジェクトに解決されます。
id
version
document.interestCohort()
利用できるようになったコホートのデータは、次のように見えます。
{ "id": "14159", "version": "chrome.1.0" }
FLoC API は Chrome 89 以降で利用できますが、オリジン トライアルに参加していない場合は、フラグを設定してコマンドラインから Chrome を実行する必要があります。さまざまなオペレーティング システムで実行する方法は、フラグ付きで Chromium を実行するで説明されています。
次のフラグを使って Chrome を起動します。
--enable-blink-features=InterestCohortAPI --enable-features="FederatedLearningOfCohorts:update_interval/10s/minimum_history_domain_size_required/1,FlocIdSortingLshBasedComputation,InterestCohortFeaturePolicy"
サードパーティ Cookie がブロックされていないこと、広告ブロッカーが実行されていないことを確認します。
floc.glitch.me のデモを確認します。
FLoC API の説明でユースケースが提示されていますが、API の使用方法は定義されていません。FLoC を使って関連するコンテンツや広告を提供する場合、サイトやサービスによって制約や要件が異なります。
独自の技術によってお勧めコンテンツ、広告、マーケティングのサービスを提供している場合は、FLoC の知見を適用することで、特定のコホートに対して最適なコンテンツやマーケティング メッセージを提供できます。これらのサービスを提供するサードパーティ企業を利用している場合は、その企業がオリジン トライアルに参加し、皆さんのサイトや他のサイトを含めた実験をする方がよいかもしれません。
たとえば、関連コンテンツを選択する方法を探しているパブリッシャーがオリジン トライアルの期間中に FLoC を試すプロセスは、次のようになります。
サイトで宣言をすると、コホートを計算するためのユーザーのサイト一覧からそのサイトが除外されるようにする必要があります。新しい interest-cohort パーミッション ポリシーによって、これが可能になります。このポリシーは、デフォルトで allow となる予定です。
interest-cohort
allow
interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() を呼び出したときに返される Promise はリジェクトされます。メインのフレームに interest-cohort パーミッションがない場合、そのページへのアクセスは興味コホートの計算には使われません。
たとえば、次の HTTP レスポンス ヘッダーを送ると、すべての FLoC コホート計算をオプトアウトできます。
Permissions-Policy: interest-cohort=()
FLoC のオリジン トライアルの期間中、オプトアウトしていないウェブサイトは、そのサイトが広告関連のリソースを読み込んだことが Chrome によって検知されると、FLoC の計算に含まれます。
Chrome で広告検出メカニズムが動作する仕組みについては、Chromium での広告タグ付けで説明されています。
FLoC は、プライバシーを保護しつつ、興味ベースで広告を選択するメカニズムです。
ユーザーがウェブを動き回ると、ブラウザは FLoC アルゴリズムを使って、直近の閲覧履歴が似ているたくさんのブラウザで共通する「興味コホート」を割り出します。コホートはユーザーのデバイスで定期的に再計算されますが、個々の閲覧データがブラウザ ベンダーなどの他者と共有されることはありません。
FLoC は現在 Chrome オリジントライアルの最中です。詳しくは FLoC のオリジン トライアルに参加する方法をご覧ください。
現在の FLoC オリジントライアルでは、以下のいずれかの要因によりブラウザの FLoC 計算に取り込まれます:
他のクラスタリングアルゴリズムでは、今回のトライアルでは異なる取り込み基準で実験を行う可能性があります。これはオリジントライアルの実験手順の一部です。
広告主（お金を払って広告を出稿するサイト）は、自分のウェブサイトにコードを含めてコホートデータを収集し、アドテック プラットフォーム（広告を配信するソフトウェアやツールを提供する企業）に提供できます。たとえば、アドテック プラットフォームは、オンラインの靴店から、コホート 1101 と 1354 のブラウザはこの店のハイキング グッズに興味があるかもしれないことを把握できます。その他の広告主から、アドテック プラットフォームは各コホートのその他の興味を知ることができます。
次に、広告プラットフォームはこのデータを使って、これらのコホートのいずれかに属するブラウザが広告掲載サイト（ニュースサイトなど）のページをリクエストしたときに、関連性が高い広告（先ほどの靴店のハイキング シューズなど）を選択できます。
Privacy Sandbox は、サードパーティ Cookie などのトラッキング メカニズムを使わずにサードパーティ ユースケースを満たすための一連の提案です。各提案の概要については、Privacy Sandbox の詳細をご覧ください。
この提案について、皆さんからのフィードバックが必要です。コメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。この提案に関連する Chrome の試験運用についてフィードバックがある方は、試験運用の目的に返信する形で投稿してください。
多くの企業は、サイトのトラフィックを増加するために広告を利用しています。そして多くのパブリッシャーのウェブサイトは、広告のインベントリを販売することで、コンテンツの資金を得ています。ユーザーは通常、関連性が高く有用な広告を見ることを好みます。また、広告の関連性が高いほど、広告主に多くのビジネスを、広告をホストしているウェブサイトに多くの収益をもたらします。言い換えれば、関連性の高い広告を表示すれば、広告スペースの価値が上がります。したがって、関連性の高い広告を選ぶことで、広告がサポートするウェブサイトの収益が上がります。つまり、関連性の高い広告は、ユーザーにメリットをもたらすコンテンツを制作するための資金源になります。
しかし、多くのユーザーは、関連性の高い広告が示唆するプライバシーの問題を心配しています。現在、このような広告は、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術を利用しています。これらは、個人の閲覧動作を追跡するために使われる技術です。FLoC の提案は、プライバシーを侵害せずに広告選択の効率を高めることを目指しています。
下の例は、FLoC を使って広告を選択するうえでのそれぞれの役割について説明しています。
この例の広告主（お金を払って広告を出稿する企業）は、次のオンライン靴店です。shoestore.example
この例のパブリッシャー（広告スペースを販売するサイト）は、次のニュースサイトです。dailynews.example
アドテック プラットフォーム（広告を配信するソフトウェアやツールを提供する企業）は、次のサイトです。adnetwork.example
この例では、ユーザーを Yoshi と Alex と呼びます。最初の状態では、どちらのブラウザも同じコホート 1354 に属しています。
ここではユーザーを Yoshi と Alex と呼んでいますが、これは例示のみの目的です。FLoC では、広告主、パブリッシャー、アドテック プラットフォームに名前や個々の ID が明かされることはありません。
コホートをユーザーの集合と考えないでください。そうではなく、コホートは閲覧アクティビティをグループ化したものと考えてください。
次は Alex です。
現在の広告選択には、Cookie によるトラッキングやデバイスのフィンガープリンティングなどの技術が利用されています。これらは、広告主などのサードパーティが個人の閲覧行動を追跡するために使われる技術です。
FLoC では、ブラウザは FLoC サービスにも他の誰にも閲覧履歴を送信しません。ブラウザは、ユーザーのデバイス上でブラウザ自身が属するコホートを割り出します。ユーザーの閲覧履歴がデバイスを離れることは一切ありません。
各ブラウザ ベンダーは、それぞれにどのようにコホートを作り出すのかを選択する必要があります。Chrome は独自の FLoC サービスを運用していますが、他のブラウザは異なるクラスタリングアプローチを採った FLoC を実装し、独自のサービスを運用する可能性があります。
このプロセスのどの時点においても、ユーザーの閲覧履歴が FLoC サービスやサードパーティに送信されることはありません。ブラウザのコホートは、ユーザーのデバイス上でブラウザ自身が計算します。FLoC サービスは、ユーザーデータを取得することも、保管することもありません。
はい、ブラウザのコホートはもちろん変わることがあります。毎週同じウェブサイトにアクセスすることはないでしょう。ブラウザのコホートはそれを反映します。
コホートは、ユーザーの集まりではなく、閲覧アクティビティのクラスタを表します。通常、コホートの行動の特徴は時間が経っても一貫性があり、コホートは最近の閲覧行動が似ているグループなので、広告の選択に役立ちます。それぞれのユーザーのブラウザは、閲覧行動の変化とともにコホートを出入りします。まずは、7 日ごとにブラウザがコホートを再計算することを想定しています。
上の例では、Yoshi と Alex のブラウザのコホートはどちらも 1354 でした。将来的に興味が変われば、Yoshi のブラウザと Alex のブラウザが別のコホートに移動する可能性があります。下の例では、Yoshi のブラウザはコホート 1101 に移動し、Alex のブラウザはコホート 1378 に移動します。他のユーザーのブラウザも、閲覧の興味が変わるにつれてコホートを出入りします。
コホートは、ユーザーのグループではなく、閲覧アクティビティのグループを定義します。行動が変わるにつれて、ブラウザはコホートを出入りします。
前述のように、ユーザーのブラウザはコホートの数学モデルの詳細データを FLoC サービスから取得します。これは、すべてのユーザーの閲覧アクティビティを表す多次元空間です。その後、ブラウザはあるアルゴリズムを使い、この「コホート空間」のどの領域（すなわち、どのコホート）が最近の自身の閲覧行動に最も近いかを割り出します。
各コホートには、たくさんのブラウザが存在することになります。
コホートのサイズが小さい場合、広告のパーソナライズには役立つかもしれませんが、ユーザーのトラッキングをやめることにはなりません。逆もまた同様です。ブラウザをコホートに割り当てるメカニズムには、プライバシーと有用性との間でトレードオフが必要になります。Privacy Sandbox は、ユーザーが「集団の中に隠れる」ことができるように、k-匿名性を利用します。コホートは、少なくとも k 人のユーザーによって共有されれば、k-匿名性があります。k の数が大きくなるほど、コホートのプライバシーは高くなります。
FLoC のコホートモデルを作成するために使うクラスタリング アルゴリズムは、なぜ分類がプライベートなのかは知ることなく、コホートにプライベートな分類と相関関係があるかどうかを評価できるように設計されています。人種、性別、病歴など、プライベートな分類が明らかになる可能性があるコホートはブロックされます。言い換えれば、コホートを割り出すとき、ブラウザはプライベートな分類が明らかにならないようなコホートのみを選択します。
FLoC では、ユーザーのブラウザは他のたくさんのユーザーのブラウザとともに、たくさんのコホートのうちの 1 つに属します。サードパーティ Cookie やその他のターゲティング メカニズムとは異なり、FLoC はユーザーのブラウザが属するコホートしか明かさず、個々のユーザー ID が明らかになることはありません。そのため、他者がコホート内の個人を特定することはできません。さらに、ブラウザのコホートを割り出すために使われる閲覧アクティビティに関する情報は、ローカルのブラウザやデバイスに留まり続けて、他の場所にアップロードされることはありません。ブラウザは、差分プライバシーなどの他の手法を使ってさらに匿名化することもできます。
ウェブサイトは、FLoC をオプトインすることもオプトアウトすることもできます。そのため、プライベートなトピックを扱うサイトは、そのサイトへのアクセスを FLoC の計算に含めないようにすることもできます。さらなる保護として、FLoC サービスによる分析では、そのコホートがなぜプライベートであるかを知ることなく、コホートによってユーザーに関するプライベートな情報が明らかになる可能性があるかどうかを評価します。あるコホートで、サイトにアクセスしたユーザーのうちプライベートな分類に属するユーザーの数が典型的なユーザーの数を超えている可能性がある場合、そのコホート全体が削除されます。この分析で扱われるプライベートな分類には、負債状況やメンタルヘルスなどが含まれます。
ウェブサイトは Permissions-Policy ヘッダーに interest-cohort=() を設定すると、FLoC 計算からオプトアウトすることができます。オプトアウトしていないページでは、document.interestCohort() が使われていると、ブラウザの FLoC 計算に含まれることになります。FLoC のオリジントライアル期間中、広告や広告に関連するリソースを読み込むことが検知された場合も、ブラウザの FLoC 計算に含まれることになります（Chrome の広告検知メカニズムの仕組みは、Chromium での広告のタグ付けで説明しています）。イントラネットのサイトなど、プライベートな IP アドレスから提供されているページは、FLoC の計算対象に含まれません。
interest-cohort=()
const { id, version } = await document.interestCohort(); console.log('FLoC ID:', id); console.log('FLoC version:', version);
{ "id": "14159", "version": "chrome.1.0"}
FLoC を使うサイトは、version の値を使って、コホート ID が参照するブラウザと FLoC モデルを知ることができます。以下の説明のとおり、interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() が返す Promise はリジェクトされます。
ファーストパーティとサードパーティのそれぞれのコンテキストで FLoC を試す方法は、FLoC のオリジン トライアルに参加する方法で説明しています。
サイトで interest-cohort パーミッション ポリシーを使うと、コホートを計算するためのユーザーのサイト一覧から除外することを宣言できます。このポリシーは、デフォルトで allow となる予定です。interest-cohort パーミッションが許可されていないフレームでは、document.interestCohort() が返す Promise はリジェクトされます。メインのフレームに interest-cohort permission がない場合、そのページへのアクセスは興味コホートの計算には使われません。
interest-cohort permission
API に関するコメントがある方は、FLoC Explainer リポジトリで Issue を作成してください。
プライバシー サンドボックスの取り組みは、一連のプライバシー保護 API を提案することで、サードパーティ Cookie などのトラッキング メカニズムのないオープンウェブに貢献するビジネスモデルをサポートします。この取り組みは 2019 年に始まり、Chrome では昨年の 1 月と 10 月に最新の進捗状況を共有しました。
1 年間のインキュベーション期間を経た 2021 年はテストの 1 年間となり、ウェブのエコシステムが関与する機会が継続的に発生するでしょう。この投稿では、Privacy Sandbox API とその提案の状況について、最新情報をお届けします。
サイト運営者や広告主は、広告を含め、関連性が高くユーザーが興味を持つコンテンツを提供したいと考えています。現在のウェブでは、どのようなサイトやページにアクセスしたかを観察することでユーザーの興味を測ることが多く、これにはサードパーティ Cookie やデバイスのフィンガープリンティングなど、透過性が低く好ましくない仕組みが使われます。
3 月の Chrome リリース 89 で、Federated Learning of Cohorts API（FLoC）のオリジン トライアルを開始する予定です。FLoC は、同じような閲覧パターンを持つ人々を大きな集団に分類し、「大勢」の中の個人やブラウザの閲覧履歴を隠すことで、関連性の高いコンテンツや広告をユーザーに届ける新しい仕組みを提案します。現在 Google 広告は、FLoC アルゴリズムのテストから得た最新情報を共有しています。このテストによって、関連性の高い興味ベースの広告を提供するという点で、提案された API がサードパーティ Cookie と同様の効果を持つ可能性があることが示されました。
標準化コミュニティで盛んな議論を呼んだユースケースの 1 つが、どうすれば企業はオーディエンスを形成できるか、そしてどうすれば再マーケティングによって以前のユーザーをウェブサイトに呼び戻せるか、ということでした。昨年には、このユースケースに対応しつつ、他の提案と同じプライバシー保護を提供できる TURTLEDOVE が Chrome に導入されました。ウェブサイトは、入札や広告表示に関する情報を含む Interest Group を保存するようブラウザに依頼します。そして、この Interest Group に基づいて広告購入候補者によるオンデバイス入札が行われることになります。
Chrome の新しい FLEDGE（First "Locally-Executed Decision over Groups" Experiment）提案は、寄せられた多くの提案に含まれる新しいコンセプトを組み込んで TURTLEDOVE を拡張したものです。FLEDGE には、オンデバイス入札アルゴリズムで追加情報を利用する仕組みが含まれています。この追加情報は、この目的に限定して設計された、新しい信頼できるサーバーから提供されます。新しい信頼できるサーバーが利用できるようになる前に初期段階の実験をサポートするため、私たちは "Bring Your Own Server" モデルを提案しています。また、この最初の実験は、2021 年中に行いたいと考えています。
マーケティング担当者が広告キャンペーンを行う場合、各広告を見たユーザー数と、それによって購入や登録などの行動に結びついたのかを理解することが重要です。
2020 年 9 月に、パブリック Chrome オリジン トライアルでテストを行うために、Event Conversion Measurement API を公開しました。これを使うと、マーケティング担当者はサードパーティ Cookie を使わずにコンバージョンを測定できます。ブラウザは、クリックとコンバージョンを記録し、匿名レポートを共有します。このテクノロジーは、将来的に「ビュースルー コンバージョン」（ユーザーが広告を見た後、時間をおいて行動する場合）もサポートする予定です。
マーケティング担当者が特定の広告キャンペーンの対象範囲を理解できるように、2020 年 4 月に Aggregate Measurement API を公開しました。この API は、複数のサイトにわたってユニーク ユーザーが広告を見た回数を測定する場合に役立ちます。ここでも、個人の特定に利用される可能性があるデータが公開されることはありません。この仕組みは、ある集計しきい値を超えた場合に一度だけデータを報告することで実現します。Aggregate Measurement API は、今年の前半に公開してパブリック オリジン トライアルとしてテストすることを計画しています。
サイトやサイト運営者は、実際のユーザーと、スパム作成者や詐欺師、ボットを確実に見分けられなければなりません。昨年 7 月には、Trust Tokens API をテスト用に公開しました。この機能は、詐欺に対抗するため、ユーザーの身元を特定することなくユーザーの正当性を評価します。Chrome 89 では、新しいタイプの Trust Token 発行者をサポートするために、オリジン トライアルを導入します。これにより、ユーザーのプライバシーを守りつつ、モバイル デバイスによる詐欺の検出機能を向上させることができます。
2020 年には、現在のウェブ テクノロジーの安全性も向上しました。Chrome と Edge が SameSite Cookie ポリシーを採用し、近日中に Firefox も採用する予定です。このポリシーにより、デベロッパーがサイト間アクセスを必要とすることを明示しない限り、Cookie はファーストパーティとして扱われます。これは Android の Webview にも導入されており、Android S 以降をターゲットとしたアプリでは、"SameSite=Lax" がデフォルトの扱いとなる予定です。
今月の Chrome 88 リリースの新機能として、このポリシーを強化します。具体的には、接続の安全性のダウングレードを含むいくつかの形態のクロスサイト攻撃を防ぐため、SameSite の定義を変更します。これにより、同じホストのドメインの安全なバージョンと安全でないバージョン（https://site.example と http://site.example など）は、お互いにサードパーティと見なされるようになります。
実際のウェブサイトが複数のドメインや国コードドメイン（.com、co.uk、.de など）にまたがる場合があることは認識しています。Chrome 89 では、オリジン トライアルとして First Party Sets を導入する予定です。これにより、ドメイン所有者は関連するウェブドメインのグループが同じ組織に所属するものであることを明示的に宣言できるようになります。この宣言を行うと、対象のドメインはお互いに「同じパーティ」として扱われます。そのため、たとえばショッピング サイトが複数のドメインをまたぐ場合でも、ユーザーはログイン状態を維持できるようになります。トライアルへの登録はこちらから行ってください。
さらに、既存の迷惑なトラッキング技術を防ぎ、問題にならない回避策を提供するため、Chrome の変更も進めています。
今後数週間のうちに、新しい User-Agent Client Hints（UA-CH）API の Chrome 安定版ロールアウトを終える予定です。これは、デフォルトでユーザーのブラウザに関する情報をすべて取得するのではなく、デベロッパーが特定の情報をリクエストできるようにするものです。将来的に Chrome は従来の User-Agent 文字列で提供する情報を制限する予定なので、デベロッパーには UA-CH API への移行を始めることを推奨します。現在の User-Agent 情報は、フィンガープリンティングに使われる可能性があります。
先週、Gnatcatcher を導入しました。これは、ユーザーのグループが同じプライベート化サーバーを通してトラフィックを送信できるようにする提案で、サイトのホストから IP アドレスを効果的に隠蔽します。また、Gnatcatcher は、不正利用の防止などの正当な目的で IP アドレスへのアクセスが必要なサイトには、認証や監査を行った上で、アクセスを保証します。
昨年 10 月にお知らせしたように、ユーザーがキャッシュの仕組みを使ってアクセスしたサイトを別のサイトから確認できる機能は、近日中にクローズする予定です。これによって元のリクエストを行ったサイトのみがキャッシュされたリソースにアクセスできることが保証され、クロスサイト トラッキングや検索攻撃などのセキュリティ攻撃のリスクを減らすことができます。この変更は、3 月の Chrome 89 からすべての Chrome ユーザーにロールアウトされる予定です。
biddingFunctions
BidRequest
Floc
User
message Floc { // The value of a cohort ID – a string identifier that is common to a large // cohort of users with similar browsing habits. optional string id = 1; // The type of the FLoC. See // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/FLOC-Whitepaper-Google.pdf. enum FlocType { // Default value that should not be used. FLOC_TYPE_UNKNOWN = 0; // FLoC simulated using affinity hierarchical clustering with centroids // and feature extraction based on Topic categories as described in the // whitepaper. SIMULATED_AFFINITY_CLUSTERING_CENTROID_VERTICAL = 2; // FLoC simulated using SortingLSH clustering algorithm and Domain One-hot // encoding feature extraction as described in the whitepaper. SIMULATED_SIMHASH_SORTING_LSH_DOMAIN_ONE_HOT = 3; // FLoC simulated using a k Random Centers locality-sensitive hash // function as described in // https://github.com/google/ads-privacy/blob/master/proposals/FLoC/k-random-centers.md // with Domain TF-IDF feature extraction as described in the whitepaper. KCENTER_DOM_FILTERED_TFDIF = 4; } optional FlocType type = 2; }
google_user_id
hosted_match_data
FlocType
BidResponse
FrequencyCap
Bid
message FrequencyCap { // An ID that can represent a bidder's use-case for frequency capping; for // example, it could represent their campaign, ad, line item, etc. It should // not contain any user-specific information or identifiers. optional string fcap_id = 1; // The time units for which frequency caps can be enforced. enum TimeUnit { UNKNOWN_TIME_UNIT = 0; MINUTE = 1; DAY = 2; WEEK = 3; MONTH = 4; // When INDEFINITE is used, time_range will be ignored. INDEFINITE means // the frequency cap will be applied for a long period of time, (longer // than a month) but not necessarily forever. INDEFINITE = 5; } // The unit of time used to specify the time window for which a frequency // cap applies. optional TimeUnit time_unit = 2; // The length of the time window, in units specified by time_unit, for which // the frequency cap applies. For instance, if time_unit=WEEK and // time_range=3, then capping is applied for a three week period. If the // time_unit=INDEFINITE, this will be ignored. optional int32 time_range = 3 [default = 1]; // The maximum number of impressions allowed to be shown to a user for // the provided frequency_cap_id within the time window described by // time_unit and time_range. optional int32 max_imp = 4; }
すべての人は、安全で強力、そして高速なオープンウェブの恩恵を受けています。私たちはここ 1 年で、次にあげる 3 つの領域について、集中的にウェブの強化を行ってきました。
この投稿では、本日（元記事公開当時）の Chrome Dev Summit の基調講演で共有したアップデートの概要をまとめます。
私たちはプライバシー サンドボックスの作業を継続し、ウェブのプライバシーを抜本的に強化するオープンな基準を作ろうとしています。そして、ウェブ コミュニティと協力しつつ、サードパーティ Cookie やクロスサイト トラッキング メカニズムに代わり、プライバシーを守ることができる新たな仕組みを構築しようとしています。Client Hints API では Chrome でフィンガープリンティングに使える領域を減らし、Chrome オリジン トライアルを通して実験できる 2 つのソリューションも提供しています。Click Conversion Measurement API は、クロスサイト識別子を使わずに広告コンバージョンを測定します。Trust Token API は、パッシブなトラッキングを行うことなく、あるコンテキストから別のコンテキストに信頼を伝える際に役立ちます。
同様に、数億人のユーザーが利用する Chrome ウェブストアの 250,000 件以上の拡張機能でも、セキュリティとプライバシーが最重要になっています。私たちは、拡張機能はデフォルトで信頼できるものでなければならないと考えています。そのため、拡張機能プラットフォームにたくさんの変更を行うドラフト提案についてお知らせしました。拡張機能デベロッパーからのさまざまな提案を反映すれば、Manifest V3 の安定版リリースに向けた準備が整います。その目的は、セキュリティの強化、ユーザーの制御とプライバシーの向上、パフォーマンスの改善です。
Manifest V3 と合わせて、リモートでホストされたコードは許可されなくなります。これは、ユーザーのプライバシーやセキュリティを侵害する悪意のある拡張機能を防ぐためです。また、新しい拡張機能モデルでは、ユーザーがインストール時にセンシティブな情報へのアクセスを許可しないことを選択できるようになります。さらに、バックグラウンド ロジックに新たなアプローチを導入します。バックグラウンド ページに Service Worker を導入し、拡張機能 API に新たな宣言的モデルを適用することで、ユーザーに一貫したパフォーマンス保証を提供します。現在、Manifest V3 は Chrome 88 ベータ版で試験運用版として利用できます。Chrome ウェブストアは、Chrome 88 が安定版になる 1 月中旬から、Manifest V3 拡張機能を受け付ける予定です。
ウェブで新しい体験を構築しているデベロッパーから、すばらしい活用例が登場しています。Gravit Designer は、File System Access API を使ってユーザーが簡単にファイルの読み書きを行えるようにし、さらに新しい Local Font Access API でローカルにインストールした特別なフォントを利用できるようにしています。Adobe は、Spark ウェブアプリでユーザーがすばらしいビジュアル ストーリーや美しいデザインのコンテンツを簡単に作れるようにしています。
本日（元記事公開当時）、Progress Web App（PWA）に新機能を追加します。これによって、PWA を Google Play ストアに掲載して見つけてもらいやすくすることができます。Chrome 86 では、Trusted Web Activity を使っている PWA を Play ストアで一覧表示できるようになります。また、Chrome 88 では、新しい Digital Goods API を使って支払いを受け取れるようにしています。
デベロッパーの皆さんがすべてのユーザーに最適な体験を提供できるようにするため、Chrome のパフォーマンス（スピードのほか、電力、メモリ、CPU などのリソースの使用量）は常に私たちの最優先事項になっています。
今年は、プロファイルによる最適化とタブ スロットリングによって、スピードに関するいくつかの重要な改善を行いました。そして本日は、V8 のメモリ フットプリントを大幅に削減したことをお知らせします。V8 ポインタ圧縮でメモリの節約に向けた大きな一歩を踏み出したことに加え、ウェブページの JavaScript ファイルを並列に読み込むことで解析による中断を完全に無くしました。これによって、ページで必要になるときには既にスクリプトの実行準備が整っているように、スクリプトの解析とコンパイルを実行できます。
Web Vitals の取り組みについて発表して以来、ウェブページのパフォーマンスを測定する際にこの基準が使われることが多くなっています。Google 検索は、2021 年 5 月より、検索ランキングの新たなシグナルに Core Web Vitals を含めることを発表しました。Chrome ユーザー エクスペリエンス レポートに加え、Search Console の Core Web Vitals レポートやその他多くの Google 製ツール、Cloudflare などの他のプロバイダで、Core Web Vitals がウェブページのパフォーマンス指標として表示されています。
この夏、Google アナリティクスを使っているサイト向けに、web-vitals Javascript ライブラリをリリースしました。本日、オープンソースのウェブサイトおよびツールである Web Vitals Report についてお知らせしました。これを使うと、Google アナリティクスで Web Vitals 指標データのクエリや視覚化ができるので、セグメント間で簡単にパフォーマンス データを比較することもできます。
最後になりますが、皆さんのフィードバックや、ウェブ インターフェースの構築が難しい点についてのご意見をお待ちしています。私たちは、ウェブのスタイリング機能の改善を進めており、レンダリング パフォーマンスを大幅に向上させる content-visibility CSS 機能を公開しました。簡単に CSS を拡張できる API セットである Houdini.how のお知らせなど、UI スタイリングを改善するアップデートやツールにご期待ください。
Chrome Dev Summit は、常にコミュニティとのつながりを大切にしています。今回は直接顔を合わせることはできませんでしたが、Chrome チームは、偶然の会話や新しい発見、記念品の収集など、実際のカンファレンスのいい所を集めた PWA、Chrome Dev Summit Adventure をリリースしました。この実験について皆さんからの感想を聞いたり、リアルタイムでチャットしたりするのが楽しみです。
コミュニティの一員になり、世界中の Google Developer Group に参加しましょう。CDS Extended イベントでは、地域のデベロッパー コミュニティを集めて、Chrome Dev Summit 2020 のハイライトを確認したり、インタラクティブなセッションがライブで行われたりします。このイベントのすべてのリストをチェックしてください。
YouTube チャンネルでは、いつでもセッションを視聴できます。また、web.dev ニュースレターにサインアップしてウェブの最新アップデートを受け取ってください。
また来年にお会いしましょう！
※ 日本では Chrome Dev Summit の日本版となる Chrome Dev Summit Recap 2020 を開催しました。アーカイブは 2021 年 1 月中旬まで閲覧可能ですので、ぜひ今からでも登録・ご視聴下さい。
この記事は、SameSite Cookie 属性変更シリーズの一部です。
SameSite
スキームフル Same-Site は、「サイト」の定義を、「登録可能ドメイン」のみから、「スキーム＋登録可能ドメイン」に変えるものです。詳細や例は、「同一サイト」と「同一オリジン」を理解するをご覧ください。
重要な用語: つまり、http://website.example のような安全でない HTTP バージョンのサイトと、https://website.example のような安全な HTTPS バージョンのサイトが、お互いにクロスサイトと見なされるということです。
うれしいのは、すべてのウェブサイトを既に HTTPS にアップグレードしている場合、何も心配することはない点です。その場合、何も変わることはありません。
まだウェブサイトを完全に HTTPS にアップグレードしていない場合は、この作業の優先度を上げる必要があります。ただし、サイトにアクセスするユーザーが HTTP と HTTPS を行き来している場合は、一般的なシナリオとその SameSite Cookie の動作について、以下をお読みください。
警告: 長期的に計画されているのは、サードパーティ Cookie のサポートを完全に廃止し、プライバシーを保護できる手法に置き換えることです。Cookie に SameSite=None; Secure を設定してスキームをまたいで送信できるようにする方法は、完全な HTTPS への移行に向けた一時的なソリューションとしてのみ検討してください。
SameSite=None; Secure
以下の変更を有効化すると、Chrome と Firefox でテストできます。
chrome://flags/#schemeful-same-site
about:config
network.cookie.sameSite.schemeful
true
Cookie のデフォルトを SameSite=Lax に変更した主な理由の 1 つに、クロスサイト リクエスト フォージェリ（CSRF）に対する保護がありました。しかし、安全でない HTTP トラフィックが存在する場合、ネットワーク攻撃者が Cookie を改ざんし、それを使って安全な HTTPS バージョンのサイトに侵入するチャンスが残ることになります。スキーム間にクロスサイト境界を追加することで、このような攻撃に対する保護を強化できます。
SameSite=Lax
重要な用語: 以下の例では、すべての URL で site.example などの同じ登録可能ドメインを使用していますが、http://site.example と https://site.example のようにスキームが異なっています。これを、お互いにクロススキームであるといいます。
これまで、クロススキームなウェブサイト間のナビゲーション（たとえば、http://site.example から https://site.example へのリンク）では、SameSite=Strict Cookie の送信が許可されていました。今後、これはクロスサイト ナビゲーションとして扱われます。つまり、SameSite=Strict Cookie はブロックされます。
SameSite=Strict
SameSite=None;Secure
警告: すべての主要ブラウザは、スクリプトや iframe などのアクティブな Mixed Contents をブロックします。さらに、Chrome や Firefox などのブラウザでは、パッシブな Mixed Contents のアップグレードやブロックに向けた作業が進んでいます。
ここで行う変更は、完全な HTTPS へのアップグレードを進める間の一時的な修正としてのみ検討してください。
サブリソースの例として、イメージ、iframe、XHR や Fetch によるネットワーク リクエストなどがあげられます。
これまで、ページでクロススキーム サブリソースを読み込んだ場合、SameSite=Strict または SameSite=Lax の Cookie の送信や設定が許可されていました。今後、これは他のサードパーティまたはクロスサイトのサブリソースと同じように扱われます。つまり、SameSite=Strict や SameSite=Lax の Cookie はすべてブロックされます。
加えて、ブラウザが安全なページで安全でないスキームからのリソースの読み込みを許可したとしても、サードパーティまたはクロスサイト Cookie には Secure が必須なので、リクエストの Cookie はすべてブロックされます。
Secure
これまでは、クロススキーム バージョンのウェブサイト間で POST を行った場合、SameSite=Lax または SameSite=Strict が設定された Cookie の送信は許可されていました。今後、これはクロスサイト POST として扱われ、SameSite=None Cookie のみ送信できるようになります。このシナリオは、デフォルトで安全でないバージョンを表示し、ログインまたはチェックアウト用のフォームを送信する際にユーザーを安全なバージョンにアップグレードするサイトで使われている可能性があります。
SameSite=None
サブリソースと同じく、リクエストが安全な HTTPS などのコンテキストから安全でない HTTP などのコンテキストに向かう場合、サードパーティまたはクロスサイトの Cookie には Secure が必要になるので、リクエストの Cookie はすべてブロックされます。
警告: ここでの最適なソリューションは、フォームのページと送信先ページの両方で HTTPS などの安全な接続を使うことです。この点は、ユーザーがフォームに機密性の高い情報を入力する場合に特に重要になります。
Chrome と Firefox では、デベロッパー ツールやメッセージを利用できます。
Chrome 86 以降では、DevTools の [Issue] タブにスキームフル Same-Site の問題が表示されます。サイトで以下の問題が表示される可能性があります。
ナビゲーションに関する問題:
サブリソースの読み込みに関する問題:
詳しい内容は、スキームフル Same-Site のテストとデバッグに関するヒントにも掲載されています。
Firefox 79 以降で about:config から network.cookie.sameSite.schemeful を true に設定すると、スキームフル Same-Site の問題に関するメッセージがコンソールに表示されます。サイトで以下の内容が表示される可能性があります。
cookie_name
http://site.example/
一部のリンクやサブリソースが安全でない URL を指している可能性があります。
この問題を修正する方法の 1 つは、HTTP Strict-Transport-Security（HSTS）と includeSubDomain ディレクティブを使うことです。HSTS と includeSubDomain を使うと、ページに安全でないリンクが意図せずに含まれる場合でも、ブラウザが自動的に安全なバージョンを使ってくれます。
includeSubDomain
サイトを完全に HTTPS にアップグレードしてユーザーを保護することを強くおすすめしますが、ご自身でアップグレードできない場合は、ホスティング プロバイダに相談してアップグレードのオプションを提供できるかを確認してください。セルフホストの場合は、Let's Encrypt が証明書をインストールして設定するためのさまざまなツールを提供しています。また、HTTPS 接続を提供できる CDN やその他のプロキシを経由してサイトにアクセスするように移行することも検討できます。
それでも難しい場合は、影響を受ける Cookie の SameSite 保護の緩和を試します。
Lax
Strict
None
SameSite 属性のない Cookie は、SameSite=Lax を指定した場合と同じように扱われ、それと同じクロススキーム動作が適用されます。なお、安全でない手法も一時的に例外として許可されています。詳しくは、SameSite FAQ の Chromium における Lax＋POST 対処法をご覧ください。
ページと同じ安全性が確保されている場合、WebSocket 接続は今後も同一サイトと見なされます。
同一サイト:
https://
wss://
http://
ws://
クロスサイト:
