Comments (1)
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:
- Device Independence
- Duplication
- Portability
- Power
- Privacy
- Use Cases
- 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.
from standards-positions.
Related Issues (20)
- Timing Info for ServiceWorker static routing API
- New `trusted-types-eval` keyword for CSP script-src HOT 10
- Reference Target for Cross-Root ARIA HOT 1
- VisibilityState performance entry
- ServiceWorkerAutoPreload HOT 2
- Add a noopener-allow-popups value to COOP HOT 3
- Prioritized Task Scheduling HOT 6
- Support 'color-interpolation: linearrgb' on SVG gradients HOT 2
- Partitioning :visited links history HOT 2
- MediaTrackSupportedConstraints.backgroundMask
- WebAuthn hints parameter
- Implement box-decoration-break:clone everywhere
- SVG Favicon
- Temporal - structured clone
- CSS Nesting: The Nested Declarations Rule
- ariaNotify API HOT 2
- Add ability to trigger autofill on form elements in webdriver-bidi specs HOT 1
- Backdrop filter mirror edgeMode HOT 2
- WebAuthn JSON serialization
- Support for PointerEvent getCoalescedEvents() API HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from standards-positions.