Gyroscope

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Devices and Sensors Working Group as a Candidate Recommendation. This document is intended to become a W3C Recommendation. This document will remain a Candidate Recommendation at least until 8 January 2020 in order to ensure the opportunity for wide review.

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 “gyroscope” in the subject, preferably like this: “[gyroscope] …summary of comment…”. All comments are welcome.

Publication as a Candidate Recommendation does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implementation all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group. The Working Group will prepare an implementation report to track progress.

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 1 March 2019 W3C Process Document.

1. Introduction

The Gyroscope API extends the Generic Sensor API [GENERIC-SENSOR] to provide information about the angular velocity around the device’s local X, Y and Z axis in terms of radian per seconds units.

2. Use Cases and Requirements

The use cases and requirements are addressed in the Motion Sensors Explainer document.

3. Examples

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

sensor.onreading = () => {
    console.log("Angular velocity around the X-axis " + sensor.x);
    console.log("Angular velocity around the Y-axis " + sensor.y);
    console.log("Angular velocity around the Z-axis " + sensor.z);
};

sensor.onerror = event => console.log(event.error.name, event.error.message);

4. Security and Privacy Considerations

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

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] research paper proposes 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].

5. Model

The Gyroscope sensor type’s associated Sensor subclass is the Gyroscope class.

The Gyroscope has a default sensor, which is the device’s main gyroscope sensor.

The Gyroscope has an associated sensor permission name which is "gyroscope".

A latest reading of a Sensor of Gyroscope sensor type includes three entries whose keys are "x", "y", "z" and whose values contain current angular velocity about the corresponding axes.

The angular velocity is the rate at which the device rotates about a specified axis in a local coordinate system defined by the device. Its unit is the radian per second (rad/s) [SI].

The sign of the current angular velocity depends on the rotation direction and it must be according to the right-hand convention in a local coordinate system defined by the device, such that positive rotation around an axis is clockwise when viewed along the positive direction of the axis (see figure below).

Device’s local coordinate system and rotation.

5.1. Reference Frame

The local coordinate system represents the reference frame for the Gyroscope readings. It can be either the device coordinate system or the screen coordinate system.

6. API

6.1. The Gyroscope Interface

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

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

dictionary GyroscopeSensorOptions : SensorOptions {
  GyroscopeLocalCoordinateSystem referenceFrame = "device";
};

To construct a Gyroscope object the user agent must invoke the construct a gyroscope object abstract operation.

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

6.1.1. Gyroscope.x

The x attribute of the Gyroscope interface represents the current angular velocity around X-axis. In other words, this attribute returns the result of invoking get value from latest reading with this and "x" as arguments.

6.1.2. Gyroscope.y

The y attribute of the Gyroscope interface represents the current angular velocity around Y-axis. In other words, this attribute returns the result of invoking get value from latest reading with this and "y" as arguments.

6.1.3. Gyroscope.z

The z attribute of the Gyroscope interface represents the current angular velocity around Z-axis. In other words, this attribute returns the result of invoking get value from latest reading with this and "z" as arguments.

7. Abstract Operations

7.1. Construct a Gyroscope object

input: options, a GyroscopeSensorOptions object.
output: A Gyroscope object.

Let allowed be the result of invoking check sensor policy-controlled features with Gyroscope.
If allowed is false, then:
1. Throw a SecurityError DOMException.
Let gyroscope be the new Gyroscope object.
Invoke initialize a sensor object with gyroscope and options.
If options.referenceFrame is "screen", then:
1. Define local coordinate system for gyroscope as the screen coordinate system.
Otherwise, define local coordinate system for gyroscope as the device coordinate system.
Return gyroscope.

8. Automation

This section extends the automation section defined in the Generic Sensor API [GENERIC-SENSOR] to provide mocking information about the rate of rotation around the device’s local three primary axes for the purposes of testing a user agent’s implementation of Gyroscope API.

8.1. Mock Sensor Type

The Gyroscope class has an associated mock sensor type which is "gyroscope", its mock sensor reading values dictionary is defined as follows:

dictionary GyroscopeReadingValues {
  required double? x;
  required double? y;
  required double? z;
};

9. Acknowledgements

Tobie Langel for the work on Generic Sensor API.

10. Conformance

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]

A conformant user agent must implement all the requirements listed in this specification that are applicable to user agents.

The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [WEBIDL]