Feature Idea/Proposal: Secret burner profile

OpaquePictureofGray

So, I stumbled upon the posts discussing secret profiles accessed through duress PINs, and many of the takes from different people were really valid, especially regarding how experts would immediately detect that there's something wrong, especially when it comes to access of ADB, and dev. Options, but I was thinking about the solution which would tackle those issue whilst helping people to have their whole lives to be saved (like with journalists, or whistleblowers, even with victims of domestic abuse! It can tremendously help!), so, I want to discuss the idea of having Secret Burner Profile — and how I propose it may look like:

Create a Secret Burner Profile (SBP) — its secrecy depends on the idea that you will create the secondary duress PIN which will log you into this SBP, it will not be visible on the lock screen, but it is going to be accessible through the settings of the Owner profile
You select one of the 2 modes of SBP — one which erases all of the data upon switch profiles, logging off, or just rebooting, meaning you can use it for sensitive work, or accessing dangerous files (like potential viruses), and second mode will not delete the data upon the switch, or reboot — but will be persistant, the idea is — that the second mode will also require to create a third PIN which then upon the entering will erase the SBP, and all of its traces, and log into the owner profile, this way — people can have an option to have their dangerous stuff in the SBP with second mode — and when needed — can just log into the owner profile which they use for daily life AND erase the SBP with all its files, and data!

This should cover lots of potential threats, and adversaries! Experts should not be able to detect anything with ADB in this case (well, I think it makes sense from my POV, I am not really familiar with Android architecture, I know that some data can be restored on desktop PCs, but I am not sure to what extend this applies to phones, as I can imagine they use different storage solutions)

Now, I want to hear the criticisms of this feature idea/proposal — because I want this to be helpful, but for it to be helpful — it should be ready as the concept first

akc3n

OpaquePictureofGray

Hi, Please first refer to https://discuss.grapheneos.org/d/11951-ai-generated-text-is-forbidden-with-the-exception-of-automated-translation

Open issue on this topic here:
https://github.com/GrapheneOS/os-issue-tracker/issues/5003

I am not really familiar with Android architecture

Short answer, you're over complicating something that you seem to have no technical experience or understanding of how things actually work. Please don't get advice or use AI slop to imagine and articulate things for you.

userofgos

OpaquePictureofGray This has been discussed in numerous threads, some change the idea a little, but in principle it stays the same. The main issue lies in the harm that is caused by such features due to 1) it will not be a "secret" that this feature exists and 2) it now makes all users (even those not using the feature) suspect of having a "hidden/dummy/secret/burner" profile.

Here's a quote from a similar feature request: https://github.com/dontletusdie/dlud/issues/1#issuecomment-3407888384

You're requesting a bunch of things which are not implemented because the obvious approach is easy to see through and would put people in harm's way by having insecure privacy/security features where anyone aware of GrapheneOS can negate the value they provide. We don't want to make features relying on tricking people unaware of basic things about Android and of GrapheneOS existing. That's not our approach, and anything reliant on that will be rejected.

userofgos

OpaquePictureofGray You select one of the 2 modes of SBP — one which erases all of the data upon switch profiles, logging off, or just rebooting, meaning you can use it for sensitive work, or accessing dangerous files (like potential viruses), and second mode will not delete the data upon the switch, or reboot — but will be persistant

This pretty much already exits in a simpler design. Use Guest profile with Delete guest activity > enabled (which deletes guest apps and data when exiting guest mode). And for normal usage use a separate User Profiles or Private Space

OpaquePictureofGray

akc3n

Sir, I am autistic, I am not an AI, but I see how it came across, I am just trying to be polite, regarding your short response — I do, in fact, have technical experience, but not a lot, as in good, profecient way with Android (hence the word "really" in the context of not knowing), I worked with Linux a lot, and had to deal with Android custom ROMs, and even modding custom ROM, but it is, in fact, much different than directly interacting with Android's APIs, and I haven't even touched the user directories, or any daemons related to the user authentication or lock screen, hence why I want to have a discussion about this, as I am interested in the ways how this can be implemented

OpaquePictureofGray

userofgos

Fair criticism, is it possible to have it as separate option? Meaning it is not included in the GrapheneOS itself, but like, a separate mod package? Or is it still impossible due to having connection to GOS? I mean — now it seems only fair to have such feature more of like a separate project which focuses on implementation of this feature into GOS, but I suppose it also introduces another attack vector, and another party to trust, which would compromise the project, and will cause Secure Boot issues if the modding is implemented through sideloading using fastboot, essentially — patching the code into the ROM, the ideal solution would have been then to have an official mod store for GOS, which is not a part of GOS itself, but like Google Play Services — can be optionally installed, and enabled at the risk of increased vectors of attack, but it is another can of worms, which is off-topic to this conversation, then the compromise seems to be a custom build of GOS with added modification patches, but that seems too much effort for too little gain.. The same issue again...

userofgos

OpaquePictureofGray Meaning it is not included in the GrapheneOS itself, but like, a separate mod package?

Most likely not a good idea and would increase attack surface.

According to this comment on the issue tracker, there is a hope to come up with a solution to make User Profiles hidden.

We want a feature in this area but done in a way where it can't just be easily discovered but rather is actually well hidden in a way that's deniable.

OpaquePictureofGray

userofgos

I have read the thread after moderator (admin?) Kindly advised me to do so, yeah, it pretty much tries to achieve what I wanted to convey, especially the bit which discusses the PIN Code scripting, as it essentially adds the layer of plausible deniability, AND extends the capabilities of what they (PIN Codes) can do, can imagine it might be really good in automation of.. Lots of stuff, it is like session profiles, you just choose the PIN, and it automatically sets up the session for you

userofgos

OpaquePictureofGray essentially adds the layer of plausible deniability

This is highly difficult to achieve, and what you suggest does not achieve that with the current limitations we have.

OpaquePictureofGray

userofgos

I know, but let me have my wishful thinking moment until I remember that big corpo and governments would probably just try to destroy the project for the sake of not having to deal with uncertainty, control is safety in psychology for a reason unfortunately...