[whatwg] Installed Apps

[Maciej Stachowiak]

On Jul 27, 2009, at 11:50 AM, Michael Davidson wrote:

> Hello folks -
>
> I'm an engineer on the Gmail team. We've been working on a prototype
> with the Chrome team to make the Gmail experience better. We thought
> we'd throw out our ideas to the list to get some feedback.
>
> THE PROBLEM
>
> We would like to enable rich internet applications to achieve feature
> parity with desktop applications. I will use Gmail and Outlook as
> examples for stating the problems we hope to solve.

I already commented on the security risks of the proposed solution,  
but I'd also like to examine the use cases more closely. "Feature  
parity with desktop applications" is pretty open-ended, and it might  
be that the actual concrete use cases can be addressed with less  
general mechanisms.

> -- Slow startup: When a user navigates to mail.google.com, multiple
> server requests are required to render the page. The Javascript is
> cacheable, but personal data (e.g. the list of emails to show) is not.
> New releases of Gmail that require JS downloads are even slower to
> load.

Caching the code part of GMail, and making loading fast in the face of  
updates, seems like a problem that can be solved by the HTML5  
Application Cache. Maybe it would be more fruitful to study further  
improvements in startup speed once GMail has adopted AppCache.

> -- Native apps like Outlook can (and do) run background processes on
> the user's machine to make sure that data is always up-to-date.
> -- Notifications: Likewise, Outlook can notify users (via a background
> process) when new mail comes in even if it's not running.

I'm not sure it's justifiable to say these features are required for a  
native-like experience. The Mail application on Mac OS X only fetches  
new mail and gives you new mail notifications while it is actually  
running. Users who want to know about new mail right away keep the app  
open, and users who would like to free up resources quit it. It seems  
like GMail can already get rough parity with this experience.

That being said, I think there are valid use cases for out-of-band  
notifications, for example for calendar events or "status update" type  
applications such as Facebook or Twitter.

I'd like to explore whether we can accommodate this notification use  
case without bringing the full power of the Web platform to bear, and  
thereby opening up a lot of attack surface on the client. Here's one  
rough sketch of an idea:

* Notification Feeds *

Often, web applications would like to give users the option to  
subscribe to notifications that occur at specific times or in response  
to server-side events, and for the user to get these UI notifications  
without a prerequisite that the web app is open or that the browser is  
running. There may be a desire to do client-side computation as well,  
but often just the ability to give the user a notification solves the  
basic user interaction problem.

One possible way to address this kind of use case is to let users  
subscribe to a "feed" of notifications. This feed could use standard  
syndication formats, such as RSS or Atom. But instead of being  
displayed in a traditional feed reader, it's displayed in the form of  
transient notifications (along the lines of Growl on Mac OS X) which  
are posted for each new event. To allow some pre-scheduling of events,  
each item can have a date and won't be displayed until that date -  
this way a calendar can give you your feed of upcoming events and you  
can still get notifications when offline. In the case of something  
like email or Twitter, obviously there's no sensible way to get  
notifications when offline since they depend on unpredeictable server- 
side activity. There could even be a client-side API that lets a Web  
app schedule items on a subscribed notification feed from script, to  
enable scheduling calendar events offline. Each notification would  
have the option to unsubscribe from the notification feed, to reduce  
spam potential.

Notice that this opens up a lot less attack surface. The user has to  
actively opt in to subscribing to the notification feed, just as for  
an RSS feed. This makes it much less likely they end up with a  
subscription to a shady site. And the notifications are passive data  
items (probably no script should be allowed in a notification, if the  
format is HTML and not just plain text), so they open up a lot less  
security risk. Obviously this is less powerful than the ability to run  
arbitrary code in the background. But it could address a large chunk  
of the use cases with much less security risk.


I'd like us to think along these kinds of lines when expanding the web  
platform. Often there is a low-power alternative to fully general  
solutions, which addresses many of the same use cases. By proceeding  
in this manner, we can extend the power of the web platform without  
neutering its desirable security properties.


Regards,
Maciej