プライバシー サンドボックスの提案のライフサイクル

プライバシー サンドボックスの提案は、ウェブ プラットフォームの機能を作成するために必要な数多くのステップのうちの最初のステップです。

これらのウェブ プラットフォーム機能は、ウェブ標準（仕様）になる可能性があります。ウェブ標準とは、ウェブ テクノロジーがどのように機能すべきかについて正確に詳述し、エンジニアがウェブブラウザでテクノロジーを実装する方法を定義する技術ドキュメントです。たとえば、Accessible Rich Internet Applications（WAI-ARIA）標準（通常、「ARIA」と呼ばれる）は、障がいのあるユーザーがウェブを利用しやすくなる技術的な方法を定義しています。この仕様は、World Wide Web Consortium（W3C）というフルタイム スタッフ、会員組織、一般ユーザーのフィードバックからなる国際的なコミュニティによって定められています。

ディスカッション、テスト、大規模な導入の後、一部のプライバシー サンドボックスの提案と API が仕様になります。デベロッパーや業界リーダー（ウェブ テクノロジーに関する知識の有無は問わず）からフィードバックを受け取ることで、ユーザーのために幅広い有用性と堅牢なプライバシー保護機能を備えた耐久性のあるウェブ機能を作成できるようにすることが重要です。

機能は、開発とテストのタイムラインを経て一般提供に至ります。
図 1: 機能は、開発とテストのタイムラインを経て、一般提供に至ります。インテントはハード バウンダリであり、特定のアクションを実行する前に必要です。たとえば、テストは、試験の意向が投稿され、承認されるまで開始できません。詳しくは、要件をご覧ください。

Chromium（多数の最新ブラウザのベースとなっているオープンソース プロジェクト）には、ウェブ標準になることを目標とするすべてのテクノロジーの機能開発プロセスについての記述があります。ウェブのプライバシーとセキュリティは極めて重要であるため、Google ではテスト開始までに多くのディスカッションを行い、多くのフィードバックを受け取ることをおすすめしています。

提案からウェブ標準になるまで

開発のあらゆる段階で、エコシステムから重要なフィードバックが寄せられ、プライバシー サンドボックスの形が作られていきます。このプロセスはウェブ デベロッパーにはなじみがあるかもしれませんが、このような専用 API を使用する他の業界関係者にとってはなじみがない可能性があります。しかし、そのような人々の意見はこの取り組みにおいて不可欠です。

ディスカッションから始める

プロトタイプを作成するインテントによって会話が開始されます。
図 2: プロトタイプを作成する目的によって会話が開始される。

この数年間、Chrome などからプライバシー保護に関する提案が多数提供されてきました。これらの提案を読んで質問し、アイデアを提供することで、提案を改善したり他者の意見を確認したりすることができます。

関心のあるユースケースに応じて、参加またはモニタリングできる W3C グループがいくつかあります。

ディスカッションの段階は、非常に複雑になる場合があります。

たとえば、Protected Audience（旧称 FLEDGE）は、クロスサイト トラッキングを行わずにインタレスト ベース広告をサポートするための提案です。Protected Audience API は、プライバシー アドボケイトや多くの業界関係者の意見を参考に、以前の 2 つの提案（PIGIN と TURTLEDOVE）から進化しました。100 以上の組織が W3C の会議に参加して現行バージョンの改善を支援し、オンライン ディスカッション スレッドも 300 を超えました。

また、同じソリューション分野で他社から 6 つ以上の提案が提供されました。Google では、継続的なコラボレーションを通して、今後の道筋を決めたいと考えています。

Protected Audience やその他の API のテストは Chrome フラグのベースとなっているため、デベロッパーは早期にアクセスできます。

すべての提案が Protected Audience ほどの大変な検討期間を経るわけではありませんが（中にはもっと迅速に移行できるものもあるでしょう）、各 API はエコシステム全体から意見を取り入れています。これらは新しいアイデアであり、きちんと理解するには多くの労力を要する場合があります。

デベロッパーによるテストとフィードバックの共有

Intent to Experiments は、機能テストとスケーリング テストを目的としています。
図 3: Intent to Experiments は機能テストとスケール テストを目的としています。

Google は、デベロッパーからのこれらのテクノロジーの改善に関するフィードバックと、API の設計と実装の変更が必要になる可能性のある問題の共有に依存しています。プライバシー サンドボックスのテクノロジーの多くは、さまざまなオプションでテストできます。たとえば、Topics API をテストするには、Chrome フラグを使用してエポック長などのパラメータを設定できます。

多くの場合、Chrome エンジニアは、ブラウザ全体でデフォルトで利用可能にすることなく、ローカル テストを可能にするために、フラグの背後にある機能を実装します。デベロッパーは、機能を有効にして試す必要があります。利用できるかどうかは Chrome のバージョンによって異なります。開発を続けるうちに、いくつかの問題が発生することが予想されます。

Chrome オリジン トライアルでは、デベロッパーは Chrome ユーザーの限定されたグループに対して機能を有効にできます。参加するには、デベロッパーが登録してサイトまたはサービスをオプトインします。これにより、本番環境のトラフィックで機能を試して、実際の使用感に関するフィードバックを提供できます。

