Permissions API Fingerprinting: What Permission States Reveal

The Permissions API lets a page ask what a user has already decided about notifications, geolocation, the camera, and more, all without triggering a single prompt. Those answers, and the mere presence or absence of the underlying features, leak configuration and expose automation with surprising reliability.

Querying state without prompting

navigator.permissions.query({ name: 'notifications' }) returns a status object whose state is granted, denied, or prompt. The same works for geolocation, camera, microphone, push, and others depending on the browser. Nothing is shown to the user; the call simply reports the stored decision.

Each state is a small piece of entropy. More importantly, the pattern across many permissions describes how a browser is configured, and configured human browsers differ systematically from fresh automation instances.

The classic headless tell

One well-known contradiction has caught headless Chrome for years. In some automated configurations, Notification.permission reports denied while navigator.permissions.query({ name: 'notifications' }) reports prompt. On a genuine browser these two views of the same setting agree. The mismatch is a direct artifact of headless operation.

This is emblematic of the whole category: the Permissions API gives you a second, independent view of settings that other APIs also expose, and automation frequently fails to keep the two views consistent.

Sensor availability as a signal

Beyond stored permissions, the presence of sensor and capability APIs describes the device class:

• Motion and orientation: DeviceMotionEvent and DeviceOrientationEvent normally exist on mobile and are absent or inert on desktop. A desktop user agent that exposes working motion sensors, or a mobile one that does not, is contradictory.
• Ambient and proximity: generally absent on desktop, restricted on modern mobile.
• Media devices: navigator.mediaDevices.enumerateDevices() reports how many cameras, microphones, and speakers exist, in bucketed form. A device reporting zero of all three often indicates a server or headless environment.
• Bluetooth, USB, and serial APIs: their presence and permission states vary by browser and platform.

None of these is decisive alone, but together they paint a device-class picture that should agree with the user agent, touch capability, and screen metrics.

Why consistency is the real signal

The Permissions and sensor surfaces are easy to override individually and hard to keep coherent. A spoofing stack might set a mobile user agent but forget to enable motion sensors, or grant camera permission on a headless instance that has no camera to grant it on. Prynt scores the joint picture:

• Do sensor APIs match the claimed device class?
• Do permission states agree with the other APIs that expose the same settings?
• Does media-device availability fit a real user rather than a bare server?

Because Prynt correlates these client signals server-side against network and behavioral data, an isolated override does not slip through; it has to be consistent with everything else Prynt observes. This is the same layered reasoning behind Prynt’s bot detection, where permission anomalies join dozens of other signals to separate real browsers from automation.

Privacy-conscious use

Permission states describe user choices, so Prynt treats them as configuration and consistency features rather than as a way to profile behavior. It queries only what contributes to distinguishing real devices from automation, never triggers prompts, and does not rely on APIs a browser has restricted. As vendors continue locking down sensor access, Prynt favors signals that remain appropriately available.

Combining permission and interaction signals

Permission states become even sharper when paired with how they were reached. A device where camera and microphone are both granted, media enumeration reports real hardware, and motion sensors are active and producing plausible values presents a coherent human picture. A headless instance that grants permissions programmatically but exposes no working sensors and enumerates zero media devices does not. The value is in the whole configuration hanging together, and automation rarely assembles a fully consistent one because each surface must be handled deliberately. Prynt evaluates these permission and capability signals as a bundle against network and behavioral evidence, so a session earns trust by being coherent across every layer rather than by satisfying any single check an operator thought to patch.

Recommendations

• Query permission states passively and compare them against the other APIs that expose the same settings.
• Check sensor and media-device availability against the claimed device class.
• Treat the notification permission mismatch and zero-media-device profiles as strong headless indicators.
• Weight the joint pattern, not any single permission, when scoring a session.

The Permissions API turns stored user choices and device capabilities into a quiet consistency check that automation repeatedly fails. It costs nothing, prompts no one, and reliably catches browsers pretending to be devices they are not.

Try Prynt free and inspect your own permission and sensor signals in the playground.