new type: location?

[chaals]

This is sort of subsetting #86. When I want to keep collecting location information, I don't necessarily want the rest of the system to run - in particular, although wifi, gps and phone connection may be used to provide location information, it's not clear that I want other external things to keep running, and when I want my system not to sleep - e.g. because it is playing music - I don't necessarily want to leave on the rest of the system, especially battery-intensive stuff like various interfaces for shifting data over the air, or privacy-impacting stuff like tracking my location.

Does it makes sense to use wake lock for background location tracking - and how do we implement this? Obviously it's one of those painfully privacy-sensitive interfaces that potentially affect personal security in a big way, but also offers lots of useful functionality.

See also https://github.com/w3c/ServiceWorker/issues/745

[patrickkettner]

feels like this could be an option for the Permissions API. E.G,

navigator.permissions.query({name:'geolocation', background: true})

[dontcallmedom]

my personal perspective is that wakelock is an ill-fit for background location tracking, if only because of the complexity of the permisionning.

Note that using sensors in the background is also something that has been discussed as part of (the next version of) the Generic Sensor API.

[MeritBased]

@dontcallmedom I doubt many would disagree [ I only know of one :-( ] that a Wake Lock is unsuitable for background Geolocation.

Please note the Background Location "Fleet Management" business case. The UWA may not have to be aware (once permission is granted or periodic toast) that it is happening, Geofencing is also inherently a Server Based function. If the user has traversed a boundary then a notification can be sent if need be.

@chaals can I please ask you to consider looking outside the W3C/IETF opinion pool for solution and design ideas on this?

Stackoverflow for example: - Background Geolocation ServiceWorker - onMessage Event order when Web App regains focus has over 430 views and 12 votes and the answer a further 2 votes. Expected ratio of ServiceWorker instances to Geolocation Updates has 126 views plus 5 and 1 votes respectively.

The source-code for the TravelManager POC and polyfill, along with an aaa_readme.txt, can be found here

If you wish to see the example without copying then, after reading the readme file, run the Ultimate Web App from Brotkrumen

The CPU Wake Lock may well be all that is needed for other/true sensors but Background Geolocation needs the Service Worker Travel Manager!

[anssiko]

@chaals, this issue is being discussed in https://github.com/w3c/sensors/issues/323 in the broader context of sensors, not just geolocation.

That said, Geolocation is a candidate to be remodeled atop Generic Sensor API, for which background operation is a v2 feature. So if the stars align, we'd get background geolocation through Generic Sensor-based Geolocation, but there are unresolved security and privacy issues in allowing powerful features in background. We have to document and solve them first before we get to that future. Background operation is to be discussed in https://github.com/w3c/sensors/issues/106 (Generic Sensor API v1 reached 0 bugs just a while ago, and we're just ramping up with v2 issues, so bear with us).

I will close this issue to avoid duplication.