Ostler custodisce l'intera tua vita digitale in un unico posto. Questo è potente e pericoloso in egual misura. Questa pagina spiega esattamente come la proteggiamo. Niente chiacchiere, niente “crittografia standard del settore.” Dettagli concreti ed etichette di stato oneste su ogni affermazione.
Qui il modello di minaccia è diverso. Una violazione del tuo LinkedIn espone una fetta della tua vita. Una violazione di Ostler esporrebbe tutto – ogni relazione, ogni conversazione, ogni schema. Abbiamo costruito la sicurezza attorno a questa realtà.
La minaccia realistica è il software, non un'IA magica. Ciò che minaccia un prodotto local-first è codice malevolo in esecuzione sullo stesso Mac, con i tuoi permessi, che fa cose che non hai chiesto. L'IA dentro Ostler è un insider istruito: chiamate di strumenti delimitate, accesso ai dati delimitato, output sottoposti ad audit. L'attaccante inatteso è tutto il resto che ha preso piede sull'host.
Ostler non si connette ad alcun server esterno. Nessun backend cloud. Nessun endpoint API. Nessuna telemetria. I database, i modelli di IA e la pipeline di elaborazione vengono eseguiti tutti sul tuo Mac.
Questo elimina la più grande e banale classe di vettori di attacco per i dati personali: violazioni dei server, attacchi man-in-the-middle, credential stuffing, accesso interno presso il fornitore e richieste governative di dati nei confronti del fornitore. Non c'è alcun server da violare. Non ci sono dati da richiedere.
Verificalo tu stesso. Disconnettiti da internet. Tutto continua a funzionare.
Ciò che questo non è: un'affermazione che nulla possa andare storto. Rimuovere il cloud chiude la porta da cui un attaccante passa più spesso. Non sigilla ogni finestra. I limiti onesti – ciò che resta tua responsabilità – sono illustrati di seguito in Da cosa questo non protegge.
Non c'è alcuna password. Abbiamo tolto del tutto le password dal tavolo.
Al primo avvio, Ostler registra una passkey presso la Secure Enclave del tuo Mac. Da quel momento in poi, sbloccare Ostler è un tocco di Touch ID, uno sguardo di Face ID o un doppio clic sul tuo Apple Watch. La prova crittografica di identità risiede dentro il chip di sicurezza hardware del tuo Mac. Non può essere esportata, sottratta tramite phishing né copiata sulla macchina di un attaccante.
Creative Machines non vede mai una password perché non c'è alcuna password da vedere. Non riceviamo mai un token di accesso, un cookie di sessione o una credenziale con hash. Non c'è nulla che possiamo perdere in una violazione perché non deteniamo nulla.
La tua passkey si sincronizza con gli altri tuoi dispositivi Apple tramite il Portachiavi iCloud, cifrata end-to-end da Apple. È così che l'app iOS di Ostler sbloccherà i dati dello stesso Hub senza un secondo passaggio di configurazione.
Ogni database di Ostler su disco è cifrato con una 32-byte data-encryption key (DEK). La DEK viene generata sul tuo Mac al momento dell'installazione, non lascia mai il tuo Mac in chiaro ed è incapsulata (cifrata) sotto una chiave derivata dalla tua passkey. Sbloccare Ostler significa: la tua biometria sblocca la passkey, la passkey disincapsula la DEK, la DEK decifra i database. Quando l'app si blocca, la DEK viene cancellata dalla memoria.
Ostler si blocca automaticamente dopo un periodo configurabile di inattività. Al blocco, la chiave di cifratura in memoria viene sovrascritta. Un Mac rubato o smarrito sulla scrivania dell'attaccante non può fornire testo in chiaro senza un Touch ID / Face ID dal vivo da parte tua.
La maggior parte del software di consumo non modella seriamente il furto del dispositivo – il cloud detiene la copia reale, quindi un dispositivo rubato è trattato come un endpoint perso. Noi lo modelliamo perché qui il dispositivo è i dati, e i dati sono intimi. Non c'è alcuna copia cloud su cui ripiegare. Il blocco automatico, la cancellazione della chiave in memoria e il requisito di una biometria dal vivo per risbloccare sono progettati attorno a questa realtà, non aggiunti dopo i fatti.
Uno schema comune nei prodotti “senza password” è legare l'autenticazione o il recupero all'e-mail – un magic link, un codice monouso, un flusso di reimpostazione della password. In superficie sembra solido; non c'è alcuna password da sottrarre con il phishing. Il punto è che la sicurezza dell'intero sistema eredita la sicurezza dell'account e-mail dell'utente. Una casella di posta compromessa è un'identità compromessa.
Ostler non funziona così. Non c'è alcuna e-mail di reimpostazione della password, nessun magic link, nessun recupero legato all'e-mail per il prodotto locale. La data-encryption key è emessa dall'Hub sul tuo Mac al momento dell'installazione e incapsulata sotto una chiave derivata dalla tua passkey, che risiede nella Secure Enclave del tuo Mac. L'unica alternativa fuori banda è la frase di 12 parole che hai annotato. La catena di custodia non passa mai per la tua casella di posta.
C'è esattamente un'alternativa: una frase di recupero di 12 parole generata durante la configurazione. La scrivi su carta. La conservi in un luogo sicuro. Non la digiti mai in iCloud, Dropbox, un gestore di password o una foto.
La frase ti viene mostrata una volta sola, su una schermata che blocca il copia-incolla, e non viene mai memorizzata su disco in seguito. Per essere precisi su cosa usiamo di BIP39 e cosa no: usiamo la sua lista di 2048 parole in inglese e la sua codifica entropia-in-parole (128 bit di entropia più un checksum di 4 bit ⇒ 12 parole). Non implementiamo il passaggio PBKDF2 mnemonico-in-seme di BIP39 – trattiamo l'entropia direttamente come il nostro materiale di chiave di recupero, che è la scelta giusta per un sistema che non è un wallet. Ostler non è un wallet di criptovalute e non rivendichiamo alcuna compatibilità wallet BIP39. Usiamo la lista di parole perché è sottoposta ad audit pubblico ed è comprovata ergonomicamente, non perché interoperiamo con qualcosa.
Se perdi il tuo Mac e il tuo iPhone, e il Portachiavi iCloud non ha ripristinato la tua passkey su un nuovo dispositivo, la frase di recupero è il modo per rientrare. Disincapsula una seconda copia, indipendente, della stessa DEK.
Se perdi la frase e tutti i tuoi dispositivi Apple e il tuo backup di Time Machine contemporaneamente, i tuoi dati sono perduti. Da parte nostra, da parte di chiunque. Questo è il prezzo della vera privacy – la stessa architettura che impedisce a noi di leggere i tuoi dati impedisce a noi di aiutarti a recuperarli.
I tuoi dati sono protetti da più livelli. Ogni riga qui sotto mostra lo stato attuale e onesto – non ciò che intendiamo fare, ma ciò che è realmente nella build:
| Componente | Crittografia | Stato |
|---|---|---|
| Disco intero | macOS FileVault (AES-256-XTS) | Attivo L'installer verifica che sia abilitato |
| Database SQLite | SQLCipher (AES-256) | Attivo nel codice Viene distribuito con l'installer al lancio |
| Store sicuro dell'app iOS | Realm (AES-256), chiave legata al dispositivo | Attivo Store del profilo vocale cifrato su iOS oggi |
| Store principale dell'app iOS | Chiave Realm derivata dalla passkey (condivisa con l'Hub) | In sviluppo Specifica multipiattaforma approvata; flusso di associazione iOS in seguito |
| Database vettoriali + a grafo | Volume APFS cifrato | In sviluppo La creazione di volume tramite script arriva nell'installer |
| Registro di audit locale | Cifrato con SQLCipher, in sola aggiunta | Attivo nel codice La catena di integrità HMAC per voce è un aggiornamento previsto |
| Backup di Time Machine | Eredita FileVault | Attivo Tramite la crittografia di Time Machine di macOS |
Due componenti di Ostler arrivano sul tuo Mac da internet al momento dell'installazione: il binario dell'assistente stesso e i pesi del modello LLM locale. Gestiamo l'integrità di ciascuno in modo diverso perché la forma della fiducia è diversa.
Il binario dell'assistente viene distribuito come tarball firmato con un checksum SHA-256 pubblicato in un file accessorio. L'installer scarica entrambi, calcola l'hash del tarball e si rifiuta di proseguire se i valori non corrispondono. Una manomissione tra la nostra pipeline di rilascio e il tuo Mac – da parte di un intermediario, di una CDN compromessa, di qualsiasi agente nel mezzo – è un fallimento netto dell'installazione, non una compromissione silenziosa.
I pesi del modello provengono da registry upstream curati (il registry di Ollama, Hugging Face) tramite TLS al momento dell'installazione. Fissiamo i nomi dei modelli; ci affidiamo alla disciplina di immutabilità dei tag del manutentore upstream per stabilire a quali byte si risolvono quei nomi. Siamo onesti sull'assunto di fiducia: se un manutentore di un upstream da cui dipendiamo distribuisse un aggiornamento malevolo sotto un tag che avevamo fissato, le installazioni nuove lo scaricherebbero finché l'upstream non rilevasse il problema. Fissiamo le versioni dove possiamo, leggiamo i changelog, manteniamo piccola la superficie dei modelli. Rafforzare ulteriormente questo aspetto fissando i digest del contenuto è un elemento di hardening nella lista post-lancio.
Quando l'app iOS di Ostler comunica con il tuo Mac Hub, la connessione è progettata per funzionare su TLS con un certificato autofirmato generato durante l'installazione, con l'iPhone che fissa la chiave pubblica del certificato al momento dell'associazione in modo che solo il tuo Mac possa rispondere.
Il contratto crittografico – formato del codice QR di associazione, handshake WebAuthn, prova HMAC della passkey condivisa, scadenza del token di associazione di dieci minuti – è bloccato in una specifica normativa multipiattaforma approvata il 23-04-2026 sia dagli implementatori lato Hub sia da quelli lato iOS. Ogni costante HKDF, byte del formato di trasmissione e vettore di test è fissato. La firma del codice lato Hub è l'ultimo ostacolo prima che l'associazione iPhone-Hub funzioni end-to-end (vedi sotto).
127.0.0.1 (solo loopback); nessuno accetta connessioni dalla LAN. Questo protegge contro ogni attaccante che non sia già sul tuo Mac. Non isola Ostler dall'altro software in esecuzione sullo stesso Mac in cui sei tu – vedi sotto.L'IA dentro Ostler è un insider istruito, nella formulazione dell'avviso in cima a questa pagina. Questa sezione spiega cosa significa in termini concreti: cosa l'assistente è autorizzato a fare, cosa non è autorizzato a fare e come le sue azioni vengono registrate.
Confinamento dello spazio di lavoro. L'assistente legge e scrive all'interno di uno spazio di lavoro a negazione predefinita. Le directory che contengono le tue credenziali e le tue chiavi private – ~/.ssh, ~/.gnupg, ~/.aws, ~/.config, le directory di sistema sotto /etc, /usr, /var – sono su una lista di negazione statica che protegge per percorso ogni strumento che tocca i file. L'assistente può leggere i tuoi messaggi, la tua e-mail e i documenti che gli hai chiesto di leggere; non può, nemmeno per disavventura, leggere la tua chiave SSH.
Binario rafforzato. Il binario dell'assistente è compilato con il macOS Hardened Runtime abilitato, con le capacità di JIT, iniezione di librerie e variabili d'ambiente dyld negate al momento della firma del codice. Le consuete vie di iniezione a livello di processo che funzionano contro il comune software per Mac – hook DYLD_INSERT_LIBRARIES, iniezione di codice mappato in JIT, riscritture delle variabili d'ambiente del loader – non funzionano contro l'assistente. La fiducia tramite firma del codice è il varco; viene eseguito solo il binario originale.
Varco di approvazione per ogni strumento. Ogni chiamata di strumento passa attraverso un varco di approvazione. In modalità Supervisionata (quella predefinita), uno strumento non pre-approvato in questa sessione si blocca finché non dici di sì. Le allowlist con ambito di sessione fanno ciò che dice il nome: scadono alla fine della sessione, non quando l'assistente decide di essersi guadagnato la tua fiducia per sempre.
Negazione predefinita guidata dal canale. Quando l'assistente è guidato da un messaggio in arrivo – iMessage, WhatsApp, e-mail – non c'è alcun essere umano alla tastiera per approvare una chiamata di strumento. In questa postura, l'assistente non può chiedere, quindi non esegue alcuno strumento al di fuori di una piccola allowlist di sola lettura (ricerca, consultazione, recupero di una pagina web pubblica). Un'iniezione di prompt che arriva via messaggio non può scalare fino a scritture di file, chiamate di rete arbitrarie o comandi shell distruttivi; la superficie dello strumento shell in questa postura è delimitata da una allowlist separata di comandi pre-approvati.
Registro di audit a prova di manomissione. Ogni chiamata di strumento scrive un record in un registro di audit locale che usa una catena di hash SHA-256: ogni voce include l'hash della voce precedente, così che una voce eliminata o modificata spezzi la catena in un modo che la validazione tramite replay rileva. La firma HMAC di ogni voce è supportata come passaggio di hardening aggiuntivo. Il registro di audit è locale; non viene inviato da nessuna parte.
Conversazioni private per impostazione predefinita. Le conversazioni tra te e l'assistente sono memorizzate sul tuo Hub e contrassegnate come private per impostazione predefinita. I contenuti etichettati al livello di privacy più sensibile (i corpi completi delle trascrizioni che hai condiviso in confidenza) vengono trattenuti dalle risposte alle query a meno che il client chiamante non scelga esplicitamente di includerli. La via API predefinita restituisce metadati, non corpi.
Ostler viene eseguito come il tuo account utente sul tuo Mac – non come root, non come servizio di sistema. L'orchestratore, il gateway API, i database locali e i processi di inferenza vengono eseguiti tutti entro l'ambito di permessi del tuo utente. Non c'è alcun LaunchDaemon distribuito con l'installer, né alcun processo in background che sopravviva al logout.
L'installer chiede una password di amministratore una volta sola, al momento dell'installazione, per le operazioni a livello di sistema per cui macOS richiede i privilegi di amministratore: modificare le impostazioni di gestione dell'alimentazione affinché l'Hub resti raggiungibile dal tuo iPhone quando il Mac è inattivo (disabilitare la sospensione con alimentazione CA, abilitare il wake-on-magic-packet) e installare i pacchetti di supporto (Homebrew, Ollama) che vengono distribuiti come CLI standard di macOS. Dopo l'installazione, nessuna parte di Ostler chiede privilegi elevati per l'esecuzione, e l'applicazione non ha alcuna via che escali da sola.
Questo delimita il raggio d'impatto di un bug o di un attacco riuscito contro Ostler stesso: eredita la portata del tuo utente, non quella del sistema. Non protegge contro malware che abbia già ottenuto i permessi del tuo utente tramite qualche altro vettore – questa è la superficie di cui tratta la sezione successiva.
Chiudere il cloud chiude la più grande e banale classe di attacco – quella che espone un milione di persone in una volta. Non significa che non possa mai andare storto nulla. Preferiamo dirti i limiti piuttosto che lasciarteli scoprire.
Questa è la superficie di minaccia realistica per un prodotto local-first, e siamo espliciti al riguardo. Se un malware raggiunge il tuo Mac tramite un'estensione del browser malevola, un download avvelenato o un'app compromessa proveniente da fuori l'App Store, eredita la capacità del tuo utente di parlare con localhost. Il livello di crittografia a riposo protegge contro il furto fisico e contro l'uscita dei tuoi dati dal dispositivo, ma non isola Ostler dall'altro software a cui hai dato il permesso di essere eseguito. Tratta il tuo Mac Hub come tratteresti un gestore di password o un'app bancaria: non installare utility a caso, non approvare prompt dell'installer che non hai avviato tu, e idealmente usa un Mac che esegua per lo più Ostler e non molto altro.
Ostler si appoggia a Ollama, a un file di modello LLM, a un runtime Python e a un piccolo insieme di pacchetti Python. Non li scriviamo noi, li usiamo. Se uno di quei progetti upstream distribuisse domani un aggiornamento malevolo, le installazioni nuove – le nostre, le tue, quelle di ogni altro utente – sarebbero esposte finché il problema non venisse rilevato. Fissiamo le versioni, leggiamo i changelog, manteniamo la superficie delle dipendenze più piccola possibile. Non fingeremo che il rischio sia zero. La stessa avvertenza sulla catena di fornitura vale per qualsiasi software tu installi mai, ovunque.
La frase di recupero è la backdoor del caso peggiore. Se la scrivi su un foglietto adesivo, ne fai una foto, la incolli in un'app di note nel cloud o la leggi ad alta voce durante una videochiamata, la frase diventa la via più breve per l'attaccante. Ti rendiamo facile fare la cosa giusta – la schermata blocca il copia-incolla, il documento di recupero spiega la minaccia – ma l'ultimo anello della catena sei tu.
Questo è il prezzo di un sistema che custodisce le chiavi sul tuo hardware, non sul nostro. Possiamo progettare l'architettura dell'interno; non possiamo progettare per aggirare una cattiva igiene operativa. La mitigazione è una documentazione onesta, non una promessa che possiamo mantenere al posto tuo.
Stiamo coinvolgendo consulenti di sicurezza senior e definendo l'ambito di un audit di sicurezza indipendente da parte di una rinomata azienda di cybersicurezza. L'ambito copre autenticazione, trattamento dei dati, crittografia dello storage, postura di rete e analisi delle dipendenze. Il report sarà pubblicato qui una volta completato.
Abbiamo scelto un audit professionale anziché affidarci alla revisione del codice da parte della community perché una revisione di esperti è più rigorosa che sperare che qualcuno legga il codice. La fiducia dovrebbe essere verificabile, non presunta. “Promettiamo di non guardare i tuoi dati” è ciò che dice ogni azienda del cloud. “Architetturalmente non possiamo guardare i tuoi dati, ed ecco il report dell'auditor che lo dimostra” è ciò a cui puntiamo.
L'architettura è intenzionalmente semplice. Autenticazione con passkey come metodo primario tramite i framework di Apple. Primitive crittografiche standard (HKDF-SHA256, AES-KW RFC 3394). Servizi locali su 127.0.0.1. Inferenza Ollama locale. C'è pochissima crittografia inedita da sbagliare perché il meccanismo di sicurezza primario è non avere una connessione di rete in partenza.
Passkey (WebAuthn Level 2) registrata presso l'autenticatore di piattaforma di Apple tramite ASAuthorizationPlatformPublicKeyCredentialProvider, usando l'estensione PRF. Richiede macOS 15+ / iOS 17.4+. L'output PRF è un valore pseudocasuale legato all'autenticatore, alla credenziale e all'identificatore della relying party – non esportabile dalla Secure Enclave.
Un piccolo binario helper in Swift è proprietario di ogni chiamata WebAuthn e comunica con il lato Python tramite JSON-RPC monouso. Puro AuthenticationServices + Security.framework, nessun pacchetto Swift di terze parti.
rp_id = creativemachines.ai. Legato al dominio dell'azienda, non al nome del prodotto, così che un futuro cambio di nome del prodotto non possa invalidare le credenziali degli utenti esistenti.
HKDF-SHA256. Le stringhe info con separazione di dominio usano lo spazio dei nomi creativemachines/ per la stessa ragione di sicurezza in caso di rebrand. Nessun PBKDF2 da nessuna parte nella via primaria – l'output PRF è già una chiave a entropia piena.
AES Key Wrap, RFC 3394 unpadded variant. Una 32-byte DEK incapsulata sotto una 32-byte KEK produce un blob da 40 byte con un controllo di integrità integrato. Una KEK errata fallisce la disincapsulazione – non restituisce testo in chiaro spazzatura.
Frase di 12 parole dalla stessa lista di 2048 parole in inglese sottoposta ad audit pubblico di BIP39, 128 bit di entropia nativa più una parola di checksum. L'entropia di 16 byte alimenta HKDF-SHA256 con lo stesso salt condiviso, sotto una stringa info distinta, per derivare una KEK di recupero indipendente. Nessun passaggio PBKDF2 mnemonico-in-seme – un secondo KDF su un input già a entropia piena non aggiunge sicurezza in questo modello di minaccia. Prendiamo in prestito la lista di parole; non rivendichiamo alcuna compatibilità wallet BIP39.
SQLCipher (AES-256) per i database di Ostler sul Mac Hub. Realm (AES-256) per l'app iOS. Elementi del Portachiavi con ambito AccessibleWhenUnlockedThisDeviceOnly, Synchronizable = false – le DEK incapsulate non viaggiano mai in Time Machine né in Assistente Migrazione.
Chiave di sessione a lunga durata mantenuta come bytearray mutabile e azzerata tramite ctypes.memset al blocco o al timeout. Le copie immutabili a breve durata in Python sono documentate onestamente come solo best-effort, non rivendicate come garantite pulite.
TLS con un certificato server Ed25519 autofirmato generato all'installazione. Chiave pubblica fissata dall'app iOS alla prima associazione. Nessun HTTP non fissato. Nessun canale di ripiego a livello applicativo.
Il contratto crittografico multipiattaforma completo tra il Mac Hub e l'app iOS, comprensivo di ogni costante, vettore di test e byte del formato di trasmissione, è disponibile per una revisione indipendente.
La trasparenza significa ammettere esattamente a che punto si trova oggi ogni elemento, con un ostacolo nominato in modo specifico per tutto ciò che non è ancora attivo:
ASAuthorizationPlatformPublicKeyCredentialProvider reale + estensione PRF tramite macOS 15 AuthenticationServices. Compila e viene eseguito. Operazioni del Portachiavi sottoposte a smoke test contro un Security.framework reale il 23-04-2026.ctypes.memset al blocco, callback di risblocco con eccezione tipizzata.~/Library/LaunchAgents/ con protezioni contro l'iniezione di percorso su tutti i percorsi dei certificati.register / assert – la chiamata non si completa mai, in silenzio. Il certificato Developer ID di Creative Machines è ora in posizione e notarizza il binario dell'assistente; il lavoro restante è firmare l'helper della passkey stesso, cablare il suo file di entitlements e servire il documento apple-app-site-association da creativemachines.ai.~/.ostler/. Nessun ostacolo tecnico – prioritizzato dopo il lavoro su SQLCipher e passkey, che è venuto prima perché protegge la superficie di dati più grande.Se pensi di aver trovato una vulnerabilità di sicurezza in una qualsiasi parte di Ostler – l'installer del Mac Hub, l'app iOS, l'helper della passkey, la pipeline di aggiornamento Sparkle o qualsiasi infrastruttura correlata – ti preghiamo di segnalarla a [email protected].
Cosa promettiamo in cambio:
Cosa chiediamo in cambio: non accedere ai dati di altri utenti, non interrompere i nostri servizi e non pretendere un pagamento come condizione per la divulgazione. Non gestiamo un programma di bug-bounty retribuito al lancio – se questo cambia, questa pagina lo dirà.
Per le segnalazioni cifrate, la nostra chiave pubblica PGP è pubblicata su /security.asc. La politica di divulgazione completa è anche leggibile da macchina su /security.txt secondo la RFC 9116.
La storia della sicurezza è la storia della privacy. Ogni concorrente invia i tuoi dati al cloud e promette di proteggerli. Noi teniamo i tuoi dati sul tuo hardware e dimostriamo che non possono uscirne. Questa non è una funzionalità. È l'architettura.
Dettagli concreti · Niente chiacchiere