Intent to Deprecate and Remove: Insecure SameSite=None cookies

703 wyświetlenia
Przejdź do pierwszej nieodczytanej wiadomości

Lily Chen

nieprzeczytany,
12 sie 2019, 14:24:5412.08.2019
do blink-dev, morl...@chromium.org, Mike West

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

nieprzeczytany,
13 sie 2019, 03:03:2613.08.2019
do Lily Chen, blink-dev, morl...@chromium.org, Mike West
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

nieprzeczytany,
13 sie 2019, 12:35:3913.08.2019
do Yoav Weiss, Lily Chen, blink-dev, morl...@chromium.org, Mike West
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

nieprzeczytany,
14 sie 2019, 02:08:3214.08.2019
do Lily Chen, blink-dev, morl...@chromium.org, Mike West
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

nieprzeczytany,
15 sie 2019, 15:21:1615.08.2019
do blink-dev, chl...@chromium.org, morl...@chromium.org, mk...@chromium.org
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

nieprzeczytany,
16 sie 2019, 15:04:3116.08.2019
do Alex Russell, blink-dev, Lily Chen, morl...@chromium.org, Mike West
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

nieprzeczytany,
16 sie 2019, 15:11:2116.08.2019
do Lily Chen, Alex Russell, blink-dev, morl...@chromium.org, Mike West
Also, among these cookies, 97% were from https origins.

Yoav Weiss

nieprzeczytany,
19 sie 2019, 02:14:5519.08.2019
do Lily Chen, Alex Russell, blink-dev, morl...@chromium.org, Mike West
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

nieprzeczytany,
19 sie 2019, 10:59:3119.08.2019
do Yoav Weiss, Lily Chen, Alex Russell, blink-dev, morl...@chromium.org, Mike West
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

nieprzeczytany,
23 sty 2020, 15:48:1123.01.2020
do Lily Chen, Yoav Weiss, Alex Russell, blink-dev, morl...@chromium.org, Mike West
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.

Yoav Weiss

nieprzeczytany,
23 sty 2020, 15:51:5723.01.2020
do Rick Byers, Lily Chen, Alex Russell, blink-dev, morl...@chromium.org, Mike West
LGTM2

Daniel Bratell

nieprzeczytany,
23 sty 2020, 16:09:5823.01.2020
do Yoav Weiss, Rick Byers, Lily Chen, Alex Russell, blink-dev, morl...@chromium.org, Mike West
Odpowiedz wszystkim
Odpowiedz autorowi
Przekaż dalej
Nowe wiadomości: 0