I understand that this could potentially be circumvented by providing a cellular network with limited internet access, as discussed in https://github.com/GrapheneOS/os-issue-tracker/issues/4297 . However, the connectivity check implementation could be linked to remote wipe functionality. For instance, if the same domain is used for both connectivity checks and receiving remote wipe commands, it would allow the device to receive or query a remote wipe command even if only the connectivity checking domain is accessible. Care must be taken to ensure that packet size and timing remain consistent to avoid detection and blocking based on side-channel analysis. OHTTP can be incorporated to increase privacy and make device less distinguishable.
This approach offers protection for an unlocked phone that is snatched. For example, an offline device lock could be configured to lock the device after losing connectivity for one hour, which would help mitigate the risk of theft or law enforcement seizing an unlocked phone. Currently, if the phone is unlocked at the time of theft, it is vulnerable, and the auto-reboot feature will not activate and all data is compromised. With this new implementation, the thief or law enforcement would have to choose between blocking the domain, which would cause the device to lock after one hour and trigger the usual auto-reboot, or allowing access to the domain, which could enable a remote wipe at any time, even during active use.
Additionally, this setup could be adjusted to reduce the auto-reboot time. For example, a standard auto-reboot might occur after 18 hours, while an offline device reboot could be set to occur after just 8 hours. If a proxy to the domain is permitted, extending the 8-hour window to 18 hours would also increase the risk of the device being wiped at any point, even within the initial 8 hours.