Accelerometer

Editor’s Draft,

More details about this document
This version:
https://w3c.github.io/accelerometer/
Latest published version:
https://www.w3.org/TR/accelerometer/
Version History:
https://github.com/w3c/accelerometer/commits/main/index.bs
Feedback:
public-device-apis@w3.org with subject line “[accelerometer] … message topic …” (archives)
GitHub
Implementation Report:
https://www.w3.org/wiki/DAS/Implementations
Test Suite:
https://github.com/web-platform-tests/wpt/tree/main/accelerometer
Editor:
Anssi Kostiainen (Intel Corporation)
Former Editor:
Alexander Shalamov (Intel Corporation)

Abstract

This specification defines Accelerometer, LinearAccelerationSensor and GravitySensor interfaces for obtaining information about acceleration applied to the X, Y and Z axis of a device that hosts the sensor.

Status of this document

This is a public copy of the editors’ draft. It is provided for discussion only and may change at any moment. Its publication here does not imply endorsement of its contents by W3C. Don’t cite this document other than as work in progress.

If you wish to make comments regarding this document, please send them to public-device-apis@w3.org (subscribe, archives). When sending e-mail, please put the text “accelerometer” in the subject, preferably like this: “[accelerometer] …summary of comment…”. All comments are welcome.

This document was published by the Devices and Sensors Working Group.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 03 November 2023 W3C Process Document.

This document is maintained and updated at any time. Some parts of this document are work in progress.

1. Introduction

The Accelerometer, LinearAccelerationSensor and GravitySensor APIs extends the Generic Sensor API [GENERIC-SENSOR] interface to provide information about acceleration applied to device’s X, Y and Z axis in local coordinate system defined by device.

2. Examples

let sensor = new Accelerometer();
sensor.start();

sensor.onreading = () => {
    console.log("Acceleration along X-axis: " + sensor.x);
    console.log("Acceleration along Y-axis: " + sensor.y);
    console.log("Acceleration along Z-axis: " + sensor.z);
}

sensor.onerror = event => console.log(event.error.name, event.error.message);
The following example shows how to use gravity sensor that provides readings in the screen coordinate system. The snippet will print message to the console when the dom screen is perpendicular to the ground and bottom of the rendered web page is pointing downwards.
let sensor = new GravitySensor({frequency: 5, referenceFrame: "screen"});

sensor.onreading = () => {
  if (sensor.y >= 9.8) {
    console.log("Web page is perpendicular to the ground.");
  }
}

sensor.start();
The following example detects shake gesture along x axis of the device, regardless of the orientation of the dom screen.
const shakeThreshold = 25;

let sensor = new LinearAccelerationSensor({frequency: 60});

sensor.addEventListener('reading', () => {
  if (sensor.x > shakeThreshold) {
    console.log("Shake detected.");
  }
});

sensor.start();

3. Use Cases and Requirements

The use cases and requirements are listed in the Motion Sensors Explainer and Sensor use cases documents.

4. Security and Privacy Considerations

Sensor readings provided by inertial sensors, such as accelerometer, could be used by adversaries to exploit various security threats, for example, keylogging, location tracking, fingerprinting and user identifying.

Research papers published by security community, for instance, [KEYSTROKEDEFENSE], indicate that by throttling the frequency, risks of successful attacks are not fully eliminated, while throttling may greatly affect usefulness of a web application with legitimate reasons to use the sensors.

The [TOUCHSIGNATURES] and [ACCESSORY] research papers propose that implementations can provide visual indication when inertial sensors are in use and/or require explicit user consent to access sensor readings. These mitigation strategies complement the generic mitigations defined in the Generic Sensor API [GENERIC-SENSOR].

This specification defines an accelerometer reading quantization algorithm (called from the get value from latest reading operation) to mitigate sensor calibration fingerprinting [SENSORID] and attacks that rely on high precision sensor readings. The details of the quantization algorithm follow W3C Privacy Interest Group’s recommendation.

5. Permissions Policy integration

This specification utilizes the policy-controlled feature identified by the string "accelerometer" defined in [DEVICE-ORIENTATION].

6. Model

6.1. Accelerometer

The Accelerometer sensor type has the following associated data:

Extension sensor interface

Accelerometer

Sensor permission names

"accelerometer"

Sensor feature names

"accelerometer"

Permission revocation algorithm

Invoke the generic sensor permission revocation algorithm with "accelerometer".

Default sensor

The device’s main accelerometer sensor.

