Chrome チームが CHIPS の実装で直面した 2 つの課題と、提案の設計開発におけるコミュニティからのフィードバックの主な役割について説明しています。
Cookies Having Independent Partitioned State（CHIPS）は、プライバシー サンドボックスの技術で、デベロッパーは、トップレベル サイト別のストレージに「パーティション化して」保存される Cookie にオプトインできます。
CHIPS のユースケースの例には、以下のような、クロスサイトのサブリソースで 1 つのトップレベル サイトのユーザー アクティビティをスコープとするセッション概念または永続状態が必要となるあらゆるシナリオが含まれます。サードパーティのチャット ウィジェット、地図の埋め込み、サブリソース 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 ジャーを共有しにくくなります。また、埋め込みコンテキストでの認証フローが困難になる場合もありました。
Chrome チームはこのフィードバックを評価し、ドメインなしの要件を削除してもプライバシーの問題は発生せず、ユーザビリティが向上すると結論付けました。これを受けて、CHIPS プロダクト チームは GitHub でディスカッションを開き、この要件の削除についてさらにフィードバックを募集しました。CHIPS をテストしていた複数の企業が、この変更が自社のユースケースにとって重要であるというコメントを公開しています。
Chrome は、W3C のプライバシー コミュニティ グループにフィードバックを送信し、更新された提案書を提示しました。Firefox と Edge は変更を承認し、Safari は懸念を表明しませんでした。翌日、Chrome チームは Blink-Dev を更新し、CHIPS GitHub リポジトリで要件を削除する計画を発表しました。
CHIPS チームは、サイトが悪意のあるサブドメインや侵害されたサブドメインからクロスサイト Cookie を受信しないようにし、ドメイン Cookie をサブドメイン間でデータを漏洩させるチャネルとして使用される可能性を軽減するために、この要件を最初に提案しました。
これによりセキュリティ上のメリットが追加されましたが、現在のアプリケーション アーキテクチャの一部はサブドメイン間での Cookie の共有に依存しているため、CHIPS の導入に課題があることを Tableau は強調しています。
Chrome でこの変更が行われた後、現在 Salesforce が所有するビジュアリゼーション アナリティクス プラットフォームの背後にある会社である Tableau は、次のように共有しました。
名前の変更を削除することで、この要件は、以前の変更（SameSite=None 属性の追加）とより整合性が高まり、より「既知」の量になります。皆様からいただいたフィードバックを参考に、影響を確認したうえで、移行を円滑に進めるための変更を加えました。 Lee Graber、Tableau ソフトウェア エンジニアリング アーキテクト
このプロセスにより、ユーザーのプライバシーを保護しながら、関係者が CHIPS を簡単に実装できるようになりました。
静的 Cookie 制限から動的 Cookie 制限への移行
CHIPS の実装におけるもう 1 つの課題は、静的 Cookie の上限でした。
Cookie のメモリ フットプリントが大きくならないように、最初の設計では、サイトごとのパーティションごとに 10 個の Cookie という数値の上限を提案しました。
Akamai は、パーティショニング クッキーに提案されている上限が、顧客のコンテンツをホストするトップレベル ドメイン（customer.cdn.xyz など）を提供する CDN などのサービスでは不十分である可能性があるという公開フィードバックを共有しました。たとえば、customer1.cdn.xyz と customer2.cdn.xyz の両方がサードパーティ コンテンツを配信し、それぞれ独自の Cookie を複数設定できます。このような複数のお客様のサイトが別のウェブサイトに埋め込まれている場合、パーティションあたり 10 個の Cookie という上限に達する可能性があります。
Chrome チームは、他のフォーラム、パートナー ミーティング、W3C のディスカッションでも同様のフィードバックを受けました。そこで、これらのユースケースで生じる Cookie 数の上限に関する課題を解決するための最善の方法を検討しました。
コミュニティからのフィードバックをどのように取り入れるかを検討した結果、Chrome は TPAC 2022 で更新されたアイデアを提示しました。これは、CHIPS の Cookie 数の上限を 10 個（静的）から、メモリに基づく 10 kb（動的）に変更することを提案するものです。分析の結果、この変更はウェブ上のユースケースの 99% をカバーし、Chrome が目指すプライバシー原則（サイト間でユーザーに関する過剰な情報の共有を制限）を維持しながら、重要なユースケースを維持できることが示されました。
他のブラウザ ベンダーも意見を述べ、更新されたソリューションに同意すると述べました。これは、CHIPS が PrivacyCG でクロスブラウザ サポートを維持するために重要でした。
その結果、Chrome は新しい上限を採用し、そのソリューションを CHIPS の設計に組み込みました。
業界との連携
CHIPS の開発中は、多くのパートナーからご意見をいただきました。ウェブ上のプライバシーを改善するための取り組みにおいて、パートナーとの連携は不可欠でした。
Akamai は、Google などの業界リーダーと複数の分野で協力関係を築いています。CHIPS プログラムについて Google から提供したフィードバックは、細かい点のように思えるかもしれませんが、この変更により、最終的な目標を達成しながら、適切なユースケースへの悪影響を最小限に抑えることができます。各組織は独自の方法でインターネットの高速化と安全性の向上に取り組んでいます。各組織が連携することで、インターネット全体がより安全になります。 Akamai Technologies のシニア アーキテクト、Martin Meyer 氏
CHIPS では、エコシステムからのフィードバックがプライバシー サンドボックスの技術の改善に不可欠であることが示されています。GitHub でのオープンなウェブ会話、W3C ミーティング、Chrome チームとの継続的なエンゲージメントが、Chrome 安定版にロールアウトされた変更に直接貢献しました。Chrome チームは、さまざまな提案について、皆様からのフィードバックを心よりお待ちしております。フィードバックは、ウェブ上での技術の開発と展開に大きな影響を与えます。