Spec is not clear about blobs created in sandboxed iframes

[youennf]

A sandboxed srcrdoc iframe will have its origin as "null" so its origin will not be trustworthy but the iframe will be considered as secure context according https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy.

If that iframe creates a blob, the blob URL will be something like "blob://null/UUID".
Applying https://w3c.github.io/webappsec-secure-contexts/#is-url-trustworthy to "blob://null/UUID", the URL should be considered as "Not Trustworthy". Trying to load that URL as iframe or worker should for instance trigger mixed content checks.

https://jsfiddle.net/fjvteqo5/ shows a difference of behaviour.

1. Safari refuses to load blob URLs (iframe and worker) due to mixed content checks.
2. Chrome loads both blob URL, the worker is not secure context.
3. Firefox loads both blob URLs, the worker is secure context.

I am wondering what is behind the difference of behaviour between Safari and others.
Is it because blob://null/UUID in Safari is considered not trustworthy, while Chrome and Firefox are checking the context that created the blob?
I am also interested in hearing about Chrome/Firefox difference here.

[annevk]

That's an interesting case, there are several related issues here:

• Sort out when blob: URLs can be fetched / navigated FileAPI#135
• Surprising secure context inheritance behavior for opened windows whatwg/html#6369

Assuming we want to allow fetching the blob URLs (and I think the idea was that these would be considered same origin with the opaque origin they are created in), I think Firefox's behavior makes the most sense. If the top-level browsing context is a secure context, it doesn't really make sense that a subpart of it would then no longer be.

cc @letitz @fred-wang @mkruisselbrink @domenic

[jimmywarting]

I originally reported this blob reading problem to safari at https://bugs.webkit.org/show_bug.cgi?id=170075
...With the issue that a origin that created the blob in the first place isn't allow to read it's own blob's that it have created
...original simpler demo that works in other browser but safari: https://jsfiddle.net/bgh27rre/1/ (using the FileReader)

The root problem was that i was using xhr.responseType = 'blob' and later did something with it on the origin itself. It had absolutely nothing to do with sending/retrieving postMessages from another origin or read/write from the filesystem.

I think at least that the document that created the blob in the first place should be allow to read its own blobs that it have created?

I only used Blob since it can have a better memory handling.
Applying the "trustworthy" flag have no real advantages if i can instead use arrayBuffer and somehow use that instead. the only disadvantages is that everything have to be put in the memory instead and i would also have to use base64 urls instead of object urls. It's just nothing but annoying.

Should not the ObjectURL have the trustworthy flag instead to warn about mixed content warning?
feels like a blob is as much trustworthy as a ArrayBuffer is...

[annevk]

The issue is not about the blob object itself, but about the environment it creates. You cannot create an environment from a buffer.

[mkruisselbrink]

I agree that the intention is that blob URLs created in a opaque origin are same origin with the opaque origin they are created in. So yeah, agree that Firefox' behavior probably makes the most sense here.

[youennf]

It is nice to see we can converge in that area.
I am wondering how it would best be fixed in terms of spec.

We have environments that are secure context, but whose origin is opaque, thus "Not Trustworthy".
Should we introduce opaque origins that can actually be Trustworthy?

Or should we special case blob/filesystem URLs in https://w3c.github.io/webappsec-secure-contexts/#potentially-trustworthy-url to use the context URL and not the context origin?

[annevk]

For secure contexts we created https://html.spec.whatwg.org/#secure-contexts which solve some problems it had except it itself has a problem for about:blank.

Is the problem that we cannot change https://w3c.github.io/webappsec-mixed-content/#categorize-settings-object to talk about secure contexts as that would not help (regress, even) with HTTPS nested inside HTTP? (By the way, note that this uses responsible document @domenic.)

It does seem that for workers that could at least be changed to look at the owners of the worker in case of an opaque origin.

Fusing it into the opaque origin is an interesting thought, but a decent undertaking as well. It might be more feasible these days though as we have a better handle on when these origins are created/assigned. @antosart's https://github.com/antosart/policy-container-explained might also help us formalize this better. (At least the refactoring that will require will make this easier I think.)

[letitz]

I think one difficulty here is that the secure context bit of an environment is closely tied to its origin before sandboxing is applied, but there seems to be no good definition for that concept in the spec. What does the "creation URL" of a blob look like? That is what the current version in HTML bases decisions off of.

[annevk]

Good point. That is broken as well. 😟 We should just set these things at creation-time.

[letitz]

+1 to setting these at creation time. The problem then becomes that of plugging that setting logic into the spec for all kinds of policies - which the policy container can address.

[annevk]

And to be clear I think we need two bits, right?

• "secure scheme" (did this have a secure scheme or was created by something that had a secure scheme)
• "secure context" (secure scheme across the hierarchy)

E.g., if you have sandboxed HTTPS inside HTTP it would have secure scheme (and mixed content restrictions), but not secure context (no nice APIs).

[letitz]

That sounds correct. I'm no expert on mixed content though :)