search

w3c / transitions

W3C Transitions
https://www.w3.org/Guide/transitions/
73 stars 30 forks source link

CR Request for Geolocation API #373

Closed xfq closed 2 years ago

xfq commented 3 years ago

Document title, URLs, estimated publication date

Geolocation API Date: 2021-09-07

Abstract

The Geolocation API provides access to geographical location information associated with the hosting device.

Status

The Devices and Sensors Working Group is updating this specification in the hope of making it a "living standard".

Link to group's decision to request transition

https://lists.w3.org/Archives/Public/public-device-apis/2021Aug/0022.html

Changes

https://w3c.github.io/geolocation-api/#change-log

Requirements satisfied

N/A

Dependencies met (or not)

Changes in Permissions API and Web IDL may have an impact on this specification.

Wide Review

The spec has received wide review at FPWD time. The normative changes since FPWD are implementation details that bring the spec in line with implementations and don't change or invalidate the wide reviews received at FPWD time.

Issues addressed

https://github.com/w3c/geolocation-api/issues?q=is%3Aissue+is%3Aclosed+

Formal Objections

None.

Implementation

https://wpt.fyi/geolocation-API

Patent disclosures

https://www.w3.org/groups/wg/das/ipr

/cc @marcoscaceres @reillyeon @anssiko

plehegar commented 3 years ago

@samuelweiler , can you update the status on those PING issues?

plehegar commented 3 years ago

History: https://www.w3.org/standards/history/geolocation-API https://www.w3.org/standards/history/geolocation

plehegar commented 3 years ago

Normative references

Secure Contexts hasn't been updated since 2016 in /TR. @sideshowbarker , can we get an updated draft please?

sideshowbarker commented 3 years ago

Secure Contexts hasn't been updated since 2016 in /TR. @sideshowbarker , can we get an updated draft please?

Yes, will do

marcoscaceres commented 3 years ago

@sideshowbarker, if you can update Bikeshed templates to the right PP (for WebAppSec), all the specs should (finally!) auto-publish 🎉 That would be really awesome. Let me know if you want me to review/help.

sideshowbarker commented 3 years ago

Autopublishing of the Secure Contexts spec to TR is currently blocked on resolving failures about missing stuff that, as far as I can see, Bikeshed and spec-prod should be adding automatically based on the Status value in the Bikeshed source.

https://github.com/w3c/webappsec-secure-contexts/pull/91#issuecomment-914108015 https://github.com/w3c/webappsec-secure-contexts/runs/3531636253#step:3:670

Any help on figuring out how to resolve those would be welcome.

xfq commented 3 years ago

@sideshowbarker I think you need to add a CRD boilerplate file in Bikeshed (example). If you need help, I can help send a PR to Bikeshed.

sideshowbarker commented 3 years ago

@sideshowbarker I think you need to add a CRD boilerplate file in Bikeshed (example). If you need help, I can help send a PR to Bikeshed.

Thanks, I’ll give it — and if I run into any problems, I’ll ping you

samuelweiler commented 3 years ago

It looks like https://github.com/w3c/geolocation-api/issues/69 needs to be checked also; I'm not sure why the tracker didn't capture that one.

Edit: oops. It's there. Perhaps I got confused because the names of the tracking issue and the underlying issue no longer match.

marcoscaceres commented 3 years ago

@samuelweiler, whatever comes out of w3c/geolocation-api#69 (if anything) can probably go in after REC. It's not a blocker, given that the only recommendation we can give there is "the user agent may suggest a permission lifetime of once to forever" (i.e., it's totally up to the user agent, as shown by all the different browsers).

plehegar commented 3 years ago

It looks like w3c/geolocation-api#69 needs to be checked also; I'm not sure why the tracker didn't capture that one.

I cited this issue in my earlier comment and it's listed in https://www.w3.org/PM/horizontal/review.html?shortname=geolocation so not sure where you think it's missing.

marcoscaceres commented 3 years ago

Btw, all but 69 have been resolved. How can we get PING to close those?

samuelweiler commented 3 years ago

Btw, all but 69 have been resolved. How can we get PING to close those?

Follow PLH's lead above at https://github.com/w3c/transitions/issues/373#issuecomment-912613304, you tag the person who opened them, the PING chairs, and/or me. And then wait. And maybe poke again.

samuelweiler commented 3 years ago

It looks like w3c/geolocation-api#69 needs to be checked also; I'm not sure why the tracker didn't capture that one.

I cited this issue in my earlier comment and it's listed in https://www.w3.org/PM/horizontal/review.html?shortname=geolocation so not sure where you think it's missing.

Perhaps because the names of the tracking issue and the underlying issue no longer match. In any case, my bad.

samuelweiler commented 3 years ago

While I'm fine with the substantive change of using the Permissions API, the privacy analysis text in Section 4 (n.b. I'm using section numbers from the diff linked in the PR, which seem to differ from the current section numbers) should explain the solution as well as the problem. e.g. "This API makes use to of the Permissions API to ensure that users have given express permission for the sharing of location" and maybe add some words about the granularity of that permission?

(In other words, the privacy considerations was stripped down too far here.)

I also tagged the filer of the issue for any more comments they might have.

Explicitly limit permission lifetimes w3cping/tracking-issues#112 , are we ok with resolving that as part of the Permissions API and was there enough progress made on that front ?

Asking @pes10k for feedback on the substance. IMHO, we should include the lifetime recommendation here, consistent with the proposed change to the Permissions spec - and we could make that recommendation even before the Permissions API change lands.

Restrict access to visible and user-activation-received frames w3cping/tracking-issues#111 should be closed (or we need more info or kept open for a longtime),

Asking @pes10k to follow up on this one.

samuelweiler commented 3 years ago

