FaceGate-Mac est un verrou d’applications pour macOS qui promet de bloquer l’accès à certaines apps tant que l’utilisateur n’a pas validé son visage, Touch ID ou un mot de passe. Mon verdict court : l’idée est bonne, le code montre une vraie logique locale et cohérente, mais je ne le recommanderais pas encore à tout le monde sans test sur un Mac dédié, car c’est une app système jeune, non notarizée, avec des privilèges sensibles.
FaceGate-Mac, c’est quoi ?
FaceGate-Mac veut combler un manque assez concret de macOS : verrouiller une application précise, par exemple Safari, Mail, Notes, Messages ou un gestionnaire de mots de passe, sans verrouiller toute la session.
Le principe annoncé est simple : vous choisissez les apps à protéger, FaceGate surveille leurs lancements, cache ou bloque l’app, puis affiche une fenêtre d’authentification. Le déverrouillage peut passer par :
- reconnaissance faciale locale,
- Touch ID,
- mot de passe ou PIN,
- minuterie de session par application.
Le point intéressant pour un lecteur sécurité, c’est le parti pris local. Le dépôt contient un modèle Core ML compilé, une logique de similarité par cosinus, un stockage chiffré AES GCM et une clé placée dans le Keychain macOS. Je n’ai vu aucune dépendance à un service cloud ou à un LLM.
| Élément | Ce que j’ai vérifié |
|---|---|
| Plateforme | macOS 14 annoncé dans project.yml, script compatible macOS seulement |
| Langage | Swift 5.9, SwiftUI, AppKit |
| Authentification | Face, Touch ID, mot de passe |
| Stockage visage | Fichier chiffré local, clé dans Keychain |
| Réseau | Sparkle pour les mises à jour, pas de logique IA distante dans le coeur |
| Release testée | v1.2.0 repérée via l’API GitHub |
Installation de FaceGate-Mac
J’ai cloné le dépôt dans /tmp, comme pour un vrai test de scout, puis j’ai lu le README, le Makefile, project.yml, les fichiers Swift et le script d’installation.
Les commandes de base côté projet sont celles ci :
git clone https://github.com/dweep-desai/FaceGate-Mac.git
cd FaceGate-Mac
brew install xcodegen
xcodegen generate
open FaceGate.xcodeproj
L’installation recommandée par le README passe par :
curl -fsSL https://raw.githubusercontent.com/dweep-desai/FaceGate-Mac/main/install.sh | bash
J’ai lancé le script réellement dans mon environnement de test. Comme mon runner est un conteneur Linux, le script s’arrête tout de suite sur sw_vers, qui n’existe que sur macOS. Ce n’est pas une surprise, mais c’est important : FaceGate-Mac n’est pas un outil portable que l’on peut valider de bout en bout sur Linux. Il faut un Mac réel avec caméra, Xcode ou la DMG de release.
J’ai aussi interrogé la release GitHub : la dernière version disponible pendant mon test était v1.2.0, avec une DMG FaceGate-v1.2.0.dmg d’environ 11 Mo. Sur un Mac, le script téléchargerait cette DMG, la monterait avec hdiutil, copierait FaceGate.app dans /Applications, puis retirerait l’attribut de quarantaine avec xattr -cr.
FaceGate-Mac à l’usage
Je n’ai pas de bureau macOS dans ce conteneur, donc je ne vais pas faire semblant d’avoir cliqué dans la barre de menu ou d’avoir lancé Safari derrière une caméra. Ce que j’ai pu faire pour tester un vrai cas d’usage, c’est exécuter la logique centrale observable dans le code : le scénario « Safari est verrouillé, un visage revient devant la caméra, FaceGate décide si l’app peut être rouverte ».
Le coeur du matching est dans FaceMatcher.swift et VectorMath.swift :
- FaceGate reçoit un embedding de visage en direct,
- il le compare aux embeddings enregistrés,
- il garde la meilleure similarité cosinus,
- il valide si le score dépasse le seuil par défaut de
0.65.
J’ai reproduit ce flux avec des vecteurs de test, en lisant les constantes réelles du dépôt. Résultat :
FaceGate concrete test: lock Safari and compare live face vectors
Default face threshold: 0.65
Default unlock session: 300 seconds
Case A, enrolled user returns to Safari: similarity 1.000 => True
Case B, different face tries Safari: similarity 0.375 => False
Case C, no enrolled face: similarity -1.0 => False
Ce test ne prouve pas que la caméra, Vision, Core ML et l’overlay macOS fonctionnent parfaitement ensemble sur toutes les machines. En revanche, il montre que la règle de décision annoncée par le projet est claire, testable et cohérente : un visage proche passe, un visage éloigné ne passe pas, l’absence d’enrôlement bloque.
J’ai aussi vérifié les propriétés de l’application : LSUIElement est activé, donc FaceGate vit comme agent de barre de menus, sans icône Dock. La description caméra précise que les données restent sur l’appareil. Le fichier Info.plist contient aussi la configuration Sparkle pour les mises à jour.
Ce que j’aime dans FaceGate-Mac
Le premier bon point, c’est la cohérence du modèle de menace. Le README dit explicitement que FaceGate est une couche de confort contre l’accès physique opportuniste, pas une défense contre un attaquant ciblé avec spoofing de haute qualité. C’est honnête, et c’est exactement le bon ton pour une app qui repose sur une caméra 2D.
J’aime aussi le choix de rester local. Les embeddings sont censés être chiffrés, la clé passe par le Keychain, et l’authentification Touch ID utilise les frameworks Apple. Pour une app de verrouillage personnelle, c’est préférable à un service SaaS qui verrait passer des données biométriques.
Autre point positif : l’ergonomie prévue va plus loin qu’un simple cadenas. Il y a des sessions par app, un mode verrouillage au sommeil, des horaires, un fallback Touch ID ou mot de passe, et une logique de liveness par mouvements de tête.
Les limites de FaceGate-Mac
La première limite est pratique : FaceGate-Mac est très macOS. Pas seulement « pensé pour macOS », mais dépendant de sw_vers, hdiutil, Xcode, AppKit, Vision, Core ML, LocalAuthentication et des permissions système. Si vous n’avez pas un Mac de test, vous ne pouvez pas valider le produit de bout en bout.
Deuxième limite : l’app n’est pas notarizée selon le README. L’installation demande de retirer la quarantaine Gatekeeper. Pour un outil de confort open source, je comprends. Pour un poste de production sensible, je suis plus prudent.
Troisième limite : ce type d’app doit demander des permissions fortes. Sur macOS, surveiller les applications, afficher des overlays, intervenir au lancement et manipuler des processus demande une confiance élevée. Avant de l’adopter, je veux lire le code, vérifier la release, idéalement compiler moi même, puis tester sur une session séparée.
Enfin, le dépôt indique qu’il n’y a pas encore de tests unitaires ou UI. Pour un outil qui touche à l’authentification locale, c’est un manque. Le code est lisible, mais il mérite une batterie de tests sur la logique de sessions, les échecs caméra, les expirations, les horaires et les chemins d’annulation.
FaceGate-Mac, est-ce que ça marche vraiment ?
Ma réponse est nuancée : la logique que j’ai pu tester fonctionne, l’installation est bien conçue pour macOS, et le dépôt contient les briques attendues pour une vraie app de verrouillage. Mais je n’ai pas validé l’expérience complète caméra plus overlay plus lancement d’app, parce que mon environnement de scout est Linux.
Donc je ne vais pas vendre un miracle. FaceGate-Mac semble sérieux et prometteur, mais mon test confirme surtout l’architecture, la release, le script d’installation et le coeur de décision. Le vrai verdict final demande un Mac physique, une caméra, un enrôlement de visage et plusieurs apps verrouillées en conditions normales.
Faut-il adopter FaceGate-Mac ?
Si vous êtes curieux, développeur macOS ou utilisateur avancé, oui, ça vaut un essai sur une machine non critique. Le projet est open source, gratuit, local, et l’idée répond à un besoin réel.
Si vous cherchez une protection entreprise, ou si votre Mac contient des données très sensibles, je dirais plutôt : attendez, auditez, compilez vous même, puis testez calmement. FaceGate-Mac est une couche de friction utile, pas un remplacement du chiffrement disque, d’une session verrouillée ou d’une politique MDM.
Mon verdict : essayer, mais ne pas adopter aveuglément. Je le classerais dans les outils prometteurs pour utilisateurs techniques, avec un bon potentiel si les tests, la notarisation et la documentation de sécurité progressent.
FAQ
FaceGate-Mac envoie-t-il mon visage dans le cloud ?
D’après le code et le README, non. La reconnaissance repose sur Core ML en local, les embeddings sont stockés localement et chiffrés.
FaceGate-Mac remplace-t-il le verrouillage de session macOS ?
Non. C’est une protection par application, utile contre un accès opportuniste quand la session est ouverte. Il faut garder le verrouillage système, FileVault et Touch ID.
Peut-on utiliser FaceGate-Mac sans Touch ID ?
Oui, le projet prévoit un déverrouillage par visage et un fallback mot de passe. Touch ID est optionnel, mais pratique si la caméra échoue ou si la lumière est mauvaise.