Chrome is joining the ranks of Firefox and Safari to change how they deal with cookie tracking on your site.
See how this could radically impact your ad revenue and metrics for other tracking cookies.
What is the Warning?
I have been seeing this type of cookie warning since the Nov Chrome update.
A cookie associated with a cross-site resource at <URL> 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
Firefox and Safari had already implemented their own new privacy improvements back in the summer of 2019 that could wholesale block third-party cookie tracking if turned on. And that will become the default setting soon.
But with Chrome having over 50% of the browser market share, a change to how it handles cookie tracking is going to have a much wider, and deeper impact.
Read on to see why this is suddenly a problem.
NOTE: It is unclear at this time if this new Chrome policy will be on by default in Chrome 80 come Feb 4, 2020, or if it will just be an option that can be turned on. Either way, it will start having an immediate impact on advertisers.
Why We Need Better Cookie Compliance
The Internet Engineering Task Force (IETF) is an international consortium of internet vendors and designers who help set the standards for protocols so that all internet hardware and software can interact globally.
These directives also include security measures that must be adhered to by the browsers we use too, like Chrome, Firefox, Safari, Edge, and Opera.
In Nov 2019, the IETF proposed changes for Incrementally Better Cookies.
The changes the IETF proposed will primarily affect cookies that track site user behavior and are focused on protecting the user’s privacy with the way the tracking info is sent off the site to a 3rd party.
The IETF is also concerned about Cross Site Request Forgery (CSRF) attacks.
This type of attack is when a malicious site causes the browser to perform an unwanted action, usually resulting in theft of personal data, changing a password, making an unintended purchase, or embedding of malicious code.
So yes, we do want better protection from this! And labeling cookies properly so their actions can be properly monitored is one way to help.
Two Types of Cookies
There are two types of cookies on websites.
First-party cookies – these are created by a site, and only for that site’s use.
For example, BlogAid has a member site for the DIY SEO and Gutenberg courses.
As a member, if you choose to allow your browser to remember your member login info, then that first-party cookie is set on your computer for that site, and that site alone. That info is not sent to a 3rd party, or other site.
First-party cookies are also set in your browser for things like:
- Links – so you can hit your browser’s Back button and return to the previous web page
- Form GET/POST info, for when you submit a form, so it can send you to a thank you page on the same site
- Image – so you can click on a linked image and go to another page within that site or another site
- iframe – for any 3rd party embeds, meaning content from another site is embedded in the site being viewed
Third-party cookies – these are created by another site to send tracking info to it when something on the current site is viewed or clicked.
Third-party cookies include, but are certainly not limited to:
- Ads – both view only and PPC
- Facebook Pixel tracking
- YouTube views and watch time
- Google Analytics
SameSite Cookie Attributes
All cyber security consortiums are really cracking down on holes all over internet security and imposing new security standards.
A few of those new security standards include:
- All sites being delivered on the encrypted HTTPS protocol
- Forcing all bots crawling a site to properly identify themselves
- Forcing all tracking cookies to be properly identified and options given to not be tracked
For the most part, the cyber security communities have not been too focused on first-party cookies, as they are generally for internal use only.
But the new IETF directives suggest that ALL cookies be better identified.
This is accomplished by assigning a SameSite attribute to each cookie.
The three SameSite Cookie attributes are:
How No Attribute Cookies Will Be Treated
Any cookie without a SameSite attribute will be considered SameSite=Lax.
This means that the cookie will be restricted to first-party contexts only.
Basically, the cookie cannot send tracking data, or any data, off the site to another site where that data may be collected.
That’s fine for our first-party cookies.
But, it breaks any data collection for third-party cookies.
You know, the kind of cookies that we rely on for analytics and ad and affiliate revenue.
iFrames Will Be Affected Too
I use iFrame to embed Facebook and YouTube videos so that lazy load can work on them and make for faster page loads. (See how to embed iFrame videos here.)
Doing it this way also keeps the actual video and all of its tracking cookies from loading until the video is clicked too.
But, the minute that YouTube video is clicked, up to 17 Google related cookies get loaded. Some depend on whether you are logged into Chrome or not.
17 cookies. I kid you not.
How Third-Party Cookies Must Be Attributed
Every third-party cookie on a site must be set to SameSite=None; Secure for the data it holds to be sent to the collecting agency.
What We Can’t Control
Here’s the rub.
We, as site owners, can’t control how those third-party cookies are set or attributed.
That’s because the code we use for the cookie tracking comes from the 3rd party vendor.
In other words, the Facebook Pixel tracking code is provided by Facebook.
Until they provide us with new code, we can’t fix this issue on our site.
Same with ads – actually, it’s way worse with ads, as they change on every new page/post load.
Ad Tracking Cookies
AdThrive says they are working on it too. (Sorry, no link available to a public post about what they are doing, at least that I could find.)
Here’s my take on this.
We had to implement a Content Security Policy (CSP) when we converted our sites to HTTPS because so many ads were still being delivered via HTTP that we were losing our HTTPS secure status over it.
And that’s still happening – 3 years later.
In fact, even as late as last year one low-barrier-to-entry agency was still telling site owners not to convert to HTTPS or they would lose a lot of ad revenue. Geez!!!
I REALLY don’t have a lot of faith that any ad agency will get this issue resolved anytime soon.
It reminds me a LOT of GDPR. I asked for months what they were going to do about it. Crickets.
And then in the final week before the GDPR deadline all of them suddenly realized that they would not be immune from the need to require some sort of cookie tracking notification and policy.
And everyone scrambled like mad to get some directives thrown together.
This new cookie thing feels the same way to me.
In fact, I feel like 1 of only 10 people who are even concerned right now.
Conflicting Browser Support
Oh, this just keeps getting more fun all the time.
Even if everything is set right to make the Chrome browser happy with cookie attributes, there is currently a bug with Mac OSX and iOS that causes the SameSite=None attribute to be interpreted as SameSite=Strict.
That means the cookie data will not be sent to the 3rd party if the site visitor is using the Safari browser.
What We Can Do
We need to ensure that the first-party cookies we use internally on our site have the proper attribute.
Fortunately, there’s a super easy way to do that.
Change the PHP level at your host to 7.3
PHP 7.3 includes directives that will satisfy how first-party cookies are attributed.
I’ve been talking about updating your PHP version for 3 years now. It’s a big part of your site’s security and speed, as PHP is the coding language of WordPress, plugins, and themes.
I also just remade my video tutorial on How to Check or Change Your PHP Version.
It now only includes how to do this on cPanel, but it also now includes both shared and VPS or reseller hosting packages. Plus it includes how to access and set your PHP options.
If you are on a host that does not have cPanel, you can contact them for help.
SameSite Cookie Plugin
If you can’t get your site to run on PHP 7.3, you really need to fix that issue asap. PHP 7.4 is already out and we’ll be needing to upgrade to it by the end of 2020.
But as a temporary stop-gap measure, you may be able to use the SameSite Cookie plugin.
NOTE: I have not used this plugin and can’t vouch for it. Use at your own discretion and risk. Upgrading to PHP 7.3 is the preferred way to go.
When No First-Party Cookies are Attributed Properly
If you don’t take measures to ensure your site’s first-party cookies have an attribute assigned, then they will be treated as SameSite=Lax.
That means that no data will be sent to a 3rd party collection agency/vendor.
That’s fine for first-party cookies, I think.
But, treating third-party cookies as SameSite=Lax means you lose that tracking data.
That could impact your ad revenue and any metrics/analytics you gather from the site.
I wish I had a solution for us.
I wish we didn’t have to deal with this.
I wish there were more info for me to give you clear directives and suggestions to fix this and so it would not turn into a fiasco.
That may or may not be coming.
We’ll wait, and we’ll see what happens when Chrome 80 releases on Feb 4, 2020.
We’ll see if they have the cookie blockers turned on by default, or if a whole bunch of people decide to turn that option on.
We’ll see what the ad agencies do about this.
And I’ll be watching it like a hawk for you.