Expose GeoLocation to workers #745

Closed
joemarini opened this Issue Sep 4, 2015 · 81 comments

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@mvano

mvano Sep 8, 2015

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

mvano commented Sep 8, 2015

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

This comment has been minimized.

Show comment
Hide comment
@joemarini

joemarini Sep 8, 2015

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

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

@mkruisselbrink

This comment has been minimized.

Show comment
Hide comment
@mkruisselbrink

mkruisselbrink Sep 14, 2015

Collaborator

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.

Collaborator

mkruisselbrink commented Sep 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@joemarini

joemarini Sep 15, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@mvano

mvano Sep 15, 2015

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.

mvano commented Sep 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ManuelB

ManuelB Oct 17, 2015

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

ManuelB commented Oct 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mkruisselbrink

mkruisselbrink Oct 19, 2015

Collaborator

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.

Collaborator

mkruisselbrink commented Oct 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mkruisselbrink

mkruisselbrink Oct 19, 2015

Collaborator

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.

Collaborator

mkruisselbrink commented Oct 19, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Oct 20, 2015

Collaborator

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?

Collaborator

jakearchibald commented Oct 20, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ManuelB

ManuelB Oct 20, 2015

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

ManuelB commented Oct 20, 2015

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

@annevk annevk added this to the Version 2 milestone Oct 27, 2015

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 2, 2016

@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

@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

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Feb 3, 2016

Member

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

Member

marcoscaceres commented Feb 3, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 3, 2016

@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"!

@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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@ManuelB

ManuelB Feb 3, 2016

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

ManuelB commented Feb 3, 2016

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

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 9, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Feb 10, 2016

Member

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.

Member

martinthomson commented Feb 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 10, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@mkruisselbrink

mkruisselbrink Feb 10, 2016

Collaborator

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

Collaborator

mkruisselbrink commented Feb 10, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@martinthomson

martinthomson Feb 11, 2016

Member

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.

Member

martinthomson commented Feb 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 12, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 12, 2016

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

@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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 16, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 17, 2016

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?

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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 19, 2016

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.

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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Feb 23, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher May 12, 2016

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!

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

This comment has been minimized.

Show comment
Hide comment
@RikdeBoer

RikdeBoer Jul 3, 2016

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.

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.

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jul 5, 2016

@RikdeBoer You might also want to watch https://bugzilla.mozilla.org/show_bug.cgi?id=1254911

Yes Blind Freddy can see the requirements and the merit in our arguments. What he can't do is make their Royal Highnesses of the IETF/W3C Cognoscente engage with the unworthy in providing a solution.

To date no one has found fault with my navigator.serviceWorker.travelManager.subcribe(options) idea with the capability of Throttle options to proxy the "interesting" movement test to the UA/Google Play/Message Console yet here we still are :-(

Nothing will happen before the Lisbon jolly.

@RikdeBoer You might also want to watch https://bugzilla.mozilla.org/show_bug.cgi?id=1254911

Yes Blind Freddy can see the requirements and the merit in our arguments. What he can't do is make their Royal Highnesses of the IETF/W3C Cognoscente engage with the unworthy in providing a solution.

To date no one has found fault with my navigator.serviceWorker.travelManager.subcribe(options) idea with the capability of Throttle options to proxy the "interesting" movement test to the UA/Google Play/Message Console yet here we still are :-(

Nothing will happen before the Lisbon jolly.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jul 7, 2016

Member

To date no one has found fault with my navigator.serviceWorker.travelManager.subcribe(options) idea with the capability of Throttle options to proxy the "interesting" movement test to the UA/Google Play/Message Console yet here we still are :-(

It's not that we've not found fault. It's that your constant abuse of people engaged with the standardization process and insane conspiracy theories make it impossible to have any sort of meaningful conversation about this topic with you.

Despite good faith attempts to allow you to collaborate, you have continuously shown yourself incapable of having a civil conversation (why I had you banned from the W3C mailing lists already). I'd again ask that you please remove yourself from the discussion - or I'll ask Github to ban you from here also.

Member

marcoscaceres commented Jul 7, 2016

To date no one has found fault with my navigator.serviceWorker.travelManager.subcribe(options) idea with the capability of Throttle options to proxy the "interesting" movement test to the UA/Google Play/Message Console yet here we still are :-(

It's not that we've not found fault. It's that your constant abuse of people engaged with the standardization process and insane conspiracy theories make it impossible to have any sort of meaningful conversation about this topic with you.

Despite good faith attempts to allow you to collaborate, you have continuously shown yourself incapable of having a civil conversation (why I had you banned from the W3C mailing lists already). I'd again ask that you please remove yourself from the discussion - or I'll ask Github to ban you from here also.

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jul 7, 2016

@marcoscaceres - Settle Petal! It was certainly not my objective to upset the sensibilities of the artisans at International Rescue.

It's just that, on this outside of the Ivory Tower, the Employer/Employee relationship is normally one where the Employer pays the Employee money in return for directed work undertaken. Unlike @mkruisselbrink 's GeoFence waste of precious time and resources, the aforementioned work effort usually results in deliverables with agreed upon metrics with which to judge their fitness for purpose. Yep, I have to admit to being a tad envious of the "Just be wonderful, Darling!" duty statement.

Anyway, just because I, and Nigel Farage, may believe that most of those in bloated bureaucracies "have never had a proper job" is no excuse for trying to hold you to account and peel back the scab on the IETF/W3C circus. My apologies.

It's not that we've not found fault.

I'm happy to defend the design, or not. If you've got something better let's go with that!

BTW. was that the Royal "we" or are you speaking for someone else again?

make it impossible to have any sort of meaningful conversation about this topic with you.

Less talking; more doing. It's simply not that hard!

I honestly can't believe such a Prima Donna attitude actually exists and is allowed to fester in Australia. "I can't work with him Kyle! KYLE - I just can't work with him!" Really?

you have continuously shown yourself incapable of having a civil conversation

Bollocks!

I suggest to you that a full and frank exchange of views only appears uncivil when viewed through a passive-aggressive prism.

(why I had you banned from the W3C mailing lists already).
I'd again ask that you please remove yourself from the discussion

  • or I'll ask Github to ban you from here also.

I have to admit that I've never met a lefty ideologue who wasn't vehemently opposed to free speech, but I am extremely surprised that Mozilla nurtures a culture of bullying. But allow me to counter your attempts at censorship with a request for you to resign from Mozilla or at least from the IETF/W3C standards junket. Time to hand the baton on and give someone less jaded a go eh?

It's not about me and its certainly not about you. Please let it be about "solutions" - not personalities! I left the schoolyard long ago.

BTW. Why didn't you or anyone else here deem @RikdeBoer worthy of a response? Yarpies are inherently uncivil perhaps?

Background GeoLocation - Just do it!

@marcoscaceres - Settle Petal! It was certainly not my objective to upset the sensibilities of the artisans at International Rescue.

It's just that, on this outside of the Ivory Tower, the Employer/Employee relationship is normally one where the Employer pays the Employee money in return for directed work undertaken. Unlike @mkruisselbrink 's GeoFence waste of precious time and resources, the aforementioned work effort usually results in deliverables with agreed upon metrics with which to judge their fitness for purpose. Yep, I have to admit to being a tad envious of the "Just be wonderful, Darling!" duty statement.

Anyway, just because I, and Nigel Farage, may believe that most of those in bloated bureaucracies "have never had a proper job" is no excuse for trying to hold you to account and peel back the scab on the IETF/W3C circus. My apologies.

It's not that we've not found fault.

I'm happy to defend the design, or not. If you've got something better let's go with that!

BTW. was that the Royal "we" or are you speaking for someone else again?

make it impossible to have any sort of meaningful conversation about this topic with you.

Less talking; more doing. It's simply not that hard!

I honestly can't believe such a Prima Donna attitude actually exists and is allowed to fester in Australia. "I can't work with him Kyle! KYLE - I just can't work with him!" Really?

you have continuously shown yourself incapable of having a civil conversation

Bollocks!

I suggest to you that a full and frank exchange of views only appears uncivil when viewed through a passive-aggressive prism.

(why I had you banned from the W3C mailing lists already).
I'd again ask that you please remove yourself from the discussion

  • or I'll ask Github to ban you from here also.

I have to admit that I've never met a lefty ideologue who wasn't vehemently opposed to free speech, but I am extremely surprised that Mozilla nurtures a culture of bullying. But allow me to counter your attempts at censorship with a request for you to resign from Mozilla or at least from the IETF/W3C standards junket. Time to hand the baton on and give someone less jaded a go eh?

It's not about me and its certainly not about you. Please let it be about "solutions" - not personalities! I left the schoolyard long ago.

BTW. Why didn't you or anyone else here deem @RikdeBoer worthy of a response? Yarpies are inherently uncivil perhaps?

Background GeoLocation - Just do it!

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Jul 7, 2016

Collaborator

I would support a ban in this case. Not happy seeing friends and colleagues being insulted in this way. I'm on leave until next week, but I'll do it unless someone beats me to it.

Collaborator

jakearchibald commented Jul 7, 2016

I would support a ban in this case. Not happy seeing friends and colleagues being insulted in this way. I'm on leave until next week, but I'll do it unless someone beats me to it.

@RikdeBoer

This comment has been minimized.

Show comment
Hide comment
@RikdeBoer

RikdeBoer Jul 7, 2016

Having come into this very late, and not knowing any past history, it looks to me that a great course may be hampered and possibly sunk by a war of words.

This would be a shame.

I do not know @RichardMaher or any history he may have with W3C or github.

For those of you who feel offended… based on what I read above, when I strip off the insulting or abusive language, I see an erudite man, who loves playing with words and is very passionate about pushing a feature request that makes common sense.

Geolocation is huge. Richard’s 8 use-cases above (Feb 19) are just the tip of the ice-berg.

Please do not be distracted or put off from working on the essential feature of "background geolocation” because of Richard’s tone.

PS:
@RichardMaher: calling me a “yarpie” based only on my surname is a long shot, even if meant as a double entendre ;-)

Having come into this very late, and not knowing any past history, it looks to me that a great course may be hampered and possibly sunk by a war of words.

This would be a shame.

I do not know @RichardMaher or any history he may have with W3C or github.

For those of you who feel offended… based on what I read above, when I strip off the insulting or abusive language, I see an erudite man, who loves playing with words and is very passionate about pushing a feature request that makes common sense.

Geolocation is huge. Richard’s 8 use-cases above (Feb 19) are just the tip of the ice-berg.

Please do not be distracted or put off from working on the essential feature of "background geolocation” because of Richard’s tone.

PS:
@RichardMaher: calling me a “yarpie” based only on my surname is a long shot, even if meant as a double entendre ;-)

@LJWatson

This comment has been minimized.

Show comment
Hide comment
@LJWatson

LJWatson Jul 7, 2016

@RichardMaher
There are good people working on this spec (and others at W3C). You make some worthwhile points, but it isn't acceptable to insult and disparage people in the process.

This repo exists outside of W3C space at present, but the spec and the people working on it are part of the W3C community - and it is the responsibility of the WPWG co-chairs to make sure that our part of the community is able to collaborate and converse positively.

Please abide by our code of ethics and professional conduct, and the advice given here.

LJWatson commented Jul 7, 2016

@RichardMaher
There are good people working on this spec (and others at W3C). You make some worthwhile points, but it isn't acceptable to insult and disparage people in the process.

This repo exists outside of W3C space at present, but the spec and the people working on it are part of the W3C community - and it is the responsibility of the WPWG co-chairs to make sure that our part of the community is able to collaborate and converse positively.

Please abide by our code of ethics and professional conduct, and the advice given here.

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jul 8, 2016

@LJWatson I am more than happy to disappear permanently from this mutual admiration society back to whence I came! I do not get paid for my time, so often wasted, here and while it can be fun, I don't get my jollies out of this sort of stuff.

All I want is progress on the two (and only 2) issues I've been banging on about for the last 6 months: -

  1. Background GeoLocation. The world needs this yesterday!
  2. Client-driven, Push-Manager mapped, Application Server unburdened, broadcast notifications

This repo deals directly with (1). The issues are well-known. ServiceWorkers are the implementation paradigm. The details can be bashed out in a couple of weeks’ Google Groups interaction and then the spec-writers can get to work.

Why is nothing happening???

  • The key word "MUST" is to be interpreted as described in [RFC2119].

. You MUST engage with the industry user-base and software-vendors in the formulation of requirements before proposing standards.

. You MUST be agile in allowing for continual and iterative review and progressive input to specifications.

. You MUST publish design direction as soon as available so incorrect assumptions can be discovered.

. You MUST not deliver a fete accompli accepting no more than grammatical corrections.

. You MUST not seek to own a specification nor personal aggrandisement. It's about results!

. Your specification delivery times MUST be quartered.

. You MUST accept the umpire’s decision on abject failures such as https://github.com/w3c/geofencing-api and not subvert the decision like some deluded sook who voted for Brexit: STAY

. You MUST not attempt to fool all the people that navigator.requestWakeLock(“screen”) is the solution to the Background GeoLocation conundrum!

Leonie, it's just that I am not used to having work farmed out to autonomous-collectives that are seemingly accountable to no one but themselves, and get to cherry-pick assignments as the mood arises. Without any recourse options available, my frustration levels have to peak :-(

There are good people working on this spec

Can you please be more specific? The “ServiceWorker” spec? The “Background GeoLocation” spec? I know you’ve got heaps of good people available. Can we please get some on Background GeoLocation?

and it is the responsibility of the WPWG co-chairs to make sure that our part of the community is able to collaborate and converse positively.

Don’t bother to veil that threat Leonie. Imelda has already gotten me blackballed by stalking me around the Internet, silencing a dissenting voice, and interfering with my ability to eke out a living in the industry. I guess the W3C/Mozilla tentacles get everywhere :-( Why don’t you just turf me out of my wheelchair and kick me in the guts while you’re at it? “Let’s see how far you get in the standards industry now smart-arse.” At least you were “polite”.

So rather than indulge, empathize with, or even pity my Tourette-esque mental health issues you choose to hack me down instead. Truly some of the ugliest people I‘ve come across in a long time :-(

@LJWatson I am more than happy to disappear permanently from this mutual admiration society back to whence I came! I do not get paid for my time, so often wasted, here and while it can be fun, I don't get my jollies out of this sort of stuff.

All I want is progress on the two (and only 2) issues I've been banging on about for the last 6 months: -

  1. Background GeoLocation. The world needs this yesterday!
  2. Client-driven, Push-Manager mapped, Application Server unburdened, broadcast notifications

This repo deals directly with (1). The issues are well-known. ServiceWorkers are the implementation paradigm. The details can be bashed out in a couple of weeks’ Google Groups interaction and then the spec-writers can get to work.

Why is nothing happening???

  • The key word "MUST" is to be interpreted as described in [RFC2119].

. You MUST engage with the industry user-base and software-vendors in the formulation of requirements before proposing standards.

. You MUST be agile in allowing for continual and iterative review and progressive input to specifications.

. You MUST publish design direction as soon as available so incorrect assumptions can be discovered.

. You MUST not deliver a fete accompli accepting no more than grammatical corrections.

. You MUST not seek to own a specification nor personal aggrandisement. It's about results!

. Your specification delivery times MUST be quartered.

. You MUST accept the umpire’s decision on abject failures such as https://github.com/w3c/geofencing-api and not subvert the decision like some deluded sook who voted for Brexit: STAY

. You MUST not attempt to fool all the people that navigator.requestWakeLock(“screen”) is the solution to the Background GeoLocation conundrum!

Leonie, it's just that I am not used to having work farmed out to autonomous-collectives that are seemingly accountable to no one but themselves, and get to cherry-pick assignments as the mood arises. Without any recourse options available, my frustration levels have to peak :-(

There are good people working on this spec

Can you please be more specific? The “ServiceWorker” spec? The “Background GeoLocation” spec? I know you’ve got heaps of good people available. Can we please get some on Background GeoLocation?

and it is the responsibility of the WPWG co-chairs to make sure that our part of the community is able to collaborate and converse positively.

Don’t bother to veil that threat Leonie. Imelda has already gotten me blackballed by stalking me around the Internet, silencing a dissenting voice, and interfering with my ability to eke out a living in the industry. I guess the W3C/Mozilla tentacles get everywhere :-( Why don’t you just turf me out of my wheelchair and kick me in the guts while you’re at it? “Let’s see how far you get in the standards industry now smart-arse.” At least you were “polite”.

So rather than indulge, empathize with, or even pity my Tourette-esque mental health issues you choose to hack me down instead. Truly some of the ugliest people I‘ve come across in a long time :-(

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jul 8, 2016

@RikdeBoer Really appreciate the empathy, and especially the kind words! Having said that, you’re backing the wrong horse mate. In truth, I am a bit of an obnoxious wanker really, always have been :-) I’ve got this knack of knowing what winds people up; it’s a gift. For example, take a quick squiz at Jake’s twitter feed. I knew I’d get him bristling with “lefty ideologue” and then once I quoted Nigel Farage it was all he could do to not stomp on his phone.

As far as “Yarpie” goes please don’t take it personally as I use it interchangeably with Saffa. No Afrikaans or dim-witted farm boy connotations. Let’s face it the Rik de Boers of this world were only ever going to come from so many places. But what are you doing in sun-deprived Melbourne? You can’t swing a cat in Perth without hitting one of your compatriots. I grew up in East Coburg and I can assure you that you got the short stick my friend. (Lucky the World Cup is so far away. If you can’t beat us now you’ll never beat us!)

This would be a shame.

Mate, it’s breaking my heart. I just can’t understand the delay let alone the recalcitrance.

BTW. I’m right into maps as well. Are you using the Google Maps API? KML as well? If you’re ever in Perth please let me know and we can catch up for a beer.

@RikdeBoer Really appreciate the empathy, and especially the kind words! Having said that, you’re backing the wrong horse mate. In truth, I am a bit of an obnoxious wanker really, always have been :-) I’ve got this knack of knowing what winds people up; it’s a gift. For example, take a quick squiz at Jake’s twitter feed. I knew I’d get him bristling with “lefty ideologue” and then once I quoted Nigel Farage it was all he could do to not stomp on his phone.

As far as “Yarpie” goes please don’t take it personally as I use it interchangeably with Saffa. No Afrikaans or dim-witted farm boy connotations. Let’s face it the Rik de Boers of this world were only ever going to come from so many places. But what are you doing in sun-deprived Melbourne? You can’t swing a cat in Perth without hitting one of your compatriots. I grew up in East Coburg and I can assure you that you got the short stick my friend. (Lucky the World Cup is so far away. If you can’t beat us now you’ll never beat us!)

This would be a shame.

Mate, it’s breaking my heart. I just can’t understand the delay let alone the recalcitrance.

BTW. I’m right into maps as well. Are you using the Google Maps API? KML as well? If you’re ever in Perth please let me know and we can catch up for a beer.

@slightlyoff

This comment has been minimized.

Show comment
Hide comment
@slightlyoff

slightlyoff Jul 15, 2016

Contributor

Not an issue appropriate for this repo. Closing.

Contributor

slightlyoff commented Jul 15, 2016

Not an issue appropriate for this repo. Closing.

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher May 28, 2017

In case your thinking that there is a lot of investigation and spec work required here you'd be wrong. Thanks to the foresight of the Service Worker spec writers and the thoroughness of the requirements gatherers, Background GeoLocation can take advantage of SW's inherent plug-n-play extensibility

Just copy & paste what was done with Notifications and we're there!

Can someone honestly tell me why the Web is not providing this???

I am happy to address any concerns or perceived problems. IMHO the only work left is: -

  • Decide on appropriate permissions protocol for acceptance and tracking discovery/visibility.
  • Decide whether you call it a TravelManager or a LocationManager or a.n.other
  • Decide whether the TravelEvent parameter is just the position object or is overloaded

What else is there?

Web Apps can now compete directly on a much more even playing field with Native Apps. Is that not the goal? Let's cheer from the roof tops?

In case your thinking that there is a lot of investigation and spec work required here you'd be wrong. Thanks to the foresight of the Service Worker spec writers and the thoroughness of the requirements gatherers, Background GeoLocation can take advantage of SW's inherent plug-n-play extensibility

Just copy & paste what was done with Notifications and we're there!

Can someone honestly tell me why the Web is not providing this???

I am happy to address any concerns or perceived problems. IMHO the only work left is: -

  • Decide on appropriate permissions protocol for acceptance and tracking discovery/visibility.
  • Decide whether you call it a TravelManager or a LocationManager or a.n.other
  • Decide whether the TravelEvent parameter is just the position object or is overloaded

What else is there?

Web Apps can now compete directly on a much more even playing field with Native Apps. Is that not the goal? Let's cheer from the roof tops?

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jun 2, 2017

@dandv @RikdeBoer @mvano @antogh @jms19

Please also see w3c/permissions#112 (comment) for a discussion on Permissions API involvement.

@dandv @RikdeBoer @mvano @antogh @jms19

Please also see w3c/permissions#112 (comment) for a discussion on Permissions API involvement.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 2, 2017

Member

We can keep the discussion here tho. I'm watching all the things 👀

Member

marcoscaceres commented Jun 2, 2017

We can keep the discussion here tho. I'm watching all the things 👀

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jun 2, 2017

@marcoscaceres I made an undertaking to @chaals that I would keep my involvement here professional succinct and objective. I intend to do just that but I honestly believe it would be much easier if you could recuse yourself from further involvement in anything to do with Background Geolocation. This has absolutely nothing to do with your abilities, just acknowledgement of the fact that we have a personality clash that could impeded progress. The fault lies with me not you.

I'm sure W3C have many capable people lining up. Perhaps from Edge?

RichardMaher commented Jun 2, 2017

@marcoscaceres I made an undertaking to @chaals that I would keep my involvement here professional succinct and objective. I intend to do just that but I honestly believe it would be much easier if you could recuse yourself from further involvement in anything to do with Background Geolocation. This has absolutely nothing to do with your abilities, just acknowledgement of the fact that we have a personality clash that could impeded progress. The fault lies with me not you.

I'm sure W3C have many capable people lining up. Perhaps from Edge?

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 2, 2017

Member

recuse yourself from further involvement in anything to do with Background Geolocation.

I can't, sorry. It's literally my job to be involved in these discussions. When my manager asks, "how did that get into the spec? are we seriously expected to implement that?!". I need to have an answer.

Can someone honestly tell me why the Web is not providing this???

You seem to assume that we don't have a huge list of other priorities. Although this is important, it's not as important as other things. So even if we were all like, "yeah, we totally are going to do this!" it still won't happen for at least 3-5 years.

Member

marcoscaceres commented Jun 2, 2017

recuse yourself from further involvement in anything to do with Background Geolocation.

I can't, sorry. It's literally my job to be involved in these discussions. When my manager asks, "how did that get into the spec? are we seriously expected to implement that?!". I need to have an answer.

Can someone honestly tell me why the Web is not providing this???

You seem to assume that we don't have a huge list of other priorities. Although this is important, it's not as important as other things. So even if we were all like, "yeah, we totally are going to do this!" it still won't happen for at least 3-5 years.

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jun 3, 2017

I can't, sorry. It's literally my job to be involved in these discussions.

Then I only ask that you spend the same time and have the same amount of input to Background Geolocation as you've had to Background Sync and Background fetch. I also recommend that your boss considers Business Continuity or Disaster Recovery or simply let you have a holiday.

it still won't happen for at least 3-5 years.

My contention is that any reasonably talented group of spec writers and/or developers could deliver the desired results in 6 months without violating any of the laws of physics. Where there is a will there is a way!

I also feel it is time for the Waterfall method of spec-writing to be challenged with something more Agile or RAD. I think the lack of competition in the standards space may ultimately be counter-productive. I forget who first asked but I am reminded of "Why is there only one Monopolies and Mergers Commission?"

I can't, sorry. It's literally my job to be involved in these discussions.

Then I only ask that you spend the same time and have the same amount of input to Background Geolocation as you've had to Background Sync and Background fetch. I also recommend that your boss considers Business Continuity or Disaster Recovery or simply let you have a holiday.

it still won't happen for at least 3-5 years.

My contention is that any reasonably talented group of spec writers and/or developers could deliver the desired results in 6 months without violating any of the laws of physics. Where there is a will there is a way!

I also feel it is time for the Waterfall method of spec-writing to be challenged with something more Agile or RAD. I think the lack of competition in the standards space may ultimately be counter-productive. I forget who first asked but I am reminded of "Why is there only one Monopolies and Mergers Commission?"

@chaals

This comment has been minimized.

Show comment
Hide comment
@chaals

chaals Jun 3, 2017

@RichardMaher There are lots of reasons why someone - @marcoscaceres isn't unique, any more than you or I - would have other priorities. Each proposal has to stand on use cases and the people who are going to work on them. Which is not necessarily "fair", but is how reality occurs...

And to be clear, there are competing organisations writing specs for the Web, and the "waterfall" approach is increasingly being abandoned - the specs produced by WebPlatform and various other W3C groups are implementation led and test driven - which is one reason a good idea might not become "a standard" in just the time it takes to write the spec.

chaals commented Jun 3, 2017

@RichardMaher There are lots of reasons why someone - @marcoscaceres isn't unique, any more than you or I - would have other priorities. Each proposal has to stand on use cases and the people who are going to work on them. Which is not necessarily "fair", but is how reality occurs...

And to be clear, there are competing organisations writing specs for the Web, and the "waterfall" approach is increasingly being abandoned - the specs produced by WebPlatform and various other W3C groups are implementation led and test driven - which is one reason a good idea might not become "a standard" in just the time it takes to write the spec.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 3, 2017

Member

(Good example being web payments: where Google implemented like 1 year ago, Microsoft too is about to ship - Mozilla is helping write the spec and provide web platform tests, while implementing at same time for a release maybe sometime late next year)

Member

marcoscaceres commented Jun 3, 2017

(Good example being web payments: where Google implemented like 1 year ago, Microsoft too is about to ship - Mozilla is helping write the spec and provide web platform tests, while implementing at same time for a release maybe sometime late next year)

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jun 4, 2017

I see merit in that strategy. Maybe this is a great opportunity for Firefox to finally secure a mobile presence by being the only browser to ship Background Geolocation, and do it in conjunction with specification development?

Shadow DOM also seems to have been developed that way with v1.0 and SLOT input from Apple.

But, once again, Background Geolocation is not a departure from the norm or a seminal moment in Web evolution. It is just using the tools and infrastructure already in place thanks to the specification giants that have gone before us. Service Worker Extensibility is there! Permissions are (almost) there! All that's left to argue about is nomenclature.

We need the UA or other omnipresent daemon (which currently exists to support push notifications) to watch location changes and deliver TravelEvents to and existing SW or instantiate a fresh one. Sorry but I just don't see 3 years work in that!

I see merit in that strategy. Maybe this is a great opportunity for Firefox to finally secure a mobile presence by being the only browser to ship Background Geolocation, and do it in conjunction with specification development?

Shadow DOM also seems to have been developed that way with v1.0 and SLOT input from Apple.

But, once again, Background Geolocation is not a departure from the norm or a seminal moment in Web evolution. It is just using the tools and infrastructure already in place thanks to the specification giants that have gone before us. Service Worker Extensibility is there! Permissions are (almost) there! All that's left to argue about is nomenclature.

We need the UA or other omnipresent daemon (which currently exists to support push notifications) to watch location changes and deliver TravelEvents to and existing SW or instantiate a fresh one. Sorry but I just don't see 3 years work in that!

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jun 6, 2017

Ok, forgetting green-field implementation aspirations and fully embracing "we are where we are" pragmatism, the following is a very workable Background GeoLocation permissions solution: -

The PositionsOptions Interface needs to be expanded to take:

  • boolean enableBackgroundWatch = false The UA will know to expect/accept a registration request with the TravelManager but, if not, who cares? ServiceWorker instantiation and TravelEvent delivery will only occur when the Client page/app is backgrounded or the phone is asleep i.e. It is the UA's responsibility decide when the mainline/client is incapable of receiving location events. For permissions, If not perviously granted, user-permission must be sought clearly specifying "Background Location continuity" in the permission description. [This attribute will be ignored (thrown?) for getCurrentLocation] TODO: Although Location has a sub-permission of "accurate" (at least on Android) and now "background", there appears to be no way to set the sub-privileges individually. How do other privileges handle this granularity? Tickboxes?
  • unsigned long minJourney = 0 If omitted there is no minimum distance required an all events will be delivered. [This attribute will be ignored (thrown?) for getCurrentLocation]
  • unsigned long minInterval = 0 If omitted no period of time must elapse between location events,[This attribute will be ignored (thrown?) for getCurrentLocation]

Cons: -

  1. I'm guessing UA implementations of watchPosition() are done in the Tab/App/process context and not globally at the UA.
  2. Messy having two registrations for the "same" event? TravelManager and watchLocation
  3. The tight coupling of SW and Client could be undesirable and confusing. Especially for fleet management where sometimes the server is updated from the Client and sometimes from the SW. Perhaps a "boolean enableForeground = true"? If false SW will get all position events foreground and background?

RichardMaher commented Jun 6, 2017

Ok, forgetting green-field implementation aspirations and fully embracing "we are where we are" pragmatism, the following is a very workable Background GeoLocation permissions solution: -

The PositionsOptions Interface needs to be expanded to take:

  • boolean enableBackgroundWatch = false The UA will know to expect/accept a registration request with the TravelManager but, if not, who cares? ServiceWorker instantiation and TravelEvent delivery will only occur when the Client page/app is backgrounded or the phone is asleep i.e. It is the UA's responsibility decide when the mainline/client is incapable of receiving location events. For permissions, If not perviously granted, user-permission must be sought clearly specifying "Background Location continuity" in the permission description. [This attribute will be ignored (thrown?) for getCurrentLocation] TODO: Although Location has a sub-permission of "accurate" (at least on Android) and now "background", there appears to be no way to set the sub-privileges individually. How do other privileges handle this granularity? Tickboxes?
  • unsigned long minJourney = 0 If omitted there is no minimum distance required an all events will be delivered. [This attribute will be ignored (thrown?) for getCurrentLocation]
  • unsigned long minInterval = 0 If omitted no period of time must elapse between location events,[This attribute will be ignored (thrown?) for getCurrentLocation]

Cons: -

  1. I'm guessing UA implementations of watchPosition() are done in the Tab/App/process context and not globally at the UA.
  2. Messy having two registrations for the "same" event? TravelManager and watchLocation
  3. The tight coupling of SW and Client could be undesirable and confusing. Especially for fleet management where sometimes the server is updated from the Client and sometimes from the SW. Perhaps a "boolean enableForeground = true"? If false SW will get all position events foreground and background?
@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jun 6, 2017

Plan B

Separate "Background Location" permission required. Total isolation/mutual exclusion between Client location gathering and Service Worker's efforts: -

// https://example.com/serviceworker.js
this.ontravel = function(event) {
  console.log(event.position);
  // From here we can postMessage() the position details to client, 
  // we can foreground the client, or we can merely XHR/Fetch the details
  // to the fleet-management server so that everyone can see where their pizza is.
}

// https://example.com/webapp.js
navigator.serviceWorker.register('serviceworker.js').then(
  function(serviceWorkerRegistration) {
  // This next line is when the user gets prompted for background geolocation access permission
    serviceWorkerRegistration.travelManager.subscribe({accurate:true, minJourney:10}).then(
      function(pushSubscription) {
        console.log(pushSubscription.options);
      }, function(error) {
        // During development it often helps to log errors to the
        // console. In a production environment it might make sense to
        // also report information about errors back to the
        // application server.
        console.log(error);
      }
    );
  });

Cons: -

When Ultimate Web Apps are first-class citizens, how to incorporate/surface the ability to turn off just background-geolocation permission and not just the sledge-hammer of all Location?

RichardMaher commented Jun 6, 2017

Plan B

Separate "Background Location" permission required. Total isolation/mutual exclusion between Client location gathering and Service Worker's efforts: -

// https://example.com/serviceworker.js
this.ontravel = function(event) {
  console.log(event.position);
  // From here we can postMessage() the position details to client, 
  // we can foreground the client, or we can merely XHR/Fetch the details
  // to the fleet-management server so that everyone can see where their pizza is.
}

// https://example.com/webapp.js
navigator.serviceWorker.register('serviceworker.js').then(
  function(serviceWorkerRegistration) {
  // This next line is when the user gets prompted for background geolocation access permission
    serviceWorkerRegistration.travelManager.subscribe({accurate:true, minJourney:10}).then(
      function(pushSubscription) {
        console.log(pushSubscription.options);
      }, function(error) {
        // During development it often helps to log errors to the
        // console. In a production environment it might make sense to
        // also report information about errors back to the
        // application server.
        console.log(error);
      }
    );
  });

Cons: -

When Ultimate Web Apps are first-class citizens, how to incorporate/surface the ability to turn off just background-geolocation permission and not just the sledge-hammer of all Location?

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Jun 6, 2017

Collaborator

To reiterate my previous comments: Service workers aren't intended for continual background operation in the way that's being proposed here. They're designed to wake up for an event, briefly handle it, then go away. This should be especially brief if the user doesn't have a tab open to the site.

Keeping a tab awake is a better solution as it isn't geo-location specific and enables a wider range of use-cases. It's also more privacy friendly as there's a tab the user can close to cease activity. On mobile, a sticky notification can inform the user about locked tabs/apps, and tapping the notification can return them to the tab. This is pretty much how Android does things natively.

This shouldn't be any worse for battery, unless your page is using more CPU than it needs to, eg doing work to update the page visually while it isn't visible. The page visibility API helps here, and CSS animations / requestAnimationFrame already stop when the tab isn't visible.

It's possible that memory usage will be greater keeping a page open vs a service worker, but I'm not sure by how much. If this turns out to be an issue, we could look at ways to fix it (I'm not convinced it'd be using a service worker).

For any given GeoFence…

To clarify, I'm referring to the kind of geo tracking that an exercise tracker would need. Geofencing is a different thing, and does kinda fit with service worker's model.

Collaborator

jakearchibald commented Jun 6, 2017

To reiterate my previous comments: Service workers aren't intended for continual background operation in the way that's being proposed here. They're designed to wake up for an event, briefly handle it, then go away. This should be especially brief if the user doesn't have a tab open to the site.

Keeping a tab awake is a better solution as it isn't geo-location specific and enables a wider range of use-cases. It's also more privacy friendly as there's a tab the user can close to cease activity. On mobile, a sticky notification can inform the user about locked tabs/apps, and tapping the notification can return them to the tab. This is pretty much how Android does things natively.

This shouldn't be any worse for battery, unless your page is using more CPU than it needs to, eg doing work to update the page visually while it isn't visible. The page visibility API helps here, and CSS animations / requestAnimationFrame already stop when the tab isn't visible.

It's possible that memory usage will be greater keeping a page open vs a service worker, but I'm not sure by how much. If this turns out to be an issue, we could look at ways to fix it (I'm not convinced it'd be using a service worker).

For any given GeoFence…

To clarify, I'm referring to the kind of geo tracking that an exercise tracker would need. Geofencing is a different thing, and does kinda fit with service worker's model.

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jun 6, 2017

They're designed to wake up for an event, briefly handle it, then go away. This should be especially brief if the user doesn't have a tab open to the site.

No they are not. This has been explained to you many times before by wonderfully talented people like Ben. Simply repeating a lie/conjecture over and over does not make it any the more true.

I hope the irony of you literally just typing this: -

You can't simply state these things, you need to give reasoning. By showing your working, it may become obvious that your understanding of these features is incorrect.

over here was not wasted on anyone.

The fact that the spec says a UA may terminate a SW at anytime by no means implies inevitability or compulsion to do so and, if the two quoted implementations are anything to go by, it simply doesn't happen. I'm not sure if you're FUDding intentionally or you simply don't understand the performance benefits of Service Worker recycling.

Even with the stipulated restrictions on global state, Service Worker re-use is extremely desirable for the performance of a subsequent Push Notification or Travel Events as well as the reduction in the device resources needed purely to spin-up/run-down a service worker. Why would one not leverage this low-hanging performance fruit? In fact, in the absence of memory and/or CPU resource load I can't see why Service Workers don't enjoy extended lifespans.

Anyway, "To reiterate my previous comments: " See how the ServiceWorker paradigm fits shimlessly with user movement: -

Travelling->Travelling->Travelling->------------At Rest---------> Travelling scenarios.
< ------- Service Worker 1 ------------>...................................................<-- SW 2 --->

Then, of course, there is the beauty of not having to foreground and/or instantiate a client/complete-UA if all the SW wants to do is tell fleet management (or facebook friends) that you've moved! This is a marriage made in heaven.

Yep, Service Workers and Background Geolocation truly are a Dream Team!

WRT other FUD on wake_lock sledge hammers: -

This shouldn't be any worse for battery,

It's possible that memory usage will be greater keeping a page open vs a service worker, but I'm not sure by how much.

Really? Not even anecdotal? Can't "simply state these things" . . . :-(

I'll let that sort of informed opinion and scientific analysis go through to the keeper if you don't mind. There's too much to be achieved and too much work to be done.

To clarify, I'm referring to the kind of geo tracking that an exercise tracker would need. Geofencing is a different thing, and does kinda fit with service worker's model.

"A different thing that kinda fits". Well I certainly can't argue with that.

FYI Chrome has abandoned the GeoFencing specification and there is no other intended implementation.

RichardMaher commented Jun 6, 2017

They're designed to wake up for an event, briefly handle it, then go away. This should be especially brief if the user doesn't have a tab open to the site.

No they are not. This has been explained to you many times before by wonderfully talented people like Ben. Simply repeating a lie/conjecture over and over does not make it any the more true.

I hope the irony of you literally just typing this: -

You can't simply state these things, you need to give reasoning. By showing your working, it may become obvious that your understanding of these features is incorrect.

over here was not wasted on anyone.

The fact that the spec says a UA may terminate a SW at anytime by no means implies inevitability or compulsion to do so and, if the two quoted implementations are anything to go by, it simply doesn't happen. I'm not sure if you're FUDding intentionally or you simply don't understand the performance benefits of Service Worker recycling.

Even with the stipulated restrictions on global state, Service Worker re-use is extremely desirable for the performance of a subsequent Push Notification or Travel Events as well as the reduction in the device resources needed purely to spin-up/run-down a service worker. Why would one not leverage this low-hanging performance fruit? In fact, in the absence of memory and/or CPU resource load I can't see why Service Workers don't enjoy extended lifespans.

Anyway, "To reiterate my previous comments: " See how the ServiceWorker paradigm fits shimlessly with user movement: -

Travelling->Travelling->Travelling->------------At Rest---------> Travelling scenarios.
< ------- Service Worker 1 ------------>...................................................<-- SW 2 --->

Then, of course, there is the beauty of not having to foreground and/or instantiate a client/complete-UA if all the SW wants to do is tell fleet management (or facebook friends) that you've moved! This is a marriage made in heaven.

Yep, Service Workers and Background Geolocation truly are a Dream Team!

WRT other FUD on wake_lock sledge hammers: -

This shouldn't be any worse for battery,

It's possible that memory usage will be greater keeping a page open vs a service worker, but I'm not sure by how much.

Really? Not even anecdotal? Can't "simply state these things" . . . :-(

I'll let that sort of informed opinion and scientific analysis go through to the keeper if you don't mind. There's too much to be achieved and too much work to be done.

To clarify, I'm referring to the kind of geo tracking that an exercise tracker would need. Geofencing is a different thing, and does kinda fit with service worker's model.

"A different thing that kinda fits". Well I certainly can't argue with that.

FYI Chrome has abandoned the GeoFencing specification and there is no other intended implementation.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald Jun 6, 2017

Collaborator

They're designed to wake up for an event, briefly handle it, then go away. This should be especially brief if the user doesn't have a tab open to the site.

No they are not. This has been explained to you many times before by wonderfully talented people like Ben. Simply repeating a lie/conjecture over and over does not make it any the more true.

I'm one of the editors and designers of service workers (@wanderview is another designer), so I know a thing or two about what they were designed for 😄 . The link you provide doesn't 'disprove' what I'm saying. Browsers have a grace period to avoid additional startup costs, but service workers are terminated when they aren't needed.

over here was not wasted on anyone.

This doesn't appear to be related. The situation there is the same. Wake up for an event, terminate once complete.

if the two quoted implementations are anything to go by, it simply doesn't happen. I'm not sure if you're FUDding intentionally or you simply don't understand the performance benefits of Service Worker recycling.

I am one of the people that designed what you call "service worker recycling". However, this does not mean workers can remain active for long periods of time when tabs are closed. Both Chrome and Firefox will terminate service workers when they're inactive.

Like I said in another thread, you should consider for a moment that you might not be the only non-idiot on the planet, and the source of your frustration may be your own lack of understanding. I empathise as I also engage in areas of development I'm less familiar with, but I increase my understanding by politely asking questions, and ensuring I test & understand conditions before declaring myself an authority – I've found this to be the quickest way to learn, and the best way to effect change.

I appreciate you made efforts to avoid being what I'd call an arsehole… briefly, but if you want to continue this conversation you're going to have to give it another go and stick with it.

I've abandoned responding to your post, but I'd happily continue if you apologise and restate your questions in a non-aggressive and polite manner. But do realise that I have no professional obligation to engage with you, so if you want to be heard (and it sounds like you're pretty eager to be), it's on those terms. Otherwise we'll have to wait for someone reasonable to discuss the features you're interested in.

Collaborator

jakearchibald commented Jun 6, 2017

They're designed to wake up for an event, briefly handle it, then go away. This should be especially brief if the user doesn't have a tab open to the site.

No they are not. This has been explained to you many times before by wonderfully talented people like Ben. Simply repeating a lie/conjecture over and over does not make it any the more true.

I'm one of the editors and designers of service workers (@wanderview is another designer), so I know a thing or two about what they were designed for 😄 . The link you provide doesn't 'disprove' what I'm saying. Browsers have a grace period to avoid additional startup costs, but service workers are terminated when they aren't needed.

over here was not wasted on anyone.

This doesn't appear to be related. The situation there is the same. Wake up for an event, terminate once complete.

if the two quoted implementations are anything to go by, it simply doesn't happen. I'm not sure if you're FUDding intentionally or you simply don't understand the performance benefits of Service Worker recycling.

I am one of the people that designed what you call "service worker recycling". However, this does not mean workers can remain active for long periods of time when tabs are closed. Both Chrome and Firefox will terminate service workers when they're inactive.

Like I said in another thread, you should consider for a moment that you might not be the only non-idiot on the planet, and the source of your frustration may be your own lack of understanding. I empathise as I also engage in areas of development I'm less familiar with, but I increase my understanding by politely asking questions, and ensuring I test & understand conditions before declaring myself an authority – I've found this to be the quickest way to learn, and the best way to effect change.

I appreciate you made efforts to avoid being what I'd call an arsehole… briefly, but if you want to continue this conversation you're going to have to give it another go and stick with it.

I've abandoned responding to your post, but I'd happily continue if you apologise and restate your questions in a non-aggressive and polite manner. But do realise that I have no professional obligation to engage with you, so if you want to be heard (and it sounds like you're pretty eager to be), it's on those terms. Otherwise we'll have to wait for someone reasonable to discuss the features you're interested in.

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Jun 6, 2017

Member

@RichardMaher, it might be best we take this off GitHub. I'm happy to answer questions in real time about all the specs you keep hitting, but going around in circles and us all getting frustrated is not helping this move forward. We are in almost the same time zone- we can chat on slack, irc, hangouts... choice is yours. You know my email. Friday is free for me.

Member

marcoscaceres commented Jun 6, 2017

@RichardMaher, it might be best we take this off GitHub. I'm happy to answer questions in real time about all the specs you keep hitting, but going around in circles and us all getting frustrated is not helping this move forward. We are in almost the same time zone- we can chat on slack, irc, hangouts... choice is yours. You know my email. Friday is free for me.

@RichardMaher

This comment has been minimized.

Show comment
Hide comment
@RichardMaher

RichardMaher Jun 7, 2017

Stackoverflow bounty closes in 40mins

Stackoverflow bounty closes in 40mins

@w3c w3c deleted a comment from RichardMaher Jun 9, 2017

@w3c w3c deleted a comment from RichardMaher Jun 9, 2017

@w3c w3c deleted a comment from RichardMaher Jun 9, 2017

@w3c w3c deleted a comment from jakearchibald Jun 9, 2017

@Zibri

This comment has been minimized.

Show comment
Hide comment
@Zibri

Zibri Aug 26, 2017

It would be great to send a push notification to (for example) a phone and get back a notification on the position. Also very good would an api for tracking a device. (As google maps can do). In this way everything (about geolocation) would be possible in a webapp too.

Zibri commented Aug 26, 2017

It would be great to send a push notification to (for example) a phone and get back a notification on the position. Also very good would an api for tracking a device. (As google maps can do). In this way everything (about geolocation) would be possible in a webapp too.

@Zibri

This comment has been minimized.

Show comment
Hide comment
@Zibri

Zibri Aug 26, 2017

About the security issues, IMHO it's simple: a new permission like GEOTRACK or something like that or INHERIT the permission already given to the origin and scope or the worker.

Zibri commented Aug 26, 2017

About the security issues, IMHO it's simple: a new permission like GEOTRACK or something like that or INHERIT the permission already given to the origin and scope or the worker.

@MeritBased

This comment has been minimized.

Show comment
Hide comment
@MeritBased

MeritBased Nov 14, 2017

Can I please ask you all to consider looking outside the W3C/IETF opinion pool for solution and design ideas on this?

Stackoverflow for example: - Background Geolocation ServiceWorker - onMessage Event order when Web App regains focus has over 430 views and 12 votes and the answer a further 2 votes. Expected ratio of ServiceWorker instances to Geolocation Updates has 126 views plus 5 and 1 votes respectively.

The source-code for the TravelManager POC and polyfill, along with an aaa_readme.txt, can be found here

If you wish to see the example without copying then, after reading the readme file, run the Ultimate Web App from Brotkrumen

The CPU Wake Lock may well be all that is needed for other/true sensors but Background Geolocation needs the Service Worker Travel Manager!

Can I please ask you all to consider looking outside the W3C/IETF opinion pool for solution and design ideas on this?

Stackoverflow for example: - Background Geolocation ServiceWorker - onMessage Event order when Web App regains focus has over 430 views and 12 votes and the answer a further 2 votes. Expected ratio of ServiceWorker instances to Geolocation Updates has 126 views plus 5 and 1 votes respectively.

The source-code for the TravelManager POC and polyfill, along with an aaa_readme.txt, can be found here

If you wish to see the example without copying then, after reading the readme file, run the Ultimate Web App from Brotkrumen

The CPU Wake Lock may well be all that is needed for other/true sensors but Background Geolocation needs the Service Worker Travel Manager!

@MauroJr

This comment has been minimized.

Show comment
Hide comment
@MauroJr

MauroJr Feb 11, 2018

Is there any plan to provide background geolocation for web apps, similarly as currently we can do background sync and push notifications?

My company would love to replace our current native app (Android / IOS) for a PWA, but unfortunately, it's not possible to do geofence in the background with a PWA.

For instance, our app does not require to be opened to alert the user for a geofence event, the geofence service starts automatically in the background.

Sorry if here it's not the right place to put this question, I can not imagine a background service running on a PWA other than through Service Worker. But I have no problem being wrong.

I just wanna see Web Apps to be capable to replace Native Apps in most possible scenarios and would love to know your opinions guys. Background Geofence is one of those scenarios which the PWA will not replace Native Apps?

MauroJr commented Feb 11, 2018

Is there any plan to provide background geolocation for web apps, similarly as currently we can do background sync and push notifications?

My company would love to replace our current native app (Android / IOS) for a PWA, but unfortunately, it's not possible to do geofence in the background with a PWA.

For instance, our app does not require to be opened to alert the user for a geofence event, the geofence service starts automatically in the background.

Sorry if here it's not the right place to put this question, I can not imagine a background service running on a PWA other than through Service Worker. But I have no problem being wrong.

I just wanna see Web Apps to be capable to replace Native Apps in most possible scenarios and would love to know your opinions guys. Background Geofence is one of those scenarios which the PWA will not replace Native Apps?

@merlinnot

This comment has been minimized.

Show comment
Hide comment
@merlinnot

merlinnot Feb 11, 2018

I hope I’ll see the day when we’ll be able to take advantage of it. My company decided to go with PWA instead of native apps and it works great, but we currently have to maintain a “companion app” which does literally nothing but sends geolocation to the server. There’s even no UI except of signing in. User installs it once and never uses it again (in the foreground).

I’d be so happy to get rid of this weirdo ;)

I hope I’ll see the day when we’ll be able to take advantage of it. My company decided to go with PWA instead of native apps and it works great, but we currently have to maintain a “companion app” which does literally nothing but sends geolocation to the server. There’s even no UI except of signing in. User installs it once and never uses it again (in the foreground).

I’d be so happy to get rid of this weirdo ;)

@valeriob

This comment has been minimized.

Show comment
Hide comment
@valeriob

valeriob Feb 12, 2018

Since the issue is closed, is there an active discussion about this feature ?

Since the issue is closed, is there an active discussion about this feature ?

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Feb 12, 2018

Member

No, but if you'd like to incubate an idea, you can propose it at https://discourse.wicg.io

Member

marcoscaceres commented Feb 12, 2018

No, but if you'd like to incubate an idea, you can propose it at https://discourse.wicg.io

@marcoscaceres

This comment has been minimized.

Show comment
Hide comment
@marcoscaceres

marcoscaceres Feb 12, 2018

Member

Thanks, @valeriob! I'll just note that there is limited interest from browser vendors to take this on at the moment. However, there is no harm in developers exploring solutions. Will follow up on discourse.

Member

marcoscaceres commented Feb 12, 2018

Thanks, @valeriob! I'll just note that there is limited interest from browser vendors to take this on at the moment. However, there is no harm in developers exploring solutions. Will follow up on discourse.

@tomayac

This comment has been minimized.

Show comment
Hide comment
@tomayac

tomayac Feb 26, 2018

@marcoscaceres The discussion on Discourse starts to get, erm, noisy for similar reasons than it got noisy here. Nevertheless left some comments and hope they get noticed.

tomayac commented Feb 26, 2018

@marcoscaceres The discussion on Discourse starts to get, erm, noisy for similar reasons than it got noisy here. Nevertheless left some comments and hope they get noticed.

@tomayac tomayac referenced this issue in WICG/geolocation-sensor Feb 26, 2018

Open

Geofencing use cases #17

@merlinnot

This comment has been minimized.

Show comment
Hide comment
@merlinnot

merlinnot Feb 27, 2018

I don't use this phrase a lot in public posts, but... LOL. This discussion got waaaay out of hand, but everything is so easy in reality...

I don't use this phrase a lot in public posts, but... LOL. This discussion got waaaay out of hand, but everything is so easy in reality...

@karianpour

This comment has been minimized.

Show comment
Hide comment
@karianpour

karianpour May 13, 2018

I have a use case that getting a geo-location with distance/time based update is necessary, ofcourse with the user permission. So far, what I see, the only way is native app which the construction and maintenance is too expensive, so not feasible to do. But if it could be done in PWA, it would be feasible. The use case is in paragliding competitions where people fly in the air and the organizer MUST follow them for the pilot safety / air space security / competition rules. And also it would be nice to watch them live for spectators, as it is a more fun, just like watching football match. And after the competition, the organizer should collect all the 100 pilots scattered in a 60km wide field with designated vehicles.

I really appreciate the PWA spec so far and I make use of it in my web apps.

I think that people behind PWA are with web background trying to walk to the native app world. That won't make it good practice for a web app. I wish that there was some one with native app background one the community.

@jakearchibald , I understand your concerns. All the time you speak about PAGE, and so far what I found in "PWA" is "Progressive Web Pages" not App.

@marcoscaceres, I understand that you have to answer the people in the hierarchy, but being conservative will never make a change, and of course wiping away the question is the simplest. I wish that you boss some day asks you "Why did't you listen to the requests?"

Giving the geo-location by it self is not a privacy violation. And the use cases are a lot, and making it safe is hard.

The spec might be like to register to get the location every 3 seconds / every 10 meter, and the user get a permission box to allow or not. And the service worker get a location changed event every 3 seconds / every 10 meter.

karianpour commented May 13, 2018

I have a use case that getting a geo-location with distance/time based update is necessary, ofcourse with the user permission. So far, what I see, the only way is native app which the construction and maintenance is too expensive, so not feasible to do. But if it could be done in PWA, it would be feasible. The use case is in paragliding competitions where people fly in the air and the organizer MUST follow them for the pilot safety / air space security / competition rules. And also it would be nice to watch them live for spectators, as it is a more fun, just like watching football match. And after the competition, the organizer should collect all the 100 pilots scattered in a 60km wide field with designated vehicles.

I really appreciate the PWA spec so far and I make use of it in my web apps.

I think that people behind PWA are with web background trying to walk to the native app world. That won't make it good practice for a web app. I wish that there was some one with native app background one the community.

@jakearchibald , I understand your concerns. All the time you speak about PAGE, and so far what I found in "PWA" is "Progressive Web Pages" not App.

@marcoscaceres, I understand that you have to answer the people in the hierarchy, but being conservative will never make a change, and of course wiping away the question is the simplest. I wish that you boss some day asks you "Why did't you listen to the requests?"

Giving the geo-location by it self is not a privacy violation. And the use cases are a lot, and making it safe is hard.

The spec might be like to register to get the location every 3 seconds / every 10 meter, and the user get a permission box to allow or not. And the service worker get a location changed event every 3 seconds / every 10 meter.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald May 14, 2018

Collaborator

@karianpour

All the time you speak about PAGE, and so far what I found in "PWA" is "Progressive Web Pages" not App.

By page I mean the context that contains the UI, rather than a worker.

Collaborator

jakearchibald commented May 14, 2018

@karianpour

All the time you speak about PAGE, and so far what I found in "PWA" is "Progressive Web Pages" not App.

By page I mean the context that contains the UI, rather than a worker.

@adamburr100

This comment has been minimized.

Show comment
Hide comment
@adamburr100

adamburr100 May 26, 2018

OK. I've come to this late and have read the whole discussion - phew!

My use case is one where mobile workers need to be tracked by their employer during their work shift to allow their location to appear on a "control map". This will improve the employees personal safety and also, if one employee is in distress it will be easy for the nearest other employee to be sent to give help.

Similarly, the controller can see which employee is nearest to a given location and can therefore despatch the closest employee to attend.

I am trying to do this using a PWA, but it currently fails to report the position whenever the browser is not being displayed.

Cutting to the chase, should I give up my PWA and write a native app, or is there a way to do this in a PWA?

I'd be grateful for any help with this decision.

OK. I've come to this late and have read the whole discussion - phew!

My use case is one where mobile workers need to be tracked by their employer during their work shift to allow their location to appear on a "control map". This will improve the employees personal safety and also, if one employee is in distress it will be easy for the nearest other employee to be sent to give help.

Similarly, the controller can see which employee is nearest to a given location and can therefore despatch the closest employee to attend.

I am trying to do this using a PWA, but it currently fails to report the position whenever the browser is not being displayed.

Cutting to the chase, should I give up my PWA and write a native app, or is there a way to do this in a PWA?

I'd be grateful for any help with this decision.

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald May 29, 2018

Collaborator

@adamburr100 the answer here is to keep the page awake, using something like https://w3c.github.io/wake-lock/. This isn't a feature for service workers.

I don't believe any browsers support wake-lock yet.

Collaborator

jakearchibald commented May 29, 2018

@adamburr100 the answer here is to keep the page awake, using something like https://w3c.github.io/wake-lock/. This isn't a feature for service workers.

I don't believe any browsers support wake-lock yet.

@adamburr100

This comment has been minimized.

Show comment
Hide comment
@adamburr100

adamburr100 May 29, 2018

Thanks @jakearchibald

So if I understand you correctly, it is currently impossible to do what I need to do using a browser app.

I should give up my PWA and switch to producing a native app, right?

Thanks @jakearchibald

So if I understand you correctly, it is currently impossible to do what I need to do using a browser app.

I should give up my PWA and switch to producing a native app, right?

@jakearchibald

This comment has been minimized.

Show comment
Hide comment
@jakearchibald

jakearchibald May 29, 2018

Collaborator

@adamburr100 I don't know the relative priorities & timelines of the features you're trying to achieve, but if a required feature is impossible on a given platform in the timeframe you're beholden to, then I agree that the platform in question is a poor target for you currently.

Collaborator

jakearchibald commented May 29, 2018

@adamburr100 I don't know the relative priorities & timelines of the features you're trying to achieve, but if a required feature is impossible on a given platform in the timeframe you're beholden to, then I agree that the platform in question is a poor target for you currently.

@tyrex1975

This comment has been minimized.

Show comment
Hide comment
@tyrex1975

tyrex1975 Jun 19, 2018

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.

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

This comment has been minimized.

Show comment
Hide comment
@CharlBest

CharlBest Jul 2, 2018

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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment