• General
  • Security of automatically turning Wifi off and on

In the settings, there‘s an option to automatically turn off Wifi once you‘re not connected for a certain amount of time. In theory, I‘d like to enable this, as to my understanding your device scanning for Wifi is something that can be used to track or identify you. In practice, when I enable this, I forget to reenable Wifi when getting home.

There‘s also an option to automatically enable Wifi if you‘re at a specific location. Location services need to be turned on for this to work. If I turn both options on, I‘d automatically have Wifi turned off when not home, but turned on when home.

My current configuration is to have an empty owner profile with pretty much no permissions (including location disabled) and maximized security. Everything I do, I do in specialized User Profiles. Inside of those I also have location services turned off, unless I actually need them to navigate somewhere.

While I can generally tell whether something (like Wifi scanning) is good or bad for security/privacy and why, it‘s often hard for me to judge exactly how bad something is. This makes it hard for me to judge what‘s preferable between two non-perfect options, like this. My question is, whether enabling automatically turning Wifi on and off, in addition to allowing location services in my owner profile, would net increase or decrease my privacy and security. If you have other ideas, feel free to tell me as well:)

    Volatile161 There‘s also an option to automatically enable Wifi if you‘re at a specific location.

    I believe this is known not to work in GrapheneOS at present. I think there may even be a filed issue.

      de0u I believe this is known not to work in GrapheneOS at present

      Oh ok, that‘s that then. Thank you!:)

      TrustExecutor It rrquires acces to some kind of back-end system that compromises privacy.
      Maybe there are some kind of self-hosted option for this?

      There‘s no need for that, it‘s not that important^^ Just wanted to know which of the two options is better.

      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."