3 ms·

ProtonMail's web client is open source, and can be deployed locally if you wish to avoid scenarios where an evil application is deployed. Their native apps are

ProtonMail's web client is open source, and can be deployed locally if you wish to avoid scenarios where an evil application is deployed. Their native apps are unfortunately not open source, though.

tptacek 9y ago
Deploying a browser Javascript application locally does not automatically protect you from serverside malicious Javascript; you have to know a lot more about how the application is structured to know whether it's even helpful.
- arghwhat 9y ago
  Deploying any application locally puts you entirely at mercy of whoever wrote it, and those that know how to abuse it. That holds true for any type of application. However, in this context, deploying this particular self-contained application locally protects against the hypothetical attack where a genuine application is later modified to turn malicious. It is relatively easy to look for and identify any execution of server-side content. To prove that an application is not intentionally malicious, you would have to inspect the source. To prove that an application cannot be malicious, directly or indirectly, intentionally a not, you will need full formal verification of the application. And that verification only holds if you have formal verification of what it runs on.
  - tptacek 9y ago
    No, it does not. You've missed my point. Deploying a browser JS application locally would help you if you could be sure that the application never loaded any additional Javascript from the server during execution. But browser JS applications can in fact do that, and so local deployment does not help as much as you think it does.
    - _Codemonkeyism 9y ago
      Yes you would probably need to play with headers.
    - arghwhat 9y ago
      You missed my point. In multiple ways. I already accounted for remotely fetched JS in my previous comment. It is relatively easy to find JavaScript execution points (there are only so many ways to parse and execute text string from a server in JavaScript—eval, new Function, script element, on... DOM attributes, ...), and thus it is quite easy guarantee that an application does not intentionally execute remote code (intentional is what is inside the control of the source code—an image decoding bug in the browser causing code execution is outside the scope here). A local deployment (with proper protection of the deployment) guarantees that an application remains static, and cannot be changed arbitrarily for malicious intent. Combined with a relatively easy inspection for intentional remote code execution, you can conclude that there is no direct way for the application to turn malicious. If you do not inspect the source, a local deployment still reduces the chance of a malicious modification being possible from "100% guaranteed" to "maybe, if the application is written in a specific way, or if there is an unintentional code execution bug somewhere in the browser". You will of course never be able to reduce the chance of any application turning malicious to 0 without full verification of the application and platform it runs on (including all other applications running with permissions to interfere).
      - tptacek 9y ago
        I don't follow, since you said none of those things --- eval, script elements, DOM attributes --- in any previous post. I also don't understand why you think it's straightforward for people ("relatively easy", in fact) to verify that a browser JS app is server-proof. As table stakes, you'd need a comprehensive understanding of every way in which the server gets to update the DOM of the client.
        arghwhat 9y ago
        They were implied as "execution of server-side content" in the sentence: "It is relatively easy to look for and identify any execution of server-side content." It is correct that it would be complicated to do for an arbitrary hosted app that may inject server-side rendered content with scripts in them, but this is not the case here. There are very few places where "external" content is inserted into the DOM (decrypted mailbox content that may be HTML, account info), and those should all employ proper script stripping techniques. Finding DOM append or assignment (including attribute assignment) points is relatively easy. With the DOM out of the way, you only have places where the application intentionally executes JavaScript through eval and new Function (potentially wrapped in whatever frameworks they use). It really isn't very hard. And yes, I have done it before—and no, I couldn't have missed something when I did it, as only interaction I had found would succeed in my sandbox.

ProtonMail's web client is open source, and can be deployed locally if you wish to avoid scenarios where an evil application is deployed. Their native apps are unfortunately not open source, though.

tptacek 9y ago

Deploying a browser Javascript application locally does not automatically protect you from serverside malicious Javascript; you have to know a lot more about how the application is structured to know whether it's even helpful.

arghwhat 9y ago
Deploying any application locally puts you entirely at mercy of whoever wrote it, and those that know how to abuse it. That holds true for any type of application. However, in this context, deploying this particular self-contained application locally protects against the hypothetical attack where a genuine application is later modified to turn malicious. It is relatively easy to look for and identify any execution of server-side content. To prove that an application is not intentionally malicious, you would have to inspect the source. To prove that an application cannot be malicious, directly or indirectly, intentionally a not, you will need full formal verification of the application. And that verification only holds if you have formal verification of what it runs on.
- tptacek 9y ago
  No, it does not. You've missed my point. Deploying a browser JS application locally would help you if you could be sure that the application never loaded any additional Javascript from the server during execution. But browser JS applications can in fact do that, and so local deployment does not help as much as you think it does.
  - _Codemonkeyism 9y ago
    Yes you would probably need to play with headers.
  - arghwhat 9y ago
    You missed my point. In multiple ways. I already accounted for remotely fetched JS in my previous comment. It is relatively easy to find JavaScript execution points (there are only so many ways to parse and execute text string from a server in JavaScript—eval, new Function, script element, on... DOM attributes, ...), and thus it is quite easy guarantee that an application does not intentionally execute remote code (intentional is what is inside the control of the source code—an image decoding bug in the browser causing code execution is outside the scope here). A local deployment (with proper protection of the deployment) guarantees that an application remains static, and cannot be changed arbitrarily for malicious intent. Combined with a relatively easy inspection for intentional remote code execution, you can conclude that there is no direct way for the application to turn malicious. If you do not inspect the source, a local deployment still reduces the chance of a malicious modification being possible from "100% guaranteed" to "maybe, if the application is written in a specific way, or if there is an unintentional code execution bug somewhere in the browser". You will of course never be able to reduce the chance of any application turning malicious to 0 without full verification of the application and platform it runs on (including all other applications running with permissions to interfere).
    - tptacek 9y ago
      I don't follow, since you said none of those things --- eval, script elements, DOM attributes --- in any previous post. I also don't understand why you think it's straightforward for people ("relatively easy", in fact) to verify that a browser JS app is server-proof. As table stakes, you'd need a comprehensive understanding of every way in which the server gets to update the DOM of the client.
      - arghwhat 9y ago
        They were implied as "execution of server-side content" in the sentence: "It is relatively easy to look for and identify any execution of server-side content." It is correct that it would be complicated to do for an arbitrary hosted app that may inject server-side rendered content with scripts in them, but this is not the case here. There are very few places where "external" content is inserted into the DOM (decrypted mailbox content that may be HTML, account info), and those should all employ proper script stripping techniques. Finding DOM append or assignment (including attribute assignment) points is relatively easy. With the DOM out of the way, you only have places where the application intentionally executes JavaScript through eval and new Function (potentially wrapped in whatever frameworks they use). It really isn't very hard. And yes, I have done it before—and no, I couldn't have missed something when I did it, as only interaction I had found would succeed in my sandbox.