'obtain a storage key' not currently suitable for non-storage APIs

[recvfrom]

The existing obtain a storage key algorithm indicates that:

3. If the user has disabled storage, then return failure.

It'd be helpful to use the storage key to partition non-storage APIs like BroadcastChannel, though, and we'd need to obtain a storage key even if storage is disabled in those cases. What's the best way to accommodate this?

[recvfrom]

Looks like the following may be problematic as well, since the existing BroadcastChannel spec language doesn't seem to prevent contexts with opaque origins from communicating:

2. If key is an opaque origin, then return failure.

[annevk]

Thank you for working on this! I think as per whatwg/html#3054 the opaque origin requirement can likely stay.

What do you think about making this algorithm delegate to something like "obtain a non-storage storage key" that does everything apart from the "has disabled storage" check?

[wanderview]

I think as per whatwg/html#3054 the opaque origin requirement can likely stay.

I think we would have to run a deprecation process to do that. Not sure what the numbers look like. Its probably fine, though.

[recvfrom]

What do you think about making this algorithm delegate to something like "obtain a non-storage storage key" that does everything apart from the "has disabled storage" check?

That works for me, although I wonder if "non-storage storage key" could be interpreted as being distinct from "storage key"? If we instead went with something like "obtain a storage key for non-storage purposes" it avoids this problem but is also more wordy.

Another option could be to rename the existing function to something like "obtain a storage key if enabled" and move everything but the "has disabled storage" check into an "obtain a storage key" algorithm (and have the former delegate to the latter).

Any preference?

[mkruisselbrink]

I think we would have to run a deprecation process to do that. Not sure what the numbers look like. Its probably fine, though.

At least in Chrome we never shipped opaque origin support for BroadcastChannel, if that is what this is about? Not sure I fully understand why we shouldn't support opaque origins with BroadcastChannel though, there would be very few contexts that share the same opaque origin anyway...

[annevk]

If we instead went with something like "obtain a storage key for non-storage purposes" it avoids this problem but is also more wordy.

Let's do that.

I don't have a strong opinion on the opaque origin question. I'm fine with keeping support for that. It seems to work reasonably in Firefox.