[webkit-dev] Notifications API
mjs at apple.com
Tue May 26 14:20:35 PDT 2009
On May 22, 2009, at 10:19 AM, John Gregg wrote:
> Sure. We have the following plan for how to handle opt-in:
> - Use of the feature by script, if permission isn't granted to the
> origin, should throw an exception, not present permissions UI. So
> your insistent porn site would have no effect on the user.
> - A dialog box asking for permission should only appear in response
> to a user gesture like a click. So in the normal case, an
> application will present a user with a link "New: Desktop Calendar
> Notifications available! Click here to setup." And that link will
> present a prompt from the user-agent "Do you trust calendar.com?
> The site wants to display notifications on your desktop. [Yes/No]"
> If the user says yes, script running under that origin will have
> permission to show desktop notifications.
To expose this flow, wouldn't you need a method in the API exposed to
actually posting a notification? I don't see such a method in the
submitted patch. It would not make sense for a link labeled "New:
Desktop Calendar Notifications available! Click here to setup" to
actually display a notification itself, I wouldn't think.
through the WebKit layer to allow a WebKit embedder to suitably prompt
the user, would address most of my concerns.
> - Permission should be removable through a menu which is accessible
> from the notification UI itself.
Seems like this part would indeed be outside WebKit.
> As proposed the permissions policy is somewhat external to WebKit,
> visible parts of the system including UI, permissions flow, and
> filtering by origin which will be in Chromium or another user agent.
I think it implies a requirement for API that's not in the patch.
> On Thu, May 21, 2009 at 11:39 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 21 May 2009, John Gregg wrote:
> > On the security question, a substantial amount of thought has gone
> > how to prevent unwanted popups (and in general how to control
> access to
> > HTML5 application features). We think user opt-in on an origin-
> basis is
> > the best policy and it's what we plan to do in Chromium; the WebKit
> > interfaces are structured so that the policy is up to the user
> agent via
> > a NotificationProvider interface.
> Could you elaborate on what you mean by "user opt-in"? A prompt or
> "installation" step seems like a poor user experience given that any
> could start asking for this, and we don't want users to click "yes" to
> make the message go away (consider a porn site that just does "while
> notifications are not allowed, try to notify").
> Ian Hickson U+1047E )
> \._.,--....,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _
> \ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev