Your battery status may be used to track you online
theguardian.com
theguardian.com
Now back to the real world, where many sites I visit peg my desktop CPU trying to serve so many ads and so much tracking to squeeze every possible cent of profitability from my visit. If there's a war against ad-blockers, did we think these sites would relent and say, oh, OK, I see you might be low on battery, I'll serve just the content you want this time?!
No, this is a purely client-side concern, with plenty of purely client-side mitigation which can be put into place. That the protocol actually specified 14m degrees of granularity -- from what at the very least ought to have been a binary setting -- makes me wonder if the point wasn't user tracking all along.
Missing from the article: Do all user agents actually provide this information in request headers? Is there a way to shut it off?
I can't see any reason to make use of the battery status server-side. But, there's also no way to prevent the information from being sent, once you make it available to javascript code on the device. If the standard api didn't send it, then you'd just see ad-hoc apis gathering the data locally and sending it.
Maybe I request low mode because...
I hope you serve me less crappy ads
I haven't bought a new phone in 3 years
I am running other apps which need more CPU
I find too much interactivity distracting or confusing
I just want to read black text on a white background
I hate your website, but need to visit it for some reason anyway
...
I have full battery, but I need to conserve it
I have low battery
Doesn't the client (laptop, phone, etc) does this already?
Often, that's probably just fine. But if I'm developing an app and I have a requirement to save state before my app gets shut down due to power failure, this api will allow me to do that. It's the equivalent to a drive flushing any writes before shutting down; normally they'd get flushed sooner or later, but if you have to shut down NOW, you'd better flush now too while you can.
You would avoid loosing data, and regarding user experience, also avoid a slower performance of your app (and perhaps complaining about it?), and also seeing your device shutting down itself with your app screen running in background (which is pretty lame).
As a developer, trying to implement requirements set by a product designer/owner who thinks saving the data is critical even if the user doesn't cooperate, the api is useful to have.
If you're really worried about your battery running low and working with critical data, removing the browser overhead which is draining you battery should be one of the first things to do.
Surely it's possible for JavaScript engines to either (a) optionally prevent code from accessing this; or (b) return random nonsense, or even just a single fixed static value (for every instance of the engine anywhere).
A security permission, or config setting, can/should be used to prevent access to the api that returns the battery level. But once access is enabled, there's no way to prevent the code from getting the level (which is just a number) and sending it to a server (which is just calling an ajax request with a numeric argument.)
You could also expose an offline-only option somewhere in your application. A user might want to do this if they are in an area with marginal coverage (e.g., there is a connection, but it's basically useless) or roaming, etc.
Don't tell Steve, but if I want to save battery, I swipe closed the browser. If I sign up for rain notifications, I better get my darn rain notification!
You're constructing an obvious straw-man here. It's easy to imagine scenarios where a 'low power mode' would be in the interest of the site and it's visitors. Especially when we're talking 'apps' rather than 'content sites' - there's plenty of desirable but non-essential functionality that could be disabled and for web apps intended for mobile use this could potentially be a great differentiator.
(If your answer is 'there are no non-essential animations' then you haven't thought about it for long enough)
Again, there's a litany of things a device can do to reduce power usage itself. Native apps and websites alike should absolutely consider their power profile and reduce it if possible.
The idea which I think is terrible is making this part of unrestricted Web API as 14m possible states. But even as a binary state I think very few apps have the resources to design, develop, and test across multiple devices for dynamically adjusting power consumption.
1. Simple example - any app that does polling for any reason can reduce the polling interval.
2. Interactive WebGL charts could be replaced with static bitmaps
3. Background spell or syntax checking could be disabled and made 'on demand'
4. Chatty network features could be disabled or cut back.
None of the above need to significantly increase development or testing costs. They are quick examples I pulled out of thin air. If we discussed specific applications I'm sure I could suggest more.
Non-browser apps already can do all this and often do. (and I wish they would do it more often)
If I'm low on battery and choose to open that webpage, and now the WebGL charts are static bitmaps, my first reaction is going to be WTF. Now I want a button synonymous with 'Show Desktop Site' -- I guess we could label it the 'Stop Fucking With Me' button.
All code should be aware of the CPU that it is consuming. More efficient code is not just better for battery, but also likely more responsive and better for multitasking. So the question becomes, not how do we reduce CPU and possibly even improve UX, but in what cases would we make the CPU requirement dynamic, and when/where might the trade-offs be made to ultimately improve the user experience.
So first is Page Visibility, as discussed. The very next area where I would consider making CPU usage dynamic is not a battery state, but rather it's an overall device performance adjustment. If someone visits with an iPhone 4 versus a 6s, they have dramatically different amounts of compute available. I would consider investing in dynamic CPU consumption based on a device performance flag a lot sooner than I would do it based on remaining charge, because I think it would improve the UX for a large percentage of users every time they used the site. It's also a static setting from the perspective of the device owner, so they are not seeing changing UX on their device potentially from one moment to the next.
> None of the above need to significantly increase development or testing costs.
I can only offer my opinion based on my experience, but trying to alter functionality to reduce CPU load based on dynamically changing battery metrics across a pool of devices which may behave inconsistently... this is really not simple to code and test and maintain over time. We have a hard enough time just trying to efficiently serve device-specific assets (like lower res images to mobile) and that's based on a static/fixed user-agent string, not a dynamic header, and sites get it wrong so often that user-agents added a special button to try to turn it off!
The problem is the web is not a very nice place, and (like the ad networks mentioned by the OP) third parties beyond my control often get to run fully-scoped Javascript on my browser. OTOH, at least I get to choose which apps are installed on my home screen.
So I wonder if instead of all the prompts we have today;
Would you like to allow this page to see your location?
Would you like to allow this page to use your microphone?
Would you like to allow this page to use your camera?
Would you like to allow this page to send notifications?
Would you like to allow this page to view your battery status?
There certainly could be use cases for having a comprehensive Web API for charging status, battery capacity, remaining charge, and time till charged. Someone will find this useful. But simply adding it and having it on-by-default is not without tradeoffs...
As Web API matures, there is a plethora of APIs which have privacy concerns, some slight, some grave. We need to communicate to users these trade-offs in some usable way, and give them some control over them. Some APIs definitely need their own unique Yes/No prompt, like turning on my camera/mic, but I wonder if there's a middle-ground of a group of APIs which should be restricted all behind a single setting, akin to favoriting or 'staring' the site gives just that first-party domain access to those APIs. Maybe we even call it "Native Mode", then we put choice back in the hands of the user and we can expose APIs with impunity.
I assume it is intended for mobile apps written in-browser that are intended to run in some sort of kiosk mode so obscure the OS's default battery display.
I see two scenarios here:
1. The usual cock-up of the API guys not being the privacy/security guys and managers being unable to find common ground between the two.
2. The pressure to make HTML5 be an "app killer" and making sure devs have everything they need to write HTML5 web apps that can compete with native apps. Security/privacy becomes a browser problem, and if the browser guys screw up (see 1.) then too bad.
Seems to me, a simple middle ground of reporting a less granular battery value would have made sense. Very Low, Low, Medium, High, Very High would probably take care of it. You can probably just shoe-horn this in right now by just assigning a number to each condition and never telling websites the real number (or randomizing it a bit).
The benefit is that the user doesn't need an additional setting for each potential web app to set the threshold for a low power mode, it's all done once at the OS level.
... I suspect many wouldn't understand the tracking implications, and even many who can understand it wouldn't immediately make the connection.
That said, this isn't the first such thing used to identify users. Other things like resolution, browser, extensions, etc, can be used to make a nearly unique fingerprint and this has been known for years. Search "browser fingerprint" and you'll find many pages on the subject.
It is is similar in any other case of low resources. 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.).
I searched Chrome settings for "battery" and found nothing. I did find this article with instructions for turning it off in Firefox: https://www.hackread.com/smartphone-laptop-battery-invading-...
I'm not opposed to the concept of a battery API, but as others have commented, it would be just as useful with a lot less granularity.
I hope some day soon your mobile OS let's you choose to restrict the device information available to sites and apps. It really ought to be a user's choice whether to make the tradeoff between providing more info in exchange for supposedly better functionality or not.
Plus ad blocking and "social button" blocking, as a preventive measure for this kind of issue.
The Web is the new Wild West.
Becoming famous and staying anonymous are diametrically opposed.
It would be sort of like setting your browser's user-agent to a unique identifier that you never change, but then never actually using the browser for anything. It's not the unique ID that hides you, it's the fact that you never use it.
You might argue that this sort of stuff should only be available to native applications, that browsers should not attempt to replace native apps or even recreate an OS within themselves (something Chrome is often criticized for). The thing is, my battery monitor has native apps and yet users have been asking for web-based clients, be it browser extensions or plain web pages. And with some platforms loading a website or installing an extension has much less friction than installing a native app.
Sure, extensions can have access to a lot of stuff webpages don't have. But I would rather use standardized APIs that work across all browsers and are well documented in more than one website, than have to rewrite my extension for each browser and not have it work on plain old pages.
If the battery API was made to work like the location one I think everyone would be happy - users are informed and in control, developers can still offer features based on it, and it raises red flags when it needs to ("why is this advert asking about my battery status?").
navigator.getBattery().then(function(a) {console.log(a);})
This lets sites who want to do "real things" with battery levels have access, without it being available "for free" (prompt is annoying).
My guess is this is just another part of the attempt to move desktop features to the web browsers so that people don't have to write actual applications. Personally, I don't like this trend.
For the ideologically inclined, it’s also about disintermediating the relationship between users and developers. Web sites don’t need an app store.
> “Some companies may be analysing the possibility of monetising the access to battery levels,” he writes. “When battery is running low, people might be prone to some – otherwise different – decisions. In such circumstances, users will agree to pay more for a service.”
That describes a scarily large portion of all web stuff.
Web applications served over HTTP, on the other hand...
Mozilla have it as part of their mission to make technology open and accessible (insert DRM debate here). Native apps have been thrown behind the app store “walled garden.” So, they want to make it possible to create rich apps over HTTP.
Thus, you find things like this available to web pages.
Here's my result:
Your browser fingerprint appears to be unique among the 119,205 tested so far.
Privacy is great...
Why should we allow companies recording other features that can identify us?
(btw, I don't think this should be a technical debate)