Cut down on needed permissions

[SecUpwN]

Cut down on needed permissions

[rmenessec]

I don't suppose you'd consider adding a workaround for rooted devices... ? I'd like to be able to use this app, but having GPS turned on continuously is another kind of privacy (and power) leak. I'm afraid it's a deal-breaker for me.

[jomo]

Unfortunately newer versions of Android won't return a list of nearby Wi-Fi devices unless GPS is turned on, or the app is in foreground. This has been discussed in #30.

[SecUpwN]

Thanks for telling me, @jomo. Does that mean the app is useless on newer devices when GPS is turned off until Google fixes the bug? Gosh, how I hate that they're tossing and turning their OS over and over..

[jomo]

As I understand it, yes :(
Maybe it works on a rooted device when PrivacyPolice is turned into a system app and this scanning option is enabled. Haven't tested that yet, though.

I'm thinking about sending CyanogenMod a PR that fixes android#185370.

[BramBonne]

I do understand the rationale behind the decision in AOSP: getting a list of nearby access points essentially discloses the location of the user, and a user could expect its location to be private when 'location access' is turned off.

However, I agree that this should probably be solved in a different way (e.g. allowing apps that manage Wi-Fi networks to have this access anyway, while alerting the user about how this could compromise his/her privacy).

I'm closing this issue for now. Feel free to re-open if you find a suitable solution.

[BramBonne]

I wouldn't know of any way to circumvent this with root access without doing lots of hacky things, so no, I won't write a workaround for rooted devices for the time being. However, if you can think of an elegant solution to this, feel free to submit a patch, and I'll gladly include it.

That being said, your GPS chip doesn't need to be turned on: having 'coarse' location access (only using Wi-Fi and cell towers) should be sufficient. However, I do understand if you'd prefer not to. Since PrivacyPolice does not enforce this by itself, you can always try running it without location turned on and see what works.

[rmenessec]

First, let me ask: is there a way to disable the location nag whilst experimenting? I didn't see one while I had the app installed. If not, I can (obviously) block the app's permission to write notifications as a temporary fix.

The absolute least hacky workaround I'm aware of would be—might be—manually granting whatever the necessary permissions. See the XDA post "Alternative to installing Better Battery Stats as system app". If this is a valid workaround for obtaining WiFiPP's permissions, then I just need to know what permission or permissions to substitute in the example. 😉

If this is a valid approach, it would be great if the app could later add the ability to elevate to root, grant itself the necessary privileges, then discard the elevated credentials. Or I can do it by hand, seeing as I can't think of a reason to regularly [re]install WiFiPP. 😁

Only slightly more hacky: install WiFiPP in /system? I'm a bit hesitant to test this, but would do if you don't have access to (don't want access to?) a rooted Android platform. 😉 As referenced in the post, apparently, this is a valid way for BetterBatteryStats to get normally-restricted permissions.

The next-least hacky workaround I can name would be a small Xposed module to restore access to the necessary permission(s), perhaps similarly to "Enable BATTERY_STATS for KitKat". I'm not clear whether KitKat revoked or merely restricted access to BATTERY_STATS, but apparently it's not hard to repair the situation.

I'm afraid that I can only offer these user-level suggestions. I am not an Android nor a Java developer. I'm in no position to submit a patch. My level of comfort with Android derives mostly from 20 years of administrating Linux—never developing for it. (I've supported unimaginable legions of Java developers in my career, if that's a help...)

[BramBonne]

Thanks for your comprehensive response! Let me answer inline:

First, let me ask: is there a way to disable the location nag whilst experimenting?

Since the latest version (2.2.2), you can disable this notification at the bottom of the new 'location rationale' screen.

The absolute least hacky workaround I'm aware of would be—might be—manually granting whatever the necessary permissions.

I'm afraid that won't be sufficient: this is just a substitute for giving normal permissions that the app would be needing anyway. As far as I know, there's no special permission for system apps to access Wi-Fi networks.

Only slightly more hacky: install WiFiPP in /system?

This could definitely work! There's a special setting in Android's location preferences that allows 'system' apps to scan for networks, even when location is disabled. You're very welcome to try this option and report back to me.

The next-least hacky workaround I can name would be a small Xposed module to restore access to the necessary permission(s)

I'm afraid this has the same problems as the first solution.

Thanks again!
Bram

[beerisgood]

I use WiFiPP 2.1.1 (from F-Droid) and it works for me in CM13 (Android 6.0.1) without GPS.
So i wonder why GPS is now required

[BramBonne]

Hi @beerisgood,

1. GPS is not required, only 'coarse location access' is, where your smartphone only uses the Wi-Fi APs and cell towers in range to determine your location.
2. On some devices, even this is not needed. You can then safely disable the notification prompt in the settings.

[SecUpwN]

Thanks for keeping an open mind to all the suggestions, @BramBonne. I am monitoring this Issue and am especially interested in the replies of @rmenessec. Please re-open this Issue if applicable.

[rmenessec]

So, I haven't tested it for long enough, but installing to /system seems to be working, at least in the short term. Depending on exactly what's going on under the hood, though (I don't see logging capability), WiFiPP (and WiFi) only seem to work just fine so long as WiFiPP has focus. I've stared at my device for minutes on end (several times), now, and WiFi appears steady.

If I switch to another app, I lose WiFi within 60 seconds or so. When WiFiPP regains focus, it takes about half a minute for WiFi to reconnect. If I swipe the app out of Recents, I lose connectivity much faster; within less than 10 seconds. Both are easily reproducible. Either WiFiPP is doing... something... differently when it doesn't have focus, or else I'd theorize it's being suspended and/or killed when focus is gone.

I'm not certain whether this has anything to do with Marshmallow vs. Lollipop; I have the "screen on when powered" option enabled in Developer Options, which—as I understand it, loosely--should mostly or entirely prevent 6.0's deep hibernation from suspending WiFiPP. I haven't bothered to test behavior on battery alone, yet.

I have "Data protection" turned on, and I get prompts asking me about the various SSIDs around me, including mine, so that's working. To summarize: as long as WiFiPP is foreground or if I'm in the notification drawer for long enough to respond to the prompts, approved SSIDs work just fine and I remain connected. If I try to do anything else, I lose WiFi.

My test platform is a Nexus 6, MMB29V.

Let me know if I can add anything.

PS: I do have Greenify installed, but I left the option to suspend system apps disabled on account of burning myself while experimenting with it on an older device. It is most definitely not suspending WiFiPP, and shouldn't; not with the screen timeout disabled.

PPS: It would be nice if the app targeted SDK 23. Just sayin'. 😉

[BramBonne]

Thank you @rmenessec for your very thorough testing! It seems indeed like something (either your system or Greenify) is suspending PrivacyPolice when it isn't in foreground. The latest release (which you're using) already has a mechanism built-in which should prevent this from happening too much, but unfortunately nothing is completely fool-proof.

As PrivacyPolice itself is not doing anything differently depending on whether it is the foreground activity, I'm afraid there's not much I can do about this. Feel free to suggest any possible solutions though!

[rmenessec]

Greenify isn't allowed to suspend anything that hasn't been "whitelisted" for Greenify to control. PrivacyPolice isn't in that list. (Very little is; mostly things like Amazon Shopping, Barcode Scanner, or Chrome. In short, apps where I'm really sure it doesn't matter much if they lose their working state or fail to respond to GCM push or other events.)

Greenify's timer coalescing is enabled - I've never seen anyone mention that this hurts compatibility / breaks apps. If I'm wrong, I'll be happy to test with it off. ☺

Does PrivacyPolice have a separate background service that handles SSID associations? If memory serves, background services in Android are treated very differently from monolithic apps; if you switch away from a monolithic app, it's generally assumed that you don't need to use it right now. With the exception of music players and a few other use cases, processes without background services are subject to suspension, even with the screen on... I think.

(I have a very loose understanding of the limits "processes" and "services" are subject to in Android, and I'm still not clear on the various changes Marshmallow made. I use Linux primarily, and I don't pretend to understand all the changes Android's made to memory handling, process scheduling, etc.)

[BramBonne]

Thanks for your clear explanation! I'll try to explain here how (and when) PrivacyPolice is active.

As soon as the Android system has performed a network scan for new Wi-Fi networks, it sends a Broadcast message to the system, indicating that a scan has been completed, and providing the list of available networks to all applications that carry the right permission. As such, PrivacyPolice is not constantly running in the background, but is woken up by the Android system itself as soon as a scan has been completed.

Now, this is not entirely correct: PrivacyPolice also contains a background service scheduling alarms from time to time to prevent Android 6.0's App Standby mode from kicking in. This mode would make it so that PrivacyPolice would be effectively disabled if it wasn't used from time to time.

[rmenessec]

Then I am completely out of ideas as to why WiFiPP stops working when it loses focus. 😁

Do you have an Android 6.0 environment to test in? I'm guessing it's going to come to that to work out what's happening. I haven't seen anything useful just from glancing at logcat output.

I haven't used the Android SDK in some time, so I've no idea whether the network hardware emulation is deep enough for testing issues with WiFi association. Alternately, if you'd like to provide me some sort of debug build, I'd be happy to collect some data with it and send you the results.

Thanks!

[BramBonne]

The strange thing is, I recently upgraded my Oneplus One to CM13 (Android 6.0), and I'm not seeing any problems.

I'll try to see if I can reproduce the issue, but I'm afraid it doesn't occur on my particular setup.