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"). 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. 3) To prevent applications from spamming the user with unwanted permission dialogs, the user agent could only display permission grants in response to user input (similar to how popup blocking works). The intent is to drive application authors to build UI flow around the permission grant, and to prevent things like third-party ad domains from doing "drive-by" permission grants. 4) Once the user has denied the permission grant, we would not display them again. The user agent can provide its own UI for managing domains with permission grants, similar to how some applications have a popup blocking whitelist/blacklist. 5) Long term, we probably want the application to specify what permissions it wants and display those permissions as part of the permissions grant. Some folks have even requested that users have the ability to pick-and-choose which permissions they want to grant, but it's not clear that this is feasible (giving an origin the ability to run in the background, but then not giving it the ability to store data locally may not make sense). We weren't positive what the correct way to specify the desired permissions would be - array of identifier strings? Javascript object/hash of configuration params? URL to some kind of application manifest? 6) From an application standpoint, they need the ability to test whether they have permission (granted, ungranted, blocked) and the ability to request permissions (throws an exception if the current permission state == blocked). This patch is already fairly large, which is why we were planning to drive the permissions API in a follow-on patch. Our current thinking was to have a simple API as John describes (getTrusted() and requestTrust()). Since there's not really any consensus around how to specify individual permissions, the API would not take any parameters so it would reflect a blanket "elevated trust" level for the application, with the intent of evolving this API based on feedback from whatwg and internal developers. -atw On Tue, May 26, 2009 at 2:32 PM, John Gregg <[email protected]> wrote: > On Tue, May 26, 2009 at 2:20 PM, Maciej Stachowiak <[email protected]> wrote: > >> >> On May 22, 2009, at 10:19 AM, John Gregg wrote: >> >> Sure. We have the following plan for how to handle opt-in: >> - Use of the feature by script, if permission isn't granted to the >> origin, should throw an exception, not present permissions UI. So your >> insistent porn site would have no effect on the user. >> - A dialog box asking for permission should only appear in response to a >> user gesture like a click. So in the normal case, an application will >> present a user with a link "New: Desktop Calendar Notifications available! >> Click here to setup." And that link will present a prompt from the >> user-agent "Do you trust calendar.com? The site wants to display >> notifications on your desktop. [Yes/No]" If the user says yes, script >> running under that origin will have permission to show desktop >> notifications. >> >> >> To expose this flow, wouldn't you need a method in the API exposed to >> JavaScript that requests permission for notifications, rather than actually >> posting a notification? I don't see such a method in the submitted patch. It >> would not make sense for a link labeled "New: Desktop Calendar Notifications >> available! Click here to setup" to actually display a notification itself, >> I wouldn't think. >> >> Having a JavaScript API to request permissions, along with plumbing >> through the WebKit layer to allow a WebKit embedder to suitably prompt the >> user, would address most of my concerns. >> > > Yes, this would be necessary. It's actually part of the spec API I > originally proposed at > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html("readonly > bool trusted" attribute and "void requestTrust()" method), and I > was planning to submit in a follow-up patch. But if you prefer it come in > at the same time as the rest of the code, it can be done all at once. Do > you have any particular proposal for how to accomplish the "plumbing"? > Part of the thinking is that it would be nice to avoid overwhelming users > with lots of different permission UIs for individual native-app-like > features that will come up (persistent workers (if and when) & local > database quota come to mind). > > Thanks, > -John > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
