Background Geolocation

[UVLabs]

Is this still not possible yet? Am I not understanding something? I've went through a rabbit hole and bunch of stackoverflow posts with so many web developers asking for this but what seems to be the issue here?

In one of the many posts i scrubbed through it mentioned about stating usecases, there have been so manyyyy usecases mentioned and referencing this repo so my usecase is just a drop in the water.

---

It's simple, I'm building an order management webapp where store owners can attach orders to drivers.

When the driver starts the delivery (by clicking "start" for example), the navigator.geolocation api will start watching the position of the driver along with other logic to store that location info so that the customer will be able to see it on their end; the customer will get an SMS letting them know that the order has began, along with a special link to track the driver's location (this would simply be some logic that queries a database at an interval to get the drivers last saved location and plot it on the map).

BUT as the driver is delivering the order, their phone might go in sleep mode (screen turn off), or they might get off the browser to make a call or something. During this process, the customer would not be able to know the driver's location because they're no longer on the website.

What this means is a driver who is 30 minutes away might start the delivery process, and within 10 minutes switch apps and then forget to go back to the browser, so while they're walking up to the customer's door, the customer might still think that they're 20 minutes away...

Simple right? This is something done by so many native delivery apps but in 2022 why do we still have to create a native app just for this one thing??

What is the difference between the browser letting the driver know that it will be tracking his location in background, versus the driver installing a native app that lets him know it will be tracking his location in the background?

They both aim to do the same thing, but why is this not possible from the web?

Please let me know if this is now possible, or if there's some other web solution I should be looking into for this functionality (background geolocation)

[reillyeon]

The sticking point is that background geolocation access changes a really fundamental property about how users think about privacy on the web. Today, when you close a tab (or switch to another app on mobile) a site can't keep running in the background indefinitely collecting information about you (like your location).

When building APIs for native apps, platforms can depend on a store review process to catch malicious apps. When designing for the web we have to be a lot more cautious about how APIs are designed to keep the user in control because anybody can create a website and we know there are a lot of malicious actors out there. Some kind of notification like you suggest might be part of a solution.

Given the potential privacy harms this isn't something the Working Group is currently putting effort into specifying.

[Tom333Trinity]

@UVLabs please see my Brotkrumen PWA at https://richardmaher.github.io/Brotkrumen/TravelManager.html

Problems: - 1) There's some CSS issue(s) on Safari. If someone can teel me why that's great otherwise use Android 2) Not all browsers on Android support Wake Lock which is needed 'cos Backgroud Geolocation is Vorbotten 3) You need to have your own Google Maps API key as they frown on publishing mine

Having said that, it works like a charm (as long as you move about a bit) and the code can be found here

All the Browser/UA has to implement is the TravelManagerPolyfill and we're done!

@reillyeon you are wrong again :-(

The Browser/UA is ALWAYS in control of the geolocation change events! It can throttle them, hide them, make sure user visibility is appropriate, in fact do anything and EVERY iOS and Android implementations trust there browsers.

But sadly, no one will ask a techichnical questions or challenge the TravelManager design and instead just spread FUD :-(

Apart from user visibility and approval it's good to go! Why not?

[UVLabs]

I really don't know why this

The sticking point is that background geolocation access changes a really fundamental property about how users think about privacy on the web. Today, when you close a tab (or switch to another app on mobile) a site can't keep running in the background indefinitely collecting information about you (like your location).

When building APIs for native apps, platforms can depend on a store review process to catch malicious apps. When designing for the web we have to be a lot more cautious about how APIs are designed to keep the user in control because anybody can create a website and we know there are a lot of malicious actors out there. Some kind of notification like you suggest might be part of a solution.

Given the potential privacy harms this isn't something the Working Group is currently putting effort into specifying.

Thanks for the reply, the reasoning you gave raises a lot of possible other questions and can be debunked but I guess the main point is you guys are withholding this functionality in the name of privacy...

[clshortfuse]

I've been writing fleet management/asset tracking applications for mobile since about 2010. We moved from Android to PWA about 7 years ago. I've somewhat resigned to not having the ability to track while the application isn't in the foreground. Once a driver moves to an external turn-by-turn navigator, we can still get some background going (text-to-speech, EventSource, and Audio playback), but not geolocation.

That said, it's disappointing there still isn't a consensus for legitimate usage of background geolocation.

@Tom333Trinity I've been using Wakelock to keep screen on. Are you saying we can keep background location too? I haven't seen it been possible, but I last tried a year or two ago. Last thing I was trying was keeping a Picture-In-Picture to keep the application "alive" and semi "onscreen" while they are on the Google Maps/Waze navigator.

[Tom333Trinity]

@clshortfuse No, sadly, background geolocation tracking is still not available on the Web.

What I am saying is that there are no insurmountable obstacles to it being introduced. I am also saying that the TravelManager stategy demonstrated by the https://richardmaher.github.io/Brotkrumen/TravelManager.html PWA proves this.

The UA is resposible for delivering appropriate Travel Events to the Service Worker for the subscribed page. I think it's about 7 years since I proposed this solution and to date no one has been able to fault it. All it needs is an appropriate permissions strategy.

[marcoscaceres]

you [folks] are withholding this functionality in the name of privacy...

I think this needs to be flipped: how can this be done without putting user's privacy at risk? It may not be possible to support this kind of functionality for regular browser tab style applications, but it may be possible to do something if the web application is "installed".

There's some precedence nowadays for APIs that are exclusively exposed if and only if an application is installed (e.g., badging API, some push implementations). I'm not proposing that this is feasible or will be acceptable to various privacy and security teams, but just that we need to consider alternatives.

At the same time, I would ask that folks don't propose solutions here (unless you are willing to sign Intellectual Property Rights commitments). If anything is going to happen it will likely happen through the WICG's incubation process.

See contributing new proposals.

[marcoscaceres]

(I move we close this as out of scope... again)

[reillyeon]

I agree, closing this as out of scope.

I want to recognize that there is a clear developer need here. The challenge, as Macros highlights, is proving that this can be done on the web without significant user harm. Making progress here requires buy-in from browser implementations who will be the ones implementing. So far it does not seem like any of them are willing to take the risk on this feature.

If you want to make a proposal I recommend following the WICG process. Background geolocation will likely require a separate API or at least significant modifications to this one so starting with a clean proposal is better.