should quota-managed storage and service workers be partitioned by FPS?

[wanderview]

Should FPS play a role in partitioning quota-managed storage and service workers? It seems like it would be ideal to follow the cookie partitioning model to avoid developer confusion.

However, in #35 it was suggested FPS should not be used for security boundaries. It would seem storage and service worker partitions are a security boundary given side channel attacks like:

https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1C-2_23104_paper.pdf

I'm assuming people will similarly suggest we should not use FPS partitioning in storage or SW as well, but would let to get that on the record.

@chlily1 suggests that perhaps we could make partitioning of storage and service worker by FPS an opt-in. So by default they would be partitioned by top-level site, but by opting-in (through a TBD mechanism) the partition would switch to be based on FPS (presumably on next load). Would something like this be more acceptable?

[eligrey]

It would be great if there was a way to opt-in to FPS-partitioned JavaScript localStorage. These security concerns seem more applicable to service worker use cases, so this API could be restricted to address these concerns (e.g. limit to main-thread localStorage, don't expose to SW, etc.)

I work on a consent manager which can also mediate consent sync across first party sets completely offline (except for a static sync endpoint, which can optionally be self-hosted). We don't want to require network requests with CHIPS just to sync consent state across a FPS.

[michael-oneill]

Naming the specific LS items would be a good idea. i.e. limiting to the particular storage used to register consent etc. This could be done in an aditional property in the domain speciic JSON manifest.