Google promises next week's cookie-crumbling Chrome 80 will only cause 'a very modest amount of breakage'

Smart websites should be fine – if you're being scummy, beware

Updated Next week Google is scheduled to release Chrome 80 to its stable channel, and says only "a very modest amount of breakage" of websites is expected.

The reason web publishers might see "breakage" – which can mean anything from the loss of certain user-facing features to backend analytics errors – is that Chrome 80 handles HTTP cookies in a different way than its predecessors. The coming changes, intended to improve online security and privacy, mean that web developers need to explicitly declare in website code how they want cookies to be handled if they want to avoid potential problems.

HTTP cookies are files containing data keys and associated values and are created on a web user's local device through website code or server interaction to help with session management and to convey information, which may be necessary or may serve a publisher-oriented purpose like advertising or analytics. They're widely used (and misused) by third-party marketing firms for tracking user behavior and interests to serve targeted ads.

Concern about third-party cookies has proven sufficient that privacy-focused browsers like Brave, Firefox, and Safari have moved to block them by default, a situation that has prompted Google to plan on phasing them out within two years, while coming up with alternative web technology that can inform its core business - behavioral ad targeting.

But before that happens, cookie handling is being addressed because the status quo allows cross-origin information leakage and cross-site request forgery attacks. Google is doing so first in Chrome 80 on February 4, but Microsoft's Edge, now based on Chromium is expected to follow, and Mozilla's Firefox plans to do so as well.

Chrome 80 will look for the SameSite cookie, and will handle cookies for the page according to the value assigned, or by assuming a default value if none has been provided by a site developer.

The SameSite cookie supports three primary values: SameSite=None; SameSite=Strict; and SameSite=Lax.

SameSite=None is what a web developer would set to allow cookies in a third-party context. For Chrome 80, an additional flag, Secure, will need to be set because without it, the browser will reject SameSite=None cookies.

SameSite=None is the current default and it's what a developer would want for a site that has widgets, embedded content, affiliate programs, advertising, or a login that works across multiple sites.

SameSite=Lax places some restrictions on cookies for cross-origin requests. As the spec explains, it "sends same-site cookies along with cross-site requests if and only if they are top-level navigations which use a 'safe' (in the [RFC7231] sense) HTTP method."

This setting is intended to be a middle ground that offers some protection against CSRF attacks via unsafe HTTP methods like POST.

And SameSite=Strict means cookies will only be sent in a first-party context.

What makes Chrome 80's arrival such a potential problem is that it changes the browser's default behavior.

"Cookies that do not specify a SameSite attribute will be treated as if they specified SameSite=Lax, i.e. they will be restricted to first-party or same-site contexts by default," the Chromium Project's FAQ explains.

That means websites using third-party cookies have to change their cookie setting code to specify SameSite=None; Secure or things may break.

Companies like Adobe, Microsoft and Salesforce have been warning about that possibility. Earlier this week, Google's AMP (Accelerated Mobile Pages) project did the same.

About a week ago, Google engineer Lily Chen posted an update on SameSite code changes across the web and concluded, "Overall, we believe the field trial results indicate a very modest amount of breakage."

According to Chen, Chrome maintains a Site Engagement Score (0-100) for every domain with which users interact. Google looked at scores for sites with noncompliant cookies to measure how much they matter to users.

"Of the requests that would have cookies blocked under SameSite=Lax by default, 79 per cent were to sites that the user had no engagement with (Site Engagement Score of 0.0), only 4 per cent 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 per cent were to sites with 'high' or 'max' engagement scores (over 50.0)."

Chen concludes that because the vast majority of affected requests are associated with sites that have little or no user engagement, most of the cookies that will be dropped by Chrome 80's changes will not be visible to users.

In an email to The Register, Augustine Fou, a cybersecurity and ad fraud researcher who advises companies about online marketing, said that while the cookie changes in Chrome 80 further concentrate Google's market power by making it more difficult for third-party ad tech to function, they do represent a real privacy win for consumers.

"It won't affect good publishers much – those publishers that didn't have egregious numbers of 3rd party trackers on their site doing god-knows-what," Fou said. "But it will negatively impact crappy long tail sites that were breaking or skirting the rules as much as possible before."

"It won't affect marketers much either, because using hundreds of targeting parameters before drove no incremental business outcomes for them anyway. Hyper-targeting is the myth that ad tech companies want marketers to believe so they can sell more targeting parameters and charge higher CPMs." ®

Updated to add

Though Chrome 80 is still slated to ship on February 4, 2020, Google now says, "The SameSite-by-default and SameSite=None-requires-Secure behaviors will begin rolling out to Chrome 80 Stable for an initial limited population starting the week of February 17, 2020."