[whatwg] Installable web apps

Henri Sivonen hsivonen at iki.fi
Tue Jun 8 04:17:41 PDT 2010

"Aaron Boodman (劉)" <aa at google.com> 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
hsivonen at iki.fi

More information about the whatwg mailing list