[tptacek]

E-commerce doesn't rely on Javascript cryptography.

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.

[mjn]

> You generally don't trust code updates, _which is one reason you do them infrequently_ [emphasis added]

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.

[igravious]

Would there be a way of hooking important Javascript blobs into the OS update/store/packaging mechanism or am I being completely dense?

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.

[tptacek]

Are you noticing how hard it is to reason through the security model of Javascript crypto code? How many different interactions there are you'd need to account for? That's a big part of the problem, and it's a problem that simply doesn't exist in the same way for native code.

[igravious]

Dang, fell asleep there mid-conversation :/

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

[simonw]

"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 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.