Security of automatically turning Wifi off and on

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

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!

Backwards876 AOSP standard clock app alarm works even after auto reboot! But if you snooze during the reboot you will sleep way too long. Ask me how I know that! 😉

TrustExecutor Any app which uses Direct Boot can do that. See https://developer.android.com/training/articles/direct-boot for details.

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.

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.

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?

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