ストレージアクセスポリシー: トラッカーからのクッキーのブロック

Firefoxでのテスト

このクッキーポリシーは、Firefox バージョン 63 以降で利用できます。このドキュメントでは、Firefox リリース版ユーザー向けに提供を計画してあるポリシーについて記述していますが、現在の Firefox リリース版に実装されている内容とは一致しない場合があります。これは、プレリリース版である Firefox Nightly にポリシーの新しい要素が実装され次第、直ちにドキュメント化しているためです。また、Firefox Nightlyには、現時点でリリース版ユーザーへの提供を予定していない実験的な機能が含まれている場合があります。実験的な機能については、このドキュメントには記載されませんが、トラッカーとして分類されたドメインの機能に影響を与える可能性があります。

サイトでは、Firefox Nightly でのテストを推奨いたします。これは、最新の保護機能が組み込まれているためです。前述の通り、Nightly には追加の保護機能が含まれている場合がありますが、これらはリリース版ユーザーに提供される前に除去または変更される可能性がある点にご注意ください。保護機能を強化していくにつれ、このページを最新の情報で随時更新していきます。

Nightly 版では、これらの保護機能はデフォルトで有効になっています。Firefox の他のバージョンでは、コンテンツブロッカーの設定^(英語)からクッキーポリシーを有効にできます（手順はバージョンによって異なります。リンク先のドキュメントには、該当する Firefox バージョンを選択するためのドロップダウンメニューがあります）。

不具合のあるサイトを報告してください

この変更により、正常に動作しなくなったウェブサイトを見つけた場合は、Bugzilla の Firefox product 内の "Tracking Protection" コンポーネントにバグを報告してください。あるいは、Control Center の "Content Blocking" セクションにある "Report a Problem" をクリックして、Firefox から直接不具合のあるサイトを報告することもできます（このショートカットは、Firefox のすべてのバージョンで利用できない場合があります）。

トラッキング防止機能の解説

Firefox は、どのリソースがトラッキングリソースであるかをどのように判断するのでしょうか？

Firefox は、トラッキング防止リストを使用して、どのリソースがトラッキングリソースであるかを判断します。トラッキング防止リストは Disconnect によって管理されています^(英語)。Firefox でこのリストを適用する際、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 ファクトリーオブジェクトにアクセスしようとすると、SecurityError 例外が発生します。

メッセージとワーカー:

• ブロードキャストチャンネル: 新しい BroadcastChannel を作成しようとすると、SecurityError 例外が発生します。
• 共有ワーカー: 新しい SharedWorker を作成しようとすると、SecurityError 例外が発生します。
• サービスワーカー: 新しい ServiceWorker を作成しようとすると、SecurityError 例外が発生します。

DOM キャッシュ:

• CacheStorage を呼び出すと、常に SecurityError を返します。

ブラウザーのキャッシュ:

• HTTP キャッシュ、画像キャッシュ、代替サービス (Alt-Svc) キャッシュは、リソースを追跡するためにすべてパーティション化されています。これにより、それぞれの最上位オリジンには別個のパーティションが割り当てられ、異なる最上位オリジン上のリソースは互いに分離してキャッシュされます。

ネットワーク接続:

• TLS セッション^(英語)は、トラッカーとして分類される埋め込みのサードパーティーリソースに対して HTTPS 接続を行う場合、セッションチケットを使用して再開されません。
• トラッカーとして分類されたドメインによる HTTP 接続の再利用は、同じ最上位オリジン下で行われるリクエストに制限されます。例えば、news.example 上の tracker.example からのコンテンツに対するリクエストは、shopping.example 上の tracker.example からのコンテンツに対するリクエストや、tracker.example が直接（つまりファーストパーティとして）アクセスされた際に発生するリクエストとは、HTTP 接続を再利用しません。

HTTP リファラー

• トラッカーに分類されるサードパーティーのリソースに対するデフォルトのリファラーポリシーは、strict-origin-when-cross-origin に設定されています。

このポリシーでは何がブロックされないのか

1. このポリシーは、現時点では、トラッキングリソースに分類されないリソースに対するサードパーティーストレージへのアクセスを制限していません。将来、サードパーティーストレージへのアクセスに対して追加の制限を適用する可能性があります。
2. このポリシーによって適用される制限は、トラッキングリソースに分類されるサードパーティースクリプトが、ページのメインコンテキスト内のストレージにアクセスすることを妨げるものではありません。これらのスクリプトは、トップレベルオリジンをスコープとするストレージを続けることができます。
3. トラッカーとして分類されたオリジンは、ファーストパーティのコンテキストで読み込まれた場合、自分自身でストレージにアクセスできます。
4. 最上位のコンテキストと同じ登録可能なドメインから読み込まれたクロスオリジンリソースは、引き続き自分自身でストレージにアクセスできます。
5. 通常はトラッカーとして分類されるオリジンであっても、最上位のページオリジンがそれらと同じ組織に属していると判断された場合、ブロックされません^(英語)。

