SameSite / Secure Reference
There is a new update coming to Google Chrome (and other browsers), starting in February 2020 that can affect how tools and scripts track users. In order to resolve this problem, you must first identify whether or not it will be a problem on your site. Below, I’ve offered basic instructions on how you can determine if your site has scripts with the SameSite Warning.
Diagnose The Problem Through Chrome Developer Tools
It is recommended that you review your homepage and one other important page in Chrome Developer Tools > Console. You will be looking for the following error:
A cookie associated with a cross-site resource at <domain> 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.
Here is a quick visual for how to review using Google Chrome’s Inspect contextual menu.
If you find these errors, it means that Chrome, in early February 2020, and other browsers, eventually, will stop allowing 3rd party site scripts to set/read cookies on your site if the 3rd party does not explicitly state that the cookie should be allowed cross site, and handled securely.
This is not a change that companies can make to their own sites in most cases, and is something that their vendors or tracking partners need to make. There would be some consideration for clients that are using CDNs to serve code which places cookies if the CDN is on a separate root domain from the main site.
Essentially, as far as I can tell, the change required is below.
For cookies set from scripts on external domains, the following should be used to set the cookie:
Server: Set-Cookie: widget_session=abc123; SameSite=None; Secure
Essentially, up to this time Google Chrome has treated cross-site cookies as
SameSite: None and now they are changing to
SameSite: Lax. They also established a requirement that Secure accompany
SameSite: None to be valid.
What Happens If I Ignore A SameSite Warning On My Site
The harm in not fixing this is that sites may lose data where scripts need to store cookies in order to track user information across visits or pageviews.
This document explains the issue well, and can be sent to site owners for reference by their developers: https://web.dev/samesite-cookies-explained/.
I think this mostly has to do with your vendors. If your vendors aren’t setting cookies appropriately the feature associated with those cookies may stop working.
They may not stop working altogether, but analytics vendors may see a higher count of uniques, for instance, if they don’t update their code in time.
Basically what you need to do is go to your site, open up the dev tools console in Chrome and figure out if any important vendors are throwing these warnings. For example, on logflare.app, we have four warnings but one is from an embedded Data Studio report, and the others are from Twitter embeds. It doesn’t matter to me if those cookies get set.
And make sure to open in an incognito window with no extensions enabled because browser plugins can also cause these warnings.
The bottom line is that taking time to determine if these errors are on your site now, and then resolving them, will save you from loss of important marketing data going forward.
Here are a few additional resources to learn more about the SameSite cookie issue. The post by Detlef Johnson is a really deep exploration, and worth a read.
- SameSite requirements for cookies: What SEOs and developers need to know (SEL)
- SameSite cookies explained (Web.dev)
- Canonicalized URL is noindex