Ostler guarda toda tu vida digital en un solo lugar. Eso es poderoso y peligroso a partes iguales. Esta página explica exactamente cómo la protegemos. Sin palabrería, sin “cifrado de nivel industrial.” Detalles concretos y etiquetas de estado honestas en cada afirmación.
El modelo de amenazas es diferente aquí. Una brecha en tu LinkedIn expone una porción de tu vida. Una brecha en Ostler expondría todo – cada relación, cada conversación, cada patrón. Construimos la seguridad en torno a esa realidad.
La amenaza realista es el software, no una IA mágica. Lo que amenaza a un producto local-first es código malicioso que se ejecuta en el mismo Mac, con tus permisos, haciendo cosas que no pediste. La IA dentro de Ostler es un infiltrado con instrucciones: llamadas a herramientas acotadas, acceso a datos acotado, salidas auditadas. El atacante inesperado es todo lo demás que ha conseguido un punto de apoyo en el equipo anfitrión.
Ostler no se conecta a ningún servidor externo. Sin backend en la nube. Sin punto de conexión de API. Sin telemetría. Las bases de datos, los modelos de IA y la canalización de procesamiento se ejecutan todos en tu Mac.
Esto elimina la clase de vectores de ataque más grande y aburrida contra los datos personales: brechas de servidor, ataques de intermediario, relleno de credenciales, acceso interno en el proveedor y solicitudes gubernamentales de datos contra el proveedor. No hay servidor que vulnerar. No hay datos que solicitar.
Compruébalo tú mismo. Desconéctate de Internet. Todo sigue funcionando.
Lo que esto no es: una afirmación de que nada puede salir mal. Eliminar la nube cierra la puerta por la que un atacante entra con más frecuencia. No sella todas las ventanas. Los límites honestos – lo que sigue siendo tu responsabilidad – se detallan a continuación en Contra qué no protege esto.
No hay contraseña. Quitamos las contraseñas de la mesa por completo.
En la primera ejecución, Ostler registra una clave de acceso contra el Secure Enclave de tu Mac. A partir de ese momento, desbloquear Ostler es un toque de Touch ID, una mirada de Face ID o un doble clic en tu Apple Watch. La prueba criptográfica de identidad reside dentro del chip de seguridad por hardware de tu Mac. No se puede exportar, suplantar mediante phishing ni copiar a la máquina de un atacante.
Creative Machines nunca ve una contraseña porque no hay contraseña que ver. Nunca recibimos un token de inicio de sesión, una cookie de sesión ni una credencial con hash. No hay nada que podamos perder en una brecha porque no guardamos nada.
Tu clave de acceso se sincroniza con tus otros dispositivos Apple a través del Llavero de iCloud, cifrada de extremo a extremo por Apple. Así es como la app de iOS de Ostler desbloqueará los datos del mismo Hub sin un segundo paso de configuración.
Cada base de datos de Ostler en el disco está cifrada con una 32-byte data-encryption key (DEK). La DEK se genera en tu Mac en el momento de la instalación, nunca sale de tu Mac en texto plano y se encapsula (cifra) bajo una clave derivada de tu clave de acceso. Desbloquear Ostler significa: tu biometría desbloquea la clave de acceso, la clave de acceso desencapsula la DEK, la DEK descifra las bases de datos. Cuando la app se bloquea, la DEK se borra de la memoria.
Ostler se bloquea automáticamente tras un periodo configurable de inactividad. Al bloquearse, la clave de cifrado en memoria se sobrescribe. Un Mac robado o perdido en el escritorio del atacante no puede entregar texto plano sin un Touch ID / Face ID en vivo de tu parte.
La mayoría del software de consumo no modela en serio el robo del dispositivo – la nube guarda la copia real, así que un dispositivo robado se trata como un terminal perdido. Nosotros lo modelamos porque aquí el dispositivo es los datos, y los datos son íntimos. No hay copia en la nube a la que recurrir. El bloqueo automático, el borrado de la clave en memoria y la exigencia de una biometría en vivo para volver a desbloquear están diseñados en torno a esa realidad, no añadidos a posteriori.
Un patrón habitual en los productos “sin contraseña” es vincular la autenticación o la recuperación al correo electrónico – un enlace mágico, un código de un solo uso, un flujo de restablecimiento de contraseña. En la superficie parece sólido; no hay contraseña que suplantar. La trampa es que la seguridad de todo el sistema hereda la seguridad de la cuenta de correo del usuario. Una bandeja de entrada comprometida es una identidad comprometida.
Ostler no funciona así. No hay correo de restablecimiento de contraseña, ni enlace mágico, ni recuperación vinculada al correo para el producto local. La data-encryption key la emite el Hub en tu Mac en el momento de la instalación y se encapsula bajo una clave derivada de tu clave de acceso, que reside en el Secure Enclave de tu Mac. La única alternativa fuera de banda es la frase de 12 palabras que anotaste. La cadena de custodia nunca pasa por tu bandeja de entrada.
Hay exactamente una alternativa: una frase de recuperación de 12 palabras generada durante la configuración. La escribes en papel. La guardas en un lugar seguro. Nunca la escribes en iCloud, Dropbox, un gestor de contraseñas ni una foto.
La frase se te muestra una sola vez, en una pantalla que bloquea copiar y pegar, y nunca se almacena en el disco después. Para ser concretos sobre qué usamos de BIP39 y qué no: usamos su lista de 2048 palabras en inglés y su codificación de entropía a palabras (128 bits de entropía más una suma de verificación de 4 bits ⇒ 12 palabras). No implementamos el paso PBKDF2 de mnemónico a semilla de BIP39 – tratamos la entropía directamente como nuestro material de clave de recuperación, que es la opción correcta para un sistema que no es un monedero. Ostler no es un monedero de criptomonedas y no afirmamos compatibilidad de monedero BIP39. Usamos la lista de palabras porque está auditada públicamente y probada ergonómicamente, no porque interoperemos con nada.
Si pierdes tu Mac y tu iPhone, y el Llavero de iCloud no ha restaurado tu clave de acceso en un dispositivo nuevo, la frase de recuperación es cómo vuelves a entrar. Desencapsula una segunda copia, independiente, de la misma DEK.
Si pierdes la frase y todos tus dispositivos Apple y tu copia de seguridad de Time Machine simultáneamente, tus datos se han perdido. Por nosotros, por cualquiera. Ese es el precio de la privacidad real – la misma arquitectura que nos impide leer tus datos nos impide ayudarte a recuperarlos.
Tus datos están protegidos por múltiples capas. Cada fila de abajo muestra el estado actual y honesto – no lo que pretendemos, sino lo que está realmente en la compilación:
| Componente | Cifrado | Estado |
|---|---|---|
| Disco completo | macOS FileVault (AES-256-XTS) | Activo El instalador comprueba que esté activado |
| Bases de datos SQLite | SQLCipher (AES-256) | Activo en el código Se despliega con el instalador en el lanzamiento |
| Almacén seguro de la app de iOS | Realm (AES-256), clave vinculada al dispositivo | Activo Almacén de perfil de voz cifrado en iOS hoy |
| Almacén principal de la app de iOS | Clave Realm derivada de la clave de acceso (compartida con el Hub) | En desarrollo Especificación multiplataforma aprobada; flujo de emparejamiento de iOS a continuación |
| Bases de datos vectoriales + de grafos | Volumen APFS cifrado | En desarrollo La creación de volumen por script llega al instalador |
| Registro de auditoría local | Cifrado por SQLCipher, de solo anexado | Activo en el código La cadena de integridad HMAC por entrada es una mejora prevista |
| Copias de seguridad de Time Machine | Hereda FileVault | Activo A través del cifrado de Time Machine de macOS |
Dos piezas de Ostler llegan a tu Mac desde Internet en el momento de la instalación: el propio binario del asistente y los pesos del modelo LLM local. Tratamos la integridad de cada uno de forma distinta porque la forma de la confianza es distinta.
El binario del asistente se distribuye como un tarball firmado con una suma de verificación SHA-256 publicada en un archivo adjunto. El instalador descarga ambos, calcula el hash del tarball y se niega a continuar si los valores no coinciden. La manipulación entre nuestra canalización de publicación y tu Mac – por un intermediario, por una CDN comprometida, por cualquier agente intermedio – es un fallo de instalación rotundo, no un compromiso silencioso.
Los pesos del modelo provienen de registros upstream curados (el registro de Ollama, Hugging Face) por TLS en el momento de la instalación. Fijamos los nombres de los modelos; confiamos en la disciplina de inmutabilidad de etiquetas del mantenedor upstream para saber a qué bytes resuelven esos nombres. Somos honestos sobre la afirmación de confianza: si un mantenedor de un upstream del que dependemos distribuyera una actualización maliciosa bajo una etiqueta que habíamos fijado, las instalaciones nuevas la descargarían hasta que el upstream detectara el problema. Fijamos versiones donde podemos, leemos los registros de cambios, mantenemos pequeña la superficie de modelos. Reforzar esto aún más fijando los digests de contenido es un elemento de endurecimiento en la lista posterior al lanzamiento.
Cuando la app de iOS de Ostler se comunica con tu Mac Hub, la conexión está diseñada para funcionar por TLS con un certificado autofirmado generado durante la instalación, con el iPhone fijando la clave pública del certificado en el momento del emparejamiento para que solo tu Mac pueda responder.
El contrato criptográfico – formato del código QR de emparejamiento, handshake WebAuthn, prueba HMAC de la clave de acceso compartida, expiración del token de emparejamiento de diez minutos – está fijado en una especificación normativa multiplataforma aprobada el 23-04-2026 tanto por los implementadores del lado del Hub como del lado de iOS. Cada constante HKDF, byte del formato de transmisión y vector de prueba está fijado. La firma de código del lado del Hub es el último obstáculo antes de que el emparejamiento de iPhone a Hub funcione de extremo a extremo (ver más abajo).
127.0.0.1 (solo bucle local); ninguno acepta conexiones de LAN. Esto protege contra cualquier atacante que no esté ya en tu Mac. No aísla a Ostler de otro software que se ejecute en el mismo Mac que tú – ver más abajo.La IA dentro de Ostler es un infiltrado con instrucciones, según la formulación del aviso destacado en la parte superior de esta página. Esta sección es lo que eso significa en términos concretos: qué tiene permitido hacer el asistente, qué no tiene permitido hacer y cómo se registran sus acciones.
Confinamiento del espacio de trabajo. El asistente lee y escribe dentro de un espacio de trabajo de denegación por defecto. Los directorios que contienen tus credenciales y tus claves privadas – ~/.ssh, ~/.gnupg, ~/.aws, ~/.config, los directorios de sistema bajo /etc, /usr, /var – están en una lista de denegación estática que protege por ruta cada herramienta que toca archivos. El asistente puede leer tus mensajes, tu correo y los documentos que le has pedido que lea; no puede, ni siquiera por accidente, leer tu clave SSH.
Binario reforzado. El binario del asistente se compila con el macOS Hardened Runtime activado, con las capacidades de JIT, inyección de bibliotecas y variables de entorno de dyld denegadas en el momento de la firma de código. Las vías habituales de inyección a nivel de proceso que funcionan contra el software corriente de Mac – hooks de DYLD_INSERT_LIBRARIES, inyección de código mapeado por JIT, reescrituras de variables de entorno del cargador – no funcionan contra el asistente. La confianza por firma de código es la barrera; solo se ejecuta el binario original.
Barrera de aprobación por herramienta. Cada llamada a una herramienta pasa por una barrera de aprobación. En modo Supervisado (el predeterminado), una herramienta que no se haya preaprobado en esta sesión se bloquea hasta que digas que sí. Las listas de permitidos con alcance de sesión hacen lo que dice su nombre: caducan cuando termina la sesión, no cuando el asistente decide que se ha ganado tu confianza para siempre.
Denegación por defecto impulsada por canal. Cuando el asistente está siendo impulsado por un mensaje entrante – iMessage, WhatsApp, correo – no hay un humano en el teclado para aprobar una llamada a una herramienta. En esa postura, el asistente no puede preguntar, así que no ejecuta ninguna herramienta fuera de una pequeña lista de permitidos de solo lectura (búsqueda, consulta, obtención de una página web pública). Una inyección de prompt que llega por mensaje no puede escalar a escrituras de archivos, llamadas de red arbitrarias ni comandos de shell destructivos; la superficie de la herramienta de shell en esta postura está acotada por una lista de permitidos de comandos preaprobados independiente.
Registro de auditoría a prueba de manipulaciones. Cada llamada a una herramienta escribe un registro en un registro de auditoría local que usa una cadena de hash SHA-256: cada entrada incluye el hash de la entrada anterior, de modo que una entrada eliminada o editada rompe la cadena de una manera que la validación por reproducción detecta. La firma HMAC de cada entrada se admite como paso de endurecimiento adicional. El registro de auditoría es local; no se envía a ninguna parte.
Conversaciones privadas por defecto. Las conversaciones entre tú y el asistente se almacenan en tu Hub y se marcan como privadas por defecto. El contenido etiquetado en el nivel de privacidad más sensible (los cuerpos completos de transcripción que has compartido en confianza) se retiene de las respuestas a las consultas a menos que el cliente que llama opte explícitamente por incluirlo. La vía de API predeterminada devuelve metadatos, no cuerpos.
Ostler se ejecuta como tu cuenta de usuario en tu Mac – no como root, no como un servicio del sistema. El orquestador, la pasarela de API, las bases de datos locales y los procesos de inferencia se ejecutan todos dentro del alcance de permisos de tu usuario. No hay ningún LaunchDaemon que se distribuya con el instalador, ni ningún proceso en segundo plano que sobreviva al cierre de sesión.
El instalador pide una contraseña de administrador una sola vez, en el momento de la instalación, para las operaciones a nivel de sistema que macOS requiere como administrador: cambiar los ajustes de gestión de energía para que el Hub siga siendo accesible para tu iPhone cuando el Mac está inactivo (desactivar la suspensión con CA, activar wake-on-magic-packet) e instalar los paquetes de soporte (Homebrew, Ollama) que se distribuyen como CLI estándar de macOS. Tras la instalación, ninguna parte de Ostler pide privilegios elevados para ejecutarse, y la aplicación no tiene ninguna vía que escale por sí sola.
Esto acota el radio de impacto de un fallo o de un ataque exitoso contra Ostler en sí: hereda el alcance de tu usuario, no el del sistema. No protege contra malware que ya haya obtenido los permisos de tu usuario por algún otro vector – esa es la superficie de la que trata la siguiente sección.
Cerrar la nube cierra la clase de ataque más grande y aburrida – la que expone a un millón de personas de una vez. No significa que nunca pueda salir nada mal. Preferimos decirte los límites a dejar que los descubras.
Esta es la superficie de amenaza realista para un producto local-first, y somos explícitos al respecto. Si una pieza de malware llega a tu Mac a través de una extensión de navegador maliciosa, una descarga envenenada o una app comprometida de fuera de la App Store, hereda la capacidad de tu usuario de hablar con localhost. La capa de cifrado en reposo protege contra el robo físico y contra que tus datos salgan del dispositivo, pero no aísla a Ostler de otro software al que has dado permiso para ejecutarse. Trata tu Mac Hub como tratarías un gestor de contraseñas o una app bancaria: no instales utilidades al azar, no apruebes avisos de instalador que no hayas iniciado tú, e idealmente usa un Mac que ejecute sobre todo Ostler y poco más.
Ostler se apoya en Ollama, un archivo de modelo LLM, un entorno de ejecución de Python y un pequeño conjunto de paquetes de Python. No los escribimos nosotros, los usamos. Si alguno de esos proyectos upstream distribuyera mañana una actualización maliciosa, las instalaciones nuevas – las nuestras, las tuyas, las de todos los demás usuarios – quedarían expuestas hasta que se detectara el problema. Fijamos versiones, leemos los registros de cambios, mantenemos la superficie de dependencias lo más pequeña posible. No vamos a fingir que el riesgo es cero. La misma advertencia sobre la cadena de suministro se aplica a cualquier software que instales alguna vez, en cualquier sitio.
La frase de recuperación es la puerta trasera del peor caso. Si la escribes en una nota adhesiva, le haces una foto, la pegas en una app de notas en la nube o la lees en voz alta en una videollamada, la frase se convierte en el camino más corto del atacante. Te lo ponemos fácil para hacer lo correcto – la pantalla bloquea copiar y pegar, el documento de recuperación explica la amenaza – pero el último eslabón de la cadena eres tú.
Este es el precio de un sistema que guarda las claves en tu hardware, no en el nuestro. Podemos diseñar la arquitectura del interior; no podemos diseñar para sortear una mala higiene operativa. La mitigación es documentación honesta, no una promesa que podamos cumplir en tu lugar.
Estamos contratando a asesores de seguridad sénior y definiendo el alcance de una auditoría de seguridad independiente por parte de una firma de ciberseguridad reconocida. El alcance cubre la autenticación, el tratamiento de datos, el cifrado del almacenamiento, la postura de red y el análisis de dependencias. El informe se publicará aquí cuando esté completo.
Elegimos una auditoría profesional en lugar de depender de la revisión de código por parte de la comunidad porque una revisión de expertos es más rigurosa que esperar que alguien lea el código. La confianza debería ser verificable, no presunta. “Prometemos no mirar tus datos” es lo que dice toda empresa de la nube. “Arquitectónicamente no podemos mirar tus datos, y aquí está el informe del auditor que lo demuestra” es a lo que aspiramos.
La arquitectura es intencionadamente sencilla. Autenticación con clave de acceso como método principal a través de los propios frameworks de Apple. Primitivas criptográficas estándar (HKDF-SHA256, AES-KW RFC 3394). Servicios locales en 127.0.0.1. Inferencia local de Ollama. Hay muy poca criptografía novedosa que se pueda fallar porque el mecanismo de seguridad principal es no tener una conexión de red para empezar.
Clave de acceso (WebAuthn Level 2) registrada contra el autenticador de plataforma de Apple mediante ASAuthorizationPlatformPublicKeyCredentialProvider, usando la extensión PRF. Requiere macOS 15+ / iOS 17.4+. La salida PRF es un valor pseudoaleatorio vinculado al autenticador, a la credencial y al identificador de la parte de confianza – no exportable desde el Secure Enclave.
Un pequeño binario auxiliar en Swift es dueño de cada llamada WebAuthn y se comunica con el lado de Python mediante JSON-RPC de un solo uso. AuthenticationServices + Security.framework puros, sin paquetes de Swift de terceros.
rp_id = creativemachines.ai. Vinculado al dominio de la empresa, no al nombre del producto, de modo que un futuro cambio de nombre del producto no pueda invalidar las credenciales de los usuarios existentes.
HKDF-SHA256. Las cadenas info con separación de dominio usan el espacio de nombres creativemachines/ por la misma razón de seguridad ante el cambio de marca. Ningún PBKDF2 en ninguna parte de la vía principal – la salida PRF ya es una clave de entropía completa.
AES Key Wrap, RFC 3394 unpadded variant. Una 32-byte DEK encapsulada bajo una 32-byte KEK produce un blob de 40 bytes con una comprobación de integridad integrada. Una KEK incorrecta falla al desencapsular – no devuelve texto plano basura.
Frase de 12 palabras de la misma lista de 2048 palabras en inglés auditada públicamente que BIP39, 128 bits de entropía nativa más una palabra de suma de verificación. La entropía de 16 bytes alimenta HKDF-SHA256 con la misma sal compartida, bajo una cadena info distinta, para derivar una KEK de recuperación independiente. Sin paso PBKDF2 de mnemónico a semilla – un segundo KDF sobre una entrada que ya es de entropía completa no añade seguridad en este modelo de amenazas. Tomamos prestada la lista de palabras; no afirmamos compatibilidad de monedero BIP39.
SQLCipher (AES-256) para las bases de datos de Ostler en el Mac Hub. Realm (AES-256) para la app de iOS. Elementos del Llavero con alcance AccessibleWhenUnlockedThisDeviceOnly, Synchronizable = false – las DEK encapsuladas nunca viajan en Time Machine ni en Asistente de Migración.
Clave de sesión de larga duración mantenida como un bytearray mutable y puesta a cero mediante ctypes.memset al bloquear o al agotarse el tiempo de espera. Las copias inmutables de corta duración en Python se documentan honestamente como solo de mejor esfuerzo, no se afirma que estén garantizadamente borradas.
TLS con un certificado de servidor Ed25519 autofirmado generado en la instalación. Clave pública fijada por la app de iOS en el primer emparejamiento. Sin HTTP no fijado. Sin canal de respaldo a nivel de aplicación.
El contrato criptográfico multiplataforma completo entre el Mac Hub y la app de iOS, incluyendo cada constante, vector de prueba y byte del formato de transmisión, está disponible para revisión independiente.
La transparencia significa admitir exactamente en qué punto se encuentra hoy cada pieza, con un obstáculo nombrado de forma específica para todo lo que aún no está en funcionamiento:
ASAuthorizationPlatformPublicKeyCredentialProvider real + extensión PRF mediante macOS 15 AuthenticationServices. Compila y se ejecuta. Operaciones del Llavero probadas en frío contra un Security.framework real el 23-04-2026.ctypes.memset al bloquear, callback de redesbloqueo por excepción tipada.~/Library/LaunchAgents/ con protecciones contra la inyección de rutas en todas las rutas de certificado.register / assert – la llamada nunca se completa, en silencio. El certificado Developer ID de Creative Machines ya está en su sitio y notariza el binario del asistente; el trabajo restante es firmar el propio asistente auxiliar de clave de acceso, cablear su archivo de entitlements y servir el documento apple-app-site-association desde creativemachines.ai.~/.ostler/. Sin obstáculo técnico – priorizado después del trabajo de SQLCipher y de clave de acceso, que fue primero porque protege la superficie de datos más grande.Si crees que has encontrado una vulnerabilidad de seguridad en cualquier parte de Ostler – el instalador del Mac Hub, la app de iOS, el asistente auxiliar de clave de acceso, la canalización de actualización de Sparkle o cualquier infraestructura relacionada – comunícalo a [email protected].
Lo que prometemos a cambio:
Lo que pedimos a cambio: no accedas a los datos de otros usuarios, no interrumpas nuestros servicios y no exijas un pago como condición para la divulgación. No tenemos un programa de recompensas por errores remunerado en el lanzamiento – si eso cambia, esta página lo dirá.
Para informes cifrados, nuestra clave pública PGP está publicada en /security.asc. La política de divulgación completa también es legible por máquina en /security.txt conforme a la RFC 9116.
La historia de la seguridad es la historia de la privacidad. Cada competidor envía tus datos a la nube y promete protegerlos. Nosotros mantenemos tus datos en tu hardware y demostramos que no pueden salir. Eso no es una característica. Es la arquitectura.
Detalles concretos · Sin palabrería