The SameSite Update for Google Chrome cookies, deconstructed by an expert.

Daisy Sajnog3 min read

First-party vs. third-party cookies
Simply put, first-party cookies are set on your domain and are read by your domain. If a cookie’s domain matches the URL address in the browser, that’s a first-party cookie. Subdomains are generally counted as part of the same site, so www.website.com and hello.website.com would be counted as first-party. First-party requests can be labelled as SameSite=Strict or SameSite=Lax.

Third-party cookies are when the cookie domain does not match the address bar of a site. In digital marketing, a lot of services used to track traffic between sites will likely be utilising third-party cookies so that marketing activity can be attributed correctly to its sources. These requests should be labelled as SameSite=None.

SameSite explained
The SameSite update will require website owners to explicitly label the third-party cookies that can be used on other sites. Cross-site cookies will be blocked in updated browsers if they fail to specify SameSite=None; Secure when setting the cookie.

With the current Chrome versions (79-80), there is a 50% chance that users will be delivered the new SameSite restriction behaviour and cookies without the proper labelling will be blocked in the browser. Chrome currently holds 58.2% of the overall browser market, according to W3Counter, so it’s likely that this could impact a segment of your audience in some way.

Google has summarised the recent change and what you need to do in this video:

You can also read the SameSite changelog on Chromium Projects.

And there’s some additional technical reading on SameSite cookies from Google:

What next?

What we’re doing
Fountain is reaching out to the service providers we work with to ensure that any cross-site cookies being created by their snippets are following the new recommended structure. This includes Google, Facebook, Bing, LinkedIn and additional tracking providers like Yomdel, ResponseTap and CallRail.

What you should do
We recommend you pass this information on to your site developer so that they can:

  1. Confirm any cookies being set by your domain on other sites are:
    1. specified with SameSite=None; Secure
    2. served over https
  2. Check your site code for any 3rd party scripts dropping cookies and record whether these are in line with the new SameSite requirements.

Developers can easily see which cookies are affected by the update by checking the development console of a site in Chrome. If these messages aren’t appearing, they can be enabled by navigating to chrome://flags/ in the Chrome browser, filtering by SameSite and enabling:

Once you’ve highlighted which third-party services have blocked resources, we recommend you reach out to them and highlight this update so that they are able to amend their cookies accordingly.

It is the responsibility of the developers behind the domain managing the cookie to label it correctly.

Summary
As technologies evolve we gradually unearth legacy issues which were never intended as part of their behaviour. Cookies are incredibly useful nodes of text which have allowed data to travel across the internet, and their capabilities have grown far beyond their initial concept.

As user privacy becomes an ever-increasing focus, browsers need to develop ways to address these privacy-leaking features. SameSite is a best-practice feature that will help remedy privacy and security concerns, which would otherwise leave user data vulnerable in the Wild West of the World Wide Web.

Further reading

Google Developers

Chromium Blog

Tech Crunch

You May Also Like…