- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 11 Jun 2010 11:11:53 -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 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. / Jonas
Received on Friday, 11 June 2010 18:12:48 UTC