- From: Carlos Lopez via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Sep 2024 13:41:26 +0000
- To: public-device-apis-log@w3.org
Persistent access to device features while being in the backwards is *one of* the goals of [System Wake Lock](https://github.com/w3c/system-wake-lock/). The topic of some indicator (eg: Persistent Notification) is of discussion there as well. I'm personally not interested in geofencing though can understand unprompted location access. * Retail store noticing you entered an area * Storm tracker notifying you of lightning strikes near your location * Travel history logger (eg: Google Maps Timeline) To note, all of this should be able to be done with some manual opt-in method. The interval at which applications poll the geolocation is already defined in spec. If an application can be hold a "wake" state, then it can react the location updates. As for automated tracking, without an manual, per usage opt-in, I'm personally not interested this. That would be something like a Service Worker that can listen for push notifications, but instead of pushed notifications, it's pushed locations. That would the "sensible" way to do this, but I think *at least* tackling manual opt-in (eg: wake lock + notification) would happen well before an automated push of geolocation to some service/application. I don't see much traction in Wake Lock, but maybe it seems that would be the first step to implementing the background, non user-initiated location requests. TL;DR: Users should be able to manually start and stop background geolocation before it can be done automatically. -- GitHub Notification of comment by clshortfuse Please view or discuss this issue at https://github.com/w3c/geolocation-sensor/issues/22#issuecomment-2343710980 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 September 2024 13:41:27 UTC