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
