Chrome チームが CHIPS を実装する際に直面した 2 つの課題と、提案の設計を進化させるうえでコミュニティからのフィードバックがどのように重要な役割を果たしたかについてご紹介します。
Cookies Have Independent Partitioned State（CHIPS）は、デベロッパーがトップレベル サイトごとに別個の Cookie ジャーを使用する「パーティション分割」ストレージに Cookie をオプトインできるプライバシー サンドボックス技術です。
CHIPS のユースケースの例には、サードパーティ チャット ウィジェット、地図の埋め込み、サブリソース CDN ロード バランシング、ヘッドレス CMS プロバイダなど、単一のトップレベル サイトでのユーザー アクティビティに限定されたセッションまたは永続的な状態をクロスサイトのサブリソースが必要とするシナリオが含まれます。
CHIPS はオープンウェブ標準になることを目標に開発中です。これは PrivacyCG で検討中であり、7 か月間のオリジン トライアルを実施し、Chrome チームは有益なフィードバックを得ています。開発チームは開発中に主要な関係者と協力してそのフィードバックを検討し、ウェブ エコシステムにより良いサービスを提供するデザインにしました。
Chrome チームが CHIPS を実装する際に直面した 2 つの課題と、提案の設計を進化させるうえでコミュニティからのフィードバックがどのように重要な役割を果たしたかについて見ていきましょう。
ホスト プレフィックスを削除し、Domain 要件が不要になりました
適切なセキュリティ対策を促進するために、CHIPS の設計では、Cookie は安全なプロトコルによってのみ設定および送信され、パーティション化された Cookie は Secure で設定する必要があります。
これらの要件に加えて、最初の提案ではパーティション化された Cookie の Domain 属性を禁止していました。Cookie の Domain を省略すると、パーティション内の異なるサードパーティ サブドメイン間で Cookie が共有されなくなります。
オリジン トライアル中、Chrome チームはパートナーや他の関係者から、ドメインがないという要件によってサブドメインを持つサイトで CHIPS を実装するのが難しいと聞きました。たとえば、shop.example.com と pay.example.com がパーティション分割された Cookie jar を共有しにくくなります。他のケースでは、埋め込みコンテキストでの認証フローが難しくなっていました。
Chrome チームはこのフィードバックを評価し、ドメインなしの要件を廃止してもプライバシーに関する課題は生じないものの、ユーザビリティが向上すると判断しました。これを受け、CHIPS プロダクト チームは GitHub でディスカッションを開始し、この要件の削除についてより多くのフィードバックを求めました。CHIPS をテストしていた数社から、自社のユースケースにおけるこの変更の重要性について回答があり、コメントが公開されました。
Chrome は W3C のプライバシー コミュニティ グループにフィードバックを受け取り、更新された提案を提示しました。Firefox と Edge はこの変更を承認し、Safari は懸念を提起しませんでした。翌日、Chrome チームは Blink-Dev を更新し、この要件を CHIPS GitHub リポジトリで廃止する計画を発表しました。
CHIPS チームは当初、サイトが悪意のあるサブドメインや侵害されたサブドメインからクロスサイト Cookie を受信しないことを保証し、サブドメイン間でデータを漏洩するチャネルとしてドメイン Cookie を使用する可能性を軽減するために、この要件を提案しました。
これにより、さらなるセキュリティ上のメリットがもたらされましたが、Tableau は、現在のアプリケーション アーキテクチャの一部がサブドメイン間での Cookie の共有に依存しているため、CHIPS の採用に課題があることを強調しました。
Chrome でこの変更を行った後、ビジュアル分析プラットフォーム（現在は Salesforce が所有する）を支えている同社の Tableau は、次のことを共有しました。
今回の名称変更により、「SameSite=None」属性を追加して「既知の」数量を増やすという以前の変更と合わせ、要件がより明確になります。お寄せいただいたフィードバックに耳を傾け、その影響について検討し、移行を容易にするための変更を行うことに心より感謝いたします。 Tableau、ソフトウェア エンジニアリング アーキテクト Lee Graber 氏
このプロセスを通じて、ユーザーのプライバシーを保護しながら、関係者による CHIPS の実装が容易になりました。
Cookie の静的制限から動的制限への移行
CHIPS の実装におけるもう一つの課題は、静的な Cookie の制限でした。
最初の設計では、Cookie のメモリ使用量が多くなるのを防ぐため、1 サイト、1 パーティション、10 個の Cookie という数値上限を提案しました。
Akamai が公開したフィードバックによると、顧客のコンテンツをホストするトップレベル ドメインを提供する CDN のようなサービス（customer.cdn.xyz など）では、パーティション化された Cookie の上限は提案されているだけでは不十分である可能性があります。たとえば、customer1.cdn.xyz と customer2.cdn.xyz は、どちらもサードパーティのコンテンツを配信でき、それぞれが独自の Cookie を複数設定できます。このような複数のお客様のサイトが別のウェブサイトに埋め込まれている場合、パーティションあたりの Cookie 数の上限（10 個）に達する可能性があります。
Chrome チームは、他のフォーラム、パートナーとのミーティング、W3C のディスカッションで同様のフィードバックをいただいたため、Cookie の制限がこれらのユースケースで生じる課題を解決する最善の方法を検討しました。
コミュニティからのフィードバックを取り入れる方法を検討した結果、Chrome は TPAC 2022 で最新のアイデアを発表しました。このアイデアでは、CHIPS の Cookie を静的な 10 Cookie の制限から、メモリに応じて _dynamic _10 KB の制限に移行することを提案しました。分析によると、この変更はウェブのユースケースの 99% をカバーするものであり、主要な用途を維持しながら、Chrome が達成しようとしていたプライバシー原則（サイト間で共有されるユーザー情報が多すぎることを制限する）を維持できることが示されました。
他のブラウザ ベンダーも、更新されたソリューションに賛同していると回答しています。このソリューションは、CHIPS が PrivacyCG でクロスブラウザ サポートを維持するために重要でした。
その結果、Chrome は新しい上限を採用し、そのソリューションを CHIPS 設計に組み込みました。
業界との連携
CHIPS の開発を通じて多くのパートナーからご意見をいただきましたが、ウェブにおけるプライバシーを向上させる取り組みには、各社との連携が不可欠です。
Akamai は、Google をはじめとする業界の他のリーダーと、さまざまな面で協力関係にあります。CHIPS プログラムに関して提供したフィードバックは、些細な内容に思えるかもしれませんが、この変更は、最終目標を達成しながら、優れたユースケースへの悪影響を最小限に抑えるために大いに役立ちます。Google と Google の各組織は、それぞれ独自のやり方でインターネットの高速化と安全性の向上に取り組んでおり、互いに協力することでインターネット全体がより良いものになると考えています。 Akamai Technologies、シニア アーキテクト、Martin Meyer 氏
CHIPS は、エコシステムからのフィードバックがプライバシー サンドボックスのテクノロジーの向上に不可欠であることを明らかにしました。GitHub でのウェブでのオープンな会話、W3C の会議、Chrome チームとの継続的な取り組みが直接貢献したものであり、現在 Chrome Stable でリリースされました。Chrome チームでは、さまざまな提案を通じてフィードバックをお待ちしています。こうしたフィードバックは、ウェブでのテクノロジーの開発方法や展開方法に大きな違いをもたらすものです。