[Proposal] Expose GeoLocation to Service Workers


#38

FYI, I’ve banned @Richard_Maher from our discourse for repeated code of conduct violations.

If he returns under a different alias (which he tends to do), please let me know.

Please refrain from engaging with him on Discourse or standards discussions.


#39

I’ve also deleted @Richard_Maher posts, as they are just noise.

Apologies to participants in this thread for not taking action sooner. This individual has been trolling our community for a long time, and, despite numerous pledges from him to behave - or claims that he will go away, he keeps coming back.


#40

I’m not sure if i should add this here or in a new post, but i also feel the need to use some of the functionality requested here, in particular the access to the geofencing api. The main goal is to use the device location services in a practical and battery-efficient way.

Here are some scenarios that i can think of:

  • an airline app can define a geofence around an airport when a flight reservation is near boarding time. When the device crosses the geofence, the app can send a notification that takes users to an activity that allows them to get their boarding pass. (taken from google geofencing api)

  • Travel guide assistance - Could define multiple interesting areas around a city, accordingly to the user interests, and warn users when they are entering or leaving that area of interest.

There exists such functionality in native apps, for example in andoid and in ios.


#41

The other use case can be in sport area. Like paragliding where the participants should be tracked and scored. The location should be tracked every 3 second and send to the server when network is available and it is better to be send LIFO (last in first out) so the server knows the last location as soon as possible to show it to the spectators on the web site. Also the server must care about, the rules (where to go and where not to go), the safety (where was the pilot lately if she/he is missing) and at the end of competition to collect them from about 60 km wide playing field with designated vehicles, the server must track the vehicles as well. One more thing, the altitude is also important, not only lat/long.

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.


#42

Two use cases that are perhaps a little left of field but I think are important.

  • Museum content based on geofences that represent different exhibitions. Research in the area of museums and other cultural orgs has shown that their apps tend to go un-used whilst their websites are visited regularly. As the web is challenged by native apps there is an opportunity in the cultural space to maintain dominance. In cultural spaces you tend to react to where the user is or what they are seeing to cue different experiences and content. Being able to access GeoLocation via SW would give developers in this space one less reason to have to build a native app.

  • Festival content based on geofences that represent different festival stages/performances areas. Useful via SW because you could send notifications as people pass locations - especially useful for events that span entire cities.

  • Art installations/web art. As the world of digital art continues to explore having more APIs available to web artists and creative coders will unlock artworks that cannot be created by other means. Artworks need to capture an audience quickly and instantly - asking a user to download an app before viewing an artwork doesn’t lead to much usage for the same reasons museums have issues (see link above).

It is anecdotal, but all 3 of the above instances have lead me (or the companies I’ve worked for) to have to pursue native apps just for geofencing capabilities (even though for many other reasons a PWA would have been better).


#43

I was under the impression that SW could use geolocation?

OTOH, these use cases are great reasons that browsers should be not only aware of the device location but also the location of other geographic features, so that it can do reasonable things, possibly including geofencing.

This is one of the things we’re trying to accomplish with Map Markup Language. https://discourse.wicg.io/t/map-markup-language/1267/4


#44

:frowning: There is some stuff that could have been editied out because it is inappropriate noise, but as far as possible it is helpful to have the other stuff available.


#45

This space has very low tolerance to abusive behaviour, as we believe that inclusivity towards abusers results in excluding others. It is not the chairs’ role to edit out the poison while trying the guess whatever substantial contribution was intertwined in it. If someone has something valuable to say, they can say it without demeaning others.


#46

First off, I just wanted to say thank you for the patience of those who not only read the associated material relating to the topic but also keeping a professional and open mind through the associated noise. I’ve been aware of the general problem for over a year now. Knowing our own customer requirements and potential future features which surround this topic. Generally I was hoping that some solution would have been proposed by now however this has not been the case.

With this in mind I would like to state what I believe to be the general high-level use-cases and the constraints of the problem:

  1. A wishes to inform B of an event within a given geo-spatial area
  2. A wishes to know that B is within a given geo-spatial area
  3. A wishes to know where B is

The primary constraint of the above is that A would be (or proxied by) a server and that the requirements apply when the user does not have the application in the foreground. The secondary constraint is that the above be also applicable if the application was installed and neither in the foreground or background.

Examples of specific user stories have been given however as demonstrated in the Wake Lock API proposal (http://w3c-webmob.github.io/wake-lock-use-cases/) there is a lack of direct references of Applications. Personally I do find it a little frustrating that to have an idea considered, you must demonstrate it being done somewhere else - however I’ve worked with customers where we must do exactly that so it shouldn’t be too unexpected.

With note to the Wake Lock API proposal - some use cases would be covered by that proposal however the conditions of such API listed below would not make the API suitable for others from a user experience perspective:

  • The application would have to be initially loaded to the Foreground before being applicable.
  • The application would still run the full UA application and accompanying resources (when using System lock).

The key I believe that distinguishes this proposal is that activity occurs in the background instead of within the primary UA loaded application. As such the considerations I think apply to moving the proposal forward are; performance, activity, security and simplicity.

  • Performance relates to the consumption of resources - this is the primary reason I don’t believe Wake Lock API is appropriate for this use case. The consumption of minimal resources as possible and the acceptance of system throttling.
  • Activity relates to use of frequency of processing and the use of network resources. Network requests consumes user bandwidth (costing user money) and a bad example of usage would be continuously sending position updates to the server.
  • Security relates to user awareness of the activity, integrity of the source of the activity (the application), and control of such activity.
  • Simplicity relates not only to implementation but usage by developers.

What I believe this proposal shouldn’t be is:

  • A general background process service (ie. More Service Worker rather than Worker that runs in background)
  • An extension of the standard application logic (the UA application is not running)

With the above, I believe the scope of the proposal should be something more like:

  • This only applies to PWA Installed applications (requiring applications to satisfy the requirements of such installation and the use of Service Workers). Standard GeoLocation API is available to foreground applications and standard web clients shouldn’t behave differently to the standard browser experience - it must require active user installation to be available.
  • A dedicated permission to have access to geo-location data within the background. This permission must then be requested when the user installs the application (or after update for applications already installed). Apple already have this kind of permission (https://support.apple.com/en-gb/HT203033) and the application should assume Denied until explicitly given. The user Must be able to Deny/Approve the permission on the application after the initial request.
  • There needs to be a distinction between passive usage and tracking, and that the user can understand and approve/deny such usage. The above permission allows the application to monitor the users position - I believe the user should have a separate permission for forwarding that position back to the server.

This indicates the following elements for a possible concept design:

  1. The concept of a Service Worker could be reused for the location processor - GeoLocation Service Worker. It operates as a background service and mirrors the same conditions of use/activity as the existing Service Worker - only handling Position Update events from the native location services.
  2. The GeoLocation Service Worker can be referenced from the Service Worker.
  3. Push Notifications extended to provide a Geo-Spatial area (simplest being a radius based area) and provide the ability to only continue processing the notification if the user is within the geo-spatial area (without telling the service worker user code the position directly). This covers the 1) high level use case of “A wishes to inform B of an event within a given geo-spatial area” using Push Notifications.
  4. API extension to the Service Worker to allow subscription to events from the GeoLocation Service Worker providing Position Updates. The subscription should be heavily throttled but could support bulk values (ie. current position + position track since last update). This covers 2) and 3) of the high level use cases as the application code can send network requests to the server with the position data.

I deliberately ignored the permissions gates in the above concept as that would have to be carefully considered in a proper design, alongside what should be done in scenarios where the location is denied or unavailable. This was just provided as thoughts to contribute to the discussion.

From a personal perspective - considering existing implementations, I would like there to be consideration about offering the ability for the user define periods of usage. This is more along the how mail applications sync and do-not-disturb features can be scheduled on Android. From a business employee application perspective the user would be expected to allow the service as required by their Standard Operating Procedures. However for standard consumers this could give a nice level of control to allow when the application can track you. Speaking from personal experience, I was frustrated (and quickly uninstalled after) a fitness tracking application that continuously tracked my location all the time - there was no limitation to when I was actually doing my cycling, it was all the time. Providing this personal control would be a nice addition.

Thank you for reading and I hope this has contributed to the discussion. Below I’ve added some examples of existing applications I’m aware of that have some of the use cases described.

  • Moves (owned by Facebook prior to shutting it down) - Fitness Tracker
    • Use case 3)
    • Why: It tracked users to monitor fitness activities (walking/cycling etc.)
    • Benefit: User had collated data on distances and estimated calories burned. This was meant to provide feedback on there fitness activity and provide motivational support.
    • Negative: User couldn’t control when the application was tracking and subsequently affected battery performance
  • Dark Sky - https://darksky.net
    • Use case 1)
    • Why: It tracks users location to inform them of appropriate weather warnings via push notifications
    • Benefit: User receives notifications of relevant weather updates for their current location without continuously monitoring an active application.