Re: Blob URLs | autoRevoke, defaults, and resolutions

On Wed, May 1, 2013 at 3:36 PM, Arun Ranganathan <arun@mozilla.com> wrote:
> At the recent TPAC for Working Groups held in San Jose, Adrian Bateman, Jonas Sicking and I spent some time taking a look at how to remedy what the spec. says today about Blob URLs, both from the perspective of default behavior and in terms of what "correct" autoRevoke behavior should be.  This email is to summarize those discussions.
>
> Blob URLs are used in different parts of the platform today, and are expected to work on the platform wherever URLs do.  This includes CSS, MediaStream and MediaSource use cases [1], along with use of 'src='.
>
> (Separate discussions about a "v2" of the File API spec, including use of a Futures-based model in lieu of the event model, took place, but submitting a LCWD with major interoperability amongst all browsers is a good goal for this draft.)
>
> Here's a summary of the Blob URL issues:
>
> 1. There's the relatively easy question of defaults.  While the spec says that URL.createObjectURL should create a Blob URL which has autoRevoke: true by default [2], there isn't any implementation that supports this, whether that's IE's oneTimeOnly behavior (which is related but different), or Firefox's autoRevoke implementation.  Chrome doesn't touch this yet :)
>
> The spec. will roll back the default from "true" to "false".  At least this matches what implementations do; there's been resistance to changing the default due to shipping applications relying on autoRevoke being false by default, or at least implementor reluctance [1].

Sounds good.  Let's just be consistent.

> Switching the default to "false" would enable IE, Chrome, andFirefox to have interoperability with URL.createObjectURL(blobArg), though such a default places burdens on web developers to couple create* calls with revoke* calls to not leak Blobs.  Jonas proposes a separate method, URL.createAutoRevokeObjectURL, which creates an autoRevoke URL.  I'm lukewarm on that :-\

I'd support a new method with a different default, if we could figure
out a reasonable thing for that new method to do.

> 2. Regardless of the default, there's the hard question of what to do with Blob URL revocation.  Glenn / zewt points out that this applies, though perhaps less dramatically, to *manually* revoked Blob URLs, and provides some test cases [3].
>
> Options are:
>
> 2a. To meticulously special-case Blob URLs, per Bug 17765 [4].  This calls for a synchronous step attached to wherever URLs are used to "peg" Blob URL data at fetch, so that the chance of a concurrent revocation doesn't cause things to behave unpredictably.  Firefox does a variation of this with keeping channels open, but solving this bug interoperably is going to be very hard, and has to be done in different places across the platform.  And even within CSS.  This is hard to move forward with.

Hard.

> 2b.To adopt an 80-20 rule, and only specify what happens for some cases that seem common, but expressly disallow other cases.  This might be a more muted version of Bug 17765, especially if it can't be done within fetch [5].

Ugly.

> This could mean that the "blob" clause for "basic fetch"[5] only defines some cases where a synchronous fetch can be run (TBD) but expressly disallows others where synchronous fetching is not feasible.  This would limit the use of Blob URLs pretty drastically, but might be the only solution.  For instance, asynchronous calls accompanying <embed>, "defer" etc. might have to be expressly disallowed.  It would be great if we do this in fetch [5] :-)

Just to be clear, this would limit the use of *autoRevoke* Blob URLs,
not all Blob URLs, yes?

> Essentially, this might be to "do what Firefox does" but document what "dereference" means [6], and be clear about what might break.  Most implementors acknowledge that use of Blob URLs simply won't work in some cases (e.g. CSS cases, etc.).  We should formalize that; it would involve listing what works explicitly.  Anne?
>
> 2c. Re-use oneTimeOnly as in IE's behavior for autoRevoke (but call it autoRevoke).  But we jettisoned this for race conditions e.g.
>
> // This is in IE only
>
> img2.src = URL.createObjectURL(fileBlob, {oneTimeOnly: true});
>
> // race now! then fail in IE only
> img1.src = img2.src;
>
> will fail in IE with oneTimeOnly.  It appears to fail reliably, but again, "dereference URL" may not be interoperable here.  This is probably not what we should do, but it was worth listing, since it carries the brute force of a shipping implementation, and shows how some % of the market has actively solved this problem :)

I'm not really sure this is so bad.  I know it's the case I brought
up, and I must admit that I disliked the "oneTimeOnly" when I first
heard about it, but all other proposals [including not having
automatic revocation at all] now seem worse.  Here you've set
something to be oneTimeOnly and used it twice; if that fails in IE,
that's correct.  If it works some of the time in other browsers [after
they implement oneTimeOnly], that's not good, but you did pretty much
aim at your own foot.  Developers that actively try to do the right
thing will have consistent good results without extra code, at least.
I realize that img1.src = img2.src failing is odd, but as [IIRC]
Adrian pointed out, if it's an uncacheable image on a server that's
gone away, couldn't that already happen, depending on your network
stack implementation?

> 3. We can lift origin restrictions in v2 on Blob URL; currently, one shipping implementation (IE) actively relies on origin restrictions, but expressed willingness to phase this out.  Most use cases needing Blob data across origins can be met without needing Blob URLs to not be origin restricted.  Blob URLs must be unguessable for that to happen, and today, they aren't unguessable in some implementations.
>
> -- A*
>
>
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19594
> [2] http://dev.w3.org/2006/webapi/FileAPI/#creating-revoking
> [3] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0294.html
> [4] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17765
> [5] http://fetch.spec.whatwg.org/#concept-fetch
> [6] http://lists.w3.org/Archives/Public/public-webapps/2013AprJun/0292.html
>
>
>

Received on Wednesday, 1 May 2013 23:26:14 UTC