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.
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.
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.
> 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.
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.
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.
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?
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.
One problem with your comment is that HN is global.
There are many people reading and posting on HN from China, Japan, Spain, Germany, Russia, etc. English is not their native language. Their mastery of written English is superb, by most objective criteria.
Or maybe someone just made a typo?
Not every minor mistake needs to be pointed out. This particular mistake wasn't egregious enough to justify creating a provocatively named new account in order to point it out.
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:
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.
> [...] 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.
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.
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...
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)
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?
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?
50 comments
[ 3.1 ms ] story [ 102 ms ] threadA `onBatteryLow` callback might do the trick?
I thought for sure the average would be to just completely ignore them.
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.
> 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.
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.
A minimal boolean API (onPower/onBattery) would be sufficient for most application uses.
Probably already on the way.
It could even be limited to an integer, or even keywords: 'good', 'medium', 'low', 'critical'.
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.
There are many people reading and posting on HN from China, Japan, Spain, Germany, Russia, etc. English is not their native language. Their mastery of written English is superb, by most objective criteria.
Or maybe someone just made a typo?
Not every minor mistake needs to be pointed out. This particular mistake wasn't egregious enough to justify creating a provocatively named new account in order to point it out.
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.
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..
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.
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.
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'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!
(Actually it would probably be "In web browsers, a feature finds an unexpected use" or some such)
EDIT: It's been fixed now, thanks.