Re: Updates to File API

On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman <adrianba@microsoft.com> wrote:
>> On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote:
>>> On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan <arun@mozilla.com> wrote:
>>> > On 6/2/10 5:06 PM, Jian Li wrote:
>>> >> In addition,
>>> >> we're thinking it will probably be a good practice to encode the security
>>> >> origin in the blob URL scheme, like blobdata:
>>> >> http://example.com/33c6401f-8779-4ea2-9a9b-1b725d6cd50b. This will make
>>> >> doing the security origin check easier when a page tries to access the
>>> >> blob
>>> >> url that is created in another process, under multi-process architecture.
>>> >
>>> > This is a good suggestion.  I particularly like the idea of encoding the
>>> > origin as part of the scheme.
>>>
>>> Though we want to avoid introducing the concept of nested schemes to
>>> the web. While mozilla already uses nested schemes (jar:http://...
>>> and  view-source:http://...) I know others, in particular Apple, have
>>> expressed a dislike for this in the past. And with good reason, it's
>>> not easy to implement and has been a source of numerous security bugs.
>>> That said, it's certainly possible.
>>
>> It's not clear to me the benefit of encoding the origin into the URL. Do we expect script to parse out the origin and use it? Even in a multi-process architecture there's presumably some central store of issued URLs which will need to store origin information as well as other things?
>
> The one advantage I can see is that putting the scheme into the URL
> allows the *implementation* to deduce the origin by simply looking at
> the URL-scheme. This avoids having to do a (potentially cross-process)
> lookup to get the origin.
>
> This could be useful for APIs which have to synchronously determine
> the origin of a given URL in order to throw an exception on an
> attempted cross-origin access. For example an XMLHttpRequest Level 1
> implementation needs to synchronously determine if it should make a
> call to .open(...) throw or not based on the origin of the passed in
> URL.
>
> However I'm not sure if this is a problem in practice or not. It's
> entierly possible that the web platform is littered with situations
> where you need to do synchronous communication with whichever thread
> the networking code runs on.
>
> Firefox is still in the process of going multi-process, so I'll defer
> to other browsers with more experience in this area.

Oh, and I should add that the implementation will of course still have
to check once a url is loaded that the origin in the url matches the
origin in whatever map is used to map urls to resources. I.e. if the
implementation has handed out a url like:

filedata:sheep.org/3699b4a0-e43e-4cec-b87b-82b6f83dd752

and script changes that to:

filedata:wolf.org/3699b4a0-e43e-4cec-b87b-82b6f83dd752

then attempting to load the latter url should result in a 404 or similar.

/ Jonas

Received on Friday, 11 June 2010 18:49:24 UTC