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
SameSite attribute value
Cookies with this setting are only sent when both the referring page and the landing page are part of the same domain as the cookie.
Cookies with this setting are only sent when the domain displayed in the URL of the browser matches the domain of the cookie. This is the new default for cookies in Chrome.
Cookies with this setting are available for external or third-party access, such as “cross-site.” Prior to this change, 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
Ensure third-party endpoints are using HTTPS
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.
This action is not required for Analytics customers using ECID, customers using a separate CNAME for each of their domains, or customers using only third-party Analytics data collection.