Prompt Spam where First Party Sets are not Used

[bvandersloot-mozilla]

There is concern that prompt spam will be a problem where first party sets are not adopted. See prior discussion on privacy-cg/storage-access#107. Forking here.

[mreichhoff]

Thanks for cutting the issue!

To summarize the prompt spam prevention possibilities besides FPS discussed elsewhere:

• Using a simple counter to limit the number of requests per top-level site, or to implicitly grant a small number of requests, much like is done today in multiple browsers. Separate counters could be used for requestStorageAccessForSite and requestStorageAccess so that there is less risk of contention.
• Treating sites that differ only by ccTLD as equivalent.
• Opting for site applicability (rather than origin) could help reduce notification spam. Note that we’ve been viewing this as an open question.

The latest comment then adds:

One other idea I thought of that I'd like to put forward is the base URL of the script making the request.

I assume this is some rule like (with "match" possibly also meaning same site or same origin): If the base URL of the script making the request does not match the top-level URL, reject the request.

i.e., <script src="a.com/rsafor.js"> calling requestStorageAccessForSite(a.com) on top-level site b.com would be rejected.

I’d be curious about whether there's any concern with CDN URLs (where a script authored by the top-level site but hosted on a CDN may be incorrectly blocked), and with bundled JS (where the true caller might be obscured, though the top-level site’s bundling of it may indicate approval), though I do think it is another good possibility.

[bvandersloot-mozilla]

I was actually thinking some rule like: If the base URL of the script making the request does not match the argument, reject the request.

i.e., <script src="a.com/rsafor.js"> calling requestStorageAccessForSite(a.com) on top-level site b.com would not be rejected, but <script src="b.com/rsafor.js"> calling requestStorageAccessForSite(a.com) on top-level site b.com would

The idea is to indicate an acceptance by a.com to allow storage access requests on its behalf on b.com. This indication comes in the form of a script that calls rsaFor being served to a page on b.com (w/ CORS acting as the control point).

[mreichhoff]

We discussed this issue a bit at TPAC, and I'm posting a summary below to ensure it matches @bvandersloot-mozilla's recollection (hopefully I didn't garble the message 😄):

• The current explainer mixes the prompt spam and 3p opt-in issues (also mentioned in a comment on the original issue). Namely, it seems to suggest First-Party Sets for both security concerns and abuse concerns. I will update it with potential non-FPS solutions for both.
• The CORS proposal in the security considerations document would ensure the embedded party opt-in concern is addressed; failing that, something else besides First–Party Sets and explicitly SameSite=None cookies would likely be needed to indicate embedded party opt-in. I think we agreed that CORS was likely better than the <script> base URL, though (CORS is being discussed on the security improvements issue, so we'll have to stay tuned).
• For non-FPS browsers to avoid prompt spam, promptless grants are doable, but the number of those grants for a given embedded domain will need to be limited to avoid widespread sharing. In other words, a limited number of top-level sites with identical requestStorageAccessForOrigin('site.example') calls could have them resolve without a prompt (with user opt-in via prompt being possible after that number was reached). Based on this, I think there is a path forward for those browsers that don't support FPS.

Does this match your recollection? Thanks again for all the discussion and feedback!

[bvandersloot-mozilla]

For non-FPS browsers to avoid prompt spam, promptless grants are doable, but the number of those grants for a given embedded domain will need to be limited to avoid widespread sharing. In other words, a limited number of top-level sites with identical requestStorageAccessForOrigin('site.example') calls could have them resolve without a prompt (with user opt-in via prompt being possible after that number was reached). Based on this, I think there is a path forward for those browsers that don't support FPS.

I would replace "non-FPS browsers" with Firefox, but otherwise I agree. Some other browsers are opposed to promptless storage access grants and may also be opposed to FPS. This puts them in a tough situation that I think we left unresolved and wanting a broader conversation on.

Otherwise this matches my recollection. Thank you for the write up!