Re: Blob URLs | autoRevoke, defaults, and resolutions

On Wed, May 1, 2013 at 7:01 PM, Eric U <> wrote:

> Glenn points out another problem: if you /never/ load the
> image, for whatever reason, you can still leak it.  How likely is that
> in good code, though?  And is it worse than the current state in good
> or bad code?

I think it's much too easy for well-meaning developers to mess this up.
The example I gave is code that *does* use the URL, but the browser may or
may not actually do anything with it.  (I wouldn't even call that author
error--it's an interoperability failure.)  Also, the failures are both
expensive and subtle (eg. lots of big blobs being silently leaked to disk),
which is a pretty nasty failure mode.

Another problem is that APIs should be able to receive an API, then use it
multiple times.  For example, srcset can change the image being displayed
when the environment changes.  oneTimeOnly would be weird in that case.
For example, it would work when you load your page on a tablet, then work
again when your browser outputs the display to a TV and changes the srcset
image.  (The image was never used, so the URL is still valid.)  But then
when you go back to the tablet screen and reconfigure back to the original
configuration, it suddenly breaks, since the first URL was already used and
discarded.  The "blob capture" approach can be made to work with srcset, so
this would work reliably.

Glenn Maynard

Received on Thursday, 2 May 2013 00:16:37 UTC