Android has a lot of information leaks. I hate to keep beating this dead horse, but as of last year Google gives every app you install access to your cellphone number without them needing to ask for an extra permission (READ_PHONE_STATE is now a freebie as far as the app store is concerned, it isn't listed, in fact it will say "no special permissions" if READ_PHONE_STATE alone is in the manifest).
I honestly think Android's permission system is a joke, and a sceptical Google will fix the majority of the information leaks with this up-coming update.
PS - It is "interesting" that getting your google account address requires a special permission on Android, but getting your phone number does not. Wonder why that is? IMEI too.
If they've found that users almost always say yes to it, that might be the correct choice for being consistently usable even if you (and I) dislike that choice.
I am not sure how it should be handled.
Allowing an app to automatically propose the user's email in a login form is pretty good in terms of UX ... but it means that the app can access to that data.
It seems pretty clear how this should be handled, no? If the app wants to do it, then, as with anything else that might make the user experience better at a privacy cost, let it ask for permission to do it!
Having to ask for the permission to display the email just for the autocomplete makes sense from a privacy perspective, but defeats its UX purpose.
A better solution would probably be to continue to move away from email + password logins and ask the user to login once in an OCD platform and then only propose this in order to signup/login to an app.
I believe these are certainly the result of deliberate decisions.
Remember when Google introduced fine-grained permission control, received much praise for it, then removed it almost immediately afterwards? To me, that showed they clearly valued the interests of themselves and their monetising "appvertiser" developers over the freedom of the users.
Even the actual SSID name is probably more than an ordinary app needs to know.
Unless it needs some sort of location data to provide functionality, what is the minimum set of facts that would cover app behaviour?
I guess they might want to know:
- if the connection is secure and/or explicitly trusted
- if the connection is bandwidth-metered
- if the connection can route to the internet
Then, it can check those flags and decide if it wants to download those 3GB of your personal banking details or whatever.
Or, perhaps better still, it registers one or more 'acceptable network profiles' based on the above fields, and the OS gives it a callback when is becomes available/unavailable.
That would prevent it from polling and building a neighbourhood network map, but I suppose it could still register for all possible combinations, and beacon out to a remote host which can then geo-IP backtrack it to you-ish.
I'm definitely not happy with the carefully secreted privacy options scattered around the android UI. I'm still getting used to it, and every time I poke around in a settings menu I'll probably find at least one thing I would much prefer to default off.
I tried their proof of concept app on CyanogenMod. Its PrivacyGuard was not fooled at all; it described the app as asking for Location permission, and it blocked access to the list of wifi access points unless that permission was granted.
I wonder if this is a corner case of Google Play policy. Stealing privacy is forbidden on GP, but nearby wifi AP should be considered as a public accessible info.
I am surprised that this is even news to people. Fire OS uses Wi-fi to set timezones (which means, by just knowing the BSSIDs, Amazon can pin point your location). Similarly, IP Addresses, if you have tolerance for error, can pretty much help you gauge (coarse) location as well.
It goes without saying that the OHA-Android [0] is a data mine for Google already. With M, they're really upping that game [1]. Far worser things to worry about.
> Note that these metrics are accessible even with system wifi and location disabled
Can someone explain this? It doesn't seem to make sense that with wifi disabled this would be possible (and the code they link to specifically has a fall through if wifi is disabled). Maybe something just got jumbled up in their explanation.
"the Android OS by default performs WiFi scans in the intervals of tens of seconds, even when the WiFi is turned off; the setting to disable background scanning when WiFi is off is buried in the advanced settings."
It looks like you can stop this from happening when the WiFi is off it just requires an extra step. I don't have an Android device so I can't really verify this.
When you set up android for the first time it gives you some text explaining what this is and how it works, and asks you whether you want to enable/disable it.
I'm not sure if this was ever a "default", but it is definitely part of the setup prompts now.
The option you are looking for is called "Keep Wi-Fi on during sleep" and it can be found under Settings -> Wifi -> Advanced on Android 4.3. This is the only device I can test with.
I advise turning it off unless you need it to be on, not only for privacy reasons but for battery life. I noticed an increase in battery life by turning that feature off.
On a Samsung Galaxy S5 running Lollipop (5.01?) it's under Wifi -> Advanced -> Always Allow Scanning.
With this turned off and GPS turned on (ie, not using Wifi to determine locations) I get a terrible reduction in battery life because all locations are done finely with the GPS chip. With all location services disabled I get much better battery life.
Basically doing what the coarse location provider does anyways, which is corollate visible APs on the device with a db of mapped APs.
Yes, it's possible, but constantly scanning for APs will have the side effect of an app draining battery even faster than if it used the phone's location service.
During the Android setup process it asks you if you want to enable this feature and has a side note that these scans are specifically to save battery life because they take much less energy than typical location services.
Yes, wifi scan location takes less power than GPS location. Rolling your own wifi location service in an app will take more power than the framework's service, however, and it will almost certainly be less optimized.
I'm sure there are tricks against battery consumption - for example - scan only when user stops driving. And when user walking scan rarely. Or maybe use Gyro/Accelerometer to estimate where the user walked.
The original title of the article is "How apps track your location without asking for permission".
Reading the article to the end:
>> The same method also applies to iOS, which has greater user location data privacy protection. Nonetheless, iOS still allows acquiring the current connected wifi BSSID. A user can deny the location requests on an iOS device at will. However, an app using wifi BSSID can still get a user’s static location without asking.
So singling out Android in HN submission title is grossly misleading. Especially since reading this comments shows that people don't read the articles posted -_-
> So singling out Android in HN submission title is grossly
> misleading. Especially since reading this comments shows
> that people don't read the articles posted -_-
You know, every time I personally write a blog post, I've learned to just assume that people will only read the title. If I'm lucky they may also see a subtitle or read the first paragraph. But unless you just write some compelling content, almost nobody will read it all the way through. You can't blame people. We're so inundated with information these days, we have to skim through things.
Is accessing nearby BSSIDs available in a similar fashion on iOS? A quick look reveals: https://developer.apple.com/library/ios/documentation/System...