01-13-2020 10:43 AM - edited 02-03-2020 11:10 AM
This article serves as a notification of an upcoming change to Google Chrome that could potentially affect the behavior of your Tealium implementation.
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
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 a server-side third-party cookie must make an update to accommodate the new default behavior from Chrome 80, otherwise their cookies will be rejected.
Tealium has made the following changes to ensure that cookies continue to perform as expected after the Chrome 80 release:
Cookies set by the Universal Tag (utag.js) are not affected because they are set in a first-party context.
Review the following scenarios and actions to see if you are affected:
|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
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
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.
|You use a custom name (CNAME) that was originally set to
No action required. Tealium sets