Reaktion auf Vorfälle
Was geschieht, wenn jemand den Link zuerst öffnet?
Was zu tun ist, wenn ein sensibler Link oder ein Passwort die falsche Person erreicht haben könnte.
Veröffentlicht: 15. April 2026
Grenzen der aktuellen Implementierung
Der aktuelle Client verschlüsselt den Text im Browser und legt den verschlüsselten Inhalt in der URL ab. Das separat geteilte Passwort gehört nicht zum Link. Es gibt keinen Anwendungsserver zum Speichern, Abrufen, Löschen oder als Einmalansicht für Nachrichten.
Weiterer Kontext
Direkte Antwort: Collogue kann nicht anzeigen, wer einen Link geöffnet hat. Wenn Link und separat geteiltes Passwort die falsche Person erreicht haben könnten, behandeln Sie das Zugangsmittel als möglicherweise offengelegt: Widerrufen oder ersetzen Sie es, prüfen Sie den Empfänger über einen anderen Kanal und erstellen Sie eine neue Nachricht, statt denselben Wert erneut zu senden.
Collogue hat kein serverseitiges Leseereignis und kann daher weder beweisen, dass eine Person eine Nachricht geöffnet hat, noch einen Betrachter identifizieren. Ein fehlerhafter Link oder eine fehlgeschlagene Entschlüsselung kann stattdessen durch eine unvollständige oder veränderte URL oder das falsche Passwort verursacht werden.
Wenn die Nachricht ein Passwort, einen API-Schlüssel, ein Sitzungstoken, einen Wiederherstellungscode oder einen Zugangslink enthielt, behandeln Sie den Wert als offengelegt.
- Widerrufen oder ersetzen Sie ihn.
- Senden Sie denselben Wert nicht erneut.
- Bestätigen Sie den vorgesehenen Empfänger.
- Erstellen Sie nach Möglichkeit einen neuen temporären Wert.
- Senden Sie einen neuen Collogue-Link.
- Untersuchen Sie den Zustellweg, wenn das Problem erneut auftritt.
Ein dauerhaftes Zugangsmittel führt zu einem größeren Vorfall als ein temporäres. Deshalb gehören Zustellung und Zugangsmitteldesign zusammen.
Nicht jede private Nachricht enthält ein Zugangsmittel.
Wenn der Inhalt eine unkritische Notiz war, kann der Absender nach der Bestätigung des Empfängers eine neue Nachricht erstellen. Das Risiko hängt von der Sensibilität des Textes und den Folgen einer Offenlegung ab.
Der Dienst kann diese Entscheidung nicht für den Benutzer treffen. Er kann den Zustand klar erklären.
Nur wenn der Dienst absichtlich relevante Belege sammelt und zuverlässig auswerten kann – und selbst dann kann die Zuordnung unsicher bleiben.
- der vorgesehene Empfänger;
- ein Unternehmens-Proxy;
- ein Mobilfunkanbieter;
- ein VPN;
- ein E-Mail-Scanner;
- ein gemeinsam genutztes Netzwerk;
- ein Angreifer.
Ein User-Agent kann Software beschreiben, nicht eine Person.
Vermitteln Sie nicht den Eindruck, dass ein Prüfprotokoll einen Menschen identifiziert, wenn das System keine authentifizierte Empfängeridentität umfasst und die Aussage nicht belegt ist.
Bei wiederkehrenden Zustellfehlern innerhalb einer Organisation testen Sie nicht sensible Links über denselben E-Mail-Weg und prüfen Sie die Richtlinien des Sicherheits-Gateways mit dem Administrator. Verwenden Sie keine echten Zugangsdaten als Testnachricht.
- Bewerten Sie die Folgen einer Offenlegung.
- Bestätigen Sie, ob der Empfänger den Link geöffnet hat.
- Wiederholen Sie nicht mehr Kontext als nötig.
- Nutzen Sie bei regulierten Informationen das dafür vorgesehene Verfahren für Sicherheitsvorfälle.
Nein. Der aktuelle Client sammelt keine Leseereignisse, und eine URL-Anfrage identifiziert keine Person.
Wenn sich ein Passwort-Link nicht entschlüsseln lässt, prüfen Sie URL und Passwort. Ersetzen Sie das Zugangsmittel, sobald beide Teile offengelegt worden sein könnten.
Collogue kann einen Scanner nicht zuverlässig von einer Person unterscheiden. Veröffentlichen Sie nur Diagnosemöglichkeiten, die der Code tatsächlich bietet.