Why is geofencing design tied to service workers?

[garvankeeley]

Why not have navigator.geolocation.geofence(...) and be consistent with the existing geolocation API?

Anything geo one would do in service worker, they would also want to do in a document. Purely opinion on my part, but the SW should be the subset functionality for APIs -not required to use the API in a document.

I am still reading the docs, I just didn't see the justification statement for this design.

[marcoscaceres]

it could be worthwhile exploring this. It might make the api simpler (even if not so fancy because it won't use promises).

[gmandyam]

The Working Group considered having geofencing in the main thread, but couldn't arrive at a use case. It was discussed during the last F2F at TPAC 2014. The discussion can be found here: http://www.w3.org/2014/10/27-28-geolocation-minutes.html#day21. The Service Worker option represents consensus among attendees at the F2F.

[RichardMaher]

Instead WHY NOT just have the fully functional, feature rich, familiar geolocation API surfaced and available to Service Workers?

As I discussed in https://code.google.com/p/chromium/issues/detail?id=444144 and https://code.google.com/p/chromium/issues/detail?id=506435 your geofencing-LIGHT serves no useful purpose other than to have re-invented a wheel that isn't round.

But more importantly, why has the Chrome implementation stopped? Is geofencing in service workers dead in the water?

Where are we at with this?

[marcoscaceres]

@Tier3Software, can I kindly ask you to please refrain from using a condescending tone (i.e., making statements like, "serves no useful purpose other than to have re-invented a wheel that isn't round").

Also, please note that Google may have it's reasons for starting/stopping implementation as they please. Unless you represent Google, can I kindly ask that you refrain from asking things like: "where are we at with this?".

The WG values everyone's input, but please be constructive with your criticisms.

[RichardMaher]

@garvankeeley Below is a simple worker thread that I use to find matching facilities in a Google Maps Circle. On center_changed or radius_changed, a message is sent from the main thread instructing the Worker to re-validate which facilities are now in/out the geofence circle, that the user is moving around the map, feeding back the results asynchronously.

I just beg someone/anyone to explain to me why the geolocation API is not available to Service Workers as well! If there is another more appropriate forum for this question then please let me know.

ONE geolocation.watchPosition throttling user location movent for ALL tabs. Sounds battery-friendly to me,

importScripts("Tier3Toolbox.js");

var currVintage = 0;
var inBounds = false;
var facFilter = [];
var imageProlog = "<div style='height:5em; width:5em; display:inline-block;vertical-align:middle;'>" +
                  "<img style='height:100%; width: 100%; max-height:100%; max-width:100%' src='";
var imageEpilog = "' ></div>";
var facilityTable, lineBreak;

self.addEventListener('message', function(e) 
{
  var data = e.data;
  switch (data.cmd) {
    case 'init':
      initThread(data.load);
      break;
    case 'initFilter':
      for (var i=0; i<data.filterTable.length; i++) {
        facFilter[data.filterTable[i].locTypeId] = {'icon':data.filterTable[i].icon};
      }
      break;
    case 'filter':
      facFilter = [];
      for (var i=0; i<data.filterTable.length; i++) {
        if (data.filterTable[i].facSelected)
          facFilter[data.filterTable[i].locTypeId] = {'icon':data.filterTable[i].icon};
      }
      break;
    case 'search':
      var searchVintage = ++currVintage;
      var tableSearch = new searcher(searchVintage, data);
      break;
    case 'reset':
      reset();
      self.postMessage({'reset': true});
      break;
    case 'stop':
      self.postMessage({'success' : true});
      self.close(); 
      break;
    default:
      self.postMessage({'success' : false, 'msg' : data.msg});
  };
}, false);

function initThread(msg) 
{
    facilityTable = JSON.parse(msg);
    reset();

    self.postMessage({'success' : true, 
                      'cnt'     : facilityTable.length
                    });     
}   

function reset() 
{
    for (var i=0; i<facilityTable.length; i++) {
        facilityTable[i].visible=false
    }
    currVintage = 0;
}   

function searcher(searchVintage, msg)
{
    var myVintage = searchVintage;
    var facIndex  = -1;
    var msg       = msg;

    var checkLoop = function()
    {
        if (myVintage != currVintage)
            return;

        if (++facIndex == facilityTable.length)
            return;

        inBounds = geoFencer.call(this, msg);

        if (inBounds) {
            var facMatch = 0;
            var bubbleHTML = "";
            for (var i=0; i<facilityTable[facIndex].facilities.length; i++){
                var currFac = facilityTable[facIndex].facilities[i];
                if (facFilter[currFac.locTypeId] != undefined) {
                    if (facMatch != 0) {
                        lineBreak = (facMatch / 3);
                        if (lineBreak == lineBreak.toFixed(0)) {
                            bubbleHTML += "<br />";
                        }
                    }
                    facMatch++;
                    bubbleHTML += imageProlog + facFilter[currFac.locTypeId].icon + imageEpilog;

                }
            }
            if (facMatch == 0) {
                inBounds = false;
            }
        }

        if (inBounds != facilityTable[facIndex].visible) {
            self.postMessage({'match'       : inBounds,
                              'facIndex'    : facIndex,
                              'scopeVintage': msg.scopeVintage,
                              'bubbleHTML'  : bubbleHTML,
                              'success'     : true
                            }); 
            facilityTable[facIndex].visible = inBounds;
        }

        setTimeout(checkLoop,0);
    }

    var circleCheck = function(msg) 
    {
        var diff = Tier3Toolbox.calculateDistance(
                        msg.centerLat,
                        msg.centerLng,
                        facilityTable[facIndex].searchLat,
                        facilityTable[facIndex].searchLng);

        if (msg.radius > diff)
            return true;        

        return false;
    }

    var rectangleCheck = function(msg) 
    {
        if (facilityTable[facIndex].searchLat > msg.SWLat &&
            facilityTable[facIndex].searchLat < msg.NELat &&
            facilityTable[facIndex].searchLng > msg.SWLng &&
            facilityTable[facIndex].searchLng < msg.NELng)
            return true;        

        return false;
    }

    var GEOFENCER = [circleCheck,rectangleCheck];
    var geoFencer = GEOFENCER[msg.checker];

    setTimeout(checkLoop,0);
    return this;
}

[marcoscaceres]

I just beg someone/anyone to explain to me why the geolocation API is not available to Service Workers as well! If there is another more appropriate forum for this question then please let me know.

My understanding is that you don't ever want to do what you are doing above (specially on mobile, and particularly in a service worker). Ideally, the service worker is supposed to just loop through as few times as humanly possible, maybe perform some short lived async task, and sleep. It's absolutely not intended to be kept alive running timers in loops for a long time.

Ideally, you want to tell the hardware, through the SW, to watch the geofence for you: because it can do it in a far more energy/code efficient way. When the user steps outside/inside the fence, the SW can be woken up with a single event by the Geofence hardware, do what it needs to do, and quickly be shut down by the user agent.

[RichardMaher]

The OP was asking for the geofencing API to be available in the main thread. I proved to him that it would redundant as the full geolocation API, currently available in the main thread, is perfectly capable of providing full-blown geofencing functionality today. Furthermore, the code I presented was for a Web Worker and NOT a Service Worker.

Please be aware that the example code permits a user to move the visible geofence (circle) around the map with their finger and in real-time turn on/off map markers that are now in/out of the geofence. Functionality that I personally find quite impressive.

That was all for the OP. What I want is the geolocation API surfaced in the Service Worker Navigator so that I can wake up the Browser or perhaps send a Notification if a condition is reached even when the phone is off.

I currently "tell the hardware, through the" main-thread to watch my location. I then throttle it (min-distance, min-time, since last update) If I have entered or left a geofence I will XHR a server who will decide if people need to be notified of my arrival/departure.

Anyway this forum appears to be aimed at the geofence API evangelism and I'd be grateful if I could be directed to an alternative that is suitable for lobbying for Service Worker functionality and in particular the navigator.geolocation object.

[marcoscaceres]

I've pinged some of the editors of SW to comment.

Sent from my iPhone

On 30 Jan 2016, at 2:32 PM, Tier3Software notifications@github.com wrote:

The OP was asking for the geofencing API to be available in the main thread. I proved to him that it would redundant as the full geolocation API, currently available in the main thread, is perfectly capable of providing full-blown geofencing functionality today. Furthermore, the code I presented was for a Web Worker and NOT a Service Worker.

Please be aware that the example code permits a user to move the visible geofence (circle) around the map with their finger and in real-time turn on/off map markers that are now in/out of the geofence. Functionality that I personally find quite impressive.

That was all for the OP. What I want is the geolocation API surfaced in the Service Worker Navigator so that I can wake up the Browser or perhaps send a Notification if a condition is reached even when the phone is off.

I currently "tell the hardware, through the" main-thread to watch my location. I then throttle it (min-distance, min-time, since last update) If I have entered or left a geofence I will XHR a server who will decide if people need to be notified of my arrival/departure.

Anyway this forum appears to be aimed at the geofence API evangelism and I'd be grateful if I could be directed to an alternative that is suitable for lobbying for Service Worker functionality and in particular the navigator.geolocation object.

— Reply to this email directly or view it on GitHub.

[garvankeeley]

Only hardware-level geofencing, that properly calls into https://github.com/android/platform_hardware_libhardware/blob/master/include/hardware/gps.h#L1033 is useful. Software approximations of geofencing may be used at the driver level or the API implementation level as a fallback. This API's goal is to provide a mechanism to call chip-level geofencing. There is no way to do this with a web api currently.

SW in future will support a wide range of web APIs, and there is interest in having the existing geolocation API available. That topic is relevant/critical to this thread. However, I don't know what information you are looking for, there are too many tangents here. Can I ask you to re-read my original question and then re-ask yours?

[jyasskin]

2¢: In order for Service Workers to have any sort of geolocation, it has to be geofencing; and geofencing is more useful when it's active for a long time, which matches Service Workers better than foreground tabs; but I don't think there's a reason to exclude it from foreground tabs, and there are long-lived foreground tabs that could take advantage of the power savings.

[garvankeeley]

In order for Service Workers to have any sort of geolocation, it has to be geofencing;

I would expect navigator.geolocation to be available in SW in future, there is no contraindication for that API that I know of. Can you explain this further?

Geofencing is more useful when it's active for a long time

I argue that web APIs should go SW-only only if there is a restriction to them being non-SW. They should be as useful in as many cases as a native API. Native geofencing APIs aren't restricted to a thread.

I suppose the goals here depend on your desired endpoints, for me, I would define success of this project as:

• are browser engines implementing hardware-level geofencing? Why the low-level implementation is related: if browsers don't do hardware geofencing, and nav.geo becomes SW-available (which can then emulate geofencing), then this API's role becomes very unclear
• are users finding the API as easy to use as native APIs and existing web geo APIs? Do we need API users to have domain knowledge of SW to use the API? Currently, the nav.geo API requires a very minimal level of JS knowledge.

And ultimately, I would like to see a wide adaption for a variety of use cases. Geofencing is in its infancy, use cases are still being discovered, even on native with the APIs available it is still minimally used. Why build restrictions in to the API if it is not necessary to do so?

[RichardMaher]

I've pinged some of the editors of SW to comment.

Thank-you.

Only hardware-level geofencing, that properly calls into https://github.com/android/platform_hardware_libhardware/blob/master/include/hardware/gps.h#L1033 is useful.

This must be the bit I don't understand. I am familiar with browser engines implementing hardware-level geoLOCATION but am not aware of how they would implement geoFENCING without software. I know you provided a link to code but if you could just explain to me how it works that'd be great.

I retrieve hardware-level GPS location by using watchposition. (Ok, if I haven't set the accuracy flag and I'm inside a building then triangulation or approximation may take place. But let's assume we're outdoors and I've asked for only accurate readings)

I can then calculate the entry/exit in/out of a geofence by checking that the distance from me to the center of the geofenced area is <= the radius.

If you're telling me that there is a hardware instruction that just knows where the geofences are and the chip automagically receives a hardware level interrupt when a geofence is traversed then I am truly in awe!

2¢: In order for Service Workers to have any sort of geolocation, it has to be geofencing;

Well argued,

[marcoscaceres]

If you're telling me that there is a hardware instruction that just knows where the geofences are and the chip automagically receives a hardware level interrupt when a geofence is traversed then I am truly in awe!

I think this is exactly/literally/precisely what we are trying to tell you.

[jyasskin]

I would expect navigator.geolocation to be available in SW in future, there is no contraindication for that API that I know of. Can you explain this further?

https://slightlyoff.github.io/ServiceWorker/spec/service_worker/index.html says "Service workers … may be killed by the user agent at nearly any time." That means you can't expect watchPosition() to keep watching for very long. getCurrentPosition() could work if the position is already available, but if it has to wait for a GPS fix, the SW is likely to be gone by the time an answer comes back.

I argue that web APIs should go SW-only only if there is a restriction to them being non-SW.

Yeah, even if geofencing is defined for SWs first, it should probably eventually come to foreground tabs. Again, though, it'll probably be less useful there: the tab is likely to get closed before the user crosses a fence.

are browser engines implementing hardware-level geofencing?

I believe the API is designed so it can be implemented by calling platform-level geofencing APIs, which in turn can often be implemented with hardware support. Even without hardware support, it's far more efficient to ask the browser as a whole to watch for fences than to keep a bunch of javascript contexts polling for location changes.

[RichardMaher]

I think this is exactly/literally/precisely what we are trying to tell you.

Amazing. Sorry for being slow on the uptake. Does anyone have a useful link that documents this so that I can read up? No having to loop through all geofences on a GPS change is a great advantage.

But if this is the case then why is it up to your API to implement the shape of the geofenced zone? Why does the API seek to limit the number of geofences or regulate their area?

"Service workers … may be killed by the user agent at nearly any time."

Yes it says they "maybe" or it is acceptable to do so; it doesn't say "they will be killed immediately"

That means you can't expect watchPosition() to keep watching for very long

Non-sequitur surely? IF the device is low on memory then sure it can kill the SW freely but if resources are available then I see no Logun's Run strategy mandated in the specification.

Either way if you tell me that a geofence traversal is sufficient to re-instantiate the SW, when a location change is not, then I will be amazed for the 2nd time in 2 days. This geofence thing is starting to sound really useful!

Having said that what would stop me throwing a small, say 10m, geofence around the current location and treat that as my pseudo watchPosition? Just re-center it or delete/create it at each move. But you would need the currentPosition otherwise have to wake up the browser?

[RichardMaher]

AUD$0.02c It would be a very inefficient, unintelligent, and resource expensive, user-agent that would terminate a SW as soon as its event loop is exhausted. IMHO.

Oh look, there's another notification let's fire up that SW again an initialize it. Terminate with extreme prejudice

Oh look, another notification, and two geofences crossed let's fire up an SW again and initialize it. There's heaps (excuse the pun :-) of memory out there but we don't like loose ends here in Browser X!

[mkruisselbrink]

One other reason I didn't see mentioned yet as to why we limited geofencing to requiring service workers is in an attempt to keep the API surface as small as possible. In order to address all the use cases we need to somehow expose geofencing to service workers. While there are definitely use cases where having access to geofencing directly from windows/other workers would make things easier, we don't actually enable more use cases this way, while we would rather significantly increase the API surface and at very least would have to introduce two ways to do various things. It might very well be that in a future version of a geofencing API it would make sense to have APIs that bypass the need for a service worker, but in this initial version I think it is very worthwhile to keep the API as simple as possible while still fulfilling all the use cases.

As for geolocation support in service workers in general, some more discussion about that also exist in slightlyoff/ServiceWorker#745 and w3c/sensors#73

[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};
    };

[RichardMaher]

From: https://github.com/slightlyoff/ServiceWorker/issues/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.

[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. User's want to know more than "Elvis has left the building"!

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

[allanjuma]

@richardmaher use case 9. App automatically fetches menu when user enters 'favourited' restaurant/shop. We are waiting for community consensus before trying this out..

my2¢ starting out with a bare minimum implementation of just geofencing might help get more interest and feedback while limiting risk.

[RichardMaher]

@allanjuma where do you put the check for opening hours on your restaurant/shop? (Umbrella specials in the rain perhaps?)

a) In the User-Agent as part of the GeoFence API options list b) No that's silly, just check in the Service Worker

My guess is you'll opt for (b) and everyone else will just opt for whatever they do with Java geofences at the moment. (After all copying what is already there is considered a no-brainer by those who don't like to think.)

I say to you that the entrie raison d'etre for geofencing is that it's supposed to save battery life by enforcing/implementing the fence in the UA and not needing to spin up a SW. Therefore it should check hours in the API to the UA yes? But opening hours aren't engraved in stone. How do I tell the UA I want to vary them or vary the radius of the geofence for that matter?

my2¢ starting out with a bare minimum implementation of just geofencing might help get more interest and feedback while limiting risk.

But why can't you see that what you're asking for is a concoction and no where near a "bare minimum"???

GeoLocation _IS_ the bear minimum! GeoFencing is just one implemented application of geolocation. You Sir, have deliberately sought to cut off developers legs by limiting them to a myopic world of geofence rigidity that is next to useless :-(

BTW Here is another recent Use Case (with geofence implementing code (circle and rectangle)) that you may find interesting: - https://bugs.chromium.org/p/chromium/issues/detail?id=383125#c38 Start reading from comment #38

(And no, there was no TPAC in Bora Bora this year. You did not miss out.)