Enfermé par
le système d'exploitation.
Un navigateur exécute du code non fiable venu de tout le web. Alors Searxly suppose le pire : l'application est en bac à sable par macOS, durcie contre l'injection de code, et les rares tâches privilégiées dont elle a besoin sont poussées dans un assistant séparé. Même si une page passait, elle reste dans sa boîte.
Le travail risqué ne vit pas dans le navigateur.
Faire tourner le moteur de recherche local exige de lancer un processus et d'écrire quelques fichiers de configuration — exactement les pouvoirs qu'on ne veut pas confier à un navigateur en bac à sable. Ces tâches sont donc séparées dans un petit assistant XPC isolé. L'app principale demande ; l'assistant fait le travail sur un canal étroit et typé.
typé · étroit
~/searxng-localL'assistant expose un ensemble fixe de méthodes — démarrer / arrêter le moteur local, vérifier s'il tourne, lire / écrire / supprimer un fichier sous un seul dossier. Il n'y a pas de porte générale « exécuter n'importe quoi ».
Durci de tous les côtés.
App Sandbox
La cible principale s'exécute dans l'App Sandbox de macOS — la même isolation qu'exige le Mac App Store. Le navigateur ne peut pas lire votre dossier personnel ni parler à des processus arbitraires ; il n'obtient que les capacités qu'il déclare.
Hardened Runtime
Les protections contre l'injection de code, la mémoire non signée et la validation de bibliothèques sont actives, pour qu'un autre processus ne puisse pas injecter de code dans Searxly. Les exceptions qui restent n'existent que parce que le moteur JavaScript de WebKit en a réellement besoin.
Séparation des privilèges XPC
Le lancement du moteur local et les écritures de configuration passent par un service XPC dédié, pas par le navigateur. L'app principale ne détient aucun pouvoir direct Process() ni sur le système de fichiers — une règle dure, pas une convention.
Accès fichiers limité
Les méthodes fichiers de l'assistant sont limitées au dossier du projet de recherche locale. Il crée automatiquement les répertoires qu'il possède et ne touche à rien d'autre sur le disque.
Entitlements au moindre privilège
Les entitlements sont limités à ce dont chaque capacité a besoin — le loopback pour joindre le moteur local, et la portée Keychain dont le portefeuille a besoin — et revus à chaque ajout.
Signé et vérifiable
Les builds sont signés par code et le source est publié, pour que ce qui s'exécute puisse être confronté à ce qui est écrit. La confiance s'ancre dans les signatures, pas dans notre parole.
Si une page devient hostile.
Un exploit WebKit tente de lire vos fichiers ou d'exécuter des commandes.
Le processus n'a aucun privilège fichier ou processus à abuser — le système d'exploitation les refuse, quoi que fasse la page.
Un malware sur le Mac tente de charger une dylib dans le navigateur.
La validation de bibliothèques et les protections contre l'injection de code bloquent le chargement de code non signé dans le processus.
Du code compromis tente de faire exécuter des commandes arbitraires à l'assistant.
L'assistant n'expose qu'une poignée de méthodes précises, avec les ops fichiers limitées à un dossier — il n'y a pas de point d'entrée « exécuter n'importe quoi ».
Supposer la compromission, contenir le rayon d'impact.
Le navigateur est traité comme le code le plus dangereux sur votre Mac — et enfermé en conséquence.