GrapheneOS makes a duress PIN the last line of defense
GrapheneOS says a duress PIN can wipe a device from any prompt that accepts a profile PIN or password. Its larger argument is that a locked phone needs layered defenses before that destructive option is ever used.
The project points to secure-element rate limiting, hardened exploit defenses, blocked USB data while locked, and an 18-hour locked-device reboot that returns the phone to its pre-unlock state.
HN readers focused on the everyday trade-off: strong protection depends on how the phone was last used. A device left running after first unlock presents a different problem from one powered down before a border crossing.
Security starts before the panic code
GrapheneOS frames its duress PIN as a minor feature inside a wider physical-access model. The project says supported Pixels use secure-element rate limiting, that GrapheneOS raises the password limit to 128 characters, and that it blocks new USB connections while locked. Its auto-reboot timer, set to 18 hours by default, moves a locked device back to Before First Unlock state.
The duress PIN is deliberately destructive: entering it in a PIN or password prompt for the current profile wipes the device. It can also be used as the second factor after a fingerprint, but not as a SIM PIN. The project warns people to think carefully about legal and physical consequences rather than treating it as a magic escape hatch.
The thread moved from wiping to state
HN’s most practical discussion was about the state of the device at the moment someone takes it. A commenter noted that disk encryption is not the only question: after first unlock, a phone may be exposed to a different class of attack than a powered-down device. Another proposed backups and restore workflows so travellers could cross with a deliberately minimal handset instead of relying on an irreversible wipe.
That makes GrapheneOS’s post more useful than a feature announcement. It separates deterrence, delay, and destruction. Rate limits and hardened hardware raise the cost of guessing; the reboot timer reduces the window in which keys remain available; a duress PIN ends recovery altogether. Users still have to choose which risk they are solving for before they are under pressure.
Get breakdowns like this every day
The top Hacker News stories, unpacked — by email, Telegram, or RSS.
Ruff 0.16 turns 413 lint rules on by default
Astral’s Ruff 0.16 expands its default rule set from 59 rules to 413. For Python teams, that changes an update from a speed improvement into a potential cleanup campaign.