The impact of Chrome 80 SameSite cookie update on personalization

A high-level overview of the Chrome version 80 SameSite update, and how Dynamic Yield has adjusted its cookie settings according to the new requirements.

VP of Global Marketing, Dynamic Yield

The Chrome version 80 SameSite cookie update is part of Google’s continuous efforts to improve privacy control and security across the web. This article provides a high-level overview of the update, as well as how Dynamic Yield has adjusted its cookie settings according to the new requirements.

In May 2019, Google announced it was changing the way its Chrome browser handles cookies. In an attempt to improve privacy and security across the web, gradual rollout of the new model began in February of 2020. Since then, many are still wondering what the update actually means and whether or not their personalization efforts will be impacted. 

So let’s dig in a little deeper, putting some of the concerns associated with the release to rest.

What is the Chrome 80 SameSite cookie update?

First, a quick lesson on first- and third-party cookies to help create a little context for those who don’t typically tango with developer lingo, thanks to our friends at Google: 

Cookies are small pieces of text data, that a site sends in its response. Your browser then stores these and sends them back to the associated site on eligible requests. If the site in your browser matches the site in the request, then that’s what’s referred to as a SameSite request, or a first-party cookie. 

Conversely, if the site in your browser does not match the site in your request, then you’ve got a cross-site or third-party cookie. The same cookie may be sent in both of these scenarios. So first, or third-party is about the context of the request, not a specific property of the cookie.

Quick Reference: Cookie Terminology

Cookie

Small pieces of text data sent from a site and stored by the browser.

Request

What is sent from the client to the server (what the browser provides).

Response

The cookies that you want to place in the browser.

First-party data

The site in your browser matches the site in the request (a SameSite request).

Third-party data

Requests for resources that are pulled from a different site.

In enforcing its “secure-by-default” cookie classification system, Chrome has started restricting access to only first-party cookies, or SameSite requests, unless otherwise specified. With the default browser setting now operating under the assumption that all cookies should be protected from external access, developers need to begin explicitly marking cookies for third-party access. 

The updated cookie settings, which specifies when and how to fire cookies in first- or third-party situations, are reflected in the following SameSite attributes:

  • SameSite=Lax
    All cookies without a SameSite attribute will be treated as SameSite=Lax, meaning they will be restricted to same site or first-party requests only. Read further about it here.
  • SameSite=None; Secure
    Cookies with the SameSite=None; Secure setting will be available for external access in third-party contexts, so long as communications are handled over HTTPS. Therefore, any cookie that is not marked Secure will be rejected. Read further about it here.
  • Developers can also still apply SameSite=Strict to prevent cross-site sharing altogether. However, this setting can affect the browsing experience negatively, as important data from external sites cannot be accessed to assist in things like populating visitor information for easy login to online accounts or apps. 

But despite the options available, cookie management has largely gone underutilized by developers, motivating Chrome to take matters into its own hands. In doing so, the updated browser settings will prevent a number of unnecessary threats, including those such as Cross-Site Request Forgery (CSRF) attacks.

A good explanation about SameSite cookies can be found here

To recap, Google has changed the default from None to Lax when a cookie does not specify a SameSite value. From now on, new or existing cross-site cookies without the Secure attribute as well as proper labeling for cross-site cookies, will be unusable on Chrome 80 and above.

What do I need to know as a Dynamic Yield customer?

As of February 2nd, 2020, Dynamic Yield is fully compatible with the Chrome 80 SameSite. All of our servers have been updated to set the appropriate cookie attributes, and because they are correctly labeled as SameSite=None; Secure, the browser should not take any action to block these cookies. 

In summary

With Dynamic Yield’s complete compliance, the Chrome 80 SameSite cookie change does not affect our customers and there is no action necessary on your end to continue using our personalization platform safely and securely.

Dynamic Yield promotes consumer privacy and we will continue to update our own solutions to ensure brands can accurately track important web activity while abiding by the many new browser privacy policies put forth by the likes of Chrome, Apple (we’re already compatible with ITP), and others. 

For any additional questions, please contact your Customer Success Manager.