Special App Access Should be Off by Default

[deleted]

I only recently noticed the special app access window, which was separate from the permissions manager and the privacy settings. I was shocked to find that Wi-Fi control is granted by default to all apps without my explicit approval. I used to be on iOS before moving to GOS and this permission was always off by default and had to be explicitly granted to apps, so I just assumed that it was the same case here. I had some social media apps installed for a while, and I shudder to think what Facebook or Twitter were doing scanning my network behind my back, before I disabled this permission.

I understand that GOS follows AOSP which enables these by default, but looking at the privacy settings in GOS, I see a toggle for disabling all future sensor permissions, even though that is also enabled by default on all apps. Why can't a similar toggle option be added for all future Wi-Fi control access?

Looking at the other options in Special App Access, I also see Alarms & Reminders is also enabled by default for all apps. I'd also like the option to turn that off if possible because according to the permission description, setting this permission also allows apps to run in the background.

One more thing to note: I know the GOS has been having issues diagnosing and fixing the AOSP bug that resets certain Special App Access permissions after a system update. Adding these toggles can at least allow users to quickly disable these permissions if they are ever reset by an update. Dear dev team: Please consider adding this option, and thank you for all the hard work you put into this project.

[deleted]

[deleted] I don't think you are right there on WiFi control mate. I have 3 apps that use this permission and I remember specifically granting that permission either upon installation or later in use when it was required. No app just grabs a permission as they please. Of course you are always welcome as many times as you like to revisit permission settings as part of your privacy and security checkup, it IS ON YOU! Have a great day.

dazinism

[deleted]
Apps do get this by default.

I think its likely your concern, but this doesnt let the apps get information which reveals your location. Access to such data is strictly gated by the location permission.

https://github.com/GrapheneOS/os-issue-tracker/issues/1551
Also see the duplicate issue linked from the bottom of that issue which has more details about the permission.

[deleted]

[deleted] I have never willingly given an app access to my Wi-Fi controls, and certainly not to the 10 apps that had it enabled by default when I checked. Just now, I double checked again by uninstalling and reinstalling an app in that list, and sure enough the Wi-Fi access control was re-enabled by default with no prompt being shown to the user.

[deleted]

dazinism Okay, I am going to accept your answer but what I said is also true, I think mainly down to the fact that I have location always turned off, unless I need it. And I think that is why my apps requested that permission to be granted.

[deleted]

dazinism Thanks for sharing. I see someone commented some details about Wi-Fi control, sharing so others can easily find it:
"Wi-Fi control" special access permission maps to OP_CHANGE_WIFI_STATE app-op, which is separate from the CHANGE_WIFI_STATE permission. CHANGE_WIFI_STATE permission has normal protection level, ie it's auto-granted and cannot be denied by the user. Many of Wi-FI APIs (WiFiP2p, WiFiRtt, WiFiAware etc), check only CHANGE_WIFI_STATE and not OP_CHANGE_WIFI_STATE.

Looks like Daniel closed the issue as there is no clear impetus for disabling by default, given the above and the location restrictions mentioned. Honestly, I feel a little better, but I still don't understand why it needs to be enabled by default in any case as it's very rarely used except for setting up specific network devices, and is just extra attack surface that an attacker can search for a zero-day in and exploit.

evalda

Reading Daniel's comments in https://github.com/GrapheneOS/os-issue-tracker/issues/922
my understanding is that having Settings > Apps > Special app access > Wi-Fi control toggle on does not give app an ability to see what Wi-Fi networks are available in the user's proximity.

Is that correct or I didn't understand it?

other8026

evalda reading what was said there, I also read it to mean that.

Location permission is required, see this quote by the project account:

Apps require the Location permission to get nearby Wi-Fi networks.

breadful_bagel

My personal concern for this subject is that I don't want my apps to be able to fingerprint me based on available networks' SSIDs and MAC addresses. First, let me cite a few quotes.

Daniel M asserts that wifi scanning is impossible without location permissions enabled on an app.

Location data including nearby Wi-Fi networks isn't available without the Location permission. Some things need a combination of multiple permissions. Wi-Fi control permission doesn't give access to any sensitive location data without the Location permission too.

@muhomorr claims that CHANGE_WIFI_STATE is auto-granted, so the GOS user cannot disable that permission.

"Wi-Fi control" special access permission maps to OP_CHANGE_WIFI_STATE app-op, which is separate from the CHANGE_WIFI_STATE permission. CHANGE_WIFI_STATE permission has normal protection level, ie it's auto-granted and cannot be denied by the user. Many of Wi-FI APIs (WiFiP2p, WiFiRtt, WiFiAware etc), check only CHANGE_WIFI_STATE and not OP_CHANGE_WIFI_STATE

This android developer document on wifi scanning claims that the ACCESS_WIFI_STATE permission is sufficient to invoke WifiManager.getScanResults().

A successful call to WifiManager.getScanResults() requires any one of the following permissions:

ACCESS_FINE_LOCATION

ACCESS_COARSE_LOCATION

CHANGE_WIFI_STATE

The android developer reference on WifiManager.getScanResults claims that both location permission and CHANGE_WIFI_STATE are needed to receive the output of a wifi scan, though.

An app must hold ACCESS_FINE_LOCATION permission and Manifest.permission.ACCESS_WIFI_STATE permission in order to get valid results.

WifiManager.getScanResults gives the caller a full list of ScanResult objects, including SSIDs but also hardware addresses of the access points, frequency bands, and other highly unique identifying information. So the goal for a fingerprinting-adverse user is to limit which apps can invoke this method.

So quotes (1) and (4) seem to line up, but they contradict quotes (2) and (3): If apps are "auto-granted" the CHANGE_WIFI_STATE permission on-demand, and that permission gives access to WiFiManager.getScanResults, then how is access to nearby WiFi AP lists be protected by location permission?

I figure @muhomorr and Daniel are probably correct, and it's the android docs for wifi-scanning (3) which are mistaken, especially given the contradiction between (3) and (4).

The only way to know for sure though seems to be to test it with a real app, which I hope the GOS devs have done. Give it location + wifi-control permission and verify it can call WifiManager.getScanResults. Then disable the location permission and verify that method now throws an exception. I would love if any GOS devs can confirm this was checked.

breadful_bagel

For what it's worth, to support my hypothesis that the android docs are wrong, see the docs for this react-native wifi-scanning library. They tell devs that they must enable the ACCESS_FINE_LOCATION permission to use wifi-scanning.

Since Android 6, you must request the ACCESS_FINE_LOCATION permission at runtime to use the device's Wi-Fi scanning and managing capabilities. In order to accomplish this, you can use the PermissionsAndroid API or React Native Permissions.