[OutOfHere]

The technical problem here seems to be that GrapheneOS apparently doesn't support logging in to a partitioned empty OS for scanning purposes, also that it doesn't support such partitions at all, only one of which would be the real one.

[Cider9986]

It's not possible to create that feature because GrapheneOS operates under the assumption that an adversary has encyclopedic knowledge of the OS. Currently your suggestion would leave forensic traces so it wouldn't achieve the goal of deniability.

[OutOfHere]

I find that line of thought to be hilarious and absurd, since even simple encrypted containers on mass-market Android devices work to shield the user. The forensic trace doesn't grant access to the container.

[Cider9986]

There's no problem with preventing access on GrapheneOS. It's one of, if not the most, secure operating systems for that purpose.

You said that there are no partitions. That's wrong. There are no hidden partitions, because they would be ineffective. You can have up to 32 user profiles with different unlock methods, and within them you can have private spaces which are basically the same as user profiles.

User profiles and private spaces are great because they can allow more of your OS to remain BFU, which is more secure than AFU. They are great for security, but they provide no plausible deniability.

>The technical problem here seems to be that GrapheneOS apparently doesn't support logging in to a partitioned empty OS for scanning purposes

Initially you suggest deniable partitions. I explain that it's not possible to achieve robust deniability that way, because it would leave forensic traces.

>since even simple encrypted containers on mass-market Android devices work to shield the user.

User profiles and private spaces are encrypted, isolated containers, and they exist on Android and are enhanced by GrapheneOS.

The forensic trace doesn't grant access to the container.

That is about security, which is already fine. We aren't talking about security; we are talking about deniability. Your suggestion to add fake partitions would not be effective for deniability because it would leave forensic traces. Deniability with hidden partitions is not currently possible on the flash storage used in Pixels and all modern phones, due to wear leveling and many other critical problems inherent to flash memory [1].

[1] https://veracrypt.io/en/Wear-Leveling.html

[OutOfHere]

Are you saying that GrapheneOS has the means to allow a user to fully encrypt applications and their files? I mean while allowing login and access to the scanner where there is nothing to see.

> Initially you suggest deniable partitions.

That's nonsense because I never suggested a goal of complete deniability. You keep insisting I did, and attempting to bury the discussion on such grounds, but I never did.

[Cider9986]

>Are you saying that GrapheneOS has the means to allow a user to fully encrypt applications and their files? I mean while allowing login and access to the scanner where there is nothing to see.

No I did not mean that. There's means to fully encrypt applications and files, like on any modern smartphone. There's also user profiles and private spaces which allow you to separate your data and encrypt them differently. Notice "private spaces" and user profiles. There's no "deniable spaces"

There's no means to allow decryption while hiding data. The only deniability feature I'm aware of is the duress password.

>"Initially you suggest deniable partitions."

>That's nonsense because I never suggested a goal of complete deniability.

>"The technical problem here seems to be that GrapheneOS apparently doesn't support logging in to a partitioned empty OS for scanning purposes"

This is what a form of plausible deniability would look like. GrapheneOS isn't going to implement a non-robust plausible deniability feature.

>You keep insisting I [suggested a goal of complete deniability], and attempting to bury the discussion on such grounds

I never insisted that you suggested a goal of effective deniability. I only explained that GrapheneOS isn't going to implement a non-robust implementation of that feature, which is the only implementation that is technically possible right now.

The reason I'm emphasising an effective plausible deniability solution is because that's the only solution that would actually help anybody. It's also the only solution that would ever be implemented. A non-robust solution would give people a false sense of security and would therefore help attackers.

Honeypot operating systems like Anøm are the ones that hide the OS within a calculator. GrapheneOS is not gonna do something stupid like that.

I'm just informing you of the real landscape of the feature you want. I thought it was a nice thing to do.