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

Add usecases, applications, acceptance process, etc. #45

Merged
merged 5 commits into from
Aug 10, 2021

Conversation

krgovind
Copy link
Collaborator

  • 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.

krgovind added 4 commits June 10, 2021 22:41
* 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.
@krgovind krgovind requested a review from torgo June 11, 2021 03:37
README.md Show resolved Hide resolved
Copy link

@rhiaro rhiaro left a 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.

README.md Outdated Show resolved Hide resolved

## 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.
Copy link

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.

Copy link
Collaborator Author

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.

Copy link
Collaborator Author

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.
@krgovind
Copy link
Collaborator Author

@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 SameParty attribute) better, especially within the context of how this conforms to Same Origin Policy.

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants