- From: Marcos Caceres <marcosc@apple.com>
- Date: Thu, 16 May 2024 11:17:07 +1000
- To: W3C Devices and Sensors WG <public-device-apis@w3.org>
- Cc: www-tag@w3.org
- Message-id: <164D2CE0-3EC2-432A-9882-96AA980F745D@apple.com>
Dear Device and Sensors WG and TAG for input, I'm requesting that the DAS consider the following specification: - [Geolocation Sensor API](https://www.w3.org/TR/geolocation-sensor/) (Working Draft) be considered by the for: - [X] superseding (by Geolocation API) The rationale for why the above action should be taken is as follows: 1. **Duplicative Nature**: There is already a well-maintained W3C Geolocation API maintained jointly by the Device and Sensors Working Group and the Web Applications Working Group. The Geolocation Sensor API does not add any real value beyond what is already offered by the existing API. 2. **No Significant New Functionality**: The Geolocation Sensor API does not introduce any significant new functionality beyond the existing Geolocation API. 3. **Recommendation to Improve Existing API**: It is more beneficial to continue improving the existing Geolocation API rather than maintaining a separate, duplicative API. 4. **Developer Confusion and Web Interoperability Issues**: Having multiple APIs that perform the same function but are only supported in Chromium browsers leads to developer confusion and site compatibility problems. Developers are forced to choose between APIs, increasing the cognitive load and the potential for errors. This also leads to inconsistent experiences across different browsers, undermining the principle of web interoperability. 5. **Security and Maintenance Concerns**: Maintaining multiple APIs that serve the same purpose increases the attack surface for security vulnerabilities. Each additional API requires its own set of security reviews, patches, and updates, which can lead to fragmented and inconsistent security postures across different implementations. 6. **Limited Multi-Implementer Input and Participation**: The Device and Sensors Working Group has limited multi-implementer input and participation. Despite extensive review processes, the working group lacks broad engagement from other implementers. The Geolocation Sensor API has been a Working Draft since 2018, yet it has not garnered sufficient interest or support from additional implementers. This prolonged stagnation indicates a lack of broader industry backing, raising concerns about the specification's viability and future. Both Mozilla and WebKit have expressed negative standards positions and have no intention of implementing the API, hence it will never advance past Candidate Recommendation. Mozilla's standards position states: > "Given that the web already has a geolocation API, any additional API for the same purpose would have to meet a high bar as both will need to be maintained forever. While the document claims to improve security and privacy, there is no evidence that is the case. And as it can be largely polyfilled on top of the existing API, it seems better to invest in web platform geolocation additions there, if any." ([Source](https://mozilla.github.io/standards-positions/#geolocation-sensor)) WebKit has also rejected the Geolocation Sensor API for similar reasons, citing duplication and no significant improvements over the existing API. Additional reasons for obsoleting this API include the lack of adoption and implementation beyond Chromium browsers, which leads to site compatibility problems and developer confusion. This confusion is compounded by the document being on the W3C Recommendation track, as external parties and developers might believe this will become an actual W3C recommendation, despite there being no chance of this happening due to the lack of interest from other implementers. The following specifications have dependencies on this specification: - None The following implementations of this specification are known: - Chromium-based browsers Filed along with TAG request: https://github.com/w3ctag/obsoletion/issues/9 Geolocation Sensor API · Issue #9 · w3ctag/obsoletion github.com Thanks for your consideration, Marcos Cáceres
Attachments
Received on Thursday, 16 May 2024 01:17:42 UTC