Re: revokeObjectURL behavior

On Thu, Nov 18, 2010 at 2:17 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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

Got it. I can appreciate that.

Received on Thursday, 18 November 2010 22:51:37 UTC