Firefox Disables Loophole that Allows Sites To Track Users Via Battery Status (theguardian.com) 104
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 (Score:1)
Re: (Score:3)
"apparent no", according to the summary.
Re: (Score:1)
Is that the first time a browser reduces functionality following research reports warning of privacy risks?
No, it is not the first time that Firefox and Safari both have reduced functionality to protect users from a privacy risk. They likewise disable/spoof link visited color in CSS, because it can be used to slurp up history (the CSS History Probing attack) to get a reasonably unique fingerprint of the viewer of a site.
Reducing Functionality? (Score:5, Insightful)
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.
Re: (Score:2, Insightful)
Right, because webmasters always do what is technically possible for improving UX, not what is most profitable with shoving malware-laced ads down consumers' throats at the maximum possible bandwidth.
Oh brb, slashdot just jacked my browser with some "dnshost.me" tab that is almost certainly downloading malicious javascript.
If only I could say, "hey guys! my battery is low! lay off a bit!". I'm sure they'd listen.
Re: (Score:2)
And completely missing OP's point. But you're AC, that's to be expected.
Re: (Score:3, Informative)
A website could serve up fewer video intensive ads if it detected a low battery status
Maybe...
even pop up an alert window and offer to sell the user a new battery
Don't want
It could go ahead and save the user's status or input if it thought that the battery was about to die.
I'll hit save before I put it to sleep, no worries.
Honestly this is a tempest in a teapot. Couldn't it just be reduced to:
Battery level low: True/False
Heck let the user set what level it shows low as at well.
And nothing of value was lost (Score:3)
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
Re: (Score:3)
The idea was that web "apps" could be nearly as good as native apps, except no need to install them and they run sandboxed in the browser. Remember that the industry seems to think that every web site needs a companion app that is basically a webview control with shortcuts to spam your contacts list or direct you to the nearest store.
With other similar features, like location information, the site has to make a request and be approved by the user. This mis-feature doesn't require that though, which is why i
Re:Reducing Functionality? (Score:4, Interesting)
This API never needed to provide battery level as a double value. An enumeration such as { Full | Sufficient | Low | Critical } would have solved the privacy issue while providing useful information.
Re: (Score:3)
An enumeration such as { Full | Sufficient | Low | Critical } would have solved the privacy issue
Except that the primary reason for this change was not tracking but Uber jacking prices up if your battery is low.
Re: (Score:2)
If an ad-monging site actually cared enough to run light on video, it would be a genuine surprise. If anything, a website likely would throw more video ads in hopes the machine suspends itself with the ads still running, just out of spite. One has to assume that anything a browser contacts is untrusted and malicious... which most is because people can make millions and companies can make billions exploiting a flaw in a browser which can track users or sneak software onto systems without notice.
Don't think
Fuck you (-10000 Flaimbate) (Score:5, Insightful)
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.
Re: (Score:3)
I'm having a hard time deciding if you were joking or serious.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yeah, they've finally turned off an API that had no place being in a browser in the first place. Now all they need to do is disable the 800 APIs that have the same problem.
Had some Rust flake the other day rhapsodise to me how Servo was going to revolutionise browsing, and how the ability for web sites to directly control your rendering hardware was going to make Firefox the bestest and fastest browser ever. My response of "fixes browser memory leaks, does it?" didn't go down too well...
Re: (Score:2)
The whole Mozilla organisation jumped the shark some years ago, when they let the UX hoodlums and mealy-mouthed marketing types take over. Been using it since it was Phoenix 0.9.something. But now... It's been so sad, watching the cancer take hold... Pretty sure it's terminal by now.
*sigh*
Not to worry... (Score:4, Insightful)
Re: (Score:3, Informative)
... there will be far more egregious privacy-risking APIs in web browsers in the future....
Indeed. I don't even want a site to know whether I'm on a "mobile" device. All I want is standards compliant HTTP, HTML, CSS, and JS. I don't want ANYTHING else in my browser - if I did want those things, I would put them there myself. The remote site should neither know nor care what system is implementing the standards-compliant browser I use. All the remote site really needs to know is that my user agent speaks HTTP. Nothing else, including OS/platform, user-agent, etc is any of its damn business.
Re: (Score:2)
I don't even want a site to know whether I'm on a "mobile" device. All I want is standards compliant HTTP, HTML, CSS, and JS. I don't want ANYTHING else in my browser - if I did want those things, I would put them there myself. The remote site should neither know nor care what system is implementing the standards-compliant browser I use. All the remote site really needs to know is that my user agent speaks HTTP. Nothing else, including OS/platform, user-agent, etc is any of its damn business.
Goddamn right you are. Sorry no mod points ATM, though.
Re: (Score:2)
I don't even want a site to know whether I'm on a "mobile" device.
Then watch it assume you're on a mobile device and require use of drag gestures to view the next or previous page. Or watch it assume you're on a desktop computer and end up with tiny text, mouseovers, and links smaller than your fingertip.
Re: (Score:2)
Then watch it assume you're on a mobile device... Or watch it assume you're on a desktop computer...
Perhaps you missed this part?
All I want is standards compliant HTTP, HTML, CSS, and JS
The point being that the website should not assume anything whatsoever about the client, other than that it accepts these things and has its own ways of handling them, thank you very much.
Re: (Score:2)
"standards compliant [...] JS" can assume the use of touch gestures, such as slide to change pages. Or it can assume the usefulness of mouseover events.
"standards compliant [...] CSS" can make links small and close together.
Re: (Score:2)
We've gone too far (Score:5, Insightful)
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.
Re: (Score:2, Informative)
Somebody should tell that to android phone manufacturers that put everything from model to build number in the user agent.
Re: (Score:1)
Somebody should tell that to android phone manufacturers that put everything from model to build number in the user agent.
You actually use the stock browser that comes with the phone? I believe that's the source of your problem - trusting Google and/or the phone vendor to have your best interests at heart was a bad move. Frankly, you can't keep doing naive things like that and then reasonably expect anything else to happen. A good heuristic: if it comes from a marketing company, a phone company, or a cable company, it's automatically suspect until rigorously proven otherwise. This is doubly true for anything that comes ou
Re: (Score:2)
...if it comes from a marketing company, a phone company, or a cable company, it's automatically suspect until rigorously proven otherwise.
Truer words were never spoken.
Or, for you millennial types, "This."
Re: (Score:2)
NOt just them.
A while back there was a story on /. where you could check how unique your browser signature is. I was unique in the then-set of about 15,000 - mostly due to my Linux/Firefox user agent combination. That one was unique.
With the web being "standard" and all, I wonder what the use of such user agents is in the first place!
Re: (Score:2)
Re: (Score:2)
I'm sure you can do that in a different way: just use a few IE6-only commands that make the pop-up appear on IE6 but not on any other browsers. No need to check the UA for that.
Re: (Score:3)
Interestingly, Mozilla's FirefoxOS is all about interacting with the device within the browser framework.
The point of FirefoxOS is to make an OS that only runs a web browser, all user programs are web apps. So all hardware features, including the battery meter, have to be accessed by a web api.
Re: (Score:1)
Stop introspecting the device within the browser framework
That's my preference, too.
It's interesting to look at the history of this API, particularly early documents for the "System Information API" drafts that the Devices and Sensors WG produced, such as this one [w3.org], and the discussions on the mailing list leading up to it.
The justification seems to have been, gee, why can't web apps do everything native apps can? Who cares whether there's a use case?
Of course this was in keeping with the historical moment. This stuff originated in 2009 (yes, seven years is a typica
For what reason...? (Score:1)
Re: (Score:3)
So it can avoid loading video ads on mobile when you have low battery :D
Re: (Score:3)
So let's have a fake 'low battery status' tool to inhibit ads. I'm setting mine at 5% for the rest of my life.
Re: (Score:3)
You really think that websites would not send you an ad if your battery was low?
Re: (Score:1)
... does that sound to you like something that an advertiser is ever going to support? They are the "privacy concern" in the first place, using battery levels as a piece of identifying data for your browser session.
Re: (Score:2)
They are the "privacy concern" in the first place, using battery levels as a piece of identifying data for your browser session.
For a session, they already have your IP address and port information. They have the info in the user agent header.
Of what value is a tracking system that reports a different user just because someone has put his device on a charger, or that thinks it is talking to someone different because the battery level has gone down?
Re: (Score:2)
I could imagine it being more useful as browser based apps become heavier and heavier, you could selectively disable features as the battery gets eaten away. Also, as the mobile world shifts from apps to responsive web pages, you can do the same.
On the other hand, one could argue that the user might want to be in control of how much power a page uses anyhow, so you might as well supply the option. But then one option might be 'go full out when there's lots of juice, drop down a little bit when we're runni
Couldn't they have addressed the privacy concern? (Score:3)
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.
Better solution (Score:5, Interesting)
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.
Re:Better solution (Score:5, Interesting)
How about just "on battery power" or "plugged in"?
Re: (Score:2)
Plugged in = full volume, full screen Flash ads
On battery power = full volume, full screen Flash ads for batteries
Re: (Score:2)
Doesn't have to be new, incompatible API. Round 10 (Score:2)
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.
Re: (Score:2)
From the actual spec [w3.org] (emphasis mine):
From now on, let's just assume that any information can be mis-used and not send it without explicit permission,
Re: (Score:3)
We've tried the global experiment of browser-as-platform, and it has failed miserably from a security, usability and consumer-rights perspective.
The browser as a platform has definitely not failed, 90% of all computer time is probably in the browser. It has taken over almost all general computing task and more is coming. Look at the R&D invested in web technologies versus your favorite desktop OS. The desktop OS as we know it are going to die, it's already minuscule compared to the web.
Also OS specific, thank you very much (Score:2)
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?
Re: (Score:2)
Good luck turning a macOS binary made "with a proper multi-OS toolkit" into the corresponding Windows, GNU/Linux, or Android binary made with the same toolkit. Or good luck convincing the publisher to distribute the source code of its proprietary application to the public so that you can do the recompilation and the fixing of inevitable platform-related bugs yourself.
Re: (Score:2)
There used to be a MSN chat client written in Tcl/tk and that required only a small interpreter (likely is installed on your system as /usr/bin/wish)
I miss it - because MSN itself was put to death and replaced with something else.
There's Skype, runs on start up like it's Real Player and wastes task bar space (at least in Windows). So there's a non-web client for Skype at least, but there's only one and you can't run something else. That's what web apps got us : the data/network access/user experience is sil
Reduce functionality for security (Score:4, Informative)
Re: (Score:2)
why no API control? (Score:2)
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.
Not the first time (Score:2)
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 [mozilla.org] in order to prevent sites from discovering what other sites you had visited in the browser.
Why? (Score:2)
Doubt it's the first time (Score:3)
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.
Re: (Score:2)
what about disabling or degrading some of the heavier elements of a page if the battery is low? seems courteous and reasonable to me; legitimate, even.
Re: (Score:2)
so use a text-mode browser. next!
Re: (Score:2)
the internet runs on ads, and people are stupid and like shiny things even if they're just shiny pictures of things they will want to buy.
yeah it's kind of a shitty system, but apparently no one wants anything else enough to actually pay for it.
Quick question (Score:2)
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 brows
Re: (Score:2)
If you're afraid to swim with the sharks, feel free to stay out of the water.
Almost exclusively used for malware (Score:2)
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 wou
Present in Webkit, but never Safari (Score:2)
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
Other sensor APIs? (Score:2)