Pre-release versions of Firefox include a new storage access policy that blocks cookies and other site data from third-party tracking resources. This new policy is designed as an alternative to thecurrent policies offered in release versions of Firefox, and protects against cross-site tracking while minimizing the site breakage associated with cookie blocking. This article explains how the new policy works and how you can test it.
If you’d like to test how your website works under the new policy we encourage you to download Firefox Nightly and try it out. You can enable it through the “Content Blocking” menu in theControl Center in Firefox Nightly:
If you find a website broken as a result of this change, file a bug under the Tracking Protection component within the Firefox product onBugzilla.
As this is an experimental policy, it will likely change as we discover site breakage and fix bugs. We’ll keep this page updated with the newest information.
How does Firefox determine which resources are tracking resources?
Firefox uses the Tracking Protection list to determine which resources are tracking resources. The Tracking Protection list is maintained by Disconnect. When the list is applied in Firefox, we make two important changes:
Firefox uses the built-inTracking Protection URL classifier to determine which resources match the tracking protection list. Domains are matched against the list in accordance with the SafeBrowsing v4 specification. Specifically, we check the exact hostname of the resource against the list, as well as the last four hostnames formed by starting with the last five components and successively removing the leading component. Consider the following examples:
|Hostname on the list||Hostname of resource||Matched|
| || ||Yes|
| || ||Yes|
| || ||No|
| || ||No|
| || ||Yes|
The storage access policy blocks resources identified as trackers from accessing their cookies and other site storage when they are loaded in a third-party context. This prevents those resources from retrieving tracking identifiers stored in cookies or site storage and using them to identify users across visits to multiple first parties. Specifically, Firefox does this by imposing the following restrictions:
Cookierequest headers and ignore
Document.cookieand ignore requests to set cookies via
Messaging and Workers:
BroadcastChannelwill throw a
SharedWorkerwill throw a
ServiceWorkerwill throw a
CacheStoragewill always reject with a
In order to improve web compatibility and permit third-party integrations that require storage access, Firefox will grant storage access scoped to the first party for a particular third-party origin under the following conditions. Currently, Firefox includes some web compatibility heuristics that grant storage access to third-party resources classified as trackers when a user interacts with those third parties. We do this when we expect that not granting access would result in the web page to break. We’re also working on improving our support for the Storage Access APIas a way for embedded
<iframe> s to request access. Going forward, we recommend third-parties to switch to using the Storage Access API in order to ensure being able to guarantee their access to storage when needed.
In order to improve web compatibility, Firefox currently includes some heuristics to grant storage access automatically to third parties that receive user interaction. These heuristics are intended to allow some third-party integrations that are common on the web to continue to function. They are intended to be temporary and will be removed in a future version of Firefox. They should not be relied upon for current and future web development.
Third-party storage access may be granted to resources that have been classified as tracking resources when a user gesture triggers a pop-up window that hasopener access to the originating document. When that occurs, there are two possible ways a third-party origin can be granted access:
When storage access is granted, it is scoped to the origin of the opener document or subdomains of that origin. Access that is granted on the subdomain of an origin does not extend to the top-level origin. As an example, if a resource from
tracker.exampleis granted storage access on
tracker.examplewill be able to access its cookies on
example.com. Instead, if
tracker.examplewere granted access on
example.comit would be able to access its storage on
When storage access is granted to
example.com, all resources loaded from
tracker.exampleon any top-level document loaded from
example.comare immediately given storage access. This includes all resources loaded in the main context of the page, embedded
<iframe>s, and resources loaded within embedded
<iframe>s. Storage access is not extended to other resources loaded on
other-tracker.example), nor to other first parties on which
tracker.exampleis embedded (e.g.
Storage access grants extend into the first level of nested contexts, but no further. This means that
<iframe>s embedded in the main context of the page will have access to HTTP cookies. However, further nested contexts, including but not limited to those from the origin classified as a tracker, will not be granted storage access.
Consider the following embedding scenarios on a top-level page loaded from
tracker.examplehas been granted storage access.
|Embedding||tracker.example resource storage access|
|An image is loaded from ||HTTP: Yes |
| ||HTTP: Yes |
| ||HTTP: Yes |
| ||HTTP: Yes |
| ||HTTP: Yes |
The storage access grant expires after 30 days. Domains classified as tracking resources may be granted third-party storage access on multiple first parties, and the storage permission for each party expires independently. The above heuristics will also serve to extend the lifetime of a third-party storage permission on origins that have already been granted access. Each time the heuristic is activated, or a success call to the Storage Access API is made, the pre-existing storage access expiration will be extended by 30 days, counting from the time the previous access was granted.
Please note that in the future we expect to make changes to how long storage access will remain valid for. As mentioned before, the way to know that you will be able to use storage as a third-party going forward will be using the Storage Access API.
We encourage site owners to test their sites, particularly those that rely on third-party content integrations. We’ve added several new features to Firefox to make testing easier.
The devtoolsNetwork Monitor now includes an indicator for all resource requests that have been classified as tracking resources. This indicator is shown as a shield icon in the domain column. In the sample image below,
trackertest.orgis classified as a tracking resource, while the request to example.com is not.
Curious how things will work if a third-party domain on your site were classified as a tracker? We’ve added a preference that allows you to add custom domains to the Tracking Protection URL classifier. To do so:
Warning: Be sure to remove these entries after you have finished testing.
No — this feature only restricts access to cookies and site data that can be used to track users across websites. Blocking tracking identifiers does not prevent the display of advertisements.
I use a third-party analytics service that is classified as a tracker. Will I still receive analytics data?
This depends on how the third-party analytics service is implemented. Third-party analytics providers will no longer be able to user their third-party storage to collect data. This means that providers using cookies which are scoped to their third-party domain, or local storage and other site data stored under their origin, will no longer have access to those identifiers across other websites.
If these services are embedded into the main context of the page, they can continue to use first-party cookies and site storage to track users across page visits on that specific first-party domain.
I use third-party services for social login, like, and share button integration. Will my users still be able to make use of these services?
A social content provider that is classified as a tracker will not have access to their third-party cookies when the user first visits a new first party. Thus, the user may appear logged out to the service despite being logged in when they visit the provider’s website directly. Depending on the type of integration, the user may have to take some action to interact with the social content provider before the provider is given access to their cookies. For example:
After these interactions, the provider will receive third-party storage access if they prompt the user in a way that is captured by the storage access activation heuristics described above. These providers should consider switching to explicitly request storage access through the Storage Access API as soon as possible. An initial implementation of this APIis currently available in Nightly.