Not all cookies are created equal – like Mrs. Fields Cookies vs. Oreos or Ben’s Cookies vs. Girl Scout Cookies. The same goes for web browser cookies – like first-party vs. third-party. The differences in cookie type are part of what is happening with Google Chrome’s cookie change that will be implemented in the beginning of February. There are a lot of concerns around how these changes will affect your site tracking and records, Omeda’s web behavioral tracking (Olytics) functionality and known subscriber information. Let’s talk about what’s happening and what to expect.
The Backstory
In May of last year, Chrome revealed a new secure-by-default model they would be implementing for cookies that went along with a new cookie classification system. They decided to do so to better their privacy and security and protect browsers from potential threats like CSRF attacks (see below). Chrome will begin implementing this new model with certain populations on February 17, 2020.
Cross-Site vs. Same-Site Cookies
In order to understand the changes that are being made, it is important to distinguish the difference between cross-site and same-site cookies. All browser cookies have a domain that is attached to the cookie. All cookies contain the same information, but discrepancies in the how they are created and used is what distinguishes if they are cross-site or same-site cookies. Identifying which type of cookie is present can be done by looking at the domain associated with the cookie. This blog post on Chromium breaks it down nicely.
Cross-Site (Third-Party) Cookies: Third-party cookies are created by domains other than the website page that the user is visiting. These kinds of cookies are used by external services for advertising, cross-site tracking and retargeting efforts. There are two types of third-party cookies:
- The obvious cross-site cookies: A cookie created by an external service, where the cookie’s domain matches the external site and not the domain of the site the visitor is on.
- The less obvious cross-site cookies: When an entity owns multiple websites and uses one cookie across a variety of different website domains, and the cookie’s domain still doesn’t match the domain of the page the web visitor is on.
Same-Site (First-Party) Cookies: When the cookie is created from and contains the same domain as the website domain in the user’s address bar. These cookies are used more often for user preferences and to maintain login status for visitors when they return.
What Is the SameSite Attribute?
The changes that Chrome is implementing are associated with the SameSite attribute that exists for website development. The SameSite attribute currently has two settings that developers can choose from to set for each cookie: SameSite=Strict and SameSite=Lax. These two options are for access in a first-party context. If neither option is selected, then there is no protection for these cookies from potential threats like Cross-Site Request Forgery (CSRF) attacks.
This is a real problem as currently, many developers are often not setting the SameSite attribute on their cookies. This makes those cookies accessible when you move from one site to another (a third-party site). Depending on the industry or website and how the cookies are used – the website visitors are being made vulnerable to potential attacks.
How This Applies to Chrome Changes
The changes that Chrome is creating in February will automatically set the SameSite attribute to be SameSite=Lax. What this ultimately means is that if a cookie has not had a SameSite value set, Chrome is going to consider it as SameSite=Lax now – which offers some protections from third-party access.
If the developers want the cookie to allow cross-site access, they must use a new setting for the SameSite attribute – SameSite=None. When this attribute is present, Chrome has also implemented an additional Secure attribute that is required with the SameSite=None attribute so that cross-site cookies have more security. The Secure attribute requires that the cookies be accessed over HTTPS connections.
This is Chrome’s attempt to alleviate web visitors from some of the threats of cyber attacks that are possible.
Does This mean CSRF Will No Longer Be an Issue?
With the SameSite attribute being automatically implemented, it does appear that CSRF attacks will be prevented with this update. The modification by Chrome will stop your cookies from being sent with third-party requests. Netsparker.com has a great example in one of their blogs regarding this:
“Let’s say you are logged in to the website www.badbank.com. Using a phishing attack, an attacker can trick you into entering www.attacker.com in another browser tab. Using a code on www.attacker.com, the attacker tries to transfer money from your account by posting a FORM to www.badbank.com. Your browser sends the cookie belonging to www.badbank.com with this request. If the form on www.badbank.com lacks CSRF tokens to prevent a CSRF attack, your session can be exploited by the attacker.
If the cookie of www.badbank.com had been set to SameSite=Lax, the cookie in the browser would not have been sent with the POST request and the attack would not be successful.”
How Will Olytics Be Affected?
The changes to Chrome shouldn’t affect the functionality of Omeda’s web behavioral tracking, Olytics. Olytics cookies don’t need cross-site access because they are first-party cookies. Therefore, even if Chrome automatically sets the attribute to SameSite=Lax, that will still allow Olytics to operate properly.
Olytics is one of Omeda’s main offerings in our Customer Data Platform (CDP). If you have any further questions, please reach out to clientsuccess@omeda.com.
