Partition Blob URL fetches by Storage Key

[recvfrom]

Partition Blob URL fetches by Storage Key

This change updates the spec to partition Blob URL fetches by Storage Key. This change is part of broader changes discussed in w3c/FileAPI#153 (comment). Specifically, we will also:

• Partition Blob URL revocation by storage key - Partition Blob URL revocation by Storage Key w3c/FileAPI#201
• Enforce noopener for cross-top-level-site Blob URLs - (Spec changes for this will follow)

I considered incorporating the Storage Key checks into the "resolve a blob URL" algorithm instead, but it seemed that this would require an environment settings object to be available as part of https://url.spec.whatwg.org/#url-parsing, and I'm not sure whether that is the case / a change we want.

• At least two implementers are interested (and none opposed):
  • Firefox has already implemented this - Blob URL store partitioning w3c/FileAPI#153 (comment)
  • Safari has implemented partitioning Blob URL fetches by top-level origin and is considering partitioning them by a site-based Storage Key (Storage Key specifics TBD) - Blob URL store partitioning w3c/FileAPI#153 (comment)
• Tests are written and can be reviewed and commented upon at:
  • https://chromium-review.googlesource.com/c/chromium/src/+/5967596
• Implementation bugs are filed:
  • Chromium: https://crbug.com/40057646
  • Gecko: N/A
  • WebKit: N/A
  • Deno (not for CORS changes): N/A (it seems Deno does not partition storage or more generally implement the same-origin policy: https://docs.deno.com/runtime/reference/web_platform_apis/#spec-deviations)
• MDN issue is filed: Note that Blob URL usage is restricted due to storage partitioning mdn/content#36542
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[recvfrom]

@annevk would you be able to look at this PR as well? Or could you recommend another reviewer? Thank you!

[recvfrom]

@domenic would you mind taking a look at this when you have a chance?

[domenic]

This feels like it would work better after line 5028, instead of near this algorithm.

[recvfrom]

I was thinking this would make sense in the Infrastructure section like how the HTTP cache partitioning section and determine the HTTP cache partition algorithm are, but I've moved the algorithm under the Scheme fetch section now (and removed the note since it seems kinda out of place now. WDYT?

[domenic]

Non-editor LGTM

[annevk]

I'm a little worried about this approach as it means obtaining and revoking are maintained in independent specifications, but need to be kept synchronized to maintain the privacy and security boundary.

I think a more ideal setup would be that File API keeps the Blob objects out of reach (i.e., they're no longer directly accessible from a 'blob URL entry') and instead exposes some kind of "obtain" algorithm that we hand the 'blob URL entry' and current 'environment' (or maybe a storage key). That way File API can stay in charge of obtaining and revoking and most of the logic associated with that. And Fetch can mainly concern itself with translating a Blob into a response.

[domenic]

It looks like there aren't too many references to the blob URL entry's object... https://dontcallmedom.github.io/webdex/o.html#object%40%40blob%20URL%20entry%40dfn

[annevk]

Nice, the HTML find is legit and would also need to be updated I suspect. It would benefit from having the obtaining defined in File API so there's less need for duplication. Reporting API seems bogus: w3c/reporting#273. Web Authentication API seems similarly bogus: w3c/webauthn#2212.

[recvfrom]

Thanks for the feedback, I've updated my FileAPI PR [1] to expose an obtain algorithm as recommended here, and I've updated this PR to use it. One question I thought more about was what to do when the request doesn't have an associated environment... It seems like for Blob URLs we should allow navigations to bypass the partitioning checks, but otherwise we should just fail (this seems in line with the Chromium implementation at least). WDYT?

[1] https://github.com/w3c/FileAPI/pull/201/files

[recvfrom]

A draft PR for the HTML spec change is at: whatwg/html#10792

[annevk]

Thank you for reworking this so quickly!