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