Two base::Features have been enabled by default:
net::features::kSameSiteByDefaultCookies: Treats a cookie without an explicit SameSite attribute as if it were SameSite=Lax, except for the first 2 minutes after the cookie's creation, during which it is subject to Lax-allowing-unsafe SameSite enforcement (a.k.a. Lax+POST).
net::features::kCookiesWithoutSameSiteMustBeSecure: Requires that any cookie specifying SameSite=None (i.e. which is not subject to SameSite enforcement) must also specify the Secure attribute.
Why does this matter?
These features enable changes with significant compatibility risk that affect how cross-site cookies are handled on close to half of all page loads. Given the magnitude of the potential impact, Chrome has been rolling out these changes with caution while monitoring metrics and web ecosystem feedback. User reports of site breakage are being tracked here, and bug reports are welcome via this template.
How can embedders modify this behavior?
Several options are available:
Disable the base::Features. For example, this can be done when setting up the FeatureList in PostEarlyInitialization().
Disable the SameSite-by-default behavior for cookies on select domains using "legacy cookie access semantics" content settings. Allowing legacy cookie access disables the new behavior, regardless of the state of the base::Features. Domain patterns can be specified as ContentSettingsPatterns and provided in the CookieManagerParams while creating a NetworkContext, and can also be updated dynamically via the CookieManager mojo interface.
Disable the new behavior globally by using a CookieAccessDelegate that always allows legacy cookie access. This is also configured via CookieManagerParams.