*Summary*: As part of the anti-tracking project, we'd like to experiment with a new feature in order to mitigate the impact of third-party tracking scripts running in top-level documents. As we are planning to start removing the storage capabilities of third-party trackers, which removes their ability to store unique identifiers for each client in cookies which would be transmitted to servers across websites, a number of cross-site trackers have started to switch to using first-party cookies to store their unique identifiers. The way that this works typically is through annotating outbound links to the target website with a unique query string parameter, and then reading and storing that unique parameter in the first-party cookie storage through the third-party scripts that they control which are running in the context of the top-level target site when the user follows such a link.
This is bad because it would allow cross-site trackers to keep tracking the user through a unique identifier, but it would also expose the unique identifier used by tracker1 to all of the other trackers that have active code running on the page, which would allow them to sync up each others' tracking identifiers without resorting to practices such as cookie syncing < https://clearcode.cc/blog/cookie-syncing/>. We'd like to experiment with imposing a short maximum life-time on cookies set through document.cookie in order to ensure that these unique identifiers would expire relatively quickly once they are established, and wouldn't allow cross-site trackers to establish a pervasive permanent unique identifier. We're picking seven days to be compatible with Safari which has been shipping this for a while now < https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/>. *Bug*: This was implemented originally in (disabled by default) https://bugzilla.mozilla.org/show_bug.cgi?id=1529836. The bug to enable this on Nightly is https://bugzilla.mozilla.org/show_bug.cgi?id=1533584. *Link to standard*: No public standard change has been made for this feature yet. We should modify the cookie RFC when we know more about whether we would like to ship this change or not given that we would be the second web engine doing so. *Platform coverage*: where will this be available? Everywhere. *Estimated or target release*: in which version do you want to/plan to release this? Getting enabled in Nightly in 67, staying Nightly only for now in order to collect some early feedback. No estimated target release available yet since this is an early exploration. *Preference behind which this will be implemented*: if applicable, how can interested parties test this before it ships pref'd on by default? The preference for this feature, available in Nightly right now, is privacy.documentCookies.maxage. The value of this pref is the maximum life-time cap in seconds. A value of 0 would disable enforcing a cap (0 is the current default.) *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 invariants 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 expiry date of cookies and once this feature gets enabled it will correctly display the expiry date for those cookies where Firefox would enforce this cap on. *Do other browser engines implement this?* Answer with: Safari shipped (since version 12.0.x, tested in 12.0.3, announced as part of ITP 2.1 recently: <https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/ >). *web-platform-tests*: This is an intervention which different engines do not agree on yet. Creating a web-platform-test for it would be very simple but it will be failing in the engines that do not agree with the intervention. I'm not sure what the recommendation for testing these types of changes is, would be happy to submit a test if there is a path for getting them accepted into wpt. *Is this feature restricted to secure contexts?* It is not. This is an intervention which is trying to protect the user's privacy, and we would like to ensure the protections would be applicable to non-secure contexts as well. Arguably these protections are even more important for non-secure contexts given the fact that cookies set through document.cookie would be visible to network MITM attackers after that point. Here are the answers to a few other questions which you may have on your mind regarding this proposed change. *Would this change cause people to get logged out of services?* We believe the answer to that should be no, at least for services with secure logins. Authentication cookies should be marked as Secure and HttpOnly, and if they're set through document.cookie they can't be HttpOnly by default and are therefore vulnerable to XSS attacks. Therefore we hope that most services people log in to would already set their authentication cookies through a secure HTTP response and would therefore be unaffected. *Would this change cause people to see more EU cookie dialogs?* Potentially, yes. We've looked at a few such sites which show such banners to see how they remember that the user has dismissed the dialog. Many of them seem to set a cookie on an HTTP response so should be unaffected by this change. Some, however, do set a cookie using document.cookie and would therefore be probably affected, but it's unclear how widespread this problem would be. One of the reasons for enabling this feature on Nightly is to get some early feedback on qualitative issues like this. Please let me know if you have any questions or concerns. Thanks, -- Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
