"Aaron Boodman (劉)" <[email protected]> wrote: > Every crx file is signed. The signature and public key are part of > the > zip file itself, just after the signature. The zip format allows > extra > data there. When you took apart those crx files, if you used 'unzip' > from the command line, you may have seen 'Ignoring xx bytes of extra > data...'. That was the public key and signature being discarded :).
Ooh. I was looking for traces of the signing mechanism in the unzipped data. Is there a reason why .crx reinvents zip file signing instead of using the mechanism that .jar and .xpi use? .wgt, ODF and OOXML also put the signature inside the zipped data. > >> Another one that we would like in Chrome is a path prefix for the > >> app. > >> This is to handle the case of applications like Google Reader > >> which > >> are on http://www.google.com/reader. > > > > How does giving permissions to a prefixed application interact with > > the origin-based security model? > > Poorly. Origin is baked so low into the platform, it is the true > boundary, and that can probably never be changed. In Chrome, we can > get close because we can enforce process isolation based on the path, > but it is an ongoing project to make that bulletproof that might > never > complete. > > However, I think it is still useful to know the paths an application > uses. One example of this is storage. > > It would be really nice to be able to show users storage used by > applications ("Google Docs", "Google Reader"). But this isn't > possible > since many apps are frequently served from the same origin. The best > we can currently do is "www.google.com". > > If we add paths to the mix, we can do this. Applications on the same > origin can circumvent it if they want, but why would they? SOP > already > guarantees that apps on the same origin are friendly and cooperate > with each other. That doesn't mean it isn't useful for the UA to know > which one is which. I have to wonder why Google needs the browser team to solve this instead of having the Reader team relocate their stuff to reader.google.com (like maps.google.com is located already). -- Henri Sivonen [email protected] http://hsivonen.iki.fi/
