On May 21, 2014, at 10:47 AM, Glenn Maynard <gl...@zewt.org> wrote: > Hmm. One factor that might change my mind on this: If I pass a blob URL, > revoking the URL appropriately becomes hard. Even if it gets implemented, > auto-revoke can't help with this. That brings back all of the problems with > non-auto-revoking blob URLs, and adds a new layer of complexity, since I have > to coordinate between the site creating the blob URL and everyone receiving > it to figure out when to revoke it. > > On the other hand, I can just post the blob itself. That avoids all of that > mess, and the other side can just create a blob URL from it itself if that's > what it needs. > > That suggests that it's not worth trying to make blob URLs more accessible > cross-origin. I can't think of any case where I'd rather pass a blob URL > instead of just posting the Blob itself.
I agree with this. Blobs themselves can be used in a cross-origin way, provided there’s caller-callee understanding (w.r.t. postMessage). It’s easy to work with Blob URLs in the context of the script origin of URL.create*, since then Blob URLs can be used within that origin as an additional convenience. Keeping Blob URL origin as a script origin concept rather than a UUID concept makes sense to me. Also, that’s how they’re already implemented. The only thing missing is a formalization of syntax that’s closer to what’s already implemented. — A*
