Interoperability and Compatibility
Cookie partitioning will be opt-in and will not affect sites that choose not to use the Partitioned attribute. Most of its best practices (e.g. requiring Secure, Path=/, and disallowing Domain) are enforced by the semantics of the __Host- prefix which is supported by all major browsers.
At first, Partitioned cookies will be more restricted than unpartitioned third-party cookies. Eventually, Chrome will begin blocking unpartitioned cookies in third-party requests, and Partitioned cookies will be the only cookies available for third-party requests. This approach will allow developers to migrate their systems to Partitioned cookies where the semantics are aligned with the use-case, in advance of third-party cookie obsoletion.
Firefox announced that they are partitioning all third-party cookies by default into their ETP Strict mode and Private Browsing mode.
The initial implementation will support the Partitioned attribute as a way third-party servers can opt-in to receiving cookies partitioned by top-level context. There are no performance concerns.
Sites will be able to use partitioned cookies for third-party requests as soon as it is available in Chrome by having their server include the Partitioned attribute in their Set-Cookie response headers. If a user agent does not recognize the Partitioned attribute, then the cookie will behave like an unpartitioned third-party cookie.
It may be helpful to have outreach to high profile open source libraries that have abstractions for setting or sending cookies in order to help facilitate the adoption of the Partitioned attribute.
This change would require Chrome DevTools to surface whether cookies have the Partitioned attribute set in Application > Storage > Cookies.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Link to entry on the feature dashboard
Requesting approval to ship?