ストレージアクセスポリシー: 追跡者からのクッキーのブロック

Firefox には、サードパーティの追跡リソース（tracking resources、トラッキングリソース）からのクッキーやその他のサイトデータをブロックする新しいストレージアクセスポリシーが含まれています。 このポリシーは、Firefox で長年にわたって利用されてきた古いクッキーポリシーの代替として設計されています。 このポリシーは、従来のクッキーブロックに関連するサイトの中断を最小限に抑えながら、クロスサイトトラッキング（cross-site tracking、サイトをまたがった追跡）から保護します。 この記事では、ポリシーの仕組みとテスト方法について説明します。

このクッキーポリシーは、バージョン 63 以降の Firefox で使用可能です。 この文書では、Firefox Release ユーザーに出荷する予定のポリシーについて説明しますが、Firefox の現在の Release バージョンで実装されているものと一致しない場合があります。 これは、プレリリースチャネルである Firefox Nightly にポリシーが追加されるとすぐに、ポリシーの新しい側面を文書化するためです。 Firefox Nightly には、Release ユーザーへの出荷を予定していない実験的な機能も含まれている場合があります。 この文書には実験的な機能は含まれていませんが、追跡者（trackers、トラッカー）として分類されたドメインの機能に影響を与える可能性があります。

これには最新バージョンの保護が含まれているため、Firefox Nightly でサイトをテストすることをお勧めします。 前述のように、Nightly には、Release ユーザーに到達する前に削除または変更される追加の保護が含まれることがあります。 保護を強化するため、このページは常に最新情報で更新されます。

Nightly では、これらの保護はデフォルトで有効になっています。 クッキーポリシーは、コンテンツブロッキング設定を介して Firefox の他のバージョンで有効にできます（これらの手順はバージョンによって異なります。 リンクされた文書には、適切な Firefox バージョンを選択するためのドロップダウンが含まれています）。

この変更の結果としてウェブサイトが中断する場合は、Bugzilla の Firefox 製品内の Tracking Protection コンポーネントでバグを報告してください。 または、コントロールセンターのコンテンツブロッキングセクションで「問題の報告」をクリックして、Firefox で中断するサイトを直接報告できます（このショートカットは、Firefox のすべてのバージョンで利用できるとは限りません）。

Firefox はどのリソースが追跡リソースかをどのように判断していますか？

Firefox はトラッキング防止リストを使用して、どのリソースが追跡リソースかを判断します。 トラッキング防止リストは、Disconnect によって維持されます。 リストが Firefox に適用されると、次の2つの重要な変更が行われます。

• 最初に、リストの「基本的な保護」バージョンのみを使用します。 これは、追跡者の一部のカテゴリを除外します。 将来的には、リストの「厳格な保護」バージョンを使用するように保護を拡張する可能性があります。
• 2番目に、Firefox は追加の「エンティティリスト」を使用します。 これにより、ドメインが同じ組織が所有する最上位サイトに読み込まれたときにそのドメインが追跡者として分類されなくなります。

Firefox は、組み込みのトラッキング防止 URL 分類子を使用して、トラッキング防止リストに一致するリソースを判別します。 ドメインは、SafeBrowsing v4 仕様に従ってリストと照合されます。 具体的には、リストに対してリソースの正確なホスト名を確認し、最後の5つのコンポーネントから開始して先頭のコンポーネントを次々に取り除くことによって形成された最後の4つのホスト名も同様に確認します。 次の例を検討してください。

ストレージアクセスポリシーは、追跡者として識別されたリソースがサードパーティのコンテキストに読み込まれたときに、それらのクッキーや他のサイトストレージにアクセスすることをブロックします。 これにより、それらのリソースがクッキーまたはサイトストレージに保存されている追跡識別子を取得し、それらを使用して複数のファーストパーティにわたって訪問したユーザーを識別することができなくなります。 具体的には、Firefox は次の制限を課してこれを行います。

クッキー:

• Cookie リクエストヘッダーをブロックし、Set-Cookie レスポンスヘッダーを無視します。
• Document.cookie の呼び出しに対して空の文字列を返し、Document.cookie を介してクッキーを設定する要求を無視します。

DOM ストレージ:

• localStorage: Window.localStorage: 読み取りおよび書き込みの試みは SecurityError 例外をスローします。 Firefox 70より前: Window.localStorage は null です。 したがって、このオブジェクトを使用して読み書きしようとすると、TypeError 例外がスローされます。
• sessionStorage: 読み取りおよび書き込みの試みが許されます。
• IndexedDB: IndexedDB Factory オブジェクトへのアクセスの試みは SecurityError 例外をスローします。

メッセージングとワーカー:

• Broadcast Channel: 新しい BroadcastChannel 作成の試みは SecurityError 例外をスローします。
• Shared Worker: 新しい SharedWorker 作成の試みは SecurityError 例外をスローします。
• Service Worker: 新しい ServiceWorker 作成の試みは SecurityError 例外をスローします。

DOM キャッシュ:

• CacheStorage の呼び出しは、常に SecurityError で拒否されます。

ブラウザーキャッシュ:

• HTTP キャッシュ、画像キャッシュ、および代替サービス（Alt-Svc）キャッシュは、追跡リソースに対してすべてパーティション化されているため、各最上位オリジンには個別のパーティションがあり、異なる最上位オリジンの追跡リソースは互いに別々にキャッシュされます。

ネットワーク接続:

• 追跡者として分類されている埋め込みのサードパーティリソースへの HTTPS 接続が行われた場合、セッションチケットを使用して TLS セッションは再開されません。
• 追跡者として分類されたドメインによる HTTP 接続の再利用は、同じ最上位オリジンで発生する要求に制限されます。 例えば、news.example の tracker.example からのコンテンツの要求は、shopping.example の tracker.example からのコンテンツの要求や、tracker.example に直接訪問したときに（つまり、 ファーストパーティとして）発生する要求との HTTP 接続を再利用しません。

HTTP リファラー:

• 追跡者として分類されたサードパーティリソースのデフォルトの Referrer Policy は、strict-origin-when-cross-origin に設定されています。

1. 現在、このポリシーは、追跡リソースとして分類されていないリソースに対するサードパーティのストレージアクセスを制限していません。 今後、サードパーティのストレージアクセスに追加の制限を適用する場合があります。
2. ポリシーによって適用される制限は、追跡リソースとして分類されたサードパーティのスクリプトがページのメインコンテキストのストレージにアクセスすることを妨げません。 これらのスクリプトは、最上位オリジンを対象としたストレージを引き続き使用できます。
3. 追跡者として分類されたオリジンは、ファーストパーティのコンテキストで読み込まれると、自分のストレージにアクセスできます。
4. 最上位コンテキストと同じ eTLD+1 から読み込まれたクロスオリジンリソースは、引き続きストレージにアクセスできます。
5. 追跡者として通常分類されるオリジンは、最上位ページのオリジンがそれらと同じ組織からのものであると判断された場合、ブロックされません。

ウェブ互換性を改善し、ストレージアクセスを必要とするサードパーティのインテグレーションを許すために、Firefox はこのセクションで説明するように、特定のサードパーティオリジンに対して、ファーストパーティを対象としたストレージアクセスを許可します。 現在、Firefox には、ユーザーが追跡者として分類されるサードパーティとやり取りするときに、これらのサードパーティリソースにストレージアクセスを許可するいくつかのウェブ互換性経験則が含まれています。 これは、アクセスを許可しないとウェブページが中断することが予想される場合に行います。 また、埋め込みの <iframe> が Document.requestStorageAccess() を呼び出してストレージアクセスを要求できる Storage Access API の初期実装もサポートしています。 これらのアプローチは両方とも同じレベルのストレージアクセスを提供しますが、ストレージへのアクセスを保証するために、サードパーティが Storage Access API の使用に切り替えることをお勧めします。

ウェブ互換性を改善するために、Firefox には現在、ユーザーとのやり取りを受け取るサードパーティにストレージアクセスを自動的に許可するためのいくつかの経験則が含まれています。 これらの経験則は、ウェブで一般的な一部のサードパーティのインテグレーションを機能させ続けることを目的としています。 これらは一時的なものであり、Firefox の将来のバージョンでは取り除かれる予定です。 現在および将来のウェブ開発において依存するべきではありません。

ユーザージェスチャーが元の文書へのオープナーアクセスを持つポップアップウィンドウをトリガーすると、追跡リソースとして分類されたリソースにサードパーティのストレージアクセスが許可される場合があります。 その場合、サードパーティのオリジンにアクセスを許可する方法には次の3つがあります。

• ポップアップウィンドウに最初に読み込まれるリソースのオリジンには、オープナー文書へのストレージアクセスが許可されます。 オリジンが追跡アクセスを取得するためにこの経験則を悪用していることが判明した場合、そのオリジンには、過去30日以内にファーストパーティとしてユーザーとのやり取りを受け取る必要があるという追加の要件があります。
• 最初のリソースがポップアップウィンドウに読み込まれた後、ウィンドウは他のホストへの一連のリダイレクトを通過する場合があります。 ユーザーがリダイレクト後にポップアップウィンドウとやり取りすると、ポップアップウィンドウに読み込まれたコンテンツのオリジンにはオープナー文書のストレージアクセスが与えられます。
• 追跡オリジンから非追跡オリジンへの最上位のリダイレクトがある場合、追跡オリジンは、非追跡オリジンとリダイレクトチェーンのさらに下に表れる他の非追跡オリジンで短期間のストレージアクセスを受け取ります（つまり、読み込みがリダイレクトし続ける場合）。 追跡オリジンは、過去30日以内にファーストパーティとしてユーザーとのやり取りを受け取っている必要があり、ストレージアクセス許可は15分後に期限切れになります。

