A browser runs untrusted code from the entire web. So Searxly assumes the worst: the app is sandboxed by macOS, hardened against code injection, and the few privileged jobs it needs are pushed out into a separate helper. Even if a page slipped through, it's boxed in.
Running the local search engine needs to launch a process and write a few config files — exactly the powers you don't want a sandboxed browser to have. So those jobs are split into a small, isolated XPC helper. The main app asks; the helper does the work over a narrow, typed channel.
~/searxng-localThe helper exposes a fixed set of methods — start/stop the local engine, check if it's running, read/write/remove a file under one folder. There's no general "run anything" door.
The main target runs inside the macOS App Sandbox — the same isolation the Mac App Store requires. The browser can't read your home folder or talk to arbitrary processes; it gets only the capabilities it declares.
Code-injection, unsigned-memory and library-validation protections are on, so another process can't inject code into Searxly. The exceptions that remain exist only because WebKit's JavaScript engine genuinely needs them.
Launching the local engine and config writes go through a dedicated XPC service, not the browser. The main app holds no direct Process() or filesystem powers — a hard rule, not a convention.
The helper's file methods are scoped to the local-search project folder. It auto-creates the directories it owns and touches nothing else on disk.
Entitlements are kept to what each capability needs — loopback to reach the local engine, and the Keychain scope the wallet requires — and reviewed whenever something is added.
Builds are code-signed and the source is published, so what runs can be checked against what's written. Trust is anchored to signatures, not to our say-so.
A WebKit exploit tries to read your files or run commands.
The process has no file or process privileges to abuse — the OS denies them regardless of what the page does.
Malware on the Mac tries to load a dylib into the browser.
Library validation and code-injection protections block unsigned code from loading into the process.
Compromised code tries to make the helper run arbitrary commands.
The helper exposes only a handful of specific methods, with file ops scoped to one folder — there's no "execute anything" entry point.
The browser is treated as the most dangerous code on your Mac — and boxed accordingly.