Battery Status API being Removed from Firefox due to Privacy Concerns | Hacker News Reader

Battery Status API being Removed from Firefox due to Privacy Concerns

bleepingcomputer.com

89 pointsKukuLu46 comments

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.

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.

They will take whatever you give them. There are sensible and useful web-sites/applications out there, but they are 1:100 (or Sturgeon's law's 10:90).

You can limit everything for everyone and maybe give option to enable softer limits for certain sites. I just hope that it would not hurt legitimate sites.

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...

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

What is an example of a site actually using it for this potentially legitimate use case?

Like others have mentioned, perhaps limiting network requests, slowing an event loop, locking FPS, that sort of thing.

Yes but has any website ever done any of this?

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..

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

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

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").

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.

Exactly what I thought. The website needs to know whether the battery is low or not, not even how much time it still has. Let the API return a true/false to that question and, if necessary for some usecases, hide the rest behind a default deny permission.

That still leaks a number, let's say it's 0-5h and resolution is 1 minute, that's 60*5 == 300, so roughly 8 bits of entropy.

A `onBatteryLow` callback might do the trick?

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.

I was actually very surprised when my wife told me she reviews permissions of app store apps on Android.

I thought for sure the average would be to just completely ignore them.

> 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.

> > Presumably there are good reasons to have it

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

I'm not sure I understand you there. If there are good reasons for it existing (as I presume there are) then surely that is a good reason for it to be kept?

> If you can't demonstrate a valid use-case

Perhaps a full-screen kiosk application needs to indicate battery level (because any OS indicator is hidden? Though admittedly this is not going to be a common need.

Another use would perhaps be to turn off "excess" animations in a game when the battery is low.

The problem is that you're presuming there's a good reason or valid use case. The existence of feature or API is not evidence that it's warranted or even a good idea.

My point is that you need to scrutinize things a little more and not just trust that there's a good reason for something, especially if it looks problematic.

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.

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?

I was thinking exactly the same thing.

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

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

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.

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.

> [...] 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.

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.

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?

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).

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

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.

Chrome uses Blink which was forked from WebKit long ago, see https://techcrunch.com/2013/04/03/google-forks-webkit-and-la...

IIRC Google already use their own fork of webkit, called Blink.

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.

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

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

Our application connects to a device that has very low tolerance for electrical interference, which means that the computer it is connected to must be on battery power. If we detect that the power supply is connected we disable the application. Also, we disable the application when the power is low, so the computer does not shut down in the middle of a session. Of course if anything happens to the API it is not that hard to bring it back via a native Electron plugin, I would just prefer not to have to do it.

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!

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)

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

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.

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

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.

Reply on news.ycombinator.com