Conversation

Notices

1. Embed this notice
   Paul Cantrell (inthehands@hachyderm.io)'s status on Friday, 04-Apr-2025 11:15:26 JST Paul Cantrell

   in reply to

   • Ars Technica
   • Steve Bellovin

   @SteveBellovin @arstechnica

   Yup. Google could even feed compromised code to one single user (they know who’s logged in) at one specific time, and then never again. No security researcher even sees the compromised code to analyze it.

   • Embed this notice
     Ars Technica (arstechnica@mastodon.social)'s status on Friday, 04-Apr-2025 11:15:27 JST Ars Technica

     Are new Google E2EE emails really end-to-end encrypted? Kinda, but not really.
     Yes, encryption/decryption occurs on end-user devices, but there's a catch.
     https://arstechnica.com/security/2025/04/are-new-google-e2ee-emails-really-end-to-end-encrypted-kinda-but-not-really/?utm_brand=arstechnica&utm_social-type=owned&utm_source=mastodon&utm_medium=social

     Xenotar repeated this.
   • Embed this notice
     Steve Bellovin (stevebellovin@infosec.exchange)'s status on Friday, 04-Apr-2025 11:15:27 JST Steve Bellovin

     in reply to

     • Ars Technica

     @arstechnica There's another problem here. If the encryption is being done client-side by *any* browser, it's being done by JavaScript—and who knows what the JavaScript is doing? I call this the trust-binding problem. When you download software or an update to it, you're making your decision to trust the vendor at that point. With JavaScript encryption and decryption, you're making that decision every time you load the page. This is a very different concept, and one that isn't make clear to users. (In theory, there could be browser extensions to do the encryption and decryption, but that's not easy for users, and there are many different browsers out there, with very different policies on extensions.)