Risposta agli incidenti
Cosa succede se qualcuno apre prima il link?
Cosa fare quando un link sensibile o una password potrebbe essere arrivato alla persona sbagliata.
Pubblicato: 15 aprile 2026
Limiti dell’implementazione attuale
Il client attuale cifra il testo nel browser e inserisce il contenuto cifrato nell’URL. La password condivisa separatamente non fa parte del link. Non esiste un server applicativo che memorizzi, recuperi, elimini o consumi i messaggi una sola volta.
Ulteriore contesto
Risposta diretta: Collogue non può mostrare chi ha aperto un link. Se il link e la password condivisa separatamente potrebbero essere arrivati alla persona sbagliata, considera le credenziali potenzialmente esposte: revocale o sostituiscile, verifica il destinatario tramite un altro canale e crea un nuovo messaggio invece di inviare di nuovo lo stesso valore.
Collogue non dispone di un evento di lettura lato server, quindi non può dimostrare che una persona abbia aperto un messaggio né identificare chi lo ha visualizzato. Un link non funzionante o una decifratura fallita possono dipendere anche da un URL incompleto o modificato, oppure dalla password errata.
Se il messaggio conteneva una password, una chiave API, un token di sessione, un codice di recupero o un link di accesso, considera il valore esposto.
- Revocalo o sostituiscilo.
- Non inviare di nuovo lo stesso valore.
- Conferma il destinatario previsto.
- Crea, quando possibile, un nuovo valore temporaneo.
- Invia un nuovo link Collogue.
- Esamina il percorso di consegna se il problema si ripete.
Una credenziale permanente crea un incidente più grave di una temporanea. Per questo consegna e progettazione delle credenziali devono essere considerate insieme.
Non tutti i messaggi privati contengono una credenziale di accesso.
Se il contenuto era una nota non critica, il mittente può creare un nuovo messaggio dopo aver confermato il destinatario. Il rischio dipende dalla sensibilità del testo e dalle conseguenze della divulgazione.
Il servizio non può prendere questa decisione al posto dell’utente. Può però spiegare chiaramente lo stato.
Solo se il servizio raccoglie intenzionalmente prove rilevanti e può interpretarle in modo affidabile; anche in quel caso, l’attribuzione può rimanere incerta.
- il destinatario previsto;
- un proxy aziendale;
- un operatore mobile;
- una VPN;
- uno scanner e-mail;
- una rete condivisa;
- un attaccante.
Un user agent può descrivere un software, non una persona.
Non lasciare intendere che una traccia di audit identifichi un essere umano se il sistema non include un’identità autenticata del destinatario e l’affermazione non è supportata.
In caso di errori di consegna ricorrenti all’interno di un’organizzazione, prova link non sensibili attraverso lo stesso percorso e-mail e verifica la policy del gateway di sicurezza con l’amministratore. Non usare una credenziale reale come messaggio di test.
- valuta le conseguenze della divulgazione;
- conferma se il destinatario ha aperto il link;
- non ripetere più contesto del necessario;
- usa il processo di gestione degli incidenti previsto per le informazioni regolamentate.
No. Il client attuale non raccoglie eventi di lettura e una richiesta URL non identifica una persona.
Se un link con password non si decifra, verifica l’URL e la password. Sostituisci la credenziale ogni volta che entrambi gli elementi potrebbero essere stati esposti.
Collogue non può distinguere in modo affidabile uno scanner da una persona. Pubblica solo le capacità diagnostiche effettivamente offerte dal codice.