#GTMTips: Chrome Samesite Warnings for Google Tag Manager

Update 17 February 2020: Google Tag Manager’s Preview mode cookies have been updated with the necessary flags, so they will not break once SameSite enforcement begins.

If you’ve opened the browser console in Google Chrome (since Chrome 76), you might have seen a bunch of warnings in a yellow background related to something called a SameSite cookie attribute that is either missing or incompletely set for cookies set on external domains. If you use Google Tag Manager, especially in Preview mode, you might have seen a warning about the http(s)://www.googletagmanager.com domain.

Even though the warning is very prominent, hogging up some prime real estate in the browser console warning, it is, for now, just a warning.

This article article briefly explains what the SameSite hoopla is all about, and how it relates to Google Tag Manager.

Tip 108: SameSite cookie attribute and Google Tag Manager

This is the full text of such a warning:

A cookie associated with a cross-site resource at https://www.googletagmanager.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

What is the SameSite attribute?

The SameSite attribute is configured when the cookie is set, and is used to describe the contexts in which the cookie is available for reading.

It has three possible values:

• Strict - A cookie set with this SameSite value is only available in requests where the request host shares the public suffix of the request origin (domain.com would be the public suffix of www.domain.com, sub.domain.com and ecommerce.blog.domain.com). Thus if a page on domain.com requested a resource from www.domain.com, the SameSite=Strict cookie would be sent with the headers. But if the page on domain.com requested a resource from doubleclick.net, any SameSite=Strict cookies written on doubleclick.net would not be included in the request.

  Notably, This applies to navigation as well - when you navigate from domain.com to anotherdomain.com, any SameSite=Strict cookies written on anotherdomain.com would not be included in the request headers.

• Lax - If set with this value, the SameSite cookie behaves similar to Strict cookies, but it does allow for top-level navigation to include the cookie in the HTTP headers. Thus, if the user moves from domain.com to anotherdomain.com, the SameSite=Lax cookies written on anotherdomain.com would be included in the request headers.

  This is also the default value for cookies without an explicitly set SameSite attribute.

• None - This attribute allows the cookie to be accessed in first-party and third-party contexts without restrictions.

Basically, if you have a cookie that needs to be distributed to multiple domains in HTTP headers, you need to set the SameSite attribute to None or it will cease to work when SameSite becomes enforced.

The catch is that a SameSite=None cookie must also have the Secure flag, or it will not work.

If the cookie does not have the SameSite parameter, the default behavior is Lax. Thus, again, all cookies intended for third-party access would cease to work unless explicitly set to None.

This is a great article for SameSite information: SameSite cookies explained.

What’s the deadline?

The SameSite change needs to be implemented by February 4, 2020. On that date, Chrome 80 will become the new stable build, and users upgrading to it will see that the SameSite attribute is enforced.

Thus, after that date, any cookies sent with cross-site requests must have SameSite=None and Secure flags or the browser will reject them.

So what about Google Tag Manager?

You might have two concerns about Google Tag Manager.

1. Why does Google Tag Manager use third-party cookies?! - Simple: Preview mode. GTM uses a third-party cookie set on www.googletagmanager.com to ensure that if your browser is in Preview mode, then your browser is privy to the container draft rather than the latest, live version.
2. What can you do about GTM’s SameSite warnings? - Nothing. If you read the previous chapters carefully, you’ll see that the SameSite change needs to be done by the party setting the cookie, i.e. Google. So Google needs to update the authentication cookies written on www.googletagmanager.com to include the SameSite=None and Secure flags for GTM’s Preview mode to continue working in Chrome (and any browsers that similarly choose to enforce SameSite).

Luckily, there is confirmation from the Google Tag Manager team that they will make sure the cookies are updated before the SameSite change enters the stable build.

Similarly, I’m positive all other Google properties that require cookie access in third-party context will be adequately processed as well.

The big concern with SameSite might not thus be the vendors (e.g. adtech) that use cookies in third-party contexts to run their tracking schemes, but rather in-house setups where things like authentication, shopping carts, and SSO are handled with a consolidated domain passing persistent information in third-party cookies.

It’s a potentially momentous change, so if your company’s IT department isn’t on top of things, they’re running out of time.

To find out about the scope of this change and how ill-prepared the general public is, I recommend looking no further than Zach Edwards’ Twitter feed, as it’s full of examples where things have gone (or are going to go) awry.

Zach’s webinar on the topic is also illuminating (you can find the presentation here).

I hope this article was illuminating - please let me know in the comments if you have further concerns about SameSite cookies!