Intent to Deprecate and Remove: Insecure SameSite=None cookies

[Lily Chen]

Contact emails

chl...@chromium.org, morl...@chromium.org, mk...@chromium.org 

Explainer

https://tools.ietf.org/html/draft-west-cookie-incrementalism-00

https://web.dev/samesite-cookies-explained

Design doc/Spec

See spec changes proposed in explainer.

TAG review request.

Summary

Deprecate and remove the use of cookies with the SameSite=None attribute but without the Secure attribute. Any cookie that requests SameSite=None but is not marked Secure will be rejected.

Motivation

Cookies delivered over plaintext channels may be cataloged or modified by network attackers. Requiring secure transport for cookies intended for cross-site usage reduces this risk, and encourages entities that produce embeddable content to migrate to HTTPS.

The use of non-Secure cookies facilitates pervasive monitoring, a widespread attack on users’ privacy. This change will mitigate the risks presented by pervasive monitoring by curtailing the use of non-Secure third-party cookies. Third-party cookies are widely used for tracking and may contain sensitive data that pertains to user identity. Cookies with SameSite=None are specifically marked for use in third-party contexts. By requiring SameSite=None cookies to be Secure, users are protected by default from attacks on their identifying data that may compromise their privacy.

In addition, non-secure embeds are a risk to users’ privacy and security. The use of non-secure embeds degrades users’ security and user experience on first-party sites by hampering first-party upgrades to secure transport because of limitations imposed on mixed content. The use of HTTPS protects users and sites, and the presence of mixed embedded content downgrades its security benefits. Requiring Secure for SameSite=None cookies will increase the security of the web by encouraging embeddable content producers to migrate to HTTPS.

Interoperability and Compatibility Risk

Some sites relying on third-party cookies may break temporarily until developers add “Secure” to any “SameSite=None” cookies they set. If a third-party service is not delivered over HTTPS, it will have to migrate to secure transport in order to use third-party cookies.

Cookies intended for use solely in first-party contexts (which have no need to be marked “SameSite=None”) will not be affected.

Edge: No signals

Firefox: In development

Safari: No signals

Web / Framework developers: Neutral to positive

Alternative implementation suggestion for web developers

Add “Secure” to any “SameSite=None” cookies (and migrate to HTTPS if necessary).

A temporary enterprise policy escape hatch will be added to allow enterprise admins to opt-in to the legacy SameSite behavior (i.e. the status quo SameSite behavior from before “SameSite by default cookies” or this change).

Usage information from UseCounter

Adoption of SameSite=None is still ramping up, but currently UseCounter indicates that insecure SameSite=None cookies appear on 19% of PageVisits. This figure has been growing rapidly.

Data from HTTP Archive also shows some usage of SameSite=None without Secure. (We will update the thread with more current data once it is available, since HTTP Archive data lags by about 3 weeks.)

Debuggability

DevTools shows the SameSite and Secure attributes for stored cookies under Application>Storage>Cookies. Cookies that are blocked from being set will not appear here. Cookies blocked from being sent will appear here but will be absent from the request headers shown in the Network tab. DevTools console messaging for cookies blocked, either due to “SameSite by default cookies” or the proposed change, is available behind the flag #cookie-deprecation-messages.

Is this feature fully tested by web-platform-tests?

WPTs are merged upstream. With the addition of “SameSite by default cookies” and this change to the set of features enabled with --enable-experimental-web-platform-features, there is now WPT coverage for this feature by default (without a virtual test suite).

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5633521622188032

Requesting approval to remove too?

Yes; the removal is currently implemented behind the flag #cookies-without-same-site-must-be-secure. Target milestone for removal is M80.

[Yoav Weiss]

19% is surprisingly high... :/ 

Do you have any ideas as to who those users are?

Is this the relevant UseCounter? It's rather interesting that the related HA data shows 0 adopters.

Data from HTTP Archive also shows some usage of SameSite=None without Secure. (We will update the thread with more current data once it is available, since HTTP Archive data lags by about 3 weeks.)

Debuggability

DevTools shows the SameSite and Secure attributes for stored cookies under Application>Storage>Cookies. Cookies that are blocked from being set will not appear here. Cookies blocked from being sent will appear here but will be absent from the request headers shown in the Network tab. DevTools console messaging for cookies blocked, either due to “SameSite by default cookies” or the proposed change, is available behind the flag #cookie-deprecation-messages.

Is this feature fully tested by web-platform-tests?

WPTs are merged upstream. With the addition of “SameSite by default cookies” and this change to the set of features enabled with --enable-experimental-web-platform-features, there is now WPT coverage for this feature by default (without a virtual test suite).

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/5633521622188032

