What can I gain from reading this article?
- Starting February 4, 2020, Chrome 80 will treat cookies with no SameSite value as SameSite = Lax, a setting that prevents a cookie from being used in a 3rd-party context, or “cross-site.” Chrome will require developers to set any cross-site cookies to SameSite = None and label them as secure.
- New or existing cross-site cookies without proper labeling and the secure attribute for cross-site cookies will be unusable on Chrome 80 and above.
- Adobe standard visitor cookies for Analytics, Target, Experience Cloud Identity Service (ECID), Audience Manager, Advertising Cloud, Bizible and Marketo Munchkin will include the necessary labeling by early January. Most updates are in production today.
- Customers still making unsecure calls to Adobe edge servers using HTTP may need to update their sites to use HTTPS.
- Adobe promotes consumer privacy and choice and will continue working with Google to ensure our customers have accurate tracking, while abiding by the intention of the Chrome browser.
Background on the Google Chrome announcement:
In May 2019, Chrome announced upcoming updates to their browser privacy and identity features. They announced changes to place a stricter requirement on cookies, specifically flags for better classification of cross-site behavior and end-user understanding. We expect this to be the first of many Google Chrome updates focused on security and privacy.
Google’s update will significantly reduce the risk of cross-origin information leakage, including defending against Cross-Site Request Forgery (CSRF) attacks. Chrome also wants developers to use this mechanism when accessing cookies cross-site and in turn, to give consumers the right information and choice about how their data should be used.
These updates should give users transparency over, and better control of, the third-party trackers on their browser. Instead of restricting cookies by default, Chrome is putting users in control of privacy management. At Adobe, we provide customers with tools that allow you to support user privacy that can lead to consumer-welcomed enriched customer experiences. Below are details about updated settings that will enable you to use our services consistent with the updates made to Chrome.
Two settings will be enabled by default in Chrome 80
What is the SameSite attribute?
The SameSite attribute is part of the cookie standard. The SameSite attribute can have one of 3 values: strict, lax, or none. The first two values have been supported by Chrome, Firefox, Edge, Safari, and Opera starting in November 2017. In 2018, the standard was updated to include an additional setting, none. However, some older browsers do not support this setting. In May 2019, Google announced they would be changing the default from none to lax when a cookie does not specify a SameSite value.
Lax — 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.
Strict — 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.
None — Cookies with this setting are available for external or 3rd-party access, i.e. “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.
Chrome 80 is expected to be released in early February, 2020. Firefox and Edge have also announced that they will be adopting these changes. The functionality is already present in both browsers, but is disabled by default. They have not announced a date when they will make this their default behavior.
What do I need to know as an Adobe Experience Cloud customer?
Adobe is updating their edge servers to set the appropriate cookie attributes. Most Adobe products have already released server-side updates to set their 3rd-party cookies with the appropriate attributes. Analytics and Ad Cloud will release their final changes the first week of January.
Ensure 3rd-party endpoints are using HTTPS
Correctly labeled cookies should collect data as intended
As long as cookies are correctly labeled, the browser should not take any action to block these cookies. Consumers will have the option to block certain types of cookies but at this time, this appears to be an opt-in setting only.
Existing 3rd party cookies without the updated labels will be ignored
3rd-party cookies that are created before Chrome 80 starts enforcing the SameSite=none and secure flags will be ignored by Chrome 80 if these flags are not present. Since many of the existing Adobe 3rd-party cookies have not had those flags, these cookies will need to be updated by Adobe’s edge servers before users upgrade to Chrome 80 or those cookies will be lost. This upgrade by Adobe edge servers will happen automatically as users visit any website where the cookie is used. For most Adobe products, cookies will have the appropriate flags by the time Chrome 80 is released. The exception is Adobe Analytics implementations that use 3rd-party data collection and do not use the Experience Cloud Identity Service (ECID). These 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 their cookies, they 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 3rd-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 a 1st-party cookie. However, if you own multiple domains and use the same CNAME for data collection across all your domains, then it will be a 3rd-party cookie on those other domains. When Chrome starts defaulting cookies without a SameSite setting to Lax, this cookie will no longer be visible on these other domains. To make the behavior more similar across all browsers, in February, after the Chrome 80 release, Analytics will start explicitly setting the SameSite value of this cookie to Lax. If you use this cookie in a friendly 3rd-party context, you will need to have the cookie set with SameSite = none, which also means you must always use HTTPS. Contact Adobe Customer Care to have the SameSite value changed for your secure CNAMEs. Note, this action is NOT required for Analytics customers using the Experience Cloud Identity Service (ECID), for those using a separate CNAME for each of their domains or those using only 3rd-party Analytics data collection.
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.
Note — Adobe 3rd-party cookies are set server-side.
* In these cases, for browsers that Google has identified as mishandling cookies when SameSite is set to none, SameSite will instead be left unset.
Where can I find more information?
Adobe solution teams have written more detail in their documentation and will continue to do so as we manage current and future browser changes.
· Adobe Target’s Google Chrome SameSite cookie policies
· Adobe Analytics Cookies, which includes their SameSite and Secure settings