What is Google Chrome’s SameSite update, and will it affect marketers?
Read on to find out how you can prepare for Google’s new privacy protocol.
What You’ll Learn:
- What SameSite is
- Why Google is implementing the update
- What changes you can expect to see
- A breakdown of the different SameSite settings
- The changes that cross-site users will need to implement
- How the update could impact marketers
Google launched a new Chrome update that brings a host of new features to the browser, promising to make it faster, stronger, and way more secure.
Among those updates comes a new take on cookies.
Dubbed the “SameSite update,” Chrome’s latest iteration requires website owners to explicitly label which third-party cookies can be used on other websites. Cookies that come without the proper labels won’t work in the Chrome browser.
The new standards are set to go live on February 17th, 2020. While Firefox and Edge will be implementing the SameSite measures as well, there’s no definitive date set for the new standards to take effect.
In this article, I’ll go over what marketers should know about SameSite and whether they need to make any changes in response to the latest Chrome update.
What is SameSite?
SameSite isn’t exactly new.
Initially defined back in 2016, the cookie attribute sought to prevent browsers from sending cookies along with cross-site requests.
The SameSite attribute allows web developers to declare if their cookie should be restricted to a same-site, or first-party, context.
What’s Behind the Big Change?
According to Google, the SameSite update is part of an ongoing push toward improving browser safety, known as the Privacy Sandbox.
The update represents one of Google’s first big moves toward a more secure browsing experience, though it’s a far cry from the “end of cookies” just on the horizon.
The reason Google’s move toward a private browsing experience is a big deal is that third-party cookies can put people at risk of malicious tracking or data leakage, as well as something known as cross-site request forgery attacks.
Cross-site forgery attacks are phishing scams in which a user clicks on a link in a seemingly legitimate email that allows a hacker to gain access to say, the victim’s banking website.
Google’s aim here is to make the browsing experience safer, changing the default behavior for unspecified SameSite attributes so that they automatically default to a more secure option, as opposed to a less secure one.
The SameSite updates also give users the ability to manage both first and third-party cookie settings independently. In most cases, users like to keep first-party cookies enabled, as they make browsing more convenient. First-party cookies prevent us from having to reenter log-ins, passwords, and addresses each time we visit a website.
What’s Actually Changing?
In the context of all of this SameSite information, you’ll see several mentions of cross-site and SameSite.
Here’s a quick breakdown of what those terms mean and why they’re important.
SameSite vs. cross-site cookies. Source: Heroku
As you may be aware, websites often integrate with external services that promote ads or content recommendations, as well as widgets, links to social channels, and other features.
When you browse the web, these external services may store cookies in your browser, which they’ll then access to track engagement or deliver personalized experiences. A prime example is Facebook’s use of data to track user behavior and sell advertising space.
Every cookie links to a domain. And if that domain is associated with a cookie that matches an external service, rather than the website listed in the end-user’s search, that means the cookie is used in a third-party or cross-site context.
For example, if a user is looking at www.samplesite.com, but the cookie is associated with Facebook, that means the cookie is being used in a cross-site context.
Fairly straightforward, right?
Where things get a bit more complicated is that cross-site context can also include use cases where one company owns multiple websites and use cookies across several properties.
In this case, even though the same company might own both the cookie and the website, if the domain names don’t match, it’s still considered a third-party cookie.
By contrast, first-party cookies are stored by a domain that you visit directly. First-party cookies are used only by the site storing them, and generally speaking, make the browsing experience much more convenient.
For instance, if you disabled all first-party cookies, a website wouldn’t even be able to track your activity from one page to the next.
First-party cookies keep track of credit card information to allow for quick checkout, remember your shipping address, remember the pages you’ve visited in the past, etc.
Search Engine Land points toward an example of how cookie settings might play out on YouTube.
Essentially, they break it down as follows:
Let’s say user logs into YouTube, and a session cookie is set in a first-party context. YouTube can track the session activity for that user while they’re on “YouTube.com,” but they’ll need to update their attribute settings to extend tracking to external sites.
The new SameSite policy now requires YouTube to set an attribute value of ‘None’ plus ‘Secure’ for YouTube to retrieve its cookie values in a third-party context, such as plays from an embedded player on an external news website.
YouTube is another example of a cross-site cookie used in both first and third-party contexts. So long as YouTube implements the policy change, its widgets will keep functioning as usual.
SameSite Cookie Settings Explained
SameSite cookie settings come in three different varieties: Strict, Lax, and None. Websites will be automatically set to the SameSite value of ‘None’ plus ‘Secure’ in third-party cookie contexts.
Here’s a quick breakdown of what that all means:
- Strict: Use the strict setting when indicating first-party cookies for websites/apps that never need to retrieve cookies in a third-party context. As you might imagine, “strict” is the most secure cookie value you can set, and prevents cookies from being sent in contexts where a third-party can reference your assets and retrieve values by including data from your site in their HTML code.
- Lax: The Lax setting works almost the same way as Strict, with one important exception: when someone clicks on a third-party backlink to your application. In this case, that click triggers a TLS (https://) request to reference cookie values from external pages that link back to your website.
- None: The SameSite=None; Secure designation is the least secure setting of the bunch. It opens access to cookie values in a cross-site context (again, like YouTube), provided all communications take place over TLS connections. Per Google, this setting is only recommended for use cases like YouTube’s, where embedded widgets factor heavily into your distribution model.
Cross-Site Cookie Users Do Need to Implement a Few Changes
If you manage cross-site cookies, it’s up to you to implement the SameSite=None attribute plus Secure setting to those cookies.
While Google notes that implementation should be relatively straightforward, they do recommend that developers start testing ASAP to identify complexities before the change goes into effect.
Here are a few complexities/individual cases developers should be aware of, per Google:
- Some languages and libraries don’t support the “None” value just yet, which means that developers will need to set the cookie header manually. The guidelines point toward a Github repository featuring instructions for implementing SameSite=None, Secure in a wide range of languages and libraries, in case this applies to you.
- Specific browsers, including older versions of Chrome, UC Browser, and Safari, might handle the None value in unintended ways. This means developers will need to write code exceptions for those clients. You can view the complete list of incompatible clients here.
- Additionally, there might be some issues for iOS and Android App developers. They may need to declare SameSite settings to ensure that TLS (https://) secure connections will take place while using the WebView API for either platform.
- If you have cookies that you access in both first and third-party contexts, you may need to consider using separate cookies in order to access the security benefits of SameSite=Lax when using first-party cookies.
Will SameSite Impact Marketers?
The SameSite update itself doesn’t impose any new restrictions, nor does it require (most) marketers to take action. As mentioned above, some developers may need to make some minor code updates.
That said, SameSite does underscore the importance of moving to HTTPS. While site security has been a ranking factor for a couple of years now, as well as a trust factor for internet users across the board, SameSite represents a push toward greater privacy and transparency.
Should the full rollout go according to plan, end-users likely won’t notice any changes due to the SameSite updates. Some services, widgets, and plugins that are not actively maintained or updated, however, might, well, break.
On the end-user side, you can work around any “broken” systems at your own risk by following a few simple steps:
- Clear your cookies and refresh the page.
- Report the issue to the provider.
- If you’re looking for immediate access, you can disable the SameSite cookie restriction in Chrome by navigating to chrome://flags/#same-site-by-default-cookies.
How Should Brands Prepare for SameSite?
As mentioned, Chrome’s SameSite update shouldn’t be cause for immediate concern. iOS and Android developers may need to make some updates to their source code, but secure, regularly updated websites likely won’t need to take action.
That said, SameSite represents a major step toward the cookie-less future on the horizon.
By 2022, third-party cookies will be obsolete in Chrome, which will make it harder for brands to personalize advertisements or take advantage of hyper-targeted programmatic ads.
