Expose GeoLocation to workers

[joemarini]

Scenario: SW receives a push event, and my handler wants to check the current geolocation so I can warn the user about a potential nasty weather issue in their area.

[mvano]

How do you think the privacy and security aspects of this should be handled? It's not trivial to permit precise background location tracking.

[joemarini]

Agreed - filed this at AlexR's request, they will work these out in spec.

[mkruisselbrink]

It doesn't sound like you need the actual current geolocation for that usecase? You just want to know if the user is in a specific area, so adding a geofence should be enough for that, at least as it is currently specced. That still has the privacy and security aspects of course. We haven't quite worked out yet what should and shouldn't be allowed with respect to registering geofences from a service worker while there are no clients currently shown.
Also maybe the list of potential areas is too big to actually register geofences for all of them, so I agree that having a way to get the current position from a service worker could indeed be valuable. I'm not convinced that having a way to watch the current position is something that we want to expose to service workers though. Certainly not if that would mean constantly waking up/keeping up the service worker while somebodies device is moving... There are of course usecases for background location tracking, but I think some kind of API where chrome does the tracking and only passes on a complete track would be a much better API for service workers.

[joemarini]

The use case that the travel partner gave me was "user gets on a plane in Vancouver, checks weather. Puts phone away. Flies to Boston, gets weather alert for storm in Boston, not Vancouver." Also, if the user is driving across the country or state, it wouldn't be practical to pre-set a geofence for the whole way.

It seems like if this was properly badged in the UI and the user knew it was happening, it could be made more secure.

[mvano]

Where would one badge this in the UI? The API would run in a service worker in the background, so the badge would be the only UI surface. Especially on mobile, screen space is limited. A permanent indicator like a notification might be too much. A tiny icon in the status bar (that cannot be interacted with and has no text) might be too little.

A list of possible UI requirements might be:

• The user can understand what it means
• It is discoverable
• It is not too distracting from other activities
• Attribution: it indicates which origin is using the API
• Permission revocation: the user has a path from the indicator to revoke the permission
• Battery blame (how much was used by this API)
• Does this UI pattern scale to work with other APIs? What if there's a dozen of them?

I don't want to solve the UX in this thread, but I do want to point out that this is tricky. It might not be worth the trouble unless we find more common use cases.

[ManuelB]

Hi,
I am working in the agriculture business. During a crop season it is necessary for all the farmers taking part in a harvesting task to see each other on a map to be able to join somebody who isn't done yet with his field. Harvester and transporter are working closely together.

Further the traces are used afterwards to generate precise work logs to see where the harvester have been and how long it took to harvest a particular field. Traces are also used to make sure that chemicals are only used on the allowed field.

There are already multiple native solutions to solve these problem but it would be awesome if this can be solved using a native API.

So technically what I need is an API that I can tell that it should send reliable message with the position of the device to a given URL for a certain timeframe. If the device is offline it will collect the message and the next time it is online if will send all messages in the queue. The message should expire after a given time.

When the browser asks to do this tracking the user should be asked if he wants to allow the particular website to track his position for a certain period of time.

Hope that use case helps to enhance the APIs.

/Manuel

[mkruisselbrink]

The use case that the travel partner gave me was "user gets on a plane in Vancouver, checks weather. Puts phone away. Flies to Boston, gets weather alert for storm in Boston, not Vancouver." Also, if the user is driving across the country or state, it wouldn't be practical to pre-set a geofence for the whole way.

I do fully agree that "Get the current location" might be something we should let service workers do, but to solve that particular use case with geofencing you'd set a geofence for the current location, with some reasonable radius, which would then wake up the service worker when the user has moved that far away.

[mkruisselbrink]

I'm not quite planning to actively work on any of this (other than the geofencing API I'm working on), and the UI issues are definitely non-trivial to solve, but I started trying to write down some of my thoughts on what the space of use cases for "geolocation in service workers" looks like, and what kind of APIs might work to address which use cases. That (not very well thought out) attempt can be found here.

[jakearchibald]

The fitness tracking case (and I think @ManuelB's case) can be solved using standard pages, perhaps with the addition of some kind of "pinning" API that keeps the page alive.

This doesn't solve @joemarini's case though. @joemarini: why is the location check triggered by a push message?

[ManuelB]

@jakearchibald I agree the important point is that I need to run a background task. We already build prototypes using WebSockets and watchPosition that worked well but the problem is as soon as the browser is suspended, closed or somebody calls the action is interrupted.

[RichardMaher]

@ManuelB I fully acknowledge and accept your business requirements and use case.

Here is a similar one for you. I have students on Campus who want to see who from their coffee-club or study-group is on Campus. If there waiting for someone they want to receive a notification when the arrive. GeoLocation.watchPosition must be empowered to re-instantiate a SW that has been terminated.

The SW will interrogate the location change event before XHRing the information to a central server. It is the server that decides which GeoFences have been traveresed and, if so, which users need to receive a Notification.

Privacy and Security is handled as usual by the manifest triggering user approval at installation time. The individual Web App with also ask for tracking-permission when the user accepts individual group membership.

Please also see my comments in this thread: -
https://github.com/w3c/geofencing-api/issues/25

[marcoscaceres]

@ManuelB I think what you want is the Wake Lock API... but with some additions we are yet to add to the spec: you could set a "CPU lock", which would keep the page alive, but would allow the screen to sleep (and maybe generate notifications as needed). Alternatively, you could keep the screen lock on - and just let the app run.

[RichardMaher]

@marcoscaceres I think you are being too end-user/device centric. I'll wager 3 sheep-stations and an oil-rig that Manuel's harvester drivers don't look at the phone from one field to the next yet the Farmer wants to be able to load the page at anytime and see a real-time feed of where his harvesters are and if one is heading home while Fred still has half a field to head then he'll ring him up and let him know.

How about a trucking company wants a central head office PC constantly tracking truck movements in real-time.

Dominos Pizza 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.

SW developers are simply being obtuse if you continue to deny the requirements for location tracking and not just a hamstrung, debilitated geoFence API.

User's want to know more than "Elvis has left the building"!

[RichardMaher]

@ManuelB Please be aware that, according to Mark (in the following Chrome bug report) Firefox, the Android Browser, Opera, and Safari already implement something akin to the CPU lock that Marco discusses: -
https://code.google.com/p/chromium/issues/detail?id=506435

I haven't tested Mark's claims which seem to be a complete alternative to Service Workers but FYI.

[ManuelB]

@marcoscaceres Thanks a lot I will look into it and report my findings.

[RichardMaher]

I found this a useful layman's reference for hardware support of geofencing: -
http://gpsworld.com/putting-the-ultra-low-power-in-geofence/

Explains a lot to me especially about power consumption,

I maintain that the SW architecture, in combination with any Android support for position batching, that subsequently offloads geo-fence processing to a central server in order to determine alarm/other processing for ALL users, is a viable if not preferable alternative.

Whether or not a wake-lock or cpu-lock is a retrograde step in power consumption, its implementation and availability pays homage to the user's right to self-determination. Likewise the user should be empowered to authorize GPS tracking while the phone is off.

Surely a myopic cluster of GNSS ICs is a less than optimal solution for fleet management or social networking, and an instance of functionality-devolution gone too far? IMHO, other than for monitoring prisoners on probation, the current geofence solution is a textbook case of the tail wagging the dog.

A Service Worker should be able to subscribe to a PositionManager optionally specifying min distance and/or seconds between updates to the position. A positionChanged event will be sufficient to re-instantiate a terminated SW.

Below is how I throttle GeoLocation.watchPosition now: -

Tier3Toolbox.prototype.LocationThrottle = 

    function(initHndlr, moveHndlr, standHndlr, errorHndlr, userOptions)
    {
        if(!navigator.geolocation) {
            throw new Error("Unsupported browser - No Geolocation support");
        }

        if (arguments.length < 4) {
            throw new Error("Insufficient call arguments");
        }

        if (typeof initHndlr  != "function" ||
            typeof moveHndlr  != "function" || 
            typeof standHndlr != "function" ||
            typeof errorHndlr != "function") {
            throw new Error("The Init, Move, Stand, and Error handler parameters must be functions");
        }

        var lastPos, trackerId, loiterTimer, deltaMetres,
            recalibrateTimer, lastOptions, lastDrop, replayTimer
            ;

        var MAXSILENCE    = 30;
        var watchCount    = 1;
        var acceptCount   = 1;
        var lastUpdate    = 0;

        var initHndlr     = initHndlr;
        var moveHndlr     = moveHndlr;
        var standHndlr    = standHndlr;
        var errorHndlr    = errorHndlr;

        var options, defMaxSilence, timeDetent, spaceDetent,
            loiterDetent, maxLocAge, accurate, maxSilence, lastOptions
            ;

        function moveReplay()
        {
            replayTimer = null;

            if ((lastDrop.timestamp > lastPos.timestamp)) {
                lastDrop.timestamp = Date.now();
                filterLocation(lastDrop);
            }                       
        }

        function loiterLimit()
        {
            loiterTimer = null;
            standHndlr.call(null);
        }

        var recalibrate = 
            function()
            {
                if (window.console) console.log("recalibrating");

                recalibrateTimer = null;

                if (trackerId) navigator.geolocation.clearWatch(trackerId);

                getCurrent(initAcc);
            }

        var getCurrent = 
            function(success) 
            {
                navigator.geolocation.getCurrentPosition(success,locError,{
                            enableHighAccuracy: false,
                            maximumAge: Number.POSITIVE_INFINITY,
                            timeout: 10000
                        });                             
            }

        var initLoc = 
            function(position) 
            {
                lastPos = position;     
                initHndlr.call(null, position); 
            }

        var initAcc = 
            function(position) 
            {
                watchCount++;

                trackerId = navigator.geolocation.watchPosition(filterLocation, locError, {
                            enableHighAccuracy: accurate,
                            maximumAge: maxLocAge
                        });

                recalibrateTimer = setTimeout(recalibrate, maxSilence);                 
            }

        var start =
            function(userOptions)
            {
                parseOptions(userOptions);

                trackerId = navigator.geolocation.watchPosition(filterLocation, locError, {
                            enableHighAccuracy: accurate,
                            maximumAge: maxLocAge,
                            timeout: Number.POSITIVE_INFINITY
                        });

                loiterTimer = setTimeout(loiterLimit, loiterDetent);
                recalibrateTimer = setTimeout(recalibrate, maxSilence);
            }

        var parseOptions =
            function(userOptions)
            {
                options       = userOptions || lastOptions; 

                defMaxSilence = (("maxSilence"  in options) ? options.maxSilence        : MAXSILENCE    );
                timeDetent    = (("minSilence"  in options) ? options.minSilence        :             0 ) * 1000;
                spaceDetent   = (("minProgress" in options) ? options.minProgress       :             0 );
                loiterDetent  = (("maxSnail"    in options) ? options.maxSnail          : defMaxSilence ) * 1000;
                maxLocAge     = (("maxAge"      in options) ? options.maxAge            :             0 );
                if (maxLocAge != Number.POSITIVE_INFINITY) maxLocAge *= 1000;
                accurate      = (("accurate"    in options) ? options.accurate          : true          );
                maxSilence    = defMaxSilence * 1000;

                lastOptions   = options;
            }

        var locError = 
            function(error) 
            {
                errorHndlr.call(null, error);
            }

        var filterLocation = 
            function(position) 
            {
                if (!lastPos) return;

                watchCount++;

                if (position.timestamp <= lastPos.timestamp)
                    return;

                var currTime = Date.now();                  
                var dropping = false;

                if (((position.timestamp - lastPos.timestamp) < timeDetent) ||
                    ((currTime           - lastUpdate       ) < timeDetent)) {
                    dropping = true;
                } else {                            
                    clearTimeout(recalibrateTimer);
                    recalibrateTimer = setTimeout(recalibrate, maxSilence);
                }

                deltaMetres = Tier3Toolbox.calculateDistance(
                                position.coords.latitude,
                                position.coords.longitude,
                                lastPos.coords.latitude,
                                lastPos.coords.longitude)

                if (deltaMetres.toFixed() < spaceDetent) {
                    return;
                }

                if (dropping) {
                    lastDrop = position;
                    clearTimeout(replayTimer);
                    replayTimer = setTimeout(moveReplay, timeDetent);
                    return;
                }

                acceptCount++;
                lastPos = position;
                lastUpdate = currTime;

                clearTimeout(loiterTimer);
                loiterTimer = setTimeout(loiterLimit, loiterDetent);

                moveHndlr.call(null, position, deltaMetres);            
            }

        var stop = 
            function()
            {
                if (trackerId) navigator.geolocation.clearWatch(trackerId);

                clearTimeout(recalibrateTimer);
                clearTimeout(loiterTimer);
                clearTimeout(replayTimer);
            }

        parseOptions(userOptions);                                      
        getCurrent(initLoc);

        return {start : start, stop : stop};
    };

[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. Thanks to @RichardMaher for bringing it to their (and my) attention.

This is a topic that has come up in the past and I think that I myself proposed that a single request for location was a fine thing. We did discuss the subject at some length.

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.

[RichardMaher]

@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-geolocation@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.

[mkruisselbrink]

@RichardMaher I totally agree with @martinthomson that none of this is really a service worker issue. All of what you describe is about features build on top of service workers, so the geolocation working group would most definitely be the correct location to actually pursue this.

Having said that, what you describe does sound very similar to parts of the API I sketched in #745 (comment) (and https://gist.github.com/mkruisselbrink/d0d38b38979a37778e71, or in a version not specifically about geolocation in w3c/sensors#73).

And yes, the new geofencing API has a lot of the same privacy and permission related problems as what you're describing. We haven't really figured out yet what to do about that (although a spec compliant implementation could not allow registering of new geofences from the background under certain circumstances, which would make adding a new geofence around the current location impossible).

[martinthomson]

I think that @RichardMaher forgets that sometimes browsers have to deal with sites that act poorly. Tracking the user in the background is highly likely to be a case of a site acting poorly. I want to ensure that the user remains in control; and I don't believe that asking users for permission is sufficient to that end for some types of features. This is one of them.

[RichardMaher]

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.

[RichardMaher]

@joemarini

Scenario: SW receives a push event, and my handler wants to check the current geolocation so I can warn the user about a potential nasty weather issue in their area.

Exactly Joe! But can I ask why you have devolved the "am I in danger" geofence logic to the client? Why send them a message if you know (or should know) that it does not concern them?

Weather is transitory and localized. If you follow my and @mkruisselbrink 's recommendations then the server will know exactly who is in/out of the danger zone and therefore needs to be PUSHed.

Please allow me to offer alternative requirements:-

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 Martin et al have ruled out creating geofences in the Service Worker and we don't know if we're in the foreground on the device.

2. The library is closing. The librarian sends a push message to anyone in the building (who hopefully have their notifications on vibrate :-)

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

This is SERVER driven logic not fat client bloatware.

[RichardMaher]

What's Mozilla doing? Floundering :-( Please see:
https://bugzilla.mozilla.org/show_bug.cgi?id=1216148
https://bugzilla.mozilla.org/show_bug.cgi?id=784505

Please put your WAKE_LOCK sledge-hammers away - all of you!

BTW. An additional piece of ServiceWorker GeoLocation governance, on Chrome at least, is that the gcm_sender_id/procet_id can be revoke for sites behaving badly.

[RichardMaher]

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

[RichardMaher]

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. "Health & Fitness" market? Ignore it?

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.

[RichardMaher]

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

[RichardMaher]

A victory for common sense. Excellent news!

On Thu, May 12, 2016 at 2:40 AM, Marijn Kruisselbrink mek@chromium.org wrote:
For quite a while now the geofencing API hasn't been much of a priority for us. Now in addition to that we're no longer convinced the geofencing API in its current shape is the best way to address the use cases we're interested in addressing. So with that in mind we've decided to stop work on the geofencing API in its current form.

Marijn

Combine that outcome with this at the upcoming TPAC: -

Hello All,

The registration for TPAC 2016 is now open - relevant information is provided in the email attachment below. There will not be a stand-alone meeting for the Geolocation Working Group, but there will likely be a joint meeting between the Geo WG and the Devices and Sensors (DAS) WG. This should be confirmed soon, and will take place during the DAS WG's allocated meeting time (Sep. 19-20).

Thanks,

-Giri Mandyam, Geolocation Working Group Chair

An the scene is set for a ServiceWorker.TravelManager.subscribe() outcome or, more likely, a generic sensor.AddListener(filterOptions). Either way these are exciting times indeed. Good Luck!

[RikdeBoer]

Agree very much with the use-case scenario's described by @ManuelB and @RichardMaher.

There are dozens of use-cases for being able to receive and record geo position updates, whereby the initiating (web)app may or may not run in the background, as the user is temporarily on another tab, or app, and/or has put their mobile device in (s)low-CPU/low-power mode.

With Progressive Web Apps touted as the new way to go and ServiceWorker being one of the mandatory components of PWA, ServiceWorker seems a natural fit.
If not ServiceWorker, then something else. Please redirect me if there is a better place where I should state my case.

But somewhere in PWA we need to be able to receive position (lat/lon) updates from the mobile device's hardware and pass these on to the page that originally activated it.
As I understand it, currently ServiceWorker does not have access to navigator.geolocation, let alone navigator.geolocation.watchPosition(), so in this respect PWA cannot offer what native apps can.

Sure, we must be prudent when it comes to power/battery requirements and privacy issues.
But when I can start a native app on my phone, fully warned & aware that it will use a lot of battery power and that it is recording position updates (because I want it too), then why, should we not have that same functionality under PWA?

As a lover of maps and entrepreneur in the market segment of geolocation-based mobile solutions, this feature, more than any other, is holding PWA back from being something truly great.

[tyrex1975]

I didn't want to put +1, but we have a very strong use case for background GPS here too.

The scenario is similar to others mentioned - mobile workers out and about, central control seeing where they are, dispatching workers to locations in a dynamic visit-allocation environment.

We made the decision to build our app as a PWA long before the term PWA existed, back in the days of inconsistent browser storage standards, polyfills everywhere etc., so to see native features gradually appear and become standardised in browsers over time has really helped validate our decision to proceed down this route.

But live tracking is a Very Big Deal commercially these days (Google 'mobile workforce management' and try to find a site that doesn't mention live tracking), and unfortunately we keep having to look over to the dark side (native) in order to achieve our technical aims.

To have genuine background geolocation, installed from the web page and available even when the device is screen locked would be a huge positive.

[CharlBest]

We also have a need for tracking users in the background, with their permission, without having the PWA open. I like Jake's suggestion about showing a fixed notification tray item to show the app is open (even that the app is using geo-location) and clicking it or swiping it away disposes of the service worker.

[HarelM]

I too have the same problem. I would like to allow users to record their cycling/hike/drive and keep the mobile phone battery in a good shape for several hours - this means the screen need to be turned off.
I'm currently using (Cordova for this)[https://github.com/mauron85/cordova-plugin-background-geolocation]. I believe PWA is a better approach, but this is currently my first concern that doesn't allow me to migrate to PWA.
BTW, my site is here: https://israelhiking.osm.org.il/

[anssiko]

The work is resuming in the context of next-gen Geolocation Sensor. Please see w3c/geolocation-sensor#30 and provide your feedback there. Especially helpful would be to understand whether the current use cases capture your requirements. Thank you!

[marcoscaceres]

Maybe we should close and lock this thread, and point people to the above?

[marcoscaceres]

Actually, it’s already closed. Would just need to lock 🔒

[ghost]

What is the status? Is there a way to add location tacking within a PWA by now?

[tomayac]

Nothing has changed so far, Navigator.geolocation is still where we are at the moment.

[ghost]

@tomayac do you have any clue that what is stopping them to do so? From my understanding I see the future of entire software/IT industry as PWA for the upcoming decade. Moreover if we see a growth in Chrome OS then this will be again a big plus. 💃 As we are already seeing major segments of google has already started using PWA aggressively with products like drive, YouTube, YouTube music etc. 😮 I believe giving flexibility of using all native features of android through JavaScript will change the way we see software/application and will allow developers to rely on a single technology, it's updates and it's community. 😄 ✌️

[marcoscaceres]

You are preaching to the choir, @lovishagg - and we all feel the same level of passion about empowering PWAs to do amazing things. However, this is very complicated from a privacy and security standpoint. It's going to take a while to sort out and for us all to come to some agreement to move this forward.

[ghost]

@marcoscaceres I understand that user privacy and security are among the major things which none of us would like to compromise on. But from my understanding of technologies, giving a hold of things which are possible through one technology to another as well, doesn't change a lot of things there. If we keep the permissions and notification alerts of a PWA, consuming the GPS data intact I believe we are doing no harm but just enabling a few APIs through non native environment. But since you say that it's more complicated than what's mentioned, I believe you and would wait like all others in the queue to implement it within my code base and start developing a native app just for the sake of unavoidable use case of having background location access. Thanks. ☮️

[Zibri]

Someone will have to explain me why this has not been implemented yet.
Web Apps need authorizations.
One I give it I am willing to activate that function.
Period.
So today you force people to code an "app" for 3-4 different OS which includes some sort of web browser which load and index.html while you should just enable thi fricking function (and all possible others).
The only reason that comes to mind is that they try to keep the "store" alive since webapps give too much freedom to coders.

[ghost]

Agreed @Zibri We as developers should be given freedom to code in whatsoever language/environment we want rather than big hardware manufacturers deciding it for us. And on top of that when they say you definitely need a mac in order to properly test and deploy your app on an iphone and the alternatives left are very low due to their so called "secure" systems.

[marcoscaceres]

This is spinning off topic. I'd suggest we lock this issue.

[hubyhuby]

+1
NEED
Please make it possible to access GPS from the background worker.
This is the number ONE feature request for my customers using PWA.
There are so many use cases that I don t want to spam this thread!

SECURITY
I don t see any security problem, PWA are now like regular apps, they ask you permissions! So there is NO differences...
PWA could be even BETTER at security than regular android or IOS apps , asking :
"This is using geo in the background and may use more power : YES/ NO"

[biju-ps]

+1

[Deltahedron]

Please

[saburo70]

Use Case : Starting to implement an app for Sailboat racing (more than that, but just to give the context) in which only GPS is monitoring the competition. Deciding if it makes sense to go the PWA route (it does for plenty of reasons non GPS related).
I cannot lose tracking if a user answers the phone or locks it, because that would potentially make him miss a waypoint and being eliminated from the competition

[James-E-A]

How do you think the privacy and security aspects of this should be handled?

Especially on mobile, screen space is limited. A permanent indicator like a notification might be too much

FWIW, I think that might be an extremely reasonable way to handle it.

e.g. Google Maps (during active navigation) and Waze (whenever it's runnning) do exactly this: and I'd say that if you "make" the app display a conspicuous location, that's far preferable to allowing it to discreetly siphon location data without much ado (as e.g. the Google Location Services are uniquely privileged to)…

The status-quo-bar for "respects privacy" on e.g. Android is quite low at the moment, but I think that "have a background-notif up while the app is monitoring your location" would leave nobody feeling violated, while not being that visually-disruptive.

The only cases I can come up with offhand in which a background-notif-during-location-access à la Waze might be a bit visually-much are:

• someone's e.g. re-implementing the entirety of Tasker as a PWA
• Geofencing per se (which might end up being its own, separate can of worms)

But in all other cases, I think that this is the only natural solution. Perhaps it could be augmented by requiring the app to be re-opened to re-access GPS after it's closed its access (and thus vanished its notification)?

(My use-case is: I've created a bike-ride tracking "webapp" in just a few hundred lines of JS; it's so much nicer of a development environment than the whole SDK mess; but I would really like to be able to allow users to turn their screens off during the ride while still collecting telemetry. This seems like such a natural thing to expect!)

[ingenix21]

After having read the whole thread I conclude without fear of being wrong, but I perceive from W3C a refusal for the development of the "geolocation in the background managed by service worker" and even more as crazy to propose https: //w3c.github.io/wake-lock/ as a solution. the W3C mentions privacy and security as the main obstacle, but perhaps that security and privacy is not "violated" by millions of applications that exist in the app store that use geolocation in the background, because that is what We speak, they also mention that the implementation is not so easy, but if geolocation is already implemented, you just have to activate it in the Service Worker!. Well, they are seeing obstacles where there are none, really the only argument I can find for such a refusal is that the W3C does not want the PWA to be able to develop applications as native applications do, if not, because they try to block this thread so vehemently.

[Tom333Trinity]

@JamesTheAwesomeDude @chaals @LJWatson My heart is truly breaking :-(

The fifth birthday of this topic has come and gone yet somehow we've managed to maintain the rage; well done. By this post alone regardless the many censored redactions by the @marcoscaceres cancel culture the voice of the people is crying out in the face of shameless falsehoods of "other priotities" and "insufficient interest".

Because of this topics and the many others to fora such as StackOverflow: -
https://stackoverflow.com/questions/44233409/background-geolocation-serviceworker-onmessage-event-order-when-web-app-regain/46210408#46210408
and
https://stackoverflow.com/questions/55290691/is-there-way-to-track-user-current-location-within-service-workers-in-pwa-while/55291929#55291929

It behoves W3C to explain their rationale, nay excuses, for not responding to such legitimate and modest requests for essential PWA functionality.

I can easily exlain to @ingenix21 why standard geolocation API is unsuitable for ServiceWorkers but we need to focus on the proven and for 5 years unchallenged TravelManager solution

Apple has green lights and read lights to unveil background functionality to the user. User permission is an issue easily solved once we have a solution that has been at hand for FIVE YEARS.

Rule 1. Nothing happens if and instance of Chrome is not running Dadaa!

Can someone, ANYONE, please tell me why W3C aren't doing this???

If only I wasn't censored from so many forums I can certainly tell you in few words why the WakeLock and dreamtime GeoLocation sensor are completely infeasible.

How to we escalate this issue over the corruption and/or incompetence of those involved at W3C?

[pperzyna]

+1

[James-E-A]

I do have to echo the sentiment others have expressed here — that the "privacy and security" concerns seem… disingenuous, at best, given what's going to come out of the upcoming Geofencing API (read: Google et. al. gaining even more and broad surreptitious access to sensitive user data).

If they're offering something like this, I think we can all be sure that the service powering that API is not going to get any kind of perma-notification w/r/t its background location access…

(The end result? Apps can only get background location access if the user gives Google indefinite access to theirs — yielding something like the Location Services fiasco, but now the exclusive background-location API for PWAs: disabling Google's access will actually cut off all these 3rd-party apps'…)

[jakearchibald]

Locking this in favour of w3c/geolocation-sensor#22.

This repo is focused on core elements of the service worker spec. Features built on top of service workers happen in other specs, and often by other working groups.

In this case there are already other groups for geo-related things, and system lock related things.

The path forward here looks exactly the same as it has for 5 years. A system lock would allow a tab to use existing geo APIs while the phone is on standby. All of this is already designed, it just needs implementing.

If we need a solution targeted to geo, we could have a system that records position in the background, and delivers that data to the service worker, in bulk, when the user next visits the origin. This system isn't designed, and comes with significant privacy issues. This isn't a problem to be solved within this repo, or by this group.

This group will reject changes to the service worker core that allows the service worker to be continually alive, particularly while the site is closed, as this would present a huge privacy abuse vector, and unnecessary battery use.