Transcript
Sills: I'm going to be talking today about running third-party JavaScript safely. Code has power. There's this great quote from the structure and interpretation of computer programs. It says, "In effect, we conjure the spirits of the computer with our spells." We conjure the spirits of the computer with our spells. As programmers, we have tremendous power. We can use this power for good or we can use it for evil. Code can read our files. It can delete our files. It can send all of our data over the network. It can drain our bank account, and much more.
My name is Kate Sills. I work for a startup called Agoric. There's two things that you should probably know about Agoric. Number one is that we are building a smart contract framework that we hope can handle millions of dollars in digital assets. Number two, we're doing so in JavaScript, which probably sounds like a terrible idea. I'll explain how we're able to do that. First, who's primarily a JavaScript developer? We got a lot of JavaScript developers. Who's primarily developing in something else, Python, Rust, anything?
Third-party JavaScript Code
At Agoric, we're at this intersection of cryptocurrencies and third-party JavaScript. We use a lot of JavaScript packages. It turns out that this intersection is just a really A-plus target for attackers. What's going on here? Npm has some great statistics. They say that there's over 1.3 billion downloads of npm packages on an average Tuesday. That's a lot of downloads. JavaScript has this rich culture of code reuse. Here are some more stats from npm. There's over 800,000 packages on npm, making it the largest code repository in the world. The average modern web application has over 1000 dependencies. Npm has this great quote, they say that over 97% of a modern web application comes from npm. An individual developer is responsible only for the final 3% that makes their application useful and unique. We can think of all the time that's saved by not having to reinvent the wheel. That's hundreds of millions of hours of coding saved. I think this is a really beautiful example of the cooperation that humankind is capable of. We have this rich civilization of code. We should be proud and npm should be proud of everything that they've accomplished. We have specialization. We have experts. We don't have to build everything ourselves. As long as we can rely on all these package developers to be good people, we're fine. Not everyone is good. Not everyone is good all the time. People make mistakes.
As Super Hans from "Peep Show" once put it, people like Coldplay, and voted for the Nazis. What happens when things go bad? Using other people's code is risky. It's risky, because whatever package we install, can basically do whatever it wants. There are no restrictions. We may not find out what happens until it's too late. In real life, we have this rich ecosystem. We're able to buy and use the things that other people create. We don't have to grow our own food or sew our own clothes. Imagine if everything that you bought, all the interactions that you had, over the course of the day, that coffee that you bought this morning. Imagine if that had the power to completely take over your life. That'd be ridiculous. It'd be absurd. That's the situation that we're in right now with JavaScript packages, we can't safely interact with the things that other people have made without it potentially ruining us.
Authority in Node.JS
Let's look at how authority works in Node.JS. I'm going to focus on Node.JS for a bit here. By authority, I mean the ability to do something. Authority in Node comes in through the use of imports. You can require certain modules, you can require the built-in modules. It comes through the use of global variables. It turns out that anyone or anything, can import modules, especially the Node built-in modules. They can use the global variables. The effects of this use, it's often opaque to the user. There's nothing that pops up and says, "Alert, your files are being sent over the network." Any of these usages could be in packages that are many levels deep. That means that you may think you're installing something that's very simple, very safe, but, actually, it could be doing something very malicious behind the scenes. Node provides no mechanisms to prevent this access.
To illustrate this, let's imagine that we're building a web application. We want to add a little excitement. Let's say that we install this package, addExcitement that adds an exclamation point to the end of a string. If this notation isn't familiar, this is just a Template Literal. We're literally adding an exclamation point. Our hello turns into hello! It turns out that addExcitement could actually be written like this, and we wouldn't know any different. From the user's perspective, the functionality is the same. We're still adding the exclamation point. Behind the scenes, we're getting access to the file system. Fs is the built-in Node module for accessing the file system. We're also getting access to the network through HTTPS.
An attacker could potentially say fs.readfile, let's say that's my Bitcoin private key there. They could essentially send this over the network. This code is simplified a little bit, but I think you can see what's happening. Just through access to the Node built-in modules, any attacker through the installation of pretty much any package can read all of our data and send it over the network. In the cryptocurrency world where we're dealing with wallets that may hold private keys that are holding digital assets, this is a big deal. This is a problem.
Steps To Read Any File
Let's go over to steps to read any file. Number one, we had to get the user or another package to install our package. Number two, we had to import the Node built-in module fs to get the file system. Number three, we had to know or we can guess, and there's no penalty for guessing, the file path. That's it. That's all we had to do. This is actually a pattern of attacks. You might have heard of the event-stream incident that happened in 2018. What happened was, there was this open-source package maintainer, Dominic Tarr, who had over 100 open-source packages that he was responsible for. A volunteer came up to him and said, "I'll take care of the event-stream package. Let me take it off your hands." Dominic Tarr was like, that sounds great. Someone's going to be doing the work that I've been doing. This volunteer, they made some changes. They also managed to insert a malicious package dependency in the event-stream package. This malicious package was specifically targeted for a specific cryptocurrency wallet. What it tried to do was it tried to take the Bitcoin private keys, exfiltrate them, or send them over the network, and ultimately steal Bitcoin. We saw this pattern again last year with the electron-native-notify package. This was trying to target cryptocurrency. It was also using the file system in the network. This one, it was caught by npm, luckily. That's great, but I think we're going to see this pattern repeat itself unless we're actually solving the root cause of this problem.
Solutions
What are the solutions? There's always the tried and true solution of just ignoring it, and then hopefully, it'll be ok. People are actually really trying to solve this problem. One of the solutions that people have come up with is, just don't use open source. Write everything yourself. Believe it or not, there are companies that are actually doing this because the stakes are so high. We can see that this isn't a very scalable solution. It's not very practical for all of us here. If I had to write everything myself, I wouldn't get very much done. We would lose the millions of coding hours that we save by reusing other people's code. I think this solution isn't very practical.
Another solution that people have been proposing is to fund open-source developers. Let's pay someone to maintain these packages. If someone is paid to be responsible for them, then hopefully, the security will be better. I think this is good. We need to pay open-source maintainers. We need to pay open-source developers. Just because someone is responsible doesn't mean that they can't be compromised, or they don't make mistakes.
Lastly, another solution that people suggest is that we should audit open-source code. This is also a good suggestion. Code audits are not a panacea. They can't solve everything. There are things that code audits miss. Here's an example of the utility of code audits. Does anyone know what this code does? Any guesses? This is actually doing a window.fetch. This is accessing the network. How it's able to do this, is that, that first line, the const i is fetch, just shifted over one character. Then the self in the third line, there is actually an alias for window. You can see, if we're just manually looking at code, we're trying to find code that's problematic. I would probably skim over this and not notice at all that something problematic is happening. This goes to show that doing a manual review of code is very difficult. Even if we had infinite time to do a review, we might not find this. We definitely don't have infinite time.
If we go back to the steps to read any file, we can see that a lot of the solutions, they focus on number one. They want us to be able to trust the open-source maintainers. They want us to only install packages that we trust. I think improving this is all admirable. I don't want to stop people from doing that. I think what we should really be focusing on is number two, and number three. What happens when the malicious code tries to import the file system? What if it can't import fs? Or, what if the malicious code knows the file name or knows the file path and that doesn't help it at all? There's this great quote from Alan Karp that goes towards this point. He says, "The mistake is in asking, 'How can we prevent attacks?' When we really should be asking, 'How can we limit the damage that can be done when an attack succeeds?' The former assumes infallibility, the latter recognizes that building systems is a human process."
JavaScript is Especially Good at Isolation
What we actually need is code isolation. It turns out through an accident of history that JavaScript is especially good at code isolation. JavaScript has a clear separation between the pure computation and access to the outside world. Typically, the host, the browser, or Node is the thing that provides access to the outside world, whereas TC39, or the JavaScript Standards Committee has focused on the pure computation part. Through an accident of history, we have this clear separation. If we sever that connection, we can actually get rid of a lot of the harmful effects. This is not necessarily true of other languages. As JavaScript developers, we're actually in a really good place to start with for code isolation.
JavaScript already has a concept of a realm. It's not very widely known. The realm is in the spec. What a realm is, is the environment in which code gets executed. Each web page is its own realm. Code that executes on one webpage, can't necessarily affect the code that executes in another. Within a realm, the realm starts off with all of the objects that you would need when the code starts running. That includes things like object, function, array, and we call those primordials or intrinsics. A realm also consists of a global object in a global scope. Historically, one way that people chose to isolate code was in the same-origin iframe. Using the iframe is clunky. We want to be able to create realms without the overhead of iframes.
Realms
That was the concept behind a TC39 standard's proposal called realms. What their thinking was, why don't we actually create these realms without the overhead of an iframe, without the DOM? What if we could do it in a very lightweight and easy way? Creating a new realm creates a new set of these primordials. A realm is almost a perfect sandbox. Whatever code is isolated in a realm is isolated from the rest of the world, and it can't cause any effects in the world outside itself. Malicious code that runs in a realm can do nearly no damage. This is a proposal before TC39. It's currently at stage 2, which is draft. The fact that it's a proposal means that we're hoping to push it forward so that it actually gets into the JavaScript language itself.
What if realms themselves are too heavy? Can we go even lighter than that? Rather than duplicating all of the primordials, the things like object, array, function, that thing. A featherweight compartment just shares them, and this makes the compartment much lighter. A newly created compartment doesn't have access to the outside world or any of the post provided authority. We can safely evaluate code in that compartment.
Let me show you how this works. I'm going to take the code that we saw earlier, I'm going to execute it just here in the console. If it succeeds, then we'll hit this URL. The attack was successful. Now I'm going to execute the same code. I'm going to do it within a compartment. I don't know if you can see at the bottom here but it says, cannot read property fetch of undefined. Window or self was not even defined within this compartment. It had no access to the outside world. This is great because we didn't even have to read this code. We didn't even have to understand what it was doing. We were still protected.
Prototype Poisoning/Pollution
We still have a problem. That problem is known as prototype poisoning or prototype pollution. This has been a recent scourge. There's been, I think, at least 20 vulnerabilities that have been found in 2019, including ones in Lodash, Angular, and jQuery. There is an Angular example here. What's happening with prototype poisoning or pollution, is that, let's say we get a string from a user. Then we try to JSON parse it. Then we try to merge it with an object that we already have. That seems fine. The problem is anything that has the double underscore _proto_ will actually be adding a key to the prototypical object. All of the objects within our realm will have that key. You can imagine an attack where some mechanism is restricted to only objects that have, admin equals true, or something like that. An attacker could just put in proto, and then, admin equals true. Then all of a sudden they have access to everything. You can imagine that attack.
Here's another example of prototype poisoning. If we're able to modify array.prototype.map, then we can actually change it to do whatever we want. We can retain the original functionality. From the outside, it looks the same. Under the hood, it's actually sending all of the data in the array over the network. Not great. To solve the problem of prototype poisoning, or prototype pollution, what we can do is we can use these compartments, but we're also going to use transitive freezing or what we call hardening. We want to try to freeze all of the primordials so that when someone tries to change the behavior of map, or when someone tries to change object, they simply can't because it's frozen.
SES or Secure ECMAScript that does this hardening, that does this freezing, is pretty easy to use. All you have to do is do an npm install. Then this particular API is actually new, over the last week or so. Things are really rapidly in flux. What you do is you import a lockdown function. That lockdown function, once you call it, it freezes all of the primordials in the realm that you're already in. Then once you do that you can create new compartments within that realm that will allow you to safely execute third-party code. You might notice that we have to stringify the code right now. We're still working on the developer ergonomics issues.
Principle of Least Authority (POLA)
What if our code actually needs a lot of authority? You might be saying isolation is all well and good. My code needs access to the file system. My code needs access to the network. There's this thing called the principle of least authority, or POLA. It's also known as the principle of least privilege, but POLP doesn't sound as great. What POLA means is that there should be no ambient authority and no excess authority. By no ambient authority, we mean that by default the code shouldn't have any authority. You know how in your normal Node programming, you can import all of the Node built-in modules. You can install scripts. You can do all that stuff. We shouldn't be able to do that under POLA. The authority should be explicitly granted by something external. It also means no excess authority. Only the bare minimum authority should be given. Don't give any authority more than is necessary.
Example: Command Line ToDo App
Let's look at an example. Let's do a simple command line ToDo app. We're only going to be able to add and display tasks. We're not going to be able to delete them. The tasks are going to be saved to a file. It's going to be very simple. We're going to use two packages. We're going to use chalk and minimist, both of which have over 35 million weekly downloads. What chalk does is that it adds color to the console logs. You might be red, green, blue, whatever it is. Minimist just parses the command line arguments for us. Here's an example of it in use, let's add a todo to pay the bills. Let's add a todo to do laundry. Then let's add pack for QCon. Let's set that to priority high. It'll show up in red.
If we analyze the authority, things start getting really interesting. First, the command line todo app, it's going to need access to the file system. Because we're going to be reading and writing to a file. It's also going to use minimist. Minimist is pretty much a pure function. It doesn't need to use a lot of authority. It's just going to be acting on the arguments that we give it. Chalk is very interesting because it uses a package called supports-color. This chalk package that is really about changing the color of the console logs, is going to be using supports-color, which in turn uses process, which is a global variable, and OS, which is a built-in Node module. If we have access to process, it gets very interesting, because we can call process.kill. All we need to know is just the process ID, and we can kill any process. If we have access to OS, we can set the priority of any process, just by knowing the process ID. This very simple chalk module actually has the power to kill any process and set the priority of any process.
How can we use SES? How can we use Secure ECMAScript to enforce POLA? Let's go over to patterns that we can use to minimize authority. The first is going to be attenuation. We're going to want to attenuate our own access to the file system. We're going to want to attenuate chalk's access to process and OS. The second thing that we're going to go over is virtualization. We can intercept the information that chalk receives and we can change it to whatever it is that we want.
To attenuate our own access to fs, let's write a simple function that will check the file path. If it's not the file that we expect it to be, we're going to throw an error. Pretty simple. To actually attenuate, we'll take the original fs object. We're going to throw away all of the methods that we don't actually want to use. We're just appending and reading from a file. We actually only need the appendFile method and the createReadStream method. In each of these, you can see that we are calling the checkFileName method that we saw earlier, so that if it's not the exact file name that we expect, we're going to throw. There might be a question of why do you want to attenuate your own authority? Don't you trust yourself? People make mistakes. People get compromised. It's actually part of the best practices for POLA to try to attenuate your own authority.
Chalk's access to OS and process. First, let's try to get rid of all the ambient authority. If we're executing this within a SES compartment, we've already solved that problem. We actually can't import OS and process. Actually, what we're going to want to do is to be able to parse in that authority instead in the form of arguments. We rewrite chalk so that it takes in OS and process. We do the same thing to supports-color as well. The reason why supports-color needed OS was simply to get the string for the release. This is crazy, but actually, if I remember correctly, there was some color blue that doesn't show up on a certain Windows system. It needed access to OS just to find out if it was that particular type of machine, so that it would know how to change the color of blue, so it'd show up. That incredible authority that we thought we needed, it actually doesn't need at all. What we can do is take the original OS object, and just parse along the release and not parse along anything else. That was attenuation.
Virtualization
Then for virtualization, we're going to actually take the process, global variable, and we're going to only parse along the things that are necessary. You can see we're creating a new hardened or transitively frozen process that has mostly the same thing. For a platform, we can actually put whatever we want there. I'm using a Mac right now but we could put win32 if we want to. We can effectively intercept the information that the chalk package gets.
Privilege of Least Authority and Access Control
When it comes to enforcing POLA and access control, it turns out that actually the best way to enforce POLA is to use something called object capabilities, and to not use identity based access control or access control lists. This is very simplified, but typically in access control you're mapping people or accounts to some centralized permissions. Does Susan have the permission, read_location? Does David have the permission, write_to_file? Very simplified, but I think you get where I'm going. Then performing an action. It does a lookup in this table to see if whoever was originally calling it has that permission. That's the typical case.
Object Capabilities
In object capabilities, there's no separation of a designation from authority. There's no centralized permissions. We saw object capabilities already in our attenuation patterns. Basically, what you're doing is that you have the authority to do something if you have a reference to the object that has a method that allows you to actually do that. Your designation and authority are actually embedded in the same object and all of the authorities and the methods themselves.
JavaScript has unforgeable references. That means that if we don't have access to a specific object, there's no way that we can fake our way or guess our way into getting there. We only have access to an object if someone grants us access to it. It has a clear separation from the outside world. JavaScript is actually very well designed for object capabilities and the use of that pattern. Under object capabilities, it's very easy to reason about authority, because the graph of which objects have references to which other objects, is actually the graph of authority. If you're interested more on object capabilities, I really recommend Chip Morningstar's post at habitatchronicles.com. It's a great read. Let's go over SES as used today. Realms is at stage 2, SES is at stage 1 at TC39. People have already started using it.
Moddable's XS
First, Moddable is a company that's doing JavaScript for the Internet of Things. They have this JavaScript engine called XS that's specifically for embedded devices. They've already built SES for XS. They use SES to enable users to safely install apps using JavaScript on their IoT devices. You can imagine, I think they have a whirlpool washer, I think they have an oven, light bulbs, other things like that, that are already in JavaScript, which is pretty insane but pretty cool.
They gave a demo recently where they allowed users to write scripts that would run on an LED light bulb. What's really cool is that they're able to restrict the scripts so that, number one, the scripts had no access to any of the configuration settings. This has actually been a big problem in IoT devices, is that, something that you're running could actually get access to your Wi-Fi password, something like that. The scripts also were limited in the maximum brightness so it didn't blow out the LED light. Lastly, they restricted the frequency of change so that someone couldn't write a script that would trigger a seizure or anything like that.
MetaMask's LavaMoat
Another example is MetaMask's LavaMoat. MetaMask is one of the main Ethereum wallets. They're using SES to pin down their supply chain. They have a Browserify and Webpack plugin that puts every dependency that they use into its own SES compartment. They're using a different approach than what I just went over. They're using a backwards compatible approach. They don't want to rewrite all of their different dependencies. Instead, what they're doing is that they're creating a manifest of the authority that's currently being used. Then that is the only authority that those packages get.
Let's see if we can actually see this. They have a great visualization here. Here's all of the dependencies that they use. On the left here is the manifest that's created that shows the authority that's being used, like the global variables, things like that, and the other packages that are being imported. The green is supposed to be safer. The red is supposed to be more harmful. We can also see what it looks like without SES. All of them are red because we would have no idea what any of them are doing. They could all be doing things under the hood.
MetaMask Snaps
MetaMask, they're also using SES in a product that they call Snaps. What was happening in MetaMask was that all of these different projects were asking for new features for their Ethereum wallet. It was getting very political, which features are we going to add next? How do we choose? What they decided was that, let's just allow the users to write their own scripts. Let's create a plugin platform so that we can actually allow custom behavior into MetaMask, and do so safely. This shows, along with the light bulb example, that SES is not just for securing JavaScript dependencies, it can also enable you to provide a plugin platform.
Salesforce's Locker Service
Salesforce, one of the primary co-authors of realms uses a version of realms in production in their Locker Service plugin platform, which is an ecosystem of over 5 million developers.
Agoric's Smart Contracts
Of course, we're using it at Agoric in our smart contracts. We use SES to allow users to upload their own smart contracts, what we call agreements enforced in code. They can upload them to our testnet and safely interact with each other.
SES Limitations
I want to be upfront about the limitations of SES. It's still a work in progress. The API has been changing. It changed recently in the past week or so. We're still working on performance and developer ergonomics. You have to currently stringify the code that you want to execute in this secure environment. Realms is at stage 2 in the TC39 proposal process, and SES is at stage 1.
Conclusion
In conclusion, SES provides nearly perfect code isolation. It's scalable. It's resilient. It doesn't depend on trust. It enables object capability patterns like attenuation. Most importantly, SES allows us to safely interact with other people's code. We can use your help. There's two repos here. One is the SES-shim. This will allow you to start using it. Then the other is for the SES proposal at TC39. Please check it out. Play around with it. Please find bugs, let us know.
Questions and Answers
Moderator: This actually goes back to some of the stuff you talked about in the JavaScript panel earlier today, which was, because there are so many modules in the Node ecosystem. The thing for me that would be really awesome is if I'm importing a module at the top level, do these tools analyze everything all the way down the tree? I can just say this thing and all of its dependencies only have access to this one method in OS alone. Does that work?
Sills: Yes. If you're only using the SES compartments, and you're not using anything else, it won't do any analysis for you. It will disallow any access to the outside world whatsoever. You start off by default with completely no access. You start off from a very safe position, that doesn't give you a lot of efficiency or ability to use it. The approach that MetaMask has been taking, where they try to look at the authority that each of these packages is requesting, and then they create a manifest that restricts the access to that specific authority, I think is a pretty solid approach. The event-stream incident that we saw, it was a sudden escalation of authority, that was unanticipated. It went unnoticed for the most part. If we had a manifest that we were using to restrict authority, that escalation just won't be possible. I think it's still in the early stages, we're going to see patterns of use. We're going to see tools being built to help people try to decide what authority certain packages should get, and that thing. I know in the panel, we talked earlier about having the possibility of being able to look at what packages are using. Maybe when we're searching through npm, we're actually able to see what authority is being requested and we can decide whether or not to use a package based on that. I think it's very early. It's in its infancy. We haven't necessarily seen all the patterns of use that we're going to see in the future.
Participant 1: Have you considered going further and actually prevent the imports? If they're not going to be safe, or they are going to contain things that you are not going to authorize just to prevent imports all together so they don't build up on your code base.
Sills: Have you considered disallowing imports entirely? Is that basically it?
Participant 1: Based on authority and other trends.
Sills: By default, if you're executing the code in a SES compartment, you can't import anything. I think generally that would be the approach that we recommend is that anything that you do actually have to import, if you're writing everything yourself, if you're starting from scratch and you really want it to be secure, parse those in, in terms of an argument. Because the way that imports work, it's nice, it's easy to use, but it does have that ambient authority problem where it's not clear that authority is being explicitly granted. I think the tools that people are building where even you may be able to import something, but the manifest that you have may determine that you say you're requesting something, but you actually get something else. The virtualization pattern that we saw. We'll have to see how those things evolve. We have a good start on that.
Participant 2: You had an example on there, whereby I think you were using the compartments in order to show that fetch was undefined. That was thrown back to the parent to say, we don't have that in scope. To your knowledge, there might not be as more of an open question, is there anything at work that almost acts as middleware between that and the parent to say, "This is trying to elevate privileges." Then you could almost lock that to Sentry, or something like that, in order to say, "These packages try to do something that we didn't anticipate it doing." Is there anything like that going on?
Sills: That's a Fantastic idea. I haven't seen anyone build that specifically as a package, but it does match. There's a pattern in object capabilities known as the power box pattern. My understanding is that it's very much like that. There may be a module that keeps track of the authority that's being used. If other packages request authority, then it gets to decide whether or not they get it.
Participant 2: The Powerbox.
Participant 3: You brag about doing it in code and [inaudible 00:39:50] in code, but [inaudible 00:39:53]. A lot of the problems you can solve [inaudible 00:40:04]. What case would do that by doing this at the JavaScript level?
Sills: I would advocate doing this at all levels, it just happens to be that the JavaScript level is where Agoric the company that I work at has been focused. We've been part of the TC39's Standards Committee, and have been really working at the JavaScript, at the language level. Of course, you can try to limit authority at all the different levels. That's even a better solution.
Moderator: From my perspective as a developer, this is really cool, if you can get it to work because I'm running up the source code. I want to release modules that people can use. I want to feel secure in myself that I'm releasing secure code. It strikes me that there has to be some tooling, ultimately, that lets me from day zero, from today, analyze my existing dependencies, produce a manifest file. That's not perfect because with dynamic code you can still have things that are not going to be discovered. I may move to a world where module writers are expected to produce manifests that say my module needs to be able to do X, Y, Z. Do you think we'll see that world?
Sills: Yes, definitely. There is a tool that's called TOFU, or Trusted on First Use that Bradley Farias who's part of the Node security group has been working on. That tool does pretty much exactly what you were talking about. It takes a package. Looks at the authority that's requested. Then prints out a manifest that says, "This is what the package says that it needs." If it's being nefarious, if it's being malicious, if it's requesting more authority dynamically. It won't get that authority. It takes the static analysis and creates this manifest. Then tries to use that to enforce the restriction of authority. That's one open-source developer's tool. I think as time goes on, we'll see that become more professionalized and easier to use.
Moderator: You seem to be quite familiar with the standard's process. Is there any movement at the standard's level to define a manifest file format?
Sills: I have not been part of a standard's discussion. That's some of my other co-workers. I'm hearing it second hand. There's definitely been movement. There's a proposal, I think, for module mapping, I'm probably getting that wrong, that seems quite tied to some of the manifest stuff. There's the possibility of using the module mapping to be able to do that restriction of authority, especially to say, when they request this, actually give them this instead. One thing that's been really exciting is TC53, which is the embedded devices standards committee. They have really embraced us. Moddable has been one of the companies that's been really big in TC53. It may be the case that the embedded devices community gets us before the rest of JavaScript.
See more presentations with transcripts
