Incidenthantering
Vad händer om någon öppnar länken först?
Vad du ska göra när en känslig länk eller ett lösenord kan ha nått fel person.
Publicerad: 15 april 2026
Gränser för den aktuella implementationen
Den aktuella klienten krypterar texten i webbläsaren och bär det krypterade innehållet i URL:en. Lösenordet som delas separat finns inte i länken. Det finns ingen applikationsserver som lagrar, hämtar, raderar eller förbrukar meddelanden en enda gång.
Mer sammanhang
Direkt svar: Collogue kan inte visa vem som öppnade en länk. Om länken och det separat delade lösenordet kan ha nått fel person ska du behandla inloggningsuppgifterna som möjliga att ha röjts: återkalla eller byt ut dem, kontrollera mottagaren via en annan kanal och skapa ett nytt meddelande i stället för att skicka samma värde igen.
Collogue har ingen serverbaserad läshändelse och kan därför inte bevisa att en person öppnade ett meddelande eller identifiera läsaren. En trasig länk eller misslyckad dekryptering kan också bero på en ofullständig eller ändrad URL eller på fel lösenord.
Om meddelandet innehöll ett lösenord, en API-nyckel, en sessionstoken, en återställningskod eller en åtkomstlänk ska du behandla värdet som röjt.
- Återkalla eller byt ut det.
- Skicka inte samma värde igen.
- Bekräfta den avsedda mottagaren.
- Skapa om möjligt ett nytt tillfälligt värde.
- Skicka en ny Collogue-länk.
- Undersök leveransvägen om problemet upprepas.
En permanent inloggningsuppgift skapar en större incident än en tillfällig. Därför hör leverans och utformning av inloggningsuppgifter ihop.
Alla privata meddelanden innehåller inte en inloggningsuppgift.
Om innehållet var en okritisk anteckning kan avsändaren skapa ett nytt meddelande efter att mottagaren har bekräftats. Risken beror på textens känslighet och konsekvenserna av att den röjs.
Tjänsten kan inte fatta det beslutet åt användaren. Den kan förklara tillståndet tydligt.
Endast om tjänsten avsiktligt samlar in relevanta bevis och kan tolka dem tillförlitligt – och även då kan attributionen vara osäker.
- den avsedda mottagaren;
- en företagsproxy;
- en mobiloperatör;
- en VPN;
- en e-postskanner;
- ett delat nätverk;
- en angripare.
En user agent kan beskriva programvara, inte en person.
Antyd inte att en granskningslogg identifierar en människa om systemet inte innehåller en autentiserad mottagaridentitet och påståendet saknar stöd.
Vid återkommande leveransfel inom en organisation bör du testa icke-känsliga länkar genom samma e-postväg och granska säkerhetsgatewayens policy med administratören. Använd inte en riktig inloggningsuppgift som testmeddelande.
- bedöm konsekvensen av att uppgiften röjs;
- bekräfta om mottagaren öppnade länken;
- upprepa inte mer sammanhang än nödvändigt;
- använd organisationens godkända incidentprocess för reglerad information.
Nej. Den aktuella klienten samlar inte in läshändelser, och en URL-begäran identifierar inte en person.
Om en lösenordslänk inte kan dekrypteras, kontrollera URL:en och lösenordet. Byt ut inloggningsuppgiften när båda delarna kan ha röjts.
Collogue kan inte tillförlitligt skilja en skanner från en person. Publicera bara de diagnostiska möjligheter som koden faktiskt erbjuder.