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

> Is this statement assuming "site" as the privacy boundary? I think it's important to keep in mind that we have not seen comprehensive privacy protections enabled by default in major browsers, that haven't run into serious site compatibility and functionality issues due to the usage of "site" as the privacy boundary. For instance, most browsers deploy a combination of heuristics, and blocklists/allowlists to deal with these issues.

This is very surprising.  Safari, Brave and Tor all use site as the default privacy boundary, and Firefox already does in some modes and intends to in all modes (according to previous comments in FPS threads). 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.

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.

More broadly though, I think this conversation is still in exactly the same place it was almost a year ago (wrt privacy), with some vendors and parties interested in FPS as a primitive to build on, but no multi-implementor interest (i.e., other than Blink/Chromium) in FPS as a _privacy feature_.

I suggest then to both the FPS proposers and the PrivacyCG chairs that PrivacyCG is not the correct place for FPS, and that the work would be better moved to another venue in W3C.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/342#issuecomment-1082330799
You are receiving this because you are subscribed to this thread.

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

Received on Tuesday, 29 March 2022 23:19:01 UTC