• General

  • Security of automatically turning Wifi off and on

Google has a well known WiFi API that can be used to identify exact location. It would not surprise me if google play services used this to scan your location even with location services for google play apps disabled.

WiFi is an attack vector that can be effectively mitigated with MAC randomization (enabled by default) and a VPN (which encrypts web traffic and DNS request(s). The prospect of MITM (man in the middle) attacks over wifi is a possibility but obviously this is highly unlikely for most users, and to be fair, a phone is not an easy target for most exploits over wifi compared to something like a windows PC.

The risks of wifi on are as follows;
-Digital forensics (if your phone is seized its network traffic can be monitored and discovered- wifi networks can be used to determine your previous locations too)
-Location API from google as stated before
-Connection records on WiFi hubs (but mitigated through pixel 7 MAC randomization)
-MITM attacks over wifi (not as prevalent in modern day networking)

The risks are present but unlikely for most users. The attack vector(s) does/do exist, and setting the disabling of wifi to be lets say 24 hours wouldn't do any harm in my opinion.

Its the same as auto reset- I have this at 24 hours as I use the alarm clock on my phone. If I'm not using the alarm within 24 hours then I have either slept too long or lost my phone!

    6 days later

    TrustExecutor Wow, didn't know that! That's great. Does it work only with the clock in the owner profile, or all of them? Any how does it even work?

        TrustExecutor This must be because I'm using an external app that links to my work calendar. I'm assuming it doesn't use direct boot as @treequell stated. I'll look for another app that can do this!

          iustitia Direct Boot is only possible for apps installed in the owner profile.

          How it works is explained in the link I provided above. Simply speaking, the data available BFU is stored in a separate location, and encrypted in a different manner.

            3 months later

            Backwards876

            Another case to think about is maybe your device is broadcasting the ESSID's of networks that it would like to connect to. The attack would go like this:

            Attacker is running airodump-ng, kismet, or similiar. They catch a connection attempt:

            MAC: 11:22:33:44:ff:ff:ff:ff randomized) wants to connect to MySuperSecretHomeNetwork

            Then they drive around and find MySuperSecretHomeNetwork. Then you show up at home and they catch another connection attempt:

            MAC: 88:77:66:55:ff:ff:ff:ff (randomized) wants to connect to MySuperSecretHomeNetwork

            They can't correlate your mac, but it's still likely to be you because it's a device that's configured to connect to MySuperSecretHomeNetwork. How many of those are there? Or maybe it's one of your friends, but it's still more info than you'd probably like to be out there. I knew a guy who named his home wifi network "Starbucks" for this reason.

            I'm not sure under what circumstances this broadcast occurs, I've just seen them while wardriving and thought "huh, that's a hazard". Next time I'm set up for collecting that kind of data, I'll see how Graphene OS is behaving and update here.

                M8rix Another case to think about is maybe your device is broadcasting the ESSID's of networks that it would like to connect to.

                Yep - good one! And there used to be a freeware app that blocked this. Can't remember if it would work on CopperheadOS (precursor to GOS), or if I was using it on an earlier Android phone. Can't find that app now.

                  M8rix Another case to think about is maybe your device is broadcasting the ESSID's of networks that it would like to connect to.

                  That's not how Wi-Fi works -- unless a device has been told to ping for so-called "hidden" networks, which aren't really hidden and arguably should not be used.

                  https://www.howtogeek.com/28653/debunking-myths-is-hiding-your-wireless-ssid-really-more-secure/

                  So if a device is leaking this information it's easy to make it stop, and that is also a best practice.

                      de0u

                      ESSIDs don't necessarily have anything to do with a hidden SSID.

                      I know that it has been an issue in the past where when you leave wifi on, an android phone will constantly be looking at wifi around you and checking if there's one in your saved list. That broadcasts what your saved wifi networks are.

                      Does GOS prevent this?

                      • de0u replied to this.

                          yam8449 I know that it has been an issue in the past where when you leave wifi on, an android phone will constantly be looking at wifi around you and checking if there's one in your saved list.

                          A Wi-Fi client device can scan for networks by listening -- transmitting is not necessary, except in the case of hidden networks, because regular access points continuously transmit beacon frames. Because the access points beacon continuously a client can just listen.

                          yam8449 That broadcasts what your saved wifi networks are.

                          Is a source available supporting that claim?

                              I find this research paper from the University of Hamburg quite informative:
                              "Probing for Passwords - Privacy Implications of SSIDs in Probe Requests"

                              Here are a few excerpts from the paper:

                              "In an active discovery, mobile devices broadcast probe requests to find APs they have previously associated with. Active discovery is also required to connect to so-called hidden networks, for which the AP does not advertise the network, i.e., does not send out beacons. Probe requests sent by most modern devices are typically broadcast and contain the empty wildcard in the SSID field. APs receiving a probe request respond with a probe response directed at the sender of the probe request. The probe response contains the SSID of the AP and additional information like supported rates and various capabilities."

                              and later on:

                              "While probe requests sent by devices running older OS might contain SSIDs of one or more APs the device has previously been connected to, newer devices transmit only the SSIDs of hidden networks to improve user privacy and make the device less traceable."

                              Many of the points mentioned in the paper GrapheneOS (MAC randomization, randomization of packet sequence numbers, Wi-Fi and Bluetooth scanning of by default) seems to mitigate but Iā€™m curious to know to what extent a GOS-device is still trackable via other parameters mentioned in the paper:

                              "All the same, various papers still describe how even modern devices can be fingerprinted due to other information contained in them, e. g. in the Information Elements (IE): These non-mandatory parameters contain information on supported rates, network capabilities, and more. Combining the IE parameters, the signal strength and, in some cases, the sequence number, allows to fingerprint individual devices despite MAC address randomization."