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
Ads that are inserted by ad agencies are particularly problematic as they may contain cookies to be sent with a request from both an image and a javascript.
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:
- None
- Lax
- Strict
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
Mediavine says they are working on this issue.
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.
See this post for more on the Safari cookie bug.
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.
If you need more info about why you have to upgrade your PHP version, read this.
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.
What’s Next?
Wait.
I wish I had a solution for us.
I don’t.
I wish we didn’t have to deal with this.
We do.
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.
This book could save you hundreds of dollars and months of frustration. Get it free with your subscription to
This is an amazing read MaAnna. Personally I am concerned of cross-site cookies by Google and Hubspot. Google alone has more than 40 cookies! Strangely not much buzz going on about this thing among the webmasters.
(I have sent a message to you on Facebook, please do check out whenever possible.)
No kidding, Rajesh. I was stunned at how many of Google’s own cookies got flagged with warnings.
best information…..
Fantastic roundup of this important situation!
Thank you, Tipper
Now, if I understand this correctly it should not affect any Amazon links. The link sent from any site TO Amazon contains the account identification (not only a cookie), so the click arrives at Amazon with the identifier ‘BlogAid’ (just as an example). Then Amazon sets a cookie for this browsing session, a cookie which is associated with your account id. Correct?
Or am I completely off target here?
I honestly don’t know how it will affect each cookie type. So can’t say how Amazon tracking will be affected.
Thank you so much for this post. I have been kind of worried about this, since my site depends on Amazon Affiliate links. I’m still not sure I understand all this correctly, but I’ve upgraded to php to 7.3 and will hope for the best for now.
The PHP update will take care of our first-party links. It won’t do anything for our third-party links. I’m hoping for the best with all of this too!!!! And will keep us all posted with updates.
This is a great post, MaAnna!
I do want to provide a little insight into GDPR/CCPA and how that’s been handled by Mediavine, at least. Preparing for both of those was *definitely* not a last minute thing. We had meeting upon meeting with our lawyers, who were researching every new article published. Warnings about GDPR and CCPA started coming before either bill had been finalized and passed.
Everyone looking for answers on exactly how it would be handled seemed not to realize that what needed to be handled had not even been decided on by the lawmakers, if that makes sense.
CCPA, for instance, did not fully communicate all that would be required until December. That gave our engineers just a few weeks to implement a solution that was compliant with the final, truly final, requirements.
Luckily, we’d already been through this with GDPR, and were able to quickly institute some similar solutions. But not every company has 16 engineers at its disposal like Mediavine does. I can only imagine the hoops that have to be jumped through to get solutions in place.
I can only speak for Mediavine, but I’ll tell you that we very much care. Right now there’s a 2-year ticking clock on a solution for Chrome, but there’s more at play than what Mediavine decides to do about it.
There are DSPs, SSPs, exchanges, and advertisers that all have to agree on how to handle this new requirement. Until everyone agrees, no one can start building solutions. So that’s the discussion happening right now, around the world.
Everyone agrees that there needs to be tighter security around this, as Steve wrote in his blog post that you shared (thank you), but as yet, not everyone is on the same page.
Our goal at Mediavine is to make sure we’re paying attention to all the moving parts and creating agile solutions that will fit whatever comes down the pipeline. We may not broadcast every update that comes down the pipe, but that doesn’t mean we’re ignoring the situation in any way.
I hope that helps your readers understand where Mediavine is on the subject. If I can answer more on this, please let me know!
Thank you for your reply, Amber. And for bringing up the fact that so much of this is still gray area and not under any one entity’s control.
My recollections of GDPR are radically different, as there was no published info until the last two weeka prior to deadline for me to be able to advise my clients on what to do for their site side of things. While I can understand that ad agencies can’t always publish the things they are working on, it does leave folks like me in a last-minute lurch for preparing clients, in a holistic way, for big changes. I have to help them coordinate whatever the ad agencies do with what they need to do for their whole site.
As an example, the CSP Mediavine added to their plugin, for blocking insecure mixed media so that the site could retain HTTPS status does not work with the top caching plugin I use and recommend. So we have to hard code it that CSP instead. Once discovered, I was able to work with Mediavine to alert about the situation and share the directive syntax that worked with all caching plugins. To my knowledge, the CSP code in the Mediavine plugin has still not been changed.
While we can agree to disagree about correct code syntax, the fact is that it doesn’t work with a top caching plugin. And I have to make it work for my clients. There are thousands of other site owners who don’t even know this is an issue.
Mediavine is most certainly not the only entity I have to combine into coordinating with what else is on my client’s sites to make work.
For this latest development with the cookie tracking, I spent hours and hours and hours researching over week’s of time trying to find answers for my clients, only to find vague statements of “we’re working on it”. While you’re in the know at a deep level of what may have to change for your site code, I’m still in the dark.
And I’ll still have to deal with this after the fact, not just with what Mediavine produces, but what all ad agencies, Facebook, YouTube, and all other such 3rd party tracking cookies implement.
Plus, I have to make it all work together with nearly no published technical info whatsoever. The research hours I have to donate are tremendous!!! And that takes me away from paying gigs.
As you mentioned, there are multiple entities involved, some of which we have no direct contact with. And I’m sure this will be a rolling issue for the entire rest of the year.
It’s my job to stay on top of it as much as I can. That, in the face of so many site owners burying their head in the sand about it today. They will be so glad somebody took the time to find the holistic answers for them when the poop hits the fan, just like they did with HTTPS and GDPR and whatever else comes down the road.
What else I will say about it is that I have very high faith that Mediavine, above all other ad agencies, will research and implement the best solution possible at the time, and stay on top of changes. My clients love and trust Mediavine. I love and trust that Mediavine is totally committed to excellence in all things. In fact, all the time I have been talking about this in my Tips Tuesday posts, I have said that I’m watching to see what Mediavine does with this. You are the standard for ad agencies in my book.
Thanks for sharing this.
Since I am not a tech person, I do have a question:
If my site uses a third-party company’s firewall & SSL (not through my hosting company) do you think this would cause any issues updating the PHP? Thanks.
I really would not want to take a guess at that. Best to ask your host.
Super helpful, as always. Will be interesting how this all rolls out.
If there are solutions for it, nobody is posting them. I’ll keep an eye out, though.