- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 11 Jun 2010 11:18:24 -0700
- To: Adrian Bateman <adrianba@microsoft.com>
- Cc: "arun@mozilla.com" <arun@mozilla.com>, Jian Li <jianli@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
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