ストレージアクセスが許可されると、それはオープナー文書のオリジンまたはそのオリジンのサブドメインを対象とします。 オリジンのサブドメインで許可されたアクセスは、最上位オリジンに拡張されません。 例えば、tracker.example のリソースに foo.example.com のストレージアクセスが許可されている場合、tracker.example は example.com ではなく bar.foo.example.com のクッキーにアクセスできます。 代わりに、tracker.example が example.com でアクセスを許可された場合、bar.foo.example.com、foo.example.com、および example.com のストレージにアクセスできます。

example.com の tracker.example にストレージアクセスが許可されると、example.com から読み込まれた任意の最上位文書において tracker.example から読み込まれたすべてのリソースには、すぐにストレージアクセスが与えられます。 これには、ページのメインコンテキストに読み込まれたすべてのリソース、埋め込み <iframe>、埋め込み <iframe> に読み込まれたリソースが含まれます。 ストレージアクセスは、example.com に読み込まれた他のリソース（other-tracker.example など）や、tracker.example が埋め込まれている他のファーストパーティ（example.org など）には拡張されません。

ストレージアクセス許可は、ネストされたコンテキストの最初のレベルまで拡張されますが、それ以上は拡張されません。 これは、ページのメインコンテキストに埋め込まれ、追跡者として分類されたドメインから読み込まれた <iframe> が、JavaScript を介してアクセス可能なすべてのストレージの場所に完全にアクセスできることを意味します。 同様に、ページのメインコンテキストに埋め込まれた <iframe> に読み込まれたリソースの要求は、HTTP クッキーにアクセスできます。 ただし、追跡者として分類されたオリジンからのものを含むがこれに限定されない、さらにネストされたコンテキストは、ストレージアクセスを許可されません。

tracker.example にストレージアクセスを許可している example.com から読み込まれた最上位ページでの以下の埋め込みのシナリオを検討してください。

ストレージアクセス許可は30日後に失効します。 追跡リソースとして分類されたドメインには、複数のファーストパーティでサードパーティのストレージアクセスが許可される場合があり、各パーティのストレージ許可は独立して期限切れになります。 上記の経験則は、すでにアクセスが許可されているオリジンに対するサードパーティのストレージ許可の有効期間を延長するのにも役立ちます。 経験則がアクティブになるたびに、または Storage Access API の成功呼び出しが行われるたびに、以前にアクセスが許可された時点から数えて、既存のストレージアクセスの有効期限が30日間延長されます。

今後、ストレージアクセスの有効期間を変更する予定です。 前述したように、今後ストレージをサードパーティとして使用できることを知る方法は、Storage Access API を使用することです。

サイト所有者は、サイト、特にサードパーティのコンテンツインテグレーションに依存しているサイトをテストすることをお勧めします。 テストを簡単にするために、Firefox にいくつかの新機能を追加しました。

Firefox 開発ツールのネットワークモニターには、追跡リソースとして分類されたすべてのリソース要求のインジケーターが含まれるようになりました。 このインジケータは、ドメイン列に盾のアイコンとして表示されます。 次のサンプル画像では、trackertest.org は追跡リソースとして分類されていますが、example.com への要求は追跡リソースではありません。

サイトのサードパーティドメインが追跡者として分類された場合、どのように機能するのか興味がありますか？ トラッキング防止 URL 分類子にカスタムドメインを追加できる設定を追加しました。 そうするには次のようにします。

1. アドレスバーに about:config と入力します。 「注意して進んでください！」と警告するページが表示された場合は、「危険性を承知の上で使用する！」をクリックします。
2. 設定名 "urlclassifier.trackingAnnotationTable.testEntries" を検索します。
3. 設定がすでに存在する場合は、設定値を編集します。
4. 設定が存在しない場合は、「文字列」をクリックしてから「+」をクリックして、新しい設定を作成します。
5. 設定値には、追跡者として分類するオリジンをコンマで区切って入力します。 例えば、"example.net,example.org"。

このクッキーポリシーはサイトの中断につながる可能性がありますが、一般的なサードパーティのインテグレーションがクロスサイトトラッキングを防止しながら機能し続けるように設計されています。 このセクションでは、さまざまなインテグレーションのシナリオで期待できる機能について説明します。

いいえ — この機能は、ウェブサイトをわたってユーザーを追跡するために使用できるクッキーとサイトデータへのアクセスのみを制限します。 追跡識別子をブロックしても、広告の表示は妨げられません。

これは、サードパーティの分析サービスの実装方法に依存します。 サードパーティの分析プロバイダーは、サードパーティのストレージを使用してデータを収集できなくなります。 これは、サードパーティドメイン、またはローカルストレージとそのオリジンの下に保存されている他のサイトデータを対象としたクッキーを使用するプロバイダーが、他のウェブサイトにわたる識別子にアクセスできなくなることを意味します。

これらのサービスがページのメインコンテキストに埋め込まれている場合、ファーストパーティのクッキーとサイトストレージを引き続き使用して、その特定のファーストパーティのドメインにおいてページにわたった訪問を追跡できます。

これは、ソーシャルインテグレーションの実装方法によって異なります。 人気のあるソーシャルインテグレーションの多くは、Firefox の現在のクッキーポリシーに基づいて機能し続けますが、ユーザーエクスペリエンスに若干の違いがあります。

追跡者として分類されたソーシャルコンテンツプロバイダーは、ユーザーが新しいファーストパーティに初めてアクセスしたときにサードパーティのクッキーにアクセスできません。 したがって、ユーザーはプロバイダーのウェブサイトに直接アクセスしたときにログインしているにも関わらず、サービスにログアウトしているように見える場合があります。 インテグレーションの種類によっては、ユーザーがソーシャルコンテンツプロバイダーとやり取りするために、プロバイダーにクッキーへのアクセスを許可する前に、何らかのアクションを実行する必要がある場合があります。 例えば次のようにです。

• ソーシャルログインの場合、ユーザーはファーストパーティのログインボタンをクリックする必要があります。
• ソーシャルのいいねボタンやシェアボタンの場合、ユーザーは最初にログアウト状態のボタンを操作する必要があります。 一度行うと、多くのソーシャルコンテンツプロバイダーはログインを促します。

これらのやり取りの後、プロバイダーは、上記のストレージアクセスのアクティベーション経験則によって捕捉される方法でユーザーにプロンプ​​トした場合、サードパーティのストレージアクセスを受け取ります。 これらのプロバイダーは、できるだけ早く Storage Access API を介してストレージアクセスを明示的に要求するように切り替えることを検討する必要があります。 この API の初期実装は、現在 Nightly で利用可能です。

これは、サードパーティが測定ツールをどのように実装したかに依存しますが、一般に広告コンバージョンの測定はより困難になります。 次の例を考慮してください。

1. あなたは、ユーザーが何度も見たがクリックされなかったソーシャルメディアウェブサイトで広告を掲載している。 そのユーザーは、後で同じソーシャルメディアウェブサイトからのコンバージョン追跡タグを含んであなたのウェブサイトに訪問します。 このタイプのコンバージョンは、多くの場合「ビュースルーコンバージョン」と呼ばれます。 ソーシャルメディアウェブサイトはそれらのサードパーティのストレージにアクセスできないため、それらのウェブサイトで広告を見たユーザーと同じユーザーとしてユーザーを認識せず、コンバージョンは追跡されません。 ディスプレイネットワークで提供されるものを含め、ほとんどのビュースルーコンバージョン追跡技術は機能しなくなると予想されます。
2. あなたは、ユーザーがクリックしたディスプレイネットワークまたはソーシャルメディアウェブサイトで広告を掲載している。 そのユーザーはあなたのウェブサイトに着陸します。 これには、あなたの広告を表示した同じウェブサイトのコンバージョン追跡タグが含まれています。 このタイプのコンバージョンは、しばしば「クリックスルーコンバージョン」と呼ばれます。 ソーシャルメディアサイトまたはディスプレイネットワークはそれらのサードパーティのストレージにアクセスできないため、それらのウェブサイトで広告を見たユーザーと同じユーザーとしてユーザーを認識せず、コンバージョンは追跡されません。 このバージョンのクリックスルーコンバージョンは機能しなくなると予想されます。
3. あなたは、ソーシャルメディアウェブサイトに表示される広告を掲載している。 ユーザーがあなたの広告をクリックすると、サードパーティのネットワークからコンバージョン追跡タグを含むランディングページに移動します。 ソーシャルメディアのウェブサイトでは、ネットワークは広告のランディングページ URL に、訪問が広告をクリックした結果であることを示すクエリパラメーターで注釈を付けます。 あなたのウェブサイトでは、ディスプレイネットワークのタグが URL クエリパラメーターをチェックし、広告追跡パラメータをファーストパーティストレージに保存します。 ユーザーが後でコンバージョンイベントを完了した場合、ネットワークのタグはファーストパーティストレージをチェックして、訪問の原因となったクリックを特定します。 この方法で実装されたクリックスルーコンバージョンは引き続き機能すると予想されます。