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)
> But for now, for anyone periodically using the phone, which I bet is most users, the phone will never reboot automatically.
Samsung has an auto-reboot daily feature and has been pushing it a lot (in form of annoying notifications and settings suggestions). In principle, it may not even be a bad idea - but for one fact:
Rebooting the phone effectively turns it off. Until the user unlocks the phone, it won't connect to phone network. AFAIK it also won't start any of the usual background processes that listen to notifications, and it might not even connect to Wi-Fi.
Those "security" measures make automated reboots an useless feature. There really is only one good time to auto-reboot, and that's when the user is sleeping. But no way anyone's doing that when it means their phone won't be able to receive calls. Even during the day, the phone randomly rebooting and remaining disconnected until the user notices - it's probably even worse, and I imagine anyone would disable this feature after first time it activated.
>>Rebooting the phone effectively turns it off. Until the user unlocks the phone, it won't connect to phone network. AFAIK it also won't start any of the usual background processes that listen to notifications,
Well yes, because the storage and all the apps are encrypted until you unlock your phone. So you could have all the apps boot up and start listening for events, but it would be at the cost of reduced security elsewhere. Not sure what the right solution is tbh, I think personally I'd rather have all of my data encrypted even if it means my phone isn't actually "active" after a reboot.
I have a Samsung with this feature. It rebooted overnight and this morning it was in BFU state with several mail and sms notifications. It was also connected to wifi and the cellular network.
It was true for my Galaxy S22, and is currently true with reboots after update. And yes, early on I had a situation where the phone rebooted overnight and remained stuck on the lock screen while disconnected from networks, until I woke up and noticed. Fortunately I didn't miss anything important, but after that I immediately reviewed all settings and disabled anything that could reboot the device automatically (including updates, which are set for manual installation now).
Not never; phones also reboot when there are critical OS updates to apply — and that happens as long as the phone is both charging and locked at any time during a vendor-defined daily maintenance window (usually something like 2AM-4AM in the user's local time.)
This happens even if the user just put the phone to sleep a moment ago. The only way to prevent it is to never leave your phone locked and charging at the same time.
> phones also reboot when there are critical OS updates to apply
Of course, or when they run out of battery, or you drop them too hard, etc. But realistically you could go for weeks or months without a reboot. From a transient fault or malware perspective, that might as well be never.
All that private key nonsense falls in this bucket as well. What else is a private key than an attempt to guard your system behind a thin veil of "an obscure number I know and you don't"? Classic security by obscurity.
Nothing wrong with security by obscurity. It's widely used and it is effective. Security is security. Usually there are easier and more effective methods though, so if it's your only security layer then you might have missed a few things.
The main reasonable criticism would be that it obscures the things you missed from naive audits while still being accessible by an attacker. So you hide the issue from the "good guys" while not baring much entry by the "bad guys". I have seen this pattern emerge many times, because what is obscure to you may not be obscure to someone else. So it /causes/ you to miss things.
Sure they would. If the system was for interactive use, it likely requires some login or unlock password. If the system is supposed to respond to external events - such as receiving phone calls when the system in question is a phone - then a reboot will effectively disable it until the user notices.
All the phones I have used were like this (Samsung, Google, Xiaomi, Redmi, Oppo - across years and years of models).
I am surprised you write that the SIM is locked upon reboot. What does this mean in technical terms? Do you mean that you have to enter the SIM PIN when your phone reboots?
Ah, this is the normal behaviour of a SIM card. You can disable this PIN at startup (a setting in the phone). This is not recommendable, though, because if your phone gets lost or stolen your SIM may be used in a "layer" (a device that will make premium calls or SMS, the name is derived from a hen (that lays eggs)).
The solution is to use an eSIM - you can disable the PIN at bootup because it is protected by the phone lock anyway and will be operational immediately.
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?
What do you mean "planning"? They already are in some places, including Apple Stores themselves. But more often you see iPads in that role with a bigger screen for customers. Are they doing the same behavior? (I don't see why not).
For the moment they have an external payment / card terminal; other than the card reader itself, I don't see why an iphone wouldn't work as a formal payment terminal.
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.
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)
I am using an app for this. It's called WebDavNav+ and there is a free version WebDavNav for evaluation.
You can create sync configurations and switch on auto sync.
I have an Odroid HC4 with Open Media Vault and docker which is my personal NAS. It runs a WebDav container and so on a daily basis my iPhone is backing up photos to my NAS using WebDavNav+.
Thanks! I mean I don't need anything fancy and honestly, I don't want to run a web server (I will if that's what's needed, it's better than this Shortcuts hell). I feel I shouldn't need fancy tools to do some pretty basic things, you know?
I'll be honest, I'm just a bit pissed Apple intentionally handicaps powerusers, and pushes people into their paid solutions. It's one thing to offer a paid solution, it's another thing to create a problem and then sell the solution. I mean just an iCloud backup isn't even good enough. Don't they know 3-2-1?
I see your point. I already had the NAS in place so it was a nobrainer for me, but if you just want to backup to computer you can still run a light webdav server on your computer. For example, I am using dufs [0], which is very easy to deploy and configure.
Yeah shortcuts could be much more useful. I wanted to make a post request when I arrive at some place with some additional javascript logic to update an authentication token. It just doesn’t work when running in the background, I have to manually trigger it
Unfortunately not. Looks like you can set the time (or choose sunrise or sunset), and then you can set it to repeat daily, weekly, or monthly. No option based on inactivity.
However, you can set it to shutdown or reboot if it receives an email that contains a specific string in the subject line. So you could have a computer that sends it a shutdown email. You could base it off of inactivity of that computer, or you could have it listen for a cancel-shutdown email, which could be sent by the iPhone when it connects to WiFi (assuming you don't live someplace like a university campus where you're always connected to WiFi even when you leave home.) If the computer doesn't receive the cancel-shutdown email within the set period of time, the computer would send the shutdown/reboot email to the iPhone.
However, like another commenter pointed out [1], the action doesn't even seem to work currently as of iOS 18.0.1. If you set it to "Run Immediately" with "Notify When Run" to off, it just doesn't run. If you turn "Notify When Run" on, the action runs, but still requires you to confirm it manually with a tap, which defeats the purpose of the automation. Who knows, maybe a future update will fix it.
Just tried it. Unfortunately, even when you choose "Run Immediately", it still asks for user input when the time comes ("Are you sure you want to restart this iPhone?")
Thank you very much. I've wanted to have a weekly reboot of my phone for years now, and it drove me nuts that I couldn't create a shortcuts automation for it.
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 imagine the number of people who don't unlock their iPhones in ≥24 hours is a vanishingly small percentage of the userbase. Especially since with new iPhones, just looking at the lockscreen with your face unobscured is enough to unlock it.
Users that have an iPhone just for work would be affected with a 24h check. Even with 72h they might be affected, but it would be fewer (if you assume they work Fridays and Mondays)
I imagine a vanishingly small percentage of the user base is still a very large number of people, that as an absolute number, would make up a significant percentage of the users of any other product.
Apple’s scale is so large, it’s easy to forget even tiny percentages are still actually really significant in absolute terms.
Your phone knows how often you normally use it. It could do something intelligent based on a usage pattern to restart when there’s an unusually long gap.
I can see this being too hard to explain compared to “reboots after 72 hours.”
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.
I tried to do it using Tasker on my crDroid device, but it requires the phone to be rooted, which mine isn't since some apps detect it and throw a fit.
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.
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?
AFAIK (from observing GOS comm channels) verified boot (alternative OSes but even the mechanism itself since some OEMs customize quite a bit), hardware rate limiting and timely security patches (which include modem firmware, preloaders - i.e. hardware) are the main reasons other devices are not supported.
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 :(
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.
Android Auto works well for me on Graphene (Pixel 9 Pro) but I obv can't make GPay work given that it relies on the OS having Google's blessing and they are actively hostile to GOS as a project.
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 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.
Once you’ve had the PIN scramble turned on for a while, it becomes second nature. I enter my GrapheneOS scrambled PIN about as quickly as the unscrambled PIN on my non‐GrapheneOS work phone. But it’s more of a defense against figuring out my PIN from the finger marks on my screen.
In environments where shoulder surfing is a concern, I prefer to use the multiple profiles feature: log out of my main profile (which is actually a secondary profile) to completely evict its keys from memory, and switch to a burner secondary profile containing no personal data, which unlocks with my fingerprint for convenience.
I had to create a shortcut to actually trigger a reboot, as I couldn’t find a reboot option in settings. My iPhone 13 mini on iOS 17.7.1 took 29 seconds.
I'd love to know what model of iPhone you have a see a video of it shutting down and starting back up in 7 seconds. Sounds like an incredible piece of hardware.
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.
there are public exploits to patch secure enclave code for some of the checkra1n devices. pongoOS uses the blackbird exploit on some models to remove a check that disables access to user data if the SEPOS boot code determines the phone has been DFU booted by checking the hardware TRNG state. https://github.com/checkra1n/PongoOS/blob/master/src/drivers...
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.
Why not just go all the way and separate the program instruction memory from the data memory, physically? I know there’s an approximation of this at the page level, but why even let the kernel modify its own memory in the first place? Memory unit that only loads signed pages. etc.
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.
And here I thought setting up a cronjob to reboot my home AIO router nightly was a good thing, back in the days when I was rocking a WRT54G running OpenWRT; just to clear any lingering socket connections from excessive bittorrent usage.
The young me would sing praise to this feature unconditionally.
The current me can only think how this feature affects countries with proper due process a lot more than countries with easy access to rubber hose decryption.
That being said, the selfish me will adopt this feature either way.
> 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.
Woah, I never cease to be surprised by the unexpected kinds of things that Shortcuts allows (given all the obvious ones it does not). Thank you!
Out of curiosity (and because I'm not going to try that for tomorrow morning) – does that kill my alarms, or does iOS schedule/store these somewhere accessible before first unlock?
iOS alarms continue to work after overnight upgrades which involve a reboot, and also work when you plug in a dead phone before bed, so they’ve apparently figured this out.
I set my work android phone to go off 10pm and come on by 7am everyday. It's under settings -> system. It also has the ability to restart on any day/time you want.
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.
They are forcing reboots, but they aren't communicating with each other to force reboots, as the article was speculating, and as the commenter was arguing against. Instead, it's just a 72-hour clock.
Also, they were calling the networking hypothesis "far fetched" and "pretty unlikely", not "impossible". I had also considered that hypothesis far-fetched, because it wouldn't just need the existence of local communication, it would also need a special protocol, trigger conditions, false-positive prevention, etc., all for that one feature.
The vehement tone was unwarranted and encouraging an attitude of self-assured “common sense” is very problematic, when there are many agents, both commercial and political, who can use it to avoid suspicion about their closed source ecosystems.
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken.
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.
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.
Periodic reboots are actually a PCI requirement for payment terminals heh, basically every point of sale on the market reboots every 24h.
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)
> reboots the phone if it’s not unlocked for 72 hours
Scheduled reboots would help more with clearing malware or transient errors.
But for now, for anyone periodically using the phone, which I bet is most users, the phone will never reboot automatically.
> But for now, for anyone periodically using the phone, which I bet is most users, the phone will never reboot automatically.
Samsung has an auto-reboot daily feature and has been pushing it a lot (in form of annoying notifications and settings suggestions). In principle, it may not even be a bad idea - but for one fact:
Rebooting the phone effectively turns it off. Until the user unlocks the phone, it won't connect to phone network. AFAIK it also won't start any of the usual background processes that listen to notifications, and it might not even connect to Wi-Fi.
Those "security" measures make automated reboots an useless feature. There really is only one good time to auto-reboot, and that's when the user is sleeping. But no way anyone's doing that when it means their phone won't be able to receive calls. Even during the day, the phone randomly rebooting and remaining disconnected until the user notices - it's probably even worse, and I imagine anyone would disable this feature after first time it activated.
>>Rebooting the phone effectively turns it off. Until the user unlocks the phone, it won't connect to phone network. AFAIK it also won't start any of the usual background processes that listen to notifications,
Well yes, because the storage and all the apps are encrypted until you unlock your phone. So you could have all the apps boot up and start listening for events, but it would be at the cost of reduced security elsewhere. Not sure what the right solution is tbh, I think personally I'd rather have all of my data encrypted even if it means my phone isn't actually "active" after a reboot.
> Until the user unlocks the phone, it won't connect to phone network.
This is not true in my case (Samsung Galaxy S22+). The phone is fully operational after a reboot, connected to GSM, 5G and Wi-Fi
I'm not sure this is true.
I have a Samsung with this feature. It rebooted overnight and this morning it was in BFU state with several mail and sms notifications. It was also connected to wifi and the cellular network.
It was true for my Galaxy S22, and is currently true with reboots after update. And yes, early on I had a situation where the phone rebooted overnight and remained stuck on the lock screen while disconnected from networks, until I woke up and noticed. Fortunately I didn't miss anything important, but after that I immediately reviewed all settings and disabled anything that could reboot the device automatically (including updates, which are set for manual installation now).
Not never; phones also reboot when there are critical OS updates to apply — and that happens as long as the phone is both charging and locked at any time during a vendor-defined daily maintenance window (usually something like 2AM-4AM in the user's local time.)
This happens even if the user just put the phone to sleep a moment ago. The only way to prevent it is to never leave your phone locked and charging at the same time.
> phones also reboot when there are critical OS updates to apply
Of course, or when they run out of battery, or you drop them too hard, etc. But realistically you could go for weeks or months without a reboot. From a transient fault or malware perspective, that might as well be never.
"Critical security updates" for iOS come ~weekly.
This is definitely not true. Apple releases security updates about once a month.
True, although for a remote attack there's no reason it can't just be reinfected after the reboot.
Exactly! Especially in a world where systems are under constant attack
But wait for security cargo-culters call it "security by obscurity"
All that private key nonsense falls in this bucket as well. What else is a private key than an attempt to guard your system behind a thin veil of "an obscure number I know and you don't"? Classic security by obscurity.
So everything is security by obscurity?
always has been...
Officially no, as one (or more secrets) are allowed
But given how some "security specialists" behave, I wouldn't put it past them
Nothing wrong with security by obscurity. It's widely used and it is effective. Security is security. Usually there are easier and more effective methods though, so if it's your only security layer then you might have missed a few things.
The main reasonable criticism would be that it obscures the things you missed from naive audits while still being accessible by an attacker. So you hide the issue from the "good guys" while not baring much entry by the "bad guys". I have seen this pattern emerge many times, because what is obscure to you may not be obscure to someone else. So it /causes/ you to miss things.
Sounds like that's just you.
This is so damn sad. I don't fully get why I have to reboot after kernel updates but accept it, but just every 3 days? Why?
Read. It's only when you don't touch it for 3 days. And I bet if you didn't even touch it for 3 days you won't even notice if it has rebooted or not.
Sure they would. If the system was for interactive use, it likely requires some login or unlock password. If the system is supposed to respond to external events - such as receiving phone calls when the system in question is a phone - then a reboot will effectively disable it until the user notices.
Only if you still use a sim pin otherwise the phone would only be unavailable for the duration of the reboot.
No it won't. My phone is completely operational after a reboot.
Yours might. My SIM, however, automatically locks on reboot. It came like that.
All the phones I have used were like this (Samsung, Google, Xiaomi, Redmi, Oppo - across years and years of models).
I am surprised you write that the SIM is locked upon reboot. What does this mean in technical terms? Do you mean that you have to enter the SIM PIN when your phone reboots?
> Do you mean that you have to enter the SIM PIN when your phone reboots?
Yes.
I can cancel the popup and then still use the rest of the phone, but when I do that I have no cellular network access until I unlock the SIM itself.
For the avoidance of confusion, the SIM PIN is independent of the phone PIN.
Ah, this is the normal behaviour of a SIM card. You can disable this PIN at startup (a setting in the phone). This is not recommendable, though, because if your phone gets lost or stolen your SIM may be used in a "layer" (a device that will make premium calls or SMS, the name is derived from a hen (that lays eggs)).
The solution is to use an eSIM - you can disable the PIN at bootup because it is protected by the phone lock anyway and will be operational immediately.
> receiving phone calls
don't be ridiculous, it's a _smart_ phone.
How do you expect to swap out your kernel without restarting your machine?
Don't know about apple, but on linux you can live patch a running kernel with security updates (kpatch/ksplice/...).
Right, which means that an attacker can trick your kernel into patching itself to do something malicious.
And automatic periodical reboots give hackers the piece they were missing. :)
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?
Isn’t Apple planning on turning iPhones into POS (point of sale) terminals?
What do you mean "planning"? They already are in some places, including Apple Stores themselves. But more often you see iPads in that role with a bigger screen for customers. Are they doing the same behavior? (I don't see why not).
For the moment they have an external payment / card terminal; other than the card reader itself, I don't see why an iphone wouldn't work as a formal payment terminal.
It already does.
Part of the new PCI standard called "Software based PIN entry on COTS" [1] which is also known generically as "PIN on glass".
Banks are now offering it to one-person trade companies etc [2].
[1] https://blog.pcisecuritystandards.org/new-faqs-on-software-b...
[2] https://www.westpac.com.au/business-banking/merchants-and-pa...
And Boeing 787 airplanes
Shouldn’t happen mid-flight though
Would interrupt my movie.
Yeah I reboot my iPhone every weekend whether it needs it or not.
[dead]
also, pretty necessary for the Prism program at the NSA to reinstall and update their firmware
Wish this could be reduced lower. If I don’t unlock my phone in a day, something is up and extra paranoia is warranted.
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.
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.
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
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)I am using an app for this. It's called WebDavNav+ and there is a free version WebDavNav for evaluation.
You can create sync configurations and switch on auto sync.
I have an Odroid HC4 with Open Media Vault and docker which is my personal NAS. It runs a WebDav container and so on a daily basis my iPhone is backing up photos to my NAS using WebDavNav+.
Thanks! I mean I don't need anything fancy and honestly, I don't want to run a web server (I will if that's what's needed, it's better than this Shortcuts hell). I feel I shouldn't need fancy tools to do some pretty basic things, you know?
I'll be honest, I'm just a bit pissed Apple intentionally handicaps powerusers, and pushes people into their paid solutions. It's one thing to offer a paid solution, it's another thing to create a problem and then sell the solution. I mean just an iCloud backup isn't even good enough. Don't they know 3-2-1?
I see your point. I already had the NAS in place so it was a nobrainer for me, but if you just want to backup to computer you can still run a light webdav server on your computer. For example, I am using dufs [0], which is very easy to deploy and configure.
[0] https://github.com/sigoden/dufs
It’s so frustrating having a nice Shortcut idea just to hit a limitation right away.
Yeah shortcuts could be much more useful. I wanted to make a post request when I arrive at some place with some additional javascript logic to update an authentication token. It just doesn’t work when running in the background, I have to manually trigger it
But can you have it run a fixed period of time after last using your phone?
Unfortunately not. Looks like you can set the time (or choose sunrise or sunset), and then you can set it to repeat daily, weekly, or monthly. No option based on inactivity.
However, you can set it to shutdown or reboot if it receives an email that contains a specific string in the subject line. So you could have a computer that sends it a shutdown email. You could base it off of inactivity of that computer, or you could have it listen for a cancel-shutdown email, which could be sent by the iPhone when it connects to WiFi (assuming you don't live someplace like a university campus where you're always connected to WiFi even when you leave home.) If the computer doesn't receive the cancel-shutdown email within the set period of time, the computer would send the shutdown/reboot email to the iPhone.
However, like another commenter pointed out [1], the action doesn't even seem to work currently as of iOS 18.0.1. If you set it to "Run Immediately" with "Notify When Run" to off, it just doesn't run. If you turn "Notify When Run" on, the action runs, but still requires you to confirm it manually with a tap, which defeats the purpose of the automation. Who knows, maybe a future update will fix it.
1. https://news.ycombinator.com/item?id=42144044
There is a restart action. You need to first add the Shut Down action, then you can change it to Restart.
Just tried it. Unfortunately, even when you choose "Run Immediately", it still asks for user input when the time comes ("Are you sure you want to restart this iPhone?")
I have had my phone set to reboot every day at sunrise and have had no issues with it prompting for input in weeks.
Thank you very much. I've wanted to have a weekly reboot of my phone for years now, and it drove me nuts that I couldn't create a shortcuts automation for it.
Nice! Just created an automation to restart daily at 4:00am. Hopefully it works without user input.
I'm so dumb. I didn't even click into the "Blank Actions" tile.
I created a shortcut to turn off my iPad every night. It’s useless
Create an automation shortcut that reboots your phone every day and you're set.
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'm one of those people. I charge my phone once a week. Most of my interaction with it is notifications on the lock screen.
I imagine the number of people who don't unlock their iPhones in ≥24 hours is a vanishingly small percentage of the userbase. Especially since with new iPhones, just looking at the lockscreen with your face unobscured is enough to unlock it.
Users that have an iPhone just for work would be affected with a 24h check. Even with 72h they might be affected, but it would be fewer (if you assume they work Fridays and Mondays)
I imagine a vanishingly small percentage of the user base is still a very large number of people, that as an absolute number, would make up a significant percentage of the users of any other product.
Apple’s scale is so large, it’s easy to forget even tiny percentages are still actually really significant in absolute terms.
Your phone knows how often you normally use it. It could do something intelligent based on a usage pattern to restart when there’s an unusually long gap.
I can see this being too hard to explain compared to “reboots after 72 hours.”
And for minimal hassle if you just hadn’t touched your phone. 12 hours would work great for me.
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.
I tried to do it using Tasker on my crDroid device, but it requires the phone to be rooted, which mine isn't since some apps detect it and throw a fit.
I think you may be able to do something like this with a shortcut.
Iirc reboot requires user input so you can’t automate.
Yep. I tried to do it with a shortcut and it was basically a reminder to reboot that could be ignored.
GrapheneOS has this feature but with a configurable time :p
You can always install Croudstrike. They will take care of reboots. /s
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.
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.
> 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.
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?
Graphene might be great, but the Google specific hardware that is the only thing it will run on might not be as trustworthy.
Graphene is not limited to Google hardware, it's just that Google hardware meets their hardware requirements... (https://grapheneos.org/faq#future-devices).
AFAIK (from observing GOS comm channels) verified boot (alternative OSes but even the mechanism itself since some OEMs customize quite a bit), hardware rate limiting and timely security patches (which include modem firmware, preloaders - i.e. hardware) are the main reasons other devices are not supported.
It is limited at moment to just pixel!
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).
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 :(
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.)
How is Graphene working for you?
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.
I have been meaning to try it. Is it best to get a new phone, or will any old model work fine?
You absolutely want a somewhat modern Pixel
https://grapheneos.org/faq#device-support
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.
GrapheneOS is great. I’m on iOS 18 for now (until I get a new Pixel after I got one stolen days ago) and I can’t wait to go back to GrapheneOS.
Not OP, but very well!! The only things that don't work for me are Google Pay and Android Auto, which is a shame but I can live without both of those.
GrapheneOS supports Android Auto now! I use it every day.
Android Auto works well for me on Graphene (Pixel 9 Pro) but I obv can't make GPay work given that it relies on the OS having Google's blessing and they are actively hostile to GOS as a project.
Auto absolutely works these days but Google Pay definitely doesn't and probably won't ever
That kinda sucks. I don’t carry cash or a credit card anymore. I just pay with my phone.
Upgrade. Auto is supported now.
[dead]
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").
Speaking of Face ID, I still use the iPhone SE (latest edition).
I like Touch ID and I like the small form factor.
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.
If you're outside the house that's less secure, because a security camera or a shoulder surfer can see your PIN.
Agreed. I don’t understand how someone would be careful to not use biometrics and yet use a six digit passcode instead of an alphanumeric password.
Graphene has a feature exactly for this which shows a shuffled unlock screen
This sounds like an excellent way to make it even easier for people to watch you enter your PIN.
Once you’ve had the PIN scramble turned on for a while, it becomes second nature. I enter my GrapheneOS scrambled PIN about as quickly as the unscrambled PIN on my non‐GrapheneOS work phone. But it’s more of a defense against figuring out my PIN from the finger marks on my screen.
In environments where shoulder surfing is a concern, I prefer to use the multiple profiles feature: log out of my main profile (which is actually a secondary profile) to completely evict its keys from memory, and switch to a burner secondary profile containing no personal data, which unlocks with my fingerprint for convenience.
30 minutes would be excessive. Keep in mind that the phone is unusable while it's rebooting, and that rebooting uses a nontrivial amount of power.
Also you cannot read your notifications, if I am not wrong.
I think 3 days is actually perfect
Rebooting takes ~7 seconds and ideally only happens when I attempt to use it.
But regardless of that.... why does it take a nontrivial amount of power?
Because booting is relatively CPU-intensive, compared to being at idle.
But iPhones do not boot in 7 seconds either — it's closer to 40. At least that's what it took on my 16 Pro Max right now when I tested it.
My iphone 15 just rebooted in 12 seconds.
Rebooted or turned on?
I had to create a shortcut to actually trigger a reboot, as I couldn’t find a reboot option in settings. My iPhone 13 mini on iOS 17.7.1 took 29 seconds.
I'd love to know what model of iPhone you have a see a video of it shutting down and starting back up in 7 seconds. Sounds like an incredible piece of hardware.
wow. that's quick. my two year old galaxy takes ~37 seconds.
I agree, but it sounds like apple is choosing 72 hours to give time for the cops, because cops are more coordinated than criminals?
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’m assuming the ability to configure this will be added to Apple Configurator at some point.
Any savvy user can download it for free. I used it recently to create a profile for a friend I’m working with to configure their email account.
If you’re the tech person for your friends and family, Apple Configurator is quite handy: https://support.apple.com/guide/apple-configurator-mac/intro...
I’m betting it’ll be configurable via MDM.
No because 3 days is about the timeframe a phone would survive without recharging and without confusing the masses why things stopped working
A balance between security and giving law enforcement a reasonable window to act
It could just be for the user experience.
There are people I know especially older who don't use their phone every day.
> 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.
A sufficiently powerful jailbreak would be able to override that.
Not aware of anyone being able to patch the Secure Enclave code to date.
there are public exploits to patch secure enclave code for some of the checkra1n devices. pongoOS uses the blackbird exploit on some models to remove a check that disables access to user data if the SEPOS boot code determines the phone has been DFU booted by checking the hardware TRNG state. https://github.com/checkra1n/PongoOS/blob/master/src/drivers...
Making it configurable would be a logical next step
[dead]
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.
> 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.
There's a good discussion of how this is implemented cryptographically https://www.youtube.com/watch?v=BLGFriOKz6U
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.
https://www.404media.co/apple-quietly-introduced-iphone-rebo...
Why not just go all the way and separate the program instruction memory from the data memory, physically? I know there’s an approximation of this at the page level, but why even let the kernel modify its own memory in the first place? Memory unit that only loads signed pages. etc.
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.
And here I thought setting up a cronjob to reboot my home AIO router nightly was a good thing, back in the days when I was rocking a WRT54G running OpenWRT; just to clear any lingering socket connections from excessive bittorrent usage.
The young me would sing praise to this feature unconditionally.
The current me can only think how this feature affects countries with proper due process a lot more than countries with easy access to rubber hose decryption.
That being said, the selfish me will adopt this feature either way.
Question: is the apple reboot seriously displaying a dmesg log?
I assume that's a Security Research Device. https://security.apple.com/research-device/
It is. You can see a SRD screen pop up briefly before the boot messages.
I guess not in final release, but security researchers used the developer beta, probably with some verbose mode enabled.
Wonder how they've determined it's a deliberate feature and not some memory leak or something that takes 72 hours to manifest.
"inactivity reboot" is in the device logs.
https://www.magnetforensics.com/blog/understanding-the-secur...
> While Apple has a great set of documentation around their security features
lol I wish
Reverse engineering.
A memory leak that causes a full-system reboot after exactly 72 hours?
A very finely tuned memory leak.
Sometimes when I turn off my iPhone for a while, it turns on by itself.
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
> 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.
It's poetic, isn't it?
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
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.
Woah, I never cease to be surprised by the unexpected kinds of things that Shortcuts allows (given all the obvious ones it does not). Thank you!
Out of curiosity (and because I'm not going to try that for tomorrow morning) – does that kill my alarms, or does iOS schedule/store these somewhere accessible before first unlock?
iOS alarms continue to work after overnight upgrades which involve a reboot, and also work when you plug in a dead phone before bed, so they’ve apparently figured this out.
AFAIK there's (private?) API surface to request a container that isn't encrypted to your PIN specifically for the lock screen to work.
It’s actually pretty powerful and you can have automation tigger based on all sorts of things.
I travel a lot so have it turn on specific data SIMs when GPS detects I’m in that country.
This leads to a confirmation prompt, and unless you select "Restart" it does nothing. Do you know a way around that?
The “run immediately” setting mentioned in the parent comments prevents this. I did this recently on my phone and can confirm it works.
Not for me, unfortunately.
Why could this be? latest iOS? Regional difference?
I set my work android phone to go off 10pm and come on by 7am everyday. It's under settings -> system. It also has the ability to restart on any day/time you want.
Very good suggestion, however I’m not sure if it’s healthy for a phone to reboot 365d/year?
Why not?
Because it's healthy to take some days off
Maybe it should reboot every day for 5 days and then not reboot for 2 days.
Of course, that would be week security.
/ducks
Eh hem... 4 day work weeks are more productive so not rebooting for 3 days should be even weeker.
> Very good suggestion, however I’m not sure if it’s healthy for a phone to reboot 365d/year?
There is no (Windows) problem that a reboot cannot fix. /s
my 2021 samsung can do that
but my new pixel cannot
Just tested on my pixel:
Go to Settings
Tap on System
Select "Advanced."
Tap on "Scheduled restart."
Toggle the switch to enable it.
Choose the day and time you want your device to restart automatically.
Suppose all police would just undo that setting as soon as they got the phone.
Can’t do that when the phone is locked. If they can do that, they’re “in” and it will take them less than a day to take all data from the phone.
The point is that they don't have the passcode so they couldn't.
I have no "Advanced".
That’s why you gotta run graphene
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.
what about my Apple Watch?
Previously (36 points, 6 days ago, 24 comments) https://news.ycombinator.com/item?id=42090636
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
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
They are forcing reboots, but they aren't communicating with each other to force reboots, as the article was speculating, and as the commenter was arguing against. Instead, it's just a 72-hour clock.
Also, they were calling the networking hypothesis "far fetched" and "pretty unlikely", not "impossible". I had also considered that hypothesis far-fetched, because it wouldn't just need the existence of local communication, it would also need a special protocol, trigger conditions, false-positive prevention, etc., all for that one feature.
Don't be petty, it's not good for you. Besides, as is, their comment is still accurate and a great addition to the discussion.
The vehement tone was unwarranted and encouraging an attitude of self-assured “common sense” is very problematic, when there are many agents, both commercial and political, who can use it to avoid suspicion about their closed source ecosystems.
From the HN guidelines [0]:
> Please don't post insinuations about astroturfing, shilling, brigading, foreign agents, and the like. It degrades discussion and is usually mistaken.
[0] https://news.ycombinator.com/newsguidelines.html
[dead]
It annoys me to no end to listen to the Android/Google apologists claim that Apple does not care about security and privacy.
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]
[flagged]
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.
I just tried on my S23+ and no, I don't get any app notification, I need to enter the pin code for that.
My S22 Ultra also does not display notifications after reboot until after login with pin.