[whatwg] Installed Apps

[Jonas Sicking]

2009/7/30 Ian Fette (イアンフェッティ) <ifette at google.com>:
>> 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.
>
> It addresses some use cases (calendar, perhaps), but I would still like to
> be able to e.g. keep my email up to date. Do I need the "full power" /
> "fully general" solution? I don't know, perhaps the push mechanism can be
> structured in a way that it gets into my database or whatever storage
> mechanism I am using for offline data storage?

I agree, however I don't think the solution is to allow a background
webpage or something similar which has the full power of the web
platform, and all the naughty things available to it. Instead I think
it'd be great to have a protocol which allowed asynchronous updates to
a client-side resource (or set of resources). There's nothing that
would prevent this from happening over non-http protocols as well
(such as SMS).

/ Jonas