Cómo funcionan los enlaces secretos de LinkPilot.

1. Visión general

LinkPilot gestiona dos circuitos de enlaces distintos en la misma plataforma: los enlaces inteligentes, enlaces cortos con tu propio dominio y estadísticas de clics, y los enlaces secretos, para entregar contenido confidencial una sola vez, con expiración y frase de contraseña. Se mantienen separados en los datos, en el código y en el producto, de modo que el contenido de un secreto nunca pueda acabar en los paneles de estadísticas, en las exportaciones de datos ni en las funciones de IA.

Esta página describe solo el circuito de los enlaces secretos: cómo se crea un secreto, cómo se muestra, qué pasa después de verlo y qué metadatos se registran por el camino.

2. Cómo funcionan los enlaces secretos

1. Quien envía crea un secreto y, si quiere, le pone una frase de contraseña, un plazo de expiración y un límite de visualizaciones tras el que se destruye.
2. El navegador de quien envía cifra el contenido antes de enviar nada. Lo que nos llega es texto cifrado, que se escribe en una tabla propia, secret_links, aislada de las tablas de estadísticas de clics.
3. LinkPilot devuelve un enlace corto (por ejemplo, shrd.link/s/<slug>#k=<key>) para compartirlo con el destinatario. La parte que va después del # es la clave de descifrado: se genera en el navegador de quien envía y nunca se nos transmite. No podemos reconstruir este enlace más tarde.
4. Cuando el destinatario abre el enlace, la aplicación llama a la función edge secret-reveal. Una petición GET devuelve solo metadatos (el estado y si hace falta frase de contraseña). Solo una petición POST con la frase de contraseña devuelve el texto cifrado. Después, el navegador del destinatario lo descifra con la clave que hay en la parte del enlace que va después del #. La función que muestra el secreto nunca descifra nada, y no podría hacerlo aunque quisiera.
5. Cada visualización correcta se registra de forma atómica y, según el límite de visualizaciones configurado, puede marcar el secreto como burned (destruido) en ese mismo momento.

3. Modelo de cifrado

Aquí queremos ser precisos, porque las palabras «cifrado» y «conocimiento cero» se usan a menudo sin rigor.

• En tránsito: todo el tráfico va cifrado con TLS de extremo a extremo entre el destinatario, nuestra red edge y nuestra base de datos gestionada.
• En tu navegador, antes del envío: desde el 29 de septiembre de 2026 el contenido se cifra en el cliente con AES-GCM-256, con una clave de 256 bits generada en tu navegador. Guardamos el texto cifrado y nada más. La clave viaja en el enlace que compartes, después del #, y los navegadores no envían esa parte a ningún servidor: ni a nosotros ni a Cloudflare, que sirve la página donde se muestra el secreto.
• En reposo: el texto cifrado está en una columna separada lógicamente de los datos de estadísticas, en una instancia gestionada de Postgres que además cifra el disco.
• Frases de contraseña: cuando pones una, se normaliza a una forma Unicode estándar (NFKC), para que la misma frase escrita con otro teclado u otro método de entrada produzca la misma clave. Después se refuerza con PBKDF2-SHA256 (210.000 iteraciones) y se combina con la clave del enlace mediante HKDF-SHA256, de modo que ni el enlace por sí solo ni la frase por sí sola descifran el secreto. Aparte, se envía un hash SHA-256 de la frase para que el servidor pueda negarse a devolver el texto cifrado a quien no la conozca. La frase de contraseña sin cifrar nunca se escribe en nuestra base de datos ni en nuestros registros.
• Qué protege y qué no: nos deja fuera del perímetro de confianza a nosotros, a nuestra base de datos y a nuestra red edge. No protege un secreto cuyo enlace completo se ha reenviado, se ha capturado en pantalla o ha quedado registrado en algún sistema del lado del destinatario, porque ese enlace lleva la clave.
• Las dos excepciones, dichas claramente: los secretos creados antes del 29 de septiembre de 2026 se guardan como texto sin cifrar. Nunca se reescriben sin avisar, siguen funcionando exactamente igual que antes y desaparecen a medida que expiran. Los archivos adjuntos también se cifran en el navegador, con una clave derivada de la clave del propio secreto, así que un mismo enlace abre ambos y no tenemos la clave de ninguno de los dos. Lo que sí podemos ver es el nombre, el tamaño y el tipo de un archivo: son columnas de metadatos, no contenido. Los adjuntos subidos antes del 29 de septiembre de 2026 siguen guardados como archivos sin cifrar.

La consecuencia práctica merece decirse claramente: como nunca tenemos la clave, no podemos recuperarte un secreto. Si se pierde el enlace, el contenido se pierde con él.

Compruébalo tú mismo. No tienes que fiarte de nuestra palabra sobre el cifrado en el navegador. El mismo código de cifrado se publica en nuestro repositorio linkpilot-cli de código abierto (con licencia MIT), que contiene la CLI, el SDK para TypeScript y el servidor MCP. El repositorio incluye los vectores de prueba con los que se comprueba la aplicación web, así que puedes leer la derivación de claves, ejecutar los vectores y confirmar que lo que sale de un cliente es texto cifrado y que la clave solo se incluye en la parte del enlace que va después del #. Si encuentras alguna diferencia entre ese código y esta página, avísanos.

4. Qué pasa después de ver un secreto

• La visualización se registra de forma atómica mediante una función de la base de datos, así que dos intentos simultáneos de ver el secreto no pueden filtrarlo dos veces.
• Si se alcanza el límite de visualizaciones, el estado del secreto pasa a burned y el contenido guardado se sobrescribe con [REDACTED].
• Los intentos posteriores de verlo reciben una respuesta clara de que el secreto ya se vio y se destruyó, con el código HTTP 410.
• El historial de auditoría registra cada visualización, destrucción y revocación con la IP en hash, algo útil para responder a incidentes y para cambiar credenciales.

5. Expiración y revocación

• Cada secreto puede tener una expiración por tiempo (1 hora, 24 horas o 7 días en cualquier plan, o una fecha y hora a medida en el plan Pro) y, si se quiere, un máximo de visualizaciones.
• Los secretos expirados pasan al estado expired en el siguiente acceso, y el contenido se borra en esa misma escritura.
• El propietario puede revocar un secreto a mano en cualquier momento desde el panel. Un secreto revocado deja de mostrarse al instante y devuelve el código HTTP 410.
• Cuando un secreto se ha destruido, ha expirado o se ha revocado, el contenido no se puede recuperar desde el producto: por diseño, no existe ninguna acción para deshacer la revocación ni para restaurarlo.

6. Protección con frase de contraseña

• La frase de contraseña es opcional, pero la recomendamos para cualquier secreto que no quieras que consuma alguien que lo abra por error.
• El navegador calcula el hash SHA-256 de la frase de contraseña, lo envía por TLS y el servidor compara los hashes. El valor original nunca llega a nuestra base de datos.
• Limitamos los intentos con la frase de contraseña a 5 por IP, por minuto y por secreto, con un limitador en memoria y una ventana deslizante en la base de datos.
• Cada intento fallido se escribe en el registro de auditoría con la IP en hash, para que los propietarios del espacio de trabajo puedan ver actividad sospechosa.
• Recomendamos enviar la frase de contraseña por un canal distinto del enlace: por ejemplo, el enlace por correo y la frase por mensaje directo de Slack o por SMS.

7. Protección frente a analizadores de enlaces y bots de vista previa

Los analizadores de seguridad del correo y los generadores de vistas previas de las aplicaciones de chat (Slack, LinkedIn, iMessage, Outlook) suelen abrir las URL en cuanto aparecen. Con un enlace que se destruye tras la lectura, un diseño ingenuo haría que la primera vista previa destruyera el secreto antes de que lo viera el destinatario.

LinkPilot lo evita de tres formas:

• Puntos de acceso separados para metadatos y para mostrar el secreto. Un GET al punto de acceso solo devuelve el estado y si hace falta frase de contraseña. Una visualización solo se registra con un POST explícito, que es lo que hace una persona al hacer clic en el botón para mostrar el secreto.
• Frase de contraseña como barrera. Si hay una frase de contraseña, no se devuelve el contenido a nadie, sea bot o persona, sin el hash correcto.
• Cache-Control: no-store en todas las respuestas que muestran un secreto, para que los intermediarios no guarden en caché su contenido.

8. Qué metadatos se registran

En cada intento de ver un secreto registramos solo lo necesario para que los propietarios del espacio de trabajo tengan un historial de auditoría fiable:

• Fecha y hora del intento.
• IP en hash: SHA-256 de la IP del cliente combinada con una sal que cambia cada día, truncado a 32 caracteres. La IP original nunca se guarda.
• Ubicación aproximada (país y ciudad) que da la red edge, cuando el proveedor la facilita.
• Cadena User-Agent que envía el cliente.
• Tipo de evento: created, viewed, failed_passphrase, burned, expired, revoked.

No registramos: el contenido del secreto, la frase de contraseña original, la dirección IP original, cookies del destinatario (no hay ninguna) ni píxeles de seguimiento de terceros.

9. Diferencias entre los enlaces secretos y los enlaces con estadísticas

Los dos circuitos comparten marca, panel y controles de equipo, pero los flujos de datos no se cruzan.

10. Archivos adjuntos

• Los archivos se cifran en el navegador con una clave derivada de la clave del propio secreto, así que un mismo enlace abre el texto y el archivo.
• Se sirven mediante URL firmadas de corta duración, sujetas a la misma frase de contraseña, expiración y destrucción que el texto.
• El nombre, el tamaño y el tipo de un archivo siguen siendo visibles para nosotros como metadatos; su contenido no.
• Los adjuntos subidos antes del 29 de septiembre de 2026 siguen guardados como archivos sin cifrar hasta que expiran; nunca se reescriben.

11. Conservación

• El contenido de un secreto se sobrescribe cuando se destruye, expira o se revoca. Por diseño, no se puede restaurar, y no podemos recuperarlo por ti.
• Los datos de la cuenta se conservan mientras el espacio de trabajo está activo y durante 30 días después de eliminarlo, para poder deshacer una eliminación accidental.
• Las estadísticas de clics de los enlaces cortos se agregan en recuentos anónimos pasados 90 días.
• Los eventos del historial de auditoría solo guardan los valores en hash y con sal que se describen en la sección 8; no hay ninguna dirección original que conservar.

12. Secretos anónimos y secretos del espacio de trabajo

El generador gratis de enlaces secretos crea secretos sin cuenta. «Destruir tras la lectura» está siempre activado, la expiración es de 1 hora, 24 horas o 7 días, Turnstile protege el formulario contra el abuso automatizado y se aplica el mismo cifrado en el navegador.

Un secreto del espacio de trabajo añade el historial de auditoría, la revocación desde el panel, los archivos adjuntos y, en el plan Pro, las frases de contraseña y una fecha y hora de expiración a medida. El modelo de cifrado es idéntico en los dos casos.

13. Límites, dichos claramente

• Un enlace reenviado es un secreto reenviado. Nada en el diseño impide que el destinatario pase el enlace a otra persona antes de abrirlo. Para reducir ese riesgo, usa una expiración corta y una frase de contraseña enviada por otro canal.
• Un enlace perdido es un secreto perdido. Nunca tenemos la clave, así que no hay nada que recuperar.
• La excepción anterior al 29 de septiembre. Los secretos creados antes de esa fecha se guardaron como texto sin cifrar hasta que expiraron.
• No es de código abierto ni se puede autoalojar. El cliente de cifrado se publica con vectores de prueba en el repositorio de la CLI, con licencia MIT; el servicio en sí es un producto alojado. Si necesitas autoalojamiento, consulta las alternativas de código abierto.
• Una visualización no es una persona. El historial registra cuándo se abrió un secreto y, de forma aproximada, desde dónde, pero nunca quién. Si lo abrió quien no debía, cambia la credencial.

14. Informar de una vulnerabilidad

Los hallazgos de seguridad y los enlaces abusivos se pueden notificar en /report y llegan directamente al equipo. Las solicitudes de privacidad y de datos se envían a privacy@uselinkpilot.com y se responden en un plazo de 30 días; la página del RGPD indica qué datos tratamos y con qué base legal.

15. Preguntas frecuentes