Re: [w3c/FileAPI] Partition Blob URL revocation by Storage Key (PR #201)

@recvfrom commented on this pull request.



> @@ -1512,15 +1512,29 @@ A [=blob URL store=] is a [=map=]
 where [=map/keys=] are [=valid URL strings=]
 and [=map/values=] are [=blob URL Entries=].
 
-A <dfn export>blob URL entry</dfn> consists of
-an <dfn export for="blob URL entry">object</dfn> (of type {{Blob}} or {{MediaSource}}),
-and an <dfn export for="blob URL entry">environment</dfn> (an [=environment settings object=]).
+A <dfn export>blob URL entry</dfn> consists of an <i>object</i> (of type {{Blob}} or

Ah that makes sense - thanks for pointing this out. Changed!

> @@ -1512,15 +1512,29 @@ A [=blob URL store=] is a [=map=]
 where [=map/keys=] are [=valid URL strings=]
 and [=map/values=] are [=blob URL Entries=].
 
-A <dfn export>blob URL entry</dfn> consists of
-an <dfn export for="blob URL entry">object</dfn> (of type {{Blob}} or {{MediaSource}}),
-and an <dfn export for="blob URL entry">environment</dfn> (an [=environment settings object=]).
+A <dfn export>blob URL entry</dfn> consists of an <i>object</i> (of type {{Blob}} or
+{{MediaSource}}), and an <dfn export for="blob URL entry">environment</dfn> (an
+[=environment settings object=]).
+
+Note: Specifications must use the [=obtain a blob object=] algorithm to access a

Oh I see, I didn't realize the "must" here would be interpreted the same way "MUST" would be in RFCs. That makes sense though. Thanks!

> @@ -1595,6 +1609,22 @@ as the serialization of the origin of the environment that created the blob URL,
 but for opaque origins the origin itself might be distinct. This difference isn't
 observable though, since a revoked blob URL can't be resolved/fetched anymore anyway.
 
+### Access restrictions on blob URLs ### {#partitioningOfBlobUrls}
+
+<a>Blob URLs</a> can only be fetched from environments where the [=storage key=] matches that of
+the environment where the <a>blob URL</a> was created. <a>blob URL</a> navigations are not subject
+to this restriction.
+
+<div algorithm="checkForSamePartitionBlobUrlUsage">
+To <dfn export id=blob-url-partition-check>check for same-partition blob URL usage</dfn> given a [=blob URL entry=] |blobUrlEntry| and an [=environment settings object=] |environment|:
+
+1. Let |blobStorageKey| be the result of [=obtaining a storage key for non-storage purposes=] with |blobUrlEntry|'s [=blob URL entry/environment=].
+1. Let |environmentStorageKey| be the result of [=obtaining a storage key for non-storage purposes=] with |environment|.
+1. If |blobStorageKey| is not [=storage key/equal=] to |environmentStorageKey|, then return false.
+1. Otherwise, return true.

Good catch, thanks

> @@ -1595,6 +1609,22 @@ as the serialization of the origin of the environment that created the blob URL,
 but for opaque origins the origin itself might be distinct. This difference isn't
 observable though, since a revoked blob URL can't be resolved/fetched anymore anyway.
 
+### Access restrictions on blob URLs ### {#partitioningOfBlobUrls}
+
+<a>Blob URLs</a> can only be fetched from environments where the [=storage key=] matches that of
+the environment where the <a>blob URL</a> was created. <a>blob URL</a> navigations are not subject

Good catch! Updated

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/pull/201#discussion_r1868717537
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/FileAPI/pull/201/review/2477286321@github.com>