> law enforcement officers and forensic experts were concerned that some iPhones were rebooting themselves under mysterious circumstances, which made it harder for them to get access to the devices and extract data.
> iOS 18 comes with improved anti-theft measures. Three days w/o unlock, the iPhone will reboot, preventing thieves from getting your data.
On iPhone, you can use the Shortcuts app to do this. Create a new shortcut with the Restart action and save it. Then go to the Automations tab, set the schedule, and select your new shortcut. Make sure it's set to Run immediately.
I would be ok with 8 hours during daytime, and some smart functionality for sleepy time. After all it’s just a reboot. I can’t remember the last decade I didn’t unlock my phone during the daytime.
Seems like a good defence in depth strategy. These days most systems have a pretty good boot chain security, so after a reboot you know the system is in a valid state and any potential malicious changes have been flushed out.
After reading your comment, I was interested in whether or not I could achieve this through the built-in Shortcuts app. Unfortunately, "Restart" is not an available action.
Edit: Actually, it's under "New Blank Automation" > "Shut Down" > "Restart". Thanks, @jwond!
18h is the default on GrapheneOS IIRC. Got my phone stolen abroad days ago with tones of sensitive data and that features was a big reassurance. I set it to 6h I believe.
If this is true, then it's a trivial enhancement to make that a configurable setting. 72 hours could be the default, if your security needs are higher, you could turn that down to 12 hours, or even less.
If this were configurable, I would make it 30 minutes and increase it if I noticed any inconvenience. But I doubt that I would. I already have my phone in permanent do-not-disturb (so a reboot causing delayed notifications wouldn't be an issue), and it's not like I mind entering my passcode instead of FaceID every 30 minutes.
I don't know where you live, but in the US it's basically understood by the courts that FaceID is not protected, but PIN is.
So if your threat model includes the sort of attacker that has a phone exploit or the ability to confiscate it, you should not be using FaceID. Instead, consider using six digit PIN with auto-delete after 10 attempts. Also enable Lockdown Mode And if you use iCloud, enable Advanced Data Protection.
Yeah, I consider FaceID to be basically a time-limited vulnerability akin to "remember me," because unlocking is a matter of just showing your face. It's convenient and I like it, but I don't get too upset when it asks me to enter a PIN (although I am annoyed when it doesn't respond well to the "swipe up to enter passcode").
I wouldn't assume this is explicitely to help LEO, but more because this is (AFAIK) the first time this is being trialed by Apple. 72 hours is a touch long, IMO (and based on some comments, it's not just me), but when your update touches millions of devices, it's also best to test thoroughly and have the first iteration be too long rather than too short.
It's easy to drop the 72 hours in a future update, or tie a shorter delay to (as I believe Apple calls it) Lockdown Mode - the more important thing might be to keep the "It just works" assumption most people (myself not included) seem to have vis-a-vis Apple products.
Notably, I assume it will never be user-configurable directly. Possibly through Lockdown Mode ("If enabled then shorter delay"), but I wouldn't count on Apple adding an explicit setting.
I get that a locked phone needs to have everything already in memory, but what technical hurdles are stopping Apple from making a locked phone as secure as a rebooted phone?
In the BFU state, notification previews, contact information for incoming calls, and other user-specific data is locked because it’s not decrypted. These things would also change the user experience dramatically, so that’s why Apple doesn’t do it.
This "novel" feature is already supported by GrapheneOS and set to trigger after 18 hours by default, with the option for the user to adjust it to their preference. There is no good reason to force the choice of 72 hours on everybody. That's a user-hostile design decision.
This is an essential feature for my personal GrapheneOS phone. I only tend to use it once or twice a day most days, which means it is usually freshly rebooted every time I go to use it.
I remember reading somewhere that many new exploits in the mobile space only exist in memory and are thwarted by a simple reboot, including the infamous Pegasus spyware.
This longer delay won't prompt hectic headlines about users angry about random reboot, it is long enought so federal agencies won't publicly react and plea Trump for their backdoor again, and it is a low profile update that won't necessarily be noticed beside tech circles thus "small fry" bad actors won't know how to correctly cover their back.
A user hostile design would have been to never implement it in the first place. It's basically Apple's signature to choose generic default value and don't bother the user (for the better and sometimes the worse).
I remember the first time I ever saw the camera flash used as a flashlight was a feature in Cyanogenmod 7. Wifi hotspot from your phone started as a Cydia app, when legitimate apps weren't particularly useful yet.
Hacks have always brought the coolest features to phones, but OEMs have made them less accessible than ever :(
Presumably because they disagree about what should be kept private from whom, and whether the user should be allowed to be in control of the security of the hardware.
Apple will vouch for applications running on, for example, MacOS. They'll check the developer's account is still in good standing, and will prevent apps from launching without this check. Sometimes this (arguably) helps. Other times it hurts [0]. And while I disagree with the choices made, these are valid trade-offs.
Apple will tie things like the hardware for FaceID, to a specific phone, and require it be re-paired by an Apple authorized technician. Sometimes this is bad - just look at any Right to Repair thread. Sometimes this is good - Evil Maid attacks don't occur often, but it's easy enough (from Apple's POV) to block them that it would almost be irresponsible not to.
There is room for these discussions, but it's geared more towards how one views general-purpose computing devices, IMO, and can't really be answered in a flamewar-style "Apple is evil" type of environment.
> iOS 18 comes with improved anti-theft measures. Three days w/o unlock, the iPhone will reboot, preventing thieves from getting your data.
It's poetic, isn't it?
Edit: Actually, it's under "New Blank Automation" > "Shut Down" > "Restart". Thanks, @jwond!
Related Cops suspect iOS 18 iPhones are communicating to force reboots (234 points, 7 days ago, 288 comments) https://news.ycombinator.com/item?id=42081874
So if your threat model includes the sort of attacker that has a phone exploit or the ability to confiscate it, you should not be using FaceID. Instead, consider using six digit PIN with auto-delete after 10 attempts. Also enable Lockdown Mode And if you use iCloud, enable Advanced Data Protection.
But regardless of that.... why does it take a nontrivial amount of power?
It's easy to drop the 72 hours in a future update, or tie a shorter delay to (as I believe Apple calls it) Lockdown Mode - the more important thing might be to keep the "It just works" assumption most people (myself not included) seem to have vis-a-vis Apple products.
Notably, I assume it will never be user-configurable directly. Possibly through Lockdown Mode ("If enabled then shorter delay"), but I wouldn't count on Apple adding an explicit setting.
https://www.magnetforensics.com/blog/understanding-the-secur...
It apparently only triggers if the phone hasn't been successfully unlocked for three days. So, it really isn't something most users will notice.
I remember reading somewhere that many new exploits in the mobile space only exist in memory and are thwarted by a simple reboot, including the infamous Pegasus spyware.
This longer delay won't prompt hectic headlines about users angry about random reboot, it is long enought so federal agencies won't publicly react and plea Trump for their backdoor again, and it is a low profile update that won't necessarily be noticed beside tech circles thus "small fry" bad actors won't know how to correctly cover their back.
A user hostile design would have been to never implement it in the first place. It's basically Apple's signature to choose generic default value and don't bother the user (for the better and sometimes the worse).
(Although I guess this change applies also to powered-on phones? Which is cool... this is why I choose Apple products.)
Hacks have always brought the coolest features to phones, but OEMs have made them less accessible than ever :(
Apple will vouch for applications running on, for example, MacOS. They'll check the developer's account is still in good standing, and will prevent apps from launching without this check. Sometimes this (arguably) helps. Other times it hurts [0]. And while I disagree with the choices made, these are valid trade-offs.
Apple will tie things like the hardware for FaceID, to a specific phone, and require it be re-paired by an Apple authorized technician. Sometimes this is bad - just look at any Right to Repair thread. Sometimes this is good - Evil Maid attacks don't occur often, but it's easy enough (from Apple's POV) to block them that it would almost be irresponsible not to.
There is room for these discussions, but it's geared more towards how one views general-purpose computing devices, IMO, and can't really be answered in a flamewar-style "Apple is evil" type of environment.
[0] https://www.theverge.com/2020/11/12/21563092/apple-mac-apps-...