Gyroscope, Accelerometer, Magnetometer, Motion, Orientation

[marcoscaceres]

WebKittens

@marcoscaceres

Title of the spec

Gyroscope, Accelerometer, Magnetometer, Orientation, Motion

URL to the spec

https://www.w3.org/TR/gyroscope/
https://www.w3.org/TR/accelerometer/
https://www.w3.org/TR/magnetometer/
https://www.w3.org/TR/orientation-sensor/
https://www.w3.org/TR/motion-sensors/

URL to the spec's repository

No response

Issue Tracker URL

No response

Explainer URL

No response

TAG Design Review URL

No response

Mozilla standards-positions issue URL

No response

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This specification defines a concrete sensor interface to monitor the rate of rotation around the device’s local three primary axes.

[marcoscaceres]

Draft position - unless anyone objects, I'd like to make this WebKit's official position within a week or so.

NB: this feedback applies to all three related specs: Gyroscope, Accelerometer, Magnetometer, Motion, and Orientation.

tl;dr: Our position is "opposed".

The Gyroscope API provides access to the data from the device's gyroscope sensor. This sensor measures the rate of rotation around the device's axes, allowing applications to detect and respond to the device's orientation and movement. The API is designed to enable applications to access high-frequency rotation data, which can be useful for applications requiring precise motion detection.

The concerns we've identified are as follows:

1. Device Independence
2. Duplication
3. Portability
4. Power
5. Privacy
6. Use Cases
7. Venue

Device Independence

The Gyroscope API ties itself explicitly to a specific sensor, namely the gyroscope. While it is true that mobile devices commonly include gyroscopes, they are often used in conjunction with other sensors to derive the desired device orientation and motion data. This reliance on a single sensor reduces the flexibility and robustness of applications, as it does not account for the potential integration with other sensors such as accelerometers and magnetometers, which are critical for accurate orientation and motion detection. Consequently, this limits the API's applicability across a broader range of devices and scenarios.

Duplication

The duplication of functionality is our most significant concern. The web already benefits from a fairly interoperable and widely supported Device Orientation and Motion specification. The Gyroscope API essentially duplicates the functionality provided by this existing specification. Instead of introducing a new API, it would be more efficient and beneficial to incorporate any additional functionality or enhancements directly into the Device Orientation and Motion specification. This approach would prevent fragmentation and ensure a more cohesive and streamlined experience for developers.

Portability

Introducing a sensor-specific API like the Gyroscope API can hinder the portability of web applications across different devices and platforms. Applications developed with this API may not function as intended on devices lacking a dedicated gyroscope sensor, or where sensor behavior varies significantly. By contrast, the Device Orientation and Motion API abstracts sensor details, providing a more portable and consistent interface that adapts to the available hardware.

Power

Unlike the Device Orientation and Motion API, the Gyroscope API allows developers to set the frequency at which the sensor data is sampled. This capability is problematic as it creates unrealistic expectations about how often the operating system or user agent will fire events. High-frequency sampling can lead to significant power consumption, adversely affecting battery life on mobile devices. Sampling frequency should be managed by the browser, which can optimize performance based on the device's power and performance characteristics, rather than being directly controlled by web pages.

Privacy

High-frequency sensor data can be exploited to infer sensitive information about users, such as gestures, keystrokes, and even location. The Gyroscope API, by supporting high-frequency data sampling, exacerbates these privacy risks. The specification itself acknowledges potential privacy issues, including keylogging, location tracking, fingerprinting, user identification, and eavesdropping. However, it still permits high-frequency sampling, which could be misused. A more prudent approach would be to limit the granularity of sensor data accessible to web pages, thus mitigating these risks.

Use Cases

The use cases cited for the Gyroscope API are already comprehensively addressed by the Device Orientation and Motion specification. Introducing a separate API for similar purposes adds unnecessary complexity and fragmentation to the web platform. Consolidating enhancements and new use cases within the existing Device Orientation and Motion specification would provide a more unified and efficient solution.

Venue

The Device and Sensors Working Group, responsible for the Gyroscope API, has limited multi-implementer input and participation. Despite extensive review processes, the working group lacks broad engagement from other implementers. Notably, the Gyroscope API has remained in draft form for eight years without a second browser engine's implementation commitment. Furthermore, it has been a Candidate Recommendation for five years, yet it has not garnered sufficient interest or support from additional implementers. This prolonged stagnation indicates a lack of broader industry backing, which raises concerns about the specification's viability and future.

Recommendation

Given these concerns, we recommend the Device and Sensors Working Group discontinue the Gyroscope API specification. Instead, any useful functionality or enhancements should be integrated into the existing Device Orientation and Motion specification together with the Web Applications Working Group. This approach will prevent duplication, enhance portability, and ensure more robust privacy and power management practices. Working together with more browser vendors and implementers will benefit developers because enhancements, should they be accepted, will actually get implemented across multiple browsers. This collaborative effort will provide a more consistent and reliable experience for developers and users alike, ensuring that improvements are widely supported and beneficial to the entire web platform.