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@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
