- From: Chaals McCathie Nevile <chaals@yandex-team.ru>
- Date: Tue, 12 Jul 2016 16:20:09 +0200
- To: public-device-apis@w3.org
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