People don’t know what problem they’re trying to solve or who is going to use (or be able to use) their solution. They just know the NSA must be stopped. End result: a lot of spaghetti on the wall.
If you trust where the Javascript is from, you’re trusting it with your plain-text. Javascript code delivery is a problem. The security is reducible to the security of the server the code is delivered from, it is not “end to end”. Now I am aware there are proposals to combat this, a signed browser extension is one, but I have not yet satisfied myself that is a realistic proposal in the age of NSL’s.
What is wrong with multi-user p2p applications without servers used for code-delivery every time you want to use the application?
I was thinking about something like this. Separate the code delivery server from the email storage server. Then I ran into the roadblock of cross domain ajax requests, but I think there’s ways around that.
Normally, you’d host the web app on your own machine. (For this discussion, web app is only the html shell and js files. The encrypted email always lives on a remote server.) If you’re at a friend’s house and need to check email, you would visit some mirror (eff.org/awesomemail or lobste.rs/mirrors/awesomemail), which loads the app, then you enter your mail server address. This isn’t so different than just downloading Thunderbird every time you visit somebody, but hopefully the js app loads faster and is more flexible about the devices it can run on.
The mail server would have to be configured to allow universal cross origin requests. Theoretically, since everything is encrypted with some key generated by the js code, that’s safe. ish. Drive by csrf attacks won’t have the magic key, which is kept in memory only, not as a cookie.
We assume that the NSA can’t convince every mirror everywhere to change their code to a backdoored version. They could tap into your friend’s ISP and backdoor you there, so the assumption we must make is they don’t know if or when you’ll be using your friend’s computer. If they do, you’re boned.
On the major downside, I think people have gotten used to search working for email. I know I have. An encrypted search index requires downloading and decrypting the entire index, which gets painful.
But then how can you trust the mirrors to load the right code? Why not just go directly to your own trusted server? Maybe I’m just not understanding you correctly.
I assume the NSA knows who you are and what server you are running, so they would tap into that server’s uplink. If there are many mirrors and many users of those mirrors, it becomes harder to identify and intercept your request (we assume that widespread infiltration will be detected because eyeballs).
How do we know the mirrors ever had a legit copy of the code? How do you know your original download was legit? That’s another bootstrapping problem which involves a lot of hand waving “somebody else will check that the signing keys match…”. :)
And yet a new javascript based encrypted mail service seems to pop up almost daily…
People don’t know what problem they’re trying to solve or who is going to use (or be able to use) their solution. They just know the NSA must be stopped. End result: a lot of spaghetti on the wall.
If you trust where the Javascript is from, you’re trusting it with your plain-text. Javascript code delivery is a problem. The security is reducible to the security of the server the code is delivered from, it is not “end to end”. Now I am aware there are proposals to combat this, a signed browser extension is one, but I have not yet satisfied myself that is a realistic proposal in the age of NSL’s.
What is wrong with multi-user p2p applications without servers used for code-delivery every time you want to use the application?
I was thinking about something like this. Separate the code delivery server from the email storage server. Then I ran into the roadblock of cross domain ajax requests, but I think there’s ways around that.
Normally, you’d host the web app on your own machine. (For this discussion, web app is only the html shell and js files. The encrypted email always lives on a remote server.) If you’re at a friend’s house and need to check email, you would visit some mirror (eff.org/awesomemail or lobste.rs/mirrors/awesomemail), which loads the app, then you enter your mail server address. This isn’t so different than just downloading Thunderbird every time you visit somebody, but hopefully the js app loads faster and is more flexible about the devices it can run on.
The mail server would have to be configured to allow universal cross origin requests. Theoretically, since everything is encrypted with some key generated by the js code, that’s safe. ish. Drive by csrf attacks won’t have the magic key, which is kept in memory only, not as a cookie.
We assume that the NSA can’t convince every mirror everywhere to change their code to a backdoored version. They could tap into your friend’s ISP and backdoor you there, so the assumption we must make is they don’t know if or when you’ll be using your friend’s computer. If they do, you’re boned.
On the major downside, I think people have gotten used to search working for email. I know I have. An encrypted search index requires downloading and decrypting the entire index, which gets painful.
But then how can you trust the mirrors to load the right code? Why not just go directly to your own trusted server? Maybe I’m just not understanding you correctly.
I assume the NSA knows who you are and what server you are running, so they would tap into that server’s uplink. If there are many mirrors and many users of those mirrors, it becomes harder to identify and intercept your request (we assume that widespread infiltration will be detected because eyeballs).
How do we know the mirrors ever had a legit copy of the code? How do you know your original download was legit? That’s another bootstrapping problem which involves a lot of hand waving “somebody else will check that the signing keys match…”. :)