Requesting approval to remove too?

Yes; the removal is currently implemented behind the flag #cookies-without-same-site-must-be-secure. Target milestone for removal is M80.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24OxzwBG3mTvZfY%3DY3mPbdRUNwukweawGhZ5GOnXw7LQNxAA%40mail.gmail.com.

[Lily Chen]

Yes, CookieInsecureAndSameSiteNone is the relevant UseCounter. I was looking at the stats on UMA, where it seems the numbers are a tad lower than on the chromestatus view.

We are hoping to get a better sense of what kinds of requests carry SameSite=None but insecure cookies when the next batch of HTTP Archive data comes out by manually looking at some of the URLs.

Based on UseCounter UKM data, it looks like the top 100 sites account for 9% of page visits with insecure SameSite=None cookies in a third party context, so there's a pretty diverse set of sites. Interestingly, the vast majority of these page visits are to https origins (top level site).

[Yoav Weiss]

On Tue, Aug 13, 2019 at 6:35 PM Lily Chen <chl...@chromium.org> wrote:

Yes, CookieInsecureAndSameSiteNone is the relevant UseCounter. I was looking at the stats on UMA, where it seems the numbers are a tad lower than on the chromestatus view.

We are hoping to get a better sense of what kinds of requests carry SameSite=None but insecure cookies when the next batch of HTTP Archive data comes out by manually looking at some of the URLs.

Based on UseCounter UKM data, it looks like the top 100 sites account for 9% of page visits with insecure SameSite=None cookies in a third party context, so there's a pretty diverse set of sites. Interestingly, the vast majority of these page visits are to https origins (top level site).

Might be helpful to deep dive into those sites to see if it's a narrower list of third parties.

[Alex Russell]

Per conversation at today's API OWNERS meeting, want to second diving into the UKM results. Very curious to know what we turn up and if that will allow us to solve some of these with targeted outreach.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

[Lily Chen]

We crawled the top 500 URLs with at least 50 client ids in the UKM data consisting of pages where CookieInsecureAndSameSiteNone occurred. We encountered insecure SameSite=None cookies from ~100 distinct origins representing ~50 eTLD+1's. The top eTLD+1 accounted for 25% of insecure SameSite=None cookies (not weighted by page popularity), and the top 6 accounted for 75%.

We are looking into targeted outreach to these domains.

[Lily Chen]

Also, among these cookies, 97% were from https origins.

[Yoav Weiss]

Oh, so these are SameSite cookies sent by HTTPS origin 3rd parties to non-secure context documents?

That changes the picture!

In this case, what's the expected behavior we want to see? 

I guess it's easier for those 3rd parties to send SameSite cookies to all their users (secure and non-secure contexts alike). But we want to clarify to their non-secure context users that they won't get the benefits of the opt-in.

Would the above be a correct characterization?

IIUC, this removal will also not result in direct breakage, at least up until SameSite=None cookies become mandatory for 3rd party cookies. Is that accurate? 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24Oxzn1b0owbG8-AxN8DrYbJe913DfAq8tS9wAz_8iXXerFQ%40mail.gmail.com.

[Lily Chen]

An overwhelming majority of the first party pages we examined were on https origins, and 97% of navigations to the examined set of URLs in the data set were over https. (Unfortunately I don't have data on how many 1st/3rd party pairs were https-https vs http-https, http-http, etc., but I could collect that data if it's of interest.)

Most 3rd party sites only had SameSite=None cookies over https (for which adding "Secure" should not change anything), but there were a number of 3rd parties sending SameSite=None cookies over both https and http. We'd like to see those 3rd parties add "Secure" to their set-cookie lines, so that those cookies can only be sent over https. This should affect only a small percentage of requests and for the majority of SameSite=None cookies this should not change anything.

The current setup is that the proposed deprecation is gated behind the "SameSite=Lax by default" feature, i.e. the feature flag for the former doesn't do anything if the latter is not enabled. We thought this would make sense as SameSite=None doesn't really do anything until the default is SameSite=Lax. So we would like to launch both together if possible.

[Rick Byers]

The API owners just met to analyze the compat trade-off argument of this in conjunction with the SameSite=None intent. LGTM1 with the same overall reasoning.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24Oxx3Qvco90AYkRfy1ov-WUgebARKmAKBLa6xsTb8mojyvg%40mail.gmail.com.

[Yoav Weiss]

LGTM2

[Daniel Bratell]

LGTM3

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgEEF5TcrU2arBvjiXb4%3DivO-KxXX-sAkemxpZynzOL7w%40mail.gmail.com.