Re: [w3c/FileAPI] "Null"ing out the Origin of a BLOB (#74)

This came up in conversation again today with some folks on Google's security team who are reviewing some of our products that stuff not-entirely-trustworthy data into blobs. We've come up with some workarounds (like creating the blob inside a sandbox srcdoc iframe), but I think we'd happily use a built-in mechanism if we can agree on something reasonable.

A specific solution to the narrow problem of moving a blob to an opaque origin could certainly be addressed as @hfhchan suggests, by adding an attribute to the `blob` object, and then adjusting the https://w3c.github.io/FileAPI/#unicodeBlobURL algorithm to serialize the origin as `null` if the attribute's value is set. (I'm not enthusiastic about allowing developers to pick an origin, `document.domain` style. Let's avoid that unless we have a very good reason not to.):

```
var b = new Blob( [ "<!-- some HTML goes here -->" ], { type: "text/html" } );
b.opaqueOriginOrSomeBetterName = true;
var u = URL.createObjectURL(b);
// u == "blob:null/uuid-uuid-uuid-uuid"
```

An alternative might add an `opaque` property to the `BlobPropertyBag` used when creating the blob:

```
var b = new Blob( [ "<!-- some HTML goes here -->" ], { type: "text/html", opaque: true } );
var u = URL.createObjectURL(b);
// u == "blob:null/uuid-uuid-uuid-uuid"
```

I guess we could also tack it onto `createObjectURL` (e.g. `URL.createObjectURL(b, { opaque: true })`), but if there are plans to migrate away from URL references to blobs (what's the alternative?), then this wouldn't be a good plan.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/issues/74#issuecomment-310048874