-
Notifications
You must be signed in to change notification settings - Fork 77
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
Add usecases, applications, acceptance process, etc. #45
Conversation
krgovind
commented
Jun 11, 2021
- Add more information about Goals and Non-Goals, specifically addressing no impact on Same Origin Policy.
- Add specific usecase examples.
- Add specific web platform applications related to browser privacy work.
- Update acceptance process/policy to propose a standard policy, verified by an independent entity.
- Address section on potential for technical enforcement of policy.
* Add more information about Goals and Non-Goals , specifically addressing no impact on Same Origin Policy. * Add specific usecase examples * Add specific applications in browser privacy work. * Update acceptance process/policy to propose a standard policy, verified by an independent entity. * Address section on potential for technical enforcement of policy.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general I think I'd like to see a lot more about what happens when a UA doesn't implement FPS when others do (including what happens to older browsers that are never going to get updated); and when different UAs ship with different FPS lists. How badly can things break from an end user pespective, and from a site owner/admin perspective?
The case I'm particularly worried about is sites blocking access to UAs that don't implement FPS (because they're old, or because they choose not to for privacy reasons) or users who have FPS turned off.
|
||
## Submission | ||
|
||
Sites will need to submit their proposed group of domains to a public tracker (such as a dedicated GitHub repository, like that of the [Public Suffix List](https://github.com/publicsuffix/list/wiki/Guidelines), and [Disconnect’s entities list](https://github.com/disconnectme/disconnect-tracking-protection/issues?q=is%3Aissue+%22entity%22+)), along with information needed to satisfy the UA policy. Technical verification of the submitter’s control over the domains may also require a challenge to be served at a `.well-known` location on each of the domains in the set. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great to see expansion on this, but I'm still concerned about how this would work in practice. I acknowledge that it's (rightfully) still very open and subject to evolution. But I'm imagining either:
- there is one list that all UAs have come to agreement on policy on, and they all pull from the same list. I see the practicality of this, but it's dependent on UAs agreeing policy (not a guarantee) and for something with such a broad scope (any site on the web can play) feels far too much centralisation.
- sites have to submit their set for approval to every UA, which doesn't seem realistic. Even with just mainstream UAs right now, assuming they all implement FPS, I can see site admins submitting requests to MS, Apple, Mozilla and Google, but not bothering with Opera, Samsung, let alone Vivaldi, Brave, Tor... And what about mobile browsers? Whether or not requests need to be submitted to eg. Firefox mobile separately from Firefox desktop may not be obvious to site admins.
- the middle ground: some UAs agree policy and share a list, other UAs might fork the list, others might use the list but take liberties with how they implement it (eg. customise it). Besides fragmentation issues, this becomes confusing for site owners with regards to knowing where to submit their sets for verification.
Basically I'm just struggling to imagine how the verification process to determine whether sites are legitimately in the same set can reasonably scale to the whole web with this level of centralisation, and without automation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the feedback, Amy. Just acknowledging that I saw this. We're discussing the technical-only enforcement issue that you linked to within PrivacyCG, and also plan to have another conversation on the policy aspects. I'll come back and address this once I hear from the others as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amy, FYI, I opened issue #48 to keep track of this feedback.
rhiaro called out when reviewing WICG#45 that the mention of "**All sites** with use-cases that depend on cross-domain, same-party communication will be required to declare one (or more) sets." is confusing assuming "site" corresponds to the HTML definition of a "tuple of URL scheme, and domain". The section later goes on to describe how a domain cannot be part of more than one set; so this is contradictory. The original intention for the phrase was to say that organizations can define more than one First-Party Set; but a single domain itself can only appear in one set.
@torgo @rhiaro - thank you for your feedback! FYI, I opened #47 and #48 to keep track of your feedback that I plan to resolve separately. For #47 , we are working on additional text/visual aids to help explain the application of FPS to cookies (via the For #48 , we have upcoming cross-browser discussion on UA Policy happening in the PrivacyCG, where we hope to make progress on the concerns that Amy raised. For now, I plan to merge this PR; but please feel free to open new issues if you have any additional comments! |