*Summary*: With Enhanced Tracking Protection gradually rolling out to our users on the release channel, we are limiting the ability of third-party trackers to store unique client identifiers on the user's device in order to capture a history of their browsing across different sites. However we are still leaking important browsing history data to these trackers in the Referer header, which may still be tied to the user through identifiers such as the IP address which may be stable for some users. It is well known that the Referer header can contain a lot of sensitive information such as the user's search query, their user ID on various sites, and so on.
In 2017 we did a study < https://blog.mozilla.org/data/2018/01/26/improving-privacy-without-breaking-the-web/> on measuring the breakage impact of a number of privacy features including limiting the Referer data sent to third-parties to origin only, and discovered very low breakage impact from doing so. Since then, we have modified the default referrer policy for all third-parties in private browsing mode with great results in terms of web compatibility. This intent is sent to experiment with applying the same idea to third-party tracking resources when Enhanced Tracking Protection is turned on, through setting a default referrer policy of strict-origin-when-cross-origin on them. We'd like to get some early testing by enabling this feature on the Nightly channel in the next cycle. *Bug*: This feature landed in https://bugzilla.mozilla.org/show_bug.cgi?id=1530076, and https://bugzilla.mozilla.org/show_bug.cgi?id=1533763 has been filed to enable it on Nightly. The intention is to enable it on normal windows, since in private windows all third-party content already has this restriction applied to it. *Link to standard*: https://github.com/whatwg/fetch/issues/879 *Platform coverage*: Everywhere. *Estimated or target release*: It is unclear as of yet, we are still in early exploration phase for this feature, *Preference behind which this will be implemented*: network.http.referer.defaultPolicy.trackers and network.http.referer.defaultPolicy.trackers.pbmode, available for testing in Nightly right now. I'm proposing to set the value of the former pref to 2 on Nightly. *Is this feature enabled by default in sandboxed iframes?* If not, is there a proposed sandbox flag to enable it? If allowed, does it preserve the current i Please link to the test suite. If any part of the feature is not tested by web-platform-tests, please include links to one or more of: - A web-platform-tests issue explaining why a certain thing cannot be tested (example <https://github.com/w3c/web-platform-tests/issues/3867>). - A spec issue for some change that would make it possible to test ( example <https://github.com/whatwg/fullscreen/issues/70>). - A Bugzilla bug for the creating web-platform-tests. nvariants in terms of what sandboxed iframes can do? I'm proposing to enable this feature in sandboxed iframes by default. It will preserve the current invariants. *DevTools bug*: No specific bug, since devtools already supports showing the referrer policy applied to each network resource in the network monitor, as well as the individual Referer headers sent alongside each request, of course. *Do other browser engines implement this?* Safari shipped this for origins with tracking capabilities since some point last year with their ITP 2.0 release (https://webkit.org/blog/8311/intelligent-tracking-prevention-2-0/). Firefox has shipped this for third-party origins in private windows since Firefox 59. *web-platform-tests*: https://bugzilla.mozilla.org/show_bug.cgi?id=1533825 is filed to track adding them. *Is this feature restricted to secure contexts?* It's not. This intervention is performed for protecting the user's privacy and the same argument applies for non-secure contexts as well. Also, Referer headers sent over non-secure contexts would be visible to network MITM attackers so arguably protecting them is even more valuable than protecting the secure context ones. Please let me know if you have any questions or concerns. Cheers, -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
