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

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

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

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

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