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

[Richard Maher]

I found a very interesting, and inspiring quote today that I'd like to
share with you: -

https://twitter.com/jaffathecake
Googler. "I want the web to do everything native can, and fast."

So  can anyone here explain to me how that precludes device/user tracking?
Or how HTML5 Web Apps can not be available today with the same
functionality as Uber, Domino's, GrindR, FaceBook, tomtom?

What the hell are you waiting for?

Here's a couple more platitudes to get you through to the next F2F plenary
junket: -

https://twitter.com/jaffathecake/status/633621917547778048

"The web should look to increase its advantages while reducing its
disadvantages. Native is doing this too. If the web stops, it dies."

"The web doesn't need to be better than native at everything, it just needs
to be close enough that the gap in certain areas doesn't matter."

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

[Richard Maher]

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 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”. 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 examples 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.

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

[Richard Maher]

@martinthomson 

I hate to make this a point of jurisdiction, but I think that this is a
discussion that needs to be had in the geolocation working group.

I've been careful to avoid any demarcation issues by always involving the
Service Worker AND GeoLocation communities. My lobbying has centered on: -

Forums:
https://github.com/slightlyoff/ServiceWorker/issues/745

https://github.com/w3c/geofencing-api/issues/25


Mailing Lists:
public-webapps@w3.org
public-geolocat...@w3.org

If there are better forums then please let me know.

Having said that, I am becoming more and more convinced that this is a
Service Worker issue. The following is what I believe is required to make
this work: -

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.

One GeoLocation watcher per UserAgent sounds battery-friendly to me!

I'm very nervous when someone saves their hands when it comes to the
privacy story. The web has thus far had a great accountability story and
adding the ability to track someone when they aren't visiting your site is
one capability that could easily undermine all the good work we've done.
I'd want to see a clear plan for how a user is able to remain in control to
be even remotely comfortable that watchPosition could be exposed.

God gave us valium and SSRIs for just such occasions. Either way please
don't FUD a technical forum with tales of "There be dragons".

Users are running a WebApp and NOT "visiting your site". Permissions are
there for just such a requirement. BTW I tested Firefox last night and it
is the only browser that DOES continue to track you when the browser is in
the background.

But can I ask where have you articulated your fears about WAKE-LOCK and
CPU-LOCK back-dooring user-tracking functionality? What about the new
GeoFence API? If I throw a 5m GeoFence around my current location and get a
"leave" event then surely I can just drop that geofence and recreate
another around my new current location. What is that if not user-tracking?

Most importantly, can I stress that this is a user REQUIREMENT and not an
IMPOSITION! Ask all the permission questions you want but this simply has
to happen.