cdflasdkesalkjfkdfkjsdajfd The difference is we can wipe the eSIM. What can the OS do for the physical SIM? Not much.
GrapheneOS version 2024053100 released
- Edited
matchboxbananasynergy I was hoping for a mission impossible style puff of smoke whilst destroying it 🤷♂️
GrapheneOS I'm very excited for the duress feature! What do you think about putting a little label with the duress PIN on the inside of the phone case in case some nosey person thinks they can just access ones phone?
I also read that Google is planning a Theft Detection Feature for later this year: "Theft Detection Lock is coming later this year and helps you keep your personal and financial data safe if your phone is ever snatched from you. This powerful new feature uses Google AI to sense if someone snatches your phone from your hand and tries to run, bike or drive away with it. If a theft motion is detected, it will be quickly locked down to keep your information out of the wrong hands."
Do you think it will find its way into GrapheneOS? It uses Google AI, so I'm not sure how this would work. I've been using Private Lock for some time, but it hasn't been updated for quite some time.
Clueless I'm very excited for the duress feature! What do you think about putting a little label with the duress PIN on the inside of the phone case in case some nosey person thinks they can just access ones phone?
Someone actually brought this up in our chat rooms, and I think it's a fantastic use of the feature. A phone snatcher is more likely to want to wipe the phone and sell it, which you as the owner kinda have to accept, but if they try to sign in to see if they can find anything that'll help them making more profit, there are two ways to combat the scenario:
The duress PIN could be a PIN that someone trying random common PINs would try. It could be a birth year that seems to be around your actual age (the thief might start guessing how old you were based on when they saw you and might trip the feature in this way), or something really common like "1234" or similar.
Is what you mentioned. A small sheet of paper in the phone case that contains a few dummy passwords for non-existent accounts (to add legitimacy to what's about to follow) and another entry which you can name "phone PIN" or just "PIN" if you don't want to make it too obvious. That PIN would of course be the duress PIN, which would wipe the device and any eSIMs you have, so that they can no longer try accessing any of the data on it.
Clueless I also read that Google is planning a Theft Detection Feature for later this year: "Theft Detection Lock is coming later this year and helps you keep your personal and financial data safe if your phone is ever snatched from you. This powerful new feature uses Google AI to sense if someone snatches your phone from your hand and tries to run, bike or drive away with it. If a theft motion is detected, it will be quickly locked down to keep your information out of the wrong hands."
This will be part of sandboxed Google Play. I don't imagine it'll be able to work without privileges, but it's not 100% certain. Maybe it does. There is an open issue on our tracker to implement something similar. It's something that we might look into in the future.
- Edited
matchboxbananasynergy There is an open issue on our tracker to implement something similar. It's something that we might look into in the future.
That's cool! I wish I knew android development, so I could contribute to such features. Maybe in the future.
matchboxbananasynergy A phone snatcher is more likely to want to wipe the phone and sell it, which you as the owner kinda have to accept,
I wondered about that: I have play services installed and am logged in to my Google account. Will it be FRP locked to make it worthless for the thief? Or is that function removed in GOS? I suspect the latter since it would need google services to be deeply integrated into the system, right?
Clueless I wondered about that: I have play services installed and am logged in to my Google account. Will it be FRP locked to make it worthless for the thief? Or is that function removed in GOS? I suspect the latter since it would Google services to be deeply integrated into the system, right?
https://grapheneos.org/faq#anti-theft has the information you need. :)
- Edited
matchboxbananasynergy Hello, I don't understand why i need to set a duress PIN and a duress password? Why not just PIN?
User11 it could be for users that use a passwords instead of a pin when unlocking their phone. I think the wording might be a bit confusing :)
- Edited
@matchboxbananasynergy @GrapheneOS I just updated a Pixel 7a to 053100 release on the beta channel. I tested setting a Duress Pin and Password in the Owner profile and entering it in a new secondary profile. The lock-screen gave me the little incorrect pin shake then the device immediately shutdown. On turning the device back on it didn't boot into the normal GrapheneOS boot mode, but instead to a GrapheneOS Recovery mode where it said user data was corrupted then offered to try to boot the OS again or Factory Reset the device. After factory resetting it gave me the New Install setup screen. Is the Recovery mode message intended? This seems to clearly indicate the user wiped the device with the Duress feature (rather than the device is new/unused) and makes it unattractive to use in jurisdictions that criminalize deleting data i.e. USA.
Is it a matter of once the device is in a new state the adversary could just check for the remnants of an encrypted filesystem on the storage media and use that as evidence of the device being wiped (even if decryption is no longer possible due to destruction of key material)? It seems to me the feature has the most utility for users that calculate that the punishment the adversary enacts is more desirable than getting access to the data. For example a political dissident that believes their torture, imprisonment, or execution to be preferable to that of their network exposed via their devices contents. Or when one knows the prison term for obstructing an investigation/deleting data is less than the term for incriminating evidence on the device.
I like that GrapheneOS gives users the option to protect the confidentiality of their data in this urgent and final manner. Kudos to all the devs that designed and implemented this feature.
Edit: Addtionally a Duress Pin/Password can be set even when there is no pin or password lock set.
I tried duress pin and it worked as intended .
- Edited
Thank you for all your hard work in developing the duress feature!
Even though my threat model does not really require this feature in the classic sense, I find the suggestion to use it against phone snatchers quite helpful: I personally don't want to give Google or other apps the invasive permissions a rempote wipe feature would require, but if I can use the duress feature and such a feint to increase the probability that a potential thief triggers the wipe himself, I think that's great (if he wipes the device anyway to sell it, even better - I personally am more interested in my personal data than in getting my phone back).
I also found xxx hint that a short duress password/PIN triggers the wipe in the event of a brute-force or dictionary attack to be a very handy side effect.
Agility8200 This seems to clearly indicate the user wiped the device with the Duress feature
Does it? The message does not say that the device is wiped, only that data is corrupt. Of course, one shouldn't be fooled into thinking that an adversary who is well aware of the duress password feature and how it will display once triggered, will think that the device somehow became corrupted for some inexplicable reason. But it could fool a simple thief or an abusive partner who are not aware of the feature. Most people have never heard of GrapheneOS, and to them it's going to look like the device is failing inexplicably.
The feature isn't theater to try and fool people. It doesn't explicitly say a wipe occurred, but it's not trying to hide it either. Anyone who thinks about it can likely realize what happened. The goal is making so the data can no longer be accessed. It's meant to help in situations where danger to someone can be reduced if there's no longer data to provide. People should of course be responsible and threat model accordingly.
That said, a journalist with sensitive data/sources that they don't remember wiping their device to make that data no longer available might be in a better spot than someone just refusing to provide the password to unlock it. If you're removing the incentive of the attacker to harm you, they might stop. Again, and I cannot stress this enough, everybody should very carefully assess the situation. GrapheneOS is providing a reliable and thorough way to trigger a wipe of your phone's data. How people use the feature (some ideas have already been floated in this thread) is up to them.
The DURESS function works perfectly.
Many thanks.
On the other hand, if you could one day add a wipe after X false attempts, based on the same code, that would be wonderful.
I've seen that you're working on a 2FA system with PIN + BIOMETRIC. Personally, I use a DICEWARE PASSWORD for the owner profile + a user profile with PIN.
Will the 2FA system be for secondary profiles in BFU or is it just for AFU?
The 2FA with biometrics is very interesting if we can completely remove the possibility of adding or modifying a fingerprint. Because even if the password has been communicated, an attacker won't be able to change it and will still need the user to look at the phone.