Don't require GPS being turned ON when scanning for Wifi or Bluetooth devices [169936948]

WAI

Feature Request

[AOSP] assigned

Status Update

No update yet.

Description

p....@centrum.cz

created issue #1

Oct 2, 2020 07:34PM

As both #37060483 (wrongly resolved as "fixed" because nothing has changed) and a reopening request #37132338 (closed as "Obsolete", possibly due to inactivity) are closed, I'm opening another fresh one with a brief summary of what is wrong with the current behavior:

Apart from a bad design, requiring GPS just doesn't make sense when scanning for Wi-Fi or Bluetooth devices. How can GPS help to discover the devices?
It's hard to explain to apps' users why GPS needs to be turned ON.
GPS eats battery (quite a lot).
Android apps' developers spend hours or days with this issue instead of creating something useful. One of the reasons is that this ill-behavior is still not properly documented, for example for bluetooth.
According to various reports, this should be a "one-line fix" (removing checking for isLocationEnabled() somewhere within getScanResults()) which makes this even worse for Google if they are not able at least to come with a meaningful explanation of why they are reluctant to change the current API behavior.

Thank you.

Comments

ja...@google.com <ja...@google.com> #2Oct 2, 2020 08:25PM

Assigned to ja...@google.com.

Thanks for the feedback. We love to hear from the community. We'll pass this feature request to our product and engineering teams for possible consideration.

ja...@google.com <ja...@google.com> #3Oct 2, 2020 09:22PM

Status: Won't Fix (Intended Behavior)

Thanks again for the feedback! Our product and engineering teams have evaluated the request and responded:

The WiFi and BT devices do not require GPS - they require Location to be enabled. These results fundamentally disclose the location of the user and therefore when the user disables Location Mode on the device these APIs do not function.

p....@centrum.cz <p....@centrum.cz> #4Oct 3, 2020 08:20AM

The WiFi and BT devices do not require GPS - they require Location to be enabled. These results fundamentally disclose the location of the user and therefore when the user disables Location Mode on the device these APIs do not function.

Thanks for your response, but guys, looks like even after all the previous feedback from the community and users you don't still get it - or worse, maybe just pretend you don't get it?

So once again, could you please kindly explain:

On most devices, enabling Location effectively means also turning on GPS, so putting it like "The WiFi and BT devices do not require GPS" is not quite correct, right?
Where do users have the choice to enable being located via WiFi or BT, but without activating the GPS? If this isn't currently possible due to how the Android code is written, can you look at how to fix your code?
Where is this documented, together with at least some basic reasoning?
When closing this as "Intended behavior", whose intention is this? Who would intentionally want this 5 years old behavior? Developers? Users? Note that smartphones happily worked without the need to enable GPS before you changed it back then.
As also mentioned elsewhere, wouldn't it suffice just to inform users that when giving an application an extra permission to WiFi or BT, that this can also lead to their location being "told to the world"? Then the current, somewhat artificial binding with the Location permission wouldn't be necessary at all. Anyway, I think this is a research task for your Android designers who surely have a deep knowledge of the various possibilities and it's them who should be able to find the simplest way out.

So, I think not only me would be very glad if you could take your time and not to repeat what was already said elsewhere and what didn't lead to any solution. In short, please tell us something new & useful. I didn't want this to be another endless discussion or one-way complaints from the community in the end...

And I apologize if I just didn't get your explanation, it looks like I'm not the only one though.

p....@centrum.cz <p....@centrum.cz> #5Oct 3, 2020 08:39AM

Also, please note that by turning GPS on as described above definitely tells the user's location to the world. So it seems like you are "getting rid of a devil by inviting even a bigger devil" (I don't know the exact English idiom). That's probably all to sum up the topic, not sure if there is anything left to say...

an...@gmail.com <an...@gmail.com> #6Oct 3, 2020 09:37AM

This is absurdly stupid. And that is not an exaggeration.

An app telling its user, "We gonna need location permission to connect to the Bluetooth device, oh and while you are at it we'll also need the location service on (the GPS looking icon in the drop-down try? yeah, that'll do). We are not gonna retrieve your location or anything by the way, in fact, we don't even need it ON to search nearby BT/WIFI devices, that is just how the bloody APIs are defined."

That sounds like borderline fishy behaviour to users. Oh, and connecting to a BLE (Bluetooth >LOW ENERGY<) device requires one of the most energy-consuming systems to be ON.

