- From: Marcos Caceres <marcos@marcosc.com>
- Date: Tue, 12 Jul 2016 03:36:30 -0400
- 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. 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. 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