[Feature Request] Automatic Timeout for Cellular Modem and NFC

gos-users

Hello everyone,

GrapheneOS offers a fantastic feature that automatically disables Wi-Fi and Bluetooth after a user-defined period of inactivity. This is incredibly useful for optimizing security and reducing unnecessary power consumption.

I’ve read that GrapheneOS is planning to extend this functionality to NFC, which would be a great addition.

However, when it comes to disabling the cellular modem, the only current option seems to be enabling Airplane Mode. Alternatively, it’s possible to manually access the testing menu with:
##4636##
and toggling:

Mobile Radio Power: Off
CBRS: Off
Enable DSDS: Off

Unfortunately, this is not persistent. After a reboot, the modem restarts.

Would it be possible to implement an automatic timeout for the cellular modem similar to Wi-Fi and Bluetooth? For instance, if no SIM card is inserted or if the cellular modem is idle for a certain period, it could be disabled automatically.

Additionally, is there any way to permanently disable Mobile Radio Power and NFC without relying on Airplane Mode?

Looking forward to hearing your thoughts and suggestions!

gos-users

PS : Alternatively, if it’s too complicated, having an option to automatically enable Airplane Mode after a set period of inactivity could also solve the issue.

Stephan-P

Could Macrodroid be of help here?
https://macrodroid.com/

Possibly in combination with the Macrodroid helper app
https://www.macrodroidforum.com/index.php?threads/macrodroid-helper-app.8212/
You will need to install this one via adb

gos-users

Stephan-P

All applications not included in the ROM are disabled by default when the device is in Safe Mode. This highlights the importance of disabling the Wi-Fi and Bluetooth stacks during such periods to reduce the risk of network-based attacks.

In the same vein, it would make sense to apply similar logic to the cellular modem. For instance, if no SIM card is present, the modem could be automatically disabled, or the device could switch to Airplane Mode. To reactivate the modem, the user would be required to insert a SIM card and unlock the device.

This approach aligns with the existing functionality to disable the Wi-Fi, Bluetooth, and potentially NFC stacks (as GrapheneOS has mentioned plans for NFC). These stacks require the device to be unlocked to reactivate them, ensuring security by reducing the attack surface in inactive or idle states.

N1b

I think to remember that an automatic airplane mode (or similar features) wouldn't work reliably since apps can and will just constantly access the network and prohibit the automation to trigger. There's simply no "inactivity" because outside of GOS apps are not cut off from the network permission.

Maybe I got this wrong, but the gist of it was "it wouldn't work reliably, and GOS devs are only providing reliable features".

gos-users

Thanks for the explanation! I understand that relying on "inactivity" in the current ecosystem might be unreliable due to apps constantly accessing the network. However, I was thinking about a more user-focused definition of inactivity, such as no screen unlocks or interactions for a defined period.

Could it be possible to trigger Airplane Mode based on this type of inactivity instead? For example:

If the screen has been locked for X minutes and the user hasn't interacted with the device, Airplane Mode could be enabled regardless of network activity.

Additionally, another option could be to automatically enable Airplane Mode if no SIM card is present. This would make sense for devices used without cellular connectivity, such as secondary phones or Wi-Fi-only setups.

I don’t think this would necessarily overlap with the auto-reboot functionality. After all, GrapheneOS already allows Wi-Fi and Bluetooth to be automatically turned off if the device is not connected to a network or a Bluetooth device after X time. Similarly, I don’t see why it wouldn’t be possible to disable the cellular modem or switch to Airplane Mode if no SIM card is detected.

This way, the feature wouldn't depend on app behavior but rather on user actions, device configuration, or inactivity conditions. It could also include a disclaimer informing users about potential limitations. Would that be feasible within GrapheneOS's approach?