Fixed
Status Update
No update yet.
Comments
ar...@google.com
ba...@gmail.com
Why Google not remove only BSSID when location is not enabled? (or return 00:00:00:00:00:00) and it's same problem for Bluetooth...
SSID only can't be used to locate user, or why google not block IP address?
With IP address you can locate me!
SSID only can't be used to locate user, or why google not block IP address?
With IP address you can locate me!
te...@gmail.com
SSIDs are completely sufficient to locate users. There's an extremely low probability that at two places in the world there are networks with the same SSIDs in the neighbourhood. Remember, we aren't talking about a single SSID but the combination of all the SSIDs your phone sees in your area - and this combination is specific to your location. Not showing BSSID isn't sufficient.
IP-based geolocation using services like MaxMind GeoIP isn't very precise - the precision is about 50km and sometimes completely off. Compare this to the SSID-based geolocation whose precision is about 50m. Don't know how you imagine IP addresses should be "blocked" - without IP you cannot use the Internet...
IP-based geolocation using services like MaxMind GeoIP isn't very precise - the precision is about 50km and sometimes completely off. Compare this to the SSID-based geolocation whose precision is about 50m. Don't know how you imagine IP addresses should be "blocked" - without IP you cannot use the Internet...
ba...@gmail.com
However with a router that changes BSSID every reboot, the location never worked at home (FREEBOX v5). Hotspot use the same SSID and the better to located is to use hotspot (fixed for more year)
Geolocation by IP is very easy and for example my ipv6 /64 is located @50m.. Once referenced in a database with precise location by GPS .. it is very accurate if we are all in fixed IP. (just google never return more precision and fortunately)
The answer of the API can be blocked to not respond with IP, and yes, the better is Android should allow the choice of which application can access the internet or not to avoid the location.
Location with only SSID never work fine and is absolutely unreliable. (I added my router in the database with BSSID to correct my location with Google; Worse than not being located is to be systematically located in the wrong place)
To say that Google does not try to completely hide the position, so why restrict so much wifi and Bluetooth? While GooglePlayService which I would limit access to my position, has features that allows it to access even wifi and bluetooth when off to search nearby devices!
Without saying it, Google just forces more than anyone to keep active localization .. this allows to inflate its geolocalisation base legally.
Geolocation by IP is very easy and for example my ipv6 /64 is located @50m.. Once referenced in a database with precise location by GPS .. it is very accurate if we are all in fixed IP. (just google never return more precision and fortunately)
The answer of the API can be blocked to not respond with IP, and yes, the better is Android should allow the choice of which application can access the internet or not to avoid the location.
Location with only SSID never work fine and is absolutely unreliable. (I added my router in the database with BSSID to correct my location with Google; Worse than not being located is to be systematically located in the wrong place)
To say that Google does not try to completely hide the position, so why restrict so much wifi and Bluetooth? While GooglePlayService which I would limit access to my position, has features that allows it to access even wifi and bluetooth when off to search nearby devices!
Without saying it, Google just forces more than anyone to keep active localization .. this allows to inflate its geolocalisation base legally.
ke...@gmail.com
@4
"However with a router that changes BSSID every reboot, the location never worked at home"
"Location with only SSID never work fine and is absolutely unreliable"
This is not the case for Most access points, since they do not have volatile BSSIDs。
"However with a router that changes BSSID every reboot, the location never worked at home"
"Location with only SSID never work fine and is absolutely unreliable"
This is not the case for Most access points, since they do not have volatile BSSIDs。
ar...@google.com
We've deferred this to a future release, but leaving this open for now.
lh...@gmail.com
Fuck yall I know diversity creative Commons. Can't hit a moving target. And I am not a big consultant for diversity. And I am mentally challenged. I'm under an apple Web kit with transparent apps to make me delusional. Don't worry I know. Bug be gone.
te...@gmail.com
I must say I'm really disappointed by Google's attitude to this privacy issue which still isn't fixed as of Android P DP1. Allowing apps to bypass the location permission is really bad for user's privacy and I am sure many apps misuse this API for this very purpose. To me this feels like another "Cambridge Analytica" scandal where apps collect sensitive data without users knowing it and where Android developers ignore the issue because they "had no idea the information could be misused" (this will be the official explanation from Google CEO once it turns out that some app was tracking locations of millions of users).
And really all it takes is to change a few lines in
com/android/server/wifi/util/WifiPermissionsUtil.java
and possibly disallow reflection which you can do now in Android P.
And yes, I know that in the autumn you will require that all app updates will have to use the latest Android for target SDK which will eliminate this issue for updated apps. But there will still be lots of zombie apps in the store that will never get updated and that can (mis)use this API forever.
Propagating latest Android versions to users takes ages and even if you fix it for Android P, it will take at least 2 years before it gets to 50% of users. So the sooner you fix it, the better.
And really all it takes is to change a few lines in
com/android/server/wifi/util/WifiPermissionsUtil.java
and possibly disallow reflection which you can do now in Android P.
And yes, I know that in the autumn you will require that all app updates will have to use the latest Android for target SDK which will eliminate this issue for updated apps. But there will still be lots of zombie apps in the store that will never get updated and that can (mis)use this API forever.
Propagating latest Android versions to users takes ages and even if you fix it for Android P, it will take at least 2 years before it gets to 50% of users. So the sooner you fix it, the better.
ke...@gmail.com
@8
I 'll raise another issue report for this, and expect it getting declined
I 'll raise another issue report for this, and expect it getting declined
te...@gmail.com
I actually did the same and reported this as a security issue (even though technically it's a privacy issue) together with a sample project here:
https://issuetracker.google.com/issues/78378449
Let's hope it gets more attention.
Let's hope it gets more attention.
ke...@gmail.com
@10
It seems they have it fixed in the internal P builds, however I am not sure whether it would be backported to previous (Android) major versions.
The fix might be observed in the next developer preview of P(probably at I/O 2018):
https://issuetracker.google.com/issues/78373196
In the end of another report(https://issuetracker.google.com/issues/68360808 ) someone said
"......I *can* read the SSID (but not BSSID) via ConnectivityManager.getNetworkInfo inside an Activity and BroadcastReceiver, with or without ACCESS_FINE_LOCATION........"
It would be an unfinished part of fix described inhttps://issuetracker.google.com/issues/65085176 if the statement is true, since SSID is also ditched from WifiInfo if the caller app doesn't have any location permission
It seems they have it fixed in the internal P builds, however I am not sure whether it would be backported to previous (Android) major versions.
The fix might be observed in the next developer preview of P(probably at I/O 2018):
In the end of another report(
"......I *can* read the SSID (but not BSSID) via ConnectivityManager.getNetworkInfo inside an Activity and BroadcastReceiver, with or without ACCESS_FINE_LOCATION........"
It would be an unfinished part of fix described in
te...@gmail.com
@11 Yes, it seems to be fixed in Android P beta. I didn't expect this would be backported to older Android version as it changes the system behavior.
I guess this bug can be closed now.
I guess this bug can be closed now.
is...@google.com
sa...@google.com
We will be closing this bug due to being logged in a Preview version of Android. If the issue is still relevant and reproducible in the latest public release (Android Q), please capture a bugreport and log the bug in https://goo.gl/TbMiIO . If a reply is not received within the next 14 days, this issue will be closed. Thank you for your understanding.
sa...@google.com
vi...@google.com
Our development team has fixed the issue you have reported.
Description
However, apps targeting pre-Android-6 API aren't checked for this permission at all and can still access this privacy-related information which indirectly reveals user's location. This way they can bypass the check forever - even in the latest Android O beta it is still possible to call WifiManager.getScanResults() without any permission check if the app defines target SDK 22 or less in its manifest.
This is wrong from the privacy point of view and should be forbidden in Android O. Malicious apps will just use target SDK 22 and will have access to users' location without any warning from Android. There are online databases mapping SSIDs to location (and Google itself uses this technique to get network-based location) and the protection right now is zero. Developers already had 2 years since the introduction of Android 6 to adapt their applications which should be more than enough. Moreover, it will take at least 1 year to get Android O to end users and before the check is finally enforced.
The code that checks for permissions of this call is in
com/android/server/wifi/util/WifiPermissionsUtil.java
In particular, in the check
// LocationAccess by App: For AppVersion older than minVersion,
// it is sufficient to check if the App is foreground.
// Otherwise, Location Mode must be enabled and caller must have
// Coarse Location permission to have access to location information.
boolean canAppPackageUseLocation = isLegacyForeground(pkgName, minVersion)
|| (isLocationModeEnabled(pkgName)
&& checkCallersLocationPermission(pkgName, uid));
isLegacyForeground () should be removed.
---
Finally, one semi-selfish reason I want this check to be enforced - I'm a developer of this app:
One of the features is also wifi signal meter which uses WifiManager.getScanResults(). The app uses the latest SDK, uses runtime permissions and I try to behave nicely and tell users why the permissions are needed also for wifi scan. Still, I keep receiving bad reviews saying my app requires the location permission while other apps (which target pre-23 API) don't. For end users I'm the "bad" guy and developers targeting old SDK are the "good" guys even though it's the other way round and it's me who is more transparent about what is happening.
So apart from privacy concerns, this isn't a fair situation for developers. There's a zero motivation for developers using a pre-23 target API to adopt the new API because they get punished for it.