¿Están mis datos del diario a salvo de hackers (o de la propia empresa)?
Esa pregunta esconde dos amenazas distintas — un atacante externo que vulnera un servidor, y la propia empresa que gestiona ese servidor decidiendo (o viéndose obligada a) mirar tus datos. El cifrado del diario de cultivo en GrowScope está diseñado para que ambas sean el mismo no-evento: ninguna de las dos tiene una clave que funcione.
Una brecha del servidor expone texto cifrado, no tu diario
Como el cifrado ocurre en tu dispositivo antes de enviar nada, lo que realmente hay en el servidor de GrowScope son bytes ya cifrados del contenido de tu diario. Si el servidor sufriera una brecha, un atacante que accediera a esos datos obtendría texto cifrado ilegible, no un diario de cultivo legible — no hay ninguna clave guardada junto a los datos que permita descifrarlos, porque la clave, en una forma utilizable, nunca sale de tu dispositivo.
La propia empresa tampoco puede leerlo — y no se le puede obligar
Esto es lo que separa un diseño de privacidad real de una simple política de privacidad: GrowScope no elige no mirar — estructuralmente no puede. No hay un botón de 'ver datos del usuario' en soporte técnico que funcione sobre un diario cifrado, ni una clave en una base de datos que una orden legal pueda obligar a entregar, porque esa clave no existe en ningún sitio salvo, de forma momentánea, derivada en tu propio dispositivo cuando lo desbloqueas.
Contra qué no protege esto
El cifrado no es un escudo universal, y conviene ser precisos al respecto. No te protege de alguien que tenga tu dispositivo desbloqueado o tu frase de recuperación anotada — la seguridad vive en la clave, y quien tenga la clave tiene el mismo acceso que tú. Y deliberadamente no se extiende a las funciones de IA: cuando ejecutas una (diagnóstico por foto, el asesor de fertilizantes, arte de tarjetas), los datos que esa acción necesita se descifran en tu dispositivo y se envían, una vez, a través del servidor de GrowScope a un proveedor externo de modelos (Anthropic Claude, o Google Gemini vía OpenRouter) para generar la respuesta, y después no se guardan — una excepción declarada y voluntaria, limitada a esa única acción, no un vacío silencioso en la promesa del cifrado. Se valoró y se descartó una IA totalmente en el dispositivo para estas funciones concretas precisamente porque tareas como el cálculo de dosis de fertilizante o la lectura de fotos de tricomas y plagas son justo donde los modelos pequeños locales son más débiles.
Por qué 'zero-knowledge' no es solo una palabra de moda aquí
El término para este diseño es cifrado de conocimiento cero (zero-knowledge): el servidor guarda y procesa datos que no tiene ninguna capacidad de leer. Es una arquitectura concreta y verificable (cifrado en el dispositivo, una clave derivada de una frase que solo tú ves, nada utilizable guardado en el servidor), no un sinónimo de 'confía en nosotros'. La contrapartida también es real: un diseño que le da a una empresa conocimiento cero de tus datos también le da a esa empresa capacidad cero de recuperarlos por ti si pierdes tu propia clave — sobre esa otra mitad del panorama trata el artículo sobre la contrapartida de la frase de recuperación.
Cómo ayuda GrowScope
Esto cubre todas las cuentas por defecto — no hay nada que configurar. Quien quiera el mecanismo exacto (los métodos concretos de cifrado y derivación de claves, y cómo se separan los registros individuales para que una clave comprometida no exponga todo a la vez) puede leer el desglose técnico completo en la documentación de cifrado, en vez de dar este resumen por bueno.
Idea clave
Como el cifrado ocurre en el dispositivo antes de enviar los datos, tanto una brecha del servidor como una solicitud a la propia empresa chocan con la misma pared: en el servidor solo existen bytes ilegibles, y no hay ninguna clave utilizable en ningún sitio salvo, momentáneamente, en tu propio dispositivo desbloqueado.