~/keydrop/legal/privacy
legal
Política de privacidad
Qué guardamos, qué no guardamos y por qué.
Última actualización: 2026-05-01
KeyDrop está diseñado con un enfoque privacy-first. Esta política describe qué datos manejamos y, sobre todo, qué datos no manejamos. Si despliegas KeyDrop por tu cuenta, eres responsable de adaptar este texto a tu marco legal.
Sin cuentas, sin perfiles
No creamos cuentas de usuario ni te pedimos información personal. No usamos analítica de terceros, ni cookies de seguimiento, ni fingerprinting.
Almacenamiento local en tu navegador
KeyDrop guarda dos preferencias de UI en localStorage de tu navegador, exclusivamente para que la web recuerde cómo te gusta verla: el idioma elegido (clave keydrop:locale, valores es o en) y el tema (clave keydrop:theme, valores dark o light). No son cookies, no se envían al servidor en ninguna petición y no contienen ni identificadores personales ni nada relacionado con secretos. Puedes borrarlas en cualquier momento desde las herramientas de desarrollador del navegador o limpiando el sitio; al recargar la web se reinicializan con los valores por defecto.
Generadores: 100% locales
Las contraseñas, passphrases, API keys, bloques .env por variable y bloques .env por stack (incluido /env/generate con sus 11 plantillas) se generan exclusivamente en tu navegador con Web Crypto API. KeyDrop no envía ese contenido a ningún servidor ni lo almacena en ningún sitio: ni en disco, ni en localStorage, ni en sessionStorage, ni en historial.
One Time Secret: zero-knowledge
En la funcionalidad One Time Secret, el secreto se cifra en tu navegador con AES-GCM 256. La clave de descifrado nunca llega al servidor: viaja en el fragmento (#) de la URL, que el navegador no envía. Si activas contraseña adicional, derivamos una clave en cliente con PBKDF2-SHA256 y 600 000 iteraciones; la contraseña tampoco sale de tu equipo. El servidor solo almacena el sobre cifrado, el IV, el salt (si aplica) y los metadatos no sensibles.
Archivos cifrados
El cifrado de archivos sigue el mismo principio que One Time Secret. El nombre, el tipo MIME, el tamaño y los bytes se serializan en un payload binario y se cifran con una clave aleatoria que viaja en el fragmento del enlace. El servidor solo recibe un blob opaco y un id aleatorio. La descarga consume el blob de forma atómica: el segundo intento ya no existe.
Solicitudes de secretos (ECDH)
En /requests tu navegador genera un par ECDH P-256. La clave pública viaja en el fragmento del enlace público que envías a la otra persona; la privada viaja en el fragmento del enlace privado que guardas tú. Quien responde genera un par efímero, deriva una clave compartida y cifra con AES-GCM. El servidor solo guarda identificadores aleatorios y un blob opaco. La privada nunca llega al servidor; sin ella nadie puede descifrar la respuesta. La reclamación es atómica y de un solo uso.
Recibos de estado
Si activas la opción de recibo, el cliente cifra los metadatos del recurso (tipo, fechas) con una clave de estado independiente y los sube como un blob opaco más. El servidor mantiene además un flag plano que se enciende cuando el recurso es revelado, sin más información. La consulta requiere la clave de estado, que vive solo en el fragmento del enlace.
Herramientas locales
El redactor (/redact), el escáner de .env (/env/scan), el diff seguro (/diff), Safe Share (/safe-share), el inspector JWT (/jwt), la herramienta HMAC (/hmac), el generador por stack (/env/generate), el asistente de rotación (/rotate) y el kit de webhooks (/webhooks) procesan tu entrada íntegramente en el navegador. No hay petición al servidor, no hay almacenamiento intermedio y no se guarda historial. Si pasas texto del escáner o del diff al redactor, se transfiere por sessionStorage en una clave efímera que se borra al primer uso.
Anti-preview en rutas sensibles
Las páginas /s/[id], /f/[id], /request/[id], /request/[id]/claim/[claimId] y /status/[id] están servidas con cabeceras Cache-Control: no-store, X-Robots-Tag: noindex, nofollow, noarchive, nosnippet, noimageindex y Referrer-Policy: no-referrer. El robots.txt incluye Disallow para las cinco rutas. Ningún secreto se consume al cargar la página: hace falta una acción explícita del usuario en el botón de revelar o descargar.
Borrado y caducidad
Cada secreto tiene una expiración entre 5 minutos y 7 días. En el primer revelado real, el backend realiza una operación atómica que recupera el sobre y lo elimina inmediatamente. Si nadie lo abre, Redis lo elimina al cumplirse la TTL. Los recibos de estado tienen su propio TTL configurable.
Logs técnicos mínimos
Para operar el servicio podemos registrar marca temporal, endpoint, código HTTP y la IP del cliente con el único fin de aplicar rate limiting. Nunca registramos contenidos sensibles: ni contraseñas, ni passphrases, ni API keys, ni .env, ni el contenido de los secretos.
Datos de terceros
KeyDrop no envía datos a servicios externos. La única dependencia operativa es Redis, usado únicamente para almacenar temporalmente sobres cifrados.
Derechos
Como no almacenamos información personal identificable, no hay datos sobre los que ejercer derechos de acceso, rectificación o supresión. Si despliegas KeyDrop bajo tu marca, ajusta esta sección a tu jurisdicción (RGPD en la UE, LOPDGDD en España, CCPA en California, etc.).