Last updated: March 15, 2026

Websites use the Sensor API to collect accelerometer and gyroscope data, which creates unique device fingerprints by analyzing the specific biases and noise patterns of your device’s hardware sensors. information that persists even if you change location or reset your browser. Protect yourself by denying sensor permissions in your browser settings, using Firefox’s privacy.resistFingerprinting, enabling Tor Browser which blocks sensor access, or using a privacy extension that spoofs sensor data. This guide examines how sensor APIs work technically, demonstrates fingerprinting code examples, explains privacy implications, and provides practical mitigation strategies for developers and power users.

Table of Contents

Understanding the Sensor API

The Sensor API provides a standardized interface for accessing device sensors through JavaScript. The most commonly exploited sensors for fingerprinting are:

Accessing sensor data requires user permission on modern browsers, but once granted, websites can collect continuous streams of readings at rates up to 200Hz on supported hardware. The Generic Sensor API (W3C spec) standardizes access across devices, making cross-platform fingerprinting feasible.

How Sensor Data Creates Unique Fingerprints

Each physical device exhibits unique characteristics due to manufacturing tolerances, component variations, and wear patterns. These micro-differences manifest in sensor data as:

  1. Calibration offsets: Sensors rarely report perfect zero values when stationary. each device has consistent non-zero baseline readings
  2. Noise patterns: Thermal noise and electronic interference create unique statistical signatures
  3. Frequency response: Slight variations in how each sensor responds to motion, measurable via spectral analysis
  4. Axis alignment: Physical mounting of sensors introduces small misalignments that appear as cross-axis coupling

A 2018 study by Al-Haiqi et al. demonstrated that combining accelerometer and gyroscope data could uniquely identify devices with over 90% accuracy, even across different browsing sessions and after clearing cookies. A 2019 followup by SensorID researchers at Cambridge showed that even a brief 1-3 second sample collected without user interaction was sufficient to extract a reliable fingerprint from most devices.

The fingerprint from sensor calibration biases is especially problematic: unlike a canvas fingerprint or WebGL hash, it cannot be changed by resetting your browser profile, clearing data, or using a VPN. The biases are permanent hardware-level characteristics of the physical chip.

Code Example - Collecting Sensor Data

Here’s a practical example of how websites collect sensor data for fingerprinting:

// Check sensor availability
if ('Accelerometer' in window) {
  const accel = new Accelerometer({ frequency: 50 });

  accel.addEventListener('reading', () => {
    console.log('Accelerometer:', {
      x: accel.x,
      y: accel.y,
      z: accel.z,
      timestamp: Date.now()
    });
  });

  accel.start();
}

if ('Gyroscope' in window) {
  const gyro = new Gyroscope({ frequency: 50 });

  gyro.addEventListener('reading', () => {
    console.log('Gyroscope:', {
      x: gyro.x,
      y: gyro.y,
      z: gyro.z,
      timestamp: Date.now()
    });
  });

  gyro.start();
}

This code samples sensor data at 50Hz, collecting hundreds of readings during a typical page session. Statistical analysis of these readings. mean, standard deviation, min/max per axis. produces a compact fingerprint vector that can be matched against a database of previously seen devices.

Fingerprinting Techniques

Static Fingerprinting

The simplest approach collects sensor readings while the device is stationary. Even when completely still, sensors report small non-zero values due to:

These baseline readings create a relatively stable signature:

function collectBaseline(readings, duration = 5000) {
  return new Promise((resolve) => {
    const samples = [];
    const startTime = Date.now();

    const interval = setInterval(() => {
      samples.push({
        accel: { x: accel.x, y: accel.y, z: accel.z },
        gyro: { x: gyro.x, y: gyro.y, z: gyro.z },
        time: Date.now() - startTime
      });

      if (Date.now() - startTime >= duration) {
        clearInterval(interval);
        resolve(analyzeFingerprint(samples));
      }
    }, 20);
  });
}

function analyzeFingerprint(samples) {
  // Calculate mean, standard deviation, and min/max for each axis
  const stats = {};
  ['x', 'y', 'z'].forEach(axis => {
    const values = samples.map(s => s.accel[axis]);
    stats[`accel_${axis}`] = {
      mean: values.reduce((a, b) => a + b) / values.length,
      std: Math.sqrt(values.reduce((a, b) => a + Math.pow(b - mean, 2), 0) / values.length)
    };
  });
  return stats;
}

