← Back to context

Comment by Perseids

8 hours ago

> I find this unconvincing. Isn't this the exact same security posture as a native app with automatic updates turned on?

Mostly. But the alternative shouldn't be a native app that updates itself, but rather a native app that is updated by a package manager. The big difference is traceability and auditability: With a trusted package manager (and even in good app stores) the company can only decide to push an update to everyone or to no-one. There is no way to push an update just to the pesky journalist or whistle blower. A covert attack is really hard to accomplish this way.

8 comments

Perseids

Reply
palata  7 hours ago

Exactly, to me there are two requirements:

* The cryptography must be sound. That's the obvious one, if it's not encrypted then it's not "end-to-end" encrypted.

* There must be a practical way for the user to "verify" (with some definition of verifying) the client they are running.

A web browser doesn't provide that at all. It does not mean that everything else provides it: there are many ways to provide a Desktop app that break E2EE, but that is a different discussion. My point is that fundamentally, the web browser does not provide that. It's not that the laws of physics prevent it, it's just that the web browser never chose to provide that.

  • thadt  6 hours ago

    > it's just that the web browser never chose to provide that.

    Yes, this exactly. If we wanted ‘verifiable’ app distribution via browser, then we’d need browsers to implement some way to cross check the code downloaded vs a publicly published list somewhere - similar to certificate transparency or what WhatsApp is trying to do with an extension [1]. Without that, web apps are left working with a weaker threat model.

    [1] https://engineering.fb.com/2022/03/10/security/code-verify

    • palata  4 hours ago

      Yep! Just nitpicking here, but...

      > or what WhatsApp is trying to do with an extension

      I remember looking into it, and while it is interesting, I think what it allows to verify is that the intermediary (Cloudflare, I believe) didn't tamper with the code being served. Which in the end allows the user to verify that the code they run comes... from the server they trust.

      And even that is not super practical, I find.