Google Chrome SameSite labelling changes google-chrome-samesite-labelling-changes
The SameSite attribute tells browsers when and how to fire cookies in first and third-party scenarios. The SameSite attribute can have one of three values: strict
, lax
, or none
. Chrome, Firefox, Edge, Safari, and Opera have supported strict
and lax
since November 2017, while none
was introduced in 2018. However, some older browsers do not support this setting.
In February 2020, Google released Chrome 80 and changed the default setting from none
to lax
when a cookie does not have a specified SameSite attribute value. This setting prevents a cookie from being used in a third-party context, also known as “cross-site”. Any ensuing third-party cookies must be set to SameSite=none
and be labelled as secure.
Cookies without a specified SameSite attribute value will default to lax
.
Visit the cookie standard document for more information on SameSite attributes.
SameSite attribute values
strict
lax
none
none
was the default SameSite setting for cookies, so using this setting makes a cookie behave most similarly to how it has traditionally worked. However, Google is requiring that any cookie with this setting now specify the secure flag, which means the cookie will only be created and sent with requests over HTTPS. All cross-site cookies without the secure flag will be rejected by Google.What you need to know as an Adobe Experience Cloud customer
No JavaScript updates required
Adobe products have already released server-side updates to set third-party cookies with the appropriate attributes. No JavaScript library updates are needed by our customers.
Ensure third-party endpoints are using HTTPS
All customers should confirm that their JavaScript configuration is using HTTPS for their calls to Adobe services. Target, Audience Manager, and the Experience Cloud Identity Service (ECID) are redirecting third-party HTTP calls to their respective HTTPS endpoints, which can increase latency. This means you are not required to change your configuration. Analytics customers should update their implementations to exclusively use HTTPS, as redirects specific to Analytics can cause data loss.
Correctly labeled cookies should collect data as intended
As long as cookies are correctly labelled, browsers will not take any action to block them. Consumers will have the option to block certain types of cookies, but currently, this appears to be an opt-in setting only.
Existing third-party cookies without the updated labels will be ignored
Third-party cookies that were created before Chrome 80 started enforcing the SameSite=none
and secure flags settings will be ignored by Chrome 80 if these flags are not present.
Many of the existing Adobe third-party cookies do not have these flags and will need to be updated by Edge servers before users upgrade to Chrome 80 or those cookies will be lost. The Edge servers update happens automatically as users visit any website where the cookie is used.
Most Adobe products already have the appropriate flags assigned to cookies. The exception are Analytics implementations that use third-party data collection and do not use ECID. Customers may experience a small, temporary increase in new visitors that otherwise would have been returning visitors.
Possible cookie match decrease for destination and marketplace partners (Audience Manager only)
While Adobe has control over updating its cookies, Adobe can’t force partners to make necessary changes. Cookie matching may decrease for Audience Manager customers using destination partners or marketplace partners that have not made these updates.
Analytics Friendly third-party Cookies (Analytics s_vi
cookies only)
Some Analytics implementations use an Analytics CNAME alias to enable creating the s_vi
cookie in the domain of that CNAME. If the CNAME is in the same domain as your website, this will be designated as a first-party cookie. However, if you own multiple domains and use the same CNAME for data collection across all your domains, then it will be designated as a third-party cookie on those other domains.
With lax
becoming the new default SameSite setting in Chrome, the CNAME is no longer visible on other domains.
To accommodate the change, Analytics is now explicitly setting the SameSite value of s_vi
cookie to lax
. To use this cookie in a friendly, third-party context, set the SameSite value to none
, which also means you must always use HTTPS. Please contact Customer Care to have the SameSite value changed for your secure CNAMEs.
Adobe Standard Visitor Cookies
Only the common visitor standard cookies are listed in the table below. For additional cookie configurations, see product-specific documentation or contact your Adobe representative.
ECID
lax
settinglax
settinglax
Audience Manager
none
none
Analytics
- Server-side first-party if using
CNAME
- Third-party if using 2o7.net or omtrdc.net
lax
if first-partynone
if third party
Customers can edit setting via Customer Care ticket for first-party domains
none
and HTTPS requestlax
settingTarget
lax
settingAd Cloud
none
Only on Google Chrome and Chromium-based browsersnone
and HTTPS requestlax
settingnone
Only on Google Chrome and Chromium-based browsersnone
and HTTPS requestBizible
none
Marketo Munchkin
lax
setting![IMPORTANT] Adobe third-party cookies are set server-side.
For more information, see the document on Target’s Google Chrome SameSite policies.