[webkit-dev] Notifications API

Tue May 26 21:49:04 PDT 2009

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/20090526/fa1d88dd/attachment.html>