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!