For those who don't know, automatic reboot restarts your device if you haven't unlocked it in a set amount of time. Cellebrite and other digital forensics companies are able to get into AFU devices much more often. The automatic reboot feature was first introduced by GrapheneOS and was later added to iOS and stock Pixels.<p>GrapheneOS's default is 18 hours and it can be set to between 10 minutes and 72 hours. iPhones and Stock pixels have it non customizable at 72 hours.<p>On GrapheneOS, for privacy and convenience, it's best to use a long random passphrase [1] for your primary unlock and then a fingerprint with a second factor pin as the secondary unlock. You enter the passphrase every time the device restarts.<p>If you're encountering someone that's going to seize your phone, try to restart/shut it down yourself so you don't have to trust the AFU protections.<p>[1] <a href="https://strongphrase.net" rel="nofollow">https://strongphrase.net</a> give memorable ones which is cool.
Never use a website to generate a password for something important like this. You can print out diceware passwords and roll dice.
> On GrapheneOS, for privacy and convenience, it's best to use a long random passphrase<p>Why do you call out just one OS? It's a good idea for any OS.
This seems specific to GrapheneOS (unique as far as I know though I'd be happy to learn otherwise) where you could set a very long first unlock passphrase and have a shorter less cumbersome fingerprint plus pin option for subsequent unlocks. I wouldn't want to have to enter a long passphrase every time I unlock but once a day isn't so bad.
I don't run GrapheneOS, but I have an >15 character passphrase that must be used before biometrics can be used after reboot. I haven't used a 4-digit pin since the option to not use it was available.
The option was there in Cyanogenmod back during the OnePlus One days. It was such a step backwards when it was removed. You almost had to wonder if it was deliberately done at the request of some TLA to prevent users from using too strong of a password for decryption.
Yes, in fact on GrapheneOS it's less necessary and it's only necessary if you don't want to rely on the secure element rate limiting.<p>GrapheneOS allows using a passphrase with more convenience because of the fingerprint plus second factor pin (I don't think you can just have a pin as a secondary unlock). You don't need to enter the passphrase every time you unlock with this setup, only when first starting up.<p>The official opinion: <a href="https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=by%3Agrapheneos%20passphrase%20rate%20limit&sort=byDate&type=comment" rel="nofollow">https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...</a>
People believed the reboot feature last time GrapheneOS was mentioned. It is of course nonsense.<p>Shut down the phone in areas with a high snatch risk. That means <i>during landing</i> for example, because the aircraft can be boarded covertly if on the ground.
> Shut down the phone in areas with a high snatch risk.<p>Yes this is of course safer. What evidence do you have that it doesn't work on GrapheneOS, though?<p><a href="https://www.computerweekly.com/feature/Journalist-Richard-Medhurst-had-his-mobile-phone-seized-Did-using-a-secure-phone-protect-his-data" rel="nofollow">https://www.computerweekly.com/feature/Journalist-Richard-Me...</a>
To add an extra layer of safety. Bring a secondary phone when travelling by airplanes, especially to other countries. You should also use it frequently, maybe with some side apps to make it look like it's your daily phone.
Or, just don't bring a phone if you're particularly vulnerable. What are they going to do? Deny you entry because you don't carry a phone? If we're really at that point, where merely not having some item is suspicious, we're in deep shit.
The internet exists and can transfer your data with no customs and borders, so if you are at risk of being <i>snatched</i>, the correct choice is to not carry a phone (or laptop, or..) at all.
<a href="https://en.wikipedia.org/wiki/Great_Firewall" rel="nofollow">https://en.wikipedia.org/wiki/Great_Firewall</a>:<p><i>“The Great Firewall operates by checking transmission control protocol (TCP) packets for keywords or sensitive words. If the keywords or sensitive words appear in the TCP packets, access will be closed. If one link is closed, more links from the same machine will be blocked by the Great Firewall. The effect includes: limiting access to foreign information sources, blocking popular foreign websites and mobile apps, and requiring foreign companies to adapt to domestic regulations. Due to the Great Firewall, China has one of the lowest cross-border internet traffic rates in the world. Usage of foreign apps in China is minuscule; Asia Society estimated in 2026 that foreign apps blocked by the Great Firewall have extremely low traffic, particularly compared to domestic apps; the top five domestic apps saw traffic that was 1,000 times more than the top five foreign apps.”</i>
I keep all of my most sensitive personal documents on my phone, as an emergency backup, but in an encrypted (Cryptomator) volume that requires a separate password. Given the routine news of such exploits this seems like due diligence.<p>As I understand it this encryption is a significant additional barrier to technical or legal access to those files. If someone knows otherwise, please let me know. Being wrong could cost me my home and life savings.
If you don't give access to law enforcement when they ask: straight to jail. Encryption is irrelevant in that situation. If they see the encrypted volume you need to provide them access.
Maybe in a country like the UK, but not in the US. The Fifth Amendment protects against self-incrimination.<p>Which covers divulging encryption keys because it is treated the same as compelling you to give up the combination to a wall safe which is testimonial and protected.
That's been my understanding until now as well... the latest on the case against Samuel Tunick has me worried and second guessing that blanket statement though...<p><a href="https://nccriminallaw.sog.unc.edu/2026/08/03/giving-police-a-duress-code-instead-of-a-passcode-to-a-phone/" rel="nofollow">https://nccriminallaw.sog.unc.edu/2026/08/03/giving-police-a...</a>
Yeah, if you use it as a way to destroy data that gives them a whole new and powerful attack vector. 18 U.S.C. § 2232 is very broad.
That's completely different. Pleading the 5th and not testifying is completely different from giving false testimony - which is <i>never</i> protected. Even in a trial, if you are asked under oath if you handled the body, you are allowed to say that you invoke your 5th amendment rights not to respond; but you are <i>not</i> allowed to say "no, I didn't" if in fact you did (you can later be accused of perjury in addition to your conviction).
> The Fifth Amendment protects against self-incrimination.<p>You can still be held in custody for obstruction of justice:<p><a href="https://www.findlaw.com/legalblogs/third-circuit/man-held-in-contempt-for-refusing-to-unlock-devices-in-child-porn-case/" rel="nofollow">https://www.findlaw.com/legalblogs/third-circuit/man-held-in...</a><p>It took four years before he could secure his release:<p><a href="https://www.sophos.com/en-us/blog/suspect-who-refused-to-decrypt-hard-drives-released-after-four-years" rel="nofollow">https://www.sophos.com/en-us/blog/suspect-who-refused-to-dec...</a>
Self-incrimination yes, but not for cases when the person compelled has evidence to incriminate another process in a case.
Classic $5 wrench.<p>Having thugs on speed dial opens a lot of doors.
So if an app installs an encrypted volume for which you don't have the password to, you go to jail? That doesn't make sense. How can they know if I have the password or not
They can't know, they infer. AFAIU, normally they just detain you at the airport and harass you to try to break you. To jail you they're technically supposed to be confident enough about you knowing the password to be able to charge you with a crime (presumably something like obstruction, possibly specific to immigration law, otherwise right against self-incrimination might prevent a conviction on failure to disclose alone), or have other evidence of some other crime. Then you end up in the legal system, where courts handle due process and a judge, preliminarily, and then a judge or jury decides if you knew the password.<p>Note that the recent high-profile case of a man being jailed involved him refusing to decrypt, rather than claiming he didn't know. He was deliberately trying to test the law regarding the permissible scope of inspection of digital data, to force the matter into the courts so the issues could be litigated in a controlled context untainted by other potential crimes; being arrested and charged was part of his plan.
It would seem wise to at least keep a backup in an E2EE cloud [1]. This could possibly allow you to not give access even if legally compelled.<p>>As I understand it this encryption is a significant additional barrier to technical or legal access to those files. If someone knows otherwise, please let me know. Being wrong could cost me my home and life savings.<p>Yes, it seems that way in the US: <a href="https://news.ycombinator.com/item?id=49922513">https://news.ycombinator.com/item?id=49922513</a><p>If your threat model includes someone using violence to coerce you, an option could be to use a cloud storage account entirely over Tor from the browser (preferably download the app because of web cryptography risks) with the login memorized. That way you can access it on any computer even if yours is lost and you can remove traces of it from your phone.<p>[1] <a href="https://www.privacyguides.org/en/cloud/" rel="nofollow">https://www.privacyguides.org/en/cloud/</a>
If you travel abroad you must unlock. No 4th amendment for you.
It seems foolhardy to carry your life savings around everywhere, encrypted or not.<p>If you really want to keep this stuff on a phone at least stretch to a second phone and keep it somewhere safe.
It seems to me you are taking a big risk. Some considerations:<p>> Cryptomator<p>Much security is poorly implemented; you can't count on it being effective. Even Apple, which takes security very seriously and has world-class talent and enormous resources, fails to implement security effectively sometimes (as in the OP). Can Cryptomator do better? Find the most respected - by professionals - security solution you can.<p>And on a device with many other functions - all the things you use your phone for - you risk all sorts of security holes in every function of app you use. And what happens to the data when your phone is backed up? Store the data on a single-purpose device.<p>Also, on an Internet-connected device, you make the data potentially accessible to the entire Internet. Use offline storage.<p>Bringing the storage device with you everywhere is asking for a mistake on your part - losing it, etc. Hide it someplace.<p>> or legal access<p>Ask a lawyer.
> The idea behind this so-called “inactivity reboot” is to revert the phone to a state that makes it harder for police to break into the device, and thus extract sensitive data from it with forensics technology.<p>This is weird framing. The feature makes it harder for <i>anyone</i> to break into the device.
Not weird, not <i>anyone</i> can buy those equipment to break into a fully updated phone, in fact, it’s pretty much only law enforcement can or will have access to them, so that statement is true, it will make it harder for police to do so.
Huh, so this is essentially very similar be what this guy said to my suggestion of a factory reset timer in GrapheneOS being flawed. Apple's implementation of the reboot timer is flawed.<p>This goes to show for all the people that want GrapheneOS to implement a feature like hidden profiles–flawed features give people a false sense of security and should not be implemented (that's not to mention deniability may not even be a good feature if it was technically possible to implement it well).<p>Me:<p>>What about a duress timer working as the reboot timer but it wipes if you don't unlock within the time period. Would that have any advantages for destruction of evidence or deniability?<p>HybridStatAnim8:<p>>That would not be viable because the hardware does not support it. It cannot be implemented in the OS because the OS can be turned off or exploited endlessly.
For GOS to consider it, it would likely need to be backed by the secure element.<p>>Duress PIN is deemed acceptable to implement in the OS because it is expected that the user is the one to enter it, so it has not fallen into the hands of attackers who may bypass it. Once attackers have it, you are effectively gambling. Account for that in your threat model and do not let it get to that point.<p><a href="https://news.ycombinator.com/item?id=49040342">https://news.ycombinator.com/item?id=49040342</a>
Offtopic:<p>>Even if that device doesn't have the ability to turn on Airplane Mode or to turn off the transmitters through the Control Center of iOS.<p>IIRC, the default on iOS is that anyone with your locked device can enable airplane mode which is concerning simply for thieves. But I suppose they have to use faraday bags anyway because of the Find My network.
So we pay Apple for friction. And the state pays for Graykey to remove it. Whoever wins that arm race this quarter determines what our rights are worth in practice.
Well, that's assuming you are ever able to claim your phone back. From what I understand police might just keep it indefinitely until they are able to access it, unless you get some kind of court order that it he returned to you<p>Even then, who enforces the court order? :/
I wouldnt be surprised if they had a backdoor into the Qualcomm chip that Apple decided to oddly still include in most of their US iPhones vs the international versions that come with their own internal modem
Ooh, I wonder whether Apple made the classic mistake of using a wall clock timer when they should have used a monotonic (local) clock timer.<p>edit: having personally gone through this kind of mess, the correct solution is to use strict typing to make sure you keep track of the difference between times and durations and the difference between different clock types. Don’t use plain integers and also don’t try to fudge it the way that Go’s standard library solution does. The modern C++ library is actually pretty good, although you need to use very recent versions of the standard for full functionality.
Is it maybe providing a bogus NTP server or something? Maybe the automatic reboot feature can be moved to the Secure Enclave or something, and made to only rely on the hardware RTC in a way that can't be tampered with.
Here's a deeper dive on that question:<p><a href="https://naehrdine.blogspot.com/2024/11/reverse-engineering-ios-18-inactivity.html" rel="nofollow">https://naehrdine.blogspot.com/2024/11/reverse-engineering-i...</a><p>Tl,dr: it's likely baked into the sep, no ntp<p>I'm wondering if you put the phone into a mode where it thinks it's dialing emergency services or contacting them via crash detection etc that it won't reboot. I could picture a scenario where the code is written to never disrupt an emergency services call.<p>Full disclosure I don't own an iPhone so this may not even be a thing. Just guessing based on liability risk from Apple of "what's more important than protecting the phone"
Does this mean iPhones are worth more to steal?
Perhaps for a short time. As soon as Apple understands the exploit I expect them to patch it. They may even back port the fix to older iOS versions as well.
No. This requires an expensive license for a government agency to purchase in order to take advantage of this functionality.
This article seems completely unrelated to theft of devices.
iOS has a remote erase feature. Its also a leaked video and doesn't show which version or model. So it could be something that is already patched, or soon will be. Remember to always keep your OSes update.
I wonder why Apple, with its resources, doesn't take the lawfare approach to someone attacking its phones, for profit, and damaging its reputation.
Well first on the things you can do right now till apple figures it out, you should have control center disabled while the phone is locked, you can find it under “Allow Access When Locked” in face id and passcode settings, while -per the article- this won’t stop them, it sure will make it harder as by the time they try to gain access the 72h might have passed and a reboot happens. Second, they definitely fake the internal clock through the port, and because connected phone will keep correcting it through the NTP, hence it’s crucial to them to isolate the phone, so your job is to make that harder on them or delay it enough till it reboots itself. I think some of the quick counter measures apple can do now is allowing custom reboot periods, remote reboots through icloud, and disabling the possibility of manipulating the time through the lightning/usbc port.
<i>> AFU</i><p>Good name.