W3C home > Mailing lists > Public > public-device-apis@w3.org > July 2016

Re: Notes of June 30 teleconference

From: Marcos Caceres <marcos@marcosc.com>
Date: Tue, 12 Jul 2016 03:36:30 -0400
Message-ID: <CAAci2aAnyPxBNCsDMO+h3WBrhPsT8UK1u5WEEmrjc1gPHpUocQ@mail.gmail.com>
To: Andrey Logvinov <alogvinov@yandex-team.ru>
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
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.


> 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.

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).
Received on Tuesday, 12 July 2016 07:37:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:08 UTC