Rewrite the identity section to try to define the default enforceable privacy/contextual boundary. #28
Conversation
index.html
Outdated
| Even though this is the default, [=user agents=] are free to both widen and restrict this context as | ||
| their users need. For example, some user agents may help their users present different | ||
| [=identities=] to subdivisions of a single [=site=], while others may help their users present a | ||
| single [=identity=] to a [=site=] across multiple installations or to multiple [=sites=] that the | ||
| user understands represent a single [=party=]. |
There was a problem hiding this comment.
We could draw lines around what variation is acceptable, but it's not clear to me what those lines should be, so it'll wait for a future PR.
jyasskin
force-pushed
the
privacy-boundary
branch
from
453f43a
to
26fb701
Compare
index.html
Outdated
| * between points in time that the user or their agent clears that [=site=]'s cookies and other | ||
| storage (which is sometimes automatic at the end of each session). | ||
|
|
||
| Even though this is the default, [=user agents=] are free to both widen and restrict this context as |
There was a problem hiding this comment.
Should this text be part of the document? First party sets are still pretty well contested across other vendors; I'm not sure we should acknowledge them.
There was a problem hiding this comment.
I agree with this, and @jonathanKingston has put more directly and concisely what I tried to mention on the call:
If there are context boundaries that are controversial, or might be ruled out by the principals mentioned elsewhere in the document, I dont think we should include those context boundaries in a menu of examples.
There was a problem hiding this comment.
I agree that FPS are still heavily contested, however I don't want to just drop things that are contentious. We should be using documents like this one to hash things out.
This seems like a good place to flag an in-document issue, no?
☣️⚠️☢️ WARNING ☣️⚠️☢️
People disagree on boundaries yada yada…
There was a problem hiding this comment.
There are several examples of user-serving identity partitions that are excluded by the purely-site-based definition above here. I understand that Mozilla's currently shipping one of them, even though it would like to get rid of that in the long run. Others include:
- bbc.com/bbc.co.uk
- github.com/githubusercontent.com and google.com/googleusercontent.com, where the domains are separate for security reasons, but users still want a uniform identity across the pair in order to access ACL'ed content
- news.bbc/sports.bbc where the registrable-domain algorithm doesn't understand that a whole TLD can be a very expensive domain registration
My text doesn't endorse any particular solution to the problem, and it restricts solutions to ones where "the user understands [the sites] represent a single party", but it does say that it's reasonable for browsers to explore solutions.
I'm happy to mark this as contentious if y'all still think the document should forbid browsers from working on this problem as a whole.
This paragraph also gives the example of users sync'ing their identity<->site mapping between devices. That can't be done by naively sync'ing all cookie values, but is that kind of goal also contentious?
There was a problem hiding this comment.
The idea is not to forbid browsers from working on this (at all), but on the contrary to mark this as an area that needs significant further discussion. We do want to get to a resolution before the document is finalised, though.
There was a problem hiding this comment.
Not to get too weedsy on the discussion regarding FPS but Mozilla's somewhat related implementation is off by default purely a web compat solution and they don't wish to see it standardised. Also their desire isn't to hang additional features from this implementation, instead use it for tracker blocking or 3rd party cookie exemptions.
Either way I'm happy to just mark this as "in discussion" and we should resolve before publishing.
There was a problem hiding this comment.
I've moved the mention of widening partitions into a "This is controversial" issue block. How's it look now?
There was a problem hiding this comment.
Discussion at the Aug 18 meeting indicated this was good enough for now. I'll merge tomorrow to give a bit of time for more asynchronous comments.
… privacy/contextual boundary. This incorporates some ideas from https://github.com/asankah/identity-domains, which distinguishes separate profiles and boundaries a user creates by clearing cookies/storage. It explicitly says that browsers are free to separate contexts more finely than this default. It drops the blanket statement that automating recognition is always inappropriate, as all webservers are automated, and sometimes users intend to present the same identity in multiple contexts. It also removes the explicit mention of email-based cross-context recognition in favor of a more general statement about difficult-to-forge pieces of people's identities.
jyasskin
force-pushed
the
privacy-boundary
branch
from
26fb701
to
11bf83b
Compare
…why I'm pointing to [PSL-PROBLEMS].
This improves #1 .
This incorporates some ideas from https://github.com/asankah/identity-domains,
which distinguishes separate profiles and boundaries a user creates by clearing
cookies/storage. This covers one of the things @sandandsnow wanted to be sure to cover, but I think I forgot a second thing.
It explicitly says that browsers are free to separate contexts more finely than
this default, which I hope covers @pes10k's concern in this area. We should add a general statement about browsers being free to more-aggressively protect their users in a separate PR.
It drops the blanket statement that automating recognition is always
inappropriate, as all webservers are automated, and sometimes users intend to
present the same identity in multiple contexts.
It also removes the explicit mention of email-based cross-context recognition
in favor of a more general statement about difficult-to-forge pieces of
people's identities.
Let me know what you think.
Preview | Diff