Acotado por
el sistema operativo.
Un navegador ejecuta código no confiable de toda la web. Así que Searxly asume lo peor: la app está en sandbox de macOS, endurecida contra la inyección de código, y los pocos trabajos privilegiados que necesita se empujan a un auxiliar aparte. Incluso si una página se colara, queda encerrada.
El trabajo arriesgado no vive en el navegador.
Ejecutar el motor de búsqueda local necesita lanzar un proceso y escribir unos pocos archivos de configuración — exactamente los poderes que no quieres que tenga un navegador en sandbox. Así que esos trabajos se separan en un pequeño auxiliar XPC aislado. La app principal pide; el auxiliar hace el trabajo por un canal estrecho y tipado.
tipado · estrecho
~/searxng-localEl auxiliar expone un conjunto fijo de métodos — arrancar/parar el motor local, comprobar si está en marcha, leer/escribir/eliminar un archivo bajo una sola carpeta. No hay una puerta general de «ejecutar cualquier cosa».
Endurecido por todos lados.
App Sandbox
El target principal corre dentro del App Sandbox de macOS — el mismo aislamiento que exige la Mac App Store. El navegador no puede leer tu carpeta personal ni hablar con procesos arbitrarios; solo obtiene las capacidades que declara.
Hardened Runtime
Las protecciones de inyección de código, memoria sin firmar y validación de bibliotecas están activas, para que otro proceso no pueda inyectar código en Searxly. Las excepciones que quedan existen solo porque el motor JavaScript de WebKit las necesita de verdad.
Separación de privilegios XPC
Lanzar el motor local y las escrituras de configuración pasan por un servicio XPC dedicado, no por el navegador. La app principal no tiene poderes directos de Process() ni del sistema de archivos — una regla dura, no una convención.
Acceso a archivos acotado
Los métodos de archivo del auxiliar están acotados a la carpeta del proyecto de búsqueda local. Crea automáticamente los directorios que le pertenecen y no toca nada más en el disco.
Entitlements de mínimo privilegio
Los entitlements se limitan a lo que cada capacidad necesita — loopback para alcanzar el motor local, y el alcance de Keychain que requiere la cartera — y se revisan cada vez que se añade algo.
Firmado y verificable
Las builds están firmadas por código y el fuente se publica, para que lo que se ejecuta se pueda contrastar con lo escrito. La confianza se ancla en las firmas, no en nuestra palabra.
Si una página se vuelve hostil.
Un exploit de WebKit intenta leer tus archivos o ejecutar comandos.
El proceso no tiene privilegios de archivo ni de proceso que abusar: el SO los niega sin importar lo que haga la página.
Malware en el Mac intenta cargar una dylib en el navegador.
La validación de bibliotecas y las protecciones de inyección de código bloquean la carga de código sin firmar en el proceso.
Código comprometido intenta hacer que el auxiliar ejecute comandos arbitrarios.
El auxiliar solo expone un puñado de métodos concretos, con las ops de archivo acotadas a una carpeta: no hay un punto de entrada de «ejecutar cualquier cosa».
Asumir la brecha, contener el radio de impacto.
El navegador se trata como el código más peligroso de tu Mac — y se encierra en consecuencia.