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

Perhaps organize by the different third party contexts? #11

Open
colinclerk opened this issue Aug 28, 2019 · 0 comments
Open

Perhaps organize by the different third party contexts? #11

colinclerk opened this issue Aug 28, 2019 · 0 comments

Comments

@colinclerk
Copy link

After sharding is applied, I believe there are three distinct contexts a third party can operate in. Perhaps it's easier to think about changes when they're grouped in these buckets?

1. Third party operating in the first-party context

  • When a website owner copies a <script> tag into their HTML. (analytics)
  • When a website owner sets a subdomain as a CNAME (blogs, support desks)

2. Third party operating in a partitioned third-party context that is specific to the first-party it's embedded in

  • Any requests to a third party resource triggered while browsing the first party (media/iframes/window.open/etc)

3. Third party operating in its primary third-party context

  • I believe this is what the privacy model is trying to eliminate, since combined with (1) it allows identities to be joined.
  • However, there are valid use-cases for a third party having access to its primary context. For example, when interacting with an embedding tweet, users expect the interaction to apply to their account. Or: Google's helper SDK for OAuth uses window.open, and that would degrade if it only had access to a partition.
  • Webkits restricts this third-party access to its primary context with the Storage Access API
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

1 participant