You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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
2. Third party operating in a partitioned third-party context that is specific to the first-party it's embedded in
3. Third party operating in its primary third-party context
The text was updated successfully, but these errors were encountered: