[whatwg] Installable web apps

[Aaron Boodman]

Hello Henri,

Thank you for the thoughtful mail. I really appreciate you taking the
time to understand the proposal.

On Wed, May 26, 2010 at 4:30 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> I don't think it's a given that everyone who is talking about "installable Web apps" is talking about HTTP plus cache, although I wish everyone were talking about that.
>
> Take a look at
> http://code.google.com/chrome/apps/docs/developers_guide.html
>
> There's a zip file with a .crx extension that contains an icon, a permission manifest and potentially the code of the app ("Building a serverless app"). When the .crx file contains the code of the app, a .crx file is essentially like a .wgt file (which is what Opera has been pushing and already has a catalog site http://widgets.opera.com/ ) except with the manifest XML exorcised and replaced with JSON.

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.

> I think neither .wgt nor serverless .crx apps are Web apps. I think they are local apps built with Web technologies. I think an essential part of an app being a *Web* app is that you navigate in your Web browser to a URL pointing to somewhere out there *on the Web* and the application UI loads into your browser from out there.
>
> Now, "somewhere out there" may not be reachable at all times. However, I think stuffing the app into a zip file is an un-Webby way of making an app available offline. I think the Webby way is reading the files of the app from cache when offline but automatically refreshing the client-side files of the app to the latest versions by retrieving them from the server when connectivity works. Thus, I think offline availability should be based on the HTML5 app cache--not on installed zip files.

I completely agree that app cache is a more "webby" way of making apps
available offline than packaging. In particular, app cache preserves
the ability to deep-link into an application, which is an important
characteristic of the web.

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.

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

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

> To work with the security model of the Web, an application bookmark should probably be considered to bookmark and origin as opposed to bookmarking just one URL. I think having an application bookmark should have the following effects by default:
>
>  1) The application bookmark should be displayed to the user in a distinct way compared to regular bookmarks (regular bookmarks are semi-obsolete anyway).
>
>  2) Restrictions on resource usage should be very relaxed or entirely removed for an origin that has an application bookmark. That is, the app should be able to consume a lot of local storage space. Rationale: If the user is using an app enough to make an app bookmark for it, the user probably considers the app at least semi-non-hostile and prefers to let the app to be able to do its thing at least in ways that don't involve relaxing privacy.
>
>  3) Restrictions on the app leaving evidence of its use on the client computer should be lifted. That is, the app should be able to read and write long-lived first-party cookies and "supercookies" (databases) and should be able to use the HTML5 app cache.  Rationale: The application bookmark itself is already evidence that the user is using a given app, so hiding further evidence is pointless.
>
>  4) Restrictions on the app causing re-identification of the user to its host should be lifted when a URL whose origin has an application bookmark is loaded to a top-level browsing context. Rationale: Web apps very commonly need some kind of way of identifying the user on repeat access would soon re-identify him/herself to the site anyway. This is so common that it would be bad to have to grant this permission for every app. However, it does not follow that if a user has a google.com application bookmark that the user wants to enable google.com ad or analytics frames on other sites have unlimited cookie or "supercookie" access.
>
>  5) Resources cached using the HTML5 app cache by an origin that has an application bookmark should not be implicitly evicted. Rationale: When a user has created an application bookmark, the level of confidence that the app continues to be available offline should be very, very high.
>
>  6) Resources cached by the HTTP caching mechanism and belonging to an origin that has an application bookmark should be prioritized for keeping when the HTTP cache needs to evict something. Rationale: Preferential performance and offline availability for origins that are "installed".
>
>  7) Restrictions on the use of annoying features such as window.open() and notifications should be lifted for origins that have application bookmarks. Rationale: If the user chooses to use an app heavily enough to create an app bookmark, it's more likely that the user wants to give more UI control to the app than the user would give to a random site and having to explicitly permit e.g. notifications would itself be a usability annoyance.
>
> However, I think the creation of an application bookmark shouldn't implicitly expose otherwise private data to the site. That is, I think creating an application bookmark should by default still have privacy properties of a traditional bookmark plus login as far as data exposure to the site's direction goes. It might still be useful to be able to grant additional permissions at the time of creating the application bookmark as opposed to granting permissions one by one when the app tries to use features like geolocation. However, if the permissions can be remembered permanently by origin, I think it not absolutely critical to be able to pre-grant the permissions considering that implicitly allowing local storage already takes care of the most obvious thing many apps would want up front.

I agree with all of this. We were thinking in the same direction.

> 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
- 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)
- Any permissions

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.

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?

> So what does all this leave to a Web "app store" if there's no .crx file for a store to host? Not much--intentionally. I think the main problem a Web "app store" should solve is discovery. But once the user and the app provider have discovered each other, it's probably not healthy for an open Web for a storefront to have be a third wheel in the relationship forever. Maybe the only technical change to discovery would be having a mechanism for permitting an authorized app store to invoke the application bookmark UI without requiring the user to navigate from the store to the app and then invoke the UI there.

I think this is the exact role the Chrome web store is planning to
play, along with continual payment authorization. But I'd rather focus
this discussion on the client bits if that is OK.

- a