Re: Notes of June 30 teleconference

On July 4, 2016 at 6:54:29 PM, Kostiainen, Anssi
(anssi.kostiainen@intel.com) wrote:
> Hi,
>
> > On 01 Jul 2016, at 11:12, Dominique Hazael-Massieux wrote:
> > Given this, I would like to suggest that we should instead of a new
> > Proposed Recommendation, fall back to Candidate Recommendation where we
> > can evaluate the expected future implementations of the API, or evaluate
> > mitigation strategies to the concerns you mentioned.
>
> The mitigation strategies baked into the spec currently are the following:
>
> * 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.

This is not a good idea, IMO. We can't just leave promises in pending
state or that will block the program from proceeding.

Imagine:

```JS
async function getState(){
  var battery = await navigator.getBattery();
  // await other async stuff, won't ever happen :(
}

getState().then(updateUI).catch(thisWontEverBeCalledHowSad);
```

In the above, the updateUI() function would never be called and
violates expectation of least surprise: we expect promises to resolve
or reject (or even time out and reject) - but never to just hang the
program indefinitely. Not even .catch helps there. That's less than
ideal.

So, leaving promises pending will just end up frustrating users, as
applications would potentially randomly stop working because promises
fail to resolve.

> * Implementations may obfuscate the exposed values, and/or adjust the precision of
> the readouts as they see fit.
>
> See also:
>
> https://w3c.github.io/battery/#security-and-privacy-considerations

This might be fine, but it doesn't address the underlying
presupposition and use case: that this API is no longer needed because
power management can be done better at the OS level instead of the
application level.

> > Frederick, Anssi, what do you think? There is a certain amount of time
> > sensitiveness to this: we owe the Advisory Committee an update on the
> > Battery API (since they reviewed it as a Proposed Recommendation quite a
> > while ago), so I would like whatever next step we choose to be put in
> > place next week if possible.
>
> Let's fall back to CR.

I agree, this would be good.

Received on Tuesday, 5 July 2016 05:15:47 UTC