333
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 28 Jul 2026
333 points (100.0% liked)
Privacy
5940 readers
19 users here now
Welcome! This is a community for all those who are interested in protecting their privacy.
Rules
PS: Don't be a smartass and try to game the system, we'll know if you're breaking the rules when we see it!
- Be civil and no prejudice
- Don't promote big-tech software
- No apathy and defeatism for privacy (i.e. "They already have my data, why bother?")
- No reposting of news that was already posted
- No crypto, blockchain, NFTs
- No Xitter links (if absolutely necessary, use xcancel)
Related communities:
Some of these are only vaguely related, but great communities.
- !opensource@programming.dev
- !selfhosting@slrpnk.net / !selfhosted@lemmy.world
- !piracy@lemmy.dbzer0.com
- !drm@lemmy.dbzer0.com
founded 2 years ago
MODERATORS
This is what happens when you try to maintain your rights in a fascist country: you risk five years in the slammer.
I wonder why GrapheneOS makes a big flashy rebooty show when using the duress password instead of quietly unlocking to an empty phone though...
Not sure there's a realistic way they don't notice. It takes time to wipe things and then the phone is empty. I feel like they'll figure it out.
Less than a second to make a new partition, unmount the old one, and have a background process start wiping
I just realized there are ways you could do plausible deniability.
What if we keep a decoy partition ready to go? Pre-populate it with some AI-generated slop Facebook account, photos, etc. Keep A small random sample of music files. etc. Something that looks as plausible and bland as possible.
This is a feature that could get better & better over time. Don't just wipe my old data; make my adversary unaware that there was anything worth wiping.
What if you were able to pick apps/accounts that mirrors to the decoy partition? Then you have real data, but all the private stuff stays locked away.
You can already make hidden spaces in graphene!
Although I think this guy should've just had an alt user active during the search and turned off usb data transfer.
He shouldn't have been searched, but he should've realized that he probably would be and prepared his device better.
I could absolutely see this being a thing, veracrypt has an option to create a hidden volume, and the two different passwords open up to two different encrypted volumes. Also if you start writing information to the non-hidden volume, it will start overwriting the hidden volume and corrupting files without any guardrails which is nice
"Oh no! You got my gramma's secret cookie recipe!!"
Hmm fair I didn't think of that option.
Android supports multiple user profiles. They could have a duress code login to a more sanitary profile while data get wiped in the background. This has been discussed on the forums I believe.
The wiping in the background is very fast, and would in turn take out the profile. The only thing a decoy profile would achieve in that case would be a slight splash of color before the phone shuts down.
Yes, how it currently works. But you could do a targeted wipe of the profile and leave the rest of the phone untouched with a secondary profile. Here's one such discussion from a year ago warning of basically exactly this happening: https://discuss.grapheneos.org/d/21122-setting-up-a-secondary-passcode-that-opens-a-dummy-profile
That would reduce the security of the duress pin significantly, and would require rewritting how the feature works in the first place.
The duress pin shreds the decryption keys to the entire OS, which is much much faster than erasing the data itself, and arguably more secure. If you're worried about getting caught wiping the device, just don't wipe it. There is no known way to get into a phone running an up to date GrapheneOS install (or anything post Q3 2022) unless you have significantly reduced the security of the phone.
Android supports per profile encryption. You can just erase the encryption keys for the other profile.
That's not the point of the duress pin.
Deleting the owner profile in the first place would make the device unusable for the same reasons you can't end the owner session and go to another profile. If your data is in a secondary profile, so you can delete it without compromising the integrity of the OS, you can make your own profile duress feature by using an app with device admin to wipe the device (which will only wipe the profile) when you trigger it. There are plenty of duress keyboards with this feature.
Gotcha yeah sounds like it could be improved then.
If the phone is encrypted already you really just need to destroy the key. Of course then it needs to be reimaged to be used again which isn't very user friendly.
From the gOS website description of the feature, thats exactly what happens. It also says that reimaging isnt needed, only the initial setup
This is a very common complaint, and the main reason is that it's way more complicated than it sounds. The duress feature is designed to immediately erase any chance to recover the unencrypted data from the phone by destroying part of the data used to derive the decryption keys (the other part being your pin/password, which can't be destroyed for obvious reasons). Any attempt to boot into a fake OS would be obvious to anyone familiar with the OS, thus making it effectively security theater. Not to mention the waste of space maintaining a fake OS, which would require fully featured apps and settings, all of which would have to be designed to pass verified boot, which means you can't actually destroy the original OS the way they do.
There's currently no known way to extract data from a locked GrapheneOS device, especially once it's in BFU, unless you've heavily reduced the default security measures, so the duress pin/password is likely unnecessary unless the danger of someone accessing the data is greater than the punishment for destruction of the data.
Also, the "big flashy rebooty show" is less of a feature and more of an unintended happenstance caused by the device immediately losing critical data and being forced to restart. The articles make it sound flashier than it is. It looks more like the device is powering on but the screen keeps disconnecting for a second, before going black.
Sure, but IIRC that does not help if the attacker can retain the device or clone it, yes? Once they have a copy of the raw data they can just throw a datacenter at it, for any future amount of time.
Let's assume they successfully extract all the remaining data after you enter the duress pin. Which, while not impossible, extracting the data on most GrapheneOS devices would require physically desoldering the SSD from the phone and dumping the data.
With the data extracted, assuming they attempt brute force, they're not brute forcing your password, they're brute forcing the entire decryption key, which is a mix of your password and a key generated when you first set up the OS (the latter of which was destroyed when the duress pin was entered). At that point, the phone owner, their entire lineage, and realistically the entirety of the universe itself will be long dead unless some breakthrough in cryptanalysis weakens AES256 such that it can be brute forced before all of humanity dies. That is to say, after the duress pin is entered, no one on Earth, even the device owner, can decrypt the data on the device.
It probably wipes the encryption key and reboots to clear anything lingering in memory.
Well, yeah, but they shouldn't have to.
Guess if you go to Iran, China, Russia or the USA it would come in handy though.
😁
my understamding is the phone is bricked when you do this. the key used to read the os itself is lost so you have to install a new one. the harddrive might as well be random noise.