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.
Probably also helps with other kinds of transient hardware faults (and cosmic-rays) that can cause bitflips.
That said, on principle, there is no reason why ECC RAM should not be the standard (c.f. Linus Torvald’s ire at Intel using ECC as a market-segmentation ploy)
The fact that Apple is adopting a similar approach for iPhones, is pretty much in line with that idea, just applied to personal data protection, isn't it?
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, I was looking in the wrong place. It’s an option for the "Shut Down” action. Thanks, @jwond!
While we're on the topic of Shortcuts, does anyone know how to do decent data transfer? I've been wracking my head to figure out how to replace my termux script on Android that would sync photos to my home computer whenever I was on my local wifi (or wifi and tailscale).
I know shortcuts has an ssh action but it appears quite buggy and if I try to do any real bash scripting or wanting to not overwrite existing backups it hangs. It doesn't handle
[[ ! -a "$FILE" ]] && cat /dev/stdin "$FILE"
Even with more formal if statement notation. Best I have come up with is a very painful shortcut that repeats this for each thing I want to sync
if [[ ! -a "$FILE" ]];
then
cat /dev/stdin "$FILE"
else
cat /dev/stdin /dev/null
fi
Seems to hate functions. iSH and others can't seem to access the photos library. There's got to be some way I can get those out of the sandbox. (God damn is the app buggy. This is worse than programming in brainfuck)
Find My already gives notifications when a device gets separated from your other mobile devices including Airtags. Apple could add extra actions on top of that to automatically mark as lost, reboot, or erase.
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.
Your shortcut likely isn’t working. I tried it, but it didn’t reboot at the scheduled time. It briefly turned on to show a dialog asking for confirmation, but since it was unattended, no one approved it, so it never restarted. You can confirm it’s failing by scheduling it to go off while you’re there, or download a System Status app that shows boot time.
My guess would be that the three-day timer is the first version to test the waters. Put it out there to see if there are any unexpected problems. And if everything's peachy, lower it in some future release to make it more secure.
If they went with something more aggressive (like 24 hours) it might annoy more users, especially those who keep their phones locked for a while but don't use them constantly
I am almost never use my phone at home anymore. And even when I leave home for gym or stuff like that, I will have my phone with me, but will interact most of the time with the apple watch. The only few times I will actually use the phone is to answer some urgent message.
For lazy reading and media consumption I will use the ipad.
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.
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 :(
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.
I am curious why you feel this is an "essential" feature. If you only use your phone once or twice a day, why would a hypothetical attacker bother targeting it?
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).
Not OP. But I am using GrapheneOS for almost 4 months now. It is a breath of fresh air. Network Permission, Contact Scope, Duress PIN, Hardened Malloc, JIT tuning, Sandboxed Google Play etc.. are some key privacy and security features in Graphene. Will never go back to Apple's or Google's surveillance platforms.
Not OP either. It's quite "buggy" (honestly too many to list, mostly UI issues, app issues that can either be attributed to the OS or the app)...but overall I'm happy because of all the great features.
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.
I don't trust FaceID (technically, I don' trust the cops with FaceID), so I'm entering my (6 digit) PIN every time I take my phone out of my pocket anyway. The only thing that'd make me hesitate to set this down to single digit minutes would be the risk of missed calls/notifications while the phone reboots.
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.
This seems to break SMS-forwarding between iDevices. Found out the hard way when some package delivery notifications only arrived once I unlocked my secondary iPhone and opened the Messaging-app.
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.
I think 404Media was first to confirm this (I could be wrong). It’s a subscriber article and I couldn’t find an archive link with the full story, but they do good work and I encourage people to support their work.
It doesn't do the same thing security-wise, though. It's more of a "performance manager" (i.e. the same reason you'd reboot an old Windows PC).
BFU (Before First Unlock, as described in the article) on an Android is pretty similar to an iPhone (data still locked down, notifs don't come in, apps not running). Only after you unlock the first time can apps start running and notifs come in. This is also the state where it's more vulnerable to attackers (cops or criminals).
I have both an iPhone and an Android (currently a Z Fold 5, so a recent model). My Fold 5 does this auto-reboot every week. When it does reboot, my usual background apps come up, and notifs work as usual.
This means that Android (or perhaps more accurately, OneUI — Samsung's custom stuff on top of Android) is not doing a "full" reboot, and thus isn't providing the same security benefits as Apple is by putting the phone in a "BFU" or "cold" state.
That said, on principle, there is no reason why ECC RAM should not be the standard (c.f. Linus Torvald’s ire at Intel using ECC as a market-segmentation ploy)
Deleted Comment
Dead Comment
Edit: Actually, I was looking in the wrong place. It’s an option for the "Shut Down” action. Thanks, @jwond!
I know shortcuts has an ssh action but it appears quite buggy and if I try to do any real bash scripting or wanting to not overwrite existing backups it hangs. It doesn't handle
Even with more formal if statement notation. Best I have come up with is a very painful shortcut that repeats this for each thing I want to sync Seems to hate functions. iSH and others can't seem to access the photos library. There's got to be some way I can get those out of the sandbox. (God damn is the app buggy. This is worse than programming in brainfuck)For lazy reading and media consumption I will use the ipad.
I really enjoy apple ecosystem.
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.
Hacks have always brought the coolest features to phones, but OEMs have made them less accessible than ever :(
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.)
Dead Comment
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.
I like Touch ID and I like the small form factor.
It could be hard-coded into the Secure Enclave so it can't be disabled if the phone is jailbroken.
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.
There are people I know especially older who don't use their phone every day.
Dead Comment
I think the hurdles are not technical, but based around user experience.
Deleted Comment
https://www.404media.co/apple-quietly-introduced-iphone-rebo...
BFU (Before First Unlock, as described in the article) on an Android is pretty similar to an iPhone (data still locked down, notifs don't come in, apps not running). Only after you unlock the first time can apps start running and notifs come in. This is also the state where it's more vulnerable to attackers (cops or criminals).
I have both an iPhone and an Android (currently a Z Fold 5, so a recent model). My Fold 5 does this auto-reboot every week. When it does reboot, my usual background apps come up, and notifs work as usual.
This means that Android (or perhaps more accurately, OneUI — Samsung's custom stuff on top of Android) is not doing a "full" reboot, and thus isn't providing the same security benefits as Apple is by putting the phone in a "BFU" or "cold" state.