Intent to Implement and Ship: Cookies with SameSite by default

14746 views
Skip to first unread message

Lily Chen

unread,
May 24, 2019, 12:15:19 PM5/24/19
to blin...@chromium.org, morl...@chromium.org, mk...@chromium.org

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

Treat cookies as SameSite=Lax by default if no SameSite attribute is specified. Developers would be able to opt-into the status quo of unrestricted use by explicitly asserting SameSite=None.


Motivation

“SameSite” is a reasonably robust defense against some classes of cross-site request forgery (CSRF) attacks, but developers currently need to opt-into its protections by specifying a SameSite attribute, i.e., developers are vulnerable to CSRF attacks by default. This change would allow developers to be protected by default, while allowing sites that require state in cross-site requests to opt-in to the status quo’s less-secure model. In addition, forcing sites to opt-in to SameSite=None gives the user agent the ability to provide users more transparency and control over tracking.


Risks

Interoperability and Compatibility

Some sites relying on third-party cookies may break temporarily until developers add “SameSite=None”. Most browsers (except for Safari; bug filed here) that do not yet support SameSite=None should just ignore that attribute and apply the status quo default of “no restriction”, which has the same effect as SameSite=None.


Edge: Public support

Firefox: In development

Safari: No signals

Web / Framework developers: Neutral to positive


Activation

No explicit activation is required.


Debuggability

DevTools shows that SameSite is “None” for SameSite=None cookies under Application>Storage>Cookies, and default cookies (which don’t specify SameSite) show up as blank. Adding DevTools console messaging for cookies that would be affected by these SameSite restrictions is in progress.


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.


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

Tentative WPTs have been merged upstream.


Link to entry on the feature dashboard

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


Requesting approval to ship?

Yes; it is currently implemented behind the flag same-site-by-default-cookies. We aim to begin shipping this in M77. We may choose to do so in an incremental fashion, ramping up the % deployment as developers shift their cookies.

Philip Jägenstedt

unread,
May 28, 2019, 8:27:04 AM5/28/19
to Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
Hi Lily,

The motivation for this is very clear, and changing the default to be more secure by default makes sense. And https://web.dev/samesite-cookies-explained is a great read, kudos to the author +Rowan Merewood.

Where I think some more research might be needed is on the compatibility side. Do we have any metrics about how many cookies won't be delivered that currently are? Is it possible to test/predict/guess how many of those cookies are actually used?

That some sites will be affected seems certain, and https://web.dev/samesite-cookies-explained#what-should-i-do-to-enable-samesite-today has good guidance. However, the fixes are recent and upgrading your whole language runtime a large undertaking, so many will probably need to "fall back to specifying the Set-Cookie header directly" which might clobber cookies from other parts of the codebase. I wonder if you've thought about some other simpler and risk-free opt-out mechanism that people could throw on while they're dealing with this transition?

--
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/CAE24OxxMmaALEVP4xPm-Weemzkx%3DAEB%3DiowQ2vTxztz%3DzvjJzg%40mail.gmail.com.

Lily Chen

unread,
May 28, 2019, 10:24:42 AM5/28/19
to Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
We unfortunately don't have metrics at this time on how many cookies would be affected, though we are looking at collecting relevant metrics. As an upper bound, UMA metrics for Cookie.Type show that over 99.8% of cookies don't specify any SameSite attribute. It's unclear how many of those are delivered cross-site.

Is there an alternate opt-out mechanism you had in mind?

Philip Jägenstedt

unread,
May 28, 2019, 10:53:56 AM5/28/19
to Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
Is it straightforward to measure how often cookies that didn't have a SameSite attribute are delivered cross-site? Whatever the number is, it's probably high enough that if all of them were breaking this change wouldn't be possible to roll out. In other words, some other type of analysis seems necessary to gauge the risk of this. Maybe:
  • Have volunteers run with the flag enabled for a week and report if anything breaks.
  • Use HTTP Archive data to find the most common cross-origin resources, and for the top 50 or so manually look at sites using those resources to evaluate how they'd be affected by this change.
For a simpler opt-out mechanism, another header is what comes to mind, but ideally this would be informed by someone who's facing breakage and is unable to set the SameSite=None attribute. Do we already know a few sites that will be affected that we could consult?

Rick Byers

unread,
May 28, 2019, 11:22:52 AM5/28/19
to Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West, Brandon Heenan
I'm excited to see this work progressing, and (although it will likely be painful) am optimistic that we will develop a reasonable plan for making this breaking change. But I agree with Philip that it's going to be a significant breaking change for some developers (who either aren't aware of the need to change their cookie headers, or don't have an easy way to do so via their workflow). And so we're probably going to need a more detailed compat analysis and risk mitigation plan before API owners can approve the breaking change (eg. see bit.ly/blink-compat for the sorts of things we tend to do for significant breaking changes like this).

In particular, with SameSite=none being treated as SameSite=strict on Safari right now, it seems there's really no reasonable developer guidance at the moment (making your behavior conditional on the UserAgent string is not something I think we want to do). This might be a severe enough issue to justify some change to the syntax (eg. prefer some new token like 'CrossSite=allowed' instead of re-using 'SameSite'?). I know that's ugly and adds complexity, but it's the sort of pragmatic compromise we often have to make when we learn of bugs in major deployed browsers.

Also we know this is going to pose particular problems for enterprises, so I think we're going to want to work with the Chrome enterprise folks (/cc bheenan@). At a minimum I expect we'll need some enterprise policy config to disable this for specific intranet sites and some outreach to ensure enterprises have time to deploy and test the config.

In terms of quantifying the compat risk, I think our best signal is probably to look at usage of third party cookie blocking today. Any site broken by this SameSite change will already be broken by Chrome's existing 3p cookie blocking feature, right? Conversely we can assume that sites broken by 3p cookie blocking which aren't explicitly opting-into the new SameSite=none will also be broken by this change, right? Perhaps we can do some analysis of how many users are using 3p cookie blocking today what exceptions they (in aggregated/anonymous form of course) tend to have set? Then we could do targeted outreach to the domains which are popular exceptions. I know much of the mainstream web already works more-or-less fine with 3p cookie blocking, but there are lots of examples in the longer tail that does not.
 
Rick

Brandon Heenan

unread,
May 28, 2019, 3:57:58 PM5/28/19
to Rick Byers, Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
Thanks for looping me in. As Rick mentioned, the best way to ship this while minimizing pain to enterprises is to include a policy that allows IT admins to revert to the old behavior if they end up being surprised by it. That policy can later be taken out after we've provided a reasonable amount of time to react to the change. It could either be a binary switch that completely reverts the update for that organization, or a list of sites to use the old behavior on.

We may also want to put these in the enterprise release notes to give admins a heads up that it's happening before it ships. Who should I work with to craft those?

FYI, there's more details on these recommendations here: https://www.chromium.org/developers/enterprise-changes

Lily Chen

unread,
May 28, 2019, 6:07:00 PM5/28/19
to Brandon Heenan, Vivek Sekhar, Rick Byers, Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
Thanks for the comments. We are working on on formulating a compat plan to address the issues raised. In terms of quantifying cookies that don't specify SameSite that are accessed in a cross-site context, we are currently working on adding console messages informing developers of cookies that would be affected and we plan to log metrics along the way. That would count the number of potentially affected cookies, but wouldn't necessarily tell us anything about which cookies would be site-breaking. We don't currently have any data on what sites would be broken by this change.

We may also want to put these in the enterprise release notes to give admins a heads up that it's happening before it ships. Who should I work with to craft those?
 
+Vivek Sekhar, I think?

Vivek Sekhar

unread,
May 28, 2019, 8:50:33 PM5/28/19
to Lily Chen, Brandon Heenan, Rick Byers, Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
Happy to help with enterprise comms language.

Starting points: blog post, web.dev documentation.
--

Vivek | Sekhar | Product Manager | vse...@google.com

Brandon Heenan

unread,
May 29, 2019, 10:45:37 AM5/29/19
to Vivek Sekhar, Lily Chen, Rick Byers, Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
Thanks Vivek, I'll reach out when we're writing up the next set

Yoav Weiss

unread,
Jun 13, 2019, 7:32:26 PM6/13/19
to Rick Byers, Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West, Brandon Heenan
On Tue, May 28, 2019 at 8:22 AM Rick Byers <rby...@chromium.org> wrote:
I'm excited to see this work progressing, and (although it will likely be painful) am optimistic that we will develop a reasonable plan for making this breaking change. But I agree with Philip that it's going to be a significant breaking change for some developers (who either aren't aware of the need to change their cookie headers, or don't have an easy way to do so via their workflow). And so we're probably going to need a more detailed compat analysis and risk mitigation plan before API owners can approve the breaking change (eg. see bit.ly/blink-compat for the sorts of things we tend to do for significant breaking changes like this).

In particular, with SameSite=none being treated as SameSite=strict on Safari right now, it seems there's really no reasonable developer guidance at the moment (making your behavior conditional on the UserAgent string is not something I think we want to do). This might be a severe enough issue to justify some change to the syntax (eg. prefer some new token like 'CrossSite=allowed' instead of re-using 'SameSite'?). I know that's ugly and adds complexity, but it's the sort of pragmatic compromise we often have to make when we learn of bugs in major deployed browsers.

Talking to folks, this seems like an issue in iOS/OSX network stacks, which make me skeptical those users will go away anytime soon.
Have we considered a rename to the header as Rick suggested?

I also saw that there's desire to add deprecation messages to notify developers that they'd need to make changes to their third party cookies.
Would be good to know what we can ship and when before those messages are finalized and put in front of users.
 

Lily Chen

unread,
Jun 25, 2019, 11:28:48 AM6/25/19
to Yoav Weiss, Rick Byers, Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West, Brandon Heenan
We are pushing back the target milestone to M80 due to interoperability concerns resulting from an issue affecting Safari on Mac/iOS and Chrome on iOS: Cookies with an unrecognized SameSite value, including SameSite=None, are handled incorrectly and are treated as SameSite=Strict. We decided not to rename SameSite=None to a different attribute because the issue is fixed in iOS 13 and we think that delaying while the fix rolls out is a better approach than the longer adoption time for a new attribute.

The console messages informing developers of the changes have been implemented behind a default-disabled flag and currently do not state a specific milestone.

Yoav Weiss

unread,
Jul 4, 2019, 2:57:33 AM7/4/19
to Lily Chen, Rick Byers, Philip Jägenstedt, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West, Brandon Heenan
Do you have any data on how many iOS<13 users developers should expect to have after the fix would be rolled out? (I'm guessing not all users upgrade immediately)

Lily Chen

unread,
Jul 8, 2019, 1:31:48 PM7/8/19
to Yoav Weiss, Lily Chen, Rick Byers, Philip Jägenstedt, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West, Brandon Heenan
I am not sure to quantify that directly, but a lower bound is devices that will not receive the iOS 13 update, such as the iPhone 6 (3.41% of mobile users), iPhone 5S (1.27%), iPhone 6 Plus (0.75%), iPhone 5 (0.42%), and anything older. At present, iOS 12 adoption is at 92%. iOS 12 adoption reached 80% within 3 months of release.

Jeffrey Yasskin

unread,
Jul 8, 2019, 1:55:16 PM7/8/19
to Lily Chen, Yoav Weiss, Rick Byers, Philip Jägenstedt, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West, Brandon Heenan
Is there also a fixed MacOS version rolling out?

Thanks,
Jeffrey

Lily Chen

unread,
Jul 8, 2019, 2:00:06 PM7/8/19
to Jeffrey Yasskin, Lily Chen, Yoav Weiss, Rick Byers, Philip Jägenstedt, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West, Brandon Heenan
Looks like it is fixed in MacOS 10.15.

Brandon Heenan

unread,
Jul 16, 2019, 11:58:51 AM7/16/19
to Vivek Sekhar, Lily Chen, Rick Byers, Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
Hey Vivek, can you please add a small paragraph to the enterprise release notes here?

On Tue, May 28, 2019 at 6:12 PM Vivek Sekhar <vse...@google.com> wrote:

Chris Harrelson

unread,
Jul 18, 2019, 3:18:51 PM7/18/19
to Brandon Heenan, Vivek Sekhar, Lily Chen, Rick Byers, Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
Quick update regarding status of this intent: the API owners just met. Given the comment about M80, we'll consider this intent withdrawn for now. I'd also like to note that we don't see data that resolves the questions raised earlier about why this change would be web compatible. When coming back with a revised intent later, I think that data will be necessary.

Lily Chen

unread,
Jul 18, 2019, 7:46:15 PM7/18/19
to Chris Harrelson, Brandon Heenan, Vivek Sekhar, Rick Byers, Philip Jägenstedt, Lily Chen, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West

Apologies for the delay. At this point we still fully intend to implement and ship this feature, but if you would prefer, we can start a new thread at some later point.


We’ve been able to collect some data to quantify the compatibility/interoperability risks of launching this feature.


Tl;dr: We believe that this feature will not cause an unacceptable amount of breakage. The majority of the impact will be borne by a relatively small number of sites. The fix for SameSite=None on Safari/iOS should be rolled out in time for the proposed launch of this feature in M80.


We would also like to reiterate that there are security benefits to this feature, so while it might break some sites, it might also protect some sites from e.g. CSRF attacks.


A temporary escape-hatch enterprise policy will allow administrators to opt out of this feature and revert to the legacy behavior.


Compatibility:


Data from Cookiepedia (which maintains a database of 9M cookies) suggests that roughly 2/3 of all cookies are 3p cookies. Following Philip’s suggestion, we examined public data from HTTP Archive to see which sites have the most 3p cookies (by the number of “Cookie” headers sent to hosts other than the parent host of the page). The results show that only 25 sites by eTLD+1 account for roughly 50% of the 3p cookies in the data set. This suggests that the majority of the change in behavior would affect only a small number of sites. (One caveat is that this data may not be representative of the web as a whole since HTTP Archive only examines the landing page of each site, and the data is not weighted by site traffic.) Data from HTTP Archive can also be used to determine the percentage of 3p cookies already setting “SameSite=None”, but this is likely to be changing rapidly so we will update the thread with more recent data once it is available.


We also analyzed anonymized data from users who have turned on the existing 3p cookie blocking feature, as Rick suggested. The metric “Privacy.ThirdPartyCookieBlockingSetting” measures the percentage of UMA-reporting users who have the 3p cookie blocking setting turned on at profile startup. This metric indicates that 2% of unique clients have 3p cookie blocking enabled. (This is likely an underestimate because more privacy-sensitive users may be less likely to report to UMA.) The exceptions they have set in their preferences to allow 3p cookies on specific sites may indicate the sites most likely to cause breakage if their cookies are blocked. Only roughly 35% of users who block 3p cookies have at least one exception set, which may suggest that the majority of 3p cookie blocking users do not need exceptions to browse the web normally. The exceptions (which include wildcard patterns) span 13k distinct eTLD+1’s. The top 75 sites by eTLD+1 account for roughly 50% of the exceptions in the data set.


3p access of cookies without a SameSite attribute is logged by a UseCounter to directly measure page views with cookies that are currently allowed but would be blocked by this feature. The resulting data indicates that about 45% of page visits result in sending or receiving a 3p cookie without a SameSite attribute. Based on the exceptions data above, however, we believe that blocking these cookies would not cause too much user-visible breakage. Anonymized and aggregated data keyed by top-level URL is also being collected, so it is possible to reach out to individual sites on which many 3p cookies would be blocked.


Interoperability:


We have been closely following the issue affecting Safari on Mac/iOS and Chrome on iOS causing SameSite=None to be treated as SameSite=Strict. Testing indicates that the bug is fixed in iOS 13 and macOS 10.15, which will both be released this fall.


Timeseries UMA data bucketed by iOS version can provide a rough estimate of iOS update rates among UMA-reporting Chrome users. For example, the total count of the metric “IOS.CommittedURLMatchesCurrentItem” (which measures navigations on iOS), when filtered to count unique clients, shows that the rollout of iOS version 12.3.1 reaches a plateau within roughly 30 days from release. This is likely to be an underestimate for a major version update to iOS 13, but it suggests that the fix is likely to be rolled out over the course of a few months (iOS 12 adoption reached 80% within 3 months), in time for the proposed launch of this feature in M80.


This still leaves devices older than the iPhone 6S, which will not receive the iOS 13 update. A 2019 web traffic analysis indicates that such devices comprise only a small percentage of mobile web users. The iPhone 6 and the iPhone 5S are the two devices with the highest market share among iPhones, and represent only 3.41% and 1.27% of mobile users in the sampled web traffic, respectively.


MacOS 10.14 currently accounts for 47% of desktop macOS market share worldwide. Based on historical adoption rates of macOS updates, we can expect about 40% of macOS users to have updated to 10.15 by the time of M80 stable release.


A backport of the fix on both iOS and macOS is under consideration.

Yoav Weiss

unread,
Jul 19, 2019, 12:12:55 AM7/19/19
to Lily Chen, Chris Harrelson, Brandon Heenan, Vivek Sekhar, Rick Byers, Philip Jägenstedt, Rowan Merewood, blink-dev, morl...@chromium.org, Mike West
On Fri, Jul 19, 2019 at 1:46 AM Lily Chen <chl...@chromium.org> wrote:

Apologies for the delay. At this point we still fully intend to implement and ship this feature, but if you would prefer, we can start a new thread at some later point.


We’ve been able to collect some data to quantify the compatibility/interoperability risks of launching this feature.


Tl;dr: We believe that this feature will not cause an unacceptable amount of breakage. The majority of the impact will be borne by a relatively small number of sites. The fix for SameSite=None on Safari/iOS should be rolled out in time for the proposed launch of this feature in M80.


We would also like to reiterate that there are security benefits to this feature, so while it might break some sites, it might also protect some sites from e.g. CSRF attacks.


A temporary escape-hatch enterprise policy will allow administrators to opt out of this feature and revert to the legacy behavior.


Compatibility:


Data from Cookiepedia (which maintains a database of 9M cookies) suggests that roughly 2/3 of all cookies are 3p cookies. Following Philip’s suggestion, we examined public data from HTTP Archive to see which sites have the most 3p cookies (by the number of “Cookie” headers sent to hosts other than the parent host of the page). The results show that only 25 sites by eTLD+1 account for roughly 50% of the 3p cookies in the data set. This suggests that the majority of the change in behavior would affect only a small number of sites. (One caveat is that this data may not be representative of the web as a whole since HTTP Archive only examines the landing page of each site, and the data is not weighted by site traffic.) Data from HTTP Archive can also be used to determine the percentage of 3p cookies already setting “SameSite=None”, but this is likely to be changing rapidly so we will update the thread with more recent data once it is available.


We also analyzed anonymized data from users who have turned on the existing 3p cookie blocking feature, as Rick suggested. The metric “Privacy.ThirdPartyCookieBlockingSetting” measures the percentage of UMA-reporting users who have the 3p cookie blocking setting turned on at profile startup. This metric indicates that 2% of unique clients have 3p cookie blocking enabled. (This is likely an underestimate because more privacy-sensitive users may be less likely to report to UMA.) The exceptions they have set in their preferences to allow 3p cookies on specific sites may indicate the sites most likely to cause breakage if their cookies are blocked. Only roughly 35% of users who block 3p cookies have at least one exception set, which may suggest that the majority of 3p cookie blocking users do not need exceptions to browse the web normally. The exceptions (which include wildcard patterns) span 13k distinct eTLD+1’s. The top 75 sites by eTLD+1 account for roughly 50% of the exceptions in the data set.


3p access of cookies without a SameSite attribute is logged by a UseCounter to directly measure page views with cookies that are currently allowed but would be blocked by this feature. The resulting data indicates that about 45% of page visits result in sending or receiving a 3p cookie without a SameSite attribute. Based on the exceptions data above, however, we believe that blocking these cookies would not cause too much user-visible breakage. Anonymized and aggregated data keyed by top-level URL is also being collected, so it is possible to reach out to individual sites on which many 3p cookies would be blocked.


Interoperability:


We have been closely following the issue affecting Safari on Mac/iOS and Chrome on iOS causing SameSite=None to be treated as SameSite=Strict. Testing indicates that the bug is fixed in iOS 13 and macOS 10.15, which will both be released this fall.


Timeseries UMA data bucketed by iOS version can provide a rough estimate of iOS update rates among UMA-reporting Chrome users. For example, the total count of the metric “IOS.CommittedURLMatchesCurrentItem” (which measures navigations on iOS), when filtered to count unique clients, shows that the rollout of iOS version 12.3.1 reaches a plateau within roughly 30 days from release. This is likely to be an underestimate for a major version update to iOS 13, but it suggests that the fix is likely to be rolled out over the course of a few months (iOS 12 adoption reached 80% within 3 months), in time for the proposed launch of this feature in M80.


This still leaves devices older than the iPhone 6S, which will not receive the iOS 13 update. A 2019 web traffic analysis indicates that such devices comprise only a small percentage of mobile web users. The iPhone 6 and the iPhone 5S are the two devices with the highest market share among iPhones, and represent only 3.41% and 1.27% of mobile users in the sampled web traffic, respectively.


So, let's say that 5% of mobile users will have that issue after M80%. What are you expecting developers to do?
Should they be serving Same-Site=None headers conditionally, only to browsers that don't suffer from this issue? Suffer the compat hit on those 5% of users? Something else?
 

MacOS 10.14 currently accounts for 47% of desktop macOS market share worldwide. Based on historical adoption rates of macOS updates, we can expect about 40% of macOS users to have updated to 10.15 by the time of M80 stable release.


A backport of the fix on both iOS and macOS is under consideration.

That would change the equation significantly.
 

Erik Anderson

unread,
Jul 23, 2019, 7:05:06 PM7/23/19
to blink-dev, chl...@chromium.org, chri...@chromium.org, bhe...@google.com, vse...@google.com, rby...@chromium.org, foo...@chromium.org, mere...@google.com, morl...@chromium.org, mk...@chromium.org
Microsoft has been evaluating the effect of this change.

We love the intent and spirit of this change, but we fairly quickly determined that this breaks a large number of our sites leveraging Azure Active Directory (AAD) and Microsoft Account (MSA) authentication using the contract as defined here:

Also see https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-openid-connect-code.

Notably, the AAD recommendation has been to set response_mode to "form_post". Many of these applications are leveraging the nonce value as an anti-CSRF protection by setting a cookie on their own domain before redirecting to the auth provider's domain.

The flow that breaks is:
1. The site creates the CSRF token cookie without a SameSite attribute. With this change, it is now treated as lax.
2. Site does a redirect to the login provider, passing as part of the query string, response_mode=form_post&state=<token>
3. Login provider completes auth flow and initiates a POST back to the original site.
4. Since it's a lax cookie and the request mode is POST, the cookie is not sent.
5. Site checks CSRF token against the CSRF cookie dropped in step 1; since it's not present, it treats it as a failed login and attempts to log in again.

For many of these sites, the login retry logic means the user sees an auth loop with no clear indication of what happened.

This is not something that can be independently resolved by the AAD and MSA teams. It requires every existing client using the cookie-based CSRF check to also go in and update their logic to set SameSite=none on the appropriate cookies.

We suspect that other OpenID-based federated auth providers may have similar scenarios be broken, but we have not done an extensive manual test pass to try to identify them. Even if it is somehow scoped to Microsoft auth providers, it seems unrealistic to expect every one of their impacted, existing consumers to update.

Lily Chen

unread,
Jul 26, 2019, 1:29:26 PM7/26/19
to Erik Anderson, blink-dev, Lily Chen, Chris Harrelson, Brandon Heenan, Vivek Sekhar, Rick Byers, Philip Jägenstedt, Rowan Merewood, morl...@chromium.org, Mike West
Thanks for bringing up this issue, Erik.

We are considering allowing "Lax plus POST" as an intervention Chrome will perform for cookies defaulted to Lax in the absence of a SameSite attribute. We will write something up describing it more fully for comment.

--
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.

Lily Chen

unread,
Aug 1, 2019, 2:29:51 PM8/1/19
to Lily Chen, Erik Anderson, blink-dev, Chris Harrelson, Brandon Heenan, Vivek Sekhar, Rick Byers, Philip Jägenstedt, Rowan Merewood, morl...@chromium.org, Mike West
We plan to default to “Lax + POST” as a temporary intervention Chrome will perform for certain cookies defaulted to Lax in the absence of a SameSite attribute. Specifically, certain cookies that don’t specify SameSite and are defaulted into Lax will be sent with top-level navigations regardless of HTTP method (i.e. removing the restriction to “safe” methods applied to Lax cookies). This intervention will be restricted to session cookies (cookies that don’t specify an expiry time) that were set within the last 2 minutes, and persistent cookies whose max age (difference between creation time and expiry time) is at most 2 minutes.

This intervention aims to avoid breaking the auth flow described above while giving developers time to migrate their cookies to explicitly specifying SameSite.

Erik/Microsoft folks, do these session/expiry restrictions work for your use case?

Eric Lawrence

unread,
Aug 5, 2019, 10:56:08 AM8/5/19
to blink-dev, chl...@chromium.org, Erik.A...@microsoft.com, chri...@chromium.org, bhe...@google.com, vse...@google.com, rby...@chromium.org, foo...@chromium.org, mere...@google.com, morl...@chromium.org, mk...@chromium.org
Thanks, Lily. There are some concerns that the 2 minute exemption here might not be sufficient for all login scenarios (e.g. I have to go fetch my YubiKey from my other PC; I have to find my phone to use HOTP/TOTP, the login page was in a background tab and I forgot about it for a few minutes, etc). 

I'm also not sure why we wouldn't treat Session cookies and Persistent cookies the same (that is to say, allow them to travel on top-level-navigations for 2 minutes after they were set)?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Lily Chen

unread,
Aug 5, 2019, 12:09:52 PM8/5/19
to Eric Lawrence, blink-dev, Lily Chen, Erik Anderson, Chris Harrelson, Brandon Heenan, Vivek Sekhar, Rick Byers, Philip Jägenstedt, Rowan Merewood, morl...@chromium.org, Mike West
On Mon, Aug 5, 2019 at 10:56 AM Eric Lawrence <elaw...@chromium.org> wrote:
Thanks, Lily. There are some concerns that the 2 minute exemption here might not be sufficient for all login scenarios (e.g. I have to go fetch my YubiKey from my other PC; I have to find my phone to use HOTP/TOTP, the login page was in a background tab and I forgot about it for a few minutes, etc). 

Do you have data on how long such cookies are typically needed for? We wanted to restrict the exemption to a reasonably short time to limit its weakening of the CSRF protection that Lax-by-default would provide.
 
I'm also not sure why we wouldn't treat Session cookies and Persistent cookies the same (that is to say, allow them to travel on top-level-navigations for 2 minutes after they were set)?

Longer-lived persistent 3rd party cookies are more likely to be used for tracking, and we would like such cookies to declare themselves SameSite=None in order to to provide users more transparency and control over tracking.

On Thursday, August 1, 2019 at 1:29:51 PM UTC-5, Lily Chen wrote:
We plan to default to “Lax + POST” as a temporary intervention Chrome will perform for certain cookies defaulted to Lax in the absence of a SameSite attribute. Specifically, certain cookies that don’t specify SameSite and are defaulted into Lax will be sent with top-level navigations regardless of HTTP method (i.e. removing the restriction to “safe” methods applied to Lax cookies). This intervention will be restricted to session cookies (cookies that don’t specify an expiry time) that were set within the last 2 minutes, and persistent cookies whose max age (difference between creation time and expiry time) is at most 2 minutes.

This intervention aims to avoid breaking the auth flow described above while giving developers time to migrate their cookies to explicitly specifying SameSite.

Erik/Microsoft folks, do these session/expiry restrictions work for your use case?

On Fri, Jul 26, 2019 at 1:29 PM Lily Chen <chl...@chromium.org> wrote:
Thanks for bringing up this issue, Erik.

We are considering allowing "Lax plus POST" as an intervention Chrome will perform for cookies defaulted to Lax in the absence of a SameSite attribute. We will write something up describing it more fully for comment.

On Tue, Jul 23, 2019 at 7:05 PM 'Erik Anderson' via blink-dev <blin...@chromium.org> wrote:
Microsoft has been evaluating the effect of this change.

We love the intent and spirit of this change, but we fairly quickly determined that this breaks a large number of our sites leveraging Azure Active Directory (AAD) and Microsoft Account (MSA) authentication using the contract as defined here:

Also see https://docs.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-openid-connect-code.

Notably, the AAD recommendation has been to set response_mode to "form_post". Many of these applications are leveraging the nonce value as an anti-CSRF protection by setting a cookie on their own domain before redirecting to the auth provider's domain.

The flow that breaks is:
1. The site creates the CSRF token cookie without a SameSite attribute. With this change, it is now treated as lax.
2. Site does a redirect to the login provider, passing as part of the query string, response_mode=form_post&state=<token>
3. Login provider completes auth flow and initiates a POST back to the original site.
4. Since it's a lax cookie and the request mode is POST, the cookie is not sent.
5. Site checks CSRF token against the CSRF cookie dropped in step 1; since it's not present, it treats it as a failed login and attempts to log in again.

For many of these sites, the login retry logic means the user sees an auth loop with no clear indication of what happened.

This is not something that can be independently resolved by the AAD and MSA teams. It requires every existing client using the cookie-based CSRF check to also go in and update their logic to set SameSite=none on the appropriate cookies.

We suspect that other OpenID-based federated auth providers may have similar scenarios be broken, but we have not done an extensive manual test pass to try to identify them. Even if it is somehow scoped to Microsoft auth providers, it seems unrealistic to expect every one of their impacted, existing consumers to update.

--
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.

Eric Lawrence

unread,
Aug 5, 2019, 1:50:16 PM8/5/19
to blink-dev, elaw...@chromium.org, chl...@chromium.org, Erik.A...@microsoft.com, chri...@chromium.org, bhe...@google.com, vse...@google.com, rby...@chromium.org, foo...@chromium.org, mere...@google.com, morl...@chromium.org, mk...@chromium.org
> Do you have data on how long such cookies are typically needed for? 
> We wanted to restrict the exemption to a reasonably short time to limit its weakening of the CSRF protection that Lax-by-default would provide.

The only datapoint I have at the moment is that the ASP.NET Core default remote login timeout (and cookie expiration) is 15 minutes.

Longer-lived persistent 3rd party cookies are more likely to be used for tracking, and we would like such
> cookies to declare themselves SameSite=None in order to to provide users more transparency and control over tracking.

I understand the general desire to get devs to mark intentionally-cross-site cookies to mark them with SameSite=None. I don't understand why we'd treat Persistent Cookies differently than Session Cookies with regard to the 2-minute exemption though. I think it's entirely possible that a site may need cross-site behavior for a persistent cookie only for a short period after it's set, but need that cookie to continue to exist for a longer period of same-site use. Forcing the developer to change their persistent cookie so that it expires in less than 2 minutes seems unnecessarily burdensome.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Lily Chen

unread,
Aug 6, 2019, 11:02:14 AM8/6/19
to Eric Lawrence, blink-dev, Lily Chen, Erik Anderson, Chris Harrelson, Brandon Heenan, Vivek Sekhar, Rick Byers, Philip Jägenstedt, Rowan Merewood, morl...@chromium.org, Mike West
Thanks for the feedback. We will allow "Lax + POST" for all cookies defaulted into Lax, regardless of expiration date, that were set within the last 2 minutes.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

Lily Chen

unread,
Aug 15, 2019, 2:34:04 PM8/15/19
to Lily Chen, Eric Lawrence, blink-dev, Erik Anderson, Chris Harrelson, Brandon Heenan, Vivek Sekhar, Rick Byers, Philip Jägenstedt, Rowan Merewood, morl...@chromium.org, Mike West
The "Lax + POST" intervention is now available in dev channel as of 78.0.3880.4 with a threshold of 2 minutes, if you enable SameSite-Lax-by-Default by turning on the flag #same-site-by-default-cookies. MS folks, could you please let us know if it helps for your use case? Thanks!

bay...@gmail.com

unread,
Aug 15, 2019, 10:55:17 PM8/15/19
to blink-dev, chl...@chromium.org, elaw...@chromium.org, Erik.A...@microsoft.com, chri...@chromium.org, bhe...@google.com, vse...@google.com, rby...@chromium.org, foo...@chromium.org, mere...@google.com, morl...@chromium.org, mk...@chromium.org
Thanks, Lily. We'll have a look.
To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

ali.gh...@gmail.com

unread,
Aug 16, 2019, 8:18:43 PM8/16/19
to blink-dev, morl...@chromium.org, mk...@chromium.org, Malte Ubl
Hi Chrome team,

Making this the default for better security on the web sounds great. 

The Intent to Implement and the talk at I/O has, expectedly, created a sense of urgency in companies that worry this may break their users' experience, however reading through the thread here, there seems to be some important issues to figure out first: better breakage analysis and the Safari incompatibility issue.

My main question is: How confident is the Chrome team on being able to enable this by M80? and is it advisable for developers to start shipping mitigations to this? If there is still some uncertainty or expected delays, I believe it would be nice to communicate that in Chrome Status ticket.

I also like to bring the breakage potential of this into spotlight again as the analysis posted here claims that at least some cookies in 45% of page views will be blocked by this change but believes that would not cause too much user-visible breakage, without backing that assumption with data.

I've only been looking at this for a day but I like to list couple of uses cases that I believe have important user-visible breakage:

1- Embeds where logged-in status is a major part of the user experience, for example Facebook widgets such as "comments" and "like" where losing the logged in status hugely reduces the usefulness of them or YouTube embeds where it breaks features like Watch Later and related videos.

2- Any CORS enabled REST API that relies on cookies instead of other mechanism like tokens for auth. For example, API calls from AMP are always cross-origin and credentialed, so many endpoints that provide authentication or personalization in AMP could be using cookies. (AMP's published tutorial uses cookies for this purpose)

3- Aside from the user-visible changes, this default clearly breaks 3P tracking and analytics providers, if these providers do not change their services in time to send `SameSite=none`, their customers will be impacted. Has Chrome team seen enough engagement from all these parties to have confidence they are aware of this and working actively to fix it?

Some of these issues can be mitigated by special rules around the default such as the `Lax + POST` mentioned below (and also, I believe it is reasonable for credentialed, cors `get` fetch() requests to send SameSite cookies to get around #2 above) but I would worry about these magic rules making this very unpredictable.

Another related point to this default that I like to discuss is: https://github.com/httpwg/http-extensions/issues/762#issuecomment-522070002 
In summary: If a site has authenticated embedibility requirement, `samesite` becomes useless for CSRF protection. Has something along the lines of `none-get-strict-post` where all `GET` requests behave as if `none` is set but all `POST` requests follow as if `strict` been considered? If so, this may be a much safer default to start with. It won't help with protecting timing-attack issues but if the main point of the feature & this default is to protect against CSRF, that should be able to accomplish with much less breakage potential.

Lily Chen

unread,
Aug 19, 2019, 5:53:09 PM8/19/19
to ali.gh...@gmail.com, blink-dev, morl...@chromium.org, Mike West, Malte Ubl
Hi Ali,

Thanks for your feedback.

We plan to enable this in M80. Developers are advised to add "SameSite=None" (this Intent) and "Secure" (see Intent here) to cookies that must be used in third-party contexts, keeping in mind the issue of incompatible clients. We will be adding updated recommendations for developers to the article here.

I believe the use cases you mentioned would still work after the change if SameSite=None is used. We have seen evidence of rapid adoption of SameSite=None as evidenced by this UseCounter (SameSite=None cookies are encountered on at least ~20% of page visits, which is an underestimate in that it does not include cookies that have been fully migrated to both SameSite=None *and* Secure). We will be able to provide an updated estimate of SameSite=None usage when the next batch of HTTP Archive data comes out.

As for "none-get-strict-post", for these situations the specification already recommends setting two cookies, one with SameSite=Strict granting access to non-idempotent actions, and a separate cookie with SameSite=None or Lax granting access to idempotent actions.

Lily

--
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/3f77d4e8-e50d-4490-93fa-b47673365f80%40chromium.org.

ali.gh...@gmail.com

unread,
Aug 20, 2019, 1:40:35 PM8/20/19
to blink-dev, ali.gh...@gmail.com, morl...@chromium.org, mk...@chromium.org, malt...@google.com
Hi Lily,

Thanks for the response.

keeping in mind the issue of incompatible clients.
This implies that Chrome is launching a feature with the expectation that developers need to perform UA sniffing to use it properly. The implications of the Safari bug are real and painful, it requires real action beyond just keeping it in mind. If UA detection is not performed, it causes breakage on a sizable user group who are still on 12.

I believe this is a big problem in need of a solution before Chrome proceeds with this I2I. 
I will offer my thoughts on a possible solution at the end of this post, I don't want to complain without trying to be helpful, but before that:

The reasons I believe this is a big problem is not just because of the common agreement among Web Developers that UA detection is bad, The Safari bug introduces a 3rd layer of complexity and an additional point of failure; Now every developer needs to know:

1- What SameSite is and why they need to set it (This is very reasonable, I have no issues here). 

2- If you set it to none, it has to be set to Secure (This is not ideal, but okay. One of those things we just learn as developers without knowing why we are doing it. Ideal would have been SameSite=none implies Secure by default). 
This is failure point 1. If devs forget to do this, bad things happen. (and as the UseCounter you posted above shows, this is already happening a lot. I also checked a few sites and noticed DoubleClick's DSID cookie is set to none but not secure... This is already not a good sign imo)

3- Safari has a bug, make sure you only set it to none if Chrome or Safari >= 13. (This is a deal breaker imo). 
UA detection is hard, we have cookies being set in many different tech stacks and some of them don't even have UA detection logic yet. It is hard to understand why code is wrapping set cookies in this logic if someone unfamiliar looks at the code later. This introduces failure point 2 which is even harder to test during development and likelier to cause issues that will get caught in production later. I'm already dreading bug reports like "X doesn't work for some iOS users" because someone (reasonably) forgot to wrap their set cookie in a "isChrome" condition.

Looking at TAG review, Rick brought this up as a blocker as well. 

Suggestion:
  • Coordinate with Webkit and launch this at the same time as Safari's plans to change the default. This implicitly assumes that Safari will not change the default unless the bug is either backported or enough time has passed for most users to be on 13.
  • Put this on pause and communicate with developers that they should not be doing this yet due to the hiccups caused by the Safari issue until further notice. When the item above is figured out, communicate the new timelines.
    • Meanwhile could you publish roughly how many of the existing sites that are setting SameSite=none are doing proper UA detection and not breaking Safari 12?
Some general feedback:
  • This new feature was publicized way too early IMO, before TAG review, proper backward compatibility analysis and discovery phase to find issues such as the Safari bug. I really like to see Chrome separating its process into an initial RFC phase and only moving to I2I/S after TAG review, discovery phase and resolving public concerns.

Thanks for taking the time to read my comments! I have further thoughts on "none-get-strict-post" but will hold on for now so we can focus on the main issue in our discussions.
-Ali


On Monday, August 19, 2019 at 2:53:09 PM UTC-7, Lily Chen wrote:
Hi Ali,

Thanks for your feedback.

We plan to enable this in M80. Developers are advised to add "SameSite=None" (this Intent) and "Secure" (see Intent here) to cookies that must be used in third-party contexts, keeping in mind the issue of incompatible clients. We will be adding updated recommendations for developers to the article here.

I believe the use cases you mentioned would still work after the change if SameSite=None is used. We have seen evidence of rapid adoption of SameSite=None as evidenced by this UseCounter (SameSite=None cookies are encountered on at least ~20% of page visits, which is an underestimate in that it does not include cookies that have been fully migrated to both SameSite=None *and* Secure). We will be able to provide an updated estimate of SameSite=None usage when the next batch of HTTP Archive data comes out.

As for "none-get-strict-post", for these situations the specification already recommends setting two cookies, one with SameSite=Strict granting access to non-idempotent actions, and a separate cookie with SameSite=None or Lax granting access to idempotent actions.

Lily

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

Rowan Merewood

unread,
Aug 21, 2019, 9:45:13 AM8/21/19
to blink-dev, ali.gh...@gmail.com, morl...@chromium.org, mk...@chromium.org, malt...@google.com
Hey Ali,

I'm trying to propose a few options for developers that minimise the impact and offer some flexibility in the approach. I also want to stress that this is not a Chrome exception, we should be directing developers to make exceptions for the incompatible clients. I have updates to the guidance coming, but the overall summary is these two distinct approaches:

Option 1. Sniff the UA for incompatible clients and serve a cookie without SameSite=None, e.g.
if (iOS 12 or MacOS 10.14)
  Set-Cookie: cname=cvalue; Secure
else
  Set-Cookie: cname=cvalue; SameSite=None; Secure

Option 2. Serve two sets of cookies: one with SameSite, one without and check on the request
// Serve
Set-Cookie: cname=cvalue; SameSite=None; Secure
Set-Cookie: cname-legacy=cvalue; Secure

// Check
if (cookie[cname])
  value = cookie[cname]
else if (cookie[cname-legacy])
  value = cookie[cname-legacy]

I'll also make it clear that both of these should be considered a temporary mitigation that can be removed when the fixes rollout / affected clients go below an acceptable threshold for the individual sites.

ali.gh...@gmail.com

unread,
Aug 21, 2019, 11:48:14 AM8/21/19
to blink-dev, ali.gh...@gmail.com, morl...@chromium.org, mk...@chromium.org, malt...@google.com, rby...@google.com
Hi Rowan,

Documentation is definitely helpful but the issue here is a problem of scale.

If we were talking about only 10s or even 100s of developers needing to make this change, this will be fine. We are talking about thousands of developers who need to understand this and get all the 3 steps I mentioned in my previous comment right.

This will not scale, at each step of the way (and particularly the last one around incompatible clients) mistakes will be made due to various reasons (not fully understanding the reasoning, tech stack not supporting it, etc...). This is not something documentation would fully resolve. Even if we assume all thousands of developers will get all of this 100% right, please consider the extra effort launching this without waiting for the Safari issue to be backported or fade away will cost the community. I am not just making this up, even the simple step 2 which requires `SameSite=none` to be `secure` is already being ignored by a lot of sites per UseCounter mentioned above and even Google's own DoubleClick is not going it right for their DSID cookie... Now imagine how many will get the step 3 which is way more complex to understand, implement and test wrong.

I really hope you all consider the scale problem here seriously in your decision and reconsider launching this at a time when Safari detection or alternative workarounds are not needed. (Ideally launch in coordination with Safari at the same time per my previous comment)

Thank you!
-Ali

Alex Russell

unread,
Aug 22, 2019, 3:18:11 PM8/22/19
to ali.gh...@gmail.com, Yoav Weiss, blink-dev, morl...@chromium.org, Mike West, Malte Ubl, Rick Byers
Hey Ali,

The API OWNERS met again today, and to your point, we're looking for high confidence that this won't break the web. I believe Yoav has suggested a separate deprecation thread once we have more information.

Lily: is it your understanding that we won't move forward bringing this behavior to Stable until we get more data? If so, looking forward to seeing new data!

Regards

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/0c33f975-54d2-4bf8-a78d-29960d63fb5e%40chromium.org.

ali.gh...@gmail.com

unread,
Aug 22, 2019, 4:40:30 PM8/22/19
to blink-dev, ali.gh...@gmail.com, yoav...@google.com, morl...@chromium.org, mk...@chromium.org, malt...@google.com, rby...@google.com
Hi,

I'd trust that assessment, thanks for confirming. My main concern currently is the extra UA detection that has to be done to workaround the Safari bug (I'd love to hear if my assessment in previous comments on why this is a big deal might be unfounded). Not sure what "separate deprecation thread" implies, does it cover the Safari issue? (like one of the TAG suggestions on having this be a separate property?). Looking forward to it either way.

Thanks,
Ali


On Thursday, August 22, 2019 at 12:18:11 PM UTC-7, Alex Russell wrote:
Hey Ali,

The API OWNERS met again today, and to your point, we're looking for high confidence that this won't break the web. I believe Yoav has suggested a separate deprecation thread once we have more information.

Lily: is it your understanding that we won't move forward bringing this behavior to Stable until we get more data? If so, looking forward to seeing new data!

Regards

Lily Chen

unread,
Aug 23, 2019, 9:31:11 AM8/23/19
to ali.gh...@gmail.com, blink-dev, morl...@chromium.org, Mike West, Malte Ubl
  • Meanwhile could you publish roughly how many of the existing sites that are setting SameSite=none are doing proper UA detection and not breaking Safari 12?
Approximately 30%, but this is drawn from a small sample size (500 URLs), so it's only a very rough estimate. Among the top 10 sites we found setting SameSite=None 3p cookies for a Chrome 76 UA string, 3 do not set any SameSite=None cookies for a Safari 12 UA string, and 8 among the top 25.

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/3b17c09d-3527-40c2-b3b5-213565880e00%40chromium.org.

Lily Chen

unread,
Aug 26, 2019, 10:22:56 AM8/26/19
to Lily Chen, blink-dev, morl...@chromium.org, Mike West
We now have data from HTTP Archive through August. This is the number of sites (sorted by total 3p cookies in the dataset) which are setting SameSite=None:

mobile6/1/197/1/198/1/19
Top 10265
Top 2041110
Top 5092426
Top 100144044
Top 100035105126
desktop6/1/197/1/198/1/19
Top 10111
Top 20245
Top 502811
Top 10051622
Top 100082640

Mobile is seeing faster adoption than Desktop. One site setting SameSite=None in the top 10 dropped to #11 but another moved half its cookies to SameSite=None so 1 in the top 10 was maintained. On Mobile, one site went from 100% to 0% in August which dropped both the top 10 and top 20 numbers.

Alex Russell

unread,
Aug 29, 2019, 3:17:28 PM8/29/19
to Lily Chen, blink-dev, morl...@chromium.org, Mike West
Hey Lily,

Thanks so much for the data!

I'm trying to understand what "sorted by total 3p cookies in the dataset" means. Is this saying that "Top 10" is the top ten sites by traffic? From something like Alexa top 1K? Or the sites which set the most 3p cookies?

Regards

Lily Chen

unread,
Aug 29, 2019, 3:21:03 PM8/29/19
to Alex Russell, Lily Chen, blink-dev, morl...@chromium.org, Mike West
The last one. Sites were sorted by the total number of 3p cookies they set in the dataset, and the Top N were drawn from that sorted list.

panv...@gmail.com

unread,
Sep 5, 2019, 12:20:59 PM9/5/19
to blink-dev, morl...@chromium.org, mk...@chromium.org
https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-4.1.2.7

> If the "SameSite" attribute's value is neither of these, the cookie will be ignored.

So, does this mean that UA sniffing needs to go beyond just detecting webkit because of their known bug? If a browser does not implement 6265bis with "none" as a value, the moment developers provide it to such browser the cookie will be ignored in accordance with the spec.

I'm starting to believe now is not the right time for this change yet, first of all the WebKit issue makes this a pain to work around for developers, then this uncertainty around other user agents supporting "none" as a value.

Lily Chen

unread,
Sep 9, 2019, 6:14:27 PM9/9/19
to panv...@gmail.com, blink-dev, morl...@chromium.org, Mike West
Hi, thanks for raising this issue. We're also aware that older versions of Chrome (prior to April 2018) ignore cookies with an unrecognized SameSite value.

That was correct at the time, but since then the spec has been updated. It now says:
If the "SameSite" attribute's value is something other than these three known keywords, the attribute's value will be treated as "None".

And this draft amends that to:
If the cookie-attribute-list contains an attribute an attribute-name of "SameSite", set the same-site-flag to attribute-value. Otherwise, the cookie's same-site-flag to "Lax".

We did some testing and found that the majority of modern browsers handle this correctly (i.e. according to the updated spec).

Either of the options for working around the WebKit bug (either UA sniffing or double cookies) should work to avoid issues with browsers implementing the earlier version of the spec.

--
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.

ali.gh...@gmail.com

unread,
Sep 11, 2019, 2:48:20 PM9/11/19
to blink-dev, panv...@gmail.com, morl...@chromium.org, mk...@chromium.org
Hi all,

  • Meanwhile could you publish roughly how many of the existing sites that are setting SameSite=none are doing proper UA detection and not breaking Safari 12?
Approximately 30%, but this is drawn from a small sample size (500 URLs), so it's only a very rough estimate. Among the top 10 sites we found setting SameSite=None 3p cookies for a Chrome 76 UA string, 3 do not set any SameSite=None cookies for a Safari 12 UA string, and 8 among the top 25.

Thanks for publishing the stats on this. Is this not a big concern that only 30% of top sites are doing this properly and handling the iOS bug and 70% are not? If a concern, what is this group doing to help alleviate that. If not a concern, I would love to hear more about why.

Thanks,
Ali

On Monday, September 9, 2019 at 3:14:27 PM UTC-7, Lily Chen wrote:
Hi, thanks for raising this issue. We're also aware that older versions of Chrome (prior to April 2018) ignore cookies with an unrecognized SameSite value.

That was correct at the time, but since then the spec has been updated. It now says:
If the "SameSite" attribute's value is something other than these three known keywords, the attribute's value will be treated as "None".

And this draft amends that to:
If the cookie-attribute-list contains an attribute an attribute-name of "SameSite", set the same-site-flag to attribute-value. Otherwise, the cookie's same-site-flag to "Lax".

We did some testing and found that the majority of modern browsers handle this correctly (i.e. according to the updated spec).

Either of the options for working around the WebKit bug (either UA sniffing or double cookies) should work to avoid issues with browsers implementing the earlier version of the spec.

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

Lily Chen

unread,
Sep 12, 2019, 11:56:02 AM9/12/19
to ali.gh...@gmail.com, blink-dev, panv...@gmail.com, morl...@chromium.org, Mike West
We are working on publishing developer guidance on how to work around incompatible clients. That should be ready soon, and I will post a link to it here when that is out.

We are also reaching out to individual sites at the top of the list, to encourage them both to set `SameSite=None; Secure`, and to make sure they are aware of the issue of incompatible clients and how to work around it.

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/a8126251-2f44-4542-b2b5-6f3258a40903%40chromium.org.

hps....@gmail.com

unread,
Oct 15, 2019, 2:30:10 PM10/15/19
to blink-dev, ali.gh...@gmail.com, panv...@gmail.com, morl...@chromium.org, mk...@chromium.org
Hi Lily, 

Have Google services experimented with setting these cookies yet, in order to produce guidance?  The Microsoft account service started setting our auth cookies last week given the UA sniffing prescribed by this thread, and found error rates spike in 106 different user agents during the 20 hour timeframe we had the change in effect. 

Specifically, we've found that many handset vendors are still shipping something that looks like an old version of Chrome that uses the previous SameSite handling, but have stripped the UA string of any Chrome version.  This was seen in Lenovo and Huawei devices primarily, as well as Smartisan.  Another notable platform we broke was Unreal Engine (uses Chromium 59 under a different UA).

We're working on guidance as well for our client apps (first and third party) that need to change their cookie behavior, and many of them cannot use the double-cookie approach - we already have issues with cookie size.  Any guidance Google can produce that has worked across their own services would be very helpful. 

Thanks,
Hirsch Singhal

On Thursday, September 12, 2019 at 8:56:02 AM UTC-7, Lily Chen wrote:
We are working on publishing developer guidance on how to work around incompatible clients. That should be ready soon, and I will post a link to it here when that is out.

We are also reaching out to individual sites at the top of the list, to encourage them both to set `SameSite=None; Secure`, and to make sure they are aware of the issue of incompatible clients and how to work around it.

ali.gh...@gmail.com

unread,
Oct 16, 2019, 8:46:59 PM10/16/19
to blink-dev, ali.gh...@gmail.com, panv...@gmail.com, morl...@chromium.org, mk...@chromium.org
Hi Lily,

Could Chrome team please publish monthly data on "how many of the existing sites that are setting SameSite=none are also setting Secure=true and doing proper UA detection and not breaking Safari 12?".

Last month the numbers you published indicated that only 30% were doing it right and 70% were breaking the web for some of their users on Safari (and even Chromium-based browsers that mess with UA string - as per latest comments here)

Having this data trend published as we get closer to the planned Feb timelines is important to ensure, as per Alex's comment above, that "we're looking for high confidence that this won't break the web" and that "we won't move forward bringing this behavior to Stable until we get more data".

I still strongly believe the iOS 12 incompatibility issue is a blocker here and asking developers to do UA detection - which is unreliable and an anti-pattern - is unreasonable.


On Thursday, September 12, 2019 at 8:56:02 AM UTC-7, Lily Chen wrote:
We are working on publishing developer guidance on how to work around incompatible clients. That should be ready soon, and I will post a link to it here when that is out.

We are also reaching out to individual sites at the top of the list, to encourage them both to set `SameSite=None; Secure`, and to make sure they are aware of the issue of incompatible clients and how to work around it.

panv...@gmail.com

unread,
Oct 17, 2019, 10:16:40 AM10/17/19
to blink-dev, ali.gh...@gmail.com, panv...@gmail.com, morl...@chromium.org, mk...@chromium.org
Quick question from our engineers. How are cookies that were set prior to the change rollout without any sameSite flag (implicit none today) going to be handled after the user's agent gets updated? Do they remain "none" (preferred, for business continuity of users resurfacing in longer intervals) or will they now have "defaulted to lax" behaviours applied?

Best,
Filip

On Thursday, 12 September 2019 17:56:02 UTC+2, Lily Chen wrote:
We are working on publishing developer guidance on how to work around incompatible clients. That should be ready soon, and I will post a link to it here when that is out.

We are also reaching out to individual sites at the top of the list, to encourage them both to set `SameSite=None; Secure`, and to make sure they are aware of the issue of incompatible clients and how to work around it.

Rowan Merewood

unread,
Oct 17, 2019, 11:59:59 AM10/17/19
to blink-dev, ali.gh...@gmail.com, panv...@gmail.com, morl...@chromium.org, mk...@chromium.org
If there's no SameSite attribute specified, the new default behaviour will be applied to existing cookies. Otherwise you might expect that sites may try to set a number of long-lived cookies in advance to try and bypass the intended behaviour.

On the best practice, I've got this in review here: https://github.com/GoogleChrome/web.dev/pull/1367 if you want to dig to what's in progress - it should be published soon.

However (and this is perhaps more complex than I'd want to show as general guidance) you might consider a hybrid approach:
- UA sniffing for definitely incompatible browsers (but not exhaustive) as per https://www.chromium.org/updates/same-site/incompatible-clients which can explicitly be sent legacy style cookies without SameSite=None
- where UA sniffing does not reveal an explicit version use the double cookie approach
- for all other browsers, send SameSite=None;Secure

Lily Chen

unread,
Oct 17, 2019, 12:13:32 PM10/17/19