5 ms·

I want whatsapp to decrypt the messages in a secure enclave and render the message content to the screen with a secure rendering pipeline, as is done with DRM'e

I want whatsapp to decrypt the messages in a secure enclave and render the message content to the screen with a secure rendering pipeline, as is done with DRM'ed video. Compromise of the client side application or OS shouldn't break the security model. This should be possible with current API's, since each message could if needed simply be a single frame DRM'ed video if no better approach exists (or until a better approach is built).

rsync 9mo ago
“I want whatsapp to decrypt the messages in a secure enclave and render the message content to the screen with a secure rendering pipeline, as is done with DRM'ed video.“ If you are sophisticated enough to understand, and want, these things (and I believe that you are) … … then why would you want to use WhatsApp in the first place?
- londons_explore 9mo ago
  Because my goal isn't to have my communication secure - but to have everyone's communication secure. And the network effect of whatsapp (3 billion users) seems currently the best route to that.
Retr0id 9mo 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.
- maqp 9mo 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 https://github.com/maqp/tfc
- willis936 9mo ago
  By avoiding untrustworthy clients. All Windows devices should be considered compromised after last year.
  - Retr0id 9mo 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 9mo 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 9mo 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."
  - GraemeMeyer 9mo ago
    Why last year?
    - willis936 9mo 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.
  - cobertos 9mo ago
    Windows has been sending usage history back to their servers for longer than just last year
- HumblyTossed 9mo 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.
- bogwog 9mo 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.
  - xvector 9mo 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 :)
    - Revolution1120 9mo ago
      Information should certainly be kept confidential, but Chat Control is also necessary.Furthermore, the former is merely rigid laws and regulations, while the latter is used to prevent the Satanists, which is capable of committing all kinds of evil.
  - palata 9mo 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 9mo 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 9mo 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?
- londons_explore 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago
        Exactly. Thats how DRM video works, and I don't see why you couldn't do the same for text.
        Retr0id 9mo ago
        Actual DRM uses symmetric keys though, figuring out how to do the crypto in an E2EE-comaptible way would be challenging.
  - pennomi 9mo ago
OtherShrezzing 9mo ago
This is what a layman would assume happens from Meta’s WhatsApp advertising. They show the e2e process, and have the message entirely unreadable by anyone but the phone owner.
- kevin_thibedeau 9mo ago
  e2e means unreadable by a middleman. That is a small inconvenience if you can readily compromise an endpoint.
  - Almondsetat 9mo ago
    People keep talking about e2ee as if it was some brain-to-brain encoding that truly allowed only the recipient person to decrypt the message
    - dijit 9mo ago
      because it used to be that the ends and the middlemen were different entities. In the universe where they are the same entity (walled-gardens) there is only the middleman. In such cases you either trust them or you don’t, anything more is not required because they can compromise their own endpoints in a way you can not detect.

rsync 9mo ago

“I want whatsapp to decrypt the messages in a secure enclave and render the message content to the screen with a secure rendering pipeline, as is done with DRM'ed video.“ If you are sophisticated enough to understand, and want, these things (and I believe that you are) … … then why would you want to use WhatsApp in the first place?

londons_explore 9mo ago
Because my goal isn't to have my communication secure - but to have everyone's communication secure. And the network effect of whatsapp (3 billion users) seems currently the best route to that.

Retr0id 9mo 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.

maqp 9mo 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 https://github.com/maqp/tfc
willis936 9mo ago
By avoiding untrustworthy clients. All Windows devices should be considered compromised after last year.
- Retr0id 9mo 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 9mo 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 9mo 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."
- GraemeMeyer 9mo ago
  Why last year?
  - willis936 9mo 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.
- cobertos 9mo ago
  Windows has been sending usage history back to their servers for longer than just last year
HumblyTossed 9mo 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.
bogwog 9mo 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.
- xvector 9mo 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 :)
  - Revolution1120 9mo ago
    Information should certainly be kept confidential, but Chat Control is also necessary.Furthermore, the former is merely rigid laws and regulations, while the latter is used to prevent the Satanists, which is capable of committing all kinds of evil.
- palata 9mo 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 9mo 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 9mo 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?
londons_explore 9mo 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 9mo 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 9mo 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 9mo 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 9mo ago
      Exactly. Thats how DRM video works, and I don't see why you couldn't do the same for text.
      - Retr0id 9mo ago
        Actual DRM uses symmetric keys though, figuring out how to do the crypto in an E2EE-comaptible way would be challenging.
- pennomi 9mo ago

OtherShrezzing 9mo ago

This is what a layman would assume happens from Meta’s WhatsApp advertising. They show the e2e process, and have the message entirely unreadable by anyone but the phone owner.

kevin_thibedeau 9mo ago
e2e means unreadable by a middleman. That is a small inconvenience if you can readily compromise an endpoint.
- Almondsetat 9mo ago
  People keep talking about e2ee as if it was some brain-to-brain encoding that truly allowed only the recipient person to decrypt the message
  - dijit 9mo ago
    because it used to be that the ends and the middlemen were different entities. In the universe where they are the same entity (walled-gardens) there is only the middleman. In such cases you either trust them or you don’t, anything more is not required because they can compromise their own endpoints in a way you can not detect.