The Blink engine already requires a page to be visible in order to receive callbacks from the Geolocation API. I support adding this behavior as a normative requirement to the specification assuming that other implementations are on board.

What are your thoughts about requiring a user-activation-received frame vs. requiring a user activation to request geolocation permission?

The Blink engine already requires a page to be visible in order to receive callbacks from the Geolocation API. I support adding this behavior as a normative requirement to the specification assuming that other implementations are on board.

🤗

What are your thoughts about requiring a user-activation-received frame vs. requiring a user activation to request geolocation permission?

I think these are both important. The latter makes it clear(er) to the user what site / party is making the permission request, the former reduces the ability for the capability to be misused over the long term.

The Blink engine already requires a page to be visible in order to receive callbacks from the Geolocation API. I support adding this behavior as a normative requirement to the specification assuming that other implementations are on board.

That sounds really neat. I'd be onboard with implementing that if we don't already do it in Gecko.

What are your thoughts about requiring a user-activation-received frame vs. requiring a user activation to request geolocation permission?

That could be fun... though I imagine it's gonna break a ton of sites :D

cc @cdumez for input on this from WebKit.

We could also consider restricting geolocation access to active documents whose origin is same origin-domain with the currently focused area document. There are obviously compatibility risks here as well, partially overlapping with those associated with the user-activation-received requirement. Similarly to what we did before restricting APIs to secure contexts, we probably need to add telemetry to measure the expected breakage first.

As the volunteer handling this review for PING, I want to make a record here that I agree that this is an important protection.

FWIW I made a simple test page (https://output.jsbin.com/yapihuf) for checking if a site with geolocation API access granted can get location updates while in the background. WebKit and Blink both don't allow it while Gecko currently does (on both desktop and android). I opened a bug report for Gecko here - https://bugzilla.mozilla.org/show_bug.cgi?id=1653549 .

Thanks for verifying, Konrad!

Given that Blink and WebKit already require the page to be visible, there seems to be little to no compatibility risk to imposing this requirement. And as per Marcos's comment, Gecko is also on board with implementing it. In light of that, making this behavior a normative requirement in the spec sounds reasonable to me.

The user-activation and focused-area requirement will probably need more discussion and compatibility risk analysis.

Thanks too @kdzwinel !

And just to avoid possible confusion, my proposal isn't to require the frame to be focused to receive updates (though thats appealing too); just that it received an activation at some point during the parent frame's lifetime

Thanks for filling the Gecko bug @kdzwinel.

Two common signals that should be incorporated into the spec are that frames need to be visible,

I think we should definitely spec this one...

and to have received a user activation before they can access location information, even if the frame was previously given permission.

This can probably be handled by the UA (see how Firefox dealt with push notifications), as this would break too much stuff.

Closed via b1fac55.

@marcoscaceres i can't find where in the commit addresses the user-activation-received frame. Can you direct me to that part of the new text (apologies if im missing it in the diff)? Otherwise i'll reopen the issue while that part of the issue is still being discussed.

Oh, we are not spec'ing the user-activation part (no one implements that!), only visibility detection. Sorry for the misunderstanding.

Enabling geolocation in third party contexts requires a Permissions Policy.

I see, thank you for the clarification @marcoscaceres . Im thrilled about the visibility detection change. I'm reopening the issue though, since the user-activation part is also an open concern i have with the spec (since it could allow unintended, ongoing privacy loss w/o the change, given the rest of the spec as is)

Happy to keep this open, as I think requiring user activation to enable geolocation on third-party frames is a sensible idea. However, unless it gets speedy implementer backing, it's not going to be part of the upcoming publication - though once we have this on a living standards track, we can republish with new features every six months or so.

Having said that, let's get some input. @pes10k, are you willing to see if the Blink folks would be open to adding this?

@martinthomson, @cdumez, thoughts? Or would you prefer @pes10k file a request for a standards position elsewhere?

We've looked into requiring a click or keypress for this API and we're broadly supportive of adding that requirement. However, there is a non-trivial amount of bustage associated with doing so and we haven't spent the time necessary to sort out how to deal with that. There's definitely a lot of annoying spamming going on here - I experienced this with the website of my bank today when looking for a branch - but we don't want to break pages that follow this practice without some sort of plan to manage the transition.

Adding @johannhof who has more context than I.

Right, we looked at this in 2019 as part of our project to reduce notification permission spam. We also measured Geolocation and found it, IIRC, slightly less bad (in terms of prompt "success rate") but still bad enough that it would warrant attention. For notifications we did a report that showed a good correlation between user acceptance and prior user gesture, however we did not do the same analysis for geolocation. We should still have the data lying around, I think, so it wouldn't be impossible to do.

In any case, if I understand correctly, this issue is less about reducing prompt annoyance and more about the privacy/security aspect of "background" geolocation access, so as @pes10k mentions we'd have to gate the entire API on user gesture, even with a permanent permission. From a Firefox perspective that should probably be fine. Firefox gives out geolocation permissions as one-off by default anyway. So gating permission prompts vs. gating the API only matters for the small percentage of users who opt into permanent permission. It could still lead to breakage but overall for Firefox not much more than when gating the prompts on interaction, which again is something we're interested in.

What we would probably do (at the very least during the transition period) is show a "silent" prompt like the ones both Firefox and Chrome have adopted for notifications recently when user interaction permission was requested without gesture.

However, that way we can't un-break the edge case where the user gave a permanent permission but the API wasn't invoked with user activation, which is annoying. I also don't understand how this accounts for watchPosition, which could just as easily be invoked in place of several getCurrentPosition calls, right?

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?

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.

I'll add my agreement from a Chromium perspective that this has the potential to be a significant breaking change, especially if the user activation requirement applies to previously granted permissions in addition to requesting new permission. A similar change was made for audio playback and caused a lot of trouble for users and developers.

I think the work on notifications is a good model for approaching this in a way which doesn't harm compatibility. For permission requests, for example, a site without user activation could trigger the "silent" permission prompts that browsers have been experimenting with while a request with user activation can trigger the normal prompt. This could push developers away from requesting permission without a user gesture and therefore reduce the compatibility impact.

I also agree with @johannhof's hypothesis that one-off permission prompts will reduce the impact of this change. Chrome is experimenting with this change as well. Once that has launched we can collect data on the impact of this proposal in a world with shorter-lived permissions.

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" 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?

There is now an initial pull request at #94. Let's keep discussing a concrete proposal there.

Just saw this in my Chrome console: -

TravelManagerPolyfill.js:117 [Violation] Only request geolocation information in response to a user gesture.

I beseech you not to do this! You will break the Web and set the PWA cause back irrevocably.

Can I ask where the ground-swell of demand is coming from? Justification?

Will the "gesture" be required before/after the "Web-Site wants to access your geolocation" prompt? Instead of?

Before launching another Pol Pot "year zero" program, please engage with the Developer/Vendor community and be the least bit pragmatic enough to accept we are where we are. What exactly are you hoping to achieve: -

I've got a prompt that says "allow geolocation ok/cancel" then I add an onclick listener to cancel that says "you bewdy! I can now ask for geolocation" :-(

That warning has been in place for many years. Everyone involved here has acknowledged above there is a significant risk of introducing incompatibility by making this change. The first step is to add the necessary metrics to browser implementations in order to understand the impact of the change and whether any developer outreach efforts (such as this warning) have had an effect on the frequency of gesture-less requests for geolocation.

Here's a perspective from a "real-world" application:

For somebody who has been writing fleet management applications for about 20 years, this is the main drawback to PWAs versus native, and probably the last real complaint users have, and I was again asked to find a solution by my clients.

Issue:

When users are on the page, we can track the vehicles remotely as it sends the live position to the base station. When users start navigating to destinations via Google Maps/Waze/Apple Maps, they stop transmitting their position, only to pop up minutes (or hours later) when they come back to the application. Even from a non-beaconing context, we would like to estimate ETA while the driver is on-route. Also, geofencing is useful for auto-marking driver arrival (ie: getDistanceFromDestination() < 10m).

Possible Workaround:

Having read that Firefox didn't impose this limitation made me about to recommend to switch to Firefox for our Android users, but seeing that it's been stopped there, is the group's advice here to just completely drop PWA and move to native if we want this feature? We left native about 7 years ago for PWA.

Activation:

Activation is really not a concern of mine since we can use navigator.permissions.query. We don't have a permission spam issue because we setup permissions during the onboarding setup at PWA installation time, so I don't mind being there a background/inactive permission. Also, we care little about true background (service-worker) since we don't care to track people not actively using the application.

Document Visibility:

document.visibilityState shouldn't be the criteria. What we want the avoid is silent background tracking. While the document is inactive, we can still get Audio (SIP calls and Text-To-Speech alerts) and JS continues working with EventSource. But even that is a kinda awkward since there is no user notification that a PWA is still running in the background. Android solves this for native applications by having applications persist and force a foreground notification.

Are PWAs windows always "active"? In tabbed environments (browser window), only the current window active? For example, with Chrome PWAs that are installed on Desktop, document.visibilityState turns to hidden if a window is open, but fully occluded. Is this the right intention? If I cover a PWA window fully with, say "Notepad", geolocation should stop? From spec:

It represents, for example, whether the browser window is minimized, a browser tab is currently in the background, or a system element such as a task switcher obscures the page.

User Activation:

User-activation, as defined in spec, seems close to what I could work, assuming I can make applications just as "sticky" as in Android native. It's a good "first-step", but I would also need something to help extend isActive because users can be away for minutes not just seconds, but still hear alerts from the background app.

Implementation:

I have no problems having to jump through hoops to get it done. Having multiple permissions isn't a problem. Having a persistent notification also isn't a deterrent. What matter is having an API to get it done. If it has to be a PWA (windowed) context, that's also fine. HTTPS is also not an issue.

Security:

There are real world consequences when APIs don't exist or aren't implemented. For example, because of the way Safari Mobile handles geolocation permissions and didn't have navigator.permissions.query pre-Safari 16. Users were prompted each and every time they launched the app for Geolocation permissions and must hit Allow every start-up. Because Safari took a negative-first approach, if the user denied once, they were locked out forever of Geolocation and had to uninstall and reinstall the PWA. This caused such a negative experience (having to constantly reconfigure devices) that the real-world solution to this was to set Safari to allow geolocation on ALL sites without asking. It's a horrible solution, but a necessary one to work with the platform. So take considerations like this into account where you may believe you are "keeping a platform secure" by restricting something, but in reality, just forcing users to drop security to workaround limitations.

What if, for .getCurrentPostion() we made it so the arguments are optional.... if no arguments are passed, we vend a promise, but require user activation. That gives us a transitional path forward without (hopefully) web compat issues.

There is some precedence for this.. Notification API has:

static Promise<NotificationPermission> requestPermission(optional NotificationPermissionCallback deprecatedCallback);

I would also like to transition this API towards a Promise-returning style but I think tying this to a user activation requirement will incentivize developers to keep using the old style.

I think the page embedded permission control will provide a better user experience for permissions like geolocation overall. Once we have signals about whether developers are able to adopt it (including its user activation requirements) then we will have better data on whether we can make this change.