Flesh out and validate the permission flows

[jyasskin]

The most difficult part of this API is ensuring that users understand the impact of accepting the permission request. That leads to three thoughts:

1. The explainer would benefit from a clear explanation of what harm websites could do with this feature, if the permission request isn't good enough.

That explanation can be aimed at standards developers. There are probably two parts to the answer: Websites can discover that you visited one of the other sites that used this file. And if you provide a pure-query function, then websites can save a set of files and use the pattern of saved files to send messages. But you should ask around to see if other people can think of other harms. Double-check which harms from https://hillbrad.github.io/sri-addressable-caching/sri-addressable-caching.html are possible for this blob-only use case.

2. There needs to be some check that a permission request exists that adequately conveys the harm to users. That means UX research is on your critical path. We wouldn't specify that UAs have to use exactly that form of request, but I (controversially) think that the spec should show the UXR-validated dialog as an example.

3. A request of the form "This website is downloading and offers to share it with other sites that want the same resource. Don't allow this if you want your use of this site to stay private. [Share it] [Only use it on this site]", for which the website can't tell what the user answered, is probably better than one where the site might break if the user gives the wrong answer. Similarly, for files that are already present, you could use something like "This website would like to use , which you already downloaded while using <othersite.com>. Can it re-use the download? [Yes] [Download it again to preserve my privacy]" These require that the requestFileHandles() function accept and match URLs in addition to hashes.