Notification of Changes to the Google Chrome 80 SameSite Cookie Attribute (Updated)

[Tony_Taliaferro]

This article serves as a notification of an upcoming change to Google Chrome that could potentially affect the behavior of your Tealium implementation.

What is changing in Chrome?

Starting in February, 2020 the release of Google Chrome 80 introduces a new default value for the SameSite cookie attribute that affects its behavior in cross-domain scenarios. The current default value is SameSite=None, which implies that the cookie be available in third-party contexts. With the release of Chrome 80, the default value will be SameSite=Lax, which implies that the cookie not be available in third-party contexts. Third-party cookie requests that do not set SameSite=None (and thus default to SameSite=Lax ) will be rejected.

Also, when the value is set to SameSite=None, the cookie must be tagged with a secure attribute to indicate it requires an encrypted HTTPS connection. Cookie requests with the attribute value of SameSite=None that are not marked secure will be rejected.

Learn more about Google's Chrome update: Cookies default to SameSite:Lax

Why is this important?

Cookies with the SameSite=None attribute are marked for use in third-party contexts that are typically used for tracking and can contain sensitive data about the identity of a user. This change is important to increase web privacy and security by limiting the amount of personal data shared across domains and to encourage adoption of HTTPS and first-party data.

Using non-secure cookies can facilitate pervasive monitoring and potential attacks on user privacy. This change mitigates this risk by restricting the use of non-secure third-party cookies. By requiring SameSite=None cookies to be secure, users are protected by default from attacks on data that can personally identify them and potentially compromise privacy.

Any service that sets an HTTP third-party cookie must make an update to accommodate the new default behavior from Chrome 80, otherwise their cookies will be rejected.

What is Tealium doing in response?

Tealium has made the following changes to ensure that cookies continue to perform as expected after the Chrome 80 release:

• HTTP cookies set by the Tealium Collect service, the View-Through Tracking extension, and Cookie Matching tags will be set to secure and use the SameSite=None attribute.
• The Tealium Collect tag used in iQ Tag Management has been updated to force the use of HTTPS for custom server endpoints in cases where no protocol is specified in the custom endpoint URL.
• Tealium additionally sets an HTTP TAPID cookie with a unique identifier that is used for specific items, such as cross-domain visitor stitching.

Cookies set by the Universal Tag (utag.js) are not affected because they are set in a first-party context.

What do I need to do?

Review the following scenarios and actions to see if you are affected:

Scenario	Action
You use the Tealium Collect tag in your iQ Tag Management configuration and use a custom server endpoint (instead of the default Tealium endpoint).	Ensure your custom server endpoint is set to use https://. For more information, see: Tealium Collect Tag Setup Guide
You use the Tealium Collect tag on a site that mixes HTTP pages with HTTPS pages.	Update to the latest version of the Tealium Collect tag to ensure all requests will use https:// . For more information, see: Updating a Tag
You use older tag templates that leverage the visitor stitching feature	Older tag templates may use HTTP instead of HTTPS, which cannot be verified as secure. The tags that use HTTP do not set a third-party cookie, which makes all visitors seem to be unique visitors. Also, in rare instances, the relative path can prevent third party cookies from not being set and can potentially create issues with visitor stitching. Due to modern browser requirements and the need for strong security enforcement, the visitor stitching feature is only available for HTTPS data collection, which is the Tealium default. Recommendations: Update all websites to use the most current tag templates, which uses HTTPS as the default configuration. Use HTTPS in all cases where you currently use or may use the visitor stitching feature.
You use a custom name (CNAME) that was originally set to SameSite=Lax or SameSite=Strict.	No action required. Tealium sets SameSite=None for all instances.