| ▲ | OutOfHere 5 hours ago | ||||||||||||||||
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 4 hours ago | parent [-] | ||||||||||||||||
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]. | |||||||||||||||||
| |||||||||||||||||