By Alex Masip, Head of Data at Labelium
Among the changes that major browsers such as Safari and Firefox are making in the management of third-party cookies, Chrome also plans significant modifications in its version 80, expected to be released in February 2020.
In this post, we explain the context, the changes Chrome has made, and the implications of those changes. We will also discuss how to test if our site is ready to manage them correctly.
First and third-party cookies
Generally, we understand as first-party any data that belongs to us directly, without the intervention of third parties. In the context of cookies, first-party cookies are those that are managed directly from the main domain of the site. In other words, all the cookies where the main domain is the same as the site we are currently visiting.
On the other hand, third-party cookies are those belonging to other main domains of the site we are in.
Third-party cookies are useful for maintaining overall consistency in user navigation. For example, if we add a YouTube video on our site and the user is logged in to their video platform account, has seen the video before or has marked it to watch it later, all these scenarios are handled with a third-party cookie. Without this cookie, the user must leave our site and go to YouTube to log in again.
The problem is that there are many not-so-good uses of this type of cookie. The best known is its use to track the user throughout their browsing for profiling and online advertising purposes. Although, there are also potentially far more serious security abuses.
The management of third-party cookies across all major browsers
Legislative changes such as GDPR and public awareness of online privacy management have led to major changes in how leading browsers such as Safari or Firefox handle these third-party cookies.
Safari started this battle against online tracking in 2017 with its ITP (Intelligent Tracking Prevention) which already prevented the use of third-party cookies. ITP has evolved and we are now in 2.3, with which Apple also protects itself against some first-party cookies misuses and the employment of other tactics such as local storage.
Firefox has opted for a similar, albeit less aggressive, tactic. Instead of blocking all cookies by default, it uses a blacklisting method. It checks if the cookie belongs to a domain identified on the list of domains (disconnect.me) that run advertising and tracking.
Chrome has chosen the least aggressive tactics so far. It does not block first or third-party cookies by default, although it does offer that option to its users through its privacy management.
The big change that comes with Chrome version 80 is that changes are active by default, without the user having to activate them explicitly.
Cookies management on Chrome 80
Chrome, from version 80 onwards, will start to force the safe use of the SameSite attribute for third-party applications.
The SameSite attribute is not new, but it has not been used regularly until now. The SameSite attribute offers three value options:
SameSite=Strict.- Purely first-part use SameSite=Lax.- An intermediate level that allows certain uses in a third-party context. The use of the cookie is allowed on external domains when they come from a direct link, for example, to keep a user logged in. Although, it does not allow the use of the cookie by other methods such as POST SameSite=None.- Standard third party use
The big difference in this Chrome update is that it forces the SameSite=None to be declared as safe. In other words, the following will be rejected:
Set-Cookie: promo=abc123; SameSite=None
Therefore, the following should be used:
Set-Cookie: promo=abc123; SameSite=None; Secure
In the first case, Chrome will reject the cookie and if it is not declared, SameSite will handle the cookie as if it were SameSite=Lax, thus blocking its use by a third party.
How does this change affect me?
There is no need to worry about Google’s cookie management, but if we have cross-site functionalities with other cookies, it’s important to make sure they meet the standard. Otherwise, we will find features that no longer work.
Important difficulties to be taken into account:
- Not all languages and libraries allow the value “None” as of today. In these cases, it must be declared directly in the cookie header. For more information, you can consult the following Github repository.
- Some older browsers are unable to handle the None attribute properly. List of incompatible browsers.
How to test the effect on my site
It is highly recommended to check as soon as possible if this change will have a significant effect on our online sites.
To test on Chrome 76+ versions:
- Go to chrome://flags and activate #same-site-by-default-cookies and #cookies-without-same-site-must-be-secure. Restart the browser.
- Start the tests. It is especially important to check everything related to navigation flows that must maintain a login, changes between domains and cross-site content. It is also important to note that due to the two-minute limitation of “Lax+POST” it is recommended to test any flow that involves POST that has delays of more or less than two minutes.
- If the site stops working as it should:
- a. Start by disabling #cookies-without-same-site-must-be-secure. If this solves the problem, then we have cookies with the value SameSite=None that are not secure.
- b. Deactivate both flags. If this solves the problem it is necessary to identify the cookies that are accessed cross-site and apply the SameSite and Secure attributes to them.
