Chrome’s SameSite Feature Updates Could Be More Significant than Apple’s ITP

Apple’s Intelligent Tracking Prevention (ITP) privacy-related features have had a lot of press in the last few months. Not to be outdone, Google immediately jumped on the bandwagon with the goal to convince us they have a better solution. Since Google’s Chrome has a significantly larger install base on laptop/desktop machines these changes could have a bigger impact on third-party cookies than Apple’s features in Safari.

With the recent release of Chrome 76 we can test these features today before they become the “default” behavior in the Chrome browser.

This post (https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html) links out to this page https://web.dev/samesite-cookies-explained/ which states:

“Chrome 76 introduces a new same-site-by-default-cookies flag. Setting this flag will shift the default treatment of cookies to apply SameSite=Lax if no other SameSite value is provided. This is a move towards providing a more secure default and one that makes the intended purpose of cookies clearer to users.”

The “SameSite” default setting described here means that Google Chrome will restrict reading of cookies — by default only first party cookies will be readable (cookies only readable on the website where they were created).  This behavior is not-yet-default, but we can test it before it becomes the default behavior.

And now, with Chrome 76 released this month (Aug 2019) we can try out what they are talking about. We can also, in theory, see the impact of what will likely take place in all Chrome browsers as soon as 2020.

Why do I say 2020? Because one of the discussion forums where the Google people talk to Safari people mention their goal to release this new feature as the “default” setting in 2020.

Mike West says on June 28, 2019:

“Note that Chrome is currently targeting ~M80 (February) to push a `SameSite=None` requirement on third-party cookies (https://www.chromestatus.com/feature/5088147346030592).”

Version 80 of the Chrome browser has a target release of February 2020.  Maybe (like many software projects) this slips a month into March or April 2020. Whenever it arrives, it could be a more significant browser update than Apple’s ITP because Chrome is a much more popular web browser on the web.

So, what will likely happen around March 2020?  We can flip the switch in Chrome 76 to get a sneak peek at the default behavior expected in Chrome 80.  Here are the steps for you to test it out on your own.

Step 1: Chrome -> About Google Chrome -> Update to version 76 or later

Step 2: In Debugging mode, visit a site that is likely to set advertising cookies such as yahoo.com

View -> Developer -> JavaScript Console -> Network

The following screenshot shows the network sends your third-party cookie across to advertising.com

Note the “cookie: APID=UP55d0b9ba-b7d5-11e9-b190-06e1d9908fb9″ at the bottom of the Headers.  That means that the browser automatically added this cookie to the outgoing “Request” from the browser — the browser allows this cookie to be read by the advertising.com domain.

Also note, you can filter your network to the first part of your id — in my case, I filter on “UP55” and see this same APID value is sent to other vendors BlueKai and Eyeota.

Step 3: Close your ‘yahoo.com’ browser tab and enter “chrome://flags” in the URL

Step 4: Choose “Enabled” for the “SameSite by default cookies” flag (screenshot of Step 4 below)

The fine print is that if the developer doesn’t use SameSite=None, then Chrome will block this cookie from being read across domains.

Step 5: Click “Relaunch” at the bottom to close and restart your Chrome Browser

Step 6: Open a new browser tab, and launch the Console again.

View -> Developer -> JavaScript Console -> Network 

Step 7: Enter ‘yahoo.com’ to see if your cookies will be part of the Headers going to advertising.com (or not)

This time, notice that your cookies are not sent to advertising.com.  With this flag enabled, Chrome detects this is a third-party domain (doesn’t match yahoo.com) and blocks the cookie from going out (screenshot below).

No “cookie:” with my APID value is sent along this time!  Try turning off the feature and running through Steps 3-7 just to make sure that it’s the new feature that has changed.

What does this mean for the digital marketer?

Well, it means that early 2020, when everyone updates to Chrome browser version 80, that many ad impression-related cookies will not be available to advertisers—they won’t be able to store information about your browsing habits across multiple web properties.  For digital marketers, you are now limited to simply measuring what ads are clicked on (as opposed to what ads were viewed).

The Chrome browser now blocks this cookie from being read by third parties by default.  But, they do allow for an advertiser to indicate up front that they plan to read this cookie across domains at a later time. It could happen that advertising.com will update their cookie-setting logic to set “SameSite=None” and they are still able to read their cookie? This appears to be an option in JavaScript as noted here:

document.cookie = ‘cross-site-cookie=bar; SameSite=None; Secure’;

It seems like this would work. Also, very likely, Google Chrome would keep track of these cookies and let me (the browser user) know which domains are using “SameSite=None” for their cookies.  The web locations setting cookies would now explicitly state that, “Even though I set this cookie in an iframe where it is first-party to the iframe, I intend to later read it in a third-party context.”  Google’s SameSite enforcement in their Chrome browser version 80 means that it’s time for developers to let everyone know what they plan to do with cookies.

We’ll be keeping an eye on Google, Apple, and other browser developers to help you keep your data supply chain up-and-running as the cookie continues to evolve rapidly over the next few months. If you haven’t caught up on Apple’s ITP yet, check out my recent webinar on the topic.