Virtual sensor type

"accelerometer"

A latest reading for a Sensor of Accelerometer sensor type includes three entries whose keys are "x", "y", "z" and whose values contain device’s acceleration about the corresponding axes.

The acceleration is the rate of change of velocity of a device with respect to time. Its unit is the metre per second squared (m/s2) [SI].

The frame of reference for the acceleration measurement must be inertial, such as, the device in free fall would provide 0 (m/s2) acceleration value for each axis.

The sign of the acceleration values must be according to the right-hand convention in a local coordinate system (see figure below).

Accelerometer coordinate system.

6.2. Linear Acceleration Sensor

The Linear Acceleration Sensor sensor type has the following associated data:

Extension sensor interface

LinearAccelerationSensor

Sensor permission names

"accelerometer"

Sensor feature names

"accelerometer"

Permission revocation algorithm

Invoke the generic sensor permission revocation algorithm with "accelerometer".

Virtual sensor type

"linear-acceleration"

A latest reading for a Sensor of Linear Acceleration Sensor sensor type includes three entries whose keys are "x", "y", "z" and whose values contain device’s linear acceleration about the corresponding axes.

The linear acceleration is an acceleration that is applied to the device that hosts the sensor, without the contribution of a gravity force.

Note: The relationship between gravity and linear acceleration is discussed in Motion Sensors Explainer § gravity-and-linear-acceleration.

6.3. Gravity Sensor

The Gravity Sensor sensor type has the following associated data:

Extension sensor interface

GravitySensor

Sensor permission names

"accelerometer"

Sensor feature names

"accelerometer"

Permission revocation algorithm

Invoke the generic sensor permission revocation algorithm with "accelerometer".

Virtual sensor type

"gravity"

A latest reading for a Sensor of Gravity Sensor sensor type includes three entries whose keys are "x", "y", "z" and whose values contain the acceleration due to gravity about the corresponding axes.

The gravity is the component of the device’s acceleration that prevents its velocity from increasing toward nearby masses. Devices in free fall for more than a short period of time may compute incorrect values for the gravity.

Note: The relationship between gravity and linear acceleration is discussed in Motion Sensors Explainer § gravity-and-linear-acceleration.

6.4. Reference Frame

The local coordinate system represents the reference frame for the Accelerometer, LinearAccelerationSensor, and the GravitySensor readings. It can be either the device coordinate system or the screen coordinate system.

The device coordinate system is defined as a three dimensional Cartesian coordinate system (x, y, z), which is bound to the physical device. For devices with a display, the origin of the device coordinate system is the center of the device display. If the device is held in its default position, the Y-axis points towards the top of the display, the X-axis points towards the right of the display and Z-axis is the vector product of X and Y axes and it points outwards from the display, and towards the viewer. The device coordinate system remains stationary regardless of the dom screen orientation (see figure below).

Device coordinate system.

The screen coordinate system is defined as a three dimensional Cartesian coordinate system (x, y, z), which is bound to the dom screen. The origin of the screen coordinate system in the center of the dom screen. The Y-axis always points towards the top of the dom screen, the X-axis points towards the right of the dom screen and Z-axis is the vector product of X and Y axes and it and it points outwards from the dom screen, and towards the viewer (see figure below).

Screen coordinate system.

The main difference between the device coordinate system and the screen coordinate system, is that the screen coordinate system always follows the dom screen orientation, i.e. it will swap X and Y axes in relation to the device if the current orientation type changes. In contrast, the device coordinate system will always remain stationary relative to the device.

7. API

7.1. The Accelerometer Interface

[SecureContext, Exposed=Window]
interface Accelerometer : Sensor {
  constructor(optional AccelerometerSensorOptions options = {});
  readonly attribute double? x;
  readonly attribute double? y;
  readonly attribute double? z;
};

enum AccelerometerLocalCoordinateSystem { "device", "screen" };

dictionary AccelerometerSensorOptions : SensorOptions {
  AccelerometerLocalCoordinateSystem referenceFrame = "device";
};
The new Accelerometer(options) constructor steps are to invoke the construct an accelerometer object abstract operation with this and options.

Supported sensor options for Accelerometer are "frequency" and "referenceFrame".

7.1.1. Accelerometer.x

The x attribute of the Accelerometer interface returns the result of invoking get value from latest reading with this and "x" as arguments. It represents the acceleration along x-axis.

7.1.2. Accelerometer.y

The y attribute of the Accelerometer interface returns the result of invoking get value from latest reading with this and "y" as arguments. It represents the acceleration along y-axis.

7.1.3. Accelerometer.z

The z attribute of the Accelerometer interface returns the result of invoking get value from latest reading with this and "z" as arguments. It represents the acceleration along z-axis.

7.2. The LinearAccelerationSensor Interface

[SecureContext, Exposed=Window]
interface LinearAccelerationSensor : Accelerometer {
  constructor(optional AccelerometerSensorOptions options = {});
};
The new LinearAccelerationSensor(options) constructor steps are to invoke the construct an accelerometer object abstract operation with this and options.

Supported sensor options for LinearAccelerationSensor are "frequency" and "referenceFrame".

7.2.1. LinearAccelerationSensor.x

The x attribute of the LinearAccelerationSensor interface returns the result of invoking get value from latest reading with this and "x" as arguments. It represents the linear acceleration along x-axis.

7.2.2. LinearAccelerationSensor.y

The y attribute of the LinearAccelerationSensor interface returns the result of invoking get value from latest reading with this and "y" as arguments. It represents the linear acceleration along y-axis.

7.2.3. LinearAccelerationSensor.z

The z attribute of the LinearAccelerationSensor interface returns the result of invoking get value from latest reading with this and "z" as arguments. It represents the linear acceleration along z-axis.

7.3. The GravitySensor Interface

[SecureContext, Exposed=Window]
interface GravitySensor : Accelerometer {
  constructor(optional AccelerometerSensorOptions options = {});
};
The new GravitySensor(options) constructor steps are to invoke the construct an accelerometer object abstract operation with this and options.

Supported sensor options for GravitySensor are "frequency" and "referenceFrame".

7.3.1. GravitySensor.x

The x attribute of the GravitySensor interface returns the result of invoking get value from latest reading with this and "x" as arguments. It represents the effect of acceleration along x-axis due to gravity.

7.3.2. GravitySensor.y

The y attribute of the GravitySensor interface returns the result of invoking get value from latest reading with this and "y" as arguments. It represents the effect of acceleration along y-axis due to gravity.

7.3.3. GravitySensor.z

The z attribute of the GravitySensor interface returns the result of invoking get value from latest reading with this and "z" as arguments. It represents the effect of acceleration along z-axis due to gravity.

8. Abstract Operations

8.1. Construct an accelerometer object

input

object, an Accelerometer, LinearAccelerationSensor or GravitySensor object.

options, a AccelerometerSensorOptions object.

  1. Let allowed be the result of invoking check sensor policy-controlled features with object’s sensor type.

  2. If allowed is false, then:

    1. Throw a SecurityError DOMException.

  3. Invoke initialize a sensor object with object and options.

  4. If options.referenceFrame is "screen", then:

    1. Set object’s local coordinate system to the screen coordinate system.

  5. Otherwise, define object’s local coordinate system to the device coordinate system.

8.2. Accelerometer reading quantization algorithm

The Accelerometer sensor type defines the following reading quantization algorithm:

input

reading, a sensor reading

output

A sensor reading

  1. Let quantizedReading be reading.

  2. If quantizedReading["x"] is not null, set quantizedReading["x"] to the nearest 0.1 m/s2.

  3. If quantizedReading["y"] is not null, set quantizedReading["y"] to the nearest 0.1 m/s2.

  4. If quantizedReading["z"] is not null, set quantizedReading["z"] to the nearest 0.1 m/s2.

  5. Return quantizedReading.

9. Automation

This section extends Generic Sensor API § 9 Automation by providing Accelerometer-specific virtual sensor metadata. Some of the virtual sensor types used by this specification are defined in [DEVICE-ORIENTATION].

9.1. Accelerometer automation

The accelerometer virtual sensor type and its corresponding entry in the per-type virtual sensor metadata map are defined in Device Orientation and Motion § automation.

9.2. Linear Accelerometer automation

The linear-acceleration virtual sensor type and its corresponding entry in the per-type virtual sensor metadata map are defined in Device Orientation and Motion § automation.

9.3. Gravity automation

The per-type virtual sensor metadata map must have the following entry:

key

"gravity"

value

A virtual sensor metadata whose reading parsing algorithm is parse xyz reading.

10. Acknowledgements

Tobie Langel for the work on Generic Sensor API.

W3C Privacy Interest Group and Paul Jensen for the sensor calibration fingerprinting mitigation proposal and discussion.

Conformance

Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

Conformant Algorithms

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

Conformance requirements phrased as algorithms or specific steps can be implemented in any manner, so long as the end result is equivalent. In particular, the algorithms defined in this specification are intended to be easy to understand and are not intended to be performant. Implementers are encouraged to optimize.

Index

Terms defined by this specification

Terms defined by reference

References

Normative References

[DEVICE-ORIENTATION]
Reilly Grant; Raphael Kubo da Costa; Marcos Caceres. Device Orientation and Motion. URL: https://w3c.github.io/deviceorientation/
[GENERIC-SENSOR]
Rick Waldron. Generic Sensor API. URL: https://w3c.github.io/sensors/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[PERMISSIONS]
Marcos Caceres; Mike Taylor. Permissions. URL: https://w3c.github.io/permissions/
[PERMISSIONS-POLICY-1]
Ian Clelland. Permissions Policy. URL: https://w3c.github.io/webappsec-permissions-policy/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[SCREEN-ORIENTATION]
Marcos Caceres. Screen Orientation. URL: https://w3c.github.io/screen-orientation/
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

Informative References

[ACCESSORY]
Owusu, Emmanuel, et al. ACCessory: password inference using accelerometers on smartphones. 2012. Informational. URL: https://dl.acm.org/citation.cfm?id=2162095
[KEYSTROKEDEFENSE]
Song, Yihang, et al. Two novel defenses against motion-based keystroke inference attacks. 2014. Informational. URL: https://arxiv.org/abs/1410.7746
[MOTION-SENSORS]
Kenneth Christiansen; Alexander Shalamov. Motion Sensors Explainer. URL: https://w3c.github.io/motion-sensors/
[SENSORID]
Zhang, Jiexin; Beresford, Alastair R.; Sheret, Ian. SensorID: Sensor Calibration Fingerprinting for Smartphones. 2019. URL: https://doi.org/10.1109/SP.2019.00072
[SI]
SI Brochure: The International System of Units (SI), 8th edition. 2014. URL: http://www.bipm.org/en/publications/si-brochure/
[TOUCHSIGNATURES]
Mehrnezhad, Maryam, et al. Touchsignatures: identification of user touch actions and pins based on mobile sensor data via javascript. 2016. Informational. URL: https://arxiv.org/abs/1602.04115

IDL Index

[SecureContext, Exposed=Window]
interface Accelerometer : Sensor {
  constructor(optional AccelerometerSensorOptions options = {});
  readonly attribute double? x;
  readonly attribute double? y;
  readonly attribute double? z;
};

enum AccelerometerLocalCoordinateSystem { "device", "screen" };

dictionary AccelerometerSensorOptions : SensorOptions {
  AccelerometerLocalCoordinateSystem referenceFrame = "device";
};

[SecureContext, Exposed=Window]
interface LinearAccelerationSensor : Accelerometer {
  constructor(optional AccelerometerSensorOptions options = {});
};

[SecureContext, Exposed=Window]
interface GravitySensor : Accelerometer {
  constructor(optional AccelerometerSensorOptions options = {});
};

MDN

Accelerometer/Accelerometer

In only one current engine.

FirefoxNoneSafariNoneChrome67+
Opera?Edge79+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

Accelerometer/x

In only one current engine.

FirefoxNoneSafariNoneChrome67+
Opera?Edge79+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

Accelerometer/y

In only one current engine.

FirefoxNoneSafariNoneChrome67+
Opera?Edge79+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

Accelerometer/z

In only one current engine.

FirefoxNoneSafariNoneChrome67+
Opera?Edge79+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

Accelerometer

In only one current engine.

FirefoxNoneSafariNoneChrome67+
Opera?Edge79+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

GravitySensor/GravitySensor

In only one current engine.

FirefoxNoneSafariNoneChrome91+
Opera?Edge91+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

GravitySensor

In only one current engine.

FirefoxNoneSafariNoneChrome91+
Opera?Edge91+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

LinearAccelerationSensor/LinearAccelerationSensor

In only one current engine.

FirefoxNoneSafariNoneChrome67+
Opera?Edge79+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

LinearAccelerationSensor

In only one current engine.

FirefoxNoneSafariNoneChrome67+
Opera?Edge79+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?
MDN

Headers/Feature-Policy/accelerometer

In only one current engine.

FirefoxNoneSafariNoneChrome67+
Opera?Edge79+
Edge (Legacy)?IENone
Firefox for Android?iOS Safari?Chrome for Android?Android WebView?Samsung Internet?Opera Mobile?