I have reported this issue two year ago, have even provided a demo app with code that specifically exhibits this behaviour and it completely baffles me how they are failing to grasp this issue.

ja...@google.com <ja...@google.com> #7Oct 5, 2020 03:18PM

Thanks again for the feedback! Our product and engineering teams have been updated.

kr...@gmail.com <kr...@gmail.com> #8Oct 6, 2020 06:02PM

Full agree on previous comments said to see that it did not changed since 5 years, these "precise location" and "coarse location" permissions should be better exposed to the end-users. Thus turning GPS should not be required... More and more users have became aware of junks stuff on the App Store, thus the times when user granted (and trusted) us all has already gone away. There are many "trojan" apps there so getting privileged from the user is not that easy, not to mention how much effort it takes to prepare all that permission flows as state of art....

Krystian.

ja...@google.com <ja...@google.com> #9Oct 6, 2020 06:17PM

Status: Assigned (reopened)

Thanks again for the feedback! Our product and engineering teams have been updated.

Issue re-opened for further evaluation. Please standby.

ja...@google.com <ja...@google.com> #10Oct 12, 2020 10:37PM

Status: Won't Fix (Intended Behavior)

Thanks again for the feedback! Our product and engineering teams have evaluated the issue and responded:

This is an intentional change in Android behavior to improve user privacy - whether a Location comes from GPS, WiFi, BT or another source - when the user turns off the Location settings, or permissions for an App, we need to interpret that as Location-is-off, for the system/app.

pi...@gmail.com <pi...@gmail.com> #11Oct 13, 2020 02:07PM

I agree with previous posters that this is absurd from Google and can only be explained as an low attempt to keep Big Brother fed with most private data if user just needs a basic function (often in the privacy of his own home). Now, the entire world has to know what my SSID is and where it is located. I can hardly believe Google took a linux base and then turned it into a leaky monster. Hope lawmakers around the world come down on you hard, and these kinds of issues make people feel you deserve no better (well, this and the tax-dodging). Hope the stock-options help appease your souls.

p....@centrum.cz <p....@centrum.cz> #12Oct 13, 2020 06:50PM

Hi there, yes, this is ridiculous. The answers are written in a way that makes me think that the "engineering teams" need to be closed in a mental health hospital. No sane engineer would give answers like that. If he did, he would surely get sent back to school in order to learn basic communication and argumentation skills. But yeah, the explanation seems simple - Google just abuses their near-monopoly market position here, giving just some lame excuses from their prefabricated templates...

ml...@ncsu.edu <ml...@ncsu.edu> #13Nov 4, 2020 08:49PM

ja... the answer is unbelievably dumb. In particular, confounding the need for permissions and the need for a service is plain stupid. And bordering on criminal! Consider the stopCOVID apps for a second you dumbasses! These applications are supposed to provide notifications of possible COVID exposure by using Bluetooth Beacons. The effectiveness of these apps depends (strongly) on penetration. The app does not want or need location information to work: just to return a scan result from BLE. However, you not only require location *permissions* for the APP (which is, borderline justified), but you also require the location service to be on. Which starts the GPS, which drains the battery (at the very least - in reality it also freaks people up), and which means that the app is not used. Which means that in the grand scheme of things (where hundreds of thousands of people die), it's practically guaranteed that at least a few people die due to your arrogance and inability to distinguish between permissions and service. Tell your arrogant asses in the team that they have the blood (or lungs in this case) of a few COVID cases (not sure how many, but surely >0) on their hands.

ma...@gmail.com <ma...@gmail.com> #14Feb 24, 2021 12:42AM

I have only just come across this issue, and I must echo the concerns raised by those posting here. The only conclusions I can draw are:

1. Google engineers don't understand the problem with this 'intended behavior'.
2. Google engineers do understand the problem, but choose not to acknowledge that it is a problem because...
A. They are part of a conspiracy with authorities to track all citizens through GPS.
B. They are part of a conspiracy with device manufacturers who want to sell new devices with especially big batteries.
C: They want more people to die of COVID-19 which will happen when people realize the security vulnerability associated with running apps the require BT.
D. I'm struggling to think of any other possible reason...

I can certainly imagine some legal liability issues here. Consider: A person wants to turn on their BLE device. Android OS forced them to turn their GPS tracking. Their ex-partner can now locate them and assault them.

Maybe time for the Google engineers to explain to Google lawyers this bit of 'intended behavior'.

ja...@google.com <ja...@google.com> #15Feb 24, 2021 09:27PM

Thanks again for the feedback! Our product and engineering teams have been updated.

wo...@gmail.com <wo...@gmail.com> #16May 26, 2021 01:57PM

We OFTEN have customers who think we are stalking them because we have to ask for the fine location permission, when all we want to do is find and talk to our product via Bluetooth.

Apple seemed to figure it out...

https://support.apple.com/en-us/HT210578
The user only needs to turn on a Bluetooth permission.
"The permission prompt includes a brief explanation of how the app uses Bluetooth, which may include discovering nearby devices, refining location information and other uses."

Maybe competition will prompt Google to get their act together?

wo...@gmail.com <wo...@gmail.com> #17May 26, 2021 02:14PM

This also has a significant negative impact on our app ratings on the play store. Many customers obviously don't understand even though we try to explain that we aren't tracking them.

Really, this seems like a Bluetooth SIG issue. There should be protected API if you want to use Bluetooth for location information, and your Bluetooth device should need special approval by the Bluetooth SIG to use those APIs. Anyway, that does not concern Google, unless Google could pressure Bluetooth SIG to fix the problem with spec changes.

p....@centrum.cz <p....@centrum.cz> #18Jul 4, 2021 10:01AM

Hi Google, I've got some important updates for you coming from your own employees that they probably forgot to tell you! ;)

Firstly, you may look at New Bluetooth permissions in Android 12 - it states that your developers introduced separate permissions like BLUETOOTH_SCAN, which possibly leads to actually fixing the design bug discussed in here? (BTW Note the clever move of deciding that this fix won't be back-ported to previous Android versions...)

Another interesting articles which you should also definitely read before leaving this issue resolved as "Won't Fix (Intended behavior)":

Android 11 Beta 3 is here, removing the location requirement for COVID-19 contact tracing apps (Android 11 comes from September 2020)
Apps no longer need your location to scan for nearby Bluetooth devices on Android 12 (Android 12 comes from February 2021)

So, if the above is true, what's next? Can we at least expect some kind of apology from the Android 6 designers or from the follow-up Google-paid trollers that tried to pretend the problem doesn't exist at all and refused any kind of fruitful discussion with the community?

mo...@gmail.com <mo...@gmail.com> #19Apr 24, 2024 12:43PM

bump... still an issue...

ra...@gmail.com <ra...@gmail.com> #20Jun 17, 2024 09:37PM

So Google is protecting my privacy by forcing me to give up even more private data? In order to enable Bluetooth scanning, do I also have to allow GPS access???

Issue 169936948

Description

Issue summary

Comments

ja...@google.com <ja...@google.com> #2Oct 2, 2020 08:25PM

ja...@google.com <ja...@google.com> #3Oct 2, 2020 09:22PM

p....@centrum.cz <p....@centrum.cz> #4Oct 3, 2020 08:20AM

p....@centrum.cz <p....@centrum.cz> #5Oct 3, 2020 08:39AM

an...@gmail.com <an...@gmail.com> #6Oct 3, 2020 09:37AM

ja...@google.com <ja...@google.com> #7Oct 5, 2020 03:18PM

kr...@gmail.com <kr...@gmail.com> #8Oct 6, 2020 06:02PM

ja...@google.com <ja...@google.com> #9Oct 6, 2020 06:17PM

ja...@google.com <ja...@google.com> #10Oct 12, 2020 10:37PM

pi...@gmail.com <pi...@gmail.com> #11Oct 13, 2020 02:07PM

p....@centrum.cz <p....@centrum.cz> #12Oct 13, 2020 06:50PM

ml...@ncsu.edu <ml...@ncsu.edu> #13Nov 4, 2020 08:49PM

ma...@gmail.com <ma...@gmail.com> #14Feb 24, 2021 12:42AM

ja...@google.com <ja...@google.com> #15Feb 24, 2021 09:27PM

wo...@gmail.com <wo...@gmail.com> #16May 26, 2021 01:57PM

wo...@gmail.com <wo...@gmail.com> #17May 26, 2021 02:14PM

p....@centrum.cz <p....@centrum.cz> #18Jul 4, 2021 10:01AM

mo...@gmail.com <mo...@gmail.com> #19Apr 24, 2024 12:43PM

ra...@gmail.com <ra...@gmail.com> #20Jun 17, 2024 09:37PM

Add comment

Issue metadata