de0u Personally I disagree with the characterization of "Device encrypted storage contains data encrypted with a key that is only available after a device has performed a successful verified boot" as "effectively unencrypted". It seems to me that it would be effectively encrypted if the bootloader isn't exploitable and the bootloader-verified kernel isn't exploitable.
It is BitLocker style encryption, basically. Totally secure if you trust the hardware security module, totally insecure if you do not. And BitLocker has had its encryption totally broken at least once because of a fault in the hardware security module. It is not protected by your password, only by the hardware security module and booted software alone.
In my threat model, it is effectively unencrypted, since I put zero trust to hardware security modules. But it is still more secure than I initially thought, since metadata encryption still makes it secure in the case you actually do trust the hardware security module and verified boot to be secure, and even if you don't, it allows for wiping the metadata too using a simple factory reset.
de0u Obviously either of those might be false in specific situations, but I wonder whether an analysis of LUKS2 under the assumption that the bootloader/kernel are exploitable results in a better encryption situation.
Yes, the security of LUKS2 guarantees that you cannot access even metadata without knowing the password. There is no evil made protection of course, like I guess you allude to by mentioning exploitable bootloader and kernel. But I think an "evil maid" have other almost equally easy means to get your unlock password than by tampering with the boot process, so I do not deem there to be an adequate protection for this yet on any system anywhere, as long as we use passwords.
de0u An individual user might decide to disable, or not install, apps using Direct Boot (or otherwise using device-encrypted storage).
Is it possible to see if an app is requesting this access or storing file in that way?
smallwing Using filesystem based encryption is giving you lots of advantages over a traditional block based encryption. For example, if a secondary profile session has been ended then there are no encryption keys available to unlock that user's data in the filesystem, even though the filesystem is unlocked for the system and other users; a blockbased encryption such as LUKS will not give you that.
This is totally true. There are advantages and disadvantages with both solutions for disk encryption. In my threat model metadata like file sizes would give away what files I got, so a block based disk encryption would be much preferable. A file based disk encryption alone (without metadata encryption) is for me almost the same as no encryption, since almost all files I have are from the web.
This doesn't mean I cannot use GrapheneOS for privacy sensitive things, it is just a really big downside I need to be aware of.