Does your browser know your battery status? You bet it does. Let's talk about that.

HTML5 keeps adding more and more features to its lineup and I just can't keep up as quickly as I'd like. Many of those features are being targeted towards mobile devices, as these days everyone is trying to go mobile first. One of the more interesting features that just recently made headlines was the Battery Status API.This one is new to me, as I'm sure many other web developers. Which means it's still only implemented in a few browsers as it isn't an official specification just yet.

So today I'll be going over just what this API is, what it can do, and just how safe it is, from a privacy point of view. And whether it's actually a useful tool or not.

What it is

The Battery Status API is just what its name implies. It's an API used to get your local battery information in your browser from either your phone or your desktop. This includes your current battery percentage, whether your device is charging or not and how much time is left to finish charging in seconds. That last one is more important than it sounds actually, and I'll get to that down below. It is currently not an official specification, but it is in the Candidate Recommendation phase. A few browsers already support it however.

Its implied purpose is to notify websites when a users battery level is low so that the websites can respond accordingly with a more battery friendly version of itself. Or even more importantly, some websites have long form processes, such as survey sites. By being able to check the users battery, they could in turn detect if the battery was low enough, to save the users content either locally or in some external storage.

This of course, makes the most sense in a mobile browser scenario. As having a laptop nowdays not plugged in to a wall is ludicrous. And the "low battery -> store in local storage" for sure makes alot of sense.

How does it work

The API is implemented through the window.navigator object. There is a new method that has been implemented navigator.getBattery() which returns a battery promise.

navigator.getBattery().then(funcRef);

This in turns resolves into a BatteryManager object which provides several new events that can be fired to gather this battery info. Some of those methods include:

• chargingchange
• levelchange
• chargingtimechange
• dischargingtimechange

Here is your battery info for example. And no, I am not keeping track of your battery level, as that would take some time to implement and there is absolutely no benefit to this blog.

Which for sure brings me to my next point.

Can it be used for tracking

Well, yes, and no. Recently many news site reported on this new feature of browsers, and claimed that it can be used to track your actions online. And that's not quite 100% true really. First of all, if the cookies, IP Address, tracking pixels and user-agent/browser info aren't enough to track you, then you're probably doing an okay job and this battery thing won't make a dent. Mainly because tracking in this method would be a last case scenario after having exhausted the previous methods that I've mentioned. And secondly, websites would need to implement this technology onto their websites as well, which I don't see many doing for this slight edge case.

So let's take a quick look at how sites would probably use your battery info to track your online footprint. Battery info is course limited in the amount of data that it can generate based on its nature. You have your battery level, such as 80%, 90%, etc. You have the amount of time that's left to charge, which is a calculation based on your particular battery and power usage. This number is the troublesome value because it is very specific to a particular user as it is specified in seconds.

Combining it with the battery level, we end up with a more unique identifier that could technically be used to track a user across multiple pages for a temporary amount of time. However, you're of course going to get collisions, as these numbers are very finite. Assuming a max value of 9999 seconds for discharge, our best case scenario would yield 1 million unique values.

80-2523 seconds

And there's another overlooked tracking design flaw as well. The battery values only update when the battery level updates, which means that technically, tracking would only be possible during these small windows. And if your battery is crappy and drops fast, then you have even less to worry about.

It's a work in progress

And remember that this standard is still a work in progress and can change at any moment, or even be deprecated at any moment. For the time being however, it is being supported by the major browsers, in some shape way or form. It is also is useful despite the negative publicity that it has on the interwebs by non technical people. Am I going to be implementing it anytime soon though? Probably not.

Its not that it's a bad feature, but more that it is really niche one. It definitely applies to websites with longer sessions, such as survey sites, or very long registration forms. Other than these scenarios, I personally wouldn't know how to render a "battery friendly" website. Perhaps I could remove ads or resource heavy videos, but I can't picture larger ad-based websites doing so. And if privacy becomes a concern down the line, perhaps a more generic approach would be best, such as a ranking system given to battery status.

Overall, not a bad feature however. And I'm sure as the specification gets closer to full release time, it will address any and all concerns that it is currently running into.