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 https://github.com/lknik/battery/pull/1

[anssiko]

@marcoscaceres does https://github.com/lknik/battery/pull/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

[anssiko]

Now that we have learned more about the possible attack vectors (thanks to Chrome and Firefox shipping the API since Oct 2014), I propose that as a further mitigation strategy against potentially malicious content using the API (e.g. framed tracker scripts) we should consider making the API available only within a secure context that is also a top-level browsing context. This would disallow the use of the API within framed content, as well as from any content that is not a secure context.

See top-level documents and framed documents for illustrations.

Along with other mitigation strategies, I believe this would alleviate the concerns raised.

There exists a hook in the spec to implement this change with no API surface changes: one could leave the promise returned by getBattery() in a pending state if invoked from within a browsing context that is not a secure context and not a top-level browsing context without breaking existing content or leaking any information.

@lknik Do you have any concrete input to the normative prose of the spec?

[anssiko]

Ping @cpeterso for Mozilla's comments.

[cpeterso]

Limiting access to the API (to a secure context of a top-level document) is good. Prompting the user for permission is another option, though I don't think most users can make an informed decision about allowing access to the battery status.

Identifying the use cases for the battery API would help show where the API is exposing more information than necessary. For example, is chargingTime useful for a web app that would like to be polite when the battery is low? IIUC, the API was originally designed to implement the status bar and system settings app in Firefox OS, which is a different use case.

[anssiko]

@cpeterso Thanks for your comments. My response below is a bit wordy since I wanted to include some historical perspective, hope it's useful. As the co-editor of the spec, I've been watching from the front row how the spec has developed over the years, driven by implementers' feedback.

About prompting:

You're right about prompting. Studies show normal users do not grasp the concept. That's why prompting is not required, it is just an option ("The user agent may ask the user for battery status information access."), and not the only mitigation mechanism.

About use cases:

None of the high value use cases for browsers that I know of require high precision readouts. For example, all the use cases I enumerated are implementable with less precise readouts. How precise the readout is for each of the property of BatteryManager is up to the implementation to decide, can vary from one to another (and can vary during runtime, more on that below). The following recommendation in the spec is meant to aide implementers in this regard: "The user agent should not expose high precision readouts of battery status information as that can introduce a new fingerprinting vector."

(We'd be happy to make this even more clear and concrete, we're open to suggestions for better wording.)

The spec leaves it up to the implementation to decide what is considered the right precision for each property. Each browser strikes a different balance between privacy and exposing powerful features. The spec as worded allows implementers to innovate and compete in this regard, while still remain spec-compliant.

For example, a privacy-aware browser might expose just hardcoded 20% or 80% readouts or round time-related readouts to nearest hour, while another implementation might offer higher precision readouts e.g. in cases when the user has established a stronger trust relationship with the web page. For example, a Progressive Web App that has been installed might get higher precision readouts. The API surface remains the same. There's more room for innovation here for browser vendors.

About the history of the API:

The API was refactored since Mozilla's initial Firefox OS-inspired proposal to make it browser-friendly and privacy-aware. Namely, in the current API BatteryManager is gated behind a promise (in Mozilla's proposal, it was directly exposed on navigator.battery) and the security and privacy considerations have been refined (in the initial proposal, they were too relaxed for browsers). These changes were done based on Google's feedback.

After these changes Google felt good shipping the API in Chrome.

[lknik]

Hi

@anssiko you are right, let's go with top-level and secure contexts. I am happy with my other suggestions to the spec and mitigation strategies... I'd also like to remind my other more concrete suggestion about minimizing the output. They're included in my report (which begs for an update, as well as converting it into a Note even?). I.e. to propose reporting of only certain levels, such as "low" "medium" "full", etc.

Also, since high-level sensors won't provide too much details by design, why not considering to split Battery in a high/low-level sensor fashion? Thank you also for the historical perspective.

However, the issue is that if someone wants to profile the user based on his device battery use, the situation is still somewhat tricky. Let's say that an Honest Ahmed Bicycle Service (HABS) observes that, say, people on Friday night tend to be a bit in a rush to get back home, and when their devices are low on battery they would tend to agree to pay more for a service... In those cases, even minimized data could reveal actionable insight.

Thad said, on the technical side - I made sure that the wording in suggestions/considerations was adequate and it was leaving enough room for vendors.

@cpeterso

Thank you for a the context behind FirefoxOS motivations. I agree about user awareness. Browsers should offer sane settings by default. I'm also unsure about the real use cases for chargingTime/dischargingTime. Sounds like the real need for those is not clear. How about (@anssiko ?) sanitizing/removing those or make them optional? If not, I would still suggest to vendors to think whether these are needed, and how the actually reported values should be processed... Designing general privacy-vetted strategies APIs for browsers sounds just exciting.

[anssiko]

I.e. to propose reporting of only certain levels, such as "low" "medium" "full", etc.

Mapping of "low", "medium", and "full" to implementation-specific level percentage values is a valid implementation strategy. @cpeterso also suggested the same.

I'm also unsure about the real use cases for chargingTime/dischargingTime. How about (@anssiko ?) sanitizing/removing those or make them optional?

As the spec editor, I can't just remove features from the spec that are shipping. Implementers can make them less precise if they wish. Only if all the implementers agree, we can consider removing features from the spec.

[lknik]

@anssiko

We agree on the minimization side, it was under long (more than a year now?) discussion, so good!

As per the spec editing details - I understand. Thanks for clarifying.

[marcoscaceres]

Given that browser vendors are pulling the API, we should rescind this spec and move on.

[anssiko]

@marcoscaceres Please note the concrete privacy-vetted mitigation strategies discussed in this issue are generic, not specific to this API -- they apply more broadly. I feel giving up would set a wrong precedent. My personal motivation is to identify concrete proposals reviewed by domain experts, so that we can collectively continue to ship powerful features on the Web in a privacy-aware manner also in the future.

Looking at the current browser market share, especially on mobile (bigger than desktop browsing now) where the use cases are the most powerful, recent pull offs have practically no real-world impact.

I'm all in for improving the spec together with implementers who don't feel like giving up on powerful features is the way to go.

[marcoscaceres]

Agree with the motivations and goals, don't get wrong. But we are not talking about all features here, we are talking about one. We learned a lot from battery (that we can now apply more generally), but if it's being removed from browsers, we should consider rescinding it nonetheless.

The question is: what UAs will continue shipping the API? and if we will have enough implementations to warrant continuing to push forward with it.

[anssiko]

The question is: what UAs will continue shipping the API? and if we will have enough implementations to warrant continuing to push forward with it.

Per http://caniuse.com/#feat=battery-status (show all) the UAs currently shipping include Firefox, Chrome, Opera, Android Browser, Opera Mobile, Chrome for Android, Firefox for Android, UC Browser for Android (partial), and Samsung Internet.

Edit: Also Yandex Browser for Android ships the API with an innovative approach to privacy. I'm excited to see such innovation in exposing powerful features in a privacy-aware manner. Kudos!

I feel it is my responsibility as the spec editor to keep maintaining and improving the specification as long as there are implementations, and that's why I'd like to keep this issue open.

[marcoscaceres]

Ok, but it's no longer exposed to web content on the Mozilla side (so that affects all Firefox versions).

If Blink decides to also unship it, then Blink-dependent browsers will be affected (taking the list above to zero implementations).

Any word on what Blink folks are planning to do?

[anssiko]

Any word on what Blink folks are planning to do?

See https://crbug.com/661792

[lknik]

It's recently linked with Blink>PermissionsAPI component in Blink.

[anssiko]

I opened #10 for the proposed concrete spec update, and will close this issue.