Dynamic Fingerprinting

More sophisticated techniques induce specific motions and analyze the response. Common methods include:

// Example: Dynamic fingerprinting through controlled motion
function generateMotionSignature() {
  const readings = [];

  // Request user to rotate device
  return new Promise((resolve) => {
    let stage = 0;
    const stages = ['hold', 'rotate90', 'hold', 'rotate180', 'hold'];

    const motionHandler = (event) => {
      readings.push({
        rotationRate: {
          alpha: event.rotationRate.alpha,
          beta: event.rotationRate.beta,
          gamma: event.rotationRate.gamma
        },
        stage: stages[stage]
      });
    };

    // Cycle through orientations with visual cues
    const interval = setInterval(() => {
      stage++;
      if (stage >= stages.length) {
        clearInterval(interval);
        resolve(extractSignature(readings));
      }
    }, 2000);
  });
}

Passive Collection via DeviceMotion Events

The older DeviceMotionEvent and DeviceOrientationEvent APIs historically required no permission on most browsers, allowing passive sensor collection without any user prompt. As of 2022, Safari gates these events behind permission on iOS. However, on many Android browsers and older iOS versions, this data remains available without explicit permission.

Privacy Implications

Sensor fingerprinting poses significant privacy concerns that differ from other tracking methods:

Mitigation Strategies

For Users - Practical Steps

Step 1 - Deny sensor permissions at the browser level

In Chrome for Android - Settings → Site Settings → Motion sensors → Block

In Firefox - Navigate to about:config, search for device.sensors.enabled, set to false. This disables all sensor access globally.

In Safari on iOS - Settings → Privacy → Motion & Fitness → disable for your browser

Step 2 - Use Firefox with resistFingerprinting

In Firefox about:config, set privacy.resistFingerprinting to true. This causes Firefox to report fake, standardized sensor values rather than real hardware readings, making fingerprinting impossible.

Step 3 - Use Tor Browser

Tor Browser blocks DeviceMotionEvent and the Generic Sensor API entirely. Sensor fingerprinting code on a webpage simply receives errors rather than data.

Step 4 - Use a sensor spoofing extension

Extensions like SpoofSensor (Firefox) override sensor APIs to return constant or randomized values. This is less strong than browser-level protections but works in Chromium-based browsers where resistFingerprinting is unavailable.

For Developers - Responsible Sensor Use

// Browser-level sensor permission request
navigator.permissions.query({ name: 'accelerometer' })
  .then(result => {
    if (result.state === 'granted') {
      // Implement privacy-preserving approach:
      // - Collect only what you need
      // - Use the minimum sampling frequency
      // - Do not send raw data to servers
      // - Delete readings immediately after processing
    }
  });

Responsible sensor use principles:

Browser Implementations

Chrome, Firefox, and Safari have implemented varying levels of sensor protection:

Verifying Your Protection

Test your sensor fingerprinting protection at:

If you see real accelerometer or gyroscope readings on these test pages, your sensor APIs are exposed. If you see zeros, errors, or randomized values, your protection is working.

Frequently Asked Questions

Who is this article written for?

This article is written for developers, technical professionals, and power users who want practical guidance. Whether you are evaluating options or implementing a solution, the information here focuses on real-world applicability rather than theoretical overviews.

How current is the information in this article?

We update articles regularly to reflect the latest changes. However, tools and platforms evolve quickly. Always verify specific feature availability and pricing directly on the official website before making purchasing decisions.

Are there free alternatives available?

Free alternatives exist for most tool categories, though they typically come with limitations on features, usage volume, or support. Open-source options can fill some gaps if you are willing to handle setup and maintenance yourself. Evaluate whether the time savings from a paid tool justify the cost for your situation.

Can I trust these tools with sensitive data?

Review each tool’s privacy policy, data handling practices, and security certifications before using it with sensitive data. Look for SOC 2 compliance, encryption in transit and at rest, and clear data retention policies. Enterprise tiers often include stronger privacy guarantees.

What is the learning curve like?

Most tools discussed here can be used productively within a few hours. Mastering advanced features takes 1-2 weeks of regular use. Focus on the 20% of features that cover 80% of your needs first, then explore advanced capabilities as specific needs arise.

Related Articles