Re: Updates to File API

One benefit of using the encoded origin is to do the security origin check
in place, instead of resorting to a centralized authority, esp. under
multi-process architecture. Considering getting and checking the origin
before hitting the cache for the blob.url item.


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?
>
> Cheers,
>
> Adrian
>