#529: Geolocation API

Visit on Github.

Opened Jun 24, 2020

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:

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

Discussions

Discussed Jul 1, 2020 (See Github)

David: this looks like a revision of the existing spec. Not the new spec.

Dan: there are several changes - highlighted in the request - we need to review these and maybe we can close this in the plenary call this week. I will review the feature policy bit.

Tess: I will also look at it.

[bumped to plenary

Comment by @hadleybeeman Sep 23, 2020 (See Github)

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

Comment by @xfq Sep 24, 2020 (See Github)

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 https://github.com/w3c/geolocation-api/issues/59 for this.

Discussed Jan 1, 2021 (See Github)

Dan: left comment

Hadley: notes the Privacy section of spec... feels very weird to have in a spec.

Dan: is it non-normative?

Hadley: it's normative.

Hadley: leaves additional comment regarding privacy & security requirements

Amy: looks like most of the changes are implemented in browsers...

Hadley: in the s&p section they have 2 sections - one for UAs and one for recipients

Dan: they can't put normative requirements on recipients of the data, they're not implementing the spec so there's no teeth

Comment by @torgo Jan 26, 2021 (See Github)

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.

Comment by @hadleybeeman Jan 26, 2021 (See Github)

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?

Comment by @marcoscaceres Mar 22, 2021 (See Github)

Just FYI, I've updated the README to be more like an explainer: https://github.com/w3c/geolocation-api/pull/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.

Comment by @marcoscaceres Mar 22, 2021 (See Github)

Sent PR https://github.com/w3c/geolocation-api/pull/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).

Comment by @marcoscaceres Mar 22, 2021 (See Github)

Fixed link to pull request above 😅

Discussed May 1, 2021 (See Github)

Hadley: in the spec - in implementation considerations - advice to implementers on location sharing and revocation of permission. The thought is there that browsers have some responsibility.

Dan: Agree. So let's close on that basis

Discussed May 1, 2021 (See Github)

Hadley: still waiting... We've been concerned about the privacy implications and that the p&s section was written from PoV of developers... it could help to put some stuff in for implementers - periodic permission prompts, visual indicators, etc...

Dan: not really engaged with P&S self checked, just linked off to their considerations section

Hadley: they didn't have an explainer, but updated the readme

Dan: this is from so long ago...

Hadley: can put in a comment suggesting clarifying our advice was for geolocation not permissions

Dan: gaguing the response, maybe thinks this is more a generalised permissions issue... what do we think? Visual indication thing is not.

Hadley: yeah

Dan: because geo is the kind of api that is used.. I dunno.. because other types of apis used in the backround include ambient light sensor, camera, audio, geo can be used in the background. How can we focus our time? we've been back and forth. If there's nothing further to say should we close it?

Hadley: agree although ... we haven't put issues in their repo. Issue marcos is linking to on permissions api references issue 69 in geo which says explicitly limit permission lifetimes. So they're already talking about it.

Dan: we've left the feedback.. I don't know if we should keep it open?

Hadley: [leaves feedback, propose closed]

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.

Dan: I remember original geo api, there were objections on privacy grounds from center for democracy and technology i think? there was a big fight over this. Some of those concerns were well placed. This was before https. Got into platform without requirement for secure contexts. Good to see they're tidying it up. I think that's what this is about, we should be supportive. But still this permissions api thing which isn't uniformly adopted

Discussed May 1, 2021 (See Github)

Rossen: I remember looking at this.... what's new?

Tess: seems like they've identified 4 changes from the last time they went to REC. One of those is webidl fixups, fine. One is only exposing in secure contexts. Also fine. Geo is sensitive. Control by feature policy, probably a good thing, it would be funny if random iframes could do this.

Rossen: is webkit committed? according to issue 41 about feature policy it looks like everyone but webkit is committed

Tess: not in the devices and sensors wg, so weren't there to say. Also fixing confusing thing. That's probably fine. But there has been all sorts of discussion since then. Hadley noticed a weird thing with privacy, marcos fixed it

Hadley: looks resolved

Rossen: I'm good with this

Tess: deeper dive than that?

Hadley: still weird from a privacy standpoint to create a spec that says hey developers please don't take advantage of this sensitive information, when developers may have a lot of incentives to do otherwise.

Dan: privacy and security considerations.. saying be nice, don't abuse this. This is information for recipients, not for implementers. Could we recommend that implementers make their UI explicitly inform users when sensitive information is being shared?

Tess: next section implementation considerations goes into that a bit. the API itself is gated behind a permission?

Rossen: yeah but

Dan: also visual information that you're being tracked, regular prompts, that user agents and OSs do

Tess: would be great for their implementer part to go into great detail listing all those things for privacy and security

Dan: be more explicit about other things implementers can to do mitigate against misuse of information - additioanl prompts, visualisation of when location is being used, periodic prompts ("continue to allow"). Non-normative. But would be for the implementers rather than for the receivers of information, which is weak.

Hadley: makes sense. Last bit of section 3.2 says implementers are advised to enable user awareness of location sharing ... revoke permissions... sounds like it's easy to exxpand that into what you're saying.

Tess: exactly

Comment by @hadleybeeman May 13, 2021 (See Github)

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.

Comment by @marcoscaceres May 18, 2021 (See Github)

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 https://github.com/w3c/permissions/issues/233

Comment by @hadleybeeman Jun 1, 2021 (See Github)

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.

Comment by @marcoscaceres Jun 2, 2021 (See Github)

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!