Intent to Implement and Ship: Cookies with SameSite by default

[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

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]

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]

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]

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]

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

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

[Brandon Heenan]

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]

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]

Happy to help with enterprise comms language.

Starting points: blog post, web.dev documentation.

--

Vivek |

Sekhar |

Product Manager |

vse...@google.com

[Brandon Heenan]

Thanks Vivek, I'll reach out when we're writing up the next set

[Yoav Weiss]

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.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY8HvYtX%2BLvqDo7R7n_1bgsK%3D03Lpbr240q4OYOLoS%3D3HQ%40mail.gmail.com.

[Lily Chen]

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]

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]

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]

Is there also a fixed MacOS version rolling out?

Thanks,

Jeffrey

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

[Lily Chen]

Looks like it is fixed in MacOS 10.15.

[Brandon Heenan]

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]

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.

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

[Lily Chen]

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]

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.

 

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

[Erik Anderson]

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:

https://openid.net/specs/openid-connect-frontchannel-1_0.html

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/40dc4555-f942-4c97-ba95-e6ebbed157c0%40chromium.org.

[Lily Chen]

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]

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]

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:

https://openid.net/specs/openid-connect-frontchannel-1_0.html

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]

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

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.