1249130 - Background GPS tracking support

Status: RESOLVED INVALID

(Core :: DOM: Geolocation, defect)

Description

[Richard Maher]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36
Firefox for Android

Steps to reproduce:

Neither the current Navigator.geoLocation.watchPosition() https://developer.mozilla.org/en-US/docs/Web/API/Geolocation/watchPosition
or the proposed GeoFencing API https://www.w3.org/TR/geofencing/ are capable of delivering the functionality required by Fleet-Management, Social-Networking, Gaming, and Risk-management web-apps today.



Actual results:

The Chromium GeoFence implementation has floundered: -
https://code.google.com/p/chromium/issues/detail?id=383125

WatchPosition can be simulated by throwing a 5m geofence around the current position and when a "leave" event is fired then simply drop and re-create the fence around new position.

Just the proposed restrictions on the GeoFence API that I know about: -
1) Maximum number of geofences
2) Only circular geofences
3) Maximum area of a geofence
4) Minimum area of a geofence
5) (Soon to be?) Cannot create a geofence in a service worker. At least around current location. 
6) Fat Client, localized, geofence processing
7) A technology born of a time when Java was king and batteries were the size of a brick and lasted just 2 hours.



Expected results:

WatchPosition() no longer functions in the background (See: https://code.google.com/p/chromium/issues/detail?id=506435 for earlier discussions)
The proposed client-device-centric and heuristically challenged GeoFencing standard is incapable of providing what myopia-free server-based geofencinbg can do with dynamic fencing and the complete picture of all the players, people, trucks, pizzas.

Comment 1

[Richard Maher]

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 an 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?
4) When the device goes to sleep when a Web App is still watching GPS, or simply backgrounds or minimizes a device-tracker, it should make a sound and or vibrate as a non-visual cue that tracking is ongoing?
5) When a device is reawakened or a device-tracking app is brought back to the foreground, then a notification must be sent to the user "This App continued to monitor your location in the background". The "Settings" icon on the message could facilitate "Prevent this app from tracking in the background" Forever/Just once.
6) Like the Push API the default must be DO NOT track in the background. If the user chooses the individual APP settings then they can turn it on? 

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: -
https://bugzilla.mozilla.org/show_bug.cgi?id=1216148
https://bugzilla.mozilla.org/show_bug.cgi?id=784505

Please get on board with this essential HTML5 functionality!

Comment 2

[Josh Matthews [:jdm]]

This sounds like something that should be proposed to relevant standards groups, rather than filed as a bug here. Since it's based in ServiceWorkers, try https://github.com/slightlyoff/ServiceWorker/?

Comment 3

[Richard Maher]

Josh,

I have already registered this proposal with that forum/group.

Given that the amount of Mozilla development time and resources that have been squandered on related fencing wire and duct tape like this: -

https://bugzilla.mozilla.org/show_bug.cgi?id=1216148
https://bugzilla.mozilla.org/show_bug.cgi?id=784505

not to mention the Mozilla effort currently going implementing the failed GeoFencing standard, I would've thought that you could have left this report ope for a couple of weeks to see what people had to say :-(

I've run it up the flag-pole. If no one salutes in the next two weeks I'll close it myself.

Comment 4

[Josh Matthews [:jdm]]

Bugzilla's the wrong place for proposals like this, though. We're certainly not going to implement this without buy-in from other vendors, and those discussions happen on mailing lists.

Comment 5

[Richard Maher]

GPS Tracking Use Cases: -

* Can I beseech the browser-developer community at large to please contribute their own use cases to this thread?

1) University security have just been told there's a shooter on campus. They touch the google maps screen and tell the system to warn everyone in a 2km radius to get out or get down. The geoFence has only just been created. Pushing the details to the client won't help you because the architects are currently considering banning creating a geofence around current position as it facilitates quasi-tracking. What's more is the time, bandwidth, CPU, and baterry-power wasted pushing a geofence to ALL users when most of them are not effected by or resident in the danger zone.

2) I want to track my jogging and bike-riding journeys to share with friends and manage calories-burned and effort.

3) I want to know when members of my coffee club are getting close so I can start ordering.

4) Let me know if bad weather is moving in.

5) The library is closing. The librarian sends a push message to anyone in the building (who hopefully have their notifications on vibrate :-) giving clients 15mins to finish up.

6) The next 10 customers to the Guild Tavern get a free beer. No use having permanent geofences around every retail establishment that may want to communicate with customers.

7) How about a trucking or taxi company wants a central head office PC constantly tracking fleet movements in real-time.

8) Pizza Co. want to let users see where their pizza van is. The van driver doesn't have to have his phone screen on killing his battery for Pete's sake.

Look, I'm not paranoid enough to suggest that W3C members are on the take from the Native App providers but, Service Worker developers are simply being obtuse if they continue to deny the requirements for location tracking and not just a hamstrung, debilitated geoFence API. The requestWakeLock() method has it's uses for those who don't care about battery life. User/device tracking Apps is not one of them.

The devolved decision-making paradigm inherent in the current GeoFencing model is simply incapable of satisfying the legitimate business and user requirements. User's want to know more than "Elvis has left the building"!

Comment 6

[Richard Maher]

Re #4 "We're certainly not going to implement this without buy-in from other vendors, and those discussions happen on mailing lists."

But then why have we implemented the B2G band-aid solution of the WakeLock("gps") as described here: -
https://bugzilla.mozilla.org/show_bug.cgi?id=1216148
https://bugzilla.mozilla.org/show_bug.cgi?id=784505

What's more why has Mozilla simply turned a blind eye to the unauthorized tracking capability in FireFox that they have acknowledged yet continue to make available to estranged spouses, unscrupulous employers, and information hungry supermarket chains?

Regardless, if my pre-emptive strike here stops Mozilla from wasting resources on the soon to be defunct GeoFence API that has had "buy-in from other vendors" then is that not a god thing?

I am lobbying the standards people as well: -
https://github.com/w3c/geofencing-api/issues/25
https://github.com/slightlyoff/ServiceWorker/issues/745

Hopefully, when they're finished their "F2F time at TPAC", my proposal will gain traction. I too would like to shoosh the hills of Sapporo after the brewery tour but I'm at the Web Developer coal face with all the other shmucks. I'm not accusing anyone of running around like FIFA or the IOC but I do question the focus of some W3C members.

But the GeoFence API won't really hit the fan until Mozilla stops propping up Apps/Sites that currently rely on FireFox's inherent vulnerability. For the life of me I cannot understand engineering's complacency.

Comment 7

[Richard Maher]

Cross reference Chrome bug report: -
https://bugs.chromium.org/p/chromium/issues/detail?id=383125

Comment 8

[Doug Turner (:dougt)]

Thank you Richard for your interested in discussing these topics!

However, as others have stated, bug tracking systems is not meant for discussions.  This is just the way the way we do things and not a reflection on your proposal.  I do encourage you to take this use case to the w3c geolocation wg.  When accepted, we can start work in a bug to implement.

Comment 9

[Richard Maher]

No worries. Thanks for the couple of weeks.