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

> (Speaking only for myself) The intent is to work backwards from intended applications. 

We recently write up privacycg/first-party-sets/pull/84 which expands on the intended applications, please take a look. 

> If all of the intended applications are cases of _weakening_ the existing privacy boundary, it seems to me that we shouldn't add a platform primitive that enables that. If some of the intended applications instead tighten things up, then it would be very valuable to try to figure out how to design a platform primitive that enables that without also accidentally enabling weakening or dissolving the existing privacy boundary.

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. 

> > and [navigational tracking mitigations](https://github.com/privacycg/nav-tracking-mitigations) exempting navigations across domains within the same FPS from anti-tracking mitigations?
> 
> I think this is the first time I've heard about this particular use case, and I don't see anything about it in the NTM draft. Could you or @jyasskin tell us more? I asked @pes10k but he wasn't familiar with this idea.

Just to clarify, the discussion about FPS applying to bounce/navigation tracking prevention has happened in the context of FPS between WebKit and Chrome engineers. I was linking to privacycg/nav-tracking-mitigations primarily to provide a canonical reference to the definition.

> I wanted to return to a point @pes10k raised back in April:
> 
> > 2. If the concern is that clustering multiple "properties" onto a single origin will cause security problems (a problem I totally understand and buy and appreciate), lets try to fix that problem (possibly by allowing a single site declare sub-site/origin security / isolation boundaries), instead of trading privacy for security.  For example, I know https://w3c.github.io/webappsec-suborigins/ didn't get broad support last time it was floated, but that seems like a place to build from.
> 
> I had trouble following the discussion that followed, and it's been almost a year since then, but could we come back to this?

@hober - Here was my response to that comment:

> Note that even if we do manage to corral together every platform feature that treats the site/domain as a security boundary, build new features, and resolve the issues over multiple years:
> 
> * We still need to develop an interim compat mechanism like the Disconnect list or First-Party Sets.
> * Site authors still have to account for older clients/browsers that don't have these solutions in place. It seems like an undue burden to require that site authors maintain substantially different patterns of deployment for different clients.




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

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