NOTE: These policies are planned, but not yet available. They will become available as of Chrome 79. All cookies that match a domain pattern listed in LegacySameSiteCookieBehaviorEnabledForDomainList (see below) will be reverted to legacy behavior. For cookies that do not match a domain pattern listed in LegacySameSiteCookieBehaviorEnabledForDomainList, or for all cookies if LegacySameSiteCookieBehaviorEnabledForDomainList is not set, the global default setting will be used. If LegacySameSiteCookieBehaviorEnabled is set, legacy behavior will be enabled for all cookies as a global default. If LegacySameSiteCookieBehaviorEnabled is not set, the user's personal configuration will determine the global default setting. The SameSite attribute The SameSite attribute of a cookie specifies whether the cookie should be restricted to a first-party or same-site context. Several values of SameSite are allowed:
See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.7 for the definition of the SameSite attribute. See https://web.dev/samesite-cookies-explained/ for a more detailed explanation of the SameSite attribute with examples. Legacy SameSite behavior As of Chrome 80, a cookie that does not explicitly specify a SameSite attribute will be treated as if it were "SameSite=Lax". In addition, any cookie that specifies "SameSite=None" must also have the Secure attribute. (See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.5 for the definition of the Secure attribute.) Reverting to the legacy SameSite behavior causes cookies that don't explicitly specify a SameSite attribute to be treated as if they were "SameSite=None", i.e., they will be sent with both same-site and cross-site requests. In addition, reverting to the legacy behavior removes the requirement that "SameSite=None" cookies must also specify the Secure attribute. Configuring LegacySameSiteCookieBehaviorEnabledForDomainList In this policy setting, you can list specific domains for which legacy SameSite behavior will be used. The domain of a cookie specifies those hosts to which the cookie will be sent. If the Domain attribute of the cookie is specified, then the cookie will be sent to hosts for which the specified Domain attribute is a suffix of the hostname, and reversion to legacy SameSite behavior will be triggered only if the value of the specified Domain attribute matches any of the patterns listed in this policy setting. If the Domain attribute of the cookie is not specified, then the cookie will only be sent to the origin server which set the cookie, and reversion to legacy SameSite behavior will be triggered only if the hostname of the origin server matches any of the patterns listed in this policy setting. See https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-03#section-4.1.2.3 for the definition of the Domain attribute. Example 1: If the Domain attribute of the cookie is set to "Domain=example.com", the cookie will be sent when making HTTP requests to example.com, www.example.com, or www.corp.example.com. To revert to legacy behavior for such a cookie, use the pattern '[*.]example.com' or 'example.com'. The value of the Domain attribute (example.com) will match either of these patterns. Even though the cookie would be sent to www.example.com, the pattern 'www.example.com' will NOT match such a cookie, because the Domain attribute value (example.com) does not match the pattern 'www.example.com'. Example 2: If the Domain attribute of a cookie set by www.example.com is not specified, the cookie will be sent only when making HTTP requests to www.example.com. The cookie will not be sent when making HTTP requests to example.com or sub.www.example.com. To revert to legacy behavior for such a cookie, use the pattern 'www.example.com' or '[*.]example.com'. The origin server's hostname (www.example.com) will match either of these patterns. Note that patterns you list here are treated as domains, not URLs, so you should not specify a scheme or port. Specifying a scheme or port may result in undefined behavior. |
|
|