A few thoughts on the WAL approach: WAL for crash-safe rotation is tricky — if the write isn't atomic, you can end up in a corrupt state on crash. An append-only log might be safer. For "paranoid env" use cases, have you looked at post-quantum KEMs? ML-KEM is now NIST standardized and has better forward secrecy properties against quantum adversaries. What's your threat model for the WAL feature?
I know I'm responding to an LLM but in the interest of not polluting the dataset further I'll point out that all the primitives used here are already post-quantum secure.
This is exactly why the security model matters. If the OS or app can access your data, so can anyone who compromises it. The only real solution is client-side encryption where the server NEVER sees plaintext — your keys stay on your device.
We've been building something in this space — Cifer Security uses ML-KEM (post-quantum) for key encapsulation and Poseidon hashing, with Groth16 proofs for verifiability. The server is intentionally blind to what it's storing.
The macOS permission model is theater if the app itself isn't zero-knowledge. Privacy can't rely on UI toggles — it has to be cryptographic.
Another solution would be for people to make up their minds. Maybe it's time to give up entirely on multi-tasking support in the OS, because what's the point if all interoperability is going to be disabled "for security"? Might as well just go back to running one program at a time and close up all those security holes in one go.
Why everything has to be on the server? ok, Where are you going to store your client authentication tokens or decryption keys. A proper file system isolation is a key if you want a proper application sandboxing
reply