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

Thanks for the feedback, @dbaron! It might also be useful to get feedback from @englehardt and @ehsan, with whom I briefly discussed this proposal. I'd love to figure out if we can make this more robust together. :)

> the [rules](https://github.com/mikewest/first-party-sets#a-proposal) that the browser not cache the set if there's any mismatch seems a little problematic if a site wants to evolve the set over time (e.g., add a host to it

First, as is probably clear, the rules are somewhat up in the air. This first pass seems like a reasonable balance between deployment difficulty and stability, but we might well want to revisit some of the restrictions. The incremental verification suggestion you mention is one route that occurred to me, but I'm sure there are others. For example, the `X-Bikeshed-This-Origin-Asserts-A-First-Party-Set` could have a version number rather than a boolean, bypassing the cache expiration.

Second, I don't know how much we _need_ this sort of thing to be trivial to change. The history of Mozilla's [`disconnect-entitylist.json`](https://github.com/mozilla-services/shavar-prod-lists/commits/master/disconnect-entitylist.json) shows that entities do indeed shift over time, but each individual entity seems relatively stable.

> Why is a host that is a registerable domain disallowed?

That's a typo. :) Should have read "is itself a public suffix". Fixing it in https://github.com/mikewest/first-party-sets/commit/34adb31b50d0ae8f9bfa77863b5e4a1792c09ce5.

> This does appear to pose some risk to users ("[How will malicious actors abuse this mechanism?](https://github.com/mikewest/first-party-sets#how-will-malicious-actors-abuse-this-mechanism)"), but it's not clear to me what the user benefit is over what happens today.  It seems like the explainer should be clearer about that.

I'm hopeful that we can create non-proprietary and publicly auditable alternatives to the lists Apple, Google, and Mozilla are independently maintaining for various features. In the best case, something like this feature would give us the ability to offer entity-related features like credential sharing, and reduce the risk of rolling out tighter controls on cross-entity sharing.

> The abuse point of hopping between sets seems to be mentioned only in passing, but it seems pretty concerning.

I think the current design fairly substantially mitigates this risk by making deployment bidirectional and atomic (e.g. the pain point you noted at the top). It seems to me that we can mitigate it more by locking sites into a given set for some period of time if we decide that the inherent difficult is either unacceptable or not enough.

Thanks again!

-- 
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-461817675