Reverse Engineering iOS 18 Inactivity Reboot

My question is: why three days specifically instead of a user-configurable delay?

Because this way, the delay is parameterized within the Secure Enclave firmware by hard-coding it, which is a thing that only Apple can do.

If you were to allow a user to change it, you'd have to safeguard the channel by which the users' desired delay gets pushed into the SE against malicious use, which is inherently hard because that channel must be writable by the user. Therefore it opens up another attack surface by which the inactivity reboot feature itself might be attacked: if the thief could use an AFU exploit to tell the SE to only trigger the reboot after 300 days, the entire feature becomes useless.

It's not impossible to secure this - after all, changing the login credentials is such a critical channel as well - but it increases the cost to implement this feature significantly, and I can totally see the discussions around this feature coming to the conclusion that a sane, unchangeable default would be the better trade-off here.

> if the thief could use an AFU exploit to tell the SE to only trigger the reboot after 300 days, the entire feature becomes useless

Then why not simply hardcode some fixed modes of operation? Just as an example, a forced choice between 12, 24, 48, or a maximum of 72 hours. You can't cheat your way into convincing the SE to set an unlimited reset timer. I'm sure there must be a better reason.