ストレージへのアクセス許可

ウェブの互換性を向上させ、ストレージへのアクセスを必要とするサードパーティー製サービスの統合を可能にするため、Firefox では、この節で説明するように、具体的なサードパーティーオリジンに対してファーストパーティーに限定したストレージへのアクセス権を付与します。現在、Firefox には、ユーザーがサードパーティーとやり取りを行う際に、トラッカーとして分類されたサードパーティー製リソースに対してストレージへのアクセス権を付与する、いくつかのウェブ互換性に関するヒューリスティックが記載されています。これは、アクセスを許可しないことでウェブページが正常に動作しなくなることが発生する可能性がある場合に実施されます。同時に、ストレージアクセス API の初期実装も対応しており、これを通じて埋め込まれた <iframe> は、Document.requestStorageAccess() を呼び出すことでストレージへのアクセスをリクエストできます。これら両方の手法は同レベルのストレージアクセスを提供しますが、サードパーティーがストレージへのアクセスを確実に保証するためには、ストレージアクセス API を使用することをお勧めします。

操作時におけるストレージへの自動アクセス

ウェブの互換性を向上させるため、Firefox では現在、ユーザーからの操作を受け取ったサードパーティーに対して、ストレージへのアクセスを自動的に許可するいくつかの推論手法を含まれています。これらの推論手法は、ウェブ上で一般的な一部のサードパーティー製機能の動作を維持する目的で導入されています。これらは一時的な措置であり、将来の Firefox のバージョンで除去される予定です。現在および将来のウェブ開発において、これらに依存すべきではありません。

ユーザーが操作を行って、元の文書に対する opener アクセスを持つポップアップウィンドウが発生した場合、サードパーティーによるストレージへのアクセスが許可されることがあります。ユーザーがポップアップを操作した場合、ポップアップウィンドウに最初に読み込まれたリソースのオリジンは、過去 30 日以内にファーストパーティとしてユーザーからの対話を受け取っている場合、操作元文書へのストレージアクセスが許可されます。

ユーザーが同じウィンドウ内で別のオリジンに移動した場合にも、サードパーティーのストレージへのアクセスが許可されることがあります。ユーザーがそのオリジン上で操作を行い、その後速やかに最初のオリジンにある文書に移動した場合、その中間ページには、その最終的な文書に対するストレージへのアクセスが許可されます。

ストレージへのアクセス範囲

ストレージへのアクセスが許可された場合、そのスコープは操作元文書のサイト、またはそのオリジンのサブドメインに限定されます。オリジンのサブドメインで許可されたアクセス権は、最上位のオリジンにも適用されます。例えば、tracker.example のリソースが foo.example.com でのストレージアクセスを許可された場合、tracker.example は bar.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 クッキーへのアクセス権を持ちます。ただし、トラッカーとして分類されたオリジンを含む（ただしこれに限定されない）さらに内側のコンテキストに対しては、ストレージへのアクセス権は付与されません。

example.com から読み込まれた最上位ページにおいて、tracker.example にストレージへのアクセス権限が付与されている場合、以下の埋め込みシナリオについて考えてみましょう。

ストレージアクセスの期限

ストレージへのアクセス許可は 30 日後に失効します。トラッキングリソースとして分類されたドメインは、複数のファーストパーティに対してサードパーティーのストレージアクセス許可を持つことができる可能性があり、それぞれのパーティに対するストレージアクセス許可は個別に失効します。上記の推論ルールは、すでにアクセス許可が与えられているオリジンにおけるサードパーティのストレージアクセス許可の有効期間を延長する役割も果たします。ヒューリスティックが有効になるそれぞれのとき、またはストレージアクセス API への呼び出しが成功するたびに、既存のストレージアクセス権の有効期限は、前回のアクセスが許可された時点から起算して 30 日間延長されます。

今後、ストレージへのアクセス権の有効期間について変更を行う予定ですので、あらかじめご了承ください。前述の通り、今後サードパーティーとしてストレージを利用できるかどうかを確認するには、ストレージアクセス API を使用いただくことになります。

デバッグ

サイト運営者は、特にサードパーティーコンテンツ統合に頼っているサイトについて、テストを行うことをお勧めします。Firefox には、テストを容易にするための新しい機能をいくつか追加しました。

開発者ツールの通知

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

トラッキング保護リストに独自のドメインを追加する

サイト上のサードパーティードメインがトラッカーとして分類された場合、どのような動作になるのか気になりますか？トラッキング保護の URL 分類機能に独自のドメインを追加することができる環境設定を追加しました。設定方法は以下の通りです。

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

FAQ

このクッキーポリシーは、サイトが正常に動作しなくなる可能性がありますが、サイト間での追跡を防止しつつ、一般的なサードパーティー製サービスの連携機能を続けることができるよう設計されています。この節では、さまざまな連携シナリオにおいて期待できる機能について説明します。

