Oddbean new post about | logout
 #GrapheneOS version 2024053100 released. Duress Password is finally here. 

- add support for setting a duress password and PIN for quickly wiping all hardware keystore keys including keys used as part of deriving the key encryption keys for disk encryption to make all OS data unrecoverable followed by wiping eSIMs and then shutting down

- disable unused adoptable storage support since it would complicate duress password support (support can be added if we ever support a device able to use it)

- increase default max password length to 128 to improve support for strong diceware passphrases, which will become more practical for people who don't want biometric-only secondary unlock with our upcoming 2-factor fingerprint unlock feature

- disable camera lockscreen shortcut functionality when camera access while locked is disabled to avoid the possibility of misconfiguration by adding the camera lockscreen shortcut and then forgetting to remove it when disabling camera access

- kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.153

- kernel (6.1): update to latest GKI LTS branch revision

- Vanadium: update to version 125.0.6422.147.0

- GmsCompatConfig: update to version 115

-make SystemUI tests compatible with GrapheneOS changes

https://grapheneos.org/releases#2024053100 
 This is excellent, thanks! 
 After using the duress password, is it possible to reinstall Graphene and make a new setup, or is the hardware bricked? 
 Bonus question: can anyone comment on the legality of wiping your device if you find yourself in the hot seat?  Pretty sure there's a jurisdiction somewhere that would charge you with destruction of evidence... even without any evidence  
 It'd be better if the OS just got silently replaced a decoy image. 
 It's easy, just don't use GrapheneOs😄 I will always use it. 
 Obviously we can't speak on what potential bad guys (criminals or abusive states) would do. Laws are different elsewhere, but some would likely choose whatever would happen to them over what would happen if they surrendered. If a threat threatens to kill you, how can you be sure they won't just kill you if you complied anyway?

Sadly a duress PIN isn't designed to make you unaccountable. An erased device will always look obvious, and how they treat it really depends on who is trying to take it away.

You can best describe it as a trigger for erasing data to prevent an unauthorized party (in your proximity) from having potential access. It's great for protecting data you do not want anybody but yourself knowing. A whistleblower preparing to leak something confidential could come to mind.

It's more about protecting your data than yourself. 
 Yes of course. Wouldn't make sense to do something that causes permanent damage. Can reinstall GrapheneOS or another OS without problems. 

Since release is in Alpha there will be people in Alpha testing channels reinstalling GrapheneOS often for further QA.

Once backups are improved and not using Seedvault, that new backup system should be designed to work well for recovering after a duress trigger. Although there are bigger priorities right now. 
 FYI: GrapheneOS does remain installed after a trigger right now so you can go into a recovery. 
 Another interesting feature would be a pin that unlocks to a hidden user account with some generic applications installed. 
 It isn't planned currently as a technical threat would be able to figure that out, or would be able to tell if it is a decoy through other means. It's a big reason we don't have a hidden profile feature at all (e.g. FFS would leave signs). The feature would only work best against someone with no knowledge on what GrapheneOS is. Cellebrite and XRY and other industry actors mentioning us in their internal documents or product material would suggest they study our work and read our posts.

Another example is Owner is still required to be authenticated first and there's tons of ways to see if an authenticated profile os the Owner or not.

We believe features involved in tricking someone could lead to someone trusting that feature and underestimating how skilled the person they're trying to trick, which could endanger them or bring even more trouble. While you could also trick someone with our Duress PIN that's not the objective, the device owner should trigger it when the time is right. 
 Very good!  
 Is there a way to prevent someone from picking up my phone, swiping down a couple times, and tapping on users to see how many users I have? 
 btw, for example the coldcard hardware wallet has a "brick me pin" which actually makes that hardware unusable. 
 FYI: Obviously Pixel 8a doesn't have this or other new features due to being in prerelease, since it is currently based on Android 14 QPR2 and not QPR3. Once it is available then all currently supported devices are together. 
 Going to be so tempting to type the duress password 😂 
 Users are free to trigger their Duress password on a spare device in many different ways for feedback. ☺️ 
 Time to buy a pixel phone 
 What about an old/used one? 
 Works as well 
 when on other hardware ? that will finally matter buying pixel means making google rich - until then grapheneOS is useless for many 
 When other hardware can meet these requirements, we will support them:

https://grapheneos.org/faq#future-devices

It is disappointing only Pixels do this currently. Samsung is a close contender if they didn't intentionally sabotage users installing other OSes by disabling cameras, security features and more. 
 lineageos and ubuntu touch already supporting quite a few now 

grapheneOS just google device only for now. 
 #GrapheneOS version 2024053100 released. Duress Password is finally here. 

- add support for setting a duress password and PIN for quickly wiping all hardware keystore keys including keys used as part of deriving the key encryption keys for disk encryption to make all OS data unrecoverable followed by wiping eSIMs and then shutting down

- disable unused adoptable storage support since it would complicate duress password support (support can be added if we ever support a device able to use it)

- increase default max password length to 128 to improve support for strong diceware passphrases, which will become more practical for people who don't want biometric-only secondary unlock with our upcoming 2-factor fingerprint unlock feature

- disable camera lockscreen shortcut functionality when camera access while locked is disabled to avoid the possibility of misconfiguration by adding the camera lockscreen shortcut and then forgetting to remove it when disabling camera access

- kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.153

- kernel (6.1): update to latest GKI LTS branch revision

- Vanadium: update to version 125.0.6422.147.0

- GmsCompatConfig: update to version 115

-make SystemUI tests compatible with GrapheneOS changes

https://grapheneos.org/releases#2024053100 
 #GrapheneOS version 2024053100 released. Duress Password is finally here. 

- add support for setting a duress password and PIN for quickly wiping all hardware keystore keys including keys used as part of deriving the key encryption keys for disk encryption to make all OS data unrecoverable followed by wiping eSIMs and then shutting down

- disable unused adoptable storage support since it would complicate duress password support (support can be added if we ever support a device able to use it)

- increase default max password length to 128 to improve support for strong diceware passphrases, which will become more practical for people who don't want biometric-only secondary unlock with our upcoming 2-factor fingerprint unlock feature

- disable camera lockscreen shortcut functionality when camera access while locked is disabled to avoid the possibility of misconfiguration by adding the camera lockscreen shortcut and then forgetting to remove it when disabling camera access

- kernel (5.15): update to latest GKI LTS branch revision including update to 5.15.153

- kernel (6.1): update to latest GKI LTS branch revision

- Vanadium: update to version 125.0.6422.147.0

- GmsCompatConfig: update to version 115

-make SystemUI tests compatible with GrapheneOS changes

https://grapheneos.org/releases#2024053100