Hacker News Reader

Comment by gdp | Hacker News Reader

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

View on HN

I was, of course, talking about the JavaScript DOM API: https://developer.mozilla.org/En/DOM

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.

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.

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.

You have chosen a particularly strange definition of "code".

  <script>
  var a = "hello, world";
  </script>

  <script>
  doSomething(a);
  </script>

My program is either syntactically invalid (because 'a' is undefined) or functionally incorrect (because it doesn't do anything) if you treat these blocks separately. This is Javascript code that relies upon script tags using the same execution context.

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

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.

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

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?

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:

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

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

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.

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

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!)

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.

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

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.

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

This is pretty much true for many languages; runtimes offering reflection usually make even private members available. OO protection is not a security feature.

Reply on news.ycombinator.com