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 <[email protected]> wrote: > > > On Tue, May 26, 2009 at 9:18 PM, David Levin <[email protected]> wrote: > >> >> >> On Tue, May 26, 2009 at 8:57 PM, Sam Weinig <[email protected]> wrote: >> >>> >>> >>> On Tue, May 26, 2009 at 5:04 PM, Drew Wilson <[email protected]>wrote: >>> >>>> >>>> >>>> On Tue, May 26, 2009 at 4:43 PM, Sam Weinig <[email protected]>wrote: >>>> >>>>> >>>>> >>>>> On Tue, May 26, 2009 at 4:20 PM, Drew Wilson <[email protected]>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 >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
