search

w3c / geolocation-sensor

Geolocation Sensor
https://www.w3.org/TR/geolocation-sensor/
Other
59 stars 21 forks source link

Support geolocation (especially geofencing) in the "background" #22

Open kenchris opened 6 years ago

kenchris commented 6 years ago

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

https://github.com/WICG/background-fetch/issues/82

jakearchibald commented 6 years ago

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 commented 5 years ago

Collected some use cases in https://github.com/w3c/geolocation-sensor/issues/17 (should probably consolidate the two issues).

tomayac commented 5 years ago

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

jakearchibald commented 5 years ago

"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 commented 5 years ago

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

anssiko commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

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

anssiko commented 5 years ago

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

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 commented 5 years ago

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 commented 4 years ago

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:

image (1)

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 commented 4 years ago

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 commented 4 years ago

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:

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

clshortfuse commented 3 years ago

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 commented 3 years ago

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

JamesTheAwesomeDude commented 3 years ago

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:

Screenshot_20210611-204327

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?

timbtimbtimb commented 1 year ago

Here is my usecase for what it's worth: a mountaineering app which keeps track of your movements even while the phone is locked, which can actually be life saving on a glacier with no visibility. Why isn't this an obvious feature? Surely privacy isn't a concern provided the user is made aware of the background location data gathering.

orpic commented 11 months ago

use case - In a driver app for a taxi provider, I navigate the driver to google maps to go to the pickup location, during that time I also need to show the current driver location to the user, I need to update it in the background since the focus of the driver app is gone the moment he opens google maps for navigation

CarelessCourage commented 10 months ago

So, I've run into a bunch of situations where this would have been really helpful - in real-life projects of all sorts, some of which unfortunately hit a dead end due to this particular problem. Personally, it's pretty obvious to me that this feature is genuinely valuable. But I've been pondering over ways to make it safer.

I believe that the worst scenario for this is if malicious actors use this opportunity to sneak geotracking onto someone's device in order to stalk or harass a vulnerable person. This could come at the cost of a person's belongings in the case of thieves looking for opportunities but especially this would be a dangerous attack vector towards women who often have to deal with highly motivated bad actors looking to take advantage. Even if used just to stalk from a distance I empathize with the severe breach of personal privacy/security that this could pose for certain members of our society. Beyond battery life or any other concern this is the biggest issue I see and this is the nr1 scenario I would want to prevent.

Since users need to give the green light for tracking, and beefing up security beyond that sounds quite technically complex its easy to think that theres no real way to make this safe. Well, unless we dive into the realm of sci-fi and start talking about devices that can read minds to verify if a user's consent is legit – though, let's be real, that's not very realistic.

So, here's the point I'm getting at: I really believe that the crux of this matter is helping users make informed choices and have control. I think the solutions to this are fundementally UX based

Imagine this: What if users could only give the thumbs up to three websites to track their location simultaneously? And on top of that, what if the browser had a clear, unmistakable indicator in their UI saying "tracking is active," along with a count of how many out of those three sites are currently doing tracking, for how long, and date when tracking is set to be disabled again. Envision a button or indicator in the browser that, when clicked, reveals the identities of those three trackers and lets the user turn one off.

And in a situation where another site wants permission to track, a pop-up would ask the user to choose which of the existing three trackers to deactivate – this way, tracking can be limited, and users can stay fully aware of their past choices that they might have forgotten otherwise. Maybe we could even say that only 1 app is allowed to track you at a time, and by default only for 6 hours before needing permission again. Maybe the only way to increase these limits is to go into the settings to do so, which would filter out most tech naive users and guarantee that only people who really want to be tracked get tracked.

This approach ensures that users are consistently reminded and prompted to think about the websites monitoring their activities, including how long the tracking lasts. Honestly, I'm quite confident that the complexity of this issue becomes less daunting when we shift our focus from technical complexities to the realm of user experience, where practical solutions exist to empower users with control and clarity over their decisions.

I belive that investing in a browsers UX solutions to these problems would give the users enough clarity and power over their tracking to keep them reasonably safe. Altough it should also be acknowledged that no solution can ever be 100% safe and bad actors will always find some way to do something bad at some point somehow. I belive the UX solutions I have described would be good enough in reducting the harm to within a reasonable limit however. Keeping people safe is a big concern of mine but moving the web forward is also something I think will improve and maybe even save lifes in its own ways in the future (geotracing medical emergency apps, parent saftey, traveling companions, etc)

In comparison battery life I think is not a big issue, because the lack of battery life in a device serves in itself as a notification to turn off tracking. So I believe that it's almost a self correcting issue with very low consequences even if implemented poorly. It would help to have clear notifications recommending to turn off tracking when battery turns low - but I suspect that if battery life starts to get poorly affected the broader community would almost by themselves start to spread the knowledge of turning off tracking to save battery the same way we always adapt to these changes over time. To an extent that's how most things go, you just have to allow the consequences to happen so that we can evolve new types of behavior to form in response in order to counter it. From that perspective delaying these features only prolonges the time it will take for solutions to form.

anssiko commented 10 months ago

@CarelessCourage thank you for these UX ideas on how to approach this problem space.

We plan to discuss this issue at our upcoming F2F meeting to check the pulse on where we're at. To set the expectations: this is not an easy problem to solve (as you rightly acknowledged) and further UX work and buy-in from browser vendors is needed to lift this stone. I feel your UX proposals are innovative so I'll bring them to the WG's attention for further ideation.

You many be interested in the proceedings of the W3C workshop where we got together to explore this broader problem space around permissions, including various UX challenges. In particular, you may want to check out the summary report we published. An excerpt from the executive summary:

There was agreement that getting the UX of permission flows right is a core aspect of making capabilities work well, especially as more capabilities get used in web apps and on a larger variety of interconnected devices. There was a desire to incorporate discussions and considerations around UX into standardization work, for example by building a forum in which to seek UX consensus among implementers and the community.

You can consider this GH repo to be one such forum where to discuss UX ideas. We'll bring them to the attention of the right folks. Thank you for your contributions.

tomayac commented 10 months ago

A while ago I have experimented with the idea of combining a wake lock with background geolocation tracking and documented my findings in a blog post. I bring this up again now since I discussed the existing UI indicators on mobile that the browser could hook into.

mfulton26 commented 10 months ago

I've been following this issue and past ones for some time now and I want to share my gratitude. This is a challenging space. An app I work on regularly for my employer is a hybrid app mainly because we need background tracking (location sharing at times and fencing throughout the user's workday). Figuring out and enabling background location tracking features in browsers will be, in my opinion, a huge step forward for standalone web apps. There are other things but I feel like background location tracking is the biggest one that prevents my group and others from going all in on web with no native mobile apps for most of our solutions.

CarelessCourage commented 10 months ago

@anssiko Thank you for your response. Im happy to see that there is continued discussion on this and to hear that you would like to carry some of my suggestions onwards. I fully appreciate that this must be a very hard problem and I cant even imagine the immense pressure to get it right. Both the pressure from all the devs who want it and the pressure from how getting it wrong might cause harm. I don't envy the position of having to actually figure all of this out and be responsible for the consequences. I would also like to show my gratitude for the incredible work that goes into maintaining browsers and the broader community. Much love from Norway

clshortfuse commented 10 months ago

I had a use case listed before, but I just recently was asked to write a tracker for an airport shuttle and I'm delivering today, coincidentally. The concerns of privacy are basically none since it will eventually be given free to the public.

All the mechanics of how it works are built and functional though requires the shuttle driver to constantly keep the device awake with the screen on. And I've had to stress not to get OLED devices.

I'm pretty sure all user agents interested in implementing this API already have mechanics in their platform to high visibility notifications. I know because I used to write GPS tracking systems in native Android and iOS 9 years ago. And before that, we used custom HAM radio equipment. It's all Web Apps now.

When we do WebRTC, I know iOS gives (maybe not anymore) a pretty high visibility of a microphone in use, changing the status bar completely red. I think they use blue for geolocation. Android does persistent notifications that can't be hidden.

Also, Safari does restrict certain APIs to Added to Home Screen (PWA). They do this for Push Notifications. I don't mind if we need to jump through hoops to get background geolocation. This eliminates the ability of random, unrecognized sites being able to just track users. Still, levels of restrictions are something that can be tweaked later. I think iOS 17 is now better equipped to separate permissions on a per-app basis instead of just assigning all Home Screen Apps the same permissions as Safari.

dlilga commented 7 months ago

This feature has been in the works for 8 years with no implementation. In this day and age there are dozens of apps that provide geo location services without issues of privacy (or at least reconciled the issues). It doesn't seem like the web developers of geo positioning should be so weak-kneed about implementing this at this time.

evancaldwell commented 3 months ago

Just going to throw my hat in the ring here. My use case is very similar to others already mentioned. A client wants to know general location of a service person on their way to complete a service. It doesn't make sense to expect a developer of an application to duplicate popular mapping applications just so that the users position can be tracked - I'm not going to do as good a job as Google, Apple, Mapbox, etc. There are existing precedents on native for this that have been around for years. After reading this and several other discussions on this topic I'm still not convinced that there is a good reason not to follow what's already being done elsewhere. Is there a way to get this moving forward?

anssiko commented 3 months ago

Thanks for your feedback folks and sorry I forgot to follow up on this. My bad.

As I promised, this was discussed at our F2F meeting: https://www.w3.org/2023/09/14-dap-minutes.html#t16

We discussed and reviewed all the use cases shared in this issue to date and a fair summary of this discussion would be, quoting @reillyeon: "we are bound by implementers moving together with this".

I know it is frustrating to hear the same message, but if you are in a position to spend a few minutes to contribute your concrete use cases here in this issue, and if possible, share your affiliation and/or product, that would help raise the priority of this feature for implementers. In particular it is useful to know if the lack of this feature (and just this) forced you or your company to develop a native app instead of a web app.

Thank you for your contributions. Let's keep the flag flying.

leonelvsc commented 3 months ago

Hi, we're finishing our PWA ERP and the logistics module has location tracking for assets/shippings and so on... It would be amazing if this moves forward because every employee needs the app to handle the shipment. Without this we've to implement gps sensors that sends mqtt messages attached to vehicles like trucks.

jlannoy commented 3 months ago

We have developed a fleet management app and a non emergency medical transport management app. In both case, we wanted to provide geo location of vehicles. For the second one, it would allow to send the nearest vehicle to the patient. Even if we are working for non emergency services, it would help. For now, we are getting the GPS position when a driver is in the app. The driver has to tell when he arrives or departs from its different way points. But then the driver launches a navigation app like Waze or Plans or whatever, directly from our PWA ; and we cannot get anymore the GPS position. That means we can show on a map the "position of the last known status", but not the real life position of the vehicle. It's not economically nor ecologically efficient for our transports managers (customers) nor for the patients waiting a transport, when they are last minute changed in current day's transports.

As we are a very small company, working also for small (business size) customers, we can't handle a native dedicated development + customers migration at this time. Some customers are using a GPS physical box in their vehicle to compensate, others are... doing whatever they can. We have even thought about setting up a parallel Traccar server, but it would be quite complicated to explain to some driver to set up an other app other than our PWA.

kavdev commented 3 months ago

We're also building an ERP in the services/trades vertical that requires geolocation functionality to show where techs/trucks are and geofencing functionality to prompt them to take certain actions before starting/leaving a job. This lack of support blocks us from building the functionality we want directly into our PWA.

Currently we have two options:

  1. We could go with something like capacitor to quickly spin up "native" apps, but having to go through the app stores for a single feature is a major pain.
  2. Like others have mentioned, we have the option of requiring customers purchase and use dedicated GPS hardware in their trucks so that we can grab the position data on our backend via something like terminal, but that sucks for the SMBs we want to support.
evancaldwell commented 3 months ago

My team is nearly complete with three apps (client, technician, and admin) that connects clients directly with technicians and gives admins visibility to both. A key feature for both the client and the admin is tracking the technician on his/her route. We cannot go without this feature so it looks like we'll be forced to shift to building natives apps for the client and technician.

Again I'll emphasize my perspective that there are no new privacy or UX concerns with enabling this feature for web that haven't already been addressed and accepted on native. Since there are no technical barriers, I would think ~6 years is enough time to make a decision on this.

mfulton26 commented 3 months ago

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.

An app I currently work on for my day job tracks deliveries and technician location for driving customer experiences and for identify "at-risk" jobs due to where a technician is (or, more importantly, isn't) physically. Most of the app is a web app but we're tied to still publishing a native app solely for background location tracking and geofencing (we used to be limited by no push notifications on iOS—which could have been implemented instead with SMS—and before that it was camera limitations but now the only limiter is background location tracking).

dlilga commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

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 commented 3 months ago

@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 commented 3 months ago

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

clshortfuse commented 3 months ago

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 commented 3 months ago

@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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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