- From: Eric U <ericu@google.com>
- Date: Mon, 6 May 2013 20:52:32 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Jonas Sicking <jonas@sicking.cc>, Arun Ranganathan <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Wed, May 1, 2013 at 5:16 PM, Glenn Maynard <glenn@zewt.org> wrote: > On Wed, May 1, 2013 at 7:01 PM, Eric U <ericu@google.com> wrote: >> >> Hmm...now 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. True. > 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. I'm not really sure what you're saying, here. If you want an URL to expire or otherwise be revoked, no, you can't use it multiple times after that. If you want it to work multiple times, don't revoke it or don't set oneTimeOnly.
Received on Tuesday, 7 May 2013 03:53:15 UTC