I don't see how Lua is easier to sandbox.

I'm a bit surprised at the use of Lua, given that JavaScriptCore is already there. But I wouldn't be surprised if Lua was just something that the team was already familiar with. Lua is tiny, so it's not like it adds a significant dependency.

As you said Luna is tiny, which makes it easier to sandbox. A smaller system with a more limited set of behaviours and features is much easier to test and verify.

I guess, but (1) JavaScript is already there, so using it adds no new attack surface; (2) JS engines get more scrutiny; (3) sandboxing isn't as important anyway since the interpreter only runs trusted code.

There was a topic a few months ago about running JavaScript code in ring 0. People used similar arguments to claim it was safe enough. A v8 engineer chimed in to explain the reality of JavaScript engines.

https://news.ycombinator.com/item?id=17186842

JavaScriptCore has a huge surface area. It is measured in tens of megabytes, whereas Lua is measured in hundreds of kilobytes. Wikipedia chose Lua because it was small enough that they were able to audit every line of code for security. Verisign approached Lua the same way for their high-reliability servers.

Consider the complexity of JavaScriptCore. Their new-ish "FTL" optimization engine stands for "Fourth Tier LLVM", which means there are at least 4 levels of runtime optimizations JSCore performs on code, which is a lot of non-trivial complexity. And JIT means they cannot utilize no-execute bits in hardware.

Then there is the memory and power-consumption. Lua's footprint for a VM instance is tiny. It is also a very efficient language, even in interpreted form. JavaScriptCore is comparatively heavy in both regards.

Remember that Apple Watch still does not have Safari and JavaScriptCore is not available for watchOS developers. Presumably this decision is partly influenced by memory and performance constraints. Lua is trivial to get working well on watchOS.

For a core feature, it makes sense to have minimal dependencies with a minimal footprint so plenty of room is left for user applications. Remember that Apple probably has a bunch of skunkworks devices in their labs they hope to productize someday. And many of these might be tiny portable devices with minimal hardware capabilities, like Apple Watch (or remember all the different iPods?).

Lua's tiny implementation and extreme portability (written in pure ANSI C) make it well suited for this role. Apple won't have to port Lua to every new experimental CPU architecture they try, whereas JavaScriptCore has a lot of platform specific #ifdefs which have to be dealt with for every new platform.

> There was a topic a few months ago about running JavaScript code in ring 0. People used similar arguments to claim it was safe enough. A v8 engineer chimed in to explain the reality of JavaScript engines.

I've worked with SpiderMonkey and have known the team for about a decade now. I'm aware of the complexity :)

> Consider the complexity of JavaScriptCore. Their new-ish "FTL" optimization engine stands for "Fourth Tier LLVM", which means there are at least 4 levels of runtime optimizations JSCore performs on code, which is a lot of non-trivial complexity. And JIT means they cannot utilize no-execute bits in hardware.

FTL is gone, I believe. But anyway, JSC is not just a JIT. If you're worried about the JIT, just use an interpreter.

> Then there is the memory and power-consumption. Lua's footprint for a VM instance is tiny. It is also a very efficient language, even in interpreted form. JavaScriptCore is comparatively heavy in both regards.

JSC uses a hand-written assembly interpreter. I would be shocked if it beat Lua in performance.

> For a core feature, it makes sense to have minimal dependencies with a minimal footprint so plenty of room is left for user applications.

JSC has been shipping since the first version of iOS in 2007. Tons of apps use embedded WebKit already.

> Remember that Apple Watch still does not have Safari and JavaScriptCore is not available for watchOS developers.

This may well be the reason.