Proposal: require websites to call an async API to request dating sharing within a first-party set

[arthuredelstein]

I believe some browsers will insist on a policy that users must give consent before data is shared between different eTLD+1 domains. Other browsers may decide that such consent is not needed.

To make sure it's possible for browsers to obtain consent, I would like to propose a general policy to be included in the First Party Sets proposal, to limit how data is shared between domains in first party sets. To get cross-domain access to cookies/data, a website should be required to make an async call, which would give the browser the opportunity to ask the user permission before sharing that cross-domain data. Browsers that don’t see a need to ask for user consent can simply resolve the promise immediately with the cross-domain data.

I think this policy addition is extremely crucial for user consent. If the FPS permission is granted synchronously (as the explainer currently describes), then it is impossible to for browsers to ask user permission first before data is leaked between domains. Browsers that decide not to implement First Party Sets are then placed at a disadvantage, and will potentially be confronted in the future with web compatibility problems.

[arthuredelstein]

I think the Storage Access API might be a possible approach. That is — some browsers could use an FPS policy to automatically grant storage access through that API for any pair of domains in the same First Party Set. Other browsers might decide not to consult any FPS policy and, instead, prompt the user to decide whether to grant or deny access.

[krgovind]

Thanks for the suggestion, @arthuredelstein!

Making our design more interoperable is definitely something I'm very interested in.

Note that we have some other applications under consideration for FPS in addition to access to cookies in cross-domain contexts (e.g. as partition key for cookies , WebID directed identifiers being sharded per first-party, Privacy Budget applies across a FPS). More recently, on a PrivacyCG call, we also discussed whether bounce tracking interventions could grant exceptions to sites within the same First-Party Set.

The use of FPS with Storage Access API for heuristics, or supplementary information on the prompt (see #28 ) certainly seems to fit into Firefox, and Safari's current model for allowing cross-domain access to cookies and site data.

However, I'm not sure how we could reconcile the use of an async API with Chrome's proposed new SameParty cookie attribute, or even cookies partitioned by FPS, which gets sent on network requests. Such requests could happen even before any Javascript is loaded, so this is before the Storage Access API could be invoked.

Perhaps we could think of introducing a new async API such as isSameParty(site1, site2); and have all cross-domain access to cookies/storage gated on this. But I'm not sure if renderer-initiated requests can be gated on such an API? Certainly in Chrome's case, we could optimize away the call to the async API; but it might introduce complexity in other implementations? WDYT?

[arthuredelstein]

Thanks for the suggestion, @arthuredelstein!

Making our design more interoperable is definitely something I'm very interested in.

Great to hear! I hope we can keep discussing options so that browsers with more restrictive rules can remain web compatible.

However, I'm not sure how we could reconcile the use of an async API with Chrome's proposed new SameParty cookie attribute, or even cookies partitioned by FPS, which gets sent on network requests. Such requests could happen even before any Javascript is loaded, so this is before the Storage Access API could be invoked.

Sending cross-site cookies on early network requests without any user prompt would indeed be a big problem and would likely break the experience for browsers that don't support FPS.

Perhaps we could think of introducing a new async API such as isSameParty(site1, site2); and have all cross-domain access to cookies/storage gated on this. But I'm not sure if renderer-initiated requests can be gated on such an API? Certainly in Chrome's case, we could optimize away the call to the async API; but it might introduce complexity in other implementations? WDYT?

Yes, we could be back to the same web-compatibility problem if websites came to rely on that optimization, so that more restrictive browsers are forced to block rendering of a page until the user responds to a prompt.

In general, I think it would help to look at how FPS could be made more restrictive rather than more expansive. That is -- what capabilities are considered absolutely necessary, and what are simply nice to have? Because as FPS becomes more expansive, it is weakening privacy protections for users.

[krgovind]

In general, I think it would help to look at how FPS could be made more restrictive rather than more expansive. That is -- what capabilities are considered absolutely necessary, and what are simply nice to have? Because as FPS becomes more expansive, it is weakening privacy protections for users.

@arthuredelstein It would be helpful if you could specify what status quo FPS is more expansive compared to, because that might be a relative statement. :) Perhaps, Firefox's current default ETP mode behavior is instructive to compare against; in which case I think FPS is more restrictive because it allows us to enable a future where third-party cookies can be blocked everywhere (not only on domains that are classified as "trackers"), while allowing for a more improved version of the Disconnect entities list (by modifying it to a mechanism that is site-declared, and policy-verified). FPS allows for a "fail closed" future, where domains not on the same FPS will have their cookies blocked; where Firefox's default ETP mode uses a "fail open" mechanism, where trackers that are not on the blocklist, or entities that are incorrectly classified as the same first-party continue to be able to use 3p cookies.

