[matthewaveryusa]

You are correct in your assessment, but this statement holds true for any application. You must read the source before executing it -- and en suite you need to trust the hardware that's executing said code.

As it stands you don't send your password to proton -- they send you an encrypted private key that the password you type decrypts (at email creation time you generated that private key in your browser via openppg.js ) They most certainly could change their API to send the password to the server once it's typed in the UI. This isn't unheard of and there is large suspicion that law enforcement made hushmail modify their API for certain users of interest in order to decrypt their mail.

[pfg]

The lack of code signing in web apps and the added attack surface of having your web and application server (which are in control of the code that users run) exposed to the internet matter a lot in this context.

Attacks on build systems of native applications aren't unheard of (CCleaner, that Ukrainian tax software, etc.), but it's far more involved and more likely to be detected, whereas web app backdoors can easily be delivered exclusively to the target and only for as long as needed to pull off the attack.

[twiss]

I've been working on adding code signing to web apps, using Service Workers: http://blog.airbornos.com/post/2017/08/03/Transparent-Web-Ap...

The main blocker is https://github.com/w3c/ServiceWorker/issues/1208 (which would fix the non-critical but less-than-ideal issue described under "Service Worker lifecycle" in the blog post).

[blfr]

It's true for applications delivered live (mostly webapps). For vast majority of apps, I expect that at least the package maintainer at least glanced at the changes before building a new version. This is hardly foolproof but there is another layer of verification.