Re: revokeObjectURL behavior

On Wed, Nov 17, 2010 at 6: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).
>

This is what we currently assume. Thanks.

>
> Let me know what you think.
>
> / Jonas
>
>