プライバシー サンドボックスでは、関連性と測定に関する API の統合オリジン トライアルを実施していましたが、このトライアルは完了しました。

機能が最初にテスト用に提供されるときの主な目的は、機能テストまたは技術テストを行うことです。新しいコードでは、投稿者がバグを発見して報告し、そのバグの修正を提供することが期待されています。この期間中、機能の安定性と形状は頻繁に変わる可能性があります。統合とデベロッパー エクスペリエンスに関するフィードバックを受け取ることは、デバッグとツールサポートを機能と並行して作成できるようにするために重要です。

開発が進み、機能の安定性が改善されると、主な目的は有効性または有用性の広範なテストに移行します。ユーティリティ テストの目的は、想定したユースケースでの機能のパフォーマンスを大規模に検証することです。この段階では、より大きく、より代表的なサンプルを取得するために、テストに含まれる Chrome ユーザーの母集団が増加します。このフェーズでは、サイトが自社のトラフィックの大部分で長期的なテストを実施し、ビジネスニーズに照らして機能を検証することを期待しています。

このプロセスを成功させるには、デベロッパーがこれらのテストを実施し、学んだことを共有する必要があります。また、各フェーズで同時にテストを実施し、API ステータスの更新と四半期ごとのフィードバック レポートでプロジェクト全体の定期的な概要を共有し、CMA とのコミットメントの一環として、さまざまな個々のプロジェクト チャネルを通じて結果を共有しています。

W3C などの公開の場やフィードバック フォーム、直接のパートナーシップ チャネルを通じてテスト結果を共有するかどうかに関わらず、皆様からのご意見をお待ちしております。

ブラウザでのテスト（機能フラグまたはオリジン トライアル）は、新しいテクノロジーがどのように機能するかを確認する方法の 1 つにすぎません。一部の企業も、プライバシー サンドボックスのコンセプトに基づいてシミュレーションを構築しています。

大規模な導入のリリース

出荷の意向は、API をスケーリングされた導入に利用できるようにするリクエストを示します。
図 4: Intent to Ship は、API をスケーラブルな導入に利用できるようにするリクエストを示します。

API をテストして、Chrome での一般利用の準備ができたら、リリースを発表し、エコシステムの大規模な導入に備えて一般公開ドキュメントを作成します。

すでに多くの重要なマイルストーンを達成しており、今後もさらに多くのマイルストーンを達成する予定です。次のテクノロジーが利用可能になりました。

  • ユーザー エージェントの情報量削減: パッシブに共有されるブラウザデータを制限して、フィンガープリントにつながる機密情報の量を減らします。これらの値の削減は 2022 年 5 月に開始され、2023 年 5 月に完了する予定です。
  • CHIPS: デベロッパーは、トップレベル サイト別のストレージに「パーティション化して」保存される Cookie にオプトインできます。CHIPS は 2023 年 2 月に安定版で利用可能になりました。
  • ファーストパーティ セット: サイト間の関係を宣言して、Storage Access API を使用したクロスサイト Cookie への制限付きアクセスを許可します。ファーストパーティ セットは、今週の Chrome Stable バージョン 113 で徐々にロールアウトされています。
  • Federated Credential Management（FedCM）: ユーザーが明示的に同意しない限り、ユーザーのメールアドレスやその他の識別情報をサードパーティのサービスやウェブサイトと共有することなく、ID 連携をサポートします。FedCM は 2022 年 11 月にリリースされました。

2023 年 7 月に、関連性および測定の API が大規模な導入向けに利用可能になりました。つまり、これらの API は Chrome でデフォルトで使用できるようになりました。デベロッパーは、ブラウザ フラグやオリジン トライアルへの参加なしでこれらのテクノロジーを使用できるようになりました。

つまり、これらの API は、本番環境で大規模に 99% のユーザーに対応できます。

段階的なリリース

一部のテクノロジーは段階的に提供されます。これにより、チームとデベロッパーは潜在的な問題をモニタリングして対処できます。また、完全な可用性とは、トラフィックの 100% で API が有効になっていることを意味するわけではありません。

たとえば、Chrome での User-Agent Client Hints（UA-CH）の段階的なリリースは 2021 年に開始されました。ユーザー エージェントの削減は 2022 年 4 月に開始され、2023 年 3 月に完了しました。これにより、デベロッパーはサイトが User-Agent 文字列に依存する方法を移行するのに十分な時間を確保できました。

API の制御

関連性 API や測定 API などの一部の API には、ユーザー向けの構成オプションがあります。これには、これらの API を有効または無効にする機能が含まれます。

適切な機能検出を構築することが重要です。機能検出は、ブラウザが特定のコードをサポートしているかどうかを判断し、代替コードを提供できるようにするのに役立ちます。これにより、ユーザーが API をオフにしている場合や、ユーザーが特定のテクノロジーをサポートしていないブラウザを使用している場合でも、サイトが想定どおりに動作し続けることを確認できます。

権限ポリシーを使用して、ブラウザ機能へのファーストパーティとサードパーティのアクセスを制御することを検討してください。

フィードバックをお寄せください

Google は引き続き、最新の状況についてご説明し、今後の予定をできるだけお伝えして、デベロッパーの皆様に積極的に参加いただいてご意見をお聞きしたいと考えています。