Background GeoLocation/GPS support
As Edge Developers are about to begin implementing Service Workers and the Push API, can I please implore you to consider implementing the following functionality at the same time?
The proposed GeoFencing API is dead in the water and requestWakeLock() is a battery unfriendly sledge hammer to ***** a nut.
The Solution: -
I propose a new W3C standard implementing a "TravelManager" and exposing the interface to ServiceWorkers. This interface would be very similar to the existing PushManager interface. E.g. ServiceWorkerRegistration.travelManager (getSubscription(), permissionState(), subscribe())
The subscribe() method with take options such as (minMsecs/metersl between position updates, accuracy, etc)
A new ServiceWorker "Travel" event will be created. The UserAgent must be able to re-instantiate a previously terminated ServiceWorker on the strength of this event.
Power consumption mitigation: -
1) The Web App is allowed to sleep as it does now ABSOLUTELY NO requestWakeLock("gps") required.
2) Although Android mandates that it "can" terminate a browser at any time, a well resourced device need not terminate Service Workers as soon as the event Loop is empty. This allows a single SW to service many GPS readings and forward them to a server in a single instance/lifetime.
2) If no browser/user-agent instance is active then it should NOT be run-up in order to accept the GPS. Thus the user is always capable of guaranteeing an end to tracking by killing the browser.
User-empowerment, transparency, and governance: -
1) User permission must be explicitly granted before GPS is accessible.
2) While GPS is being watched, even in background, the circles/ripples icon cue is visible to user on the device.
3) The underlying Service Worker architecture mandates the use of secure/authenticated httpS communication.
4) The user can be 100% sure tracking is off by simply closing the browser on their device.
5) The manifest-resident gcm_sender_id (Google Project Id) can be revoked/voided if a site is behaving badly
Other Options: -
1) Only permit background/service-worker GPS access if the Web App is installed/home-screened?
2) If a single GPS permission will cover both background and foreground access, then put a link on the permission-toast pointing to the Faustian details?
3) Use a new icon, perhaps an eye or a doughnutted version of the current GPS ripples? Pulse the icon?
Similar conundrums so that Service Worker GPS is not singled out unfairly: -
1) Firefox currently continues to process watchPosition events in background
2) All browsers except IE and Chrome continue to watchPosition when phone is locked but browser tab in foreground.
3) The proposed WAKE-LOCK and CPU-LOCK will backdoor user-tracking
4) The proposed GeoFence API, as it stands, will be another backdoor to user tracking
5) Native Apps can do this with impunity
6) Push Messages must be required to trigger a notification so as not to be silent/stealthy.
7) Geofencing is still tracking! Knowing when my next victim leaves their house each Tuesday is still an intrusive invasion of one’s privacy if it has not been sanctioned. Surely the degree of “badness” is not the issue here?
8) Speech synthesis API and microphone access
PS. Mozilla is also floundering: -
Please get on board with this essential HTML5 functionality!
As promised/threatened. The TravelManager.PollyFill.js file is all Edge developers need to implement in order to be the first browser out there with supportable background geolocation. See aaa_readme.txt here: - https://drive.google.com/drive/folders/0B7Rmd3Rn8_hDNW1zSWRoXzBTclU
David Storey [MSFT] commented
Previous comment deleted for name calling. Please stay civil.
David Storey [MSFT] commented
Where is the link to the spec being proposed to be implemented? Discussions on a proposed new spec should happen at https://discourse.wicg.io
This is where it hooks in: -