[whatwg] Installable web apps

[Henri Sivonen]

On May 26, 2010, at 20:10, Aaron Boodman wrote:

> This isn't really the point of this mail, but I just want to point out
> that there are more differences between wgt and crx than the format of
> the manifest file. The most important is that the identify of a crx
> file is a public key, and all crx files are self-signed by their key.
> This makes a crx file's identity unforgeable.

.wgt supports signing, too, but as with Sun .jar or Mozilla .xpi the signing proves that the .wgt came from the entity that the private key belongs to as certified by PKI--as opposed to proving without PKI that it came from the same source as the previous version of the .wgt.

After googling around a bit, I was unable to find a signed .crx file for analysis. (I took apart 3 .crx files and gave up.) Is the signing mechanism documented somewhere? .wgt reinvents the .jar signing wheel by the basic idea of .jar signing with XML Signatures.

(Note that I am not in any way implying that PKI were better. If Google can actually get extension authors to sign their extensions on average and proving that extension updates came from the same source as the previous version, that's a pretty big win over the Firefox extension signing situation. In principle, Firefox extensions can be signed to the stronger level of proving who signed them as opposed to proving just "same as before", but in practice, virtually no one--not even Mozilla Labs--signs Firefox extensions, so it doesn't help much that the level of proof would be stronger if signed.)

> The source of our support for packaged applications is that we have
> gotten a lot of feedback from developers that find packages a very
> convenient way to develop applications that work offline. I think the
> reason is that packages are conceptually much simpler than app caches.
> That said, I think this is mainly a lack of good tool support for app
> cache and good documentation, and I think it can eventually be
> overcome.

I see.

> For now, I would like to focus on live web apps, not packaged local apps.

Great.

>> I think it follows that to install a Web app, you navigate to its URL and bookmark it. There is no need to have an icon in a zip file for this: HTML5 already provides <link rel=icon sizes=... that the app can use to declare its icon, which can be pinned to cache upon bookmarking. So far, nothing new to design.
>> 
>> A plain bookmark doesn't elevate the bookmarked app sufficiently to be special in the system app switcher (like Prism) or inside the tab system of the browser (like Firefox 4 application tabs). A plain bookmark also doesn't pre-grant any permissions or ensure that the app stays in the cache.
>> 
>> I think the Webby step to take from here is to introduce the concept of application bookmarks (still without zip files). To "install" a Web application, the user would navigate to the app's URL and create an application bookmark.
> 
> For Chrome this isn't the UX we want. We want users to click a link in
> the content area and be presented with an install dialog. We think
> that going to something in the browser to "applicationify" a web app
> is too indirect and that many users will not get it.
> 
> That said, I think there is room to support multiple models of
> installation (or bookmarking, or whatever you want to call it),
> though.

Why don't you want the UX of the applicatinification process starting from browser chrome? Screen real estate reasons? Expectation or research showing that users don't understand the difference anyway?

Don't you need an annoying "This site is trying to applicationify itself. Allow or Deny?" piece of UI if the site can start the process?

>> If it's still deemed useful to be able to pre-grant permissions, I think the app should, again instead of installed zip files, use <link rel=something> to point to a manifest that shows what the apps wishes to be pre-granted. When the features to be granted have obvious JavaScript entry points from the window object (e.g. navigator.geolocation), the JavaScript names of those entry points should be used to identify the features in the manifest in order to avoid having to standardize separate permission names.
> 
> We have a growing set of metadata you're trying to <link> to:
> 
> - Icons

Mobile Safari and, AFAIK, the default Android browser already use use <link rel=apple-touch-icon> for this, so it seems to me the <link> cat is already out of the bag.

> - Application name (you didn't mention this, but I think it is nice to
> have distinct from the <title>, which is often overloaded with status
> information)

As Lachy mentioned, there's already in-document syntax for this:
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta-application-name

I'm not aware of anyone implementing it, though.

> 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?

> Every URL in an application will have to <link> to this same
> information. It seems like it would be better to just <link> to a
> separate resource that contains the information.
> 
> To me, this all leads to the following proposal:
> 
> <html>
> <head>
> <!-- for UAs that want a button in the browser chrome to appify -->
> <link rel="application-description" href="myapp.json">
> </head>
> <body>
> <!-- for UAs that want a button in the Chrome to appify -->
> <button onclick="navigator.installApplication()">install</button>
> </body>
> </html>
> 
> // myapp.json
> {
>  "name": "My Application",
>  "icons": ...,
>  "urls": [
>    "reader/"
>  ],
>  "permissions": [
>    ...
>  ]
> }
> 
> WDYT?

Makes sense to me (if you add sniffing for navigator.installApplication before showing a button that calls it), although I doubt you'll be able to avoid repeating a <link> to the icon anyway.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/