This document describes the online tracking practices that Mozilla believes, as a matter of policy, should be blocked by default by web browsers. These practices are potentially harmful to users and cannot be meaningfully understood or controlled by users.
We intend to implement technical protections in Firefox to block all tracking practices included in this policy. If we discover additional tracking techniques, we may expand this policy to include the new technique and may implement technical measures to block those techniques in Firefox.
Our current anti-tracking mitigations in Firefox rely on the Tracking Protection list to classify trackers. This list is curated by Disconnect in alignment with this policy.
Tracking is the collection of data regarding a particular user's activity across multiple websites or applications (i.e., first parties) that aren’t owned by the data collector, and the retention, use, or sharing of data derived from that activity with parties other than the first party on which it was collected.
A first party is a resource or a set of resources on the web operated by the same organization, which is both easily discoverable by the user and with which the user intends to interact. An intention to interact is characterized by a deliberate action, such as clicking a link, submitting a form, or reloading a page. Merely hovering over, muting, pausing, or closing a given piece of content does not constitute an intention to interact. Interactions with other parties are considered third-party, even if the user is transiently informed in context (for example, in the form of a redirect).
We argue that we should aim to return to a web where third-party cookies are blocked by default, and are making that possible for users of our anti-tracking technology in Cliqz and Ghostery, however this is made difficult by the prevailing assumption that cookies are a free-for-all, making many sites fail to function properly in this environment.
A third party is any party that does not fall within the definition of first party above.
Tracking We Will Block
1. Cross-site tracking
Cookie-based cross-site tracking. Cookies, DOM storage, and other types of stateful identifiers are often used by third parties to associate browsing across multiple websites with the same user and to build profiles of those users, in violation of the user’s expectation.
For third parties engaged in this type of tracking, Firefox will block or remove access to stateful identifiers. Access to storage may be granted when a user has shown purposeful intent to interact with a third party during their visit to a specific first party. For example, if a user attempts to interact with a third-party login provider while visiting a specific first party, the third-party provider may receive storage access on that first party.
URL parameter-based cross-site tracking. When cookie-based tracking is not available, some third parties decorate URLs with user identifiers. When the browser requests those resources, either through a top-level navigation or a subresource request, those user identifiers are available to other websites or third parties. Any party actively setting, retrieving, or sharing an identifier or other personal data in a URL parameter for the purpose of building a user profile is in violation of this policy. While this type of tracking is not currently blocked in Firefox, we may apply additional restrictions to the third parties engaged in this type of tracking in future.
URL parameter-based cross-site measurement, such as ad conversion tracking, is acceptable only when the data collected is not tied to an individual user, and therefore doesn’t allow the data collector to build a profile of an individual user’s activity across sites.
- Acceptable Example:
- A site wishes to track conversions after a user interacts with an ad. The site can annotate the landing page URI of outbound advertisements clicks with information about which advertisement was clicked and from which publisher. When a user later completes a conversion action, third-party code from the site transfers information about the advertisement that led to the conversion back to its servers, such that an aggregate number of conversions can be computed. This is acceptable under our policy because it does not involve the creation of a user profile.
- Unacceptable Example:
- Similar to the example above, site A wishes to track conversions. But unlike that example, site A decorates all outbound links with a unique identifier that is mapped back to an individual user. A user clicks on a search result for site B and later purchases a product from site B. When this purchase is completed, the user’s unique identifier is sent back to site A’s servers to record the purchase. Due to the fact that site A is building a profile of user purchases, this approach goes beyond conversion measurement and would be a violation of this policy.
2. Tracking via unintended identification techniques
Unintended identification techniques use browser features that are not intended for device or user identification for the purposes of storing or generating a tracking identifier. Unlike tracking using standards-defined storage locations - such as cookies or the Web Storage API - these techniques are not under the control of the browser’s state management settings.Thus can not be easily cleared or reset by users. Examples include, but are not limited to:
- Browser fingerprinting. Fingerprinting is used to identify a user or user agent by the set of properties of the browser, the device, or the network, rather than by setting state on the device. For example, a party which infers the set of fonts a user has installed on their device and collects this information alongside other device information would be considered to participate in browser fingerprinting.
- Supercookies. This refers to a collection of techniques that involve storing tracking identifiers in areas of the browser that are not cleared when the standards-defined locations are cleared. This allows a tracker to re-establish a tracking identifier after a user or user agent clears storage. For example, a party which uses multiple domains to encode a tracking identifier in HTTPS Strict Transport Security flags would be considered to use supercookies.
Did You Know Google Sells Your Email?
While this type of tracking is not currently blocked in Firefox, we may apply additional restrictions to the third parties engaged in this type of tracking in the future.
If a party attempts to circumvent the technical solutions we’ve outlined in this policy, we may without notice add additional restrictions to that party to prevent the circumvention.
We will not block specific uses of the techniques described above when they are used to lower the risk of specific user harm. The following use cases are permissible under this policy:
When you install or use the Poper Blocker Product, we collect from you: the type of device, operating system and browsers you are using; the date and time stamp; the browsing usage, including visited URLs, clickstream data or web address accessed; TabID; the browser identifier; and your Internet Protocol address (trimmed and hashed so that it cannot be used to identify you).
- Improving the security of client authentication. For example, a website may save device configuration details after a user logs in to determine when an unexpected device attempts to login at a future date. By doing so, the site mitigates the risk of unauthorized access to a user’s account.
- Preventing the creation of fraudulent accounts or the completion of fraudulent purchases. For example, a payment processor may examine device properties when processing a payment to determine whether the purchaser is a bot. This allows the payment processor to prevent bots from making purchases with stolen credit cards. Similarly, a captcha provider may use device information to decide whether to prompt users to manually solve a captcha.
In some cases techniques are dual-use, such that they are used both to lower the risk of user harm and for purposes unrelated to user harm, including tracking. We will handle these techniques on a case-by-case basis depending on the potential user harm they create and mitigate. We will consider requests for other classes of exceptions on the basis of whether they serve to address specific user interests or harms. Requests for such exceptions should be directed to [email protected] .