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:
- A wishes to inform B of an event within a given geo-spatial area
- A wishes to know that B is within a given geo-spatial area
- 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:
- 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.
- The GeoLocation Service Worker can be referenced from the Service Worker.
- 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.
- 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.