- From: Jeffrey Yasskin <jyasskin@google.com>
- Date: Sun, 22 Mar 2015 15:03:37 -0700
- To: Florian Bösch <pyalot@gmail.com>
- Cc: Mounir Lamouri <mounir@lamouri.fr>, Dave Raggett <dsr@w3.org>, Webapps WG <public-webapps@w3.org>
The Permissions API moved to the WebAppSec WG, and there's an open call for comments on publishing its FPWD: https://lists.w3.org/Archives/Public/public-webappsec/2015Mar/0131.html. It would probably make more sense to discuss in that group. On Sat, Mar 21, 2015 at 2:47 PM, Florian Bösch <pyalot@gmail.com> wrote: > Time to revise this topic. Two data points: > > 1) Particularly with pointerlock (but also with other permission prompts > that sneak up on the user) I often get the complaint from users along the > lines of "I tried your stuff, but it didn't work." or "I tried your stuff, > but it asked me to do X, I don't think it works". > > 2) MRI scans show that user attention dramatically drops when presented with > a security prompt: > http://arstechnica.com/security/2015/03/mris-show-our-brains-shutting-down-when-we-see-security-prompts/ > > Permission/Security prompts are bad UX. Particularly the kind you need to > prompt the user with along the way. And within that, even worse are the ones > that pop up again and again (like the fullscreen popup). > > On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin <jyasskin@google.com> wrote: >> >> On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri <mounir@lamouri.fr> wrote: >> > On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote: >> >> I'm generally supportive of this direction. >> >> >> >> I'm not sure that that the PermissionStatus thing is needed. For >> >> example in order to support bluetooth is might be better to make the >> >> call look like: >> >> >> >> permissions.has("bluetooth", "fitbit").then(...); >> > >> > That's more Permission than PermissionStatus, right? >> > >> > What you proposed here would probably be something like that in WebIDL: >> > Promise<> has(PermissionName name, any options); >> > >> > But really, we could make that option bag be a dictionary because it >> > gives good context about what you are passing like what does "fitbit" >> > means here? Is that a black listed device or a white listed one? The one >> > you want to target? >> > >> > I agree that it might be unusual to have a required "name" than might >> > often be used alone but it makes the API way more javascript-y and self >> > explanatory. IMO, this call is nicer to read than the one you wrote >> > above: >> > permissions.has({ name: 'bluetooth', devices: 'fitbit' }); >> > because I understand what the call is trying to do. In addition, as you >> > pointed, it gives a lot of flexibility. >> >> Belatedly, I'd like to suggest a slightly different model. Instead of >> trying to stuff arbitrary queries into the permissions.has() call, >> maybe expose the current permissions as data, and let the application >> inspect them using custom code. This is likely to work better for >> Bluetooth, since we're planning to have pages request devices by the >> Services they expose, not their deviceIds, and a page may want to >> check for either an available device exposing some services, or that a >> device they've already opened hasn't been revoked. >> >> Getting permission revocation to update a UI correctly is also an >> interesting problem. You could expose an event on permission change, >> but given that templating frameworks are moving toward >> Object.observe() to update themselves in response to model object >> changes, that would require developers to write extra code to >> propagate the permission changes into their models. >> >> So what if navigator.permissions just _was_ a suitable model object? >> Make it, say, a Map from permission-name to an object defined by the >> permission's standard, and extend Map to expose enough synthetic >> change records that Object.observe(a_map) is useful. >> >> Jeffrey >> >
Received on Sunday, 22 March 2015 22:04:25 UTC