[webkit-dev] Notifications API for workers

[John Gregg]

Thanks Maciej for the feedback.

We are definitely concerned with making this feature resistant to abuse,
since everyone agrees we don't want to create another class of annoying or
insecure pop-ups.  A good amount of thought has preceded the code, although
I probably didn't coordinate the distribution of the design very well.

In the design doc I did send to whatwg (
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html),
there are several options presented for how to prevent unwanted popups via
notifications, such as:

"it can be mitigated by separating applications into trust zones defined by
the user-agent, where trust is granted by the user. Desktop placement is
limited to trusted origins..."

So what I meant by "similar to popups" was just that background
notifications should only be allowed if the user has given permission in
advance, which has been my experience with popups (though maybe I got that
idea from non-WebKit browsers).

The design also reflects some thoughts into preventing phishing:

"It is recommended that HTML notification bubbles always contain a
recognizable browser frame, which displays the origin source of the bubble
and identifies HTTPS and other security elements in a standard way."

Regarding the issue of making the notifications stop, I think HTML
notifications should always have an options control in the frame which makes
this easy.

In terms of the implementation so far, the code provides a pass-through from
the worker script to a NotificationProvider interface in the WebKit client,
which can & should go through a security policy before showing anything to
the user.  I think that leaves things flexible for stopping abuse paths,
both the ones we already have thought of and anything that might occur
later.  If you have ideas to move specific enforcement rules into WebKit
itself, we should discuss that too.

 -John

On Sat, May 2, 2009 at 4:07 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> 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/20090504/1bc16824/attachment.html>