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

Thanks, @lknik! Sorry I missed your feedback when you first provided it.

> > Still, it seems likely that folks will want to stretch the bounds of what first-party sets enables over time
>
> Can you please elaborate why it's likely, and which folks specifically do you mean here? Not asking for all their names and addresses, of course.

The example I linked in the document (https://lists.w3.org/Archives/Public/public-webappsec/2017Mar/0034.html) came to mind as an existence proof of folks with interesting ideas about loosening the same-origin policy based on affiliation.

> Any other risks that you can imagine (apart from the stuff listed later in the explainer)? Aside from the Ordinary User not knowing about the existence first/third party stuff, would it make sense to require browser UI changes to indicate that some site is linked with another?

The document lists the risks I've thought about. If I come up with more, I'll add them. :)

I don't personally think there's any value in exposing the relationship between A and B to users directly via browser UI, but I'm not at all a UI guy. I'd expect folks like @estark37 to have strong, well-informed opinions on these topics, and I'd defer to them completely. That said, however Chrome comes down on that question, I don't think it makes sense to specify UI in this kind of document.

> Would there be a way to deregister from the set, and e.g. change sets in quick time intervals, or something like that? I'm simply wondering if site1 can easily change its membership (rather than: being member of two separate sets on the same time, which is already marked as concern). Apart from the natural expiration of 7 days you speak of, unless it could be the same.

I don't think it would be helpful to create a way to deregister oneself in an accelerated fashion without also taking some catastrophic action against the data that's been built up given the existing first-party relationships. I could imagine the `Clear-Site-Data: *` mechanism being draconian enough to enable this, for example.

> How would the risk after such mitigation compare with today's risk of making the same? Would you imagine it conceivable that advertisers will start serving their stuff from XXXYYYZZZ.ccTLD, and smartly game the number-limited system? (but: "Forget the entity" looks good).

How would this "game the system"? The risk mitigated by limiting the size of a set is the incentive that would otherwise exist to create a single global set of all an advertisers' otherwise unrelated publishers (e.g. `doubleclick.net` + `cnn.com` + `sz.de` + `vox.net` + ∞). Allowing an advertiser (or anyone else) to bind their matching ccTLDs together seems different in kind from that scenario.

> Sounds like an opportunity for a new batch of research papers? I'm sure many will be happy ;-)

I agree! Mechanisms that encourage transparency are good.

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