[webkit-dev] Notifications API

Wed May 27 11:51:34 PDT 2009

I think that makes sense for now as well.

I expect we'll get to this sort of generic permissions system in the future,
but for the time being I am adding to my current patch some methods:

  // internal methods implemented by the embedder
  int NotificationProvider::checkPermission(SecurityOrigin*);
  void NotificationProvider::requestPermission(SecurityOrigin*,
PermissionCallback);

  // JS API methods
  int Notifications.checkPermission()                 --> invokes
m_provider->checkPermission(my_origin);
  void Notifications.requestPermission(PermissionCallback)   --> likewise.
callback is invoked when the user (or user agent) makes a decision.

Additionally,
  Notifications.createNotification() will throw a SECURITY_ERR exception if
permission is not granted.

Sound good?  I think most of the code will easily migrate to a generic
system.

 -John

On Wed, May 27, 2009 at 11:44 AM, Sam Weinig <sam.weinig at gmail.com> wrote:

> I would prefer we limit the scope to notifications, since this is an
> experimental feature at the moment.  Perhaps something along the lines of
> window.notifications.requestTrust(), or window.notifications.requestUse() (I
> am not a huge fan of either of those function names, but you get the general
> idea).  We can always revisit this if this type of
> explicit privilege escalation becomes something other apis need as well.
> -Sam
>
>
> On Wed, May 27, 2009 at 9:22 AM, Drew Wilson <atwilson at google.com> wrote:
>
>> Sam, I think you are right here. I'm convinced that applications should be
>> specific about what permissions they are asking for.
>>
>> I also believe that from a UX standpoint, we will probably want to provide
>> the user with a single dialog that enumerates the permissions being granted,
>> although a given user-agent may want to do this differently. We certainly
>> want to enable both models.
>>
>> So I'd like to propose an API like the following (cribbed from the Android
>> permissions manifest):
>>
>> int getTrusted(permissionName)  - returns 0 if the application is
>> blocked/unsupported (user said "no" or user-agent does not support it), 1 if
>> it is untrusted (no permissions grant yet), 2 if it is trusted
>>
>> void requestTrust(permissionArray, callback)
>>
>> This provides a couple of important things:
>>
>> 1) granularity, so an application can specify exactly what permissions it
>> wants
>> 2) flexibility for the user agent - the application asks for a block of
>> permissions at once (for example, a given feature like background
>> notifications may require two permissions: persistent workers and
>> notifications). The user agent has the flexibility to decide whether to
>> display this as one dialog enumerating permissions, two separate dialogs, a
>> dialog which allows the user to pick and choose which permissions it wants
>> to grant, etc.
>>
>> What do you think?
>>
>> -atw
>>
>>
>> On Tue, May 26, 2009 at 9:49 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>>
>>>
>>>
>>> On Tue, May 26, 2009 at 9:18 PM, David Levin <levin at chromium.org> wrote:
>>>
>>>>
>>>>
>>>> On Tue, May 26, 2009 at 8:57 PM, Sam Weinig <sam.weinig at gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, May 26, 2009 at 5:04 PM, Drew Wilson <atwilson at google.com>wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, May 26, 2009 at 4:43 PM, Sam Weinig <sam.weinig at gmail.com>wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 26, 2009 at 4:20 PM, Drew Wilson <atwilson at google.com>wrote:
>>>>>>>
>>>>>>>> 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").
>>>>>>>
>>>>>>>
>>>>>>> It seems like a bad idea to give all or nothing trust, and not along
>>>>>>> the lines of how APIs have managed choices in the past (quotas are increased
>>>>>>> when the limit is hit).  I am not even sure how a UA would present such a
>>>>>>> choice to a user in a meaningful manner.  I think a workflow such as the one
>>>>>>> quoted above by Maciej is a good direction, that gives a user a better
>>>>>>> chance of understanding the choice they are making.
>>>>>>>
>>>>>>
>>>>>> I thought that maciej suggested the same thing we suggested - an
>>>>>> explicit javascript API to request permissions. In our case, we want to ask
>>>>>> for permissions in bulk up front, rather than peppering the user with
>>>>>> permissions on an ad-hoc basis - in your example (prompting for more quota
>>>>>> when the quota is hit) will break things like background sync in persistent
>>>>>> workers, as the user may not be around when that background sync occurs.
>>>>>>
>>>>>>
>>>>>
>>>>> It is similar, but I am concerned with how to present a dialog to a
>>>>> user that states that by clicking "grant" they are completely trusting you.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>> Can you please elaborate on this, perhaps with a concrete example.
>>>>>>>
>>>>>>
>>>>>> One example of a similar flow is Gmail Offline feature, where the user
>>>>>> clicks on a "Offline" link, which drives the user through some
>>>>>> app-controlled UI, culminating in a Gears permission-grant dialog. Here's
>>>>>> another example:
>>>>>>
>>>>>> Remember The Milk rolls out a new feature: desktop reminder
>>>>>> notifications. This is implemented by having a persistent worker which
>>>>>> tracks changes on the server, determines when it's appropriate to display a
>>>>>> reminder for a task, and displays a desktop notification.
>>>>>>
>>>>>> When a user logs into Remember The Milk, he sees a link: "New feature:
>>>>>> desktop reminders!". He clicks on this link, and is taken to an HTML page in
>>>>>> Remember The Milk which describes what the feature is and asks the user if
>>>>>> he wants to turn on these reminders. The application invokes getTrusted() to
>>>>>> see if the domain is already trusted - if it isn't, then the UI may include
>>>>>> some language to prepare the user for the upcoming permission grant dialog
>>>>>> by telling him what to expect.
>>>>>>
>>>>>> When the user clicks "yes, turn on this feature", the application
>>>>>> calls requestTrust() - this brings up the UserAgent-specific permission
>>>>>> grant dialog. When the user clicks the appropriate UI to grant this
>>>>>> permission, then the application has the ability to create persistent
>>>>>> workers and notifications (if we don't allow this kind of bulk permission
>>>>>> grant, then the user is subjected to multiple dialogs for each feature -
>>>>>> persistent workers and notifications - which is a crummy user experience).
>>>>>>
>>>>>
>>>>> I would argue it is much more confusing to a user to have to grant
>>>>> complete trust (for some undetermined list of things to trust a origin
>>>>> with).  Should that include geolocation data?  I don't really want Remember
>>>>> The Milk to know where I am, does that mean I can't have notifications?  How
>>>>> can a user make an informed decision?
>>>>>
>>>>
>>>> I'm not in the chrome ux discussion... but I'll add my 2 cents.
>>>>
>>>> If you think of the clients of webkit that expose it as a browser to
>>>> third parties.  Here's a few that come to mind.
>>>>
>>>>    - Safari on OSX
>>>>    - Dashboard on OSX
>>>>    - Safari on iPhone
>>>>    - The browser on Andriod
>>>>    - Google Chrome
>>>>
>>>> When I think of Andriod, I know that installing apps gives me a list of
>>>> permissions being requested.  I would expect that any web item that wanted
>>>> permissions would have to be similar on that platform.
>>>>
>>>> For iPhone, I don't know what the install looks like (sorry).
>>>>
>>>> For dashboard, it just asks if you want to install it.
>>>>
>>>> For chrome, it is tbd.
>>>>
>>>> It looks like there is a mix of models in this small set.  An internal
>>>> api which is granular (areNotificationsAllowed(securityOrigin)) can support
>>>> a blanket uber permission as well so it seems like that is the more flexible
>>>> model which would cover the needs of the many webkit hosts better.
>>>>
>>>
>>> Installation of an application is quite a different experience than
>>> clicking a button to grant an arbitrary webpage full permissions.  There is
>>> at level of user training to not install software from untrusted sources.
>>>  That same truth does not exist when it comes to clicking buttons pop'ed up
>>> by the browser (see unsigned certificate) and as such, I believe a much
>>> higher bar must be set when granting permission in this setting.
>>>
>>> -Sam
>>>
>>
>>
>
> _______________________________________________
> 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/20090527/11169261/attachment.html>