Also, note that our goal is absolutely to adhere to the privacy principles that have been articulated by all major browser vendors (the Do Not Track specification also offers precedence); and not a single one defines tracking as something that happens across domains. Generally, tracking is defined as something that happens across parties. See excerpts from browser policies here. The primary mechanism that we've proposed to adhere to these principles is the "UA Policy", for which we are inviting feedback here.

I realize that Storage Access API is Firefox's preferred mechanism for cross-site access to cookies; but in addition to the concerns I've previously mentioned on the FPS TAG review thread, I think requiring cookies to be script-accessible may be a security anti-pattern. Due to script-accessible cookies' vulnerability to XSS attacks, we (Chrome) have generally been advocating that developers use the HttpOnly attribute (e.g. see this recent I/O talk starting at 3:44, our CHIPS / partitioned cookies proposal requires the attribute). Would Firefox consider a different design (such as a cookie attribute, or maybe something else) where the 3p could request storage access without having to load script, or requiring cookies to be script-accessible?

[johannhof]

@arthuredelstein It would be helpful if you could specify what status quo FPS is more expansive compared to, because that might be a relative statement. :) Perhaps, Firefox's current default ETP mode behavior is instructive to compare against; in which case I think FPS is more restrictive because it allows us to enable a future where third-party cookies can be blocked everywhere (not only on domains that are classified as "trackers"), while allowing for a more improved version of the Disconnect entities list (by modifying it to a mechanism that is site-declared, and policy-verified). FPS allows for a "fail closed" future, where domains not on the same FPS will have their cookies blocked; where Firefox's default ETP mode uses a "fail open" mechanism, where trackers that are not on the blocklist, or entities that are incorrectly classified as the same first-party continue to be able to use 3p cookies.

While it's totally fair to call out the real status quo in Firefox which is ETP, I want to emphasize again that we consider any list-based approaches a temporary workaround for web compat. We're working towards rolling out State Partitioning to all release users. So I think that (full cookie blocking/isolation) is what Arthur refers to as the status quo, somewhat prematurely but probably inevitably. It's certainly what we'll measure any new API proposals against.

Also, note that our goal is absolutely to adhere to the privacy principles that have been articulated by all major browser vendors (the Do Not Track specification also offers precedence); and not a single one defines tracking as something that happens across domains. Generally, tracking is defined as something that happens across parties. See excerpts from browser policies here. The primary mechanism that we've proposed to adhere to these principles is the "UA Policy", for which we are inviting feedback here.

Establishing party as a new privacy boundary in the browser may make sense (and I guess that question makes up a fair bit of the discussion around this proposal), but I think we should acknowledge that origin/domain is the existing boundary and that when we consider expanding it (especially with proposals like the SameParty attribute) we should give browsers with more privacy-concerned users the chance to add additional consent and transparency measures, such as a prompt.

I realize that Storage Access API is Firefox's preferred mechanism for cross-site access to cookies; but in addition to the concerns I've previously mentioned on the FPS TAG review thread, I think requiring cookies to be script-accessible may be a security anti-pattern. Due to script-accessible cookies' vulnerability to XSS attacks, we (Chrome) have generally been advocating that developers use the HttpOnly attribute (e.g. see this recent I/O talk starting at 3:44, our CHIPS / partitioned cookies proposal requires the attribute). Would Firefox consider a different design (such as a cookie attribute, or maybe something else) where the 3p could request storage access without having to load script, or requiring cookies to be script-accessible?

Storage Access API has an asynchronous component specifically to allow different browsers to run heuristics and checks that ensure that the requesting origin is allowed access. This can mean a prompt but doesn't have to. I agree that the SAA unfortunately makes handling HTTP-only cookies much harder for developers, which can be considered a design tradeoff.

If requesting storage access for every origin in the party is unmanageable, how do you feel about requiring the parent to use an async API when registering the FPS? For example, sso.example.com could call something like await document.registerFirstPartySet() which would give concerned browsers the chance to prompt the user for allowing the establishment of the set, including a description and maybe all included domains in an expandable list. This wouldn't cause issues on sso.example.com because it's already a top-level document and can use its first party cookies. Then, later, when new *.example.com pages are loaded they'd allow embedded sso.example.com resources access to their first party cookies on load.

I think that such a mechanism would already go a long way in terms of fighting abuse of the feature, simply by virtue of ensuring user participation and awareness, even if a portion of users doesn't care about the content of the prompt. The prompt could also be designed and triggered in a way that minimizes user confusion, but by ruling out any kind of async API requirement we can't even experiment with it.

