JavaScript must die(jgc.org)
jgc.org
JavaScript must die
http://www.jgc.org/blog/2009/09/javascript-must-die.html
13 comments
If we follow the idea of killing everything that's "insecure" then we will end up killing everything, because nothing is 100% secure. I vote for improving JavaScript, for example, by sourcing external code via Google Caja. We should also improve defense against XSS and CSRF attacks in today's most popular frameworks (because, a lot of the times it's not the JavaScript that's insecure, but the frameworks that developers use - - i.e. making it possible to source arbitrary HTML is a very bad idea, no matter if JavaScript is used or not [e.g. one can do malicious attacks via an image tag as well]).
> If we follow the idea of killing everything that's "insecure" then we will end up killing everything, because nothing is 100% secure
Perhaps, but killing off the stuff that is obviously and demonstrably broken seems like a pretty sensible policy.
Perhaps, but killing off the stuff that is obviously and demonstrably broken seems like a pretty sensible policy.
Killing one of the most popular languages isn't a solution, it's only wishful thinking. The situation with JavaScript isn't that bad, we just needs better tools such as a secure way to source external JavaScript and better protection against XSS and CSRF attacks... If these issues are solved, then 90% of the problems are solved.
Pretty silly really. (NoScript? deprecate js? aint gonna happen thankfully).
Many of the arguments are just arguments of why you don't include arbitrary untrusted javascript in your page. Many of the use cases of including external scripts in a page could be done exactly the same server-side, which would make them far more secure. But, it's extra work for websites to do that, so they often don't.
>> background-image: url('javascript:window.alert(1)')
Some browser seriously executes that js? I have not seen that work anywhere. (Just tested safari, firefox).
Perhaps a better answer would be to have browsers show you a small warning if the website is including js code from external sites, however, it's so common now that most websites would flag up. But it might cause people to rethink things a bit.
(Also as others say, the issues are not with the language javascript, but in the way it is used in browsers. Killing js wouldn't solve anything if you don't address the issues in the browsers).
Many of the arguments are just arguments of why you don't include arbitrary untrusted javascript in your page. Many of the use cases of including external scripts in a page could be done exactly the same server-side, which would make them far more secure. But, it's extra work for websites to do that, so they often don't.
>> background-image: url('javascript:window.alert(1)')
Some browser seriously executes that js? I have not seen that work anywhere. (Just tested safari, firefox).
Perhaps a better answer would be to have browsers show you a small warning if the website is including js code from external sites, however, it's so common now that most websites would flag up. But it might cause people to rethink things a bit.
(Also as others say, the issues are not with the language javascript, but in the way it is used in browsers. Killing js wouldn't solve anything if you don't address the issues in the browsers).
What is 'trusted' javascript though?
There is no differentiation between 'trusted' and 'untrusted', which I think was the point that the presentation was making.
There is no differentiation between 'trusted' and 'untrusted', which I think was the point that the presentation was making.
Sure there is (I agree js doesn't know the difference, but we do, and we are the music makers).
trusted: I wrote it / looked over the source code
untrusted: I pasted some <script src=http://gonnaHackU.com/blah.js>; into my page.
Including <script> tags from external entities is always a potential security risk. And it's always better to do it serverside if at all possible.
trusted: I wrote it / looked over the source code
untrusted: I pasted some <script src=http://gonnaHackU.com/blah.js>; into my page.
Including <script> tags from external entities is always a potential security risk. And it's always better to do it serverside if at all possible.
Right, but that's just a social distinction. It does nothing to protect users from careless web developers, and it does nothing to help web developers be less careless.
Please, somebody think of the users!
There are obvious technical solutions to this, but people seem unwilling to acknowledge that they might even be necessary.
Please, somebody think of the users!
There are obvious technical solutions to this, but people seem unwilling to acknowledge that they might even be necessary.
internet explorer allow javascript expressions in plain css, it used to be a handy trick to make zebra striped tables, although thats a bad use, its also part of what was behind the png hacks
I was aware of expression() when used in css on IE, but didn't know anything would execute url('javascript:
IE7 executes expression() when used in css (inline/style/external css file), but not when you set css from js. Also cannot make it execute url('javascript:
(Safari/Firefox/Opera/Chrome execute none of the above).
IE7 executes expression() when used in css (inline/style/external css file), but not when you set css from js. Also cannot make it execute url('javascript:
(Safari/Firefox/Opera/Chrome execute none of the above).
There is only one sure way to prevent all kinds of attacks involving javascript.
Never emit contents of any variable to the browser without treating it with htmlspecialchars() (or equivalent) first.
If you want your users to post formatted content either don't use html for formatting (use something like markdown) or parse the html to tree, and run it through whitelist filter that will let through only tags you want to pass, only attribute values that you want to pass, and only values of attribute that you want to pass (defined by narrow regexps that dont allow such thing as background:url(javascript:)).
To sum up never mix other data types with html (kept in static places like template files or read-only database tables), unless you are absolutely sure that they contain html you want to display, either by htmlspecialchars-ing them (safe and fast general policy) or by parsing and whitelisting (for cases that you really, really have to allow some html).
Never emit contents of any variable to the browser without treating it with htmlspecialchars() (or equivalent) first.
If you want your users to post formatted content either don't use html for formatting (use something like markdown) or parse the html to tree, and run it through whitelist filter that will let through only tags you want to pass, only attribute values that you want to pass, and only values of attribute that you want to pass (defined by narrow regexps that dont allow such thing as background:url(javascript:)).
To sum up never mix other data types with html (kept in static places like template files or read-only database tables), unless you are absolutely sure that they contain html you want to display, either by htmlspecialchars-ing them (safe and fast general policy) or by parsing and whitelisting (for cases that you really, really have to allow some html).
> Never emit contents of any variable to the browser without treating it with htmlspecialchars() (or equivalent) first.
That seems like one way of using a sledgehammer to needlessly burn server-side CPU cycles.
That seems like one way of using a sledgehammer to needlessly burn server-side CPU cycles.
Compared to the cost of accessing the database, html-escaping plain text is basically free.
Think like that and you will save one dollar in computing power during normal operation and lose over nine thousand when you'll be forced to clean up mess after xss worm attack.
There's a difference between a language and an API. JavaScript is a very powerful language in itself that has features like closures to please professional developers but is also easy to grasp by novice or amateur programmers. This makes it ideal for the role of being a client-side script engine of the web.
There might be issues with the standard JavaScript API (I mean, the DOM) but this could be fixed by correcting the API, there's no need to "kill" the language.
There might be issues with the standard JavaScript API (I mean, the DOM) but this could be fixed by correcting the API, there's no need to "kill" the language.
Which API are you talking about?
I don't mean to sound condescending, but following the general tone of your post, are you sure you know what an API is?
The take-home point for me was that the execution model for Javascript is inherently poor security-wise. Changing this would require changing the semantics of the language (i.e. you would break most Javascript code in existence), at which point it essentially ceases to be Javascript (unless you want to start to argue about replacing axe handles and such, but the original point stands - you could take a new language which fixes the execution model and call it "Javascript", but it would still not be the Javascript we use right now).
I don't mean to sound condescending, but following the general tone of your post, are you sure you know what an API is?
The take-home point for me was that the execution model for Javascript is inherently poor security-wise. Changing this would require changing the semantics of the language (i.e. you would break most Javascript code in existence), at which point it essentially ceases to be Javascript (unless you want to start to argue about replacing axe handles and such, but the original point stands - you could take a new language which fixes the execution model and call it "Javascript", but it would still not be the Javascript we use right now).
I was, of course, talking about the JavaScript DOM API: https://developer.mozilla.org/En/DOM
The DOM is unrelated to JavaScript's global variable/function/everything oriented nature, the ability to do stuff like redefine the Object constructor, the fact that there's no real protection between objects (e.g. guess the name of a variable or function and you have access).
The issue isn't that js has a global namespace, it's that scripts included on the same page all use the same global namespace.
This could easily be changed/fixed in browsers without changing anything about js.
It'd be nice to be able to specify in a <script> tag if you want a new js execution context setup, and also what access you want to give that script to your own execution context.
For example, maybe:
<script src=http://widgetmaker.com/wm.js newContext=true permissions="modifyDom:false,readNamespace=false,passMessages=true">
<script src=http://hitcounter.com newContext=true permissions="NONE">
With such a scheme, everything is executing in completely separate contexts, with clear permissions about their interactions. Some script messes with the Object constructor? only affects its own execution context.
Saying a blanket "js must die" isn't really understanding the issues, as they are actually in browsers, not js.
It's like saying python/perl/etc is an insecure language and must die, because it usually shares the same filesystem between processes.
This could easily be changed/fixed in browsers without changing anything about js.
It'd be nice to be able to specify in a <script> tag if you want a new js execution context setup, and also what access you want to give that script to your own execution context.
For example, maybe:
<script src=http://widgetmaker.com/wm.js newContext=true permissions="modifyDom:false,readNamespace=false,passMessages=true">
<script src=http://hitcounter.com newContext=true permissions="NONE">
With such a scheme, everything is executing in completely separate contexts, with clear permissions about their interactions. Some script messes with the Object constructor? only affects its own execution context.
Saying a blanket "js must die" isn't really understanding the issues, as they are actually in browsers, not js.
It's like saying python/perl/etc is an insecure language and must die, because it usually shares the same filesystem between processes.
The would help, but it doesn't eliminate the problems. For example, the JSON Hijacking attack would still work because the attacker would control the 'permissions' attribute in your proposal and allow himself access to the JSON object via modification of the Object constructor.
It also adds a layer of decision making on the part of a web designer. I believe it would be better to alter the language so that these global problems are eliminated at the language level. Because any decision making about the execution context are likely to cause problems themselves because people make all sorts of mistakes and they would have to understand what it means.
It also adds a layer of decision making on the part of a web designer. I believe it would be better to alter the language so that these global problems are eliminated at the language level. Because any decision making about the execution context are likely to cause problems themselves because people make all sorts of mistakes and they would have to understand what it means.
>> "because people make all sorts of mistakes and they would have to understand what it means."
I think this sums it up really. People make mistakes and make insecure software. Whatever language it is. I fail to see how swapping out js for anything else would solve anything. It's all pretty moot also, since it'd never happen.
The JSON attack again, isn't any inherent insecurity in the language, just in the way it is used within browsers.
Lets improve browser security rather than focusing on a language which has pretty much nothing to do with security issues. None of the examples you give had anything to do with the core javascript language. They were all about how it is used in the context of browsers.
Just to get this straight, one of your arguments is that since some browsers apparently execute the javascript inside css "url('javascript:...", the solution is to change javascript for some other language? Do you understand how ridiculous that seems?
I think this sums it up really. People make mistakes and make insecure software. Whatever language it is. I fail to see how swapping out js for anything else would solve anything. It's all pretty moot also, since it'd never happen.
The JSON attack again, isn't any inherent insecurity in the language, just in the way it is used within browsers.
Lets improve browser security rather than focusing on a language which has pretty much nothing to do with security issues. None of the examples you give had anything to do with the core javascript language. They were all about how it is used in the context of browsers.
Just to get this straight, one of your arguments is that since some browsers apparently execute the javascript inside css "url('javascript:...", the solution is to change javascript for some other language? Do you understand how ridiculous that seems?
Given that I object to the use of Javascript outside of browsers, you've basically negated (for me) any reason to treat the issue of language security versus browser security separately.
>> "Given that I object to the use of Javascript outside of browsers"
Fine. You seem to have something odd and bizarre against the language. Good luck to you and your quest.
You also don't seem to realize that swapping out js for some other language would mean exactly the same security issues, unless you actually fixed those security issues where they are - in the BROWSER.
If you would like to learn about the language, I'd recommend "O'Reilly Definitive Javascript". Also checkout Rhino.
Fine. You seem to have something odd and bizarre against the language. Good luck to you and your quest.
You also don't seem to realize that swapping out js for some other language would mean exactly the same security issues, unless you actually fixed those security issues where they are - in the BROWSER.
If you would like to learn about the language, I'd recommend "O'Reilly Definitive Javascript". Also checkout Rhino.
> You seem to have something odd and bizarre against the language.
It's not "odd and bizarre" - it's a belief that the language is fundamentally unsuitable for the things that people insist upon using it for, and reasonably well supported by my own experiences of the language, as well as the reported experiences of others.
> You also don't seem to realize that swapping out js for some other language would mean exactly the same security issues, unless you actually fixed those security issues where they are - in the BROWSER.
I take it you didn't read my reasonably concrete proposals for the use of proof carrying code? It becomes a largely mechanical process to verify that the browser and the language implement "security" in a sensible way at that point.
> If you would like to learn about the language, I'd recommend "O'Reilly Definitive Javascript". Also checkout Rhino.
Thanks. If you would like to learn about Horse and Pony care, I recommend "BHS Complete Horse and Pony Care".
It's not "odd and bizarre" - it's a belief that the language is fundamentally unsuitable for the things that people insist upon using it for, and reasonably well supported by my own experiences of the language, as well as the reported experiences of others.
> You also don't seem to realize that swapping out js for some other language would mean exactly the same security issues, unless you actually fixed those security issues where they are - in the BROWSER.
I take it you didn't read my reasonably concrete proposals for the use of proof carrying code? It becomes a largely mechanical process to verify that the browser and the language implement "security" in a sensible way at that point.
> If you would like to learn about the language, I'd recommend "O'Reilly Definitive Javascript". Also checkout Rhino.
Thanks. If you would like to learn about Horse and Pony care, I recommend "BHS Complete Horse and Pony Care".
The security needs to be in the browser - as in the user needs to enforce the security, not the code - leaving it up to developers to specify what permissions things should have is a recipe for lazy developers getting us into a situation much like the one we're in now.
I agree! Improve the BROWSER security model. Javascript is an innocent bystander in the mess.
It's the browser that allows 20 scripts from different domains all come together in the same execution context each with full permission to do anything.
It's the browser that allows 20 scripts from different domains all come together in the same execution context each with full permission to do anything.
> Javascript is an innocent bystander in the mess.
No, it's not, because well-formed, valid Javascript code is permitted to depend on this execution model.
No, it's not, because well-formed, valid Javascript code is permitted to depend on this execution model.
You're not making any sense whatsoever any more.
The decision to combine 20 <script> sources into the same execution context is the BROWSERS decision. NOT javascripts.
It's the BROWSER that doesn't have any concept of allowing <script> fine grained permissions within the execution context, or specifying you'd prefer if the browser put that script in a separate execution context.
It's the BROWSER that needs fixing here, not js.
The decision to combine 20 <script> sources into the same execution context is the BROWSERS decision. NOT javascripts.
It's the BROWSER that doesn't have any concept of allowing <script> fine grained permissions within the execution context, or specifying you'd prefer if the browser put that script in a separate execution context.
It's the BROWSER that needs fixing here, not js.
I'll refer you to this comment now, as we appear to be arguing about the same thing in two threads:
http://news.ycombinator.org/item?id=843320
http://news.ycombinator.org/item?id=843320
axod is right. It's a fallacy to say those are "features of JavaScript," when of course it is really a feature of the runtime environment.
JavaScript in a browser runs in the global namespace of the WINDOW, which is defined by the DOM API. Remember that JavaScript, on its own, is a headless language, with no I/O of any kind. It relies on the runtime environment to provide it with scope, context, and i/o, among other things.
Moreover, you can easily "fake" private members/functions/etc by using closures. (Yay!)
JavaScript in a browser runs in the global namespace of the WINDOW, which is defined by the DOM API. Remember that JavaScript, on its own, is a headless language, with no I/O of any kind. It relies on the runtime environment to provide it with scope, context, and i/o, among other things.
Moreover, you can easily "fake" private members/functions/etc by using closures. (Yay!)
This is pretty much true for many languages; runtimes offering reflection usually make even private members available. OO protection is not a security feature.
That was both not-obvious from your comment, and quite irrelevant, given that I can only see one complaint that stems from the design of the DOM API. The rest of them are all based on the flawed language security model. Basically an "API" is only as dangerous as the language that permits its use.
I agree that the execution model of JavaScript in the context of web scripting, especially in regards of security, could be better. On the other hand, I think that a too complex or restrictive model would alienate non-programmers such as web designers who don't understand (or don't want to understand) such abstract concepts.
Don't you think that something that prevented people from unintentionally introducing XSS vulnerabilities into their code would actually be easier? Building broken software is always easy, so shouldn't we be focusing on making it easier to build software that isn't broken?
It's not a flawed language security model.
Change browsers to use separate execution contexts for each <script> tag, and specify permissions about what they can and can't do to the containing context.
<script> tags are not part of the js language.
Change browsers to use separate execution contexts for each <script> tag, and specify permissions about what they can and can't do to the containing context.
<script> tags are not part of the js language.
But there is lots of code that relies upon that behaviour. We can argue about the exact source of it if you like, but if the language execution model is dependent on that behaviour, then the language execution model is flawed, which was my original point, I think.
There's no js code that relies on <script> tags using the same execution context, because <script> is not js code. It's an HTML tag.
It's outside of the scope of javascript. It's the Browser security model that needs toughening up.
It's outside of the scope of javascript. It's the Browser security model that needs toughening up.
You have chosen a particularly strange definition of "code".
Once again, I (recursively) refer you to this comment:
http://news.ycombinator.org/item?id=843320
<script>
var a = "hello, world";
</script>
<script>
doSomething(a);
</script>
Once again, I (recursively) refer you to this comment:
http://news.ycombinator.org/item?id=843320
I'm tired of this now, you don't seem to be reading comments, and putting up silly straw men.
You're well aware we're talking about <script> tags when used to load external source from other domains, so your example above is pretty irrelevant.
Good luck on your quest to rid the world of javascript!
You're well aware we're talking about <script> tags when used to load external source from other domains, so your example above is pretty irrelevant.
Good luck on your quest to rid the world of javascript!
You appear to be relying on the clairvoyant abilities of those you correspond with. My example could be re-factored into exactly the same situation you're talking about by substituting the body of each script tag with two files that contain the same code, but the example is valid either way.
Really, I don't understand the hostility here. Surely this is a worthwhile discussion to have? Either we can establish that it's not a problem that needs fixing, or we can establish that something needs fixing, and identify where it is.
Implying that I'm on some kind of vendetta just because I disagree with you about the source and nature of the flaws in javascript seems a little bit juvenile. These are genuinely-held opinions, and I'd appreciate it if you would not assume that I'm being disingenuous just because I disagree with you.
Really, I don't understand the hostility here. Surely this is a worthwhile discussion to have? Either we can establish that it's not a problem that needs fixing, or we can establish that something needs fixing, and identify where it is.
Implying that I'm on some kind of vendetta just because I disagree with you about the source and nature of the flaws in javascript seems a little bit juvenile. These are genuinely-held opinions, and I'd appreciate it if you would not assume that I'm being disingenuous just because I disagree with you.
If you did something so horrendously asinine, like make each <script> tag a separate execution context, then you would undo the huge leaps that web interaction has made - in one fell swoop.
I, for one, remain totally unimpressed by these accusations of insecurity. They don't seem like a big deal at all.
Lazy and/or incompetent programmers will always find a way to write insecure code.
I, for one, remain totally unimpressed by these accusations of insecurity. They don't seem like a big deal at all.
Lazy and/or incompetent programmers will always find a way to write insecure code.
>> " then you would undo the huge leaps that web interaction has made - in one fell swoop."
Why? Just have them in a separate execution context, and give them specific permissions... eg you can mess with the DOM, but only within this specific element, you can pass me messages, you can't access my execution context etc etc.
Such fine grained permissions would allow everything that goes on already, and disallow things you don't want to happen.
I agree though, the 'brokenness' is being vastly overplayed here. js isn't "broken", browsers aren't "broken", they just need improving, which is happening.
Why? Just have them in a separate execution context, and give them specific permissions... eg you can mess with the DOM, but only within this specific element, you can pass me messages, you can't access my execution context etc etc.
Such fine grained permissions would allow everything that goes on already, and disallow things you don't want to happen.
I agree though, the 'brokenness' is being vastly overplayed here. js isn't "broken", browsers aren't "broken", they just need improving, which is happening.
Iteresting, how new language will solve problems with have little to do with the language itself?
Nowhere does he propose a new language built on the same foundation.
What he actually proposes if you read the presentation is more security for/around JS.
What he actually proposes if you read the presentation is more security for/around JS.
Yes, but I do believe that it would be best to rethink JavaScript. Essentially you could start from a safe subset of JavaScript that remove the global nonsense and rebuilds with a proper object model that restricts how you can get a reference to an object.
Douglas Crockford makes a proposal for this in a recent presentation: http://www.slideshare.net/webdirections/douglas-crockford-aj...
Douglas Crockford makes a proposal for this in a recent presentation: http://www.slideshare.net/webdirections/douglas-crockford-aj...
Computer security problems aren't that different from "real world" ones: it's a matter of trust. Either you believe that someone will do what you want, or they deceive you. While it's reasonable to have some systemic protections, at some point it is entirely up to the individual.
You might leave someone to watch over your house, and they could decide to trash it; that violates your trust, but it doesn't hurt your neighbor's house. You don't tie up every citizen to make it impossible for anyone to ever trash another house; you simply deal with that one trust violation, and learn from the experience. Also, you should tell others, to minimize how many suffer the same fate.
You might leave someone to watch over your house, and they could decide to trash it; that violates your trust, but it doesn't hurt your neighbor's house. You don't tie up every citizen to make it impossible for anyone to ever trash another house; you simply deal with that one trust violation, and learn from the experience. Also, you should tell others, to minimize how many suffer the same fate.
I said as much in the blog comments, but I'll repeat it here too. The issues noted in the presentation, plus the fact that the language is a bit of a dog, is why I suggested proof-carrying code as a replacement for Javascript:
http://www.plsadventures.com/2009/08/worrying-trends-in-prog...
(and got pretty well flamed for it, too)
http://www.plsadventures.com/2009/08/worrying-trends-in-prog...
(and got pretty well flamed for it, too)
So let's presume that we come up with a better alternative, which this article doesn't suggest. By what mechanism do we replace all that is out there and ensure that the current js is not used anywhere by any of the bazillion web sites currently using it?
I think the horse is well out of the barn.
I think the horse is well out of the barn.
Why is the language insecure in all of this? What is it, in the ECMAScript Spec, which makes the language insecure? Programmers who do not know how to write secure code will leave security holes when programming in any language.
I find JavaScript to be wonderfully expressive, allowing me a great amount of power.
I find JavaScript to be wonderfully expressive, allowing me a great amount of power.
Javascript is now being used even in remote controllers today. See http://www.webdigi.co.uk/blog/2009/rise-of-javascript/
It certainly is a useful language.
It certainly is a useful language.
And again a link for which the only interest is the short, attracting and more or less controversial title.
I read the title in the spirit of the classic Unix-Haters Handbook: It is both tongue-in-cheek and brutally honest at exactly the same time.
Though much of the suckage which inspired the the Unix-Haters Handbook has been fixed... or at least finessed [1]... it's still the case that there are aspects of Unix that suck. But of course that doesn't matter. Unix isn't going anywhere fast. It has outlived many of its alternatives, and the remaining alternatives are either worse or have little traction. None of the Unix-Haters were under any illusions about this: They would point out various features that were done better in other operating systems (old-school Mac OS, Windows, OS/2, perhaps even the Commodore Amiga though I don't remember that, and of course the late, lamented Lisp machine) but none of them seriously thought that any of these things had a chance in hell of unseating Unix, just as I suspect that jgc does not seriously think that Javascript will be replaced anytime soon.
Javascript and the DOM, like Unix, isn't something that was designed by a rational committee of experts, but it snuck up on all of us and is now ubiquitous, and the social and economic forces that built it in the first place will not let it disappear easily. To paraphrase Crockford, we should all thank god that JS is as good a system as it is, given the inauspicious conditions that surrounded its birth. But I'm perfectly prepared to hear jgc's argument that its security problems are so dire that you can't really fix them while still calling the result "Javascript". That's important information. The first step in working through a hopeless situation is to understand the size and shape of the hopeless part.
---
[1] Or, let's face it, in some cases we've all just joined hands, smiled, and agreed to love the suckage. It's the industry standard!
Though much of the suckage which inspired the the Unix-Haters Handbook has been fixed... or at least finessed [1]... it's still the case that there are aspects of Unix that suck. But of course that doesn't matter. Unix isn't going anywhere fast. It has outlived many of its alternatives, and the remaining alternatives are either worse or have little traction. None of the Unix-Haters were under any illusions about this: They would point out various features that were done better in other operating systems (old-school Mac OS, Windows, OS/2, perhaps even the Commodore Amiga though I don't remember that, and of course the late, lamented Lisp machine) but none of them seriously thought that any of these things had a chance in hell of unseating Unix, just as I suspect that jgc does not seriously think that Javascript will be replaced anytime soon.
Javascript and the DOM, like Unix, isn't something that was designed by a rational committee of experts, but it snuck up on all of us and is now ubiquitous, and the social and economic forces that built it in the first place will not let it disappear easily. To paraphrase Crockford, we should all thank god that JS is as good a system as it is, given the inauspicious conditions that surrounded its birth. But I'm perfectly prepared to hear jgc's argument that its security problems are so dire that you can't really fix them while still calling the result "Javascript". That's important information. The first step in working through a hopeless situation is to understand the size and shape of the hopeless part.
---
[1] Or, let's face it, in some cases we've all just joined hands, smiled, and agreed to love the suckage. It's the industry standard!
It was a very interesting article. My eyes popped approx every 1.5 pages.
really? the only interesting part of presentation you found to be the title? it was quite opposite for me - very interesting examples/proposals he has there under inflammatory attention-seeking title...
Sorely lacking from this article, even if we take it at face value, is any workable alternative solution.
What reading list do you recommend for a javascript security newb?