[webkit-dev] Notifications API

[Drew Wilson]

To give the list some insight into the discussions we've had with the Chrome
UX folks:

1) We want to associate some set of enhanced permissions with a given origin
(e.g. https://mail.yahoo.com), and we want the user to be presented with a
single "do you want to grant permissions to https://mail.yahoo.com" dialog,
rather peppering the user with a bunch of individual permission dialogs for
each feature ("Yes, please allow mail.yahoo.com to use 100MB of local
storage", "Yes, allow mail.yahoo.com to display notifications", "Yes, allow
mail.yahoo.com to run in the background").
2) We want the timing of the permission grant UI to be under application
control (as part of some kind of application user flow). So just visiting
mail.yahoo.com would not suddenly popup an unexpected dialog - instead the
application would have some UI along the lines of "Turn on desktop
notifications" which would drive some app-specific UI flow, a part of which
would involve the permission grant.
3) To prevent applications from spamming the user with unwanted permission
dialogs, the user agent could only display permission grants in response to
user input (similar to how popup blocking works). The intent is to drive
application authors to build UI flow around the permission grant, and to
prevent things like third-party ad domains from doing "drive-by" permission
grants.
4) Once the user has denied the permission grant, we would not display them
again. The user agent can provide its own UI for managing domains with
permission grants, similar to how some applications have a popup blocking
whitelist/blacklist.
5) Long term, we probably want the application to specify what permissions
it wants and display those permissions as part of the permissions grant.
Some folks have even requested that users have the ability to
pick-and-choose which permissions they want to grant, but it's not clear
that this is feasible (giving an origin the ability to run in the
background, but then not giving it the ability to store data locally may not
make sense). We weren't positive what the correct way to specify the desired
permissions would be - array of identifier strings? Javascript object/hash
of configuration params? URL to some kind of application manifest?
6) From an application standpoint, they need the ability to test whether
they have permission (granted, ungranted, blocked) and the ability to
request permissions (throws an exception if the current permission state ==
blocked).

This patch is already fairly large, which is why we were planning to drive
the permissions API in a follow-on patch. Our current thinking was to have a
simple API as John describes (getTrusted() and requestTrust()). Since
there's not really any consensus around how to specify individual
permissions, the API would not take any parameters so it would reflect a
blanket "elevated trust" level for the application, with the intent of
evolving this API based on feedback from whatwg and internal developers.

-atw

On Tue, May 26, 2009 at 2:32 PM, John Gregg <johnnyg at google.com> wrote:

> On Tue, May 26, 2009 at 2:20 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> 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
>> JavaScript that requests permission for notifications, rather than 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.
>>
>> Having a JavaScript API to request permissions, along with plumbing
>> through the WebKit layer to allow a WebKit embedder to suitably prompt the
>> user, would address most of my concerns.
>>
>
> Yes, this would be necessary.  It's actually part of the spec API I
> originally proposed at
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html("readonly bool trusted" attribute and "void requestTrust()" method), and I
> was planning to submit in a follow-up patch.  But if you prefer it come in
> at the same time as the rest of the code, it can be done all at once.  Do
> you have any particular proposal for how to accomplish the "plumbing"?
> Part of the thinking is that it would be nice to avoid overwhelming users
> with lots of different permission UIs for individual native-app-like
> features that will come up (persistent workers (if and when) & local
> database quota come to mind).
>
> 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/20090526/71ced255/attachment.html>