Battery and Sensor Data as an Identifier: How Fingerprinting Sees Your Device's Physical State

Why battery level matters to a fingerprint script

Most people assume fingerprinting is about screen resolution, fonts, and canvas rendering. Those are the famous ones. But the Battery Status API and device sensor APIs are a quieter piece of the puzzle, and they matter for a different reason: they don’t identify you directly, they help correlate sessions over time and catch automation that never bothered to fake them.

The Battery Status API, when exposed, returns four values: charging state, charging time, discharging time, and level (a float between 0 and 1). On its own that looks useless for tracking. A battery at 73% tells a script almost nothing about who you are. But researchers flagged years ago that the combination of level and the two time estimates can produce a value specific enough, updating frequently enough, to link requests from the same device across origins within a short window. That’s why most browsers pulled public access to the API or gated it hard. Chrome still exposes it, Firefox and Safari largely don’t anymore on desktop.

Device sensors work differently. DeviceMotionEvent and DeviceOrientationEvent expose accelerometer, gyroscope, and sometimes magnetometer readings. On mobile these are legitimately useful for things like tilt-to-scroll games or AR features, which is why they still get requested through a permission prompt in most modern mobile browsers. On desktop, a real human sitting at a desk with a real laptop or monitor never generates accelerometer noise, because there’s no accelerometer to poll. A profile that claims to be “iPhone Safari” but returns null or a suspiciously flat, silent motion stream when the site asks for devicemotion is telling on itself.

What a script is actually testing for

When you dig into how anti-fraud and anti-bot vendors use this, it comes down to three checks, not one:

Presence. Does the API exist at all, and does it match the claimed platform. A profile spoofed as Android Chrome should have navigator.getBattery in Chrome-flavored builds and should respond to sensor permission requests the way a real Android device does. A desktop automation stack pretending to be mobile often just doesn’t have these APIs wired up, so calling them throws or returns undefined where a real device would return a promise or a permission prompt.

Plausibility of values. A battery discharging from 100% to 40% in six minutes is not physically realistic for almost any device. A gyroscope reading that never varies by more than a rounding error, frame after frame, reads as synthetic because real hardware sensors are noisy, they jitter even when the phone is sitting still on a table. Scripts that fake sensor data by returning a static or slowly-ramping value are easy to catch because real MEMS sensors don’t behave that cleanly.

Consistency over the session. This is the correlation angle. If a site reads your battery level at the start of a session and again ninety seconds later, the delta should be small and directionally sane (draining slowly while unplugged, flat or rising while charging). If a farm is running the same browser profile across two different “accounts” but both report identical charging-time-remaining values down to the second, that’s a tell those two sessions share an underlying machine or a copy-pasted fingerprint template, not two different people.

Why this matters more for mobile-emulating profiles

If you’re running desktop-based anti-detect profiles that claim to be desktop browsers, battery and sensor exposure is a smaller concern, since real desktops mostly don’t have gyroscopes and modern browsers already hide or strip battery precision by default. The exposure that matters is when a profile is built to look mobile, because that’s when the absence of sensor data becomes the anomaly rather than the norm.

I’ve run this test directly: load a page that calls navigator.getBattery() and requests motion/orientation permission, using a profile configured as a mobile Safari or mobile Chrome user agent inside Multilogin, GoLogin, Kameleo, AdsPower, and Dolphin Anty, and watch what actually comes back in devtools. The honest result is mixed across tools and versions. Some emit a plausible battery object with a level that isn’t pinned at exactly 1.0 or exactly 0.5 (both of which look synthetic to a detection script). Others leave the API present but returning static, unchanging values across reloads, which is arguably worse than not having it at all, because a static fingerprint is itself a linkable signal. None of the tools I’ve tested generate genuinely noisy accelerometer output the way a phone resting on a desk does, because that requires simulating physical sensor jitter, not just spoofing a user agent string, and it’s a much harder engineering problem than swapping a canvas hash.

This is worth being blunt about: spoofing battery and sensor APIs convincingly is one of the weaker areas across the anti-detect category generally, not a specific product failure. It’s a smaller attack surface than canvas or WebGL fingerprinting, so it gets less engineering attention, and real accelerometer data is genuinely hard to fake believably without emulating actual hardware.

What this does and doesn’t mean for your setup

None of this makes any anti-detect browser undetectable or unbannable, and no test I run changes that. What it means practically is narrower: battery and sensor checks are one input among dozens that a fraud-scoring system weighs, usually alongside proxy quality, canvas and WebGL hashes, font lists, and behavioral timing. A mismatch here rarely gets a session flagged on its own. It’s more likely to nudge a risk score up, which then combines with other signals (a residential-labeled proxy that’s actually a datacenter block, a fresh device fingerprint with no history, unnatural click timing) to trigger a manual review or a soft block.

If you’re building profiles for mobile-context multi-accounting, it’s worth checking what your tool actually returns for these APIs rather than assuming “mobile emulation” covers it. Open devtools, run the calls yourself, and see if the numbers look like something a real phone would produce or like a template that never changes. That’s a five-minute check that tells you more than any vendor’s feature list.

The bigger point, and one I keep coming back to on the channel: fingerprint spoofing is never a single fix. Getting battery and sensor output right doesn’t matter if your proxy is a flagged datacenter IP, and a perfect proxy doesn’t matter if your canvas hash is identical across fifty “different” accounts. Treat this as one line item in a much longer checklist, not the thing that decides whether an account survives.

For breakdowns of how the other fingerprint surfaces work, and hands-on tests of how Multilogin, GoLogin, Kameleo, AdsPower, and Dolphin Anty actually perform against them, head back to the homepage.

Get new guides and videos first — join the Telegram channel.