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

Domains state purpose for being in First-Party Set #28

Closed
krgovind opened this issue Oct 5, 2020 · 3 comments
Closed

Domains state purpose for being in First-Party Set #28

krgovind opened this issue Oct 5, 2020 · 3 comments

Comments

@krgovind
Copy link
Collaborator

krgovind commented Oct 5, 2020

@johnwilander proposed during the F2F that domains should state their purpose for being in a set with the other domains. Specifically, this may be useful for domains that provide single-sign-on capability, and is something that could be surfaced to users within the context of storage access API and isLoggedIn.

Questions:

  • Is the expectation for users to opt-in or opt-out per domain; and mostly use FPS membership information to show more user-friendly prompts? Or would storage access be granted automatically?
  • What about domains that are separated for non-SSO reasons, such as ccTLD variants, or for security reasons (e.g. domains that host user-uploaded content)?
@JadeKessler
Copy link

Some potential concerns to think about with regards to this might be:

  • Since there is a user agent policy for FPS, should the purpose provided by the organization be verified by the user agent during the policy verification process? Verifying something like this would likely require examining multiple user flows and checking the validity over time, which may be difficult to enforce.

  • Capturing some feedback from PrivacyCG call, there could be multiple domains serving the same purpose or a set of domains serving multiple purposes, which may be difficult to communicate to users in an understandable way.

  • It would also likely require defining meaningful categories to represent purpose in a consistent way to users. Terminology may not translate easily across industries, countries etc...

@krgovind
Copy link
Collaborator Author

Got some clarification on use-cases from John, which answers some of the questions I posed in my initial post. They are primarily interested in login related domains: "It could help with SSO, bounce tracking prevention, Storage Access API prompts, Storage Access API cookie access scope beyond per-page, and auth flows that have an easy integration with IsLoggedIn."

@johannhof
Copy link
Member

We did something quite similar with the subsets design and I don't think that we'll get a lot more out of this issue, so closing :)

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

No branches or pull requests

4 participants