Support geolocation (especially geofencing) in the "background"

[kenchris]

Background here meaning out living the document and service worker lives.

WICG/background-fetch#82

[jakearchibald]

This would be ok for geofencing (in which case we'd just call it geofencing), but I don't think we should have geo polling that keeps the service worker open.

A better way to do that would be via https://w3c.github.io/wake-lock/, because that gives the user somewhere to go back to, and something to close.

[tomayac]

Collected some use cases in #17 (should probably consolidate the two issues).

[tomayac]

After discussing with @jakearchibald, I now understand that we need to look into https://w3c.github.io/ServiceWorker/#extensibility, namely the ExtendableEvent.

[jakearchibald]

"FunctionalEvent" isn't an interface, it's just an example. You'd do something like:

interface GeoChangeEvent : ExtendableEvent {
  // add your own properties and methods
};

[romulocintra]

Hi @jakearchibald @tomayac @kenchris , there is some way to have geolocation in my Home Screen Installed PWA while in background ?

[anssiko]

@romulocintra, not yet, but spec work is now (re)starting, so we hope that to be possible in the future. If you want to help, please check that https://w3c.github.io/geolocation-sensor/#use-cases considers what you had in mind. These use cases inform the spec work. Early implementation(s) will typically follow when there’s an MVP spec and rough consensus. Positive signals from web developers help encourage implementers to consider the feature too.

[anssiko]

• I used "MVP spec" to make a point. The group has not made a formal resolution on what constitutes an "MVP spec" yet. Related discussion in the context of use cases starting at WIP: Use Cases #30 (comment)

• What's new is currently explained in the use cases section ("novel" meaning not shipping):

Note: Only the foreground operations were possible with [GEOLOCATION-API], the background operations are completely novel.

• Timelines are hard to predict in spec work. A static timeline can be found from the charter, in addition I try to update the roadmap on a best effort basis. Please consider all future dates guesstimates.

• The decision to adopt the Geolocation Sensor spec was made by the W3C Advisory Committee when it approved (Member-only link) the current charter on 29 Jun 2018.

I know everyone is impatient to get this feature done. I'm happy to see positive web developer feedback and growing implementer interest. There's a lot of work to do and issues to resolve. By keeping the discussion professional, everyone can help. Thank you.

[romulocintra]

@anssiko , great news , i will follow close as posible in order to check if it goes aligned with our use cases . At moment it serves all our goals. any help on testing/ defining or experimental use please let me know ...

Observation or internal thinkings about posible limitations:
- Battery consumption
- Update cycle
- Would be a mirror from "Mobile Native" implementation
- Limitations in user side (i would be able to activate deactivate this geolocation or even choose strategy when using my installed PWA or always using geo) policies !?

Probably i mixing thins and concepts ... thanks for quick answers before

[anssiko]

@romulocintra, thank you for your feedback. To experiment:

• You can test the foreground API ergonomics using the geolocation-sensor.js polyfill (instructions). Note that also the foreground API is expected to get new features, currently it just mirrors the legacy API, since we had to start from somewhere :-)

• For background geofencing we do not have any polyfill (since that'd be impossible). The API would need to take a different shape, possibly drawing inspiration from the earlier work on the Geofencing API. Anyway, web developer feedback on that API shape welcome.

• For background geotracking (aka continuous background geolocation) we have just started identifying use cases. This has the most significant privacy considerations so will need a good story on how the user's informed (continuous?) consent is acquired to make browser vendors comfortable with the idea.

There's a quick demo you can use as a starting point for your experimentation. It has some rough edges, so beware. Pull requests welcome!

[hadriann]

Both background geotracking and background geofencing are important. Just think of a basic cyclocomputer or a {run, ski, hike} tracker. There are tons of examples and use cases if we open some play or app store and search for tracker. Native apps are already doing it. The same applies for privacy. In the context of today's Web, a PWA should strive to be no different than a native app in regards of basic device functionality.

The Wake Lock API is a step forward and is supported in Chrome latest (mobile and desktop) after enabling the experimental-web-platform-features flag. However, only the screen lock works properly. The system lock — which would be required for any background geostuff — can be set, but is not honored, thus not functional.

[josephrocca]

As an end-user of this starlink satellite tracker, I would have liked the ability to only allow permission for a specific period of time, perhaps with UI like this:

Same for other permissions like webcam now that I think about it. I'm often just testing a demo, and it would be nice to not have to click the lock icon in the URL and remove permissions every time I'm finished.

Though I guess this is a browser feature rather than a web platform feature?

[tomayac]

Though I guess this is a browser feature rather than a web platform feature?

Correct, the permission prompt design and permission features like the time-boxing of permission grants is up to the user-agent.

[jeantil]

We are switching our strategy from PWA to native apps because support for background geofencing is not available (or any other means of detecting a country change).
Our company yupwego offers an insurance which optimizes prices and coverage level based on the coutry you are currently travelling in. We started with a web app hoping to be able to switch to PWA if this feature became available.
Unfortunately it isn't and we are getting requests for users to improve usability for our service:

• detect country changes without having to go back on the website to click a bouton,
• detect that they are back in their home country and automaticall stop the insurance service
  We haven't been able to find a way to do this with the current PWA capabilities.

I understand it is a hard problem especially with regards to users privacy and I cheer for the people who are still working on this.

[stefanloerwald]

how is background geolocation still not a thing? Native apps had that for ages... Browsers could simply ask for permission to "use geolocation services in the background", in the same way browsers already ask for the permission if it's in foreground. That dialog could even include a warning on privacy... It's dead simple and it prevents so many geolocation usecases.

Please lets get going with this. It's 2020 and I don't want to go back into native app development. What can members of the general public do to help accelerate this?

[fernap3]

@tomayac , is there any more current discussion on adding geofencing features to the web platform that you could point me to? I have some experience with this on iOS (as well as some personal and commercial interest) and may be willing to contribute.

[tomayac]

Your best bet at the moment is to add your use case description to https://crbug.com/898533.

[clshortfuse]

We track vehicles live. Think emergency vehicles, delivery, transport services, courier, etc. We sometimes refer to this as "asset tracking". When a driver arrives at a location, we would like the application to notify the driver. When a driver doesn't reach his location a remote dispatcher would like to query where the driver is.

Everything works 100% fine when the PWA is in the foreground. But the moment a driver decides to use a third-party navigation application (eg: Google Maps, Waze, Apple Maps), all geolocation services stop. On Android Chrome, we can still send audio at times, but if memory pressured, it's gone and the user has no idea.

I present this because we "cheat" with background audio support. Because PWAs essentially have two states in Android Chrome: "foreground" and "background". iOS is more like "Running" or "Paused". Nothing happens when iOS goes to the background. This seems like user agent quirks.

I don't see a strong use case, personally, for background tracking of geolocation with just a service worker. But a somewhat persistent state of a PWA could be useful. In this third state (background but persistent), I feel geolocation should be allowed. I feel like trying to just open any service worker to collect geolocation could invoke some battery and security concerns. Of course, a new permission dialog might be enough.

I'm not sure if my use case falls into this. Maybe it's a better distinction as to what "background" means. I know JavaScript will continue to run while the window loses focus.

[jakearchibald]

That feature is https://github.com/w3c/system-wake-lock fwiw

[James-E-A]

Is there any plan to provide this API without requiring providing user location to e.g. Google?

For instance, my use-case is a bike ride tracking app that can stay open in the background, but both I and my users would prefer that Google not harvest their location when no Google app is open. Is the new "geolocation" API going to rely on aggregation services to collect the location data while PWAs are backgrounded?

---

I feel like trying to just open any service worker to collect geolocation could invoke some battery and security concerns.

@clshortfuse Do you think that offering the same paradigm to service workers (*or maybe shared workers) that apps such as Google Maps and Waze currently use would be a good path forward? They can only initiate location access while foregrounded, and a very "loud" notification is in the tray the entire duration of access:

The access can only be initiated while in the foreground (and after the user has explicitly granted access), can be terminated by the user by closing the (extremely obvious) persistent notification, and cannot be resumed from the background if terminated by the user or relinquished by the app. This is the model of perfection for background location access, IMO. There are absolutely no surprises as regards either privacy or battery usage here — not even arguable ones — unlike with the geofencing API and any of the other solutions currently being tossed around for this. Does anybody disagree?

[dlilga]

Are there any implementers assigned to this project, or is this an ad-hoc volunteer situation?
Perhaps we need to start a GoFundMe page to motivate someone to volunteer!

[reillyeon]

As discussed before consumer-focused browser implementations are unlikely to support this feature due to the risk of abuse. The use cases above all seem like enterprise scenarios. The best bet for encouraging implementation interest is to reach out to enterprise-focused browser vendors or the enterprise customer departments of general-purpose browser vendors. If there is sufficient interest to justify investment in the new feature it may make progress.

This working group will happily facilitate standardization but only once there are implementers willing to engage with this feature.

[Bessonov]

The use cases above all seem like enterprise scenarios.

I am not sure why you guys ask for use cases at all? I mean the comment three messages before explains the situation quite well:

I think there are a good number of apps in the Apple App Store that might have been implemented as standalone web apps if background location tracking were available to web apps like they are to native apps. Without feature parity native apps will continue to reign.

Isn't it enough to learn from real-world use cases?

Anyway. I am no longer on the project, but one of the desired use cases was a safety function in a chat application similar to Uber's share ride, but for walking/bicycling/driving/any-movement.

Another app I recently installed is for finding my car where I left it.

due to the risk of abuse

Is there any explanation for that fear? We already have many sensitive APIs such as Notifications, Camera, Audio, and some of them run in the background. What's wrong with asking users for permissions? What's wrong with putting it behind user interaction? It's like saying that digitalization is insecure; let's write in stones 🤷

[hilburger]

We have developed a festival PWA working together with TYPO3 to get content and deal with different useful stuff on the festival site.
But the lack of background GPS tracking (after approval of course) to enhance over-all security on festivals is a pretty hard deal breaker.

[evancaldwell]

@reillyeon, from your perspective, is there something specific about implementing this for the web the is less secure or more prone to abuse than implementing for native. The thing I'm struggling to understand is why this feature has been available on native (with the potential for abuse accepted) for quite some time but is still and ongoing discussion for web.

The ultimate effect of this - at least in my opinion - is not that people will stop developing apps that "abuse" location tracking, they will just develop them on native platforms instead of using the web platform. Motivated bad actors will still build their abusive applications, they'll just do it on native. It seems to me that the majority of apps that are being prevented from seeing the light of day are legitimate, useful, beneficial ideas from people who don't have the time/ability to build across multiple platforms.

[reillyeon]

Native mobile platforms require apps to go through a review process which provides some mitigation against abuse. The web does not.

[clshortfuse]

Native mobile platforms require apps to go through a review process which provides some mitigation against abuse

Can you articulate what you believe is "abuse" since native applications do not need to be reviewed to land on either iPhone (via enterprise) or Android.

[fabyeah]

@reillyeon how can it be abuse if the user agrees to and is aware that their location is being tracked in the background?

Maybe you're referring to how the data can be used. But that's a question for every native app that does it, too. And app reviewers also don't have any insight into what happens with data once it's sent to some server.

[jlfy738]

Hello.
Very happy to see this topic!

We have a French hiking website (https://www.altituderando.com) that offers route descriptions with an interactive map, GPS tracking, and geolocation. This site has been around since 2006. Two and a half years ago, we transformed it into a PWA, adding mobile-specific features such as downloading routes and maps for offline use, on-site consultation, and with geolocation functions, compass, altimeter.

Why did we make it a PWA? Offering a native app would have required too much time (starting from scratch) and money (hiring developers), which we didn't have. It would also have been a waste of energy to redo and maintain something that already works everywhere, thanks to the capabilities of the web... When we chose the PWA, we were not aware of these "foreground", "background" aspects. But even in hindsight, the choice was good, because we are a very small company and it allowed us to progress a lot so far. We evolve a single codebase, continuously improving on all platforms!

Many of our users ask us to be able to record their route while hiking, or to have statistics upon returning from the hike (number of kilometers traveled, positive elevation gain, average speed, etc.). Most of our competitors do this (AllTrails, Komoot, Openrunner, IgnRando, Strava, Adidas running, ...).

The fact that geolocation does not work in the background prevents us from doing this. So we wait while developing other features, hoping that the web will have evolved by then, allowing us to truly compete with native apps in this area.

Furthermore, GPS on mobile web is quite complicated for the general public. We have a lot of exchanges with our users and have been led to write a long article explaining how to activate GPS, unblock permissions, tips for GPS to be "accurate", on Android, on iPhone, on Chrome, Firefox, Safari...

On competing native apps, we sometimes see an alert "power-saving mode is activated and may affect your GPS and background operation, or accuracy". On the web, it is impossible to detect this kind of thing.

There are also differences in the implementation of the Geolocation API "watch" between Chrome and Firefox. In case of failure, Firefox tries again regularly and Chrome does not, which requires reloading the page. I hope the new specification will help limit implementation differences.

Otherwise, it works great! and many of our users are very happy. But the competition is tough, and the lack of GPS function in the background is blocking the development of a whole range of features.

[phil-w]

I have two current non-evil use-cases:

1. An event-driven road-based sales person who needs to report on which of a set of possible locations they visited at the end of each week. The current approach is error prone, as sales-folk can't in practice maintain accurate logs on the road. Just need to pull their location trace and correlate against financial sales data. The data would not be shared with anyone other than them, although they would use it to generate their own sales reports for customers. Easy and a dramatic benefit, if it would only run in the background.

2. Tracking workers who visit residential locations. Current system is paper based, in the process of converting to tablets for logging. Background location would allow us to "nudge" the user should they forget to log a visit, and would allow (with user's express approval) automatic logging of visits, removing the need for the user to remember to log their activity completely in most cases. The workers are generally obliged to be able to demonstrate (not to us) which locations they were in and when. Could also of course be done with a web app plus a couple of associated/ integrated Google/ Apple apps with the precise same privacy issues.

We too are a small company. The limitation which created this thread helps the big companies and makes it harder for us.

The idea that Apple and Google, both of whom are regularly in court for both privacy and market manipulation reasons, should have any say over who can and who can't have users who want to track their own locations... is laughably absurd.

[vsychov]

I'm a software engineer who's also pursuing a pilot's license. The process of taking off and landing a plane involves numerous actions in a short timeframe, especially during touch-and-go maneuvers, which are quite common during training. One of these actions is recording the takeoff and landing times to maintain a flight log according to regulatory requirements.

I intended to develop a PWA to simplify this task. However, due to the absence of background geolocation, I'm left with just two options: using a wake lock or creating a native app. Both choices have drawbacks. Developing a native app requires more effort, especially for cross-platform support. Meanwhile, using a wake lock keeps the screen constantly on, draining the battery, which isn't good.

Distributing a PWA among flight instructors could be beneficial, allowing them to use the app with other students.

While investigating the reasons for the lack of background geolocation, I encountered this issue. It would be great to have this feature and allow browser users to decide for themselves whether to enable background geolocation or not (perhaps even with some ominous warnings about potential device tracking). In my opinion, any concerns about potential misuse are merely attempts to hinder the advancement of PWA technology, nothing more.

[anssiko]

Thank you for your continued use case contributions, everyone! I see many innovative use cases here. Background geolocation is wanted on hiking trails and even on the flight deck, to note a few. I will make sure your contributions will be on the agenda when we discuss new features with browser implementers.

To ensure your contributions are well received, please remember to keep the tone professional and focus on describing the use case and possible technical considerations you have. If you are in a position to share your affiliation and/or product it is useful information. Use cases from individual contributors and small companies are equally valuable contributions and appreciated. The web is for everyone and particularly important for the long tail.

[hilburger]

Thank you for your continued use case contributions, everyone! I see many innovative use cases here. Background geolocation is wanted on hiking trails and even on the flight deck, to note a few. I will make sure your contributions will be on the agenda when we discuss new features with browser implementers.

To ensure your contributions are well received, please remember to keep the tone professional and focus on describing the use case and possible technical considerations you have. If you are in a position to share your affiliation and/or product it is useful information. Use cases from individual contributors and small companies are equally valuable contributions and appreciated. The web is for everyone and particularly important for the long tail.

Thank you for your motivating words :)

I can add some information the case I have roughly described, too:

On events with a higher number of visitors we can get a massive improvement of security by offering the option of background tracking.
That means that security and organization staff is able to track "mass" movements easily and react to potential problems extremely fast by connecting the annonymous GPS-data to crowd tracking software.

Hope this helps to get a features needed for secure and well organized events!

[jzijp]

Great to see some activity here! It's already been 10 years since the idea of implementing background geolocation for the web was proposed. It seems to me that a large number of use cases have already been described, and there is a strong demand from developers and users. Honestly, I no longer believe it will happen. I am a small web application developer, and like many other small businesses here, I don't have the resources to develop and maintain native apps for all platforms. It's costly in time, money, and energy. The web is ideal. There have been enormous advancements in features over the past few years, but background geolocation is still a significant gap for me, and it prevents me from competing with larger organizations. My use cases? Primarily recording sports activities. User safety is important, but justifying the non-implementation of this feature is incomprehensible to me. There are multiple solutions: user authorization via notification, time limitation (e.g., 3 hours), manual unlocking in settings, adding a mandatory shortcut on the home screen. I wrote earlier that I don't believe it will happen. Why? Because it feels like some are working against the web, as seen in today's message https://lists.w3.org/Archives/Public/public-device-apis/2024May/0004.html. How is this possible? Halting the sensor-geolocation API because it provides nothing new compared to the current Geolocation API? Background capability, perhaps? I'm at a loss for words.

Best regards

[anssiko]

@jzijp thank you for sharing your use case! Please note the message you referred to does not reflect the views of the Working Group responsible for this deliverable. We are here for you, listening to you web developers, end users, your needs. We know the web is ideal for you and we keep advancing it, not regressing it.

We work with you in the open and your constructive contributions make it possible for us to serve your needs ❤️

[adamjimenez]

We operate a food delivery platform and use background tracking to monitor driver activity without excessive battery usage. Our stack is predominately web-based but is complicated by the fact that we need to use an app platform in order to access native API's for background tracking. This has added unneccesary costs and complexity to our codebase. There is so much the web platform can access from push messages to bluettoth but background tracking seems like a crucial oversight. User privacy is clearly the main concern but this can be solved using a combination of browser permissions and notifications.

[Lucho-git]

I operate a Farming vehicle tracking service, which uploads the operators vehicles location and trail path as they move around the paddock. This coordinates all of the farmers and allows them to see the overall picture of everyone who's working.

It's very frustrating that the location can't be set to update in the background while it's moving around the paddock. I build the entire thing as a PWA without realising this and might need to move to a dedicated app which I don't have time to implement on both IOS and Android as the sole developer.

[sedubois]

We had the case of a client who wanted to build an app where users could track their movement while using a hot air balloon. This data would be gathered so that they get a history of all their flights and can optionally compare this with other balloons in the area. The location data to be collected would be not only the latitude and longitude but ideally also the accuracy, altitude, heading and speed (to the extent that these are available from the device sensors). After building a PWA proof of concept, we were forced to conclude that this would require building a native app, as such data could be obtained through the navigator.geolocation API but only while the web page is in the foreground, and we cannot expect users of the balloons to constantly keep their app open and visible on screen in order to ensure that their movement gets tracked reliably throughout their flight.

What would be needed on the web from a user's point of view is what native apps allow: initially ask the user for the permission to collect and process their location data both while the app is in foreground and in the background, then let the user remove this permission at any time through some system setting.

[paulo-assoc]

If an installed PWA can be trusted to access the navigator.geolocation API while the app is in the foreground, then why not in the background or under lock? Of course, in the same manner as a native app, the browser would ask the user for permission when the PWA is run the first time (or every time if the 3rd option below was chosen):

Location access for this web app:
o Allow all the time
o Allow only while using the app
o Ask every time
o Deny

[James-E-A]

I do want to re-emphasize how disturbing it is that "geofencing" (using an always-online background service to persistently record the user's location in case some apps might have registered triggers) is being considered somehow less of a privacy risk than simply allowing PWAs to extend an interactively-initiated geolocation consent session with the same UX as they can already use for extending other interactively-initiated backgroundable tasks such as audio playback.

[James-E-A]

If I start a location watch, then send the app to the background, I expect the app to keep watching my location until the App Is Watching Your Location notice disappears, at which point the consent is obviously revoked; this is the same model that every existing navigation app uses; it's an excellent model, and I've never seen any criticism against it.

As long as the app isn't allowed to start collecting location data in the background — if the user has to affirmatively open the app for it to even have the opportunity to open a location-watch session — then what exactly is the supposed privacy risk?

In particular, "geofencing" seems to be infinitely more risky, privacy-wise. If an app can get my consent once and then lurk in the background, unseen, with no notification, indefinitely waiting for Firefox/Google/Microsoft/systemd to notify it that I've left the city — which is a rather basic example of geofencing — that seems like *way* more of a concern than the natural use-case of "bike ride tracking app keeps running when I turn the screen off or check my texts".

[marknelissen]

Especially since geofencing itself can be used to simulate through multiple triggers or redefining the geofencing zone as a pseudo real-time tracker, duplicating actual position tracking and thus raising the same privacy concerns.

[clshortfuse]

Persistent access to device features while being in the backwards is one of the goals of System Wake Lock. The topic of some indicator (eg: Persistent Notification) is of discussion there as well.

I'm personally not interested in geofencing though can understand unprompted location access.

• Retail store noticing you entered an area
• Storm tracker notifying you of lightning strikes near your location
• Travel history logger (eg: Google Maps Timeline)

To note, all of this should be able to be done with some manual opt-in method. The interval at which applications poll the geolocation is already defined in spec. If an application can be hold a "wake" state, then it can react to the location updates.

As for automated tracking, without a manual, per usage opt-in, I'm personally not interested this. That would be something like a Service Worker that can listen for push notifications, but instead of pushed notifications, it's pushed locations. That would be the "sensible" way to do this, but I think at least tackling manual opt-in (eg: wake lock + notification) would happen well before an automated push of geolocation to some service/application.

I don't see much traction in Wake Lock, but maybe it seems that would be the first step to implementing the background, non user-initiated location requests.

TL;DR: Users should be able to manually start and stop background geolocation before it can be done automatically.

[scovillo]

As an outdoor enthusiast, I use a Progressive Web App to record my adventures over several days via GPS, so that I can recall them, revisit them, or even share them. During an adventure, my GPS is also permanently shared with selected people via the PWA, so that in the event of an emergency, these people know my location immediately.

To ensure that my battery lasts as long as possible and that I have my hands free for climbing or similar, the smartphone screen is locked for long periods of time and it is in my pocket, but the GPS recording must work reliably in this state. Losing the GPS recording in this state would be fatal and permanently activating the screen is not an option. To achieve this, I can permanently unlock my location in the PWA, preferably directly in the PWA's own settings, or at least in the operating system settings, which also means in the background.
When I have finished my adventure, I revoke the app's location permission, preferably directly in the PWA's own settings, or in the operating system settings.

Because I want to use the app on different devices without having to install any platform-specific software, the Progressive Web App is, for me as a person without technical knowledge, the best solution with the smallest technical hurdle.

Positive test case

• I permanently activate location sharing for an installed PWA in the settings
• I activate GPS tracking in the PWA
• I put the smartphone into the locked state
• I go for a 30-minute walk
• I unlock the smartphone and can view the recorded, unbroken route in the PWA
• I withdraw location sharing from the PWA in the settings
• Activating GPS tracking is not possible, I am asked for permission
• Ideally, I have the choice between "allowing during use" or "permanently"

Negative test case

• I activate location sharing for an installed PWA in the settings
• I activate GPS tracking in the PWA
• I start a walk with the active smartphone
• After 2 minutes, I lock the smartphone and continue my walk
• At the end, I unlock the smartphone and find that only the first 2 minutes were recorded and the rest of the route is missing since locking

[Lucho-git]

Actively losing customers, because taking a phone call disables their location tracking :(

[Bessonov]

Hi everyone, I see a lot of comments, use cases, and upvotes on the comments. Don’t forget to upvote the issue itself! 👍

[anssiko]

Thank you all for your continued use case contributions! For full transparency, I want to share what the Working Group discussed at its recent F2F: https://www.w3.org/2024/09/24-dap-minutes.html#t22

TL;DR: The group agreed to focus on background geolocation for this specification and not duplicate foreground geolocation functionality provided through the older Geolocation API. The group also acknowledged and thanked everyone for the professional use case contributions in this issue (>60 comments!).

Besides use case contributions, another mechanism to influence browser vendors' feature priorities was brought up:

Browser vendors use the State of HTML survey results as important input into their feature prioritization. As a web developer, you can help by heading over to https://stateofhtml.com/ and taking the survey. For this background geolocation feature specifically, in the "Native-like Web Apps" part of the survey there's a "What are your biggest pain points around making web apps that feel native?" section where you can voice your support for this feature. Thank you! 👍