Mitigating potential privacy-invasive usage

[anssiko]

Starting with a concern raised in https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0000.html (see the full thread), we ended up discussing the permission model for the API, in particular why it is different from other APIs.

Let's use this issue to document proposed solutions that could be transformed into spec prose, while keeping compatibility with the existing shipping implementations.

[lknik]

Interesting issue.

Since the considerations advise:

"The user agent may obfuscate the exposed value in a way that authors cannot directly know if a hosting device has no battery, is charging or is exposing fake values.

Would it be a good idea to consider returning a "fully-charged status" in such cases?
Would that break anything?

[anssiko]

@marcoscaceres do you have concrete proposals how to fix the API to allow you to continue ship the API and feel good about it?

[dontcallmedom]

@marcoscaceres @anssiko I don't think the proposed conversation at TPAC happened; meanwhile, we ought to decide what the right next steps for this API should be (scrap, amend, or finalize)

[anssiko]

We ran out of time at TPAC (had so intense discussions related to sensors).

I've seen no concrete solutions, so I'd amend the spec with non-normative text that makes it clear what the concerns are, and finalize it. The API ships in http://caniuse.com/#search=battery

[lknik]

Just a slight addenum, aren't the current privacy considerations already reflecting it?

[anssiko]

It would be great if you @lknik could help review the current considerations section and let us know if we indeed have covered all of the Mozilla's concerns.

[lknik]

@anssiko I will do so, just a slight comment: are the concerns specified in any specific place?
Back in a while I made a post on it. I'll write additional text for the spec.

[anssiko]

Concerns specified in https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0000.html

[lknik]

Let's add at the consideration's end:

The information provided by Battery API may potentially be used in profiling the user via analysis of device use patterns.

(I don't think we should link to any media reports/blogs and mentioning media posts in the spec are probably not good practices?)

We can also consider changing MAY to SHOULD, so rephrase:

The user agent MAY ask the user for battery status information access, or alternatively, enforce the user permission requirement in its private browsing modes.

to:

The user agent SHOULD be subject to permissions

[lknik]

Hi,

Just did it here lknik#1

[anssiko]

@marcoscaceres does lknik#1 document your concerns adequately?

[anssiko]

Per https://bugzil.la/1313580 Mozilla is in process of unshipping the web-facing Battery Status API.

Given the API is pretty high on the Edge wish list, we should probably consult other implementers on their interests and plans before we do any decisions in terms of Rec Track advancement.

Also UC Browser with 17% worldwide market share on mobile has partial support per http://caniuse.com/#feat=battery-status

[anssiko]

Now that the unshipping news broke, there are strong reactions for and against, as expected.

I'll add some pointers to historical discussion below in case we'll revisit this topic. Further pointers to helpful fact-based discussion welcome.

Mozilla's heads-up:
https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0000.html

Mitigation strategies:
https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0005.html

Use cases: https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0011.html