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.
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?
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.
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 the browser that allows 20 scripts from different domains all come together in the same execution context each with full permission to do anything.
No, it's not, because well-formed, valid Javascript code is permitted to depend on this execution model.
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.
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 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.