I figure that if this is explained to me then surely the solution should present itself at the same time :)
In a peer to peer setup, Bob and Alice only need to trust a discrete piece of software they download from Sergey at a given point in time. Maybe that software is open source so they can audit it and thereafter have confidence in it. But if Sergey is instead releasing his software as a javascript program to be run in a web browser than they need to trust Sergey each and every time they run the program, because they are downloading the program anew each and every time they want to use it.
Even if Sergey is a stand up guy, this setup means that the government can force him to break his promise at any time, whereas if he had put out a discrete set of software versions, particularly if they were open source with a public source control, he could plausibly tell the government that what they were asking was impossible.
In a larger sense, I would push back against the web browser as a general purpose OS. We already have a few battle tested OSes who designers have put great thought and effort into these problems. If you insist on javascript, there's even node.js programs, albeit generally installed outside of the usual OS specific mechanisms. If you insist on HTML/css for layout and javascript for programming, I believe there are toolkits based on webkit, chromium and IE that let you create a standalone program embedding the respective browser engines. You can even do what mailpile is doing and embed a web sever in your client application and use your web browser as a client to the client acting as a server (though this last seems a little Rube Golderg-esque to me). But in any event downloaded and installed like a full fledged program rather than treating the exercise as though you were going to a special website.
And if a web site suddenly switches to a new public key, the browser should do the same kind of thing as it does for expired SSL.
It should be relatively easy to create a browser extension that does this in the meantime.
Then what I'd like to see is a mail service that sends its source unminified, and then publishes the same code (with signature) on its server. That way you could easily verify that you were getting the canonical version of the code (and not a special compromised version that an attacker inserted for users on a special list), and anyone could look and see if it was doing something fishy (or broken).
JavaScript in web browsers also has a few other issues, such as side-channel timing attacks and the lack of control of memory.
In that case, why do we trust e-commerce? Are we stupid to trust e-commerce?
Am I right in saying though that if the javascript has been signed that the browser could trust it assuming the browser could trust webmail.example.com
I mean, we all get our software from somewhere. Why should I trust a security update from Apple, Microsoft, or Canonical for instance ...
You generally don't trust code updates, which is one reason you do them infrequently; every time you update code there's an opportunity for someone who has corrupted the update process to take over your machine.
A Javascript application might need to update itself several times per second across a single execution of itself.
Say I don't trust code updates which is why I choose to run Uuntu because I like its central package management system. Is it entirely infeasible to leverage that update mechanism to enable end-to-end crypto communication in the browser or are these entirely separate issues? Is it your contention that the browser is not the correct platform for end-to-end crypto communication?
edit: it's ok - you needn't reply, I've read some of your other posts and I get that you'd tell me that there are DOM considerations as well.
I am noticing that it is unexpectedly difficult to reason through the security model of Javascript crypto code. And you sure are patient, and I thank you for bringing about that realisation. It is beginning to dawn on me that it is amazing how _happily_ we allow any random site to go ahead and use are CPUs to do _God knows what_ as soon as we visit their site. That's rather trusting of us when you think about it.
But we gotta. Because why? Because dynamic content supposedly; it was easier to have Turing-complete Javascript than figure out how to make HTML/CSS dynamic. Never mind that a generic VM approach should have been taken if that's what you're gonna do, and let random site-designer Jo(sephin)e choose the language they like hacking with rather than create yet another language that we're all going to bitch and moan about. And you can tell that the assembler for the Web / VM approach should have been taken because that's what Javascript is becoming. Exhibit A: ASM.js
And at the time we should have figured out that in addition to sandboxing we also needed a security model that would cater for end-to-end secure (anonymous?) communication. Pity we couldn't see 20 years down the road. Now we're stuck with Javascript (which I actually like, don't get me wrong) and GMail (which I'm regretting that I use, nowadays) . sigh
That's a very different issue from JavaScript cryptography though. Allowing random sites to use your CPU is the whole purpose of the world wide web - it takes CPU cycles to render static HTML, after all. The issue here is trusting that the browser sandbox is good enough to prevent that code doing anything malicious outside of the context of the browser. Browsers are pretty good at that these days.
Is this true anymore? So much stuff auto-updates I barely know what goes on these days, and it seems pretty frequent. Between Firefox auto-updates, OS X updates, MS Word critical updates, etc., I would be surprised if a week goes by without something important being updated.
Because it's your operative system and you can't realistically read and compile each time the patches (if you have the sources). If your operative system is against you you've utterly lost, so your best bets are to both trust them and use 100000 eyes to find bogus patches (open source OS)
well, many don't trust it, with good reason, and use temporary credit cards (sorry, can't remember the correct name for that but I hope it's clear enough)
The difference is that it is very hard to specifically target someone via an OS update. It is very easy to specifically target a web app user:
http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/
Now, if you were forced to log in or to otherwise uniquely identify yourself before you received OS updates, this would be different.