Request to obsolete Gyroscope, Accelerometer, Magnetometer, Orientation, Motion APIs

Dear Device and Sensors WG and TAG for input, 

I'm requesting that DAS consider the following specifications:

  - [Gyroscope API](https://www.w3.org/TR/gyroscope/) - CR 
  - [Accelerometer API](https://www.w3.org/TR/accelerometer/) - CR
  - [Magnetometer API](https://www.w3.org/TR/magnetometer/) - WD
  - [Orientation](https://www.w3.org/TR/orientation-sensor/)  - WD
  - [Motion](https://www.w3.org/TR/motion-sensors/) - WD

be considered for:
  - [x] superseding (by Device Orientation and Motion specification)

### Rationale for why the above action should be taken

#### Device Independence
These APIs tie themselves explicitly to specific sensors. While mobile devices commonly include gyroscopes, accelerometers, and magnetometers, these sensors are often used in conjunction to derive the desired device orientation and motion data. This reliance on individual sensors reduces the flexibility and robustness of applications, as it does not account for their potential integration. Consequently, this limits the APIs' applicability across a broader range of devices and scenarios.

#### Duplication
The duplication of functionality is a significant concern. The web already benefits from a fairly interoperable and widely supported Device Orientation and Motion specification. The Gyroscope, Accelerometer, and Magnetometer APIs essentially duplicate the functionality provided by this existing specification. Instead of maintaining separate APIs, 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 sensor-specific APIs can hinder the portability of web applications across different devices and platforms. Applications developed with these APIs may not function as intended on devices lacking the corresponding sensors 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, these sensor-specific APIs allow 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. These APIs, by supporting high-frequency data sampling, exacerbate these privacy risks. The specifications themselves acknowledge potential privacy issues, including keylogging, location tracking, fingerprinting, user identification, and eavesdropping. However, they still permit 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 these APIs are already comprehensively addressed by the Device Orientation and Motion specification. Introducing separate APIs 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 these APIs, 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 specifications' viability and future.

### Recommendation
Given these concerns, the Device and Sensors Working Group should discontinue the Gyroscope, Accelerometer, Magnetometer, Orientation, and Motion API specifications. 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 ecosystem.

The following implementations of these specifications are known:
 - Chromium only

If the recommended action is superseding, the newer version that supersedes it is:
  - [Device Orientation and Motion specification](https://www.w3.org/TR/orientation-event/)

Filed this along with TAG request:
https://github.com/w3ctag/obsoletion/issues/8
Gyroscope, Accelerometer, Magnetometer, Orientation, Motion APIs · Issue #8 · w3ctag/obsoletion
github.com


Thanks for your consideration,
Marcos Cáceres