|
|
|
|
|
by tptacek
4605 days ago
|
|
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. |
|
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