On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sicking <[email protected]> wrote: > On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman <[email protected]> > wrote: >> On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote: >>> On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan <[email protected]> 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