As I was looking at the above, I saw that the privacy consideration section changed significantly since PING was asked to review it, including by marking even the one remaining normative paragraph as non-normative. The latter change was not in a reviewed PR, as best I can tell.

While I'm not objecting to the substance of that (although PING still might), that is a change that should have somehow been called out.

What I find particularly challenging is that I can't easily pull up the version of the doc that PING reviewed. The request for review in 2020 just pointed at the editor's draft. That was pre-FPWD, apparently, so following the "previous version" links still won't bring me back to that version. This is making me wish for cleanly-versioned documents!

Using this as an example: how should our review processes be catching changes like this - potentially big ones - that a WG or editor doesn't mention? @swickr @pes10k @sandandsnow

plehegar commented 3 years ago

short story long: we need to make sure what the Director can see the diff between what was reviewed and what is being asked for a transition. I have a patch to require publication in /TR to trigger in https://github.com/w3c/documentreview/pull/21 .

Now, regarding this transition in particular, here is a diff.

I used the June 25, 2020 version as the reference for the wide review request since PING discussed the document in July 2020.

swickr commented 3 years ago

The request for review in 2020 just pointed at the editor's draft.

This -- requests for review of documents other than in /TR -- is a pattern that I hope we can strongly discourage.

sideshowbarker commented 3 years ago

Normative references

Secure Contexts hasn't been updated since 2016 in /TR. @sideshowbarker , can we get an updated draft please?

https://www.w3.org/TR/secure-contexts/ now has the updated autopublished CRD

marcoscaceres commented 3 years ago

Awesome! thanks @sideshowbarker. Looks like it's already been picked up by specref too.

plehegar commented 3 years ago

ACTION: @plehegar to nudge @samuelweiler and @marcoscaceres on their understanding on where we stand here.

marcoscaceres commented 3 years ago

Permission lifetime needs to land first, into Permission spec: https://github.com/w3c/permissions/pull/287

And then, I need to write a pull request to close off: https://github.com/w3c/geolocation-api/issues/69

marcoscaceres commented 2 years ago

Ok, various PRs sent to address the outstanding privacy and security issues. I'm giving folks until the end of November to provide feedback.

The permissions lifetimes PR is also getting fairly close to getting merged.

marcoscaceres commented 2 years ago

Given the positive feedback on w3c/geolocation-api#69, I've gone ahead and merged.

I think we are good to move forward with publishing as CR.

xfq commented 2 years ago

@samuelweiler @pes10k Can you confirm that PING is satisfied?

marcoscaceres commented 2 years ago

Are we ok to move forward on this? It would be great to publish this week.

marcoscaceres commented 2 years ago

HTML changed the way timers are accessed/used, so Geolocation needs to be updated: https://github.com/w3c/geolocation-api/issues/113

It's an editorial update... but links are broken right now and I need to read up about the new timing model to integrate things properly (next week, once I'm back).

samuelweiler commented 2 years ago

I reopened https://github.com/w3c/geolocation-api/issues/49 partly to confirm WG intent. I'm okay if the answer is "yep, this is what we're doing for now.

Restrict to user-activation-received frames (was: Restrict access to visible and user-activation-received frames) w3cping/tracking-issues#111 should tracked for the next revision. @marcoscaceres, how would you like to do that? (And I might fie a new issue re: the thing in https://github.com/w3c/geolocation-api/issues/49, also, if you tell me where/how you want them to carry forward...

marcoscaceres commented 2 years ago

@marcoscaceres, how would you like to do that?

Via https://github.com/w3c/geolocation-api/pull/94 would be best.

And https://github.com/w3c/geolocation-api/issues/49 if you tell me where/how you want them to carry forward...

We can keep discussing in w3c/geolocation-api#49, but again, we need to convince implementers post REC.

Right now, we are just trying to get the REC to match reality of things that got implemented over last few years (before 2022) - and not add any are features for 2022+. New features we can start adding after REC, as this is an updable REC.

marcoscaceres commented 2 years ago

@samuelweiler @pes10k Can you confirm that PING is satisfied?

marcoscaceres commented 2 years ago

@xfq, @plehegar, I think we are good to go here: We've waited a reasonable amount of time for PING to respond and everything has now been addressed.

What are the next steps here?

anssiko commented 2 years ago

My expectation is no WG chair action is needed at this point (CfC to publish CR ended with no concerns in Aug 2021), but please let me know if I can help with this transition somehow.

I think this CR publication is particularly important given the feature's wide adoption and the spec's post-CR history being stale for so long.

marcoscaceres commented 2 years ago

@plehegar, see @samuelweiler and @pes10k confirmations at: https://github.com/w3c/geolocation-api/issues/49#issuecomment-1026244568 https://github.com/w3c/geolocation-api/issues/49#issuecomment-1026939893

plehegar commented 2 years ago

The CR duration requested is 28 days (minimum). Expectation is to have 2 implementations of all conformance requirements.

swickr commented 2 years ago

Transition approved.

xfq commented 2 years ago

(I'm on a vacation right now that ends next week, so won't be able to publish it this week.)

xfq commented 2 years ago

Published: https://www.w3.org/TR/2022/CR-geolocation-20220217/

sandandsnow commented 2 years ago

@anssiko, we discussed this at our PING meeting yesterday. As a consequence, there are a couple of follow-up questions. I was hoping to share them with you yesterday, but I'm waiting on colleagues to clarify those.

anssiko commented 2 years ago

Thanks @sandandsnow. If the questions are of technical in nature, please record them in the Geolocation API spec repo. Specifically, CR->PR transition is tracked at https://github.com/w3c/geolocation-api/issues/121

sandandsnow commented 2 years ago

Apologies, I was in the wrong thread. I thought was writing in the thread about Ambient Light Sensor API. Please ignore my earlier note.