Battery Status API being Removed from Firefox due to Privacy Concerns

[hawski]

There probably is not much of a difference for a website if user is low in power than if it is low in memory. There should be then just one flag/event really: low resources (catch-all for: battery, memory, CPU time, storage etc.). But browser could just emit please-save event and give a second or so to complete. Then decrease timer intervals significantly.

Alternative (only for power) could be the levels of concern in power usage: low concern (desktop or mobile that is charging), concern (mobile), high concern (mobile on low battery). Then we could streamline it more, because websites know when you are on mobile already and give single flag: low power. But approach from first paragraph is probably more sensible.

[jasonkostempski]

How about websites just don't use more resources than they have to? If I'm 100% charged, it doesn't mean I'm willing to give 85% of it to some site that wants to show some useless flair.

[cptskippy]

I like this approach, a nonspecific flag that simply indicates that all polling or interval based APIs will function at prolonged delays. GPS only updates every minute or so, timeouts are extended, etc...

[endemic]

Great idea. The API itself does have legitimate use, and removing the fine level of detail would hopefully assuage privacy concerns.

[sbarre]

Wasn't there also a thread a while back about how Uber was allegedly using battery levels to manipulate surge pricing at the individual level?

So if your phone was dying you were more likely to accept it because you wanted to book the ride before it died?

Unscrupulous websites could theoretically manipulate your experience in similar ways using battery level knowledge, I would think..

[campuscodi]

It was only a study. Users were willing to accept higher prices, but no company was caught red-handed yet.

[mynameisbahaa]

https://news.ycombinator.com/item?id=11746343

[dspillett]

Completely removing the feature seems overkill. Presumably there are good reasons to have it (full-screen kiosk style apps perhaps?) so would it not be better to leave the feature there but add a permissions gate as seen with location information and full-screen use ("This site wants to see power management information about your device, should we allow this? yes/no/always-for-this-site/never-for-this-site").

[rossy]

Agreed wrt. the permissions gate. I wish more web APIs used these. I think there's an argument going around that these things are bad UX because they train the user to ignore prompts and just accept anything and everything so they can use the app, but at least on Android, it seems like users actually take notice of permissions (and complain about excessive permissions in Play Store reviews.) Keeping users aware of exactly what data is being leaked about them can only be a good thing. Bonus points if the API returns fake data until the user accepts the permission and there's no way for the app to tell if the data is real or not, so it can't force the user into accepting permissions they're not comfortable with.

[cptskippy]

> Presumably there are good reasons to have it

That's not a good reason to keep a feature ever.

Given the context, browsers are ultimately a user's tool, not the developer's and the validity of APIs should be gauged by how useful they can be to the end user. If you can't demonstrate a valid use-case for the end user then there's no business having the API.

[currysausage]

Permissions probably aren't that great UX-wise, but couldn't the API have been simplified instead, only allowing web sites to query remaining battery time? To me, it sounds like the API is vastly overengineered.

[anilgulecha]

Good move by Mozilla, and sets good precedent of deprecating/removing features that hamper privacy. Safari is following on too.

A minimal boolean API (onPower/onBattery) would be sufficient for most application uses.

[corecoder]

I don't understand: couldn't they just make the results less accurate (say, ten possible values) so that it can still be used to tell if the battery is going down but not to identify users?

[Ygg2]

I doubt attackers only rely on a battery API. It's a conglomeration of attributes, not a single one. Problem isn't this phone with 30% battery is Adam Jensen. The problem is this phone with 30% battery and this user agent, and these addons, that takes X time to render SVG as Y, and takes 20ms to execute this code, etc. is Adam Jensen.

For example the mere presence of battery API gives bits of information (because it identifies your program as phone or computer). I assume that Battery API:

A) Provides enough bits of information,

B) Isn't useful enough.

[frankquist]

Or to go entirely minimalistic: only provide a boolean "device might die within 10 minutes" value or something.

[chriswwweb]

Agree, this seems overkill, privacy is good, but removing a feature because some use to spy on users seems to be a quick fix. I mean will they also remove cookies because some adds networks use them to track users? Probably not.

And the problem probably won't go away by just killing one feature. As far as I know such user fingerprinting techniques work because values from lots of APIs get taken into account, so just killing one API won't solve the problem completly.

What bothers me most, is that this is a step back for webapps developers, the web app loose a feature the native apps can still use, it's just sad.

I guess the mozilla team has put some thought into this!? I would really like to know what their pros and cons where. I wonder what other solutions they considered and why those where all dismissed until finally deciding in favor of such a drastic move.

[altern8]

I was thinking exactly the same thing.

It could even be limited to an integer, or even keywords: 'good', 'medium', 'low', 'critical'.

[xg15]

> [...] the Battery Status API, a feature that allows websites to detect the status of the user's battery level, and use this information to save critical website data to disk before the device shuts down.

If that was the primary use-case, why not add a new feature that explicitly handles this?

You could imagine an "emergency shutdown imminent" callback that the browser invokes if there is a high likelihood of an emergency shutdown (because of battery level or other indicators). This would also give the browsers more leeway in evolving this feature and experimenting with different indicators, without breaking compatibility.

[jsgo]

I like this idea. And then if the browser can tie back to the OS, specifically Windows with its update restarts but really any of them where browser open + reboot/shutdown, it's an enhancement for site developers without actually needing to do anything.

[crisnoble]

Has anyone ever seen a website that uses this for anything at all other than user tracking? Has anyone ever built a website that adapts its power consumption based on this value?

[ysavir]

It's funny how many people here are advocating adding more functionality and UX to a feature that is hardly used (that I've seen, at least).

[campuscodi]

To be fair, the article doesn't say Google is removing it. Just Mozilla and Apple.

[gpvos]

Yes, but Google Chrome uses Webkit. If it's removed from that, Google will have to maintain that functionality on its own. Might not be worth it.

[soft_dev_person]

Couldn't a new API be added where web apps can subscribe to critical battery level warning events? Would be a lot less useful for tracking, but still serve the purpose intended for the original API.

Probably already on the way.

[yoz-y]

Hum, I hope this API will stay there at least in Electron as we need it for our application.

[jasonkostempski]

I haven't seen a convincing use case for the feature yet, any chance you can share what you "need" it for?

[JadeNB]

For what it's worth, in case you did a double take as I did, it's "(removing a feature) to protect consumers' privacy" (that is, a good move), not "removing (a feature to protect consumers' privacy)" (a bad move).

I'm not sure why we're keeping the clickbait title; the feature is the battery status API, which a study (http://lukaszolejnik.com/battery) showed might open up privacy issues. EDIT: Neither complaint applies to the new title. Thanks to the editors for changing it!

[dictum]

I joke about their headline clichés, but the NYT solved this a while ago. Their standard headline format is [motivation, action]. So it would probably be "To protect consumers' privacy, web companies remove a feature"

(Actually it would probably be "In web browsers, a feature finds an unexpected use" or some such)

[zihotki]

They are removing battery status API because it was used to track users by ads networks and alike.

[bgarbiak]

The article does't exactly explain how the API and its exploit works, but my first thought was: can we at least have a simplified version, with not so accurate status? 10% thresholds should be just enough for the intended use, I believe.

[jlgaddis]

Note that you can turn this off yourself by setting "dom.battery.enabled" to "false".

[problems]

Title should be corrected, Mozilla is removing it, Apple is considering removing it, but nothing about any movement on Chrome. Maybe the poster made the Blink vs Webkit mistake?

EDIT: It's been fixed now, thanks.