Re: [w3ctag/design-reviews] First-Party Sets (#342)

> Every iOS browser (by choice or not) also uses the site as the privacy boundary by default and w/o heuristics and block/allow lists.

Safari does use heuristics for their bounce tracking prevention feature. WebKit has expressed interest in using FPS to replace those heuristics so they can enable it more broadly (as well as to improve their implementation of Storage Access API, and Login Status API). This application is also captured in privacycg/first-party-sets#84 and was discussed on the [Feb-24-2022 PrivacyCG call](https://github.com/privacycg/meetings/blob/main/2022/telecons/02-24-minutes.md#update-applications-section-with-proposed-applications-84). (PrivacyCG requires multi-implementer interest to adopt a proposal as a work item, and it was adopted there due to WebKit's support for incubation)

> Further, as you mention, some browsers ship lists and heuristic based exceptions to the boundary. But, at least in some cases, these browsers think site-as-boundary is correct, but compat risk is too high. Further entrenching leaks and exceptions to site-as-boundary through FPS would make this problem worse, not better.

Site-as-boundary’s “compat risk is too high” is exactly the motivation for FPS. The fact that compatibility impact has been too high to ship without exceptions indicates that the web needs something more nuanced, at least in the medium term. We can use the FPS policy controls to ensure that users are still protected. Unifying on a single cross-browser system for these exceptions will also make it easier to understand these use-cases and constraints, and use the policy controls to push the web toward the desired direction in the long run.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/342#issuecomment-1082483198

You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/342/1082483198@github.com>