このストレージアクセスポリシーによって、ウェブサイトに広告が表示されなくなりますか?

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

トラッカーに分類されるサードパーティー分析サービスを使用していますが、分析データは引き続き受け取れますか?

これは、サードパーティの分析サービスがどのように実装されているかによって異なります。サードパーティの分析プロバイダーは、自社のサードパーティストレージを使用してデータを収集することができなくなりました。つまり、自社のサードパーティドメインにスコープが限定されたクッキーを使用しているプロバイダー、あるいは自社のオリジン下に格納されたローカルストレージやその他のサイトデータを使用しているプロバイダーは、他のウェブサイトにおいてそれらの識別子にアクセスできなくなりました。

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

ソーシャルログインや「いいね！」ボタン、シェアボタンの統合にはサードパーティーサービスを使用しています。ユーザーは引き続きこれらのサービスを使用できますか?

これは、ソーシャル連携がどのように実装されるかによって異なります。一般的なソーシャル連携機能の多くは、Firefox の現在のクッキーポリシー下と同様に機能し続けるものと予想されますが、使い勝手には若干の違いが生じる可能性があります。

トラッカーに分類されるソーシャルコンテンツプロバイダーは、ユーザーが新しいファーストパーティサイトに初めてアクセスした際、そのユーザーのサードパーティクッキーにアクセスできません。そのため、ユーザーがプロバイダーのウェブサイトに直接アクセスした際、実際にはログインしているにもかかわらず、サービス側ではログアウト状態と見なされる場合があります。統合の方式によっては、プロバイダーがユーザーのクッキーにアクセスできるようになる前に、ユーザーがソーシャルコンテンツプロバイダーと何らかのやり取りを行うことができる場合があります。例を示します。

• ソーシャルログインの場合、ユーザーはファーストパーティのログインボタンをクリックする必要がある可能性があります。
• ソーシャルメディアの「いいね」や「シェア」ボタンについては、ユーザーがログアウト状態でそのボタンに対する最初の操作をする必要があります。そうすると、多くのソーシャルコンテンツプロバイダーはログインを促すメッセージを表示します。

これらの操作の後、プロバイダーが、前述のストレージアクセス有効化の推論規則に該当する形でユーザーに確認を求めた場合、そのプロバイダーにはサードパーティーによるストレージアクセス権限が付与されます。これらのプロバイダーは、できるだけ早く、ストレージアクセス API を通じて明示的にストレージアクセスをリクエストする方式への移行を検討すべきです。この API の初期実装は、現在 Nightly で利用可能です。

サードパーティーのピクセルやその他のツールを使用して、広告キャンペーンの効果を測定しています。今後も広告のコンバージョン率を測定することは可能でしょうか？

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

1. あるソーシャルメディアサイトで広告を掲載し、ユーザーに数回表示されましたが、クリックされることはありませんでした。その後、そのユーザーが貴社のウェブサイトを訪問し、そのサイトには同じソーシャルメディアサイトのコンバージョン追跡タグが記載されていました。この種のコンバージョンは、多くの場合「ビュースルーコンバージョン」と呼ばれます。ソーシャルメディアサイトはサードパーティーのストレージにアクセスしていないため、そのサイト上で広告を閲覧したユーザーと同一人物であると認識できず、コンバージョンは追跡されません。ディスプレイネットワークが提供するものを含め、ほとんどのビュースルーコンバージョン追跡手法は動作しなくなりました。
2. ディスプレイネットワークやソーシャルメディアサイトに広告を掲載し、ユーザーがそれをクリックしたとします。そのユーザーはウェブサイトにアクセスしますが、そのサイトには、広告を表示させたサイトと同じコンバージョン追跡タグが記載されています。この種のコンバージョンは、多くの場合「クリックスルーコンバージョン」と呼ばれます。ソーシャルメディアサイトやディスプレイネットワークは、サードパーティーのストレージにアクセスできないため、そのユーザーを自社のウェブサイトで広告を見たユーザーと同一人物として認識できず、コンバージョンは追跡されません。この形式のクリックスルーコンバージョンは、今後動作しなくなるものと予想されます。
3. ソーシャルメディアサイトに現れる広告を掲載しています。ユーザーが広告をクリックすると、サードパーティーによるコンバージョン追跡タグが埋め込まれたランディングページに移動します。ソーシャルメディアサイト上で、ネットワークは広告のランディングページのURLにクエリー引数を追加し、その訪問が広告のクリックによるものであることを示します。貴社のウェブサイトでは、ディスプレイネットワークのタグが URL のクエリー引数を調べ、広告追跡引数をファーストパーティストレージに保存します。その後、ユーザーがコンバージョンイベントを完了した場合、ネットワークのタグはファーストパーティストレージを確認し、どのクリック（または複数のクリック）がその訪問の原因であったかを特定します。この方法で実装されたクリックスルーコンバージョンは、今後も正常に機能し続けると予想されます。