[DrewHintz]

If your browser gets JavaScript crypto from webmail.example.com every time you visit webmail.example.com then there's nothing stopping webmail.example.com from serving malicious JavaScript crypto that steals your keys or unencrypted data. Even though the JavaScript runs locally, the code is supplied by webmail.example.com. There's a discussion of this and a few other issues here: http://www.matasano.com/articles/javascript-cryptography/

JavaScript in web browsers also has a few other issues, such as side-channel timing attacks and the lack of control of memory.

[igravious]

Ahhh. I see. But of course, how dim of me.

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

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

[betterunix]

"I mean, we all get our software from somewhere. Why should I trust a security update from Apple, Microsoft, or Canonical for instance"

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.

[riquito]

> Why should I trust a security update from Apple, Microsoft, or Canonical for instance

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)

[riquito]

> why do we trust e-commerce? Are we stupid to trust e-commerce?

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)

[elBob]

I'd like to point to this http://blog.opal.io/crypto-in-the-browser.html

[tptacek]

And here's the thread taking that post apart:

https://news.ycombinator.com/item?id=6637915