Mark as Discontinued Draft and continue in Geolocation API

[marcoscaceres]

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

• Geolocation Sensor API (Working Draft)

be considered be marked as for a Discontinued Draft

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 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 ANY implementers.

The following specifications have dependencies on this specification:

• None

The following implementations of this specification are known:

• none

Thank you for considering this request.

[anssiko]

In this context it is important to observe strong developer and end user demand for the use cases outlined in https://www.w3.org/TR/geolocation-sensor/#use-cases for https://github.com/w3c/geolocation-sensor/labels/geo-background-fencing and https://github.com/w3c/geolocation-sensor/labels/geo-background-tracking in particular. Thank you everyone for your contributions. ❤️

Retrofitting these sought after features discussed in use cases and issues into the "legacy" Geolocation API may not be reasonable due to the historical design, process, and other reasons. The shape of the solution to address these use cases may also differ materially from what is currently proposed as an API in this repo as GeolocationSensor, built atop the extensible modern framework, the Generic Sensor API. All these aspects need careful consideration.

All this does not however change the fact that there's significant demand for these features among developers and users and the wider web community has come together in this repo to share their suggestions, feedback and real-world use cases. This is not often happening in W3C repos, so it is important that the W3C community does not dismiss this valuable developer and end user feedback, but uses this information wisely and continues to engage with the web developer community in shaping the solution in a venue where our collaborative stakeholders are now, that is, here.

To address the concern raised, we will look for appropriate mechanisms to help clarify the current status to ensure discussion continues on these important use cases and features without disruption. Everyone - do not worry, your voice continues to be heard.

[marcoscaceres]

While there is developer demand for the use cases outlined in the "experimental" Geolocation Sensor specification (see how unpleasant when people add "labels" to specs), it is crucial to address some misconceptions about the feasibility and practicality of retrofitting new features into what you deceptively call the "legacy" Geolocation API.

First, the assumption that retrofitting these sought-after features into the Geolocation API has repeatedly proven incorrect. Unlike the "experimental" Geolocation Sensor, the Geolocation specification has been consistently well-maintained and is interoperably implemented by all major browser vendors. This robust maintenance contradicts the notion of it being "legacy" and underscores its viability for evolution.

Second, labeling the Geolocation specification as "legacy" is misguided and deceptive. It is an actively maintained specification with widespread support across all major engines. The validity of the use cases is not in question; however, it is misleading to dismiss the current Geolocation specification when it continues to serve developers and users effectively. Put bluntly: there is nothing "legacy" about it, and, despite baseless claims to the contrary, nothing preventing it from being evolved. On the other hand, despite claims to the contrary, there is zero evidence that the "experimental" Geolocation Sensor specification meets the use cases or is even implementable across user agents or OSs - let alone meeting the stringent privacy requirements for some of these features.

Moreover, wide review feedback from Mozilla and WebKit has already indicated a lack of support for the "experimental" Geolocation Sensor specification. This feedback led browser vendors to move the actual Geolocation specification from the DAS working group to make it a joint deliverable with WebApps, allowing browser vendors and a wider set of stakeholders than would be possible in DAS to collaborate on it and steer it inclusively. The lack of participation from other implementers in the DAS working group further diminishes the potential for significant input or adoption of the experimental and unimplemented Geolocation Sensor spec. Implementers have consistently advised the DAS group to collaborate with WebApps to improve the existing Geolocation standard rather than pursuing a separate, unsupported and duplicative .

It's also important to consider the W3C TAG's guidance on adding new capabilities, which emphasizes integrating new features with existing functionalities and considering existing usage before introducing new specifications. The current approach with the "experimental" Geolocation Sensor specification appears to violate this principle by not adequately integrating with the well-established and actively maintained Geolocation API (see W3C TAG Design Principles).

Therefore, it is essential to set aside any pettiness and focus on advancing a single specification that is already widely implemented and supported. Claims that the Geolocation specification cannot evolve have been demonstrably and repeatedly shown to be unfounded and without merit.

In conclusion, the W3C community should prioritize practical, well-supported solutions that address developer and user needs without unnecessary fragmentation. By working together on the existing Geolocation standard, we can ensure a smoother, more effective path forward for all stakeholders.

[jzijp]

Dear Marcos,

Thank you for your feedback regarding the Geolocation Sensor API. While the idea of unifying APIs to avoid duplication and simplify the work for developers and browsers is commendable, it is hard not to question the real motivations behind this request.

It is concerning that this opposition to the new API could be seen as a commercial strategy to hinder the development of web applications in favor of native apps, especially coming from Apple, known for its restrictive policies towards web apps. Ignoring advanced capabilities like geo-background-fencing and geo-background-tracking and simplifying it to "no additional functionality" seems misleading.

The current Geolocation API was never designed for background functionalities, and integrating these capabilities appears challenging. If your true intention is to improve the situation, I encourage you to propose a form of integration and a mechanism for supporting background functionalities within the existing API, rather than simply rejecting the new specification.

Additionally, citing competitors without providing a full perspective seems petty and does not reflect the collaborative spirit needed to advance web standards. A more open and balanced discussion would be beneficial for all stakeholders.

Best regards,

[marcoscaceres]

@jzijp, I kindly remind you of the W3C's Code of Conduct. Making insinuations or attributing malice to me or my employer is out of line.

The current Geolocation API was never designed for background functionalities, and integrating these capabilities appears challenging.

I would like to understand the specific challenges and for whom they are challenging. As the Editor of the Geolocation specification, I haven't had the opportunity to try specifying it yet, and the specification was only brought to the WebApp Working Group within the past year.

Additionally, the Geolocation Sensor specification doesn't address issues related to fencing or background processes. Simply adding [Exposed=(DedicatedWorker)] to an interface is not sufficient. While fencing and background are mentioned in the use cases, the specification does not thoroughly address these issues. Have you had a chance to read through the spec in detail?

I encourage you to propose a form of integration and a mechanism for supporting background functionalities within the existing API, rather than simply rejecting the new specification.

I'm proposing that we collaborate on addressing this use case within the existing Geolocation API.

Additionally, citing competitors without providing a full perspective seems petty and does not reflect the collaborative spirit needed to advance web standards. A more open and balanced discussion would be beneficial for all stakeholders.

Respectfully, I believe there's a misunderstanding. The DAS Working Group was limiting the participation of relevant stakeholders, which led to the W3C's decision to move the Geolocation API to be a joint deliverable with the WebApps WG. The WebApps WG includes a larger set of stakeholders, allowing for a more collaborative approach to solving these challenges.

Now that we have all implementers involved, we can work together to develop solutions. This approach avoids unilateral decisions by DAS, which other implementers have opposed or labelled "harmful". Notably, DAS has overlooked feedback from Wide Review.

[anssiko]

As a chair of the Devices and Sensors Working Group responsible for the Geolocation Sensor deliverable, I consider that @jzijp is engaging in this discussion in good faith. Thank you for sharing your perspective here. Also thank you for your use case contributions that have been already recognized by the group.

While here, I feel obligated to refute the claims made by @marcoscaceres.

First, the Devices and Sensors Working Group is not limiting participation. The group is open for everyone to join, including for all browser vendors, any other stakeholders, no matter big and small. To join, follow the instructions at: https://www.w3.org/groups/wg/das/instructions/

(Use case contributions can be provided without joining to make it possible to capture the broadest feedback, including from end users. The group is grateful for contributions on that front from the broader web ecosystem.)

Second, the Devices and Sensors Working Group approaches wide review professionally and has received recognition from horizontal groups for its exemplary work over the years across its deliverables. Furthermore, the group is participated by industry-recognized privacy experts who actively review the group's deliverables, identify issues and co-design mitigations. One recent example: https://github.com/w3c/compute-pressure/issues/177#issuecomment-2112891153

[marcoscaceres]

First, the Devices and Sensors Working Group is not limiting participation.

And yet, the fact remains that we had to make Device Orientation and Motion, Geolocation, and Screen Wake Lock API joint deliverables. Why do you think that is, @anssiko?

Second, the Devices and Sensors Working Group approaches wide review professionally and has received recognition from horizontal groups for its exemplary work over the years across its deliverables.

Really? Seem DAS willfully and actively ignores wide review, such as Mozilla's standards position, and WebKit's standards position.

DAS even ignores feedback from its own participants (https://github.com/WebKit/standards-positions/issues/32#issuecomment-1180126411):

Yep... "exemplary" indeed. Well done.

[anssiko]

And yet, the fact remains that we had to make Device Orientation and Motion, Geolocation, and Screen Wake Lock API joint deliverables. Why do you think that is, @anssiko?

The proposal to make these joint deliverables came from you @marcoscaceres in https://github.com/w3c/webappswg/issues/90 and your rationale was "more possibility for input by a larger set of members". That is, you are asking a question you are in a position to answer, not me.

Related to this, considering the normal approach is for W3C members to join a Working Group responsible for the work they want to provide input on, it is understandable that the wider web community is asking questions, including in this very issue.

As a reminder to the wider web community watching: the W3C Process governs participation across all W3C Working Groups equally. This means all W3C Working Groups are governed by the same rules and follow the same process. None of them is limiting participation to ensure fairness in technical decision-making. All WGs are open for any W3C member organization to join. There's also a separate Invited Expert path for individuals.

Again, while here, with my chair hat on, I feel obligated to refute @marcoscaceres' claims regarding wide review:

Please talk to the leaders of the horizontal groups to hear how the Devices and Sensors Working Group is conducting its wide reviews if you're not convinced. The Working Group is carefully following the W3C Process to ensure the entire set of stakeholders of the web community is informed of the progress of the Working Group, is able to perform reviews and provide comments on the specifications.

What comes to the Geolocation Sensor deliverable specific claims, the Working Group has most recently focused on listening to the wider web community's feedback on use cases, in particular for background operations. The work on the API definition has been on hold while we've solicited further feedback. What has become clear is that there's strong developer and end user demand for these use cases and that implementers have indicated they need more time.

As said already, the Working Group believes it is important to allow this discussion to happen, not suppress these voices.

Thank you to all the contributors who've shared helpful feedback. Please don't feel discouraged by these arguments that may seem intimidating and please continue to do the right thing.

Your voice continues to be heard. The Working Group is listening. Peace.

[marcoscaceres]

@reillyeon, has the Working Group formally discussed Mozilla's standards position, and WebKit's standards position?

Are there minutes where those were discussed and the points addressed?

[anssiko]

This was discussed in the Working Group's F2F meeting, minutes: https://www.w3.org/2023/09/14-dap-minutes.html#t16

@reillyeon please provide additional pointers to meeting minutes as appropriate.

In this context it is worth noting the position statements did not consider background and geofencing use cases. However, these use cases in scope for this API are important based on feedback received by the Working Group. I have a reason to believe this is one point that has created dissonance.

@marcoscaceres as a chair, I'd like to invite you to our next F2F as a guest as permitted by the W3C Process so we can build consensus on these important background and geofencing use cases together.

[marcoscaceres]

This was discussed in the Working Group's F2F meeting, minutes: https://www.w3.org/2023/09/14-dap-minutes.html#t16

I don't see any reference to either the Mozilla Position or the WebKit position? Where did you specifically discuss the actual positions?

I do see people asking for positions from Mozilla and WebKit in various other parts. And a various pleas to find what WebKit and Mozilla are doing. It's telling how many times Mozilla (4) and WebKit (7) get mentioned in the DAS minutes. If you want to work with us on stuff, then do it in a forum where we can, and would want to, participate (i.e., WebApps). Thankfully, we can now for the joint deliverables.

@reillyeon, it would be great to have an actual meeting to discuss the 6 things I listed (point by point) https://github.com/w3c/geolocation-sensor/issues/60#issue-2307167883 and Mozilla's position, which is:

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.

I'm happy to join a call to discuss https://github.com/w3c/geolocation-sensor/issues/60#issue-2307167883 and maybe we can reach out to someone form Mozilla to join to discuss their position (e.g., @tantek) .

@marcoscaceres as a chair, I'd like to invite you to our next F2F as a guest as permitted by the W3C Process so we can build consensus on these important background and geofencing use cases together.

Appreciate the invite, but I must decline because (again) DAS is excluding other members by only inviting me.

What would be better would be to meet as a larger community on Wednesday at TPAC during the Tech Plenary. If we want to build consensus on this, we should do it in a forum where it doesn't need to be "permitted by the W3C Process" and where folks form Mozilla and other interested parties can join.

Also, as almost all DAS members are also part of WebApps (and all implementers are represented in WebApps), we should really have the discussions there. It doesn't make sense to have them in DAS at the exclusion of WebKit, Mozilla, and other interested parties.