Re: revokeObjectURL behavior

On Thu, Nov 18, 2010 at 2:04 PM, Michael Nordman <michaeln@google.com> wrote:
> On Tue, Nov 16, 2010 at 11:42 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>> Hi All,
>>
>> We have at length discussed what revokeObjectURL should be called, and
>> where it should live. However we haven't yet discussed how it should
>> behave.
>>
>> In particular, there is one edge case that I'm concerned about. Consider:
>>
>> myurl = window1.URL.createObjectURL(myblob);
>> window2.URL.revokeObjectURL(myurl);
>>
>> in this example window1 and window2 are separate, but same origin,
>> windows (for example window2 could be an iframe inside window1).
>>
>> The question is, should the call to revokeObjectURL succeed, do
>> nothing, or throw an exception. One important aspect here is that if
>> the two windows are not same origin, and the code in window2 simply
>> guesses a url to revoke, then we definitely don't want the revoke to
>> succeed. While implementations should take steps to make URLs
>> unguessable, it is good to have extra layers of security by not
>> allowing different origins to unregister each others URLs.
>>
>> Another concern I have is that silently doing nothing is bad for APIs
>> that are intended to free resources. It makes it very easy to create
>> the situation where a author think they are revoking a URL, but in
>> reality are not.
>>
>> I think for safety, I'm leaning towards saying that different
>> same-origin windows can unregister each others URLs. But if
>> revokeObjectURL is called with a string that is not a same-origin URL,
>> it does nothing (other than possibly warning in error consoles if the
>> UA so desires).
>
> Given the per-window semantics of these URLs, it seems a odd that a
> URL coined in one window is revocable via another window.  Is there a
> use-case in mind that would rely on being able to revoke thru any of
> the origin's windows?
>
> The other obvious choice is that a window only knows how to revoke a
> URL that it has explicitly coined which I think has clearer semantics.
> These semantics, along with silent error handling, match what is
> implemented in webcore right now (albeit with the methods bound to the
> window object for now).
>
> Jian... you said... "This is what we currently assume."
> Do you have changes in the works to alter the current semantics/impl
> in webcore? If so, what's motivating that change?

My thinking was that since this is a "free resources" API being as
permissive as possible will result in the fewest leaks.

Look at it this way. If a page on site A calls revokeObjectURL, it
probably does so in order to free up the resources that that url is
holding. Why would you want to ignore that call and still hold the
resources just because the resource was originally allocated in
another window on site A? It seems very likely to me that the result
will be that those resources are leaked (until the user leaves the
page). It seems much less likely that the author made the call in
error and is planning on using the resource later.

It's bad enough that we have to have a specific call to free
resources. I think we should make it as easy as possible for authors
to use the call, even if it's at the cost of additional implementation
complexity.

/ Jonas

Received on Thursday, 18 November 2010 22:18:11 UTC