Thoughts @krgovind ? Also happy to discuss this on the Privacy CG meeting tomorrow :)

[arthuredelstein]

So I think that (full cookie blocking/isolation) is what Arthur refers to as the status quo

I hadn't referred to a status quo: but it is already true that State Partitioning is the status quo in Firefox Strict Mode and Private Browsing, as well as Tor Browser. (And, as Johann says, we are working toward using State Partitioning by site in Firefox in the future as well.)

The issue is -- if First Party Sets remains synchronous, it implies that these existing browsing products would become web incompatible. My question is: can we find a way to make First Party Sets compatible with these existing products that partition by eTLD+1?

[johannhof]

So I think that (full cookie blocking/isolation) is what Arthur refers to as the status quo

I hadn't referred to a status quo: but it is already true that State Partitioning is the status quo in Firefox Strict Mode and Private Browsing, as well as Tor Browser. (And, as Johann says, we are working toward using State Partitioning by site in Firefox in the future as well.)

Ah, right, you didn't use that term, sorry, but I think/hope I captured your meaning otherwise :)

[bslassey]

origin/domain is the existing [privacy] boundary

I don't think this is true. In current default browsing mode (i.e. not private browsing or strict mode), the privacy boundary is the entire web. Any origin not classified as a tracker by ETP can have shared state across multiple other arbitrary origins and domains.

Storage Access API has an asynchronous component specifically to allow different browsers to run heuristics and checks that ensure that the requesting origin is allowed access. This can mean a prompt but doesn't have to.

What heuristics or checks require an asynchronous interface other than prompts?

[johannhof]

origin/domain is the existing [privacy] boundary

I don't think this is true. In current default browsing mode (i.e. not private browsing or strict mode), the privacy boundary is the entire web. Any origin not classified as a tracker by ETP can have shared state across multiple other arbitrary origins and domains.

Right, Kaustubha already pointed out that Firefox doesn't ship state partitioning in Standard yet, but we're working on it. For that reason it's the model that we're considering for evaluating future proposals against. In Safari this is shipping by default and Chrome has also announced deprecation of third party cookies.

Storage Access API has an asynchronous component specifically to allow different browsers to run heuristics and checks that ensure that the requesting origin is allowed access. This can mean a prompt but doesn't have to.

What heuristics or checks require an asynchronous interface other than prompts?

The point is that because one of the checks could be a prompt it needs to be async, but that doesn't mean that the browser has to show a prompt (Firefox doesn't in some cases).

[krgovind]

@johannhof Could you take a look at the language in PR #54 and let us know if that sufficiently covers this suggestion?

[arthuredelstein]

Speaking in a individual capacity only: PR #54 is a welcome improvement, but I think couching the request API as a mere recommendation still leaves some browsers at a disadvantage. That is: if majority-share browsers don't require websites to request access to cross-domain storage, then many website developers won't bother to make that request. So minority-share browsers requiring user consent will still have a broken experience. So I would argue the language should be that: in order to get access to FPS storage, a website MUST first request permission through an asynchronous API.

[michael-oneill]

+1 Their might be less resitance to FPS if restriction lifting required a user prompt, allowing the user to be properly informed of who the controller of the set was, and the reasons for requiring data sharing across domains. There would necessarily also have to be browser UI to warn users when sets were active, and allow them to revoke their decisions, Restriction-lifting shuld also expire after a resonable time.

[krgovind]

@arthuredelstein @michael-oneill Apologies for not pinging this issue sooner; but I believe the changes we've since made to the proposal - see summary of changes in issue #92, and the Leveraging the Storage Access API section of the current explainer - your feedback is fully addressed. Particularly, the new proposal covers:

• Interoperability with browsers that don't support First-Party Sets
• The ability for browsers to surface request for storage access as a user prompt with information about set composition
• Flexibility for browsers to allow revocation/expiration of storage access permissions

Please let me know if you think otherwise!

[arthuredelstein]

Thank you for letting me know, @krgovind! That indeed sounds like a welcome change in the proposal from my perspective. Will the SAA be required for any website to use FPS, or would there be alternative means that would bypass SAA?

[krgovind]

@arthuredelstein Either SAA or a similar API called requestStorageAccessForOrigin must be used. We proposed the latter because SAA was designed for the authenticated embeds usecase and is limited to invocation from an iframe that requires user activation, and isn't suitable for other use-cases (for example, credentialed cross-site subresources like profile pictures). It follows a similar permissioned model as SAA, but with different ergonomics.