- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 7 Aug 2009 15:07:23 -0700
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
Received on Friday, 7 August 2009 15:07:23 UTC