Re: [ServiceWorker] Expose GeoLocation to workers (#745)

Look I %100 acknowledge the problem(s) @martinthomson  highlights, and the need to prevent abuse from the black hats. All I’m saying is let’s work the problem rather than simply rocking in the foetal position, or worse, concocting artificial and exaggerated speed-humps on the release path of much needed functionality.

On the plus side: -

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.

I personally think the above is enough, but for the sake of argument, does anyone have thoughts on how access may be further governed?

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

Also, can I list 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. 
6) Fat Client, heuristically-challenged, 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.

Are these design smells not beginning to make people think twice?

Finally, to address some of Martin’s comments directly: -

> Tracking the user in the background is highly likely to be a case of a site acting poorly.

Unsubstantiated, conjecture, hearsay, prejudice, and FUD :-( 

A plethora of valid business cases and user-requirements have been portrayed for all who are willing to see. We must find a way to satisfy these legitimate requirements whilst fire-walling against malicious intent.

> I want to ensure that the user remains in control; 

Here we are in violent agreement! See the “plus side” above. How more empowered can the user be?

Look, I enforce my right to privacy more than most, I can assure you! I am not on FacePlant, LinkedIn, etc. I do not use my real photo on the net. I pay cash everywhere I can, and wish I could stop my card having Tap-n-Go. But @MulderAndScully I do not wear a tin-foil hat.

> I don't believe that asking users for permission is sufficient to that end for some types of features. This is one of them.

Can you please give me example of one or two other features that you felt failed your test? How did you get on overturning the SpeechRecognition API and access to that microphone?

The Service Worker developers must love all their children equally! Just because the blue-eyed boy of GeoFencing turned out to be the milkman’s mongrel doesn’t mean that your GeoLocation Cinderella can’t go to the ball.

Let’s get on with it – please.


---
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/745#issuecomment-183159534