Re: [geolocation-api] Require user activation to use API (#48)

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 it, 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.

Security:

There a 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 we 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.

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


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 18 January 2023 14:36:56 UTC