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.

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?

And Boeing 787 airplanes

Yeah I reboot my iPhone every weekend whether it needs it or not.

also, pretty necessary for the Prism program at the NSA to reinstall and update their firmware

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!

How about a system for rebooting if the phone is not close to a specific Airtag or similar device. Ofc. with the possibility to override by unlocking.

And for minimal hassle if you just hadn’t touched your phone. 12 hours would work great for me.

Create an automation shortcut that reboots your phone every day and you're set.

You can always install Croudstrike. They will take care of reboots. /s

GrapheneOS has this feature but with a configurable time :p

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.

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.

I really enjoy apple ecosystem.

> There is no good reason to force the choice of 72 hours on everybody. That's a user-hostile design decision.

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 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.

It's probably more of a tradeoff.

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).

How is Graphene working for you?

Back in my day, this was a non-issue because our phone batteries didn't last more than 6 hours.

(Although I guess this change applies also to powered-on phones? Which is cool... this is why I choose Apple products.)

[dead]

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.

> If this is true, then it's a trivial enhancement to make that a configurable setting

It could be hard-coded into the Secure Enclave so it can't be disabled if the phone is jailbroken.

I agree, but it sounds like apple is choosing 72 hours to give time for the cops, because cops are more coordinated than criminals?

Making it configurable would be a logical next step

[dead]

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.

There's a good discussion of how this is implemented cryptographically https://www.youtube.com/watch?v=BLGFriOKz6U

> what technical hurdles are stopping Apple from making a locked phone as secure as a rebooted phone

I think the hurdles are not technical, but based around user experience.

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.

What you're asking for is a Harvard architecture computer (as opposed to a von Neumann architecture). There's tradeoffs involved.

Two things to keep in mind are that JITs are damn useful pieces of tech, so losing them is a pretty damn heft price to pay for that separation, and interpreters will still treat your data memory as program instruction memory, which limits the benefit.

What is this a response to? This already happens though - the kernel can't modify its own code pages. But there are plenty remaining attacks like overwriting function pointers or other data.

This is how iOS works already.

I assume that's a Security Research Device. https://security.apple.com/research-device/

I guess not in final release, but security researchers used the developer beta, probably with some verbose mode enabled.

"inactivity reboot" is in the device logs.

https://www.magnetforensics.com/blog/understanding-the-secur...

A memory leak that causes a full-system reboot after exactly 72 hours?

Reverse engineering.

It's quite clear Apple wants /their/ devices connected regularly and you don't have a choice.

- iPhones powering themselves on

- the various defaults on MacOS to connect while sleeping

- the "bugs" in Sequoia on desktop (it refuses to sleep. Tries for a few seconds then turns on the display again, not even locked!)

- the subtle removal of the pulsating light while sleeping to an always on light while sleeping (subtle nudging)

Now with the low power consumption of apple silicon they will easily convince people there is no need to sleep

I fully expect my powered off Mac to turn itself on if it doesn't already do that. I should check that actually...

…are you somehow pressing the power button?

This is a feature. For your security. Also Bluetooth is on when the phone is turned off, for FindMy and remote exploits. /s

I'd like to be able to specify much shorter times than 3 days, I could have my phone reboot every night while sleeping if possible

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.

I just want to point and shame this top-voted comment [0] that dismissed with the characteristic self-assurance of the armchair specialist the very possibility of it; and all the users who upvoted it, purely because it sounded like a “rational opinion”; and all the users who impulsively downvoted my post which provided partial evidence to the contrary.

[0] https://news.ycombinator.com/item?id=42083555

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.

[0] https://www.theverge.com/2020/11/12/21563092/apple-mac-apps-...

They do care. Read carefully the TOS. /s

[flagged]