MozillaWiki

Security/Anti tracking policy: Difference between revisions

Page Discussion

Security/Anti tracking policy (view source)

Revision as of 09:13, 5 October 2022

465 bytes removed ,  5 October 2022
Update navigation tracking policy text
(Fix mailto)
(Update navigation tracking policy text)
 
(10 intermediate revisions by 5 users not shown)
Line 14: Line 14:
== Tracking We Will Block ==
== Tracking We Will Block ==


===== 1. Cross-site tracking =====  
===== 1. Stateful cross-site tracking through Web APIs =====  
'''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.  
'''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.
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.
===== 2. Navigational cross-site tracking =====


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.
'''Cross-site tracking using URL decoration.''' When tracking by other means is not available, some entities choose to add information to URLs to pass information between sites. When the browser navigates between sites, the linking site adds information to the URL that is not about the destination page.  URL decoration might be used to carry information about the user: their identity, their interactions on the linking site, or other information.


::''Acceptable Example:''
Any party actively setting, retrieving, or sharing an identifier or other personal data in a URL for the purpose of building a user profile is in violation of this policy.
::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 because it does not involve the creation of a user profile.  


::''Unacceptable Example:''
The most common form of URL decoration uses [https://en.wikipedia.org/wiki/Query_string query parameters]. Firefox will seek to identify query parameters that sites use for tracking purposes and remove these parameters from cross-site, top-level navigations.
::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 =====
An exception is made for URL decoration that is used for the following purposes:
 
* Attribution, specifically where URL decoration is not user-specific and Mozilla is confident that it cannot be used to enable tracking.
 
* Cross-site login or authorization, where URL decoration might identify a user, but is explicitly part of actions deliberately requested by the user (i.e., where the decoration is required to fulfill the user’s request, rather than just carrying unnecessary information).
 
* Form submission, or other actions where the URL decoration contains information that is the direct result of user choice.
 
These exceptions might be temporary. As alternative approaches for use cases are developed that do not rely on URL decoration, Firefox might implement additional restrictions on the use of URL decoration. Firefox might also offer options that allow users to further limit URL decoration.
 
This policy might be amended in future to include stricter rules.
 
===== 3. 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:
'''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:


Line 36: Line 46:
* '''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.
* '''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.


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.
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.


== Policy circumvention ==
== Policy circumvention ==
Line 42: Line 52:


== Policy Exceptions ==
== Policy Exceptions ==
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:
We will block the practices described above when the party using them is classified as a tracker. We [https://wiki.mozilla.org/index.php?title=Security/Anti_tracking_policy&diff=1214837&oldid=1214836#Policy_Exceptions previously offered] a set of exceptions independent from tracker classification, but as of July 9, 2019 we will no longer grant new exceptions. We will stop honoring the current set of exceptions in a future version of Firefox.
 
== Temporary Web Compatibility Interventions ==


# 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.
If we discover breakage that we'd like to fix through Firefox code changes, we may temporarily disable a protection for the relevant domains while we work on the fixes. To prevent these from becoming permanent exceptions, a deadline must be provided by the engineer at the time of unblocking, with a maximum deadline of 18 months. We may alternatively unblock domains for up to 6 months when we are working in collaboration with the impacted site or party to fix website breakage. These interventions are tracked in [https://bugzilla.mozilla.org/show_bug.cgi?id=1537702 Bug 1537702].
# 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 [mailto:antitracking-policy@mozilla.com antitracking-policy@mozilla.com].
Questions about this policy should be directed to [mailto:antitracking-policy@mozilla.com antitracking-policy@mozilla.com].
Mthomson
Confirmed users
23

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1206791...1244096"