Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Geolocation Sensor API #9

Closed
1 task done
marcoscaceres opened this issue May 16, 2024 · 5 comments
Closed
1 task done

Geolocation Sensor API #9

marcoscaceres opened this issue May 16, 2024 · 5 comments

Comments

@marcoscaceres
Copy link

marcoscaceres commented May 16, 2024

Hello TAG!

I'm requesting that the TAG consider the following specification:

be considered by the TAG for:

  • obsoleting

NB: This is not a recommendation yet, but I'm requesting TAG action now regardless.

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)

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.

This specification was produced by the Device and Sensors Working Group.

The following specifications have dependencies on this specification:

  • None

The following implementations of this specification are known:

  • none

Thank you for considering this request.

@reillyeon
Copy link

There are a number of factual inaccuracies in this proposal:

  1. The Geolocation Sensor API has not been published a W3C Recommendation and so §6.3.13.3 Obsoleting or Rescinding a W3C Recommendation is not applicable.
  2. The Working Group which maintains this specification is still active, in contradiction of the criteria for requesting the TAG to consider whether a specification is obsolete.
  3. The Geolocation Sensor API is not implemented in Chromium browsers. It exists solely as a Working Draft.

I am not opposed to asking whether work on this specification is worth doing but I don't believe the process here is the right venue for that.

@marcoscaceres
Copy link
Author

marcoscaceres commented May 17, 2024

Corrected above. There are no implementations of this spec.

Previous erroneously claimed Chromium.

@plehegar
Copy link

[[
The process of rescinding, obsoleting, superseding, or restoring a Recommendation can be initiated either by a request from the Team or via a request from any of the following:

Since we do have an active Working Group, such request is misplaced.

@marcoscaceres
Copy link
Author

Ok, so yes.. Let me close this, and send file a bug on DAS instead.

@marcoscaceres
Copy link
Author

Sent w3c/geolocation-sensor#60

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants