Privacy Alert: Your Laptop Or Phone Battery Could Track You Online 95
Mark Wilson writes: Is the battery in your smartphone being used to track your online activities? It might seem unlikely, but it's not quite as farfetched as you might first think. This is not a case of malware or hacking, but a built-in component of the HTML5 specification. Originally designed to help reduce power consumption, the Battery Status API makes it possible for websites and apps to monitor the battery level of laptops, tablets, and phones. A paper published by a team of security researchers suggests that this represents a huge privacy risk. Using little more than the amount of power remaining in your battery, it is possible for people to be identified and tracked online. As reported by The Guardian, a paper entitled The Leaking Battery by Belgian and French privacy and security experts say that the API can be used in device fingerprinting.
We need an OS fix (Score:5, Interesting)
If the OS randomizes the LSBs of the value every time it is asked that would reduce the use for tracking but still provide the function that might be useful to a user.
No, we need to ditch this web idiocy completely. (Score:5, Insightful)
We shouldn't resort to hacks like that.
Seriously, get rid of this shitty functionality. It does not belong in a web browser.
After getting rid of this battery shit, get rid of the goddamn video and audio capabilities that have been added recently. If a website wants me to watch some audio or video, it can serve up a file that VLC or some other external player can play, after I've been promoted to allow this to happen.
Since they audio and video shit would be gone, the motherfucking DRM that has been added lately can be totally removed, too.
Get rid of JavaScript, too. It's a total piece of shit, and it hasn't gotten any better after 20 frigging years! If a browser needs to be scriptable, at least use a real language, like Lua or Python.
We shouldn't hack around this idiotic functionality that's been added to web browsers lately. We should remove it completely.
Re:No, we need to ditch this web idiocy completely (Score:4, Interesting)
I was starting to think the API was the most stupid thing ever, but I realize how to turn it to my advantage. The API is present so that websites can know to dial down the dumb crap when the user's device has low battery. All I'll need to do is hack the browser so that it permenantly reports the battery level as 10% of a full charge. If I'm lucky, that will make the sites revert to being useful.
Re: (Score:2)
The API is present so that websites can know to dial down the dumb crap when the user's device has low battery.
I think you will find that its primary purpose is to display full screen ads screaming "LOW BATTERY!!! CLICK HERE TO BUY MEGA-ULTRA-BATTERY OVER 9000mAh TOP QUALITY IPHONE LAPTOP ANDROID WINDOWS 10 GENUINE" with the volume at 109%.
Re: (Score:2)
I dont agree with this.
What we need is a browser that has this capability but does _NOT_ under any circumstances allow it to autoplay. Flashblock used to perform this functionality admirably, but since we all moved to HTML5 and all its magical wonder we've gone back to the point where browsers automatically play anything.
And I warned all of you years ago you'd rue the day you bli
Motherfucking IMG tags (Score:2)
Ever since marca came up with that inline image shit everything has been downhill.
"marca digs goto"; shoulda known how this would turn out...
Re: (Score:2)
You had me until Python. Any language where whitespace has meaning... I still can't believe such a thing actually caught on.
The Problem with Pen Island (Score:2)
Any language where whitespace has meaning... I still can't believe such a thing actually caught on.
I don't know how English caught on with things like "experts exchange" vs. "expert sex change" or "mole station nursery" vs. "molestation nursery" or "who represents" vs. "whore presents" or "pen island" vs., you know... [orain.org]
Codec pack as malware dropper (Score:2)
If a website wants me to watch some audio or video, it can serve up a file that VLC or some other external player can play, after I've been promoted to allow this to happen.
If you happen not to have a compatible video player installed on the machine that you are presently using, what message or prompt should the system display? Offer a chance to install a "codec pack"? That's what we had before Flash, and malware developers learned that it was effective to to disguise an installer as a codec pack or Flash Player update. And if a web application wants to play several audio streams at a time, such as a game that wants to play both music and sound effects, how would it "serve up
Re:We need an OS fix (Score:5, Insightful)
I'm going to propose a more radical fix: we need to stop letting the DOM have reliable access to so damn much information.
When we started the move away from webpages and toward web applications, we let the DOM have access to pretty much everything, because applications are big and general and data-hungry: The DOM captures keystrokes so each website can have it's own controls and hotkeys (and which unintentionally lets a user be identified by keystroke dynamics). The DOM has access to blocks of offline memory so that applications can be stable offline or when infrequently connected (and which is another vector for super-cookie tracking). It has access to viewports and peripherals for responsive layouts (which is more data for a browser signature that can easily allow user activity to be correlated). CSS needs read access to layout colors if it's going to be changing them dynamically (which means that those colored as recently-visited by the browser are know, which allows for history-based signatures).
Hell, we still have to live with all the ancient tracking methods and features like HTTP referer [sic], cookies, and user agent strings. And even though the World Wide Web was meant to be extensible, fail gracefully wherever possible, and be tolerant or varying levels of technological support, most modern websites will go out of their way to detect that you are not 100% compliant with their demands, then tell you to play by their rules or get off the net. Usually this is couched in the language of "reasonable compatibility testing" or "consistent experience", but most such sites will work perfectly well once you spoof some parameter, thus proving it wasn't necessary after all (for example, Gmail after spoofing javascript). Some I can only believe are deliberately architectured to fail: static pages which could be served entirely as native HTML, but instead decided to have just enough HTML to call Javascript to do all the real work by manipulating DOM to insert HTML into a mostly-blank structure (looking at you, Board Game Geek).
The DOM has demanded every piece of data available to the browser in the name of ever more byzantine applications, even though all but an insignificant portion of the web is still consumed in a page-like way. You can use NoScript and set Opera/Firefox/Chrome preferences until your blue in the face, but you will never reduce your tracking cross-section while the standards bodies insist on pushing these very broad, demanding features in the standards themselves.
Re: (Score:1)
Yes, we need to stop doing apps in the web browser, and start doing apps in actual applications. It's like the world has forgotten that the internet is accessible outside of the web browser.
The main issue preventing that is that OS security sucks. It should be possible to run a random application downloaded from the internet without giving that application access to all of my files and everything else I'm able to do on my computer, but for some reason we're stuck in the stone ages of computer security, wh
Cancel or Allow? (Score:2)
Yes, we need to stop doing apps in the web browser, and start doing apps in actual applications.
Applications for which platform? Good luck running a native application on Windows if it has not been ported to Windows, or on a Mac if it has not been ported to OS X.
A word processor can simply call an OS API to open a file, then get permission to access that file when you choose to open it.
Repetitive "Cancel or Allow?" dialogs for elevation to administrator is something for which Apple's Mac commercials used to satirize Microsoft [youtube.com]. And now you're proposing to show one every time a word processor opens a file. Heaven help you if you're running a compiler toolchain that may open hundreds of files when rebuilding a complex project.
Sandboxing policies can be hard to get right (Score:2)
I understand what you're talking about and have mentioned it in the past, using OLPC Bitfrost as an example. It's just that before such a system is put into place, policies need to be designed carefully so as not to break common productive scenarios in favor of over-optimizing for a non-technical home user who uses a device only view works created by others, not to create his own works.
The file open dialogue is the "allow" operation.
Would the permission through a file open dialog persist across closing and reopening an application? If not, the "Recent Fi
Re: (Score:3)
Kill either the percentage or the time part of the spec and it won't be nearly as specific.
And why the fuck is this shit in a markup language specification in the first place?
Re: (Score:1, Funny)
Because someone Need Such Ability. :)
A VM... (Score:2)
Probably the best fix for these shenanigans is a VM. Since the VM has no clue what battery status it is running on, nor CPU (especially if you use CPU masking), there is a lot less an advertiser can go on, especially if the VM is rolled back to a clean snapshot after each browsing session.
However, this does nothing against browser fingerprinting (actually nothing really does help here.)
Old Mozilla would have stopped this. (Score:5, Interesting)
This kind of shit makes me yearn for the days of what I'll call Old Mozilla. I'm talking about Mozilla like it was back in the early days of Phoenix/Firebird/Firefox, when providing a damn good browser was the most important thing. They wouldn't have stood for dumb functionality like this ending up in the browser. It's totally unnecessary, and totally out of place. In the days of Old Mozilla, that would have been apparent, and this functionality would never have gotten implemented in the first place. We wouldn't have to fuck around with the dom.battery.enabled config option.
But Modern Mozilla? They've shown us time and time again that they apparently don't give a flying fuck about providing a good browser experience. Firefox 4 and every release after it have been a massive clusterfuck or disaster of one sort or another. The usability of Firefox's UI is like shit in a urinal today. We've seen almost no visible improvement to Firefox's memory usage and performance under real-world usage as well (so fuck off with the useless, totally unrealistic "Are We Fast Yet?" pseudobenchmarks that don't tell the real story!). Then there has been all of the shit about ads and Pocket lately. And we can't forget about Firefox OS, one of the biggest and most wasteful software development failures we've seen in ages.
Each and every day I wish that Old Mozilla came back, or something close to it formed. Sorry, Pale Moon doesn't cut it. Vivaldi [vivaldi.com] is showing some potential, but it has its own problems.
Is it really too much to ask for Mozilla to go back to doing the right thing with Firefox? Is it really too much to ask for them to make Firefox about the users first and foremost? Is it really too much to ask for them to throw out stupid functionality, or just to avoid implementing it in the first place?
Re: (Score:2)
If the user can track a battery life remaining then the computer can too. That's one of the fundamental problems in making something that is designed to be tracked by one thing but not another.
Re: (Score:1)
But... but... but... but... (Score:3)
Re: (Score:2)
The EFF Coalition has just proposed a new Do Not Track standard.
The EFF is in some way associated with "Do Not Track"? Refresh me on this, please. Or do I just not get your joke?
Re: (Score:2)
See previous Slashdot post: http://tech.slashdot.org/story... [slashdot.org]
Re: (Score:1)
It's the next article down [slashdot.org] here on slashdot.
Re: (Score:2)
And they're getting some exercise & fresh air.
In the event that an actual certified & credentialled pediophiddlerist runs out from behind the nearest tree and tries to abduct them they might be sufficiently fleet to evade capture.
Re: (Score:2)
So it could stream lower quality video / audio that would take less battery to play is one thing that springs to mind. If a site monitored battery usage while streaming HD to your phone it could calculate if you had enough to juice left to finish watching.
Re:Facepalm. (Score:5, Insightful)
That's a determination that the device and/or user should make, not some website that doesn't know all the facts. This is the same type of thinking that led to some Youtube changes that piss me off. "We've detected that your connection is sub optimal so instead of buffering the video we've made the video entirely unwatchable."
Re: (Score:1)
Oh please. We can't even get web sites to offer two versions of the same video for web browsers with different codec support.
There needs to be a HTML/A specification similar to PDF/A: A limited, non-interactive subset of functionality. But with or without that, the battery API needs to be eliminated, not fixed, amended or corrected.
Re: (Score:2)
I'd rather have the ability to know the speed of the connection with a setting that the user could set himself to override this web-readable value.
The user is on a slow connection? Send regular DPI photos which are highly compressed, bandwidth is more important than quality.
The user is on a fast connection and I detect a HiDPI display? Send HiDPI photos that are compressed but preserved quality.
Want to preserve your monthly quota and/or load pages faster? Override this setting and tell websites you're on a
Re: (Score:3, Insightful)
Sounds like the ideal sort of thing to be able to disable (or provide a random response to) in the browser.
Everything your browser does that is different than other browsers can be used to fingerprint you, so sending a random response would be an identifiable trait to narrow the group they think you are in. Better to send nothing, assuming most people's browsers don't send anything, or whatever the response a desktop sends when asked for its battery level.
Re: (Score:2)
So they can show you ads for new batteries when they figure out it's wearing out?
Re: (Score:2)
Unless they detect an iPhone or iPad. Or almost any other device from the last few years.
The ability to replace batteries are gone, because thin devices.
Re: (Score:2)
I've noticed your iPhone battery is running flat, could I interest you in a battery case [mophie.com]?
Re: (Score:2)
Oh sure, let's make the phone even bigger and heavier...
Re: (Score:2)
Phones get bigger every year, it would be kind of like an upgrade!
Re: (Score:2)
Why would a website need to know how much battery I have left (maybe so it can send more and more-obnoxious ads to me if my battery will stand it.)
Or maybe the inverse... Maybe show a simpler page (no videos?) if the battery level is in a discharge / low state.
Re: (Score:2)
Why would a website need to know how much battery I have left (maybe so it can send more and more-obnoxious ads to me if my battery will stand it.)
Or maybe the inverse... Maybe show a simpler page (no videos?) if the battery level is in a discharge / low state.
That's not the inverse. It is the equivalent.
Re: (Score:2)
for html5 apps it's not that bad of a feature.
like, for firefox OS they need such a feature anyways so might just as well put it on the browser.
however, then they implemented it without rounding without thinking about it one bit.
Me (Score:1, Funny)
in firefox (Score:3, Informative)
Is story about that:
dom.battery.enabled false
Limited usefulness (Score:2)
It seems like this really is not useful for tracking you long-term.
But it could be useful for tracking a user in the short term if the API can give you charge/discharge rates along with capacity.
Still... I would think you are giving more away with simple meta information (headers, etc).
Re: (Score:2)
Re: (Score:2)
A lot of the things called "track you" aren't as much about tracking your physical location as about associating a particular session with another session as being the same person. This way, sites can correlate these unique identifiers and build a dossier about each user.
How the hell is this exposed by default? (Score:1)
And why, why, why is the DOM trusted to know this?
Re: (Score:2)
And why, why, why is the DOM trusted to know this?
Hipsters.
lower the reported sample rate (Score:5, Interesting)
| the estimated time in seconds that the battery will take to
| fully discharge, as well the remaining battery capacity
| expressed as a percentage. Those two numbers, taken together,
| can be in any one of around 14 million combinations, meaning
| that they operate as a potential ID number
okay — so why not decrease the provided resolution of the values?
i.e. time til battery discharges expressed in minutes instead of seconds,
and remaining battery capacity expressed to the nearest 5% -- this will
provide substantially less unique combinations to ID your battery, while
still being sufficiently useful enough for what the feature was intended.
2cents
jp
We need even less resolution than that (Score:1)
Give the "worst-case" time left rounded to the nearest 15 minutes, with some maximum ("more than 2 hours, but I won't tell you how much more").
By "worst case" I mean the amount of time if the device goes into "maximum power use" mode and stays there until it shuts off.
Oh, and to further prevent profiling, as the battery drains or charges have the "switch over point" to the next "reported" value be slightly off of "real." For example, if it's got 38 minutes left, it will report "30 minutes." But change it
Re: (Score:2)
Because it's the tip of the iceberg. If you make something that's designed to allow users to track their usage then it could be used to formulate an ID by a computer as well. Sure the combinations may be higher, but combined with your OS, Browser version, plugin list, screen resolution, language, ... snip ... remaining battery life, you end up with a pretty unique fingerprint without any individual item being very unique to you.
Re: lower the reported sample rate (Score:3)
Did anyone actually read the actual paper? They were only able to track Firefox browsers on Linux due to the precision of the battery level outputs. Their recommendation was to limit the precision to two significant digits, something a home and Opera were already doing, and something all of them do on every other OS. So this is only applicable to that 2% of PC users running Linux desktops with their tin foil hats. For the vast majority of us, THIS DOESNT WORK!
No, not the battery (Score:2)
Re: (Score:2)
It is useful for HTML5 local applications. The problem with JavaScript is that variables can be transmitted without a whole lot of warning to the user(s). If we had something akin to Perl's Taint Mode - something that prevents you from using or affecting 'outside' data sources without your explicit cleaning/permission in JavaScript, we'd be a whole lot further.
Re: (Score:2)
Can you expound. I don't understand your suggestion.
Re: (Score:2)
Look up Perl Taint Mode. It basically throws up an error if you have not properly cleaned your variables that are sourced from outside (eg. user input) and in turn affect outside sources (eg. SQL query).
If we had something similar for JavaScript where an outside variable or personal data objects were 'tainted' and required user permissions and developer cleanup before they went back out. That way the system can't leak data. Something similar to the pop-up box on iOS (or it's lesser/broken version on Android
Re: (Score:2)
It seems like a difficult system to put together. The odds are there are going to be holes. But, far more importantly, it seems these could be done when the API call is made, no need to track data taint.
Android apps ask for freaking every permission. That's the real concern. How do we stop asshats from wanting it all?
We're actually better off (Score:2)
We used to have applications run locally. They used to have a lot more freedom - any and all apps could know exactly who you are and what your computer's UUID was, not only how your battery's doing. Today most of what you use - the obvious examples being your mail and to a lesser extent office suite - is at least sandboxed inside your browser.
This is not to say there hasn't been a rise in tracking, but the story just got me thinking that maybe it's a good thing it's being done in a browser.
(And you should b
Re: (Score:2)
Maybe the OS didn't have a UUID but pretty much all of the hardware did. Your BIOS and CPU's have been able to return serial numbers for a very long time. The generic CPUID came into existence around the 80486 but before that there were almost always methods to return said information. I remember even on my 80286, there were tools that could read unique BIOS information.
Re: (Score:2)
Except web apps aren't primarily replacing other apps. They are replacing static content. It's like when they allowed people to put code in PDFs. Sure, I suppoe it was somewhat sandboxed and better than a special purpose EXE, but the alternative that is supplanted really was a static PDF with form information.
FireFox mitigation: dom.battery.enabled (Score:1)
Set this to false in about:config.
use much lower resolution data (Score:3)
Re: (Score:2)
Re: (Score:2)
Just the tip of the iceberg (Score:2)
There's already plenty of info that websitse can use to identify you - https://panopticlick.eff.org/ [eff.org]
Firefox fix. (Score:1)
Tor browser defaults to false (Score:2)
Just a PSA, TOR browser defaults to false.
Re: (Score:2)
Err, the about:config -> dom.battery setting. True in firefox, false in TOR.