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

A few notes from reading through the explainer (which I haven't fully digested yet):
* 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).  If something depends on the set being present, they'd need to make sure to roll out the change across multiple hostst at exactly the same time, probably including dropping HTTP cache expiration times for a period leading up to the switchover.  Is that avoidable?  (There are some thoughts on this later in the "[Incremental Verification](https://github.com/mikewest/first-party-sets#incremental-verification)" section... but I suspect there might be other options for rollout if that isn't viable.)
* Why is a host that is a registerable domain disallowed?  ("[None of the origins specified is itself a registrable domain](https://github.com/mikewest/first-party-sets#a-proposal)")  (I'm guessing you have a good reason, but I don't see it, and it seems a little confusing to me.)  (Though it seems to contradict the "[The design above relies on origins. Shouldn't we evaluate registrable domains instead?](https://github.com/mikewest/first-party-sets#the-design-above-relies-on-origins-shouldnt-we-evaluate-registrable-domains-instead-)" FAQ item.)
* 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.
* The abuse point of hopping between sets seems to be mentioned only in passing, but it seems pretty concerning.

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

Received on Friday, 8 February 2019 13:58:54 UTC