Re: Notes of June 30 teleconference

On Tue, 12 Jul 2016 09:36:30 +0200, Marcos Caceres <marcos@marcosc.com>  
wrote:

> On July 8, 2016 at 9:50:53 PM, Andrey Logvinov  
> (alogvinov@yandex-team.ru) wrote:
>> Well, it looks like the spec doesn't actually suggest leaving the  
>> promise in the pending
>> state indefinitely.
>
> Good.
>
>> Rather, if the user decides to reject the permission, the UA should
>> resolve the promise and report some obfuscated values that have nothing  
>> to do with the real ones. Am I correct?
>
> That would be bad: that would cause it to behave differently to other
> APIs. We should not do that. We should just reject with a permission
> denied error.

Agreed. Unless the user specifically asked to send a false value - which  
should be an option somewhere in the "hard to use interface full of  
complex options" - its better to just say "no, the user isn't giving the  
information".

> The point is that a script should not be able to access the battery
> API without the UA first prompting for permission: If the UA provides
> a "fake battery" option when it prompts, then it should resolve with
> the fake battery instead.
>
> Under no circumstance should the UA  arbitrarily resolve with fake
> batteries when the permission is denied.
>
>> Still, from the user's perspective, it is not immediately clear whether  
>> she should allow the app to know the battery status so it can scale
>> down requests and processing etc to save power, or she shouldn't allow
>> the app to know the battery status so that the app won't be able to
>> take advantage of the low remaining battery time. Effectively, the user  
>> needs to be able to tell good apps from malicious ones.
>
> Like with any other permissions in the platform, the permission should
> just be revoked by the user (or the UA should revoke it for them,
> given a list of bad actors).

And like with any other permissions, we need to think hard about how and  
when we present this, and what support we can give the user to tell a good  
app from a potentially malicious one.

This mostly comes down to UI and accessibility. I don't think we really  
know the best way to do it yet, but we're learning…

cheers


-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
  chaals@yandex-team.ru - - - Find more at http://yandex.com

Received on Tuesday, 12 July 2016 14:20:41 UTC