Web-based cryptography is always snake oil

I wouldn’t call this “incoherent” rather, I propose the terminology “vendor subvertable”.<p>Yes, any time a vendor of software has any direct update capabilities, a targeted update can bypass the encryption provided by some software.<p>In practice, we tend to delegate to a 3rd party like an OS distribution packager, where there is a delay between vendor releases and packaging. Where it can be discovered.<p>Another good reason to use open source for core cryptography libraries and any code a vendor supplies should be open and repeatably built also.

&gt; A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against.<p>I don’t see why this would be true. The real problem with the cited examples is that every program downloads the latest implementation every time you want to use it. You could download the software once and then verify it is safe (by auditing the code etc) without any problem, and the security of the channel you get it over doesn’t matter. The real problem is that you can’t freeze the state of the application but the server can modify the code that’s running every time you use it.

Yes, web crypto requires trust on the server and is not secure if your threat model includes its compromise (or that of the CA). ProtonMail recognizes this[1] and offers native open source clients. They also try to somewhat reduce the issue by using an SPA for the web client, to reduce fetches from the server.<p>[1] <a href="https:&#x2F;&#x2F;vimeo.com&#x2F;216747532" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;216747532</a> 2017 presentation by ProtonMail&#x27;s CTO saying essentially the above, at 50:41

There are some efforts to use extensions to allow signing&#x2F;verification of web assets (assuming you trust the extension&#x2F;browser), some via third parties:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;tasn&#x2F;webext-signed-pages" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;tasn&#x2F;webext-signed-pages</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;jahed&#x2F;webverify" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jahed&#x2F;webverify</a><p><a href="https:&#x2F;&#x2F;github.com&#x2F;facebookincubator&#x2F;meta-code-verify" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebookincubator&#x2F;meta-code-verify</a><p>There was another one posted here recently, but I&#x27;m unable to find it now.

&gt; A cryptosystem is incoherent if its implementation is distributed by the same entity which it purports to secure against.<p>That&#x27;s what the recent Signal tormoil is like.<p>Communication via Signal app that&#x27;s safe if you could be sure it was compiled from verified open-source code, but Signal still doesn&#x27;t provide any way to in principle eliminate the possibility that client binary distributers put in a backdoor at the last minute.