Slashdot Mirror
Firefox Disables Loophole that Allows Sites To Track Users Via Battery Status (theguardian.com)
New submitter xogg writes: Battery Status API allows web sites to read the battery level of user's system. The API was found to bring privacy risks and abuse potential and a number of implementation bugs. Now with apparent no legitimate use cases, Mozilla is taking the unprecedented decision to vaporize a browser API due to privacy concerns. And apparently, WebKit, powering Apple's Safari follows. Is that the first time a browser reduces functionality following research reports warning of privacy risks?
Yes
I would hardly call this reducing functionality. Technically, sure. But a web browser is supposed to browse the web, and this API wasn't helping any.
... there will be far more egregious privacy-risking APIs in web browsers in the future....
Go to about:config and set
dom.battery.enabled = false
Nothing of value will be lost
Stop introspecting the device within the browser framework. Browse the web, run sandboxed script code, but stop digging into the device. Leave the other information mining to apps with appropriate user controls to say fuck off when appropriate.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
At the risk of being relegated to the realm of the uninitiated, I have to ask: For what practical reason does a browser need to have information about battery life?
Make the site request permission, like it would for the camera or GPS location.
I don't see this is as some big thing, but just because I can't think of an important use case doesn't mean there isn't a good one somewhere. Surely somebody wanted this for some reason? Anyway, it seems weird to introduce it then take it back over concerns that seem pretty mild, and also pretty easy to address the same way other concerns have been addressed in the past.
Let's not stir that bag of worms...
Browsers should allow.. browsing content. That's all. I'm willing to accept a browser being able to render graphics in RAM (NOT to disk), perhaps beep at me and play some music, and respond to the mouse and keyboard. Downloading files at explicit user request, to specific locations is also useful. Everything else is a security risk and should not be part of the browser. That's what 'desktop apps' were for, and they worked very well thank you very much.
We've tried the global experiment of browser-as-platform, and it has failed miserably from a security, usability and consumer-rights perspective.
It isn't the first time browsers reduced functionality for security. It used to be you could use a url such as http: //username:password@hostname/ but that was abused and eliminated from all major browsers. (space added after http so slashdot reformatter doesn't break comment).
Just replace the battery percentage value, if that's what the API was returning with an BatteryIsLow() boolean, which could be set at something arbitrary, like 30%.
This way, the valid use cases, like control of video serving or "intensity", could still work, but the privacy concern would be gone. You can't effectively track someone in general just by knowing the times when they transition around 30%. That would be too rare to be a useful tracking data point.
Where are we going and why are we in a handbasket?
I wish Chrome and Firefox gave their owners complete control over exactly what APIs random websites can access, rather than just presume we don't care if they report our system details and other things.
It seems crazy to me that by default I can't even stop websites from opening other browser windows.
There were many promising use cases for this functionality, which now have gone into the shitter.
There wasn't a single valid use case for third parties being able to monitor your battery through a general purpose web browser. It just gives another way for advertisers to try to keep tabs on you without your permission. There is nothing useful about this "feature" to me as an end user and as such it should go away.
A website could serve up fewer video intensive ads if it detected a low battery status, for example, or even pop up an alert window and offer to sell the user a new battery
I have an easier solution. I just block the ads and then there is no problem with them draining my battery. Here's a clue - anything that increases the ability of advertisers to track me is a Bad Thing. Here's another clue. Advertisers don't give a shit about saving your battery. You are nothing more than $$$ to be harvested to them. The notion that advertisers would altruistically do things to save your battery life is unbelievably naive.
It could go ahead and save the user's status or input if it thought that the battery was about to die.
This can be done without worrying about the state of the battery and in fact doing so is often a good idea. Being able to monitor my battery improves nothing.
and about time.
Comment removed based on user account deletion
It wouldn't *have* to be a new API that breaks compatibility. The implementation could just be changed to have less precision, round to nearest 10%. That would be less likely to break any current legitimate use of the API, such as on Firefox OS.
Setting aside cross-site requests etc, I think the first time privacy issues were recognized by browsers was when they restricted access to :visited link styles in order to prevent sites from discovering what other sites you had visited in the browser.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Now that nobody uses Firefox (down to 7% share now) any more, I suppose this is their new business model.
1) Insert some stupid, pointless, malicious code,
2) Remove said code,
3) Expect undeserved accolades,
4) ?
5) Profit!
So when are they going to get on that one? As of now HTML5 audio API will return details even if you have click to play or media disabled. They took away the setting that controlled it after pronouncing the bug "closed".
Why the hell would Mozilla allow websites to view your battery status to begin with? That's bullshit.
I doubt this is the first time, seeing as how computer science is now a 70 year old field.
But that's not even the correction question. The real question is, "Did they do the right thing?" IMO, yes, yes they did. A website has zero legitimate reason to track battery status, and as we've already discovered, the API is nothing more than another avenue for abuse.
The whole bluetooth web API nonsense falls into the same category. The level and likelihood of abuse is countless orders of magnitude more likely than any legitimate use case the budding Einstein inventor can come up with.
On desktops I use PaleMoon & Vivaldi. On my phone I use Lightning. It is open source and available on F-Droid.
Why would a web site ever need to know the battery level of a device? Somebody obviously thought it was a good idea and then got some others to agree. "Yes, that's an excellent idea. We'll roll it into the next release. Good work."
Who the fuck ever thought this was a good idea in the first fucking place?!?!?!?!?!??!?!?!?!?! 99% of all web sites give exactly ZERO fucks about my screen dimensions, bandwidth availability, bandwidth costs, CPU, memory, storage usage, what else I'm using my computer for, or how much free time I have. What fucking IDIOT thought ANYONE ANYWHERE would ever lift a fucking FINGER to save me an ounce of battery life? "Oh, hey, I was going to do a few rounds of SETI@HOME in this iframe here, but since your browser indicates you have under 20% battery left, I'll just skip that."
Now, if my OS wants to tell my browser "Hey, battery is low, don't autoplay media or loop GIFs", that's totally fine, but I can't think of one single reason to ever tell a remote server about that.
Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
There were many promising use cases for this functionality, which now have gone into the shitter.
Horseshit. No website has *any fucking business whatsoever* accessing my hardware in such a fashion, period.
And I am perfectly capable of reading my device's battery monitor on my own, thanks very much.
And if websites didn't on serving up "video intensive" ads, ad blockers might not be in such high demand.
And you're a complete asshole for wanting to be an enabler of this shit.
Go die in a fire.
Il n'y a pas de Planet B.
Let's face it, using the battery level for tracking purposes is malware. And, while it would be possible to serve simpler, lower computational cost websites when battery levels are low, or increase autosave frequency, its main use has been hostile to the user. I would say that if a website didn't make use of the battery state information in any way that helps the user, but asks for it anyways, then it is a malware website. Admittedly very mild malware, but if this had been severely punished early on, we wouldn't now be removing this abused functionality.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Everything else is a security risk and should not be part of the browser. That's what 'desktop apps' were for, and they worked very well thank you very much.
How well does a web application made for Safari for macOS work on Chrome for Windows or Linux? Reasonably well.
How well does a desktop application made for macOS work on anything but a Mac?
Pretty close. I mean, they haven't even removed the annoying popup ad API, instead putting popup blockers on top, which need to be updated again and again, because advertisers keep finding ways to get around the popup blocker. If they had instead removed the popup api, there would be no way to create popups, and thus no popup ads period.
AFAIK, while Webkit has an implementation of the Battery Status API, Apple always specifically disabled it in their Safari builds.
From what I can see, the only browsers affected by it currently are Firefox, Chrome, and Opera. Microsoft and Apple had enough wisdom to stay away from this API in their shipping browsers.
Yaz
They are on their way to making a portable operating system using the browser. The web literally is "write once run everywhere" these days (i.e. as long as you stick to the standards and don't add Flash and friends to it). They will probably have to implement a permission system like in iOS and Android 6+ at some point. Asking for webcam and location permissions is already in, more to come.
Before you know it they'll start saying "Chrome is a great operating system. All it lacks is a decent web browser." /wink
Yet I don't know why any app (web or native) would need to read the battery status or any hardware characteristic for that matter.
How about the Ambient Light API? And any other sensor-exposing APIs that may be lurking in there? Or, if somebody really thinks there's a good reason to allow sites to read arbitrary sensors, give the user fine-grained control over which sites have access to which sensors. Preferably with the default access being "NONE".
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.
From the actual spec (emphasis mine):
From now on, let's just assume that any information can be mis-used and not send it without explicit permission, okay?
Chelloveck
I give up on debugging. From now on, SIGSEGV is a feature.