Bypass blob URL partitioning after storage access granted

[recvfrom]

To be able to fetch blob URLs created using a StorageAccesssHandle's CreateObjectURL, we would need to specify that the same-partition check should be bypassed when obtaining the blob URL object

[recvfrom]

Working on this now

[recvfrom]

In general it seems that bypassing partitioning for Blob URL fetching once storage access aligns with how unpartitioned storage for many of the other storage APIs will be accomplished: update "obtain a storage key for non-storage purposes" to return a first-party storage key if Environment's "has storage access" boolean is true. The spec currently references this, but the whole effort is blocked because the spec Storage Key definition doesn't include more than origin, so "obtain a storage key for non-storage purposes" only ever returns first-party storage keys anyway (at least until whatwg/storage#144 or something similar lands).

One complication with this approach is that the current blob URL revocation behavior (see #35) is most easily spec'd by not factoring "has storage access" into "obtain a storage key for non-storage purposes" when determining whether either URL.revokeObjectURL or saa_handle.revokeObjectURL should revoke a given Blob URL. Some thoughts on how we could work around this:

• We could update "obtain a storage key for non-storage purposes" to take a boolean parameter that causes the "has storage access" check to be bypassed, and update "check for same-partition blob URL usage" to set that to false if it's being called for revocation
• Alternatively, we could update revokeObjectURL to create a copy of "current settings object" (I'm assuming this is an operation that makes sense), set the copy's "has storage access" boolean to false, and then pass that to "check for same-partition blob URL usage".

@arichiv WDYT?

[arichiv]

I might be misunderstanding, but I think the current behavior accomplishes what we want. The version on URL shouldn't be changing the source based on storage access, only the fetch implementation has to care.

You're touching on some deeper rot here that #36 is also concerned with, but right now we just sort of hand wave and say the handle is magical and it gets a different storage key and its existence doesn't impact other existing APIs besides document.cookie and fetch.

To be clear this should change, but it's not a unique issue and I don't think it needs to block you.

[recvfrom]

The Fetch spec's entry point into the Blob URL code is obtain a blob object which contains the partitioning check, so we shouldn't need to update the Fetch spec for this.

Thinking more about it, the potential fix is more complicated than I originally proposed - if we only update "obtain a storage key for non-storage purposes" to return a first-party storage key when "has storage access" is true, comparisons with the original third-party storage key would fail unexpectedly (in this case, a document with storage access wouldn't be able to fetch blob URLs created using URL.createObjectURL). So maybe instead we'd need to change the way storage key comparison takes this into account, so that when "has storage access" is true it does the check using a first-party storage key computed from the Environment in addition to just checking whether the storage keys are equal.

The point I was raising above regarding revocation is that if we do what's described in the paragraph above unconditionally, then saa_handle.revokeObjectURL would be able to revoke a URL.createObjectURL blob URL and vice versa (since the third-party context would have storage access and bypass partitioning checks).

[arichiv]

Ah, the spec was structured to assume the underlying service for blob would reject requests if the storage key it got when initializing didn't match. If that's not the case then yeah we probably need a bool to force only partitioned access.

I'm fine with whichever is less of a lift since the entire thing will need to be re-worked eventually anyway.