Fragmented FPS implementation in UAs

[rhiaro]

I'd like to see exploration of what happens when a UA doesn't implement FPS when others do (including what happens to older browsers that are never going to get updated); and when different UAs ship with different FPS lists. How badly can things break from an end user perspective, and from a site owner/admin perspective?

I'm worried about sites blocking access to UAs that don't implement FPS, or to users who have FPS turned off.

(originally posted in #45 (review))

[krgovind]

Hi @rhiaro - FPS aims to preserve workflows/usecases that rely on existing cross-site relationships of domains on the web, as long as the domains in question are part of the same FPS. Specifically, this is useful in the face of new "on-by-default" restrictions on third party data sharing within browser.

Within the context of FPS and SameParty cookies, a browser that doesn't implement FPS and SameParty cookies would be in no different than today's situation when a browser blocks third party cookies. Even within browsers that implement FPS, there will likely be a stricter mode that allows users to opt-out of FPS as a feature.

[krgovind]

@rhiaro - FYI, we published a significant update to the proposal with #92 (changes have been merged into main); which changes my response.

We have since abandoned development of the SameParty cookie attribute, and instead now require use of the Storage Access API (SAA), and requestStorageAccessForOrigin. We recommend that user agents incorporate FPS into the implementation-defined rules that the SAA specification allows for. So user agents that use different lists, or don't support FPS at all, will simply fall back to other rules. The result is that sites authors can maintain one interoperable implementation (where cross-site cookies are mediated via SAA); and user agents can facilitate that cookie access via their own rules around auto-granting/auto-denying/prompting the user.