4 ms·

> If PM decides to act maliciously, they can do so undetected. Unlike the mobile application who’s binaries get cryptographically signed to match the official c

> If PM decides to act maliciously, they can do so undetected. Unlike the mobile application who’s binaries get cryptographically signed to match the official codebase, there is no method to verify a web application. Because everyone uses reproducible builds and verifies them for every automatic app update, right? > Although they do use the same client side OpenPGP library maintained by ProtonMail (its likely the only one in the world that works in browsers), they have accounted for the concern and developed a system that allows you to compare the code in your browser with the code that they’ve published Their implementation for the checksum is actually cool, I like it. However, I believe that most people use protonmail for convenience and that it fits the threat model of the average joe. If you're getting targeted by the NSA, you shouldn't use a browser with JIT enabled anyway.

gillesjacobs 5y ago
Having user auditable source code and verifiable builds is pretty much the gold standard approach. Yes, the vast majority won't check the checksum and even less well check the source, but it only takes one critical person to get the ball rolling upon compromise.
- Brian_K_White 5y ago
  Yep. The difference between convenient and inconvenient doesn't really matter at all. Visibility is the difference between possible and not-possible. That is all the difference in the world, and matters no matter how few people ever actually do something.
yanmaani 5y ago
> Because everyone uses reproducible builds Of course not, but it is possible to do so. It can also be verified by trusted third parties, etc. > However, I believe that most people use protonmail for convenience and that it fits the threat model of the average joe. If you're getting targeted by the NSA, you shouldn't use a browser with JIT enabled anyway. This is a non-sequitur. If you're starting to talk about average Joes with an unspecified threat model, surely GMail will be fine too, for some very low bar of "crooks can't hack my facebook". But there's obviously a big span inbetween that and "specifically targeted by intelligence agencies". More to the point, no matter your threat model, you should try not to do business with scammers. Firstly, out of moral imperative, and secondly, because your threat model might change.
dane-pgp 5y ago
> Their implementation for the checksum is actually cool, I like it. For those interested, I think the checksum trick referred to above (in the context of the service offered by CTemplar) is described at [0] and there is a step-by-step how-to guide at [1]. Basically the top level index.html contains integrity hashes for the JavaScript it fetches, and you're expected to copy-paste the source of the page you're viewing into an editor, save the file, and run a local checksum on it. That is clever, but it seems like a more convenient design would be to use a "bootstrap" page which only has the minimal set of tags on it needed to run a single <script src=bootstrap.js integrity=sha384-whatever>. Then the user can do a quick visual inspection that there's nothing suspicious in the DOM and confirm that the integrity hash matches the value in an append-only log somewhere. Mozilla actually had a clever idea for building binary transparency using the existing certificate transparency infrastructure for domains[2], by registering something like $version_number-$hash as a sub-domain of the domain where the app is hosted, e.g. v14-abc123.ctemplar.com which the user could search for using one or more certificate transparency logs. Anyway, this manual checking process can be avoided entirely if the site is made available as a SecureBookmark[3], although that has the disadvantage that the browser would show a Data URI as the page address rather than a standard URL/domain which users are more familiar and comfortable with. [0] https://ctemplar.com/ctemplar-checksum-implementation/ https://ctemplar.com/ctemplar-checksum-implementation/ [1] https://github.com/CTemplar/webclient/tree/gh-pages https://github.com/CTemplar/webclient/tree/gh-pages [2] https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency [3] https://coins.github.io/secure-bookmark/ https://coins.github.io/secure-bookmark/

gillesjacobs 5y ago

Having user auditable source code and verifiable builds is pretty much the gold standard approach. Yes, the vast majority won't check the checksum and even less well check the source, but it only takes one critical person to get the ball rolling upon compromise.

Brian_K_White 5y ago
Yep. The difference between convenient and inconvenient doesn't really matter at all. Visibility is the difference between possible and not-possible. That is all the difference in the world, and matters no matter how few people ever actually do something.

yanmaani 5y ago

> Because everyone uses reproducible builds Of course not, but it is possible to do so. It can also be verified by trusted third parties, etc. > However, I believe that most people use protonmail for convenience and that it fits the threat model of the average joe. If you're getting targeted by the NSA, you shouldn't use a browser with JIT enabled anyway. This is a non-sequitur. If you're starting to talk about average Joes with an unspecified threat model, surely GMail will be fine too, for some very low bar of "crooks can't hack my facebook". But there's obviously a big span inbetween that and "specifically targeted by intelligence agencies". More to the point, no matter your threat model, you should try not to do business with scammers. Firstly, out of moral imperative, and secondly, because your threat model might change.

dane-pgp 5y ago

> Their implementation for the checksum is actually cool, I like it. For those interested, I think the checksum trick referred to above (in the context of the service offered by CTemplar) is described at [0] and there is a step-by-step how-to guide at [1]. Basically the top level index.html contains integrity hashes for the JavaScript it fetches, and you're expected to copy-paste the source of the page you're viewing into an editor, save the file, and run a local checksum on it. That is clever, but it seems like a more convenient design would be to use a "bootstrap" page which only has the minimal set of tags on it needed to run a single <script src=bootstrap.js integrity=sha384-whatever>. Then the user can do a quick visual inspection that there's nothing suspicious in the DOM and confirm that the integrity hash matches the value in an append-only log somewhere. Mozilla actually had a clever idea for building binary transparency using the existing certificate transparency infrastructure for domains[2], by registering something like $version_number-$hash as a sub-domain of the domain where the app is hosted, e.g. v14-abc123.ctemplar.com which the user could search for using one or more certificate transparency logs. Anyway, this manual checking process can be avoided entirely if the site is made available as a SecureBookmark[3], although that has the disadvantage that the browser would show a Data URI as the page address rather than a standard URL/domain which users are more familiar and comfortable with. [0] https://ctemplar.com/ctemplar-checksum-implementation/ https://ctemplar.com/ctemplar-checksum-implementation/ [1] https://github.com/CTemplar/webclient/tree/gh-pages https://github.com/CTemplar/webclient/tree/gh-pages [2] https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency [3] https://coins.github.io/secure-bookmark/ https://coins.github.io/secure-bookmark/