It would be very interesting to read about how S-expressions became the language of choice for macOS's sandboxing, somehow sandwiched between the XML and JSON trends (e.g. plists were/are still? XML)

It's a fork of tinyscheme with some security improvements that's been in MacOS since 2007. It's used to compile all the rules down to a bytecode (similar to eBPF) that's evaluated by the kernel.

I don't have specific info on the rationale, but a powerful language with a small surface area that's easy to parse was probably an attractive choice for mid-2000s security code written in C.

Guix also chose scheme in 2010s, https://guix.gnu.org/manual/en/html_node/G_002dExpressions.h...

  (define build-exp
  #~(begin
      (mkdir #$output)
      (chdir #$output)
      (symlink (string-append #$coreutils "/bin/ls")
               "list-files")))

> I don't have specific info on the rationale, but a powerful language with a small surface area that's easy to parse was probably an attractive choice

I interviewed with the team that worked on this a few years back, and if I recall correctly one of them just liked scheme, and it was easy to embed.

It still compiles the rules down to a very basic bytecode: https://bdash.net.nz/posts/sandboxing-on-macos/#sandbox-poli...

Funfact of historical interest only: in NeXTSTEP/OPENSTEP, plists had a more JSON-type syntax, although of course it predates JS.

Relevant username? Anyway these are still used in e.g. Xcode projects

Yes! I was hoping someone would notice eventually, congratulations ;) (That's cool, I always thought they'd junked that when they got rid of Project Builder...)

To take a stab in the dark.

JSON and xml are both data representation formats, but the code snippets in the article seem more like a declarative language.

You could make a declarative language using JSON semantics, but maybe they wanted something more bespoke.

it’s also super duper easy to write an s-expression parser

The code snippets are purely declarative because they are reconstructed from the simple bytecode that the macOS sandbox library generates after evaluating the Scheme code. At that point any abstractions present in the source code are long gone and only predicates and actions remain.

If you look at typical SBPL source code you'll see it tends to contain a mix of straightforward, declarative `(allow …)` policies and custom functions/macros used to simplify repeated patterns. See https://github.com/WebKit/WebKit/blob/11b5279aec6113c661dac3..., for example.

Thanks for all the hypotheses and anecdotes! In either case I'm always a bit pleasantly tickled to know there's some Lisp lurking in macOS quietly doing its job.

TCC = Transparency, Consent and Control

Not to be confused with numerous other uses of the acronym.

I thought it was about https://en.wikipedia.org/wiki/Tiny_C_Compiler

Indeed, I opened the link wondering what Apple had fucked up in their sandbox policy that it could hinder an innocent C compiler.

I was guessing breakage of some JIT thing, though in hindsight that would probably be a bit out of character for tcc.

What, tcc -run?

My impression is that `tcc -run` is a trivial wrapper to the tune of `tcc && ./a.out`, which... actually I guess there could be a security sandbox that prevents you writing a file and then immediately executing it, but I'd expect it to be rarer. What I had in mind was that there have been true C interpreters, which are... weird, frankly, but whatever... but I could easily see one of them using a real JIT that could get tripped up by a sandbox. But this is just my incorrect first thought, obviously it's not really what's in play.

When using Desktop Linux, how are applications prevented from using camera, microphone, address book, etc without user agreeing to it?

That Mac vs. PC ad comes to mind.