Re: Proposal for a Permissions API

2015-03-22 Thread Jeffrey Yasskin
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 pya...@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 jyass...@google.com wrote:

 On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri mou...@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





[XHR] UTF-16 - do content sniffing or not?

2015-03-22 Thread Hallvord Reiar Michaelsen Steen
Hi,
I've just added a test loading UTF-16 data with XHR, and it exposes an
implementation difference that should probably be discussed:

Given a server which sends UTF-16 data with a UTF-16 BOM but does *not*
send charset=UTF-16 in the Content-Type header - should the browser
detect the encoding, or just assume UTF-8 and return mojibake-ish data?

Per my test, Chrome detects the UTF-16 encoding while Gecko doesn't. I
think the spec currently says one should assume UTF-8 encoding in this
scenario. Are WebKit/Blink - developers OK with changing their
implementation?

(The test currently asserts detecting UTF-16 is correct, pending discussion
and clarification.)

-Hallvord


Re: Proposal for a Permissions API

2015-03-22 Thread Anders Rundgren

On 2015-03-21 22:47, Florian Bösch 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).

I agree with this. When skimming 
https://webbluetoothcg.github.io/web-bluetooth/use-cases.html
I particularly noted the following lines:

  3.2.1 The Bluetooth API must only expose those parts of the general Bluetooth
   protocol that present an acceptable risk of exploit

This may lead to:
- Crippled functionality
- User's being confronted with questions they don't understand the consequences 
of
  like http://www.sconnect.com/FAQ/#permissionrequest

Although efforts making the Open Web more competitive with the Native/Platform 
level are
motivated, I'm personally unconvinced that DUPLICATION is the right approach 
for system-
level interfaces.

COMBINING these layers seems like a simpler way ahead.  FWIW, I have sort of 
launched
such a scheme: http://www.ietf.org/mail-archive/web/jose/current/msg05005.html

What's the difference you may [rightfully] wonder?  Well, the short version is 
that it enables
any numbers of specific (single-purpose) interfaces that does exactly what you 
want and at
worst needing a privacy prompt.  These interfaces can also be defined (and 
implemented!)
by different communities which allows for quicker turnaround which is quite 
important if
you are set to compete with the App world.

Anders






On Wed, Oct 1, 2014 at 7:34 PM, Jeffrey Yasskin jyass...@google.com 
mailto:jyass...@google.com wrote:

On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri mou...@lamouri.fr 
mailto:mou...@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







Re: Proposal for a Permissions API

2015-03-22 Thread Florian Bösch
On Sat, Mar 21, 2015 at 10:47 PM, Florian Bösch pya...@gmail.com wrote:

 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/


It's also likely the case that (as others have suggested) if you're doing a
double security poll (or even a tripple one) ala:

   1. Hey we need this permission to get started, do you want to grant it?
   2. Click here to make us request this permission from you, remember to
   click the next dialog on allow
   3. Actual permission dialog asking the permission.

Then the attention loss effect is probably knocked on N-fold.