[webkit-dev] Notifications API

Wed May 27 09:22:02 PDT 2009

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/3153afb1/attachment.html>