- From: Arun Ranganathan <arun@mozilla.com>
- Date: Wed, 21 May 2014 11:44:12 -0400
- To: glenn Maynard <glenn@zewt.org>
- Cc: Anne van Kesteren <annevk@annevk.nl>, Jonas Sicking <jonas@sicking.cc>, Adam Barth <w3c@adambarth.com>, Joel Weinberger <jww@google.com>, Boris Zbarsky <bzbarsky@mit.edu>, Web Applications Working Group WG <public-webapps@w3.org>
On May 21, 2014, at 10:47 AM, Glenn Maynard <glenn@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*
Received on Wednesday, 21 May 2014 15:44:42 UTC