Comment by dredmorbius

Deleting arbitrary directories, messages and app data would be highly unreliable. There's a high likelihood of the data being recovered. It's not how computer filesystems and storage are designed to work. Reliable deletion of data requires setting it up to be reliably deleted later on by having it encrypted on storage with keys which can be reliably prevented from ever being obtained again.

Wiping the overall data on the device via a factory reset, OS recovery mode or duress PIN/password prevents recovering any of the data because it reliably wipes material needed to derive key encryption keys and also reliably wipes the encrypted disk encryption keys. Wiping the encrypted disk encryption keys alone would not be good enough because they're stored on the SSD so imaging the SSD and restoring it could preserve the ability to recover the data. The way the key material needed to derive the key encryption keys is wiped prevents recovery via imaging the SSD mainly due to the secure element.

There's already support for reliably wiping data at the granularity of Private Spaces and secondary users. Those have their own encryption keys and can be reliably deleted due to having their own Weaver slots in the secure element and other hardware-based security integration.

Apps can also assorted generate encryption keys in the secure element and use those to encrypt data where it can be reliably deleted via wiping the hardware keystore keys. That requires apps built to have granular storage and encryption of their data.

Despite it being possible to wipe a secondary user or Private Space reliably, the past existence of it and when it was wiped will be easily discoverable via the main Owner user and system data. Preventing discovery of those profiles having existed requires an overall wipe of the data. It isn't feasible to hide it without doing that and hiding it would involve a whole bunch of unreliable removal of data without a way to prevent recovery along with redoing a bunch of statistics and other metadata to hide that there was another profile until recently. For example, things like the battery and data usage stats directly refer to the profiles. Even hiding it from naive analysis not looking at the leftover data on storage would still require changing a bunch of things to hide it.

Making data deletion of the data reliable for a whole profile or the whole data partition also requires a reboot or shutdown. Consider how much data gets loaded into the page cache and many other forms of data in the Linux kernel and other processes. Consider how much linger around in various kinds of registers, etc. including outside of the OS itself. Reboot or shutdown has code to get rid of this and the device sitting there turned off or booting again also gets rid of it.

They were clearly going to hook his phone up to forensics software on a laptop and had done what they needed to do in order to justify it for their own policies. It would not make sense to set up everything they did simply to have someone non-technical manually sift through his apps. They have widespread access to forensic software and also more advanced software with exploits. They definitely have easy access to it at a major Atlanta airport. The adversary in this case is not a non-technical human but rather advanced software from Cellebrite who are fully aware of alternative operating systems and document information on it. Their documentation directly refers to GrapheneOS and has tables listing their (currently very limited) capabilities against it.

This story got widespread news coverage and is widely known about. That should help make it clear how important it is for features to work against adversaries aware of these kinds of features. Our duress PIN/password works against adversaries aware of it. If they don't coerce a PIN/password from someone or don't enter a coerced PIN/password because they know it could be in use then the feature has worked. We want to improve the feature with secure element rate limiting integration in the future so that an OS exploit cannot be used to bypass it. The secure element already prevents an OS exploit from bypassing the limit of 20 total attempts for deriving encryption keys with massively increasing delays between those attempts. It used to solely be based on delays with throttling quickly reaching 1 attempt per day after 140 failed attempts but now there are only 20 total unique attempts. The past 5 failed unique attempts are temporarily remembered and discarded when entered again rather than trying to use them again for usability.