search

mozilla / standards-positions

https://mozilla.github.io/standards-positions/
Mozilla Public License 2.0
650 stars 72 forks source link

Add a capability to create a Blob URL with a unique (non-opaque) origin #779

Open shhnjk opened 1 year ago

shhnjk commented 1 year ago

Request for Mozilla Position on an Emerging Web Specification

Other information

We have 2 proposals (listed above in the explainer URLs) to provide this capability. While we (Google) prefer allow-unique-origin option, we are happy to hear if you prefer the other one.

dveditz commented 1 year ago

It's tricky to have "a position" when there are two different proposals that do mostly the same thing.

I'm not keen on how either one is "spelled". crossOrigin means something else in other contexts, and for the other one you're not "allowing" the use of a unique origin but requiring it. I suppose that's a parallel construction with allow-same-origin (the "don't sandbox my sandbox" option) so it fits in to that extent.

Clearly it doesn't make sense to have have allow-same-origin and allow-unique-origin in the same sandbox. What happens when someone inevitably does that?

What happens when someone uses allow-unique-origin on a regular iframe sandbox or a CSP header sandbox? Does it work the same way or is it an error? it seems like it would be useful apart from Blobs.

I'm assuming from the name ("unique") that every such Blob a page creates would get a separate one. It might be useful, though, to be able to create multiple Blobs that shared a unique origin so they could do things that require same-origin or CORS.

dveditz commented 1 year ago

The ability to set arbitrary headers worries me, but i can't name any specific harm or attack off the top of my head.

shhnjk commented 1 year ago

Thanks Dan for the feedback! CC:

It's tricky to have "a position" when there are two different proposals that do mostly the same thing.

Right. I think we are requesting position for adding a capability to create a Blob URL with a unique (non-opaque) origin, and whether Mozilla think this is useful. And if so, which one would you prefer.

I'm not keen on how either one is "spelled". crossOrigin means something else in other contexts, and for the other one you're not "allowing" the use of a unique origin but requiring it. I suppose that's a parallel construction with allow-same-origin (the "don't sandbox my sandbox" option) so it fits in to that extent.

The crossOrigin naming came up in the File API issue as well, and we are happy to change it to something else (e.g. crossSite, unique, etc) 🙂

For allow-unique-origin, I also think we are happy to change it to something else, but it does match with allow-same-origin keyword.

Clearly it doesn't make sense to have have allow-same-origin and allow-unique-origin in the same sandbox. What happens when someone inevitably does that?

IMO, the only thing which makes sense to have both allow-same-origin and allow-unique-origin is that when developer knows that opaque origin will break an application, so it specify both in order to use unique origin for supported browsers, and use allow-same-origin for unsupported browsers. Therefore, I think supported browsers should ignore presence of allow-same-origin if allow-unique-origin is specified. CC: @ddworken

What happens when someone uses allow-unique-origin on a regular iframe sandbox or a CSP header sandbox? Does it work the same way or is it an error? it seems like it would be useful apart from Blobs.

We want to support outside of Blob URL as well, which will be useful for sandboxing marketing pages which needs to be hosted in sensitive origins for SEO/UX purposes, but does not neccesary have good security posture (see this for more details).

I'm assuming from the name ("unique") that every such Blob a page creates would get a separate one. It might be useful, though, to be able to create multiple Blobs that shared a unique origin so they could do things that require same-origin or CORS.

That's interesting, but I don't know such a use case on top of my head. WDYT @ddworken?

The ability to set arbitrary headers worries me, but i can't name any specific harm or attack off the top of my head.

Yes, same here. We just need CSP and Content-Disposition headers for security purposes, so we can change it to only allow those headers.