KleinesSinchen Sounds interesting. Though a false positive would make me miss the bus (reboot takes way too long to open the ticket app). A feature for locking on snatching is planned as far as I know.
the issue with AFU locking is the device is still vulnerable to 0days. I'd suggest having a option to choose between normal lock and reboot. But any such feature is welcome.
KleinesSinchen There is an unmaintained app that locks based on sensor data: Private Lock. It is using device administrator privileges and has a low target API. ← Both probably not well-received here.
3rd party apps are risky in both attack surface and also that they probably don't have GrapheneOS' security standards. What if the app itself is vulnerable?
KleinesSinchen Doesn't remote access add new attack surface?
Yes, which is why I said to not share any device personal info to the attacker, and only allow very limited functionality, like make siren or reboot. I think if the functionality is kept to a minimum, GOS devs can securely implement this.
KleinesSinchen f it is a known exploit, the known vulnerability should be patched.
for example, if a known vulnerability is attempted, then we can infer that the device attempting it is not for any good and immediately block the device giving them no chance to try and find unknown vulnerability. It is of course not bulletproof, but this is another friction point, or trap that adversaries have to be careful not to trip, making their work harder and therefore deterring them from doing for less serious cases. My opinion is to put as much as friction between adversaries targeting a device that they are deterred from doing so most of the cases. I also suggest logging these attempts such that it can be used as evidence if someone illegally tried to hack the device.