Please add using specfic Duress Pin to delete a specfic user profile

PrivacyEndGame

I have all my apps I use with empty data installed on my owner profile. Creating a new user profile is as easy as deciding which apps to have enabled on the new user profile and signing into my password manager. It makes it super convenient and easy to create and delete user profiles making it a very useful tool for keeping your data safe from confiscation. Yet it's not a feature that's utilized as you can't delete a profile from lock screen easily when it matters most.

As nice as the duress password feature is, it's inconvenient to have to restart all over again every time you fear a potential threat by redoing your settings, re-downloading all your apps, creating new profiles, and thus the duress feature in the real world goes under utilized way more often then when it should and thus creates severe unnecessary risks for individuals. Allowing a certain password to delete only certain user profiles would be the enhancing feature the duress password feature really needs in order for it to be truly useful for those who really need the feature since if you're the type of person who really needs the feature, it's not a feature you think about only using once but have to remain vigilant about using often. Vigilance truly matters for a feature like this and convenience plays a large role in it to not be taken importantly.

de0u

PrivacyEndGame This feature, or something similar, is requested pretty frequently, maybe around once a week. Searching the forum for "stealth profile" will probably turn something up.

One issue (there are others!) is that deleting a secondary profile leaves significant traces, and if GrapheneOS shipped the feature then many people would know about it. The combination would significantly reduce deniability, which is problematic for a feature that in theory would be primarily a deniability feature.

So far the GrapheneOS project has expressed firm disinterest in doing this. That said, other people could fork the project and implement whatever they want.

Please note that I do not speak for the GrapheneOS project.

PrivacyEndGame

de0u As incredible as deniability is, for some threat models making sure you are not compelled to release data is more important then being found guilty of destroying unknown data. It's the sort of feature that is best left to the individual to decide whether a full duress or profile duress with the lack of deniability benefits is more preferable to them and considering the wide variety of threat models that GrapeheneOS users use GrapheneOS for, it would really be in GrapheneOS's interest to re-evaluate their stance especially if it is indeed a widely requested feature as not doing it does more harm then having it. That said I appreciate the reply.

Alternatively, just like how on the lock screen there is a "End Session" Button, there could also be a "Delete Profile" button as well. This way you have the best of both worlds, deniability of "oops my finger accidentally pressed the button" and ability to delete individual profiles rapidly.

de0u

PrivacyEndGame Considering the wide variety of threat models that GrapeheneOS users use GrapheneOS for, it would really be in GrapheneOS's interest to re-evaluate their stance especially if it is indeed a widely requested feature as not doing it does more harm then having it.

Obviously if some users want Feature X and the GrapheneOS developers add Feature X to GrapheneOS then that is in the interest of those users. But there are at least three other groups to consider.

If some users would be harmed by GrapheneOS shipping Feature X, suddenly it's not so clear that shipping Feature X is in the interest of the project. In the case of stealth profiles or partial duress PINs, it has been explained repeatedly that some users plausibly would be harmed. If GrapheneOS is known to have stealth profiles / partial duress PINs, then some people will have grounds to assume/declare that some user (e.g., some user in custody) has plausibly turned that feature on and used it. No matter how many users are sure that they would personally decide to use the feature and would enable it, that just does not address the interests of the users who would plausibly be harmed by the feature.
At least for the foreseeable future, if the GrapheneOS developers spend time on Feature X, they are not spending that time on Feature Y. This is undeniable. If Feature Y is more beneficial to more people, then developing Feature X instead of Feature Y is not clearly in the interest of the project.
Meanwhile, I think the GrapheneOS developers are entitled to an opinion about whether a feature is or isn't something they wish to invest in.

One way to resolve this would be for the users who really really really want this feature to hire somebody to write code implementing that feature, and to deploy that code in their own fork of GrapheneOS. If there are a lot of users who want this, and they do very much want this, then that should work out.

This suggestion has been made. I assure you that the GrapheneOS developers are aware that some users want this (and that some users want it a lot). Also the GrapheneOS developers have said that they do not plan to do this, and they have said why. That disagreement may be irreconcilable, in which case the open-source way to handle that disagreement is a fork.