Apologies, this was the outcome of a poor FastMail mobile UI interaction.
On Fri, Mar 8, 2019, at 9:48 AM, z...@falconsigh.net wrote: > > > On Fri, Mar 8, 2019, at 1:31 AM, Ehsan Akhgari wrote: > > *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 > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
