6 ms·

Is Javascript an appropriate language for embedded applications? Given all of the security issues with IOT, I would think a 'stricter' language (e.g., Rust or

Is Javascript an appropriate language for embedded applications? Given all of the security issues with IOT, I would think a 'stricter' language (e.g., Rust or even Java) is better suited to this application.

m0meni 8y ago
Don't think it's necessarily the most appropriate lang, but it significantly lowers barrier to entry. One could also always use a compile-to-js lang if they want more safety e.g. TypeScript, Reason, ScalaJS, Kotlin, PureScript, etc.
- nine_k 8y ago
  If you can pick a language which is not JS, there's little point in carrying around such a resource-intensive runtime as JS requires. Consider compiling to LLVM and have a runtime statically adjusted to only carry what's actually used.
- bdcravens 8y ago
  Aren't there cases where low barrier to entry is a liability, not an asset?
matthewmacleod 8y ago
What security issues do you feel that using Rust or Java would avoid? I get the impression that the underlying argument here for many is that JavaScript lowers the barrier to entry and means less experienced developers will build less secure systems.
- pjmlp 8y ago
  I guess exploits due to logic errors caused by lack of strong typing.
starik36 8y ago
Tessel 2 allows both JavaScript and Rust for embedded devices and they do ok.
janoc 8y ago
The problem is not so much the security of Javascript itself but the craptacular state of the Javascript/Node ecosystem where pulling in random unchecked dependencies is the norm, for example. So lowering the barrier of entry to already bad IoT to Javascript programmers that have no clue whatsoever about embedded work is likely going to be a mess. Also the fact that you need a pretty beefy MCU (=costly and not just the price of the chip itself but also the stuff required to integrate it on the board - e.g. all the RF stuff) just to be able to run Javascript on it - and cripple it in the process, because then the majority of the processing capabilities of the chip are going to be wasted on interpreting Javascript code instead of doing something useful. I wish these guys luck if they think they can sell this software to embedded developers. There are some very good reasons why most embedded work is still done in C (not even C++!) and languages like Javascript on microcontrollers just aren't a thing - and not because they don't exist (e.g. Micropython, Forth, even Lisp ...)
- pjmlp 8y ago
  True, but there are also religious reasons against anything else that isn't Assembly or C89, when reading about experience reports about trying to move devs forward to C++ or even more up to date C versions.
  - village-idiot 8y ago
    It’s very hard to throw away decades of knowledge, libraries, and tooling.
    - rhapsodic 8y ago
      Especially when they get the job done quite nicely.
    - monocasa 8y ago
      And a lot of the time you don't have a choice. For example the Xtensa core in ESP32s doesn't have an upstream quality GCC or LLVM backend last time I checked.
avip 8y ago
The "security issues" with IoT are a consequence of security mindset (or lack thereof), not a programming language.
- freehunter 8y ago
  Agreed, Rust isn't going to matter over Javascript or even Visual Basic 6.0 if you're leaving port 22 open to the Internet with a username of "root" and a password of... well, just hit the enter key at the prompt, because there's no password set by default. Or exposing an anonymous TFTP server to the Internet, with a cron job running every hour to automatically flash any firmware that's dropped into there. That's pretty much par for the course in IoT security.
- illuminati1911 8y ago
  IoT development in general has bad security mindset, but it does not let JS slip away from the responsibility. Javascript's runtime interpretation + lack of strong typing is the real issue here and not just for embedded devices, but for any application.
  - allover 8y ago
    > Javascript's runtime interpretation + lack of strong typing is the real issue here and not just for embedded devices, but for any application. Explain how 'runtime interpretation + lack of strong typing' is significant for security. JS is memory safe which makes it a more secure choice than e.g. C/C++.
    - pjmlp 8y ago
      Unsanitized data given to eval() is an open door for exploits, whereas lack of strong typing makes it easier for logic programming errors, due to typos or implicit conversions. Memory corruption is just one possible attack vector.
      - allover 8y ago
        eval() is a pretty opt-in security vuln, and there are ways of doing the equivalent in statically typed languages. Logic errors are pretty hard to quantify, but if there're stats on vulnerabilities caused by logical errors that could only happen in languages without strong types I'd love to see them. Meanwhile there's a whole class of vulnerabilities attributable to lack of memory safety that are pretty easily distinguished, including some of the most notorious (cloudbleed, heartbleed).
z3t4 8y ago
JavaScript is very safe when it comes to things like buffer overflow and type errors. It will always try to convert to one type or another.

m0meni 8y ago

Don't think it's necessarily the most appropriate lang, but it significantly lowers barrier to entry. One could also always use a compile-to-js lang if they want more safety e.g. TypeScript, Reason, ScalaJS, Kotlin, PureScript, etc.

nine_k 8y ago
If you can pick a language which is not JS, there's little point in carrying around such a resource-intensive runtime as JS requires. Consider compiling to LLVM and have a runtime statically adjusted to only carry what's actually used.
bdcravens 8y ago
Aren't there cases where low barrier to entry is a liability, not an asset?

matthewmacleod 8y ago

What security issues do you feel that using Rust or Java would avoid? I get the impression that the underlying argument here for many is that JavaScript lowers the barrier to entry and means less experienced developers will build less secure systems.

pjmlp 8y ago
I guess exploits due to logic errors caused by lack of strong typing.

starik36 8y ago

Tessel 2 allows both JavaScript and Rust for embedded devices and they do ok.

janoc 8y ago

The problem is not so much the security of Javascript itself but the craptacular state of the Javascript/Node ecosystem where pulling in random unchecked dependencies is the norm, for example. So lowering the barrier of entry to already bad IoT to Javascript programmers that have no clue whatsoever about embedded work is likely going to be a mess. Also the fact that you need a pretty beefy MCU (=costly and not just the price of the chip itself but also the stuff required to integrate it on the board - e.g. all the RF stuff) just to be able to run Javascript on it - and cripple it in the process, because then the majority of the processing capabilities of the chip are going to be wasted on interpreting Javascript code instead of doing something useful. I wish these guys luck if they think they can sell this software to embedded developers. There are some very good reasons why most embedded work is still done in C (not even C++!) and languages like Javascript on microcontrollers just aren't a thing - and not because they don't exist (e.g. Micropython, Forth, even Lisp ...)

pjmlp 8y ago
True, but there are also religious reasons against anything else that isn't Assembly or C89, when reading about experience reports about trying to move devs forward to C++ or even more up to date C versions.
- village-idiot 8y ago
  It’s very hard to throw away decades of knowledge, libraries, and tooling.
  - rhapsodic 8y ago
    Especially when they get the job done quite nicely.
  - monocasa 8y ago
    And a lot of the time you don't have a choice. For example the Xtensa core in ESP32s doesn't have an upstream quality GCC or LLVM backend last time I checked.

avip 8y ago

The "security issues" with IoT are a consequence of security mindset (or lack thereof), not a programming language.

freehunter 8y ago
Agreed, Rust isn't going to matter over Javascript or even Visual Basic 6.0 if you're leaving port 22 open to the Internet with a username of "root" and a password of... well, just hit the enter key at the prompt, because there's no password set by default. Or exposing an anonymous TFTP server to the Internet, with a cron job running every hour to automatically flash any firmware that's dropped into there. That's pretty much par for the course in IoT security.
illuminati1911 8y ago
IoT development in general has bad security mindset, but it does not let JS slip away from the responsibility. Javascript's runtime interpretation + lack of strong typing is the real issue here and not just for embedded devices, but for any application.
- allover 8y ago
  > Javascript's runtime interpretation + lack of strong typing is the real issue here and not just for embedded devices, but for any application. Explain how 'runtime interpretation + lack of strong typing' is significant for security. JS is memory safe which makes it a more secure choice than e.g. C/C++.
  - pjmlp 8y ago
    Unsanitized data given to eval() is an open door for exploits, whereas lack of strong typing makes it easier for logic programming errors, due to typos or implicit conversions. Memory corruption is just one possible attack vector.
    - allover 8y ago
      eval() is a pretty opt-in security vuln, and there are ways of doing the equivalent in statically typed languages. Logic errors are pretty hard to quantify, but if there're stats on vulnerabilities caused by logical errors that could only happen in languages without strong types I'd love to see them. Meanwhile there's a whole class of vulnerabilities attributable to lack of memory safety that are pretty easily distinguished, including some of the most notorious (cloudbleed, heartbleed).

z3t4 8y ago

JavaScript is very safe when it comes to things like buffer overflow and type errors. It will always try to convert to one type or another.