WICG
should quota-managed storage and service workers be partitioned by FPS?
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?
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.
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.
