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.wei...@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 <atwil...@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.wei...@gmail.com> wrote: >> >>> >>> >>> On Tue, May 26, 2009 at 9:18 PM, David Levin <le...@chromium.org> wrote: >>> >>>> >>>> >>>> On Tue, May 26, 2009 at 8:57 PM, Sam Weinig <sam.wei...@gmail.com>wrote: >>>> >>>>> >>>>> >>>>> On Tue, May 26, 2009 at 5:04 PM, Drew Wilson <atwil...@google.com>wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, May 26, 2009 at 4:43 PM, Sam Weinig <sam.wei...@gmail.com>wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, May 26, 2009 at 4:20 PM, Drew Wilson <atwil...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev