Intent to Prototype: Partitioning Storage, Service Workers, and Communications APIs
We intend to partition a number of APIs in 3rd party contexts. This effort is focused on partitioning APIs above the network stack. This includes quota-managed storage, service workers, and communication APIs (like BroadcastChannel). See the explainer for more details.
Partitioning is intended to address known, existing privacy and security issues in 3rd party contexts.
We are not intending to provide an escape hatch for 3rd party contexts to access 1st party storage; i.e. no requestStorageAccess(). We feel solutions like requestStorageAccess() produce either a bad experience for users with prompts or an unpredictable platform for developers with heuristics. See the explainer for more discussion of this topic.
Not providing an escape hatch means this effort is at greater web compatibility risk. We are attempting to remove some capabilities to remove privacy and security abuses, but it's possible we will encounter a use case that we did not anticipate that blocks shipping. We believe that partitioning these APIs will be mostly compatible, however, since they are typically not used for storing authentication state. We do plan to deprecate 3rd party cookies as well, but there are separate efforts, like WebId, targeted at mitigating the authentication issue.
There is also some feedback from developers that partitioning has not been a problem in other browsers.
Webkit: No official signal, but they have been partitioning storage in various forms for a long time.