[whatwg] Installable web apps

[Henri Sivonen]

"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
http://hsivonen.iki.fi/