Update Applications section with proposed Applications #84
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
@@ -127,13 +127,73 @@ First-Party Sets is a proposal to standardize a mechanism that solves this issue | |||||||||||||||
|
|
||||||||||||||||
| # Applications | ||||||||||||||||
|
|
||||||||||||||||
| Various applications of First-Party Sets have been suggested by different parties. The list below is an effort to compile suggested applications. | ||||||||||||||||
|
|
||||||||||||||||
| ## Initial Proposed Applications | ||||||||||||||||
|
|
||||||||||||||||
| **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.
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.
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
and
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). |
||||||||||||||||
|
|
||||||||||||||||
| **Relaxing full third-party cookie blocking for cookies with the SameParty attribute**\ | ||||||||||||||||
| _Interest from: Chrome, Edge_ | ||||||||||||||||
|
|
||||||||||||||||
| 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.
Suggested change
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.
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):
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:
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 the clarification. How does this edit look to you?
Suggested change
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.
The entity list? How so? :) There was a problem hiding this comment.
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 There was a problem hiding this comment. I think the link is outdated:
Suggested change
|
||||||||||||||||
|
|
||||||||||||||||
| **Cookie partitioning key**\ | ||||||||||||||||
| _Interest from: Chrome, Edge_ | ||||||||||||||||
|
|
||||||||||||||||
| 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) |
||||||||||||||||
| _Under consideration by: [Chrome](https://github.com/privacycg/first-party-sets/issues/37), Edge_ | ||||||||||||||||
|
|
||||||||||||||||
| 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. |
||||||||||||||||
| _Under consideration by: [Chrome, Edge](https://github.com/privacycg/first-party-sets/issues/35)_ | ||||||||||||||||
|
|
||||||||||||||||
| To mitigate performance issues from full cache partitioning, FPS could enable a mechanism for sites to opt into sharing a cache partition within the same set. This would have to be opt-in to ensure participating sites are protecting against side-channel cache attacks from compromised sites within the set. \(TODO: need to write up security considerations\). | ||||||||||||||||
|
|
||||||||||||||||
| **Relaxing cross-site prefetch restrictions within the same FPS**\ | ||||||||||||||||
| _Under consideration by: [Chrome](https://github.com/privacycg/first-party-sets/issues/35#issuecomment-797713194), Edge_ | ||||||||||||||||
|
|
||||||||||||||||
| For privacy reasons, prefetches are limited to same-origin or same-site. To help performance, browsers could decide to expand this limitation to same-party \(this has no privacy implications for browsers that decide to relax 3p cookies based on FPS but may be a worthwhile trade-off for others, as well\). | ||||||||||||||||
|
|
||||||||||||||||
| **Relaxing PWA origin-scoping to FPS**\ | ||||||||||||||||
| _Under consideration by: [Edge](https://github.com/privacycg/first-party-sets/issues/46#issuecomment-892251777)_ | ||||||||||||||||
|
|
||||||||||||||||
| 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? |
||||||||||||||||
| _Interest from: [Safari](https://github.com/privacycg/first-party-sets/issues/28)_ | ||||||||||||||||
|
|
||||||||||||||||
| Some websites host authentication services on a separate site; and may require frequent cross-site storage access on resources from that site. Allowing websites that span multiple sites to designate specific sites in the FPS as a single-sign-on service could be useful to surface to users in Storage Access API prompts, and potentially extend the duration/scope of the storage access grant; thus improving user experience. | ||||||||||||||||
|
|
||||||||||||||||
| **Use of FPS to restrict or relax requirements for SAA**\ | ||||||||||||||||
| _Interest from: [Safari](https://github.com/privacycg/storage-access/issues/83#issuecomment-989205411)_ | ||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
| **Federated Credentials Management (FedCM) API**\ | ||||||||||||||||
| _Interest from: Chrome_ | ||||||||||||||||
|
|
||||||||||||||||
| Issuing FedCM [directed identifiers](https://fedidcg.github.io/FedCM/#mitigation-directed-identifiers) by First-Party Set, so the same account can be shared across multiple applications or services provided by the same first-party. | ||||||||||||||||
|
|
||||||||||||||||
| **Privacy Budget**\ | ||||||||||||||||
| _Interest from: Chrome_ | ||||||||||||||||
|
|
||||||||||||||||
| Applying [Privacy Budget](https://github.com/bslassey/privacy-budget) across an entire First-Party Set, in order to prevent fingerprinting entropy from being accumulated across domains that are able to communicate in an unconstrained manner due to access to cross-domain, same-party cookies. | ||||||||||||||||
|
|
||||||||||||||||
| **Same-party token for other protocols such as Cross-Origin-Resource-Policy**\ | ||||||||||||||||
| _See [issue 5](https://github.com/privacycg/first-party-sets/issues/5)_ | ||||||||||||||||
|
|
||||||||||||||||
| Expanding access by adding a same-party token might help sites adopt security-critical headers such as CORP, which might not be viable for them if they were restricted to same-site or same-origin only. | ||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
| # Site-Declared Sets in Browsers | ||||||||||||||||
|
|
||||||||||||||||
|
|
||||||||||||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree that the benefits to the users are indirect only. Each of these applications materially improves user's experience with the site. Specifically
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are double-edged benefits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.