How to specify desired accuracy / resolution of data?

[pes10k]

The spec currently says that

Section 7.2 Requirements

The Geolocation API MUST allow an application to specify a desired accuracy level of the location information.

This is a terrific idea, and enables all sorts of good practices (i might just want to know what city someone lives, but not their street, etc, for ethical, safety and legal reasons).

However, I don't see a way to do this in the API. I see the enableHighAccuracy flag, but i) this is a boolean option, and ii) its not clear to the caller what this will mean, or what the resolution of true or false will be here. It would be a terrific to have a way of allowing sites to say "no more accurate than…" or "only city level" or "only use IP based location" etc.

Basically, the ask here to allow sites to blind themselves from non-needed location data

[marcoscaceres]

Note, although useful, we are updating a REC to reflect updated implementations, not add new features. This is probably out of scope for now.

[pes10k]

Yep! Didn't mean this one as any kind of blocking issue. Definitely feature request level issue.

Though (and its a super minor thing) i think the text in the requirements section about "specify a desired accuracy level" seems a bit at odds with the rest of the document. But any change requested here would be text-tweak level, not feature request level

[anssiko]

As @marcoscaceres rightly points out, new feature proposals beyond editorial text tweaking are out of scope for the Geolocation API since this spec is in maintenance mode. Maintenance includes hardening this quite old API for privacy and security to the extend we can without breaking existing content.

For new feature discussion, there's another API called Geolocation Sensor. Please see its issues labeled geo-accuracy and submit this feedback there. See also all open issues.

Related, and probably of interest to @pes10k as well:

Feedback is also welcome on the new use cases that motivate every new geolocation feature under consideration. Out of these use cases, especially the background operations are highly demanded by web developers but at the same time they are also the most tough ones to solve in a privacy-preserving manner and thus have not advanced beyond use case solicitation at this point. We're hopeful we'll get there eventually, but we don't yet know what API shape and form will get us there. We think, however, that retrofitting the Geolocation API with new features for use cases such as background operation is not a viable option due to its aging design.

[pes10k]

Thank you both for your notes above. I'm holding off adding comments to Geolocation Sensor since my understanding is the relevant WG charter has objections (including regarding geolocation). If those get resolved, or if ive misunderstood the situation, i'll happily move this issue over there.

[anssiko]

@pes10k wrote:

Thank you both for your notes above. I'm holding off adding comments to Geolocation Sensor since my understanding is the relevant WG charter has objections (including regarding geolocation). If those get resolved, or if ive misunderstood the situation, i'll happily move this issue over there.

@pes10k I think you may have slightly misunderstood how the W3C Process works. Let me try to clarify.

First, The Director has not announced any changes regarding this WG or the Geolocation Sensor work, so please feel free to submit your feedback to the https://github.com/w3c/geolocation-sensor repo where the context for your proposal is. In particular, please review the issues labeled with geo-accuracy and chime in.

Second, the WG is not aware of any technical arguments against the Geolocation Sensor spec that'd suggest changes to the direction. The WG acknowledges the historical context and that the problem is not easy to solve, but that's not a valid reason to disinvest. This, especially given the strong demand for the new geolocation features from the web developer community. As per the WG's commitment, we solve also this problem in a secure and privacy-preserving manner. As a WG, we also benefit from horizontal review from experts in privacy, security, others. Of course, we're lucky to have our resident privacy experts in this WG who are scrutinizing the WG's work closely. And we have you watching us!

Last but not least, the fact that you opened this issue adds to the pile of evidence we need to keep the Geolocation Sensor as its own separate WG deliverable as to allow discussion and development of new features for geolocation without interfering with the Geolocation API maintenance effort that is also important, but has its own timelines and priorities. These two APIs coexist.

I'll ping @samuelweiler to ensure this valuable feedback from @pes10k is considered by the W3M.

[pes10k]

@anssiko I appreciate your comments above, but there as been, i believe, at least a few AC comments asking the "Devices and Sensors Working Group" to cease work on the geolocation spec, and for it to stay in this WG. I'd like to wait for the resolution of that conversation before moving comments over. Either way, i will make sure this issue winds up in one (or both) repos

[anssiko]

@pes10k wrote:

but there as been, i believe, at least a few AC comments asking the "Devices and Sensors Working Group" to cease work on the geolocation spec, and for it to stay in this WG

Given "Devices and Sensors Working Group" == "this WG", I feel obligated to clarify one more thing: both the Geolocation API (since March 2019) and Geolocation Sensor (since June 2018) are deliverables of the Devices and Sensors Working Group.

Geolocation Working Group that produced an initial version of the Geolocation API closed in May 2017 leaving that spec in an unmaintained state. Devices and Sensors Working Group was concerned about that and adopted the Geolocation API spec to continue its maintenance in parallel to the new feature work in the Geolocation Sensor spec it had started earlier.

[samuelweiler]

I'm going to take this thread in a different direction: it seems odd to have this spec list some requirements (with 2119 MUSTs, even) that are then not met - or very weakly met (e.g. with a single bit?!?!?). A casual reviewer might take solace from reading the requirements, even though they don't reflect the reality of the spec.

I suggest adding a note to this requirements section saying that the spec does not meet requirement #7 (or does a poor job of meeting it). Ideally, the WG would consider each of the other items also.

I think this suggestion falls into the realm of text tweaking rather than new features.

[samuelweiler]

Our security reviewer suggested this feature in #57 and separately called out the weird bit about having 2119 language in a non-normative section #56 without commenting on how they tie together, as I observed on July 2nd..

I'm flagging this for resolution.