[webkit-dev] Notifications API for workers

[Maciej Stachowiak]

I'm pretty concerned about the security/spamming implications of  
notifications from Workers. A lot of thought has been put into how to  
make them a good feature for thoughtful, competent Web developers like  
those at Google. But it seems to me that not as much thought has been  
put into making the feature resistant to abuse.

A few specific concerns:

1) Notifications may appear to the user to come from the Web page they  
are currently looking at, even if the Worker issuing them was created  
by a different originating page.

2) In the case of a SharedWorker, there may not even be an originating  
page with which to assiciate the notification, and it may not be clear  
to the user how to make notifications stop.

3) It appears that Notifications can be used for unwelcome advertising  
spam, much as pop-up windows before the advent of browser pop-up  
blocking.


On Apr 30, 2009, at 2:05 PM, John Gregg wrote:

> Hi WebKit,
>
> I'm working on a Notifications API for Web Workers, with the idea  
> that a user agent could receive these from script and route them in  
> a platform-appropriate & user-configurable way (desktop HTML toasts,  
> Growl calls, status bar on mobile browsers, etc.).  Permission  
> controls would be similar to popups.

I don't see how that's possible. The default policy used by many  
WebKit clients (including Safari) is that popups are only allowed in  
response to explicit user actions, such as clicking a link. But no  
code running in a Worker is in response to a user action. In addition,  
as I understand it, the whole point of Notifications is that they are  
in response to background events, *not* in response to user actions.

>
> I have a prototype working in Chromium but I need some advice as to  
> how I might get the JS API checked in. I opened a bugzilla item  
> here: https://bugs.webkit.org/show_bug.cgi?id=25463, which links to  
> the design doc I'm using and has a rough draft of the patch I'm  
> proposing.
>
> I got some feedback there already, so I thought I would reach out  
> for more advice.  Basically it amounts to adding to  
> WorkerContext.idl an attribute WorkerContext.notifications, which  
> notifications object contains methods like createNotification(URL or  
> text+icon).  Because of the proposed idea of dynamic routing, I'm  
> inclined not to roll it in to window.open() until we get more  
> experience building apps on it and decide that makes sense.
>
> Since this is experimental, it's already behind a compile time flag,  
> but I would be happy to do more to make it further protected (like  
> calling it WorkerContext.chromiumNotifications to indicate it's  
> currently a Chromium experiment).  Any other advice on how to proceed?

I think we should have a clear design for how this feature will resist  
abuse by malware before landing it in the WebKit tree. And if we can't  
find a solid design for that, then we shouldn't implement it. While  
many of us working on WebKit are greatly interested in extending the  
capabilities of Web applications, we have to recognize that it's  
important to proceed carefully and think through how a feature may be  
abused. In some cases, such as read-write access to the filesystem,  
there might not be any practical way to make it safe. In other cases,  
restricting the scope of the feature appropriately may make it safe  
enough. But I think it's too risky to implement first and figure out  
the security implications later.

Regards,
Maciej


>
> Thanks!
>  -John
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090502/0d3b2326/attachment.html>