Summary

  • The Battery Status API was designed to let web applications adapt work to the device's power state. A mail client might poll less on battery; a word processor might save before the machine dies.
  • Precise level and time readings can also help distinguish a device. W3C's records show the privacy concern entering the working group's discussion, followed by advice to avoid high precision, optional permission and obfuscation, and later a secure-context and Permissions Policy boundary.

The laptop battery is fading. An email client could stop knocking on its server every few seconds. A document editor could save while there is still enough charge to finish the sentence. The 2016 W3C proposal gives both examples. Neither asks the webpage to be a hero. It asks the browser for a simple clue so the application can do a little less work, or save the work already done. The battery might prefer the first option; the writer probably prefers the second.

The first public design was more like a tap on the shoulder than a modern promise. In April 2011, W3C pulled battery-status events out of a broader System Information API. Its BatteryStatusEvent considered whether the machine used a battery, whether it was charging, a level from zero to 100 and estimated remaining time in seconds. The draft still sought strong uses for some of those fields. Its example listener simply logged the level. It had described the gauge; it had not yet proved how much of the gauge every page deserved.

The application use case was real. When an inbox is open all afternoon, a difference in polling frequency is not merely decorative. A page that knows the plug is out can postpone animation or network chatter; a page that knows the charge is low can prioritize saving. But a number precise enough to be operationally useful can also be a clue. A percentage, a charging flag and a changing time estimate can form a small moving profile. The webpage did not need to steal an address book to learn something distinctive about the device on the desk.

That concern reached the people writing the standard. In a July 2015 W3C working-group message, chair Frederick Hirsch passed along concrete privacy proposals after original research on battery readings: call out high-precision fingerprinting, consider asking for access, and make use of the API visible to users. It is a telling moment. An interface introduced to conserve resources had created a new resource for anyone trying to recognize a visitor. The gauge had acquired an audience it never asked for.

The March 2016 Proposed Recommendation put the issue into the specification's privacy section. Browsers should avoid high-precision readouts; they may ask permission and may obscure values. The interface had become navigator.getBattery(), returning a BatteryManager with charging state, level, charging time and discharging time. If a browser cannot report the real state, it can return defaults that look fully charged and plugged in. That choice also blocks an ugly fallback: a site should not be able to punish a user with worse performance merely because the browser withholds the battery reading. A gauge that says “full” may sometimes be a privacy curtain, not a triumphant battery.

By the October 2024 W3C draft, the boundary was drawn with more browser machinery. getBattery() belongs in a secure context. The battery Permissions Policy feature defaults to 'self'; a document not allowed to use it gets a NotAllowedError. The warning against exposing highly precise readings remains. The specification still permits a browser to ask permission or obfuscate the values. None of these details gives a website a universal right to inspect the laptop's remaining seconds. They identify where the browser can say no, or answer less exactly.

The W3C publication history runs from 2011 drafts through the 2016 recommendation-track work and 2024 revisions. Those are dates on specifications, not a claim that every browser exposed the same battery data at every point. The deeper history is a design correction. The web asked for a power hint. It learned that a hint can also be a handle for recognition, especially when the instrument reports it with engineer-grade precision.

The laptop still needs to save the document before it dies. The page can still choose to be considerate. It just does not need a stopwatch, a magnifying glass and a detailed inventory of the battery's last breaths to do so.