Intent to Implement and Ship: Cookies with SameSite by default

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.

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.

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)?

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 <[email protected]> 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 <[email protected]> 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.