How a battery became an identifier
The 2015 research showed the readout combined level (e.g. 0.57) with chargingTime/dischargingTime in seconds, giving roughly 14 million combinations at any instant. Two sites reading the API within a few seconds saw the same tuple, letting them re-identify and link a user even across cookie clears for that short window. Firefox removed the API; Chrome restricted it to secure contexts and coarsened values. The episode is now a standard teaching example of unintended fingerprinting surface.
The bot-detection angle
For anti-bot systems the battery readout is a coherence check. A server-hosted headless browser has no battery, so the API is absent or reports a permanently full, charging state. A laptop UA that reports no battery, or a battery stuck at exactly 1.0/charging forever, is mildly suspicious and feeds a lie-detection score alongside stronger signals. It is rarely decisive alone, but it is cheap to read and contributes to the overall picture.
Current status and how to handle it
The Battery Status API has been walked back since its 2012 debut: Firefox removed it outright, and Chrome restricts it (notably gating it behind secure contexts and reducing its precision). That history matters for scraping because the API's presence or absence is now itself a fingerprint surface — a browser claiming to be current Firefox while still exposing navigator.getBattery() is contradicting itself, and a Chrome profile returning suspiciously round values (exactly 100%, charging, infinite time) looks synthetic.
The right move is not to invent battery values but to match the API surface to the browser you claim to be: expose it only where that browser version really does, and let the values reflect a plausible device. Patched browsers such as Camoufox keep these capability surfaces aligned with the reported identity, which is more robust than overriding getBattery() on top of a stock headless build.