Re: [geolocation] New Working Group Technical Report - Background GPS

Addendum (Sorry)

Other Options: -
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?

On Wed, Feb 17, 2016 at 9:42 AM, Richard Maher <maherrj@googlemail.com>
wrote:

> 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
>
>
>
>