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?

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.

Kind regards,

Andrey Logvinov

+7 (903) 600-56-97

alogvinov@yandex-team.ru

08.07.2016, 12:29, "Chaals McCathie Nevile" <chaals@yandex-team.ru>:

On Thu, 07 Jul 2016 16:24:41 +0200, Andrey Logvinov
<alogvinov@yandex-team.ru> wrote:

Can't a malicious app just wait for a while and if the promise has been
neither
resolved nor rejected, decide that the user has in fact denied the
request? Is
there any "normal" cause at all for the battery promise to remain in
pending
state for extended periods of time? If we are talking about a taxi app,
there is
plenty of time from the start until the price needs to be presented to
the user
to test for a probably intentional non-action on the promise.

That's true. But I think this still defeats the threat model, because you
know nothing about the battery state.

The specific behaviour was knowing that the user's battery is very low.
You could try to burn battery in order to achieve that, but you're
unlikely to keep customers that way - there are multiple taxi apps around…

cheers

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