CR Request for Geolocation API #373
Comments
xfq
added
Entering CR
@samuelweiler , can you update the status on those PING issues? |
|
Secure Contexts hasn't been updated since 2016 in /TR. @sideshowbarker , can we get an updated draft please? |
Yes, will do |
|
@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. |
|
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. w3c/webappsec-secure-contexts#91 (comment) Any help on figuring out how to resolve those would be welcome. |
|
@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 |
|
It looks like w3c/geolocation#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. |
|
@samuelweiler, whatever comes out of w3c/geolocation#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). |
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. |
|
Btw, all but 69 have been resolved. How can we get PING to close those? |
Follow PLH's lead above at #373 (comment), you tag the person who opened them, the PING chairs, and/or me. And then wait. And maybe poke again. |
Perhaps because the names of the tracking issue and the underlying issue no longer match. In any case, my bad. |
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.
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.
Asking @pes10k to follow up on this one. |
|
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 |
|
short story long: 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. |
This -- requests for review of documents other than in /TR -- is a pattern that I hope we can strongly discourage. |
https://www.w3.org/TR/secure-contexts/ now has the updated autopublished CRD |
|
Awesome! thanks @sideshowbarker. Looks like it's already been picked up by specref too. |
|
ACTION: @plehegar to nudge @samuelweiler and @marcoscaceres on their understanding on where we stand here. |
plehegar
added
Awaiting Working Group
|
Permission lifetime needs to land first, into Permission spec: And then, I need to write a pull request to close off: |
|
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. |
|
Given the positive feedback on w3c/geolocation#69, I've gone ahead and merged. I think we are good to move forward with publishing as CR. |
|
@samuelweiler @pes10k Can you confirm that PING is satisfied? |
|
Are we ok to move forward on this? It would be great to publish this week. |
|
HTML changed the way timers are accessed/used, so Geolocation needs to be updated: 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). |
|
I reopened w3c/geolocation#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 w3c/geolocation#49, also, if you tell me where/how you want them to carry forward... |
Via w3c/geolocation#94 would be best.
We can keep discussing in w3c/geolocation#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. |
|
@samuelweiler @pes10k Can you confirm that PING is satisfied? |
|
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. |
plehegar
added
[DO NOT USE] Awaiting Director
|
@plehegar, see @samuelweiler and @pes10k confirmations at: |
|
The CR duration requested is 28 days (minimum). Expectation is to have 2 implementations of all conformance requirements. |
|
Transition approved. |
swickr
added
Awaiting Publication
|
(I'm on a vacation right now that ends next week, so won't be able to publish it this week.) |
|
@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. |
|
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 w3c/geolocation#121 |
|
Apologies, I was in the wrong thread. I thought was writing in the thread about Ambient Light Sensor API. Please ignore my earlier note. |
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
The text was updated successfully, but these errors were encountered: