The ostensibly domain-specific interpreter tucked away in NSFunctionExpression is interesting, and I think it would be reasonable for Apple to try to rid their platforms of all such interpreters (with the inevitable exception of JavaScriptCore exclusively for the web). But I think the most important part is this:

> The expressive power of NSXPC just seems fundamentally ill-suited for use across sandbox boundaries, even though it was designed with exactly that in mind.

It reminds me of the YAML deserialization vulnerabilities that plagued Rails. It's clearly necessary to ensure that any data received from an untrusted source is merely data, with no generic way of instantiating arbitrary classes.

Agreed. I worked in closure for a hot minute and learned of a pretty nice solution they had to this called EDN (pronounced "eden"): https://github.com/edn-format/edn

I suspect it was inspired by the whole "data is code" philosophy of lisp languages, but it seemed like a well thought out pattern for encoding and decoding data in relatively safe ways. It had a way of tagging fields to indicate that they required processing to derive the decoded value, e.g.

    #inst "1985-04-12T23:20:50.52Z"

Would be interpreted as a Java DateTime object, but one could just as easily read the raw data without respecting those tags if one didn't trust the safety of the data being read.

In effect the format split the work of parsing the data from decoding the data, which is a distinction I haven't seen in many other data encoding mechanisms.