W3C's bright idea turned your battery into a SNITCH for websites Website owners keen on tracking netizens, but thwarted by AdBlock or similar, could instead look at the battery charge in people's devices to identify them. How so? A feature the W3C added to HTML5 that lets a website interrogate the state of a visitor's battery. According to security boffins writing for the International …
HTML pages have morphed into apps which have access to a ton of sensitive local system state.
Therefore at minimum, every web page needs to be granted explicit permissions for anything like this. It happens already when a web page asks for your location information.
But the fundamental problem is the web is full of active content which is executed automatically, *and* users are expecting to be able to connect to random sites safely, *and* not only the site owners may not be trustworthy, the ad networks they use certainly aren't. (i.e. nowadays strangers on the Internet can simply *pay* to have their content injected into other people's web pages)
Maybe Opera Mini had the right idea: render all pages in the cloud, and just send back bitmaps to be displayed locally.
"HTML pages have morphed into apps which have access to a ton of sensitive local system state...*and* users are expecting to be able to connect to random sites safely,..."
Given that, it's remarkably safe. Most of the holes come from legacy plugins. *cough* Flash *cough*
It's almost as if there's a security dividend from forcing people to use an interpreted language with no low-level access to hardware where every API has been scrutinised by a committee.
I was going to suggest three levels: "Good" (mains power or battery nearly full), "Poor" (less than 30% or one hour remaining) and "Average" for all other cases. But however you slice it, they clearly don't need nearly as much information as this thing gives them. I can't seriously imagine any website using that much detail for the intended purpose. In fact, given how much they love to shove crap in your face nowadays skeptical that any sites would use it for the intended purpose, at all, ever.
Power users. Nice.
It makes you wonder just what other information is available for a website to slurp. Websites should be able to determine the type of device*, windows size (not even the current screen resolution), browser agent and, should you allow it, what addons you have installed.
That's it.
Yes, something about modern, rich experiences and web 2.0 and so forth, but none of that requires knowing more than the above. Anything more is being used purely for information gathering.
* - Retrievable device type information should be limited to knowing whether it is a computer or a tablet, the latter including phones but being considered one type of device as some tablets are small and some phones large.
"Somebody needs to give W3C a slap, then the browsers that actually implemented this."
Those responsible at W3C and on the browser development teams should be slapped with the browsers.
The browsers themselves being installed on the chunkiest laptop available (a laptop being the most practical for the purpose, I think).
This post has been deleted by its author
Personally I’m quite happy with the W3c, we need web standards more than ever, I pretty confident to speak for everyone when I say no one likes to write different version of their javascript just to support different make of browsers or (versions of a same browser).
In essence the battery API is a good idea, for those of us who attend web consortium conferences regularly,they are many use cases and scenarios where the API contribute to a better user experience:
when running out of battery one may still needs to access a MINIMALISTIC (= ads free, no animated gif, superfluous information ) version of a web site, think of a map, only to display routes and directions instead of the usual crap (locations of mcdonalds, starbucks, etc...)
But as it's always the case with great ideas there are always unforeseen weaknesses... This exploit is sadly one of them, so kudos to the German and Belgian team for they contribution to make a safer web.
Now common sense... The problem with common sense is that:
1) it's actually not that common, yeah it may sound bizarre but really it's not
2) it's cultural, regional, etc.. for example it's common sense in the US to drive on the right of the road
3) It's only common until proven to be a utterly wrong (cf. flat earth, geocentrism, etc...)
Good day
..."when running out of battery one may still needs to access a MINIMALISTIC (= ads free, no animated gif, superfluous information ) version of a web site"...
Orrrrrrr... a MINIMALISTIC (= ads free, no animated gif, superfluous information ) version of a web site all along might stop the user running low on battery power in the first place!
The website can then reinstantiate users' cookies and other client side identifiers, a method known as respawning," the paper continues.
And if they guess wrong they will have planted the info on the wrong PC and they will ultimately be confusing and screwing themselves. There is no guarantee they will get it right, a lot of likelihood they won't, so few cases where it would work as intended.
It sounds to me like guessing who is knocking on the door by the style of the knock. That works a lot of the time with few people knocking with a consistent knocking style but falls to pieces when scaled.
" if a server could detect a user's battery state, it could dish out a lighter, CPU-friendly version of a page for someone with a low charge remaining. "
As if preparing a lighter (read: minimal ad or less data slurping) version of their page was going to be the end result of access to battery level by most websites.
People might spoof their battery state to cheat them out of their ad revenue or they'd be deprived of their 'pound of flesh/data'.
That is as 1980s_coder points out, the alternate page is at all readable to the user in a flustered panic.
The more than likely response would be another pop-up with 'Buy Quick' before your battery runs out or 'Your battery is running out, Do you want to search for recharging points?', which would engage location tracking and more info slurping.
No, tear this useless extra appendix out of the specification or lock it out in browser settings at the users discretion.
Have an upvote for killing with fire. I'd like to add that the folks who thought this was a good idea should also be cured of their poor thinking by fire.
I trust W3C had a valid reason why they chose to facilitate remote access to local data over local users telling the remote site they want the low-power version of a webpage.
The more food scares of "Sugar/Beer/Bread/Butter/Veg Spread/Ready Meals/Wine/Cake/Fast Food are bad...then good...then bad!"
Means I just turn off all the more.
I'm getting to the point of IT security whereby I'll worry about something if I know it's happening. Otherwise...just sod off!
http://www.w3.org/TR/battery-status
"The Battery Status API can be used to defer or scale back work when the device is not charging in or is low on battery. An archetype of an advanced web application, a web-based email client, may check the server for new email every few seconds if the device is charging, but do so less frequently if the device is not charging or is low on battery. Another example is a web-based word processor which could monitor the battery level and save changes before the battery runs out to prevent data loss."
That seems reasonable; no one wants a Windows 10 update to start just as a battery is going flat, and, just as it would be nice if local apps could take account of battery condition, why not the same for cloudy-based apps?
As long as there's an 'off switch' client-side or a means to override what is sent I don't see there's really a problem.
This post has been deleted by its author
This post has been deleted by its author
"That seems reasonable; no one wants a Windows 10 update to start just as a battery is going flat, and, just as it would be nice if local apps could take account of battery condition, why not the same for cloudy-based apps?"
The approach taken is dumb for the following reasons:
1) Not all batteries are made equal, so a remote application has no idea how to interpret the battery information.
2) The remote application has no visibility over the user's usage patterns or other applications running locally and can't actually predict them as well as the user can.
3) It's likely that users will have no control or visibility over how a website reacts to the battery info, their web browsing session will change on the hoof without warning.
4) The remote application has no --ing idea how power intensive it is to render a page - so how the fuck can it optimise for it ? Surely the browser is best placed to understand this - there's no need or benefit in offloading this to the remote servers or some ropey bit of code running in a Javascript sandbox.
5) There is a really simple way to accomplish the same goal of power saving without changing anything: Have the websites provide a "low-power" version of themselves and let the user navigate to it using a bog standard link. If users care enough about low-power they'll find the link and even better they will be in control.
Because it's such a bad fit for the problem at hand I suspect that automatically pushing low-power webpages isn't the main goal behind this particular piece of crap.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
