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つの重要な変更が行われます。
Firefox は、組み込みのトラッキング防止 URL 分類子を使用して、トラッキング防止リストに一致するリソースを判別します。 ドメインは、SafeBrowsing v4 仕様に従ってリストと照合されます。 具体的には、リストに対してリソースの正確なホスト名を確認し、最後の5つのコンポーネントから開始して先頭のコンポーネントを次々に取り除くことによって形成された最後の4つのホスト名も同様に確認します。 次の例を検討してください。
| リスト上のホスト名 | リソースのホスト名 | 一致 |
|---|---|---|
example.com |
example.com |
はい |
example.com |
a.b.example.com |
はい |
blah.example.com |
example.com |
いいえ |
a.b.example.com |
c.d.example.com |
いいえ |
blah.example.com |
foo.blah.example.com |
はい |
ストレージアクセスポリシーは、追跡者として識別されたリソースがサードパーティのコンテキストに読み込まれたときに、それらのクッキーや他のサイトストレージにアクセスすることをブロックします。 これにより、それらのリソースがクッキーまたはサイトストレージに保存されている追跡識別子を取得し、それらを使用して複数のファーストパーティにわたって訪問したユーザーを識別することができなくなります。 具体的には、Firefox は次の制限を課してこれを行います。
クッキー:
Document.cookie を介してクッキーを設定する要求を無視します。DOM ストレージ:
Window.localStorage: 読み取りおよび書き込みの試みは SecurityError 例外をスローします。 Firefox 70より前: Window.localStorage は null です。 したがって、このオブジェクトを使用して読み書きしようとすると、TypeError 例外がスローされます。SecurityError 例外をスローします。メッセージングとワーカー:
SecurityError 例外をスローします。SecurityError 例外をスローします。SecurityError 例外をスローします。DOM キャッシュ:
SecurityError で拒否されます。ブラウザーキャッシュ:
ネットワーク接続:
HTTP リファラー:
strict-origin-when-cross-origin に設定されています。ウェブ互換性を改善し、ストレージアクセスを必要とするサードパーティのインテグレーションを許すために、Firefox はこのセクションで説明するように、特定のサードパーティオリジンに対して、ファーストパーティを対象としたストレージアクセスを許可します。 現在、Firefox には、ユーザーが追跡者として分類されるサードパーティとやり取りするときに、これらのサードパーティリソースにストレージアクセスを許可するいくつかのウェブ互換性経験則が含まれています。 これは、アクセスを許可しないとウェブページが中断することが予想される場合に行います。 また、埋め込みの {{htmlelement("iframe")}} が {{domxref("Document.requestStorageAccess()")}} を呼び出してストレージアクセスを要求できる Storage Access API の初期実装もサポートしています。 これらのアプローチは両方とも同じレベルのストレージアクセスを提供しますが、ストレージへのアクセスを保証するために、サードパーティが Storage Access API の使用に切り替えることをお勧めします。
ウェブ互換性を改善するために、Firefox には現在、ユーザーとのやり取りを受け取るサードパーティにストレージアクセスを自動的に許可するためのいくつかの経験則が含まれています。 これらの経験則は、ウェブで一般的な一部のサードパーティのインテグレーションを機能させ続けることを目的としています。 これらは一時的なものであり、Firefox の将来のバージョンでは取り除かれる予定です。 現在および将来のウェブ開発において依存するべきではありません。
ユーザージェスチャーが元の文書へのオープナーアクセスを持つポップアップウィンドウをトリガーすると、追跡リソースとして分類されたリソースにサードパーティのストレージアクセスが許可される場合があります。 その場合、サードパーティのオリジンにアクセスを許可する方法には次の3つがあります。
ストレージアクセスが許可されると、それはオープナー文書のオリジンまたはそのオリジンのサブドメインを対象とします。 オリジンのサブドメインで許可されたアクセスは、最上位オリジンに拡張されません。 例えば、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 から読み込まれた最上位ページでの以下の埋め込みのシナリオを検討してください。
| 埋め込み | tracker.example リソースのストレージアクセス |
|---|---|
画像は tracker.example から読み込まれ、example.com のメインコンテキストに埋め込まれます。 |
HTTP: はい JS: 該当なし |
example.com は、example.org から <iframe> を埋め込みます。 その <iframe> は、tracker.example から画像を読み込みます。 |
HTTP: はい JS: 該当なし |
example.com は、example.org から <iframe> を埋め込みます。 その <iframe> は、tracker.example から <iframe> を埋め込みます。 |
HTTP: はい JS: いいえ |
example.com は、tracker.example から <iframe> を埋め込みます。 |
HTTP: はい JS: はい |
example.com は、example.com（同じオリジン）から <iframe> を埋め込みます。 ネストされた <iframe> は、tracker.example から <iframe> を埋め込みます。 |
HTTP: はい JS: いいえ |
ストレージアクセス許可は30日後に失効します。 追跡リソースとして分類されたドメインには、複数のファーストパーティでサードパーティのストレージアクセスが許可される場合があり、各パーティのストレージ許可は独立して期限切れになります。 上記の経験則は、すでにアクセスが許可されているオリジンに対するサードパーティのストレージ許可の有効期間を延長するのにも役立ちます。 経験則がアクティブになるたびに、または Storage Access API の成功呼び出しが行われるたびに、以前にアクセスが許可された時点から数えて、既存のストレージアクセスの有効期限が30日間延長されます。
今後、ストレージアクセスの有効期間を変更する予定です。 前述したように、今後ストレージをサードパーティとして使用できることを知る方法は、Storage Access API を使用することです。
サイト所有者は、サイト、特にサードパーティのコンテンツインテグレーションに依存しているサイトをテストすることをお勧めします。 テストを簡単にするために、Firefox にいくつかの新機能を追加しました。
Firefox 開発ツールのネットワークモニターには、追跡リソースとして分類されたすべてのリソース要求のインジケーターが含まれるようになりました。 このインジケータは、ドメイン列に盾のアイコンとして表示されます。 次のサンプル画像では、trackertest.org は追跡リソースとして分類されていますが、example.com への要求は追跡リソースではありません。
サイトのサードパーティドメインが追跡者として分類された場合、どのように機能するのか興味がありますか？ トラッキング防止 URL 分類子にカスタムドメインを追加できる設定を追加しました。 そうするには次のようにします。
about:config と入力します。 「注意して進んでください！」と警告するページが表示された場合は、「危険性を承知の上で使用する！」をクリックします。警告: テストが終了したら、これらのエントリを必ず取り除いてください。
このクッキーポリシーはサイトの中断につながる可能性がありますが、一般的なサードパーティのインテグレーションがクロスサイトトラッキングを防止しながら機能し続けるように設計されています。 このセクションでは、さまざまなインテグレーションのシナリオで期待できる機能について説明します。
いいえ — この機能は、ウェブサイトをわたってユーザーを追跡するために使用できるクッキーとサイトデータへのアクセスのみを制限します。 追跡識別子をブロックしても、広告の表示は妨げられません。
これは、サードパーティの分析サービスの実装方法に依存します。 サードパーティの分析プロバイダーは、サードパーティのストレージを使用してデータを収集できなくなります。 これは、サードパーティドメイン、またはローカルストレージとそのオリジンの下に保存されている他のサイトデータを対象としたクッキーを使用するプロバイダーが、他のウェブサイトにわたる識別子にアクセスできなくなることを意味します。
これらのサービスがページのメインコンテキストに埋め込まれている場合、ファーストパーティのクッキーとサイトストレージを引き続き使用して、その特定のファーストパーティのドメインにおいてページにわたった訪問を追跡できます。
これは、ソーシャルインテグレーションの実装方法によって異なります。 人気のあるソーシャルインテグレーションの多くは、Firefox の現在のクッキーポリシーに基づいて機能し続けますが、ユーザーエクスペリエンスに若干の違いがあります。
追跡者として分類されたソーシャルコンテンツプロバイダーは、ユーザーが新しいファーストパーティに初めてアクセスしたときにサードパーティのクッキーにアクセスできません。 したがって、ユーザーはプロバイダーのウェブサイトに直接アクセスしたときにログインしているにも関わらず、サービスにログアウトしているように見える場合があります。 インテグレーションの種類によっては、ユーザーがソーシャルコンテンツプロバイダーとやり取りするために、プロバイダーにクッキーへのアクセスを許可する前に、何らかのアクションを実行する必要がある場合があります。 例えば次のようにです。
これらのやり取りの後、プロバイダーは、上記のストレージアクセスのアクティベーション経験則によって捕捉される方法でユーザーにプロンプトした場合、サードパーティのストレージアクセスを受け取ります。 これらのプロバイダーは、できるだけ早く Storage Access API を介してストレージアクセスを明示的に要求するように切り替えることを検討する必要があります。 この API の初期実装は、現在 Nightly で利用可能です。
これは、サードパーティが測定ツールをどのように実装したかに依存しますが、一般に広告コンバージョンの測定はより困難になります。 次の例を考慮してください。