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 ...)
Embedded already is a mess, these people can twiddle bits and bytes, but they're the most idiosyncratic and change-resistant folk among programmers. In some ways, they also have it really easy because their hardware is relatively fixed and their ecosystem evolves slowly.
> 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.
Another thing embedded developers like to do is requisition "minimal" hardware even when it doesn't matter (neither in terms of price nor power) and then screw over shipped hardware on new future requirements.
A lot of these MCUs spend most of their time doing absolutely nothing, having an interpreted language there isn't necessarily a problem (though Javascript or Python aren't really ideal here). Interpreted code can drastically lower the risks associated with OTA updates.
That's pretty much par for the course in IoT security.
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++.
Memory corruption is just one possible attack vector.
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).