[geolocation] New Working Group Technical Report - Background GPS

Hi,

I have no experience with how a W3C standard gets off the ground, or an
existing standard gets modified, but it would appear that a Working Group
Technical Report is required. Either way, none of the browser manufacturers
seem keen on implementing this functionality without W3C involvement so I
implore you to look at my proposal to enhance to the GEOSPATIAL and
JAVASCRIPT APIs standards for background device-tracking.

NB. These are Apples and the proposed GeoFencing API are Oranges. I am
happy to explain that claim at anytime.

If someone will volunteer to pick this idea up and run with it the HTML5
Web App world will be a much better place!

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?

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

Thanks for listening.

Cheers Richard Maher