Comment by Retr0id
14 hours ago
Signal uses the DRM APIs to mitigate threats like Microsoft Recall, but it doesn't stop the app itself from reading its own data.
I don't really see how it's possible to mitigate client compromise. You can decrypt stuff on a secure enclave but at some point the client has to pull it out and render it.
> I don't really see how it's possible to mitigate client compromise
Easy: pass laws requiring chat providers to implement interoperability standards so that users can bring their own trusted clients. You're still at risk if your recipient is using a compromised client, but that's a problem that you have the power to solve, and it's much easier to convince someone to switch a secure client if they don't have to worry about losing their contacts.
> Easy: pass laws requiring chat providers to implement interoperability standards so that users can bring their own trusted clients.
In Europe that's called the Digital Markets Act.
That's not permissionless afaik. "Users" can't really do it. It's frustrating that all these legislations appear to view it as a business problem rather than a private individual's right to communicate securely.
6 replies →
You seem to think the government wants your messages to be private and would "pass laws" to this effect.
Methinks you put far too much faith in the government, at least from my understanding of the history of cybersecurity :)
>I don't really see how it's possible to mitigate client compromise.
You could of course offload plaintext input and output along with cryptographic operations and key management to separate devices that interact with the networked device unidirectionally over hardware data diodes, that prevent malware from getting in or getting the keys out.
Throw in some v3 Onion Services for p2p ciphertext routing, and decent ciphersuite and you've successfully made it to at least three watch lists just by reading this. Anyway, here's one I made earlier https://github.com/maqp/tfc
> don't really see how it's possible to mitigate client compromise.
Think of the way DRM'ed video is played. If the media player application is compromised, the video data is still secure. Thats because the GPU does both the decryption and rendering, and will not let the application read it back.
That's not what signal's doing though. It's just asking the OS nicely to not capture screen contents. There are secure ways of doing media playback, but that's not what signal's using.
Video decryption+decoding is a well-defined enough problem that you can ship silicon that does it. You can't do the same thing for the UI of a social media app.
You could put the entire app within TrustZone, but then you're not trusting the app vendor any less than you were before.
Although now I think about it more, you could have APIs for "decrypt this [text/image] with key $id, and render it as a secure overlay at coordinates ($x, $y)"
2 replies →
There will always, ALWAYS be the analog hole in security models like this.
It's pretty hard for the government or service provider to snoop through the analog hole unless they have a camera on your forehead...
By avoiding untrustworthy clients. All Windows devices should be considered compromised after last year.
That's not mitigating client compromise, that's a whole other thing - trying to construct an uncompromiseable client.
You don't build defense-in-depth by assuming something can't be compromised.
Clients can always be compromised. I'm not talking about a client that can't be compromised, but simply a client that is not compromised out-of-the-box.
1 reply →
Windows has been sending usage history back to their servers for longer than just last year
Why last year?
Windows recall, intrusive addition of AI features (is there even a pinky promise that they're not training on user data?), more builtin ads, and less user control (most notably the removal of using the OS without an account - something that makes sense in the context of undisclosed theft of private information).
This was 2025. I'm excited for what 2026 will bring. Things are moving fast indeed.
This. The gap in E2E is the point at which I type in clear text and the point at which I read clear text. Those can be exploited.