
Battery Status API being Removed from Firefox due to Privacy Concerns - KukuLu
http://www.bleepingcomputer.com/news/software/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.

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

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

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

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

~~~
teh
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?

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

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

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

~~~
namtrac
Chrome uses Blink which was forked from WebKit long ago, see
[https://techcrunch.com/2013/04/03/google-forks-webkit-and-
la...](https://techcrunch.com/2013/04/03/google-forks-webkit-and-launches-
blink-its-own-rendering-engine-that-will-soon-power-chrome-and-chromeos/)

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

~~~
yoz-y
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.

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

