C++ compiles to assembly (or machine code directly, which can be viewed as the same thing in different representation), just like TypeScript compiles to JavaScript (or a subset of it to Web Assembly - see the link at the end of my comment). My point is that in any language it's possible to escape from the "world" it builds by having something that lives outside of that world making it do unwanted things, circumventing any "in-world" protections this way. Just like I can defeat TypeScript's type safety by interacting with it from JavaScript, I can defeat C++'s type safety by interacting with it from assembly (or actually any other language that allows me to interact with a library - again analogous how I could use, say, CoffeeScript to "attack" TypeScript the same way I can use JavaScript for that).
In both cases I just think it's not right to call the higher-level language less of a language than the lower-level one it compiles to just because there are ways outside of the language's defined borders to make some features of it work not as expected, because then basically every language is actually not a language except maybe for the microcode implementation of opcodes inside the processor, and even then I could mess with it on a hardware level.
And for the above point it doesn't matter that the syntax of TypeScript is mostly (not entirely, by the way!) a superset of JavaScript. It is still its own language which just happens to borrow 99% of JavaScript's grammar, from that perspective. Crystal has also an extremely high similarity with Ruby and is still a different language entirely, which is clearer to see there since Crystal does in fact not compile to Ruby (or take C# and C++, or Visual Basic and QBasic, etc.), but the concept that similarity doesn't devalue either of the similar entities should apply in both cases.
You can also look at it the other way: I guess you would agree more that Elm is a separate language. Yet it also compiles to JavaScript and you can also trip it over by forcing it to do unintended things from the JavaScript side. The difference is that the syntax doesn't resemble JavaScript... but that doesn't affect any technical features of the language at the end of the day, so it should not be relevant! And for that reason I believe calling TypeScript a superset of JavaScript is helpful to start working with it but it just describes syntax similarity, which influences no other part of the language itself. (By the way, there is a project called AssemblyScript - which, using your point of view, could be viewed as a subset of TypeScript - that compiles to Web Assembly instead of JavaScript, albeit not all types are supported. Check out github.com/AssemblyScript/assembly...)
You will never figure out why it starts falling apart after entering PWN3D into the field just looking at the Elm file.
But if you see the rogue script inside the HTML file which reaches into Elm's "protected" world and breaks assumptions (in this case the assumption that reading the property of an HTML element never throws an error), you can see why it behaves like that.
(And in the same way I can of course pass unexpected things from JavaScript into the TypeScript world that break assumptions there, as you said. The only protection against this sort of thing would be to rigorously check every detail at runtime and that would kill performance obviously.)
As I was suspecting, it takes a script written in JavaScript. So you example will work in the case of a malicious attacker having the ability to inject scripts. But I hope we don't do that to our own applications!
I think that we can agree that in the context of an application, one won't use the JavaScript DOM API and the Elm DOM API at the same time or it would be pointless to use Elm.
But I'm really grateful for your example because this kind of attack might be harmful if an attacker has access to a flaw that allows him to inject scripts as I said. I wonder if using the MutationObserver API in some way can prevent the outside from mutating some HTMLElements (but it would probably mean blocking the Elm runtime from mutating it too).
MutationObserver won't help here, especially since my attack is against the JavaScript object representing that DOM element and not even the DOM element itself.
But one point I'm getting confused about right now is this: The reason I even chimed in in the first place was this statement of yours:
My point was to say that you can have interfaces, tuples, and everything you want, this won't prevent me from using your library, compile it to javascript and use the wrong types because in the runtime, it is JavaScript.
...which I read as "things outside of your bubble can interfere with your code at runtime in unexpected ways, rendering your compile-time protections useless", which in my opinion is true for pretty much every language, hence the example with Elm now.
If we are talking about staying inside the bubble anyway, then for me that point is moot, because in your own TypeScript code you also won't add scripts that hurt yourself...
And if you are just talking about the defined interfaces between the languages, then it's true that JSON data in ports won't be able to trip up Elm that easily but that's just because Elm does (expensive) runtime validation there for you. TypeScript leaves this task up to you. (But there are tools out there to help with that, such as the validator io-ts github.com/gcanti/io-ts/ which does runtime validation with given constraints and automatically also creates the correct TS types from it based on your constraints.) Just like in my C++ example: C++ also won't do runtime type checking (in fact it cannot because unlike JavaScript as "base language", machine code doesn't have types, just raw bytes in memory whose meaning is up to you to know).
And if that is actually the point here, then again I don't see how "doesn't do runtime type checking" makes TypeScript any less of a language than Elm. :-)
(Oh and, "in Elm you have to use Elm" isn't true either, because there are (hacky) ways to synchronously invoke your Elm function from JS without implicit type marshalling, and then you can pass arbitrary data to it including data with traps like properties that throw and so on. And since you are talking about other people using your code, you can't force them not to do that either, if they think they need it. See lazamar.github.io/calling-elm-func... for example. Just like only providing a .ts file won't prevent people from compiling it to .js and circumventing your types, providing only an .elm file won't prevent people from compiling it to .js and messing with it either. Or, as mentioned, providing only a .cpp file in C++ won't prevent people from compiling to an .a file and statically linking to it from a language that doesn't care about the original function signatures your C++ functions had.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Are you comparing C++ to TypeScript? I'm not sure I get the point.
As far as I can remember, C++ is not a superset of Assembly. Please, elaborate your point.
C++ compiles to assembly (or machine code directly, which can be viewed as the same thing in different representation), just like TypeScript compiles to JavaScript (or a subset of it to Web Assembly - see the link at the end of my comment). My point is that in any language it's possible to escape from the "world" it builds by having something that lives outside of that world making it do unwanted things, circumventing any "in-world" protections this way. Just like I can defeat TypeScript's type safety by interacting with it from JavaScript, I can defeat C++'s type safety by interacting with it from assembly (or actually any other language that allows me to interact with a library - again analogous how I could use, say, CoffeeScript to "attack" TypeScript the same way I can use JavaScript for that).
In both cases I just think it's not right to call the higher-level language less of a language than the lower-level one it compiles to just because there are ways outside of the language's defined borders to make some features of it work not as expected, because then basically every language is actually not a language except maybe for the microcode implementation of opcodes inside the processor, and even then I could mess with it on a hardware level.
And for the above point it doesn't matter that the syntax of TypeScript is mostly (not entirely, by the way!) a superset of JavaScript. It is still its own language which just happens to borrow 99% of JavaScript's grammar, from that perspective. Crystal has also an extremely high similarity with Ruby and is still a different language entirely, which is clearer to see there since Crystal does in fact not compile to Ruby (or take C# and C++, or Visual Basic and QBasic, etc.), but the concept that similarity doesn't devalue either of the similar entities should apply in both cases.
You can also look at it the other way: I guess you would agree more that Elm is a separate language. Yet it also compiles to JavaScript and you can also trip it over by forcing it to do unintended things from the JavaScript side. The difference is that the syntax doesn't resemble JavaScript... but that doesn't affect any technical features of the language at the end of the day, so it should not be relevant! And for that reason I believe calling TypeScript a superset of JavaScript is helpful to start working with it but it just describes syntax similarity, which influences no other part of the language itself. (By the way, there is a project called AssemblyScript - which, using your point of view, could be viewed as a subset of TypeScript - that compiles to Web Assembly instead of JavaScript, albeit not all types are supported. Check out github.com/AssemblyScript/assembly...)
Do you have any examples of unintended things you could do on the javascript side using Elm?
You mean the opposite, right? Like, breaking Elm using JavaScript? Since this is what we were talking about.
Here is an example: gist.github.com/CherryDT/7ced888d7...
You will never figure out why it starts falling apart after entering
PWN3Dinto the field just looking at the Elm file.But if you see the rogue script inside the HTML file which reaches into Elm's "protected" world and breaks assumptions (in this case the assumption that reading the property of an HTML element never throws an error), you can see why it behaves like that.
(And in the same way I can of course pass unexpected things from JavaScript into the TypeScript world that break assumptions there, as you said. The only protection against this sort of thing would be to rigorously check every detail at runtime and that would kill performance obviously.)
Interesting, thanks for your repro.
As I was suspecting, it takes a script written in JavaScript. So you example will work in the case of a malicious attacker having the ability to inject scripts. But I hope we don't do that to our own applications!
I think that we can agree that in the context of an application, one won't use the JavaScript DOM API and the Elm DOM API at the same time or it would be pointless to use Elm.
But I'm really grateful for your example because this kind of attack might be harmful if an attacker has access to a flaw that allows him to inject scripts as I said. I wonder if using the MutationObserver API in some way can prevent the outside from mutating some HTMLElements (but it would probably mean blocking the Elm runtime from mutating it too).
MutationObserver won't help here, especially since my attack is against the JavaScript object representing that DOM element and not even the DOM element itself.
But one point I'm getting confused about right now is this: The reason I even chimed in in the first place was this statement of yours:
...which I read as "things outside of your bubble can interfere with your code at runtime in unexpected ways, rendering your compile-time protections useless", which in my opinion is true for pretty much every language, hence the example with Elm now.
If we are talking about staying inside the bubble anyway, then for me that point is moot, because in your own TypeScript code you also won't add scripts that hurt yourself...
And if you are just talking about the defined interfaces between the languages, then it's true that JSON data in ports won't be able to trip up Elm that easily but that's just because Elm does (expensive) runtime validation there for you. TypeScript leaves this task up to you. (But there are tools out there to help with that, such as the validator io-ts github.com/gcanti/io-ts/ which does runtime validation with given constraints and automatically also creates the correct TS types from it based on your constraints.) Just like in my C++ example: C++ also won't do runtime type checking (in fact it cannot because unlike JavaScript as "base language", machine code doesn't have types, just raw bytes in memory whose meaning is up to you to know).
And if that is actually the point here, then again I don't see how "doesn't do runtime type checking" makes TypeScript any less of a language than Elm. :-)
(Oh and, "in Elm you have to use Elm" isn't true either, because there are (hacky) ways to synchronously invoke your Elm function from JS without implicit type marshalling, and then you can pass arbitrary data to it including data with traps like properties that throw and so on. And since you are talking about other people using your code, you can't force them not to do that either, if they think they need it. See lazamar.github.io/calling-elm-func... for example. Just like only providing a .ts file won't prevent people from compiling it to .js and circumventing your types, providing only an .elm file won't prevent people from compiling it to .js and messing with it either. Or, as mentioned, providing only a .cpp file in C++ won't prevent people from compiling to an .a file and statically linking to it from a language that doesn't care about the original function signatures your C++ functions had.)