Ostler conserve toute votre vie numérique en un seul endroit. C'est à la fois puissant et dangereux à parts égales. Cette page explique exactement comment nous la protégeons. Pas de flou, pas de “chiffrement standard de l'industrie.” Du concret, et des libellés d'état honnêtes sur chaque affirmation.
Le modèle de menace est différent ici. Une violation de votre LinkedIn expose une tranche de votre vie. Une violation d'Ostler exposerait tout – chaque relation, chaque conversation, chaque schéma. Nous avons bâti la sécurité autour de cette réalité.
La menace réaliste est le logiciel, pas une IA magique. Ce qui menace un produit local-first, c'est du code malveillant qui tourne sur le même Mac, avec vos permissions, et fait des choses que vous n'avez pas demandées. L'IA à l'intérieur d'Ostler est un initié sous instructions : appels d'outils délimités, accès aux données délimité, sorties auditées. L'attaquant inattendu, c'est tout le reste qui a pris pied sur l'hôte.
Ostler ne se connecte à aucun serveur externe. Pas de backend cloud. Pas de point de terminaison d'API. Pas de télémétrie. Les bases de données, les modèles d'IA et le pipeline de traitement tournent tous sur votre Mac.
Cela élimine la plus grande et la plus banale catégorie de vecteurs d'attaque contre les données personnelles : violations de serveur, attaques de l'homme du milieu, bourrage d'identifiants, accès d'initié chez le fournisseur et demandes de données gouvernementales adressées au fournisseur. Il n'y a aucun serveur à violer. Il n'y a aucune donnée à réclamer.
Vérifiez-le vous-même. Déconnectez-vous d'Internet. Tout continue de fonctionner.
Ce que ce n'est pas : une affirmation que rien ne peut mal tourner. Supprimer le cloud ferme la porte par laquelle un attaquant passe le plus souvent. Cela ne scelle pas chaque fenêtre. Les limites honnêtes – ce qui reste de votre responsabilité – sont détaillées ci-dessous dans Ce contre quoi cela ne protège pas.
Il n'y a pas de mot de passe. Nous avons entièrement écarté les mots de passe.
Au premier lancement, Ostler enregistre une clé d'accès auprès de la Secure Enclave de votre Mac. À partir de ce moment, déverrouiller Ostler se fait par un effleurement Touch ID, un regard Face ID ou un double-clic sur votre Apple Watch. La preuve cryptographique d'identité réside dans la puce de sécurité matérielle de votre Mac. Elle ne peut pas être exportée, hameçonnée ni copiée sur la machine d'un attaquant.
Creative Machines ne voit jamais de mot de passe parce qu'il n'y a pas de mot de passe à voir. Nous ne recevons jamais de jeton de connexion, de cookie de session ni d'identifiant haché. Il n'y a rien que nous puissions perdre lors d'une violation parce que nous ne détenons rien.
Votre clé d'accès se synchronise avec vos autres appareils Apple via le Trousseau iCloud, chiffré de bout en bout par Apple. C'est ainsi que l'application iOS Ostler déverrouillera les données du même Hub sans deuxième étape de configuration.
Chaque base de données Ostler sur le disque est chiffrée avec un 32-byte data-encryption key (DEK). Le DEK est généré sur votre Mac au moment de l'installation, ne quitte jamais votre Mac en clair, et est encapsulé (chiffré) sous une clé dérivée de votre clé d'accès. Déverrouiller Ostler signifie : votre biométrie déverrouille la clé d'accès, la clé d'accès désencapsule le DEK, le DEK déchiffre les bases de données. Quand l'application se verrouille, le DEK est effacé de la mémoire.
Ostler se verrouille automatiquement après une période d'inactivité configurable. Au verrouillage, la clé de chiffrement en mémoire est écrasée. Un Mac volé ou perdu posé sur le bureau de l'attaquant ne peut livrer aucun texte en clair sans un Touch ID / Face ID en direct de votre part.
La plupart des logiciels grand public ne modélisent pas sérieusement le vol d'appareil – le cloud détient la vraie copie, donc un appareil volé est traité comme un terminal perdu. Nous le modélisons parce qu'ici l'appareil est les données, et les données sont intimes. Il n'y a pas de copie cloud sur laquelle se replier. Le verrouillage automatique, l'effacement de la clé en mémoire et l'exigence d'une biométrie en direct pour redéverrouiller sont conçus autour de cette réalité, pas ajoutés après coup.
Un schéma courant dans les produits “sans mot de passe” consiste à lier l'authentification ou la récupération à l'e-mail – un lien magique, un code à usage unique, un processus de réinitialisation de mot de passe. En surface, cela paraît solide ; il n'y a pas de mot de passe à hameçonner. Le hic, c'est que la sécurité de tout le système hérite de la sécurité du compte e-mail de l'utilisateur. Une boîte de réception compromise est une identité compromise.
Ostler ne fonctionne pas ainsi. Il n'y a pas d'e-mail de réinitialisation de mot de passe, pas de lien magique, pas de récupération liée à l'e-mail pour le produit local. Le data-encryption key est émis par le Hub sur votre Mac au moment de l'installation et encapsulé sous une clé dérivée de votre clé d'accès, qui réside dans la Secure Enclave de votre Mac. Le seul recours hors-bande est la phrase de 12 mots que vous avez notée. La chaîne de garde ne passe jamais par votre boîte de réception.
Il existe exactement un recours : une phrase de récupération de 12 mots générée pendant la configuration. Vous l'écrivez sur papier. Vous la gardez en lieu sûr. Vous ne la tapez jamais dans iCloud, Dropbox, un gestionnaire de mots de passe ou une photo.
La phrase vous est montrée une seule fois, sur un écran qui bloque le copier-coller, et n'est jamais stockée sur le disque par la suite. Pour être précis sur ce que nous utilisons de BIP39 et ce que nous n'utilisons pas : nous utilisons sa liste de 2048 mots en anglais et son encodage entropie-vers-mots (128 bits d'entropie plus une somme de contrôle de 4 bits ⇒ 12 mots). Nous n'implémentons pas l'étape PBKDF2 mnémonique-vers-graine de BIP39 – nous traitons l'entropie directement comme notre matériau de clé de récupération, ce qui est le bon choix pour un système non-portefeuille. Ostler n'est pas un portefeuille de cryptomonnaie et nous ne revendiquons aucune compatibilité de portefeuille BIP39. Nous utilisons la liste de mots parce qu'elle est auditée publiquement et éprouvée ergonomiquement, pas parce que nous interopérons avec quoi que ce soit.
Si vous perdez votre Mac et votre iPhone, et que le Trousseau iCloud n'a pas restauré votre clé d'accès sur un nouvel appareil, la phrase de récupération est le moyen de revenir. Elle désencapsule une deuxième copie, indépendante, du même DEK.
Si vous perdez la phrase et tous vos appareils Apple et votre sauvegarde Time Machine simultanément, vos données sont perdues. Par nous, par quiconque. C'est le prix de la vraie confidentialité – la même architecture qui nous empêche de lire vos données nous empêche de vous aider à les récupérer.
Vos données sont protégées par plusieurs couches. Chaque ligne ci-dessous montre l'état actuel et honnête – non pas ce que nous avons l'intention de faire, mais ce qui est réellement dans la build :
| Composant | Chiffrement | État |
|---|---|---|
| Disque entier | macOS FileVault (AES-256-XTS) | En service L'installateur vérifie que c'est activé |
| Bases de données SQLite | SQLCipher (AES-256) | En service dans le code Déployé avec l'installateur au lancement |
| Stockage sécurisé de l'application iOS | Realm (AES-256), clé liée à l'appareil | En service Stockage de profil vocal chiffré sur iOS aujourd'hui |
| Stockage principal de l'application iOS | Clé Realm dérivée de la clé d'accès (partagée avec le Hub) | En développement Spécification multiplateforme validée ; flux d'appairage iOS ensuite |
| Bases de données vectorielles + graphes | Volume APFS chiffré | En développement La création de volume scriptée arrive dans l'installateur |
| Journal d'audit local | Chiffré par SQLCipher, en ajout seul | En service dans le code La chaîne d'intégrité HMAC par entrée est une amélioration prévue |
| Sauvegardes Time Machine | Hérite de FileVault | En service Via le chiffrement Time Machine de macOS |
Deux éléments d'Ostler arrivent sur votre Mac depuis Internet au moment de l'installation : le binaire de l'assistant lui-même, et les poids du modèle LLM local. Nous gérons l'intégrité de chacun différemment parce que la forme de confiance est différente.
Le binaire de l'assistant est livré sous forme de tarball signé avec une somme de contrôle SHA-256 publiée dans un fichier annexe. L'installateur télécharge les deux, calcule le hachage du tarball et refuse de continuer si les valeurs ne correspondent pas. Une altération entre notre pipeline de publication et votre Mac – par un intermédiaire, par un CDN compromis, par n'importe quel agent entre les deux – est un échec d'installation net, pas une compromission silencieuse.
Les poids du modèle proviennent de registres en amont sélectionnés (le registre Ollama, Hugging Face) via TLS au moment de l'installation. Nous épinglons les noms de modèles ; nous nous appuyons sur la discipline d'immuabilité des tags du mainteneur en amont pour déterminer à quels octets ces noms se résolvent. Nous sommes honnêtes sur l'hypothèse de confiance : si un mainteneur d'un amont dont nous dépendons livrait une mise à jour malveillante sous un tag que nous avions épinglé, les nouvelles installations la récupéreraient jusqu'à ce que l'amont repère le problème. Nous épinglons les versions là où nous le pouvons, lisons les journaux de modifications, gardons la surface de modèles réduite. Renforcer cela davantage en épinglant les empreintes de contenu est un point de durcissement sur la liste post-lancement.
Quand l'application iOS Ostler communique avec votre Mac Hub, la connexion est conçue pour fonctionner via TLS avec un certificat auto-signé généré pendant l'installation, l'iPhone épinglant la clé publique du certificat au moment de l'appairage afin que seul votre Mac puisse répondre.
Le contrat cryptographique – format du QR code d'appairage, poignée de main WebAuthn, preuve HMAC de la clé d'accès partagée, expiration du jeton d'appairage de dix minutes – est figé dans une spécification multiplateforme normative validée le 23/04/2026 par les implémenteurs côté Hub et côté iOS. Chaque constante HKDF, chaque octet du format de transmission et chaque vecteur de test est fixé. La signature de code côté Hub est le dernier obstacle avant que l'appairage iPhone-vers-Hub ne fonctionne de bout en bout (voir ci-dessous).
127.0.0.1 (boucle locale uniquement) ; aucun n'accepte de connexions LAN. Cela protège contre tout attaquant qui n'est pas déjà sur votre Mac. Cela n'isole pas Ostler des autres logiciels qui tournent sur le même Mac que vous – voir ci-dessous.L'IA à l'intérieur d'Ostler est un initié sous instructions, selon la formulation de l'encadré en haut de cette page. Cette section explique ce que cela signifie concrètement : ce que l'assistant a le droit de faire, ce qu'il n'a pas le droit de faire, et comment ses actions sont enregistrées.
Confinement de l'espace de travail. L'assistant lit et écrit à l'intérieur d'un espace de travail à refus par défaut. Les répertoires qui contiennent vos identifiants et vos clés privées – ~/.ssh, ~/.gnupg, ~/.aws, ~/.config, les répertoires système sous /etc, /usr, /var – figurent sur une liste de refus statique qui protège par chemin chaque outil touchant aux fichiers. L'assistant peut lire vos messages, vos e-mails et les documents que vous lui avez demandé de lire ; il ne peut pas, même par mégarde, lire votre clé SSH.
Binaire renforcé. Le binaire de l'assistant est compilé avec le macOS Hardened Runtime activé, avec les capacités de JIT, d'injection de bibliothèque et de variables d'environnement dyld refusées au moment de la signature de code. Les voies d'injection au niveau processus habituelles qui fonctionnent contre les logiciels Mac ordinaires – hooks DYLD_INSERT_LIBRARIES, injection de code mappé en JIT, réécritures de variables d'environnement du chargeur – ne fonctionnent pas contre l'assistant. La confiance par signature de code est le verrou ; seul le binaire original s'exécute.
Verrou d'approbation par outil. Chaque appel d'outil passe par un verrou d'approbation. En mode Supervisé (par défaut), un outil qui n'a pas été pré-approuvé pendant cette session bloque jusqu'à ce que vous disiez oui. Les listes d'autorisation à portée de session font ce que leur nom indique : elles expirent à la fin de la session, pas quand l'assistant décide qu'il a gagné votre confiance pour toujours.
Refus par défaut piloté par canal. Quand l'assistant est piloté par un message entrant – iMessage, WhatsApp, e-mail – il n'y a aucun humain au clavier pour approuver un appel d'outil. Dans cette posture, l'assistant ne peut pas demander, donc il n'exécute aucun outil en dehors d'une petite liste d'autorisation en lecture seule (recherche, consultation, récupération d'une page web publique). Une injection de prompt arrivant par message ne peut pas s'élever vers des écritures de fichiers, des appels réseau arbitraires ou des commandes shell destructrices ; la surface d'outils shell dans cette posture est délimitée par une liste d'autorisation de commandes pré-approuvées distincte.
Journal d'audit inviolable. Chaque appel d'outil écrit un enregistrement dans un journal d'audit local qui utilise une chaîne de hachage SHA-256 : chaque entrée inclut le hachage de l'entrée précédente, de sorte qu'une entrée supprimée ou modifiée brise la chaîne d'une manière que la validation par rejeu détecte. La signature HMAC de chaque entrée est prise en charge comme étape de durcissement supplémentaire. Le journal d'audit est local ; il n'est expédié nulle part.
Conversations privées par défaut. Les conversations entre vous et l'assistant sont stockées sur votre Hub et marquées privées par défaut. Le contenu étiqueté au niveau de confidentialité le plus sensible (les corps de transcription complets que vous avez partagés en confidence) est retenu des réponses aux requêtes à moins que le client appelant ne choisisse explicitement de l'inclure. La voie API par défaut renvoie des métadonnées, pas des corps.
Ostler s'exécute en tant que votre compte utilisateur sur votre Mac – pas en tant que root, pas en tant que service système. L'orchestrateur, la passerelle API, les bases de données locales et les processus d'inférence s'exécutent tous dans la portée de permissions de votre utilisateur. Aucun LaunchDaemon n'est livré avec l'installateur, et aucun processus en arrière-plan ne survit à la déconnexion.
L'installateur demande un mot de passe administrateur une seule fois, au moment de l'installation, pour les opérations au niveau système pour lesquelles macOS exige des droits d'administrateur : modifier les réglages de gestion de l'alimentation pour que le Hub reste joignable par votre iPhone quand le Mac est inactif (désactiver la veille sur secteur, activer le wake-on-magic-packet), et installer les paquets de support (Homebrew, Ollama) livrés comme des CLI macOS standard. Après l'installation, aucune partie d'Ostler ne demande de privilèges élevés pour s'exécuter, et l'application n'a aucune voie qui s'élève d'elle-même.
Cela délimite le rayon d'impact d'un bug ou d'une attaque réussie contre Ostler lui-même : il hérite de la portée de votre utilisateur, pas de celle du système. Cela ne protège pas contre un logiciel malveillant qui a déjà obtenu les permissions de votre utilisateur par un autre vecteur – c'est la surface dont traite la section suivante.
Fermer le cloud ferme la plus grande et la plus banale catégorie d'attaque – celle qui expose un million de personnes d'un coup. Cela ne signifie pas que rien ne peut jamais mal tourner. Nous préférons vous dire les limites plutôt que de vous laisser les découvrir.
C'est la surface de menace réaliste pour un produit local-first, et nous sommes explicites à ce sujet. Si un logiciel malveillant atteint votre Mac via une extension de navigateur malveillante, un téléchargement empoisonné ou une application compromise hors de l'App Store, il hérite de la capacité de votre utilisateur à parler à localhost. La couche de chiffrement au repos protège contre le vol physique et contre la sortie de vos données de l'appareil, mais elle n'isole pas Ostler des autres logiciels que vous avez autorisés à s'exécuter. Traitez votre Mac Hub comme vous traiteriez un gestionnaire de mots de passe ou une application bancaire : n'installez pas d'utilitaires au hasard, n'approuvez pas d'invites d'installateur que vous n'avez pas initiées, et idéalement utilisez un Mac qui exécute surtout Ostler et pas grand-chose d'autre.
Ostler s'appuie sur Ollama, un fichier de modèle LLM, un environnement d'exécution Python et un petit ensemble de paquets Python. Nous ne les écrivons pas, nous les utilisons. Si l'un de ces projets en amont livrait demain une mise à jour malveillante, les nouvelles installations – les nôtres, les vôtres, celles de tous les autres utilisateurs – seraient exposées jusqu'à ce que le problème soit repéré. Nous épinglons les versions, nous lisons les journaux de modifications, nous gardons la surface de dépendances aussi réduite que possible. Nous n'allons pas prétendre que le risque est nul. La même réserve sur la chaîne d'approvisionnement s'applique à tout logiciel que vous installez un jour, n'importe où.
La phrase de récupération est la porte dérobée du pire scénario. Si vous l'écrivez sur un Post-it, en prenez une photo, la collez dans une application de notes cloud ou la lisez à voix haute lors d'un appel vidéo, la phrase devient le chemin le plus court pour l'attaquant. Nous facilitons le bon réflexe – l'écran bloque le copier-coller, le document de récupération explique la menace – mais le dernier maillon de la chaîne, c'est vous.
C'est le prix d'un système qui détient les clés sur votre matériel, pas sur le nôtre. Nous pouvons concevoir l'intérieur ; nous ne pouvons pas concevoir une parade à une mauvaise hygiène opérationnelle. L'atténuation, c'est une documentation honnête, pas une promesse que nous pourrions tenir à votre place.
Nous mobilisons des conseillers en sécurité expérimentés et définissons le périmètre d'un audit de sécurité indépendant par une société de cybersécurité reconnue. Le périmètre couvre l'authentification, le traitement des données, le chiffrement du stockage, la posture réseau et l'analyse des dépendances. Le rapport sera publié ici une fois terminé.
Nous avons choisi un audit professionnel plutôt que de nous reposer sur la revue de code communautaire parce qu'une revue d'expert est plus rigoureuse que d'espérer que quelqu'un lise le code. La confiance devrait être vérifiable, pas présumée. “Nous promettons de ne pas regarder vos données” est ce que dit chaque entreprise du cloud. “Nous ne pouvons architecturalement pas regarder vos données, et voici le rapport de l'auditeur qui le prouve” est ce que nous visons.
L'architecture est volontairement simple. Authentification par clé d'accès en priorité via les frameworks d'Apple. Primitives cryptographiques standard (HKDF-SHA256, AES-KW RFC 3394). Services locaux sur 127.0.0.1. Inférence Ollama locale. Il y a très peu de cryptographie inédite à rater parce que le mécanisme de sécurité principal est de ne pas avoir de connexion réseau au départ.
Clé d'accès (WebAuthn Level 2) enregistrée auprès de l'authentificateur de plateforme d'Apple via ASAuthorizationPlatformPublicKeyCredentialProvider, en utilisant l'extension PRF. Nécessite macOS 15+ / iOS 17.4+. La sortie PRF est une valeur pseudo-aléatoire liée à l'authentificateur, à la créance et à l'identifiant de la partie utilisatrice – non exportable depuis la Secure Enclave.
Un petit binaire utilitaire Swift possède chaque appel WebAuthn et communique avec le côté Python via un JSON-RPC à coup unique. Du pur AuthenticationServices + Security.framework, aucun paquet Swift tiers.
rp_id = creativemachines.ai. Lié au domaine de l'entreprise, pas au nom du produit, afin qu'un futur changement de nom de produit ne puisse pas invalider les créances des utilisateurs existants.
HKDF-SHA256. Les chaînes info à séparation de domaine utilisent l'espace de noms creativemachines/ pour la même raison de sûreté au changement de marque. Aucun PBKDF2 nulle part dans la voie principale – la sortie PRF est déjà une clé à entropie complète.
AES Key Wrap, RFC 3394 unpadded variant. Un 32-byte DEK encapsulé sous un 32-byte KEK produit un blob de 40 octets avec un contrôle d'intégrité intégré. Un mauvais KEK échoue à la désencapsulation – il ne renvoie pas de texte en clair erroné.
Phrase de 12 mots issue de la même liste de 2048 mots en anglais auditée publiquement que BIP39, 128 bits d'entropie native plus un mot de somme de contrôle. L'entropie de 16 octets alimente HKDF-SHA256 avec le même sel partagé, sous une chaîne info distincte, pour dériver un KEK de récupération indépendant. Pas d'étape PBKDF2 mnémonique-vers-graine – un second KDF sur une entrée déjà à entropie complète n'ajoute aucune sécurité dans ce modèle de menace. Nous empruntons la liste de mots ; nous ne revendiquons aucune compatibilité de portefeuille BIP39.
SQLCipher (AES-256) pour les bases de données Ostler sur le Mac Hub. Realm (AES-256) pour l'application iOS. Éléments du Trousseau cantonnés à AccessibleWhenUnlockedThisDeviceOnly, Synchronizable = false – les DEK encapsulés ne voyagent jamais dans Time Machine ni dans Assistant de migration.
Clé de session longue durée détenue sous forme de bytearray mutable et mise à zéro via ctypes.memset au verrouillage ou au délai d'expiration. Les copies immuables de courte durée en Python sont honnêtement documentées comme étant au mieux du best-effort, et non revendiquées comme nettoyées de manière garantie.
TLS avec un certificat serveur Ed25519 auto-signé généré à l'installation. Clé publique épinglée par l'application iOS au premier appairage. Pas de HTTP non épinglé. Pas de canal de repli au niveau applicatif.
Le contrat cryptographique multiplateforme complet entre le Mac Hub et l'application iOS, incluant chaque constante, chaque vecteur de test et chaque octet du format de transmission, est disponible pour revue indépendante.
La transparence, c'est admettre exactement où en est chaque élément aujourd'hui, avec un obstacle nommé précisément pour tout ce qui n'est pas encore en service :
ASAuthorizationPlatformPublicKeyCredentialProvider + extension PRF via macOS 15 AuthenticationServices. Compile et s'exécute. Opérations du Trousseau testées à blanc contre un vrai Security.framework le 23/04/2026.ctypes.memset au verrouillage, rappel de redéverrouillage par exception typée.~/Library/LaunchAgents/ avec des protections contre l'injection de chemin sur tous les chemins de certificat.register / assert – l'appel n'aboutit jamais, en silence. Le certificat Developer ID de Creative Machines est désormais en place et notarise le binaire de l'assistant ; le travail restant consiste à signer l'utilitaire de clé d'accès lui-même, à câbler son fichier d'entitlements et à servir le document apple-app-site-association depuis creativemachines.ai.~/.ostler/. Aucun obstacle technique – priorisé après le travail SQLCipher et clé d'accès, qui est venu en premier parce qu'il protège la plus grande surface de données.Si vous pensez avoir trouvé une faille de sécurité dans une partie quelconque d'Ostler – l'installateur du Mac Hub, l'application iOS, l'utilitaire de clé d'accès, le pipeline de mise à jour Sparkle, ou toute infrastructure connexe – veuillez la signaler à [email protected].
Ce que nous promettons en retour :
Ce que nous demandons en retour : n'accédez pas aux données d'autres utilisateurs, ne perturbez pas nos services, et n'exigez pas de paiement comme condition de divulgation. Nous ne menons pas de programme de prime aux bugs rémunéré au lancement – si cela change, cette page le dira.
Pour les signalements chiffrés, notre clé publique PGP est publiée à /security.asc. La politique de divulgation complète est aussi lisible par machine à /security.txt conformément à la RFC 9116.
L'histoire de la sécurité est l'histoire de la confidentialité. Chaque concurrent envoie vos données dans le cloud et promet de les protéger. Nous gardons vos données sur votre matériel et prouvons qu'elles ne peuvent pas en sortir. Ce n'est pas une fonctionnalité. C'est l'architecture.
Du concret · Pas de flou