Re: Request to obsolete Geolocation Sensor

To correct the record, this API has never been implemented in Chromium.

Given the lack of interest from any implementation I think it is reasonable
to mark the specification as "inactive" in some way. There is still clear
developer interest in some kind of geofencing capability however that would
likely be a different specification which could coexist with the
Geolocation API.
Reilly Grant | Software Engineer | reillyg@chromium.org | Google Chrome
<https://www.google.com/chrome>

On Wed, May 15, 2024 at 6:18 PM Marcos Caceres <marcosc@apple.com> wrote:

> 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:
> [image: 9.png]
>
> Geolocation Sensor API · Issue #9 · w3ctag/obsoletion
> <https://github.com/w3ctag/obsoletion/issues/9>
> github.com <https://github.com/w3ctag/obsoletion/issues/9>
> <https://github.com/w3ctag/obsoletion/issues/9>
>
> Thanks for your consideration,
> Marcos Cáceres
>
>