Update Applications section with proposed Applications #84
Conversation
Various applications of First-Party Sets have been suggested by different parties in Privacy CG and other avenues. The update is aimed at compiling various suggested applications in a single place.
|
I'm a bit surprised to see the call out to FCM for directed identifiers, as I was under the impression that directed identifiers were not in scope for that work item. |
Just as clarification, but it is important to note the distinction between scoping and sequencing: global identifiers (specifically, email addresses, phone numbers and subs) are and will continue to be a big tracking vector, but not one that we are planning to tackle on at the moment. There are still a lot of missing pieces to enforce directed identifiers, but we are actively working on the dependencies such that at some point we can transition to directed, but that, as you must have guessed, isn't going to happen overnight. So, it is very much within the scope of FedCM, but it isn't where we are starting from. |
| To help websites maintain various uses of cross-site cookies within the same organization such as for SSO, consent management, sandboxed domains, etc. | ||
| Cookies need to be labeled with the [SameParty attribute](#sameparty-cookies-and-first-party-sets). | ||
|
|
||
| Prior art: Firefox and Edge use the [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. |
There was a problem hiding this comment.
I think other Mozillians have stated this before: we don't consider this prior art. This is a workaround to more quickly get to a place where authority is fully derived from the information in the address bar.
(Safari naming it "Quirks" suggests a similar line of thinking, but I won't speak for them.)
There was a problem hiding this comment.
The intention here is to document similar relaxation of cross-site cookie access currently shipping in other major browsers, based on curated lists of related/affiliated sites. "Prior Art" happens to be a succinct term that explains that intention, but happy to use a different phrase. :)
Would "Similar mechanism currently employed in other browsers as a workaround" be more appropriate?
There was a problem hiding this comment.
I'm not sure. The key point is that we want this to go away and don't consider it something worth standardizing, unless the goal of that standardization effort is aligned with the goal of eventually removing it.
There was a problem hiding this comment.
Understood. We didn't mean for this to come off as us presuming Mozilla's support for FPS standardization. It was only referring to similar mechanisms that exist in browsers.
There was a problem hiding this comment.
While I don't read it as such, the message here is pretty clear: "FPS is the permanent solution".
What I think is missing from this is a discussion of the intent behind the mechanisms. Mozilla has been clear that our use of the entity list is a stopgap. The entity list is terrible for a range of reasons, some of which FPS aims to solve, some of which FPS also shares.
| Prior art: Firefox and Edge use the [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. |
There was a problem hiding this comment.
I think it's worth pointing out something else here. We use the list for blocking known trackers access to cookies and storage in Firefox (release version). This is to prevent our users from being tracked. That's a fundamentally different goal from FPS.
FPS is a Google proposal to augment state partitioning. We don't think state partitioning (which we're calling Total Cookie Protection and we haven't rolled out to release yet, but are actively working on) needs to be augmented with lists in that manner. We may or may not keep the tracker list around, but it fundamentally shouldn't change the privacy argument much, except perhaps when we block for fingerprinting or other aspects we don't have a holistic solution for yet.
We do have heuristics in place around TCP to mitigate breakage, but we believe we can reduce those over time.
So respectfully, please stop making this comparison.
There was a problem hiding this comment.
@annevk Thanks for your note, and the discussion on the call. The discussion was very educational for me, because it made me question my assumption that we were all targeting the same end-state regarding tracking protections. As Chrome has announced, our desired end-state is to phase out usage of third-party cookies completely, without use of tracker blocklists, and ideally even without temporary escape hatches like Storage Access API.
Is comprehensive third-party cookie blocking/partitioning on all cross-site contexts something you consider as your desired end-state? The reason I'm asking is if you only plan to intervene on known trackers (for cross-site cookie access, navigational tracking, fingerprinting, and other kinds of tracking protections); that has significantly fewer compat implications than a comprehensive approach that intervenes on all cross-site contexts.
(I plan to modify this section of the PR that you're taking issue with, but just want to make sure I understand your position before proposing the change)
There was a problem hiding this comment.
Is comprehensive third-party cookie blocking/partitioning on all cross-site contexts something you consider as your desired end-state?
Yes.
Partitioning of all site-level state would be ideal. We want the promise we make to be very clear: if the address bar changes, that's a new space. When we get there, only the address bar matters.
Your previous statements about blocklists is probably where we differ most. You seem to view blocklists as inherently bad. We recognize their limitations and failings, but I think our view is somewhat more pragmatic: there will be bad actors and we'll need some way to limit what those bad actors can do. That might entail use of things like blocklists, for actors with established patterns of bad behaviour. That might be true even when the technical protections we have a more robust. As you know, our ability to prevent tracking or secure the browser is finite, so we're simply allowing for the possibility that those systems we've built for might still be useful. And technical enforcement is tricky and inflexible, so there might be a place for some manual processes.
There was a problem hiding this comment.
Hey @martinthomson , super late to this, been learning a lot of the issues in this space from these and other threads. Hoping you can help me relate a couple of your previous points here to current state (both of RWS and the web more broadly):
Mozilla has been clear that our use of the entity list is a stopgap. The entity list is terrible for a range of reasons, some of which FPS aims to solve, some of which FPS also shares.
I think this is saying that Firefox is using the entities.json list to allow a "known tracker" (known according to other Disconnect lists) to be loaded if it's from a site that is owned by the top level site, according to that list. I'm a little unclear how this impacts Total Cookie Prevention but it does seem to still be active. So I'm hoping to understand:
- What is bad about the Disconnect entities.json list? Is it how the list is curated? Something about how it conveys information?
- The answer to (1) may answer this, but which issues of those does RWS still share in your mind?
- Is Firefox still planning on reducing the ways it uses entities.json?
We want the promise we make to be very clear: if the address bar changes, that's a new space.
Would this mean that the only way a 3P embed could see information across top level sites would be either something like FedCM, or an explicit request via something like SAA?
There was a problem hiding this comment.
There are a number of problems with lists, which is why we still hope to wean ourselves from a dependence on them. The obvious problems are simple maintenance and ensuring they are correct. The less immediate problems are that they often embed bias and inequity (I don't know how well Disconnect is able to serve sites from communities that exclusively use different languages, for example). The pragmatic problem is that it takes a bunch of effort to keep lists synchronized with every browser instance.
There was a problem hiding this comment.
Thanks for putting this together Harneet. Some of these were new to me.
I don't think that it changes my opinion at all, but it's good to have these listed out. To expand on that a little, I'm not seeing any direct benefits for users here. The indirect benefits might be there, but that isn't outweighed by the negatives.
| To help websites maintain various uses of cross-site cookies within the same organization such as for SSO, consent management, sandboxed domains, etc. | ||
| Cookies need to be labeled with the [SameParty attribute](#sameparty-cookies-and-first-party-sets). | ||
|
|
||
| Prior art: Firefox and Edge use the [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. |
There was a problem hiding this comment.
While I don't read it as such, the message here is pretty clear: "FPS is the permanent solution".
What I think is missing from this is a discussion of the intent behind the mechanisms. Mozilla has been clear that our use of the entity list is a stopgap. The entity list is terrible for a range of reasons, some of which FPS aims to solve, some of which FPS also shares.
| Prior art: Firefox and Edge use the [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. |
| @@ -127,13 +127,73 @@ First-Party Sets is a proposal to standardize a mechanism that solves this issue | |||
|
|
|||
| # Applications | |||
|
|
|||
| In support of the various browser privacy models, first-party sets only control when embedded content that would otherwise be considered third-party can access its own state. Examples: | |||
| Various applications of First-Party Sets have been suggested by different parties. The list below is an effort to compile suggested applications. | |||
There was a problem hiding this comment.
It might pay to talk about who gets what here.
What are the benefits that each constituency see as the result of doing FPS? Users? Sites? Browsers?
There was a problem hiding this comment.
I disagree that the benefits to the users are indirect only. Each of these applications materially improves user's experience with the site. Specifically
- Improved ease of use with applications like single sign on, unified consent management, persistent personalization etc.
- Improved security on sites with user uploaded content.
- Improved performance and reduced latency with caching etc. especially for users who have a slow connection to the internet.
There was a problem hiding this comment.
These are double-edged benefits.
- A site might be able to offer a smoother sign-on process, but this comes at a cost to users in a loss of control over how their activity on different sites is shared. Similar things apply to consent (if I let one site access my camera, maybe I don't want other sites to gain the same privilege). And personalization... the same argument is made in favour of tracking.
- This is very much an indirect benefit.
- I might concede this, but it's not that significant relative to the above.
There was a problem hiding this comment.
I can see how 3 can be detrimental to security by directly removing a security boundary, but I don't see how FPS can be beneficial to security. Where is that explained below? It's already the case that if you have user uploaded content you need to use a separate registrable domain to host that. I don't see how FPS changes anything there.
There was a problem hiding this comment.
I think the point here is that some user uploaded content is still access-restricted through cookies, which seems impossible to accomplish with full cross-site cookie blocking. The user content would have to be uploaded on the main site to achieve effective access control. With the Same-Party cookie attribute proposal powered by FPS it would be possible to set a Same-Party cookie for this purpose (with attention to the security considerations outlined in #85).
I don't think this is an indirect benefit or use case of SameParty. This pattern is common with interactive coding environments, cloud storage providers and blogging/commenting platforms. Firefox has already seen instances of breakage caused by variations of this pattern (user content hosted on a separate authenticated site) and I'd expect to see many more. Some of these can be worked around with partitioning because they're limited to viewing content in an embedded fashion, but some other things are much harder to do.
Regarding the consent use case, I think Harneet was not referring to permissions and rather things like cookie consent management data which could be shared between sites of the same data controller, IIUC.
There was a problem hiding this comment.
Doesn't that presume a very specific outcome of the storage access discussion? That is, if you block cookies in a cross-site context, this is one of the problems you create. Solving it using FPS is - at least in my view - the wrong answer. The right answer is to allow cross-site content access to cookies (storage might suffice, but you probably want to avoid extra round trips).
There was a problem hiding this comment.
I agree, the question is how do we relax cookies in this case.
None of the possible solutions is without drawbacks. Partitioning probably works for many cases but fails when moving out of an embedded context. Storage Access API mediates full 3PC access but might be too unwieldy and noisy for this, I suspect, rather popular use case. SameParty arguably allows for building/maintaining the best user experience while staying within the privacy boundaries guaranteed by FPS. However, these boundaries are based on ownership/data controllership (TBD) and not on whats-in-the-url-bar, which I think is a fair concern to consider given the historic security/privacy model of the web.
I'm going slightly off-topic here, so coming back to the original question I mainly wanted so show that solving the problem of separate (authenticated) user content sites is definitely serving a legitimate need of users (and developers).
Finally, your feedback makes me think that we should collectively do a better job of listing and evaluating the various known scenarios that will be broken by e.g. third-party cookie deprecation or navigational tracking protections, to have more common ground when discussing potential solutions.
There was a problem hiding this comment.
given the historic security/privacy model of the web
Hm, I guess this is inaccurate in that the actual historic privacy model has been unregulated third-party access and the newly proposed ideal end state is "partitioned by whats-in-the-url-bar", which even where it's already implemented isn't fully achieved because of heuristic loop holes etc.
| **Bounce/navigation-based tracking protections**\ | ||
| _Interest from: [Safari](https://github.com/privacycg/first-party-sets/issues/53#issuecomment-902396090), Chrome, Edge_ | ||
|
|
||
| To allow for first-party cross-site single-sign-on flows to continue working, where [navigation-based tracking mitigations](https://privacycg.github.io/nav-tracking-mitigations/) are applied by browsers. Sign-on typically involves exchange of authentication tokens or other user identifiers via URL parameters on top-level navigation and redirects; which may get classified as navigational tracking. |
There was a problem hiding this comment.
How does this relate to other efforts in this space, like FedCM? Is FPS a temporary solution until FedCM is implemented? Is FedCM not viable?
How does FPS help for sites that don't have their own in-house identity management systems? A site that uses an external identity provider won't have that identity provider in their FPS, so unless they do some integration work (a CNAME of a subdomain, for instance), this isn't going to help any.
There was a problem hiding this comment.
How does this relate to other efforts in this space, like FedCM? Is FPS a temporary solution until FedCM is implemented? Is FedCM not viable?
FedCM is currently being designed for federated identity providers that follow OAuth/OpenID-type flows; and first-party SSO is not in-scope for that API.
How does FPS help for sites that don't have their own in-house identity management systems? A site that uses an external identity provider won't have that identity provider in their FPS, so unless they do some integration work (a CNAME of a subdomain, for instance), this isn't going to help any.
You’re correct that FPS will not help for sites that don’t host their own identity management services, as FPS is not meant to serve use cases that extend beyond a single entity. For the simple case (relying parties that don’t span multiple registrable domains) we are considering a partitioning solution, which we expect to discuss further in privacycg/storage-partitioning/issues/28.
In the event that the site belongs to a FPS, and intends to maintain the same login state across multiple registrable domains, using the FPS as a (cookie/storage) partitioning key should allow the same solution to extend to the entire set.
Indeed, a CNAME-based solution (which has the same effect from the privacy perspective as partitioning state) can also be used to achieve this; but there have been some questions that have come up in the CG about browser tracking interventions on CNAME’d domains, so we (as a community) are going to have to revisit that as a potential recommendation.
There was a problem hiding this comment.
On
How does this relate to other efforts in this space, like FedCM? Is FPS a temporary solution until FedCM is implemented? Is FedCM not viable?
and
FedCM is currently being designed for federated identity providers that follow OAuth/OpenID-type flows; and first-party SSO is not in-scope for that API.
We recently wrote down how we think about the relationship between FedCM and FPS here.
While FedCM is indeed intended to address OpenID/SAML-type flows, some of them are indeed used to enable first-party SSO, so would fit reasonably within FedCM (in that the user experience that FedCM provides - one of choosing a third-party federated accounts, would apply).
FedCM is designed to be agnostic/complementary/orthogonal to FPS in that it should work across privacy boundaries that each user agent decides to impose / delineate. Ideally, that privacy boundary would be interoperable between browsers, but if / until they aren't, FedCM can still play a constructive role in conjunction with or independently of FPS (or other signals, e.g. enterprise policies).
| To allow third-party software-as-a-service vendors \([reference use-case](https://github.com/privacycg/first-party-sets/issues/33)\) to continue supporting websites whose user flows span multiple sites/domains via cookies. Third-party sites must opt-in via the Partitioned attribute to partition the cookie by the [top-level website’s FPS](https://github.com/WICG/CHIPS#chips-and-first-party-sets). | ||
|
|
||
| ## Other potential applications under discussion | ||
| **Storage partitioning key**\ |
There was a problem hiding this comment.
How is this different from the cookie example?
There was a problem hiding this comment.
(See response to comment on Cache partitioning key section)
|
|
||
| To allow third-party software-as-a-service vendors to continue supporting websites whose user flows span multiple sites/domains via storage \(IndexedDB, localStorage, sessionStorage, Service Workers, etc.\); [storage partitioning](https://github.com/wanderview/quota-storage-partitioning/blob/main/explainer.md) could use the top-level website’s FPS \(instead of top-level site\) as a partition key. However, there are security implications \(TODO: need to write up security considerations\) that need to be accounted for before making such a change. | ||
|
|
||
| **Cache partitioning key**\ |
There was a problem hiding this comment.
Same as above. Isn't this all storage?
There was a problem hiding this comment.
See Erik’s summary here from a previous discussion on this topic that led to a different strategy than for cookies. Essentially, there are side-channel concerns with cache or service workers sharing the same partition across domains in a FPS, some of which may host untrusted (e.g. user-uploaded content) content; so we’d like to consider a per-domain opt-in to ensure that web developers understand where there are XS-leak implications.
|
|
||
| Progressive Web Apps \(PWAs\) are currently scoped to origins; therefore, cross-origin navigations may result in warnings, or open in a separate environment such as a [Custom Tab](https://developer.chrome.com/docs/android/custom-tabs/). PWA developers would like to scope their apps to multiple origins, using [scope_extensions](https://github.com/WICG/manifest-incubations/blob/gh-pages/scope_extensions-explainer.md). Since this mechanism is dynamically asserted, it may be an improvement for the browser to check that where the _scope_extensions_ list origins that are cross-site; all sites belong to the same FPS. | ||
|
|
||
| **Use of FPS metadata in Storage Access API prompts**\ |
There was a problem hiding this comment.
This probably belongs under the storage heading also.
There was a problem hiding this comment.
Did you mean the "Storage partitioning key" heading, or something else? I don't think this is the same as the former, since SAA grants access to unpartitioned cookies?
| To help websites maintain various uses of cross-site cookies within the same organization such as for SSO, consent management, sandboxed domains, etc. | ||
| Cookies need to be labeled with the [SameParty attribute](#sameparty-cookies-and-first-party-sets). | ||
|
|
||
| Prior art: Firefox and Edge use the [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. |
There was a problem hiding this comment.
Thanks for the clarification. How does this edit look to you?
| Prior art: Firefox and Edge use the [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. | |
| Prior art: Edge uses the [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. | |
| Similar idea used elsewhere: In their default tracking protection mode, Firefox currently also uses the Disconnect [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list). However, Firefox intends for the usage of the entity list to be temporary, and plans to phase out its usage in the medium-to-long term. A combination of curated lists and heuristics may be used to treat any resulting site compatibility issues in the interim. |
There was a problem hiding this comment.
@annevk @martinthomson Sorry, I just realized this forked our comment thread. Would you be able to take a look at my proposed edit and let us know if this looks okay to you? We'd like to merge in this PR as soon as resolved this thread.
There was a problem hiding this comment.
I don't see how it's a similar idea. This list is to actively block bad actors. Our plan is partitioning for everyone which to some extent makes blocking bad actors unneeded (but it might still be good for certain other attack vectors). FPS goes completely counter to our long term goal of having all authority derive from the address bar so I don't see how it's comparable.
There was a problem hiding this comment.
I don't see how it's a similar idea. This list is to actively block bad actors.
The entity list? How so? :)
There was a problem hiding this comment.
disconnect-entitylist.json limits the impact of disconnect-blacklist.json to some extent, but there are no plans to make it undo partitioning or anything of that kind. I continue to fail to see the relevance.
There was a problem hiding this comment.
It's a list that declares domains owned by the same entity for purposes of avoiding breakage, shipped by a major browser. That seems relevant to me.
There was a problem hiding this comment.
It limits the impact of a blocklist which has the aim of limiting known trackers, but it doesn't relate to state partitioning or limiting the impact of state partitioning. Which is a separate feature we plan on shipping. So how it's relevant to FPS, which is about limiting the impact of state partitioning, is rather unclear to us.
There was a problem hiding this comment.
ETP targets 3rd party cookies as well, using a worst-actor blocklist and an entity list. The entity list itself bears a lot of resemblance to the list that is used in FPS, and sparked some inspiration for FPS. I don't see how this is in any way inaccurate. The text doesn't say that ETP is equal to FPS and/or state partitioning.
I think we can agree on the baseline truth that in the past, browsers have attempted to mitigate breakage from anti-tracking restrictions through the grouping of domains by common owner (and some of these attempts are still being shipped today). This is all this text is meant to convey, which is why it carefully tries to ensure that it's not misread as support from Mozilla.
And just to clarify, as this PR is intended to show more clearly, FPS has use cases outside of limiting the impact of 3rd party cookie restrictions like state partitioning.
There was a problem hiding this comment.
If you prefer, we could alter the beginning of that text to In ETP, a default-enabled feature that selectively blocks 3rd party cookies from trackers, Firefox currently uses the entity-list...? That may also give more context to the reader and make it clear why the entity list is mentioned in the section for 3rd party cookie blocking.
| To help websites maintain various uses of cross-site cookies within the same organization such as for SSO, consent management, sandboxed domains, etc. | ||
| Cookies need to be labeled with the [SameParty attribute](#sameparty-cookies-and-first-party-sets). | ||
|
|
||
| Prior art: Firefox and Edge use the [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. |
There was a problem hiding this comment.
I think the link is outdated:
| Prior art: Firefox and Edge use the [entity list](https://github.com/mozilla-services/shavar-prod-lists#entity-list), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. | |
| Prior art: Firefox and Edge use the [entity list](https://github.com/mozilla-services/shavar-prod-lists#disconnect-entitylistjson), Safari’s [Quirks.cpp](https://webkit-search.igalia.com/webkit/rev/0be50a7e5c29546e4c5f27ee6b808f9aaadb9f80/Source/WebCore/page/Quirks.cpp#1154) and [affiliated domains](https://www.w3.org/2017/11/06-webappsec-minutes.html#item12) proposal. |
Various applications of First-Party Sets have been suggested by different parties in Privacy CG and other avenues. The update is aimed at compiling various suggested applications in a single place.