+++ This bug was initially created as a clone of Bug #1216148 +++ I think we need to collect some telemetry data first to see the impact of this. See also https://bugs.chromium.org/p/chromium/issues/detail?id=506435 Two factor we should weigh in is 1) power consumption and 2) user privacy

(In reply to Kan-Ru Chen [:kanru] (UTC+8) from comment #0) > I think we need to collect some telemetry data first to see the impact of > this. We are. Look for GEOLOCATION_GETCURRENTPOSITION_VISIBLE and GEOLOCATION_WATCHPOSITION_VISIBLE.

Re: #c2 Can you please clarify what you are asking for? I interpret what you saying as you want a GeoLocation API that only works when the tab/app is visible. Is that correct? Foreground only and not background monitoring? Firefox is the *only* browser that behaves this way and Mozilla staff have simply refused to explain let alone justify their recalcitrance in being the stalkers' favourite browser. This unsanctioned invasion of privacy simply cannot be tolerated.

Richard, We are looking at disabling geolocation in background threads. As part of this investigation, we are collecting usage information. That is all.

(when I say threads, what I mean is windows or tabs that are not visible)

Sorry everyone for throwing this (related) message-in-a-bottle from this beach but, for reasons that currently escape me, I am blacklisted from the appropriate W3C Github repository(s). Just in case someone here's involved with Permissions: - "PermissionName granularity too coarse to cover environment/ambient variables" At this time I am specifically concerned with the upcoming background Geolocation capability. Do you have to look at all permissions and add attributes? Keep adding permissions "GeolocationBG"? I don't know, but I'd really appreciate some feed-back or existing thoughts on the matter. How do you propose to handle permissions in these scenarios? The consensus is that a user has a reasonable expectation that when an App (where they may have permitted location tracking) is backgrounded, or the phone is asleep, it will cease tracking. Counter this with the myriad of legitimate Apps that need approved-background location tracking and we are at an impasse. Here are the thoughts/requirements that I feel could assist in user authorization, acceptance and empowerment: - User-empowerment, transparency, and governance: - 1) User permission must be explicitly granted before GPS is accessible. 2) While GPS is being watched, even in background, the circles/ripples icon cue is visible to user on the device. 3) The underlying Service Worker architecture mandates the use of secure/authenticated httpS communication. 4) The user can be 100% sure tracking is off by simply closing the browser on their device. (Maybe not with Google Play, and MS Notification Center) 5) The manifest-resident gcm_sender_id (Google Project Id) can be revoked/voided if a site is behaving badly Other Options: - 1) Only permit background/service-worker GPS access if the Web App is installed/home-screened? 2) If a single GPS permission will cover both background and foreground access, then put a link on the permission-toast pointing to the Faustian details? 3) Use a new icon, perhaps an eye or a doughnutted version of the current GPS ripples? Pulse the icon? 4) When the device goes to sleep when a Web App is still watching GPS, or simply backgrounds or minimizes a device-tracker, it should make a sound and or vibrate as a non-visual cue that tracking is ongoing? 5) When a device is reawakened or a device-tracking app is brought back to the foreground, then a notification must be sent to the user "This App continued to monitor your location in the background". The "Settings" icon on the message could facilitate "Prevent this app from tracking in the background" Forever/Just once. 6) Like the Push API the default must be DO NOT track in the background. If the user chooses the individual APP settings then they can turn it on? GPS Tracking Use Cases: - 1) University security have just been told there's a shooter on campus. They touch the google maps screen and tell the system to warn everyone in a 2km radius to get out or get down. The geoFence has only just been created. Pushing the details to the client won't help you because the architects are currently considering banning creating a geofence around current position as it facilitates quasi-tracking. What's more is the time, bandwidth, CPU, and baterry-power wasted pushing a geofence to ALL users when most of them are not effected by or resident in the danger zone. 2) I want to track my jogging and bike-riding journeys to share with friends and manage calories-burned and effort. "Health & Fitness" market? Ignore it? 3) I want to know when members of my coffee club are getting close so I can start ordering. 4) Let me know if bad weather is moving in. 5) The library is closing. The librarian sends a push message to anyone in the building (who hopefully have their notifications on vibrate :-) giving clients 15mins to finish up. 6) The next 10 customers to the Guild Tavern get a free beer. No use having permanent geofences around every retail establishment that may want to communicate with customers. 7) How about a trucking or taxi company wants a central head office PC constantly tracking fleet movements in real-time. 8) Pizza Co. want to let users see where their pizza van is. The van driver doesn't have to have his phone screen on killing his battery .

Please fix this. There's no reason to keep GPS active (especially on mobile where it drains A LOT of battery) when the app is in background. With Chrome for Android as soon as I go back to the Android home screen the GPS icon disappears.

Sorry guys, but this is not a bug, it's a feature. So, do you want to ban from stores native apps like tomtom, uber or glympse because they read gps position even when they are in background? The user gives the permission to web app to read GPS, the icon is clearly showing the GPS icon activity, if that is not ok , just close the broswer tab (or the native app)... end of the problem. Maybe there could be a notification after a certain limit of using the service, but let's not kill the feature completely. I don't think a read each minute is draining the battery so much, also if the read is actually getting cached values recently read by other applications there is no drain at all. Do you guys know that many smartphones send quite frequent periodic gps info to the anti theft or location history service ? And no gps icon is showing, nor many users are aware of it. Where do you think info come to provide services like trafic, location history or mall popular times? I hope this issue will be well pondered before a decision.

(In reply to Richard Maher from comment #7) > For the record the behaviour is not the same on iOS. There, unless Firefox > is in the foreground, the watchPosition ceases to report. Marvelous :-( > > How soon can we expect Ban Ki Moon, Butrus Butrus, and Kofi to come up with > a course of action? Yes, because browsers on ios are basicallly just wrappers around safari, they are forced to use the ios web engine. So firefox ios has just the firefox UI, but inside is safari. It is a restriction imposed by Apple , they say that's to protect users security and battery but probably they also want to protect their native app store, an important sources of revenue. In the past those who applied too many restrictions and control over their platform were disrupted by those who were more open to developers and 3rd parties. Microsoft distrupted the PCs, Linux the servers, Android the smartphones and now who will distrupt the native mobile apps and stores? Thats a huge opportunity open considering mobile has a growing number of users never seen before.

@antonio If you read the original bug you'll find that I and most of the world are desperate for background geolocation for web-apps but it needs to be done properly which includes overtly. This is why Mozilla is alone in providing this "feature" that empowers stalkers, estranged husbands, and marketeers to snoop and track unwitting users. I have submitted a valid workable and battery friendly solution to the W3C and IETF forums that involves filterable geolocation movement events being sufficient to instantiate a service worker who, in turn, could wake of foreground the browser if need be. Unfortunately, W3C and IETF organizations, much like Mozilla, are stacked with people who are more interested with social issues and jobs-for-the-boys than they are in providing the essential functionality :-( So unless you're interested in land-rights for gay whales I suggest to stop wasting your time on technical advocacy here.

Hi Richard, I agree that reading location must be done properly to prevent abuses, however the risk of stalking with the current firefox is IMO very low, the stalker would have to: - convince the victim to install android firefox since most non tech people just use chrome or stock browser on android - convince the victim to visit the site - make sure that who is visiting the site is really the victim because the site is public and anyone could access it - convince the victim to grant explicit permission to access location then the victim can see the access to location icon flashing and as the page is closed or the phone rebooted the control on the victim is lost. It's unlikely all these things happen. What happens instead, unfortunately, is that some bad guys use native apps or vulnerabilities in the OS to gain permanent access to location or anything else done with the phone (messages and so on...) and all the tracking is hidden to the user. Sometime just stealing the email password is enough to access the anti theft or location history service. That's really dangerous and the news sadly is full of these cases, last one not long ago a boy killed his ex-GF because using the anti theft app he discovered she had a new relation amd with the same app he could wait for her walking in a dark isolated street and kill her. Crazy! Coming back to firefox and the other browsers too, I have not read your proposal, but it should not be difficult to grant background access safely. There are many ways actually. For example when getlocation request is called for the 1st time the browser could ask "Do you allow the site xyz.com want to access your location?" -> "Allow once" , "Allow permanently (WARNING the site could track you until you close the page)", "Do not allow". If you give the 1st answer the next request would still get same popup, if you allow permanently the site has free access to location until the page is closed, no matter foreground or background. If you do not allow the request fails. Another way could be to leave the permission request as it is (yes/no), then when the first request comes from background spawn a notification (like when you receive a whatsapp message) saying "the site xyz.com want to read your location permanently, click to go to the site for permission" until user click the notification and grant the permission from the site the location request would not be completed. Dimissing the notification popup or denying permission would be a permanent NO. My opinion anyway is this feature is gone come one way or another, if you watch this video https://www.youtube.com/watch?v=9Jef9IluQw0 it looks like the whole industry (maybe apple not so much) is serious about web apps, they will find the way to bring the native feature to web apps, a mentality shift is required, it takes some time. In the wile we developers must write what we need to relevant people in the forums, it's not a complete waste of time ;) btw how did you solve your problem? I'm still in the prototype stage and firefox is helping me a lot :) I hope I don't have to go native in the end. Take care and let me know how you proceed. You are doing some really interesting stuff, I'd be glad to keep in touch.

@antonio there are certainly many ways to mitigate the risks and inform users of what's happening the solution is available, but please be aware (and search monorail if you wish) that Google Chrome disable this exact same "feature" due to the risks. On the up side I believe that once Mozilla decides to do the right-thing and stop this bug then there will be more momentum for a secure/supportable background geolocation cross-browser. Having said that I'm more broken-hearted about FF dropping the Web-App install features not fully supporting the manifest standard and no longer supporting full-screen access for web-apps :-( "Progressive Web Apps" is just the latest bollocks nom de guerre of those more interested in caching and offline-first then they are in having Web-Apps truly compete with native apps. I try not to watch their evangelical videos as the clicks only encourage them. Likewise, I avoid the twitter-feeds and blogg-pages of these social-warriors as it makes their ignorant bosses think their doing a good job :-( Honestly, it's like an episode from Dark Mirror where those with enough social-media votes are listened to and those who don't agree are "blocked". (See my banning from W3C GitHub forums and IETF mailing lists.) As the Sam-Wow guy would say background geolocation "Sells itself" but Mozilla is an organization in decline and becoming less technically relevant by the day, Chrome is following the agenda of its own numpties, Opera just does what Chrome does, Safari is only beginning to look at Service Workers and I have to have a real job unlike these pretentious knobs who get to fly around the world for F2F time sucha as Lisbon and Sapporo. I wish you well but I'm not banging my head against the wall any more. The game is rigged.

(In reply to Richard Maher from comment #14) > @antonio there are certainly many ways to mitigate the risks and inform > users of what's happening the solution is available, but please be aware > (and search monorail if you wish) that Google Chrome disable this exact same > "feature" due to the risks. On the up side I believe that once Mozilla > decides to do the right-thing and stop this bug then there will be more > momentum for a secure/supportable background geolocation cross-browser. > > Having said that I'm more broken-hearted about FF dropping the Web-App > install features not fully supporting the manifest standard and no longer > supporting full-screen access for web-apps :-( > > "Progressive Web Apps" is just the latest bollocks nom de guerre of those > more interested in caching and offline-first then they are in having > Web-Apps truly compete with native apps. I try not to watch their > evangelical videos as the clicks only encourage them. Likewise, I avoid the > twitter-feeds and blogg-pages of these social-warriors as it makes their > ignorant bosses think their doing a good job :-( > > Honestly, it's like an episode from Dark Mirror where those with enough > social-media votes are listened to and those who don't agree are "blocked". > (See my banning from W3C GitHub forums and IETF mailing lists.) > > As the Sam-Wow guy would say background geolocation "Sells itself" but > Mozilla is an organization in decline and becoming less technically relevant > by the day, Chrome is following the agenda of its own numpties, Opera just > does what Chrome does, Safari is only beginning to look at Service Workers > and I have to have a real job unlike these pretentious knobs who get to fly > around the world for F2F time sucha as Lisbon and Sapporo. > > I wish you well but I'm not banging my head against the wall any more. The > game is rigged. The only reason you will be blocked from this bug is for not following our participation guidelines (https://www.mozilla.org/en-US/about/governance/policies/participation/) and keeping this bug strictly to the discussion of the fix itself. Bugzilla is not for lobbying or carrying out your personal grudge against those you perceive wronged you.

I wonder if watchPosition() could fit in here: - https://w3c.github.io/ServiceWorker/#extensibility

Please see https://drive.google.com/open?id=0B7Rmd3Rn8_hDNW1zSWRoXzBTclU for what is arguably the way forward with Geolocation and Web Apps. There is a aaa_readme.txt.