4 ms·

The JS doesn't appear to be compressed so it's possible to view source and see what exactly it's doing. So if it was actually backdoored, somebody will actually

The JS doesn't appear to be compressed so it's possible to view source and see what exactly it's doing. So if it was actually backdoored, somebody will actually find out.

rdl 12y ago
You can serve different JS to "special" users once. If you're smart, you run checks "for the security of the browser environment" first to make sure it's something unlikely to contain debugging capabilities, e.g. an unmodified iOS device. The site even helpfully asks you to identify yourself with ANOTHER username and passphrase first, making it even safer for the attacker.
- fareastcoast 12y ago
  An attacker would have to (1) Gain access to the server in Switzerland (without the admins noticing) or (2) Break the SSL and execute a MITM attack. It seems ProtonMail actively scans the code on the backend for unauthorized changes. It's not 100% secure against a very determined attacker (NSA), but for the citizen that wants more privacy without the hassle of PGP, it's pretty good until we can replace SMTP.
  - sp332 12y ago
    Or (0) Be an admin.
  - tptacek 12y ago
    The same thing is true of a mail server in Switzerland that uses TLS and doesn't use clientside encryption.
  - rdl 12y ago
    Honestly if it is a good usability service based in Switzerland with no special sauce, but well run, I would like it. The only problem I have is that the security asserted doesn't match the reality of a decent threat model. You can go pretty far with policy and law alone.
tptacek 12y ago
You can't just review "openpgp.min.js". You have to review every single Javascript input and every single DOM node, and any of them can alter the behavior of any other element of the Javascript runtime in subtle ways to subvert cryptography. And you have to do this every time you load any page on the site, and any time any of those pages asynchronously load any content. So, no, contrary to popular belief, this doesn't work.
- yuhong 12y ago
  I wonder if XHTML would make sense here, to make XSS attacks more difficult.
- theboss 12y ago
  Why can't browsers just build crypto primitives in that can be called from js? I don't understand what people's obsession with browser crypto is...but I don't know enough about browser's to think of a reason this solution is bad. Any guidance? edit: I understand that this won't solve all the problems...but at least the problem that you are constantly being served this chunk of potentially unsafe code. edit2: I've been doing some thinking. Even though I didn't really get a response I think the reason is that it doesn't buy you the ability to do anything new safely. You still have the old problems of other dom elements mucking with your dom elements that control the code, or whatever the site does...so it doesn't really buy you anything...it's just work for nothing. I still think it would be a useful start to one day having safe browser crypto
  - IgorPartola 12y ago
    It is a long story and has been discussed one million times on here at least. Google the answer or just trust that crypto in JS cannot be not because the implementation is hard but because it is not possible in principle.
    - theboss 12y ago
      I'm only talking about solving this 1 problem related to js crypto...

The JS doesn't appear to be compressed so it's possible to view source and see what exactly it's doing. So if it was actually backdoored, somebody will actually find out.

rdl 12y ago

You can serve different JS to "special" users once. If you're smart, you run checks "for the security of the browser environment" first to make sure it's something unlikely to contain debugging capabilities, e.g. an unmodified iOS device. The site even helpfully asks you to identify yourself with ANOTHER username and passphrase first, making it even safer for the attacker.

fareastcoast 12y ago
An attacker would have to (1) Gain access to the server in Switzerland (without the admins noticing) or (2) Break the SSL and execute a MITM attack. It seems ProtonMail actively scans the code on the backend for unauthorized changes. It's not 100% secure against a very determined attacker (NSA), but for the citizen that wants more privacy without the hassle of PGP, it's pretty good until we can replace SMTP.
- sp332 12y ago
  Or (0) Be an admin.
- tptacek 12y ago
  The same thing is true of a mail server in Switzerland that uses TLS and doesn't use clientside encryption.
- rdl 12y ago
  Honestly if it is a good usability service based in Switzerland with no special sauce, but well run, I would like it. The only problem I have is that the security asserted doesn't match the reality of a decent threat model. You can go pretty far with policy and law alone.

tptacek 12y ago

You can't just review "openpgp.min.js". You have to review every single Javascript input and every single DOM node, and any of them can alter the behavior of any other element of the Javascript runtime in subtle ways to subvert cryptography. And you have to do this every time you load any page on the site, and any time any of those pages asynchronously load any content. So, no, contrary to popular belief, this doesn't work.

yuhong 12y ago
I wonder if XHTML would make sense here, to make XSS attacks more difficult.
theboss 12y ago
Why can't browsers just build crypto primitives in that can be called from js? I don't understand what people's obsession with browser crypto is...but I don't know enough about browser's to think of a reason this solution is bad. Any guidance? edit: I understand that this won't solve all the problems...but at least the problem that you are constantly being served this chunk of potentially unsafe code. edit2: I've been doing some thinking. Even though I didn't really get a response I think the reason is that it doesn't buy you the ability to do anything new safely. You still have the old problems of other dom elements mucking with your dom elements that control the code, or whatever the site does...so it doesn't really buy you anything...it's just work for nothing. I still think it would be a useful start to one day having safe browser crypto
- IgorPartola 12y ago
  It is a long story and has been discussed one million times on here at least. Google the answer or just trust that crypto in JS cannot be not because the implementation is hard but because it is not possible in principle.
  - theboss 12y ago
    I'm only talking about solving this 1 problem related to js crypto...