3 ms·

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

by gdp 17y ago

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.

axod 17y ago
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.
- gdp 17y ago
  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.
  - axod 17y ago
    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.
    - gdp 17y ago
      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 http://news.ycombinator.org/item?id=843320
      - axod 17y ago
        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!
        gdp 17y ago
        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.
- ahoyhere 17y ago
  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.
  - axod 17y ago
    >> " 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.
DrJokepu 17y ago
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.
- gdp 17y ago
  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?

by gdp 17y ago

axod 17y ago

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.

gdp 17y ago
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.
- axod 17y ago
  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.
  - gdp 17y ago
    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 http://news.ycombinator.org/item?id=843320
    - axod 17y ago
      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!
      - gdp 17y ago
        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.
ahoyhere 17y ago
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.
- axod 17y ago
  >> " 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.

DrJokepu 17y ago

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.

gdp 17y ago
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?