W3C home > Mailing lists > Public > public-device-apis-log@w3.org > April 2021

Re: [geolocation-api] Restrict to user-activation-received frames (#48)

From: Marcos Cáceres via GitHub <sysbot+gh@w3.org>
Date: Thu, 08 Apr 2021 02:53:37 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-815407500-1617850415-sysbot+gh@w3.org>
 > I also don't understand how this accounts for watchPosition, which could just as easily be invoked in place of several getCurrentPosition calls, right?

Correct. Why it probably has to be API wide permission grant, like other APIs. That's also how it's currently spec'ed: check permission on every call, including on the looping "[request position](https://w3c.github.io/geolocation-api/#dfn-request-position)" that is created with `watchPosition()`. That way, `watchPosition()` gets stopped if the user takes away the permission. 

> Maybe we should gate the prompts instead of the whole API and the more privacy-focused browsers can just switch their prompts away from permanently granting permissions?

Not sure I fully understand this, but yes. :) 

> As @marcoscaceres mentioned, with permissions policy I don't really see the point of differentiating between frames or not anymore, we should make this consistent for the whole API, IMO.

Agree. I like the proposed transitional path of the silent prompt (or similar transitional UX mechanism), even if it takes a few years. Should we just aim to gate the whole thing on user activation? 

GitHub Notification of comment by marcoscaceres
Please view or discuss this issue at https://github.com/w3c/geolocation-api/issues/48#issuecomment-815407500 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 8 April 2021 02:53:39 UTC

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:58 UTC