- From: Michael Nordman <michaeln@google.com>
- Date: Fri, 11 Jun 2010 12:04:17 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Adrian Bateman <adrianba@microsoft.com>, "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>
- Message-ID: <AANLkTilfpy4YGOjWOJhwnZzQmEbVNOVq_dD-TJ0GcbIn@mail.gmail.com>
Another advantage is that... blobdata:// http_responsible_party.org:80/3699b4a0-e43e-4cec-b87b-82b6f83dd752 ... makes it clear to the end user who the responsible party is when these urls are visible in the user interface. (location bar, tooltips, etc). 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. > > / Jonas > >
Received on Friday, 11 June 2010 19:04:49 UTC