Geolocation API

[xfq]

Saluton TAG!

I'm requesting a TAG review of Geolocation API.

This specification defines an API that provides scripted access to geographical location information associated with the hosting device. It is now maintained by the Devices and Sensors WG, and contains the following substantive changes since the last REC:

• Now Controlled by feature policy
• Fixed confusion around callback interfaces not being an EventHandler
• Only expose the API in SecureContexts
• Renamed the interfaces and dictionaries + removal of [NoInterfaceObject] + [SameObject] annotation on geolocation attribute

---

• Specification URL: https://w3c.github.io/geolocation-api/
• Tests: https://github.com/web-platform-tests/wpt/tree/master/geolocation-API
• Security and Privacy self-review: https://w3c.github.io/geolocation-api/#security
• GitHub repo (if you prefer feedback filed there): https://github.com/w3c/geolocation-api
• Primary contacts (and their relationship to the specification):
  • Anssi Kostiainen (@anssiko), Intel
  • Fuqiao Xue (@xfq), W3C
  • Reilly Grant (@reillyeon), Google
• Organization(s)/project(s) driving the specification: Devices and Sensors Working Group
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status):
  • Geolocation
  • Remove geolocation from Insecure Contexts
  • Feature Policy
  • Remove NoInterfaceObject

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is currently being done: W3C DAS WG
• Major unresolved issues with or opposition to this specification: no known issues

We'd prefer the TAG provide feedback as:

☂️ open a single issue in our GitHub repo for the entire review

[hadleybeeman]

Hi @xfq! We're looking at this at our W3C TAG virtual face-to-face. Do you have an explainer we could look at?

[xfq]

We're looking at this at our W3C TAG virtual face-to-face. Do you have an explainer we could look at?

@hadleybeeman Not yet. I just filed w3c/geolocation#59 for this.

[torgo]

Hi @xfq - I guess this has fallen through the cracks for you folks - and we haven't been the best at following it up either. I want to make sure we're able to do this. Can you provide a more substantive discussion / description of the changes including the justification and user needs behind them? And what has happened since the last REC regarding security & privacy and the move to secure contexts? Hope this helps to focus the activity so we can complete this review.

[hadleybeeman]

Looking at this in our W3C TAG virtual face-to-face. Specifically looking at the 3.2 Privacy considerations for recipients of location information section, we aren't sure that it makes sense to put normative references on the recipients of geolocation information. They aren't implementing the spec. Perhaps you'd want to make these non-normative?

[marcoscaceres]

Just FYI, I've updated the README to be more like an explainer:
w3c/geolocation#65

I've also called out the examples in the spec, as they also serve the role of an explainer.

@hadleybeeman:

we aren't sure that it makes sense to put normative references on the recipients of geolocation information. They aren't implementing the spec. Perhaps you'd want to make these non-normative?

Yeah, you are right... recipients are not a conformance class, so the conformance requirements make no sense there. I'll send a PR to fix that up.

[marcoscaceres]

Sent PR w3c/geolocation#66 .... the section is now informative, with lowercase "must, should, can". Also added a clarifying note about what a "recipient" is (basically a developer... that was not clear).

[marcoscaceres]

Fixed link to pull request above 😅

[hadleybeeman]

Thanks for addressing that comment, @marcoscaceres!

We're looking at this in our virtual TAG face-to-face. The Privacy and Security section looks stronger now, though it still has more text for recipients than implementers (in a document whose audience is more likely to be implementers).

We suggest strengthening the section for implementers 3.2 Implementation considerations:

However, in designing these measures, implementers are advised to enable user awareness of location sharing, and to provide access to user interfaces that enable revocation of permissions.

...by adding additional examples like periodic permissions prompts (for example, "$website still has access to your location. Would you like it to continue to know where you are?"), visual indicators of when location is being used, etc.

[marcoscaceres]

Thanks @hadleybeeman.

Prompted (no pun intended!) by this and related discussion, we are looking at adding such recommendations/examples generally to the Permissions API as part of w3c/permissions#233

[hadleybeeman]

Thanks, @marcoscaceres. To clarify: we were thinking more about advice to implementers of geolocation, rather than making changes to the Permissions API. Repeated prompts and UI indicators should be in the suite of options that browsers can use to empower/inform their users.

Beyond that though, we don't think we have much more to add. We're glad to see the progression this effort has taken, given the years in its development and our privacy concerns on earlier iterations. We are proposing to close this issue, but let us know if we can help with anything else.

[marcoscaceres]

Thanks, @marcoscaceres. To clarify: we were thinking more about advice to implementers of geolocation, rather than making changes to the Permissions API. Repeated prompts and UI indicators should be in the suite of options that browsers can use to empower/inform their users.

TBH, I'm hesitant to add anything that makes UI suggestions. Having worked at multiple browser vendor companies, the privacy UI teams of those companies are exceptionally professional (and scientific!) at coming up with innovative solutions to the UI challenges of the Web. I'd feel like we would be overstepping or being patronizing if we suggested anything, given that we are not user-testing anything we would propose.

Case in point, Mozilla's solution for annoying notification requests and the underlying research that went into that solution.

Beyond that though, we don't think we have much more to add. We're glad to see the progression this effort has taken, given the years in its development and our privacy concerns on earlier iterations. We are proposing to close this issue, but let us know if we can help with anything else.

Thanks again @hadleybeeman and TAG members. This has been very fruitful!