Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rewrite the identity section to try to define the default enforceable privacy/contextual boundary. #28

Merged
merged 5 commits into from
Aug 19, 2021

Conversation

jyasskin
Copy link
Collaborator

@jyasskin jyasskin commented Aug 4, 2021

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

@jyasskin jyasskin added the substantive substantive addition or change label Aug 4, 2021
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated Show resolved Hide resolved
index.html Outdated
Comment on lines 570 to 577
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=].
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@darobin darobin mentioned this pull request Aug 4, 2021
22 tasks
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
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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…

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

@jonathanKingston jonathanKingston Aug 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've moved the mention of widening partitions into a "This is controversial" issue block. How's it look now?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
index.html Outdated Show resolved Hide resolved
@jyasskin jyasskin merged commit 9bf9bae into w3ctag:main Aug 19, 2021
@jyasskin jyasskin deleted the privacy-boundary branch August 19, 2021 20:07
github-actions bot added a commit that referenced this pull request Aug 19, 2021
… privacy/contextual boundary. (#28)

SHA: 9bf9bae
Reason: push, by @jyasskin

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
substantive substantive addition or change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants