3 ms·

Except that we cannot verify that you actually deploy the "open" code. It's obviously commendable that you do development in the open, and have people review th

Except that we cannot verify that you actually deploy the "open" code. It's obviously commendable that you do development in the open, and have people review the work you do. But there is no way for us to know that you don't run /addNSAbackdoor.sh in your deploy script for key parts of your infrastructure. There is already published docs that show Yahoo is/was part of Prism since 2008: http://www.wired.com/2014/09/feds-yahoo-fine-prism/ http://www.wired.com/2014/09/feds-yahoo-fine-prism/

magicalist 12y ago
All encryption runs clientside. The whole point of end-to-end is that you don't have to care about who the message passes through. Your actual worries at this point are the key exchange (impersonation) and extension distribution. The first is very hard to get right without alienating a large number of potential users, the second seems perfectly possible to have verified but seems like it's going to require some kind of changes in the Chrome extension system.
- m-app 12y ago
  It doesn't have to pass through anything but if the '/addNSAbackdoor.sh' script just adds a routine to the code that adds the Public Key of an NSA owned key-pair before the encryption process, then the NSA can pick it up from any Internet-tap they have and decrypt it.
  - pionar 12y ago
    Except that this runs locally, so if you're worried about that, you can build it yourself.
arianvanp 12y ago
Maybe Its time to introduce reproducible buulds to the JavaScript word? So that we can prove that the minified version is the same as the source.. Or just release the code as a nonminified AGPL set of ES6 files. With the coming of http2 it's going to be less of a problem But I still think we need to think of an out of band way to verify trust. Just like I can verify that my install of gpg or tails is legit
- diafygi 12y ago
  You're in luck! There's a working group called "Subresource Integrity" that's developing a way to allow websites to restrict a resource (including javascript files) to a defined hash. http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
  - deanclatworthy 12y ago
    This is a step in the right direction for embedding external resources. It'd remove CDNs as an attack vector (once it's rolled out everywhere). It'd be great to come up with some kind of way to also tell the client what resources are expected, and if a new one is loaded (e.g. <iframe src="http://dangerous.malware.com"></iframe> http://dangerous.malware.com"></iframe>) the client would not even connect to it.

magicalist 12y ago

All encryption runs clientside. The whole point of end-to-end is that you don't have to care about who the message passes through. Your actual worries at this point are the key exchange (impersonation) and extension distribution. The first is very hard to get right without alienating a large number of potential users, the second seems perfectly possible to have verified but seems like it's going to require some kind of changes in the Chrome extension system.

m-app 12y ago
It doesn't have to pass through anything but if the '/addNSAbackdoor.sh' script just adds a routine to the code that adds the Public Key of an NSA owned key-pair before the encryption process, then the NSA can pick it up from any Internet-tap they have and decrypt it.
- pionar 12y ago
  Except that this runs locally, so if you're worried about that, you can build it yourself.

arianvanp 12y ago

Maybe Its time to introduce reproducible buulds to the JavaScript word? So that we can prove that the minified version is the same as the source.. Or just release the code as a nonminified AGPL set of ES6 files. With the coming of http2 it's going to be less of a problem But I still think we need to think of an out of band way to verify trust. Just like I can verify that my install of gpg or tails is legit

diafygi 12y ago
You're in luck! There's a working group called "Subresource Integrity" that's developing a way to allow websites to restrict a resource (including javascript files) to a defined hash. http://www.w3.org/TR/SRI/ http://www.w3.org/TR/SRI/
- deanclatworthy 12y ago
  This is a step in the right direction for embedding external resources. It'd remove CDNs as an attack vector (once it's rolled out everywhere). It'd be great to come up with some kind of way to also tell the client what resources are expected, and if a new one is loaded (e.g. <iframe src="http://dangerous.malware.com"></iframe> http://dangerous.malware.com"></iframe>) the client would not even connect to it.