In adtech, we can’t overlook the importance of web browsers. Because we understand how browsers can make or break the programmatic ecosystem. And, as you are aware, Chrome is the market leader with close to 70 percent market share.
While other browsers have enabled ITP to block third-party cookies, Chrome didn’t. It plans to phase out the support for third-party cookies within two years and proposed a set of standards to replace them. But there’s something more immediate, Chrome will limit cross-site cookie sharing with its next v80 update. Specifically, Google announced that the Chrome cookie update to version 80.0.3964.0 (also known as SameSite Cookie Update) would come into effect from February 4th, 2020.
However, due to the outbreak of Coronavirus, Google has rolled back the SameSite Cookie changes. So, you have got more time to make essential changes.
Table of Contents
- What is SameSite Cookie?
- What’s Going to Change With Chrome V80 Update?
- Impact on Advertising Industry
- How Should A Publisher Prepare for the Changes?
- What’s Next?
Let’s dive in.
First off, SameSite cookies aren’t relatively new. Chrome has been supporting the SameSite attribute, but it wasn’t necessary for anyone to use it.
The purpose of introducing the concept was to give website owners control on how the cookies are shared b/w the domains (or parties). Note that the SameSite attribute doesn’t affect who can set cookies, but who can access it (anyone on the page can still set cookies, but they can’t access it as users visit different sites). So, before talking about what is going to change with the Chrome SameSite cookie update, we’ll take a quick look at the basics.
What is SameSite Cookie?
Cookies are set by a website on the user’s browser and they are generally categorized into same-site or cross-site, based on the relationship with the user.
So, if the URL entered by the user in the address bar of the browser matches the domain associated with the cookie, then it is known as the same site.
Whereas, a cross-site cookie is set by a different domain that doesn’t match with the URL in the browser’s address bar.
Chrome’s update to v51 introduced the concept of the SameSite attribute and enabled the developers or publishers to instruct the browser on how to control cookie sharing. These instructions are done by passing values into cookies via the SameSite attribute.
None: SameSite attribute with the “None” value enables the site to share cookies via third-party requests (in other words, a third party can access its cookie from your users’ browsers). This is the default as of now. So, b.com will be able to access cookies as users go from a.com to c.com to x.com.
Attribute Specification: “SameSite=None;”
Strict: Cookies wouldn’t be shared with any third parties and all the third-party cookie requests are nullified. Only the site that sets the cookie can access it; on the same domain. For instance, if example.com sets a cookie and the SameSite attribute is “Strict”, then example.com is the only domain that can access it and it can do so only on example.com. And, if your users are visiting your site from a different domain say Facebook.com or LinkedIn.com, then you won’t be able to access cookies.
Attribute Specification: “SameSite=Strict;”
Lax: All the sites belonging to the same domain can set and access cookies, regardless of whether the user is from a different site or directly landed on your site.
Attribute Specification: “SameSite=Lax;”
What’s Going to Change With Chrome V80 Update?
Basically, Chrome’s v80 update is all about bringing changes to the default behavior of SameSite. As of now, Chrome sets the default value of SameSite cookie to None that allows the first-party as well as third-party websites to set and access cookies in the user’s browser and to track them as they surf different sites.
Unfortunately, many developers and website owners haven’t actively adopted the SameSite cookie values – Lax and Strict. Moreover, the default setting of SameSite cookie to None makes the website vulnerable to CSRF (Cross-site Request Forgery).
Hence, to encourage the web community and make internet surfing secure, Chrome is introducing the following changes to its v80 update:
- Enforce Lax as the default value of the SameSite cookie. That means, if you manually don’t set the value for the SameSite cookies, it will be automatically set to Lax by default.
- If you have defined a SameSite cookie with None value, then the cookie must also have “Secure” to ensure that the browser request is sent by a secure (HTTPS) connection. SameSite cookies that do not adhere to that mentioned requirement will not be accepted. Here’s an example of a SameSite cookie with Secure and None value:
Example: Set-cookie: demo_view = xyz356; SameSite = None; Secure.
Is it Going to Affect the Advertising Industry?
Yes. Chrome’s v80 or SameSite cookie update is going to affect publishers, advertisers, and ad tech vendors as well who are heavily relying on cookies to better target the audience.
So, if you haven’t been aware of what to do, read the next section of this article to prepare yourself for the upcoming changes in the next month.
But, first, to prepare yourself for SameSite cookies, you need to check how many cookies your website has and if the cookies are labeled correctly. In case, you don’t know how to do that, follow the steps given below to check the cookie status in the browser:
- Go to your website. Right-click and select Inspect.
- After this navigate to Console. Here, you can check the status of your SameSite cookies.
You will be able to see the following screen: To make it simpler for you, we have analyzed a website to check the cookies present on the site:
In the image above, you can see the warning text showing two blocked cross-site resources because they haven’t been defined as SameSite cookie with None value. So, what should you do if you see such warnings in the Console?
How Should A Publisher Prepare for the Changes?
As you’re here, chances are high that you’re working with some programmatic partner or any ad platform. Considering it, there might be two situations:
Case #1: If you are working with an advertiser or a platform (think, Facebook) directly, they are likely to cookie your users and have pixels on your pages.
What should you do: In such a case, you must ask them to update the SameSite attribute to “None” in order to send cookies via first-party as well as third-party requests from your website. Along with that, they must specify the “Secure” label to ensure that the cookies are read and sent over HTTPS connections. Otherwise, the cookies will be rejected after the Chrome v80 update.
Case #2: Monetizing the website with a third-party programmatic partner.
What should you do: Here, you need to talk to the representatives and ensure that they have updated their cookies. If not done, the contribution of ad revenue via Chrome v80 might decline. For instance, let’s say you work with SSPs and they haven’t updated their SameSite attribute, then they wouldn’t be able to target users across the site. Basically, they will bid as if the user is completely new to them.
At Automatad, we are proactively working with our publishers and partners to prepare for the update.
Wondering how to check the impact of SameSite cookies on your site? Follow the steps to see what happens to your site after you enable the SameSite cookies.
- Write “chrome://flags/” in the address browser of Chrome (version 76 and above) and press Enter.
- In the “Search flags box, type “SameSite” to filter. From the drop-down menu, select Enable. Relaunch the browser to view the changes.
In the next few weeks, Chrome will start blocking the cookies that aren’t labeled according to the specifications. Since the revenue model of a publishing business depends on audience recognition, analytics, retargeting, and many other factors that further rely on cookies, we recommend you make the changes in the cookies before Chrome’s v80 update comes into effect. Are you still confused about SameSite cookies? Ask us in the comment below.
Update 1: As expected, Chrome rolled out its v80 update on Feb 4. But there’s a twist. Hear it from Chrome itself:
“The enablement of the SameSite-by-default and SameSite=None-requires-Secure enforcement will not be included in this initial Chrome 80 stable rollout.”
So, the industry has some time to update its cookies. How long? Chrome SameSite cookie update page notes that the SameSite attribute enforcement will begin on Feb 17, 2020, for a limited population.
Update 2: Chrome said it is rolling back the SameSite cookie changes temporarily citing the COVID-19 situation — starting from April 3.
“However in light of the extraordinary global circumstances due to COVID-19, we are temporarily rolling back the enforcement of SameSite cookie labeling, starting today”
Don’t forget to subscribe to our weekly newsletter so that you do not miss any such important updates.
Amazing article. Thanks for the write up!
Quick questoin: Do we know if any of the major partners have already switched to the new changes. Especially, Google DSPs and Ad Servers?
Google switched and most of the partners would have done the same. If you want to know the status of a specific partner, you can go to Chrome developer tool > Application > Cookies. Once you click the cookie, you can see all the cookies from the partners and their SameSite attribute. If there’s no attribute, then they haven’t set anything so far.
So as a company who consumes pixels like Facebook and DoubleClick, is there anything that our site needs to do to prepare for this? Or does the responsibility lie with the advertising platforms who supply these tags?
It’s the job of the advertising platforms. But if you are also setting cookies, then you need to make the changes as well.
I have to send POST variables from https to http page within the same domain, but browser doesn’t accept cookie anymore.
In Google developer console there is message for PHPSESSID cookie:
“This set-cookie was not sent over secure connection and would have overwritten a cookie with the Secure attribute”
Please help! What headers should I send?
Hey Damir, Google is rolling back the SameSite Cookie changes. But just to stay safe, we suggest using the updated SameSite cookie attribute.