[webkit-dev] Notifications API

Wed May 27 11:44:43 PDT 2009

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.comto 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090527/a2d1204c/attachment.html>