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.

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

[Lily Chen]

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]

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]

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]

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]

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]

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]

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]

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]

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

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.

[Lily Chen]

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

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:

mobile	6/1/19	7/1/19	8/1/19
Top 10	2	6	5
Top 20	4	11	10
Top 50	9	24	26
Top 100	14	40	44
Top 1000	35	105	126
desktop	6/1/19	7/1/19	8/1/19
Top 10	1	1	1
Top 20	2	4	5
Top 50	2	8	11
Top 100	5	16	22
Top 1000	8	26	40

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]

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

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

[Lily Chen]

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]

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]

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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/556f12e4-cffb-4950-865d-70664f2f6739%40chromium.org.

[ali.gh...@gmail.com]

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]

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]

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.

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.

[ali.gh...@gmail.com]

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.

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.

[panv...@gmail.com]

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.

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.

[Rowan Merewood]

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]

Thanks, Rowan.

Regarding:

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

I'm not sure it is possible to determine UA detection statistics in any remotely precise way such that a meaningful trend could be observed. The 30% number was very approximate and the variance is probably pretty large.

As for SameSite=None and Secure, we have Chrome metrics which show that, right now, about 70% of SameSite=None cookies are not correctly setting Secure. This has been moving in the right direction quite rapidly recently, e.g. 10 days ago it was 78% non-Secure and 22% Secure.

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/03230097-a81a-42e5-9647-9fd14d9617fd%40chromium.org.

[hps....@gmail.com]

Thank you Rowan, Lily.

Lily, do your browser stats for 3rd party cookies indicate average or a distribution of cookie sizes? For auth in particular, cookies needed in a 3p context can become fairly large.

Thanks,
Hirsch

[Lily Chen]

We don't have separate metrics on 1p/3p cookies for the size of the Cookie header. Overall, the average size of outgoing Cookie headers is 800 bytes.

Is there any reason you think this might be relevant to the proposed SameSite changes?

--
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/1d5e485f-d01d-42a2-a0ab-978c3ca0178f%40chromium.org.

[hps....@gmail.com]

Appreciate the quick response, thanks Lily.  

The proposed solution for handling incompatible clients is to set your cookies twice.  This effectively doubles the size of cookies that you're setting on the request (for our login pages in particular, but also our relying parties like Outlook.com).  Today our partners already run up against the limits of exceeding header and cookie limits in browsers.  These issues will occur more often if some cookies are set twice, so we cannot give this guidance to our partners.  Understanding who is actually capable of increasing their cookie load by 10-50% would help us explore the effectiveness of this guidance. 

On Thursday, October 17, 2019 at 9:46:32 AM UTC-7, Lily Chen wrote:

We don't have separate metrics on 1p/3p cookies for the size of the Cookie header. Overall, the average size of outgoing Cookie headers is 800 bytes.

Is there any reason you think this might be relevant to the proposed SameSite changes?

On Thu, Oct 17, 2019 at 12:23 PM <hps....@gmail.com> wrote:

Thank you Rowan, Lily.

Lily, do your browser stats for 3rd party cookies indicate average or a distribution of cookie sizes? For auth in particular, cookies needed in a 3p context can become fairly large.

Thanks,
Hirsch

--
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 blin...@chromium.org.

[Lily Chen]

Oh, I see, you meant the size of the Set-Cookie header. Unfortunately we don't have any metrics on that. You raise a good point, that browser header limits and server load would be a consideration for the double-cookie approach.

For Chrome at least, there is a limit of 4096 bytes for each Set-Cookie line. As far as I'm aware, there's no limit on total size of all Set-Cookie lines (aside from max cookie count * max cookie size). This page seems to have some test results for other browsers.

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/3eae93b8-1e74-4d62-b884-e342c46473f5%40chromium.org.

[riking...@gmail.com]

That page states that the maximum compatibility limit is 4093 bytes per domain - significantly less than "any number of 4096 byte cookies"!

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3eae93b8-1e74-4d62-b884-e342c46473f5%40chromium.org.

[Lily Chen]

I meant that in Chrome, there is no limit on total cookie size per domain aside from the obvious (max count) * (max size). Other browsers may have different restrictions. 

Another relevant limit is the max allowed size of the headers for a single response, which is 256K.

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/52f326b7-aa84-46bb-a105-d16d93898081%40chromium.org.

[Erik Anderson]

The Microsoft Edge team has received some questions about when we’ll expose this change. We are planning to experiment starting with Microsoft Edge 80, following a similar pattern of exposing it to each channel progressively with the timing being based on user and developer feedback.

[Daniel Bratell]

This is not a direct answer to your question, but I will mention that the team had a presentation of the state and the plan for the api owner group. Part of the effort is to reduce the amount of content that could possibly be badly affected by the change. The effectiveness of that work will probably affect the timeline quite a lot.

/Daniel

On 2019-10-22 02:56, 'Erik Anderson' via blink-dev wrote:

The Microsoft Edge team has received some questions about when we’ll expose this change. We are planning to experiment starting with Microsoft Edge 80, following a similar pattern of exposing it to each channel progressively with the timing being based on user and developer feedback.

--

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/DM5PR00MB0309D590E2600BF3E035D7C6F4680%40DM5PR00MB0309.namprd00.prod.outlook.com.

[Lily Chen]

Hi all,

We have posted some pseudocode that may help with working around incompatible clients. This is linked from the SameSite updates page on chromium.org. As always, we welcome any feedback.

Lily

[hir...@microsoft.com]

Thanks Lily. 

We've found in our testing that the pseudocode provided misses the internal browser within Mac that exhibits the SameSite bug present in Safari 12. 

Safari	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13 Safari/605.1.15
Chrome	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36
Internal Browser	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko)

Google.com correctly handles this case, even though the provided pseudocode does not.  Can you sync with the Google.com team to have them share the UA sniffing code that they're using? 

You can find the current sniffing code that Microsoft is shipping documented here (dotnet team) and here (Passport JS for AAD) 

Thanks,

Hirsch

On Monday, October 28, 2019 at 2:21:25 PM UTC-7, Lily Chen wrote:

Hi all,

We have posted some pseudocode that may help with working around incompatible clients. This is linked from the SameSite updates page on chromium.org. As always, we welcome any feedback.

Lily

On Thu, Oct 24, 2019 at 2:47 PM Daniel Bratell <brat...@gmail.com> wrote:

This is not a direct answer to your question, but I will mention that the team had a presentation of the state and the plan for the api owner group. Part of the effort is to reduce the amount of content that could possibly be badly affected by the change. The effectiveness of that work will probably affect the timeline quite a lot.

/Daniel

On 2019-10-22 02:56, 'Erik Anderson' via blink-dev wrote:

The Microsoft Edge team has received some questions about when we’ll expose this change. We are planning to experiment starting with Microsoft Edge 80, following a similar pattern of exposing it to each channel progressively with the timing being based on user and developer feedback.

--
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 blin...@chromium.org.

[Lily Chen]

Thanks, Hirsch! We have updated the incompatible-clients page with this information.

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/a5b34f07-7d57-4ab9-920c-c91da5084d67%40chromium.org.

[mcarl....@gmail.com]

Hi Lily,

I got a question as well on the pseudocode provided. I had a look at the user agent list regarding UC Browser - all version 4.0 - e.g. 'Mozilla/5.0 (Linux; U; Android 9; en-US; vivo 1907 Build/PPR1.180610.011) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 UCBrowser/12.13.4.1214 Mobile Safari/537.36' do reference a 'Chrome/57'. So although the version is > 12.13.2 it will be detected to be incompatible as part of of Chrome/51-Chrome/67 validation. Is this by intention of should checks in pseudocode be flipped to validate UCBrowser first?

Thanks,

Michael

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a5b34f07-7d57-4ab9-920c-c91da5084d67%40chromium.org.

[Lily Chen]

Hi Michael,

Thanks for pointing that out. UC Browser does seem to send Chrome 57 in its UA string, even on newer versions with the updated SameSite behavior. We've updated the pseudocode with this information.

Best,

Lily

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/47d667b4-6737-41a3-8bbc-11bb05042870%40chromium.org.

[deaun...@gmail.com]

On Saturday, May 25, 2019 - 12:15:19 am UTC + 8, Lily Chen wrote:

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 unrestricted status quo 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-in to its protections by specifying a SameSite attribute, that is, developers are vulnerable to CSRF attacks by default. This change would allow developers to be protected by default while allowing sites that require cross-site state 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 with 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 ignore that attribute and apply the default status quo 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 do not specify SameSite) are shown as blank. Adding DevTools messaging console for cookies that will 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 the entry on the dashboard feature

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

Requesting approval to ship?

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

[Nicolás Peña]

Hi, any update on the intended timeline for this intent? I don't see owners lgtms yet.

[Lily Chen]

The planned timeline can be found here. We have been monitoring metrics from HTTP Archive and from a fieldtrial on Canary/Dev/Beta. We have been reaching out directly to sites with cookies that would be affected, and many of them have indicated that they will be updating their cookies after the new year (due to production freezes during the holidays), so we expect the numbers to improve substantially in a few weeks. We'll follow up on this Intent thread after the new year.

--

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/2c1dfa12-c64c-4bed-915b-726121a09823%40chromium.org.

[Chris Harrelson]

Also:

The API owners met with the team and discussed the current plan. Currently, it is approved for experimentation on beta (see thread here). And as mentioned by Lily, we'll discuss stable launch in January with the data from the experiment. Until then, I recommend developers continue to prioritize the changes required to prepare for this launch.

Chris

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

[srraj...@gmail.com]

It would be really helpful if you could explain the way these changes affects requests made in Chrome Extensions.
Thanks in advance.
Below are the scenarios we tested and the queries.

We are working on Chrome extensions that

- reads cookies from a domain which was set without SameSite attribute
- writes cookies to a domain without SameSite attribute
We have added permissions to both the domains in manifest.json

We enabled the following flags in Chrome browser,

● SameSite by default cookies
● Enable removing SameSite=None cookies
● Cookies without SameSite must be secure

Queries

1.Even after enabling the flags, we are able to read the cookies that were set with following values from other domain. Is that expected and if so why??

- without SameSite attribute
- with SameSite=strict

2.Say an extension sets cookies without SameSite attribute in a site with a domain X.com. What happens when the site (X.com) is
consumed via iframe by another extension
consumed via iframe by another site with domain Y.com. Will the cookie be rendered with the response in both the cases??

Are requests from extensions considered as cross site request??

3.How does cookies set by extensions in a domain behaves?? Is that similar to what happens when a web site from a different domain sets a cookie??

4.Does extensions with permissions to a domain in manifest.json be able to read cookies from the other domain irrespective of the SameSite value??

[2020s...@gmail.com]

Hi all,

I work at LinkedIn and I am working on getting our cookies get ready for this upcoming change. We have followed the Chromium article for incompatible clients, and we have some unit tests for certain user agents that we get requests from, and have assertions whether we can send SameSite=None for those user agents. With www.google.com now issuing cookies with SameSite attribute, I picked some of my test cases and ran it on python shell and found that Google's implementation doesn't exactly implement what is suggested in the article - specifically the Mac embedded browser part. According to the article, we can set SameSite=None for embedded browsers on MacOS after 10.14, but even on 10.15, www.google.com is not setting SameSite=None.

Here is the test case: Chrome 78, SameSite=None comes for cookie 1P_JAR, but for embedded browser on Mac OS 10_15, SameSite is not being set by Google. Can someone please check if the article needs to be updated with what Google has internally implemented or is there a miss in Google's implementation?

>>> requests.get('https://www.google.com', headers={'user-agent': "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36"}).cookies
<RequestsCookieJar[Cookie(version=0, name='1P_JAR', value='2020-01-09-01', .., domain='.google.com', .., path='/', .., secure=True, expires=1581124747, .., rest={'SameSite': 'none'},

>>> requests.get('https://www.google.com', headers={'user-agent': "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko)"}).cookies
<RequestsCookieJar[Cookie(version=0, name='1P_JAR', value='2020-01-09-00', .., domain='.google.com', .., path='/', .., secure=True, expires=1581122022, .., rest={},

On Friday, 24 May 2019 09:15:19 UTC-7, Lily Chen wrote:

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.

[Lily Chen]

srrajaraja: Extensions are subject to special rules with respect to SameSite cookies. The behavior was recently updated in Chrome 80 so you may want to retest using Chrome 80.

I will try to describe what the current behavior is: A web request is treated as same-site (and attaches all SameSite cookies, including Strict, in its request headers) if one of the following is true:

1. The request is initiated by an extension page (e.g. the extension's background page) and the requested URL is listed in the extension's permissions in the manifest.
2. The top level frame (i.e. the site shown in the URL bar) is an extension page, and the requested URL is listed in the extension's permissions in the manifest, and the requested URL and the initiator of the request are same-site to each other, and the extension has permission for the initiator origin.

The chrome.cookies API is separate, and is able to read and set any kind of cookie, including SameSite. However, a web page embedded in an extension page is considered to be in a third party context for the purposes of document.cookie accesses.

It wasn't clear to me what method of cookie access you were asking about, but hopefully that answers your questions. If not, please provide a concrete example of what scenarios you are concerned about.

--

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/171699c8-5537-4cc6-b299-314727f2d632%40chromium.org.

[Rowan Merewood]

Hey there,

Embedded browsers on Mac OS 10.15 should be compatible with SameSite=None; Secure and I don't believe we're excluding them in our detection. However, I wouldn't take the presence / absence of the SameSite attribute on that cookie as a direct proxy for our detection. In some cases there may be a specific reason, e.g. functionality only relevant for older browsers, that means the attribute may not be set.

--

[kb...@panopto.com]

Hello,

I would like to check on the status for releasing this change and to request that it be delayed beyond Chrome 80 / February 4.

I work at Panopto, which provides video services to universities and companies around the world.  Our primary use case for universities involves loading lecture videos, in an iframe, within a learning management system (such as Blackboard or Canvas). These videos are secured and access controlled, so authentication is required to view them. We use an auth cookie to achieve this, with SameSite currently unspecified. When this change is released, all of these embedded videos will be broken in Chrome.

Our services are hosted both on the cloud (managed by us), and on-premises (managed by our customers). For our cloud-hosted services, we have already applied the fix. But updating on-prem services (covering a substantial number of our active users), requires a large amount of coordination with our customers. The compressed timeline between now and Chrome 80’s release on February 4th presents a serious challenge to get all of those on-premises servers patched.

That means Chrome 80’s planned release of the SameSite change presents a risk of an outage for a very large number of university students, in a critical use case.  Any impacted students will be forced to switch to a different browser.

Unfortunately, the workaround Google has recommended for IT administrators--using a policy to change Chrome’s behavior--is not viable for the university students, since they aren’t controlled by any sort of corporate group policy.

As an extra complexity, our service is built on top of Microsoft .Net, which only updated to support SameSite=None mid-December 2019, cutting down our time to implement, test, and distribute a fix to customers ahead of the current February 4th estimated release day.

If there are any workarounds that may work on an individual level (rather than a policy level), please let me know. Otherwise, I would ask if it’s possible to delay the full roll out of this change, at least until April. The additional time would help service developers like us to coordinate with customers and update on-premise installations, and will make a big difference in mitigating any negative impacts of this change.

Kevin Baum & the Panopto team

[srraj...@gmail.com]

Thank you so much for the explanation lily. Appreciate it.
It would be helpful if you could clarify few more queries mentioned below.

Extension settings
● We are using chrome.cookies API to read and write cookies
● We have listed the domains from which we read cookies and domains to which we write cookies in extension's manifest.

Flags enabled during testing,

● SameSite by default cookies
● Enable removing SameSite=None cookies
● Cookies without SameSite must be secure

Scenarios and Queries

1. We read cookies that are not set without SameSite attribute from a domain.

As per your point #1, this will work as the request is made using from extension's background page using chrome.cookies API and the permission is also added in manifest.
Whatever the value of SameSite is (not mentioned/lax/strict), the cookie will be accessible through chrome.cookies API.
Is our understanding correct?

2. We are writing cookies to a domain using chrome.cookies API without setting SameSite attribute to the cookie.
How this cookie works,
Q: When the page is visited as a standalone site?
A: This is in first party context and hence the cookie will be available to the site

Q: When the page is consumed via iframe by an extension?
A: This is in 3rd party context and hence the cookie cannot be accessed by the extension even though it has listed permissions to the domain loaded via iframe in manifest.

Q: When the page is consumed via iframe by another site with different domain?
A: This is in 3rd party context and hence cookie will not be available to the site consuming it.

Kindly validate our understanding.

3. In web.dev article, we read that the default value LAX is set to SameSite as a temporary mitigation. Will it be deprecated in future? If so, when can we expect the same??

Thanks in advance.

[Lily Chen]

srrajaraja: The chrome.cookies API is allowed to get/set cookies with any SameSite value, as long as the extension has permission.

1. If the cookie is set (successfully) by some HTTP response, it should be accessible using the chrome.cookies API regardless of SameSite attribute. Note that the cookie must be successfully set, so the SameSite attribute is still relevant for setting the cookie via HTTP response header.

2. Assuming you have set a cookie with no SameSite attribute on site A using chrome.cookies: 1) When site A is visited, this is a (laxly) same-site context so the cookie will be sent. 2) If site A is in an iframe on an extension page, this will be considered a same-site context if the extension has permission for the requested URL, which in your case it does. 3) When site A is in an iframe on site B, this is considered a cross-site context so no SameSite cookies will be sent.

3. The "temporary mitigation" in the web.dev article refers to Lax+POST as the default. The "+POST" part will be phased out, and the default will become Lax only. We have not proposed a timeline for this deprecation.

--
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/0a376a71-7ebb-483c-ada4-eaf9434ad03b%40chromium.org.

[srraj...@gmail.com]

Appreciate the quick response, thanks a lot for the detailed explanations Lily.

[Philip Jägenstedt]

Hi Lily,

Do you have an update on the various metrics and if they've changed after the holidays?

If shipped today, what kind of breakage would we expect to see, and how much of it?

Thanks!

On Wed, Jan 15, 2020 at 7:47 AM <srraj...@gmail.com> wrote:

Appreciate the quick response, thanks a lot for the detailed explanations 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/d7c9e542-a76f-4d75-8f83-afe8857091d6%40chromium.org.

[apoorv...@gmail.com]

The SameSite updates page mentions that : 

In addition, there is a bug affecting Chrome 78 which causes spurious SameSite warning messages to be emitted to the console when the user has cookies for other domains on the same site as a resource fetched in a cross-site context. We apologize for the confusion. This will be fixed in Chrome 80.

As per my testing, Chrome 79.0.3945.117 (Official Build) (64-bit) Stable is also affected with this bug. Can you please confirm this and update the page accordingly ?  

[Lily Chen]

Philip: I am currently putting that information together, and my team expects to discuss this with the API Owners at your upcoming meeting. Thanks for the reminder!

apoorvmunshi: That is correct. Sorry for the imprecise wording. I will update the page.

--

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/00e8e838-318b-49df-be24-be6d616888fc%40chromium.org.

[Philip Jägenstedt]

That's great, thanks Lily! I did see that this is planned for Jan 23, and if at all possible it would be good to also share it on blink-dev, even before the meeting if it's ready.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAE24Oxw%3DYjn5x%2BQHRzQ%3DF5%3DxkwhsCNHgNm3kBM4q7kkpaSokZA%40mail.gmail.com.

[Nikky heri sandi Lubies]

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

[Lily Chen]

Hi all,

Here’s an update on this feature, SameSite=Lax by default, and the related feature SameSite=None requires Secure.

The web ecosystem has been moving rapidly to adopt the SameSite attribute. Since October 2019, the proportion of cookies that explicitly specify a SameSite attribute has increased from 6% to 13% (Cookie.SameSiteAttributeValue). SameSite=None is now found on 10% of cookies and SameSite=Lax is found on 3% of cookies (up from 0.5% in October). For comparison, requests for cookies in a cross-site context, which would require SameSite=None, account for 14% of all cookie requests (Cookie.RequestSameSiteContext). Data from HTTP Archive shows that, as of December 2019, SameSite=None is being used on cross-site cookies by 237 of the top 1000 sites, up from 58 in October.

Use of the Secure attribute is also on the rise. Because SameSite=None will soon require the Secure attribute to be set, we have been monitoring the proportion of SameSite=None cookies that also specify Secure (Cookie.SameSiteNoneIsSecure). As of early December 2019, there are more SameSite=None cookies that specify Secure than not. Currently over 67% of SameSite=None cookies are Secure, up from about 50% just two weeks ago. Since the announcement of these SameSite cookie changes in May 2019, the overall use of the Secure attribute (Cookie.Type) has grown from 12% of cookies to 20% of cookies, a definite win for security -- not only for Chrome users but for all web users.

There are still some cookies that are not yet compliant with these changes. About 52% of page visits result in at least 1 access to a cookie with no SameSite attribute in a cross-site context. About 26% of page visits result in at least 1 access to a SameSite=None cookie that does not specify Secure (Blink.UseCounter.Features). These cookies would be blocked by the SameSite changes.

However, these numbers are only an upper bound (and, we believe, a loose one) for the amount of breakage that may actually be experienced by users. The fact that a cookie would be dropped does not mean it would break or affect any user-facing functionality. For example, many services (such as Google Accounts) have adopted the “double cookie” approach of setting one SameSite=None cookie for clients that support it, and a duplicate cookie with no SameSite attribute for clients incompatible with SameSite=None. In such cases, the duplicate cookie would intentionally be dropped while having no impact on site functionality.

As you browse the web, Chrome keeps track of a Site Engagement Score from 0 to 100 for every origin that you interact with. (You can inspect your own at chrome://site-engagement.) We examined the Site Engagement Scores of the sites with noncompliant cookies (Net.SameSiteBlockedCookieSiteEngagement) as a measure of how important they are to the user. Of the requests that would have cookies blocked under SameSite=Lax by default, 79% were to sites that the user had no engagement with (Site Engagement Score of 0.0), only 4% were to sites with which the user had “medium” levels of interaction (Site Engagement Score of 15.0 to 50.0), and fewer than 3% were to sites with “high” or “max” engagement scores (over 50.0). That the vast majority of affected requests are for sites with little to no user engagement suggests that most of the cookies that would be dropped after these SameSite changes would not result in user-visible breakage.

Since October 2019, we have been running fieldtrials on Canary, Dev, and Beta, where 50% of users had these SameSite changes enabled. We have been monitoring several metrics as potential indicators of breakage:

• Total Site Engagement Score: breakage may cause users to move away from browsing the web using Chrome. This decreased by about 2% for the experimental groups as compared to the control groups (SiteEngagementService.TotalEngagement).

• Page (re)loads: users may reload the page if something is broken, resulting in an increase in reloads, or they may use Chrome less, resulting in fewer page loads. Overall page loads decreased by 3%, though reloads did not change significantly (PageLoad.PaintTiming.NavigationToFirstContentfulPaint).

• Clearing cache or cookies: users may clear their browsing data in an attempt to fix breakage. No statistically significant changes were found (History.ClearBrowsingData.UserDeletedCookieOrCacheFromDialog).

• Opening DevTools: users may attempt to troubleshoot breakage by opening the developer console. No statistically significant change in total count was found (DevTools.PanelShown).

• Password manager activations: users may be prompted to login more frequently due to missing cookies. No statistically significant change in either successful logins or failed logins was found (UserActions.Counts:PasswordManager).

• Redirect chain length: broken logins may result in long chains of redirects. There was a 15% increase in 99th percentile redirect chain length, from 1.5 redirects to 1.7 redirects. The 25th, 50th, 75th, and 95th percentiles increased slightly, each by 0.6%.

Overall, we believe the fieldtrial results indicate a very modest amount of breakage. The two fieldtrials running in parallel, one enabling SameSite=Lax by default only, and the other enabling both SameSite=Lax by default and SameSite=None requires Secure, had very similar results. As more sites complete their updates in the coming weeks, the metrics will continue to improve.

Of the approximately 30 actionable bug reports received about these changes on crbug.com since September, all but 5 have been closed (with the remaining either waiting for reporter verification or left open as tracking bugs for unfinished work). The majority of user reports have stemmed from confusion about the console warning messages (updated in Chrome 80 to report feature status), breakages due to Google Accounts cookies (now updated), or buggy interactions with Chrome extensions (fixed in Chrome 80).

Finally, we have been testing and reaching out to sites directly about updating their cookies with SameSite=None and Secure. With the help of the Chrome test team, we were able to manually test the Alexa Top 50 sites on desktop and Android, finding no SameSite-specific breakage, login-related or otherwise. The Chrome 80 branch validation test pass was performed on the top 200 sites with and without these SameSite features enabled, and no SameSite-specific breakage was found. We are also manually testing login and logout on the top 1000 sites by number of page views containing noncompliant cookies. This testing is still in progress, but so far we have tested close to 400 sites and found breakage on fewer than 15. These sites have been contacted and asked to investigate. We have been reaching out directly to sites with the most noncompliant cookies according to HTTP Archive data. Of the top 100 sites, we have been able to reach over 80 and confirm their awareness of the SameSite=Lax by default and SameSite=None requires Secure changes. Many have indicated to us that they plan to update their cookies and are targeting January 2020 or before Chrome 80 is released to complete this work.

In summary, we are seeing the web ecosystem respond to these changes and cookie updates are in full swing. The vast majority of the remaining noncompliant cookies are on sites with little to no user engagement, so there may not be much user-visible breakage. We have confirmed with many of the top sites still sending noncompliant cookies that they are aware of the changes and are actively working to update their cookies before Chrome 80 is released. We believe the SameSite cookie changes are safe to roll out in February 2020 and request that the API owners approve these two changes.

Thanks,

Lily

[apoorv...@gmail.com]

Since the Chrome release date is very close now, is there any official decision yet from MS Edge team ? Since some web administrators are going to deploy this change only for Chrome 80+ by sniffing User-Agent , an official communication about Edge's release timeline is very important IMO. Thank you. 

[Rick Byers]

The API owners just met to discuss this. There is of course still significant risk here, but personally I'm now satisfied with the care and diligence that has been applied to this change, and the evidence that the ecosystem will be able to successfully adapt with minimal harm to users and businesses (which is more than offset by the expected long-term benefits to user privacy of going down this path).

LGTM1

--

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/CAE24OxzfEVvfXs1mnCZgbRY%3Dy0Tz4%2B7LrpVh%2B1dUqYhfc66veg%40mail.gmail.com.

[Yoav Weiss]

Thanks you for the update, and the thought-out research and outreach that went into it.

While the use-counters are significantly higher than we would like, the fact that many sites emit those cookies unknowingly, and that "double cookies" also touch them, makes me agree with your assessment that they represent a very loose upper bound.

The fact that most sites that touch the counters are low engagement ones and that "user frustration" metrics haven't moved (much) in the significant beta population that was subject to this change, is also reassuring.

This is still risky, but the benefits to user privacy and security are significant enough to overcome that risk.

LGTM2

 

--

[Daniel Bratell]

LGTM3

/Daniel

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

[Christian Biesinger]

Hi Lilly,

I recently found a site that's broken by this. Is there a recommended document I can send to them so they can update their site? (Destiny item manager login, if anyone is curious)

Thank you!

Christian

--

[Rick Byers]

Probably this chromium blog post from October is our best resource?

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

[Kaustubha Govind]

Hi Christian,

Thanks for reaching out to report this. We also recently published this FAQ page that you may find handy.

Kaustubha

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

[hir...@microsoft.com]

Hi Lily, 

I noticed that the Chromium SameSite status page has been updated to indicate a ship date of "the week of February 17th".  This is much appreciated as it gives our customers more time to patch their on-prem services. We will update our docs to snap to yours.

As we're expecting an increase in support tickets on the day this launches - is it possible to ensure that this change does not go live until the 18th? Microsoft has off on the 17th for President's Day in the US, and we'd prefer to not have more folks on-call that day/over a long weekend if we can help it.  Documenting a specific day for launch or your ramp plan would be best so that we can target our bridges and on-call rotations around it. 

Thank you for your help and coordination throughout this process, I really appreciate it. 

Hirsch

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

[Anna Perez]

Can you clarify if Chrome will be updated on Feb 4 to v80 with the field trials config changing Feb 17? Or will the version remain v79 until Feb 17?

[Eric Lawrence]

Chrome 80 will ship on schedule, with rollout to stable starting February 4th. The field trial configuration enabling SameSiteLaxByDefault will start rollout the week of February 17th.

https://chromiumdash.appspot.com/schedule

https://textslashplain.com/2017/10/18/chrome-field-trials/

On Sun, Feb 2, 2020 at 2:40 PM Anna Perez <annav...@gmail.com> wrote:

Can you clarify if Chrome will be updated on Feb 4 to v80 with the field trials config changing Feb 17?  Or will the version remain v79 until Feb 17?

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/AknSSyQTGYs/unsubscribe.
To unsubscribe from this group and all its topics, 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/da60b70d-6251-499b-a7a9-6ddcfa3c9aa2%40chromium.org.

--

Eric Lawrence
Bayden Systems
https://bayden.com

[Lily Chen]

Hirsch: Thanks for your feedback. The rollout will begin with a small percentage of Stable users, and will be ramped up progressively to allow for feedback and monitoring of the web ecosystem after each percentage increase. We cannot commit to a rollout schedule or rate of increase, because plans may change as we monitor the response to the rollout. We will keep https://www.chromium.org/updates/same-site updated with the most current information. As you pointed out, Feb 17 is a major holiday in the US, and starting the ramp-up on that date would be counter to usual best practices.

Anna: What Eric said is correct. The Stable release of Chrome 80 is scheduled for Feb 4. After that is released, the new SameSite behavior will be rolled out gradually to Chrome 80 Stable users starting the week of Feb 17.

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/CAN_MvkBD61CrSFPa5hnSG3LhSeuEDmufJMqi6jLWMR%3D1NDVjOg%40mail.gmail.com.

[bco...@gmail.com]

So, given that Feb 17th is a holiday in the US, we can assume that the experimental rollout to users of the Chrome 80 Stable release will not begin until February 18th. As in accordance with best practices. Am I reading that correctly?

On Monday, February 3, 2020 at 9:10:56 AM UTC-5, Lily Chen wrote:

Hirsch: Thanks for your feedback. The rollout will begin with a small percentage of Stable users, and will be ramped up progressively to allow for feedback and monitoring of the web ecosystem after each percentage increase. We cannot commit to a rollout schedule or rate of increase, because plans may change as we monitor the response to the rollout. We will keep https://www.chromium.org/updates/same-site updated with the most current information. As you pointed out, Feb 17 is a major holiday in the US, and starting the ramp-up on that date would be counter to usual best practices.

Anna: What Eric said is correct. The Stable release of Chrome 80 is scheduled for Feb 4. After that is released, the new SameSite behavior will be rolled out gradually to Chrome 80 Stable users starting the week of Feb 17.

On Sun, Feb 2, 2020 at 6:02 PM Eric Lawrence <bay...@gmail.com> wrote:

Chrome 80 will ship on schedule, with rollout to stable starting February 4th. The field trial configuration enabling SameSiteLaxByDefault will start rollout the week of February 17th.

https://chromiumdash.appspot.com/schedule

https://textslashplain.com/2017/10/18/chrome-field-trials/

On Sun, Feb 2, 2020 at 2:40 PM Anna Perez <annav...@gmail.com> wrote:

Can you clarify if Chrome will be updated on Feb 4 to v80 with the field trials config changing Feb 17?  Or will the version remain v79 until Feb 17?

--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/AknSSyQTGYs/unsubscribe.

To unsubscribe from this group and all its topics, send an email to blin...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/da60b70d-6251-499b-a7a9-6ddcfa3c9aa2%40chromium.org.

--

Eric Lawrence
Bayden Systems
https://bayden.com

--
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 blin...@chromium.org.

[Lily Chen]

Yes, this is reflected in the updated Launch Timeline.

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/d969b73e-f9a0-4cda-92fd-2ec3e4eedf7e%40chromium.org.

[Alex Russell]

Sorry for the slow reply (was OOO).

Per the recent meeting, I wanted to thank the team for doing the research to ensure that we have quantified the risk, validated the impact with significant user populations, and ensured that we have good controls in place to ensure we can quickly respond if issues arise during the rollout. Confidence in a change this large is hard to build, and I appreciate the persistence of Lily and the team in building it.

Regards

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

[Mike DuVall]

I'm trying to test a scenario where I believe the "Lax + POST" mitigation should be allowing my cookie to be set, but it's not working.  Is the "Lax + POST" mitigation supposed to be available in Chrome version: 80.0.3987.87

Should it be working in that version?  Are there any other settings I have to set to make it work?

I have these two settings set to "Enabled":

chrome://flags/#same-site-by-default-cookies
chrome://flags/#cookies-without-same-site-must-be-secure

[Lily Chen]

Mike: Lax+POST is enabled in Chrome 80 if you have those two flags enabled. Note that the allowance for POST requests only applies to top-level POSTs, and only if the cookie was created under 2 minutes ago. You can collect a NetLog to see how Chrome is handling each cookie.

--

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/7cc40e49-94b2-4185-b0f8-a8d6b85c03cd%40chromium.org.

[manuel.b...@dailymotion.com]

Hi, 

is there any information available regarding the details of the samesite roll-out on Chrome80? how many users are affected in which country by when? I would be very interested to have some details on the detailed roll-out plan.

Thanks.

kind regards.

Manuel

[Lily Chen]

Hi Manuel,

The rollout has begun, starting with a limited population of users on Chrome 80. We plan to slowly ramp up while gauging impact. Please see our updates page for the latest information.

Best,

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/e2dc0b13-0edb-4e14-8b33-90eaa658d65e%40chromium.org.

[sairam...@gmail.com]

Hi Chrome Team/Lily,

We are noticing a strange occurrence on an e-commerce website which basically full-page-POSTs a form to a payment processor. The payment processor (different domain), is supposed to return a HTML with a form (that contains details of payment processing result) and a inline JS which POSTs the form back to our domain.

Our domain relies of cookies (which do not yet have the SameSite directive set) to recoup the session and setup the order. However, in some % of chrome 80 (80.0.3987.132 & 149), we are seeing that cookies are NOT sent. We were presuming, this to be a typical Lax+POST scenario but we have begun doubting that based on live results.

What diagnostic/investigation, then further solutions could we employ with such clients to ensure we are able to provide them with the best experience possible (assuming that we are restricted to using cookies that have no SameSite directive to do our session management/retrieval for the next few foreseeable dev cycles)?

Thanks in advance

S.

On Monday, February 10, 2020 at 1:51:22 PM UTC-5, Lily Chen wrote:

Mike: Lax+POST is enabled in Chrome 80 if you have those two flags enabled. Note that the allowance for POST requests only applies to top-level POSTs, and only if the cookie was created under 2 minutes ago. You can collect a NetLog to see how Chrome is handling each cookie.

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