Respuesta a incidentes
¿Qué ocurre si otra persona abre primero el enlace?
Qué hacer cuando un enlace sensible o una contraseña pudo llegar a la persona equivocada.
Publicado: 15 de abril de 2026
Límites de la implementación actual
El cliente actual cifra el texto en el navegador y lleva el contenido cifrado en la URL. La contraseña compartida por separado no forma parte del enlace. No existe un servidor de aplicación que almacene, recupere, elimine o consuma mensajes una sola vez.
Contexto adicional
Respuesta directa: Collogue no puede mostrar quién abrió un enlace. Si el enlace y la contraseña compartida por separado pudieron llegar a la persona equivocada, trate las credenciales como potencialmente expuestas: revoque o cambie su valor, verifique al destinatario por otro canal y cree un mensaje nuevo en lugar de volver a enviar el mismo valor.
Collogue no tiene un evento de lectura en el servidor, por lo que no puede demostrar que una persona abrió un mensaje ni identificarla. Un enlace roto o un descifrado fallido también pueden deberse a una URL incompleta o modificada, o a una contraseña incorrecta.
Si el mensaje contenía una contraseña, una clave de API, un token de sesión, un código de recuperación o un enlace de acceso, trate ese valor como expuesto.
- Revoque o cambie su valor.
- No vuelva a enviar el mismo valor.
- Confirme quién es el destinatario previsto.
- Cree un valor temporal nuevo cuando sea posible.
- Envíe un enlace nuevo de Collogue.
- Investigue la ruta de entrega si el problema se repite.
Una credencial permanente provoca un incidente mayor que una temporal. Por eso la entrega y el diseño de credenciales deben considerarse conjuntamente.
No todos los mensajes privados contienen una credencial de acceso.
Si el contenido era una nota no crítica, el remitente puede crear un mensaje nuevo después de confirmar al destinatario. El riesgo depende de la sensibilidad del texto y de las consecuencias de su divulgación.
El servicio no puede tomar esta decisión por el usuario. Sí puede explicar claramente el estado.
Solo si el servicio recopila deliberadamente pruebas relevantes y puede interpretarlas de forma fiable; aun así, la atribución puede seguir siendo incierta.
- el destinatario previsto;
- un proxy corporativo;
- un operador móvil;
- una VPN;
- un escáner de correo;
- una red compartida;
- un atacante.
Un user-agent puede describir software, no a una persona.
No sugiera que un registro de auditoría identifica a un ser humano si el sistema no incluye una identidad autenticada del destinatario y la afirmación no está respaldada.
Si los fallos de entrega se repiten dentro de una organización, pruebe enlaces no sensibles por la misma ruta de correo y revise la política de la pasarela de seguridad con el administrador. No use una credencial real como mensaje de prueba.
- evalúe las consecuencias de la divulgación;
- confirme si el destinatario abrió el enlace;
- no repita más contexto del necesario;
- use el proceso de incidentes aprobado para la información regulada.
No. El cliente actual no recopila eventos de lectura y una solicitud de URL no identifica a una persona.
Si un enlace con contraseña no se descifra, compruebe la URL y la contraseña. Sustituya la credencial siempre que ambos elementos pudieran haberse expuesto.
Collogue no puede distinguir de forma fiable un escáner de una persona. Publique únicamente las capacidades de diagnóstico que el código realmente ofrece.