Comment by Retr0id

Comment by Retr0id 18 hours ago

27 replies

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.

bogwog 17 hours ago

> 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.

  • palata 16 hours ago

    > 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.

    • digiown 16 hours ago

      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.

      • palata 11 hours ago

        Right, I get what you mean.

        But in a way, I feel like sometimes it makes sense to not completely open everything. Say a messaging app, it makes sense to not just make it free for all. As a company, if I let you interoperate with my servers that I pay and maintain, I guess it makes sense that I may want to check who you are before. I think?

  • xvector 17 hours ago

    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 :)

maqp 11 hours ago

>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

londons_explore 17 hours ago

> 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.

  • gruez 14 hours ago

    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.

  • Retr0id 17 hours ago

    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.

    • Retr0id 17 hours ago

      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)"

      • londons_explore 16 hours ago

        Exactly. Thats how DRM video works, and I don't see why you couldn't do the same for text.

        • Retr0id 16 hours ago

          Actual DRM uses symmetric keys though, figuring out how to do the crypto in an E2EE-comaptible way would be challenging.

  • pennomi 17 hours ago

    There will always, ALWAYS be the analog hole in security models like this.

    • londons_explore 12 hours ago

      It's pretty hard for the government or service provider to snoop through the analog hole unless they have a camera on your forehead...

willis936 18 hours ago

By avoiding untrustworthy clients. All Windows devices should be considered compromised after last year.

  • Retr0id 18 hours ago

    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.

    • willis936 18 hours ago

      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.

      • Retr0id 18 hours ago

        That seems orthogonal to the subject of this discussion, i.e. "Compromise of the client side application or OS shouldn't break the security model."

  • cobertos 18 hours ago

    Windows has been sending usage history back to their servers for longer than just last year

  • GraemeMeyer 18 hours ago

    Why last year?

    • willis936 18 hours ago

      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.

HumblyTossed 18 hours ago

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.