Re: Notes of June 30 teleconference

On Tue, Jul 5, 2016 at 10:33 AM <marcos@marcosc.com> wrote:

>
>
> > On 5 Jul 2016, at 10:22 PM, Kostiainen, Anssi <
> anssi.kostiainen@intel.com> wrote:
> >
> > Hi Marcos,
> >
> >> On 05 Jul 2016, at 08:15, Marcos Caceres <marcos@marcosc.com> wrote:
> >>
> >> On July 4, 2016 at 6:54:29 PM, Kostiainen, Anssi
> >> (anssi.kostiainen@intel.com) wrote:
> >>>
> >>>> 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.
> >
> > Domenic seems to disagree with your position:
> >
> >
> https://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0031.html


I think this is a bit of a misunderstanding. What I am saying in that post
is that it's OK to have APIs that always fulfill, and never reject. I'm not
explicitly endorsing APIs that stay pending forever.

I'm not against such APIs in principle; it seems like there are many cases
where you might wait for something to happen which never happens. But in
this case it seems like there's a clear-cut signal that the battery will
not be gotten, when the user denies the prompt.

I'm curious why battery uses a different permissions model than most other
APIs, which are OK with rejecting when the user denies permission?


>
>
> That seems odd. We (developers) have enough issues as it is with promises:
> but to suggest that a UA provided promise never settles seems like a whole
> new level of uncertainty (particularly without, currently, a means of
> cancelation).
>
> What am I missing? and yes, I know one could wrap the promise in another
> promise that times out - or that permission-requesting APIs can block on
> settling on waiting on the user, but this seems different.
>
> I'm reminded of the continuing disaster that is Firefox's Geolocation UI,
> which never calls the error callback if the end user dismisses (rather than
> cancels) the permission prompt. The amount of abuse we've received from
> devs for that terrible decision over the years.... This sounds a lot like
> that.
>
> See (make popcorn first 🍿):
> https://bugzilla.mozilla.org/show_bug.cgi?id=675533
>
> >
> >>> * 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.
> >
> > I think we need to take another look at use cases.
> >
> > Below are couple of use cases that came to my mind that would require
> app level power management:
> >
> > * App adjusts the amount/number of messages/tweets/data it fetches over
> the network as well as the polling frequency depending on the battery
> level/plugged in state. If battery drops below 20% the app will only poll
> for new data if the user explicitly interacts with the app and clicks the
> "Update" button, otherwise the app fetches data without user interaction.
> >
> > * App persists its state to cloud only if there's an increased risk of
> running out of battery. App does not want to persist the state
> unnecessarily since it is an expensive operation that also depletes battery
> (don't want to do it unless really needed).
> >
> > * App will only start an expensive (in terms of battery) operation that
> must run to completion if the battery level is over 40%. For example, show
> a simpler map and not the fancy WebGL one if low on battery while using a
> web-based navigation app. (the navigation app knows how long it'll take to
> get to your destination, so can act accordingly).
> >
> > * App will only start a long-running irreversible operation if the
> battery level is above certain threshold. For example, a very tedious
> checkout process, or an update of app assets (e.g. download of hi res
> textures for the new level in a web-based game).
> >
> > All these could be enhanced with app level power management that would
> complement the power management decisions the OS makes. I think in an
> optimal scenario app and OS level would work in concert. For example, OS
> could still batch network requests from various apps/services in order to
> keep the radio up as little time as possible (to preserve battery), even if
> the app also does decisions based on battery status.
> >
> > In reality some app developers will always abuse APIs. What I'd like to
> do in terms of the spec is to ensure we specify escape hatches as to allow
> implementations mitigate the impact when that happens, while still remain
> conformant with the spec.
> >
> >>>> 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.
> >
> > Thanks,
> >
> > -Anssi
>