[webkit-dev] Notifications API for workers

Sat May 2 18:24:16 PDT 2009

Thanks for the thoughtful response. We're also concerned about many of the
same issues you've brought up below, and we've engaged in a number of
discussions with the Chrome UX team and our internal Security folks to
determine how we can best expose this functionality to the user and prevent
misuse.

The specification linked by the bug only describes the security/UX aspects
at a high level - this is not because the issues aren't important, but
rather because it's expected that different user agents may have varying
policies/implementations so the specifics of a given implementation are
outside the bounds of the spec. Our goal is to produce an implementation in
Chrome which can be used to inform other user agent implementations (more on
this below).

More replies are inline below - John can provide more specifics, but I'll
try to give you a general idea of how we're planning to protect this feature
from misuse. We'd appreciate any feedback you have on our approach.

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.
>

Our intent is to make it clear from within the notification what the origin
of the notification is (essentially, each notification has a mini address
bar and can include similar cues to highlight verified sites). John, perhaps
you can send out a screenshot of an example notification to give an idea of
what we mean? One other idea we're considering is preventing keyboard input
into these notifications to prevent phishing attempts.

>
> 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.
>

We're hoping to address the "popup spam" issue through two methods:

1) User opt-in - users have to opt-in before a domain is allowed to use
notifications. This prevents some random site or ad provider from suddenly
throwing notifications up. This is similar to the Gears install flow, where
a domain needs to get explicit user permission before it is allowed to
access enhanced APIs.
2) User opt-out - users will have opt-out UI within the notification itself,
allowing them to easily undo mistaken permission grants.

>
>
> 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.
>

John can clarify what he meant to say here, but I believe he intended to
convey that permission controls would be similar to the whitelists
maintained by some popup blockers (e.g. "Always allow popups from
www.popupspam.com"?). Agreed that we can't whitelist notifications based on
user action, so it's not completely analogous to popups.

>
>
> 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.
>

We'd love to discuss the security and UX implications in more detail - we've
had quite a bit of internal discussion and feedback, and some direction from
the whatwg list as well. What do you think of the approach I've outlined so
far?

As I mentioned above, our intent is to produce an experimental
implementation in Chromium (disabled by default), then iterate on it based
on UX and developer feedback until it's deemed ready for external
consumption. We expect that having an experimental implementation can help
other browser developers explore the design issues around this feature and
ultimately drive its inclusion in the HTML5 spec.

Our goal is to share this work with the WebKit community, and it seemed like
the best way to do it is to include our work in WebKit from the start (hence
this patch). Our fear is that if we start down the path of writing a bunch
of chromium-only code, it will be difficult to create a shared codebase down
the road.

-atw

>
> Regards,
> Maciej
>
>
>
> Thanks!
>  -John
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
>
> _______________________________________________
> 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/430d81d9/attachment.html>