- From: Anssi Kostiainen via GitHub <sysbot+gh@w3.org>
- Date: Fri, 13 Apr 2018 13:26:31 +0000
- To: public-device-apis-log@w3.org
@bzbarsky, thanks for taking a look at the Battery Status API spec! For the context, @bzbarsky is referring to the following steps in [`getBattery()`](https://w3c.github.io/battery/#dom-navigator-getbattery): >1. If the incumbent settings object is not a secure context, then reject this Navigator object's battery promise with a "SecurityError" DOMException and abort these steps. > >2. If the browsing context is not a top-level browsing context, then reject this Navigator object's battery promise with a "SecurityError" DOMException and abort these steps. ... which can abort the algorithm and as a consequence we never reach: >5. Return this Navigator object's battery promise and continue asynchronously. This was an intentional design decision to keep compatibility with existing web content written against the older version of the API that never rejected the promise. Such a design was chosen at that time to mitigate the following privacy concerns, quoting [notes of June 30 2016 teleconference](https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0005.html): >* BatteryManager is gated behind a promise allowing implementations to leave the promise in a pending state, for example, if no user consent is acquired. In particular, the promise never rejects, as to not allow implementations to know whether the user did not grant access or whether she just did not act on the request. It seems it'd be reasonable to return the rejected promise in steps 1 and 2 as suggested, since after all if those assertions are true no readouts would be exposed anyways. -- GitHub Notification of comment by anssiko Please view or discuss this issue at https://github.com/w3c/battery/issues/16#issuecomment-381134577 using your GitHub account
Received on Friday, 13 April 2018 13:26:35 UTC