Was regelbasierte Schwärzung in einem Ticket oder Chatprotokoll trifft – und was trotzdem stehen bleibt

Einfügen ist keine Kopie. Es sind mehrere Kopien, die Sie nicht zurückholen.

Viele behandeln Schwärzung als Höflichkeit: die volle Nummer gegen Sterne tauschen, damit die Nachricht professionell wirkt. Der Schaden beginnt nach dem Einfügen. Das Ticketsystem speichert den Text. Der Messenger speichert die Nachricht. Die Fehlerüberwachung greift den Stack. Session-Replay zeichnet das Eingabefeld auf. Eine Outsource-Queue exportiert noch eine Datei. Ein paar Zeichen auf Ihrem Bildschirm zu ändern, ändert keine schon geschriebenen Kopien. Ein späteres „Ticket bereinigen“ ändert nur die aktuelle Zeile. Suchhistorie, Mailbenachrichtigung und nachgelagerte Auswertungen halten den Ausgangstext oft weiter.

Das OWASP Logging Cheat Sheet schreibt das als technische Vorgabe, nicht als Stilhinweis. Es listet Daten, die vor dem Log gelöscht, maskiert, bereinigt, gehasht oder verschlüsselt gehören: sensible personenbezogene Daten und bestimmte Kennzeichen (Gesundheitsdaten, staatliche Identifikatoren), Authentifizierungspasswörter, Zugriffstoken, kryptografische Schlüssel und andere Hauptschlüssel, Bankkonten und Karteninhaberdaten. Intern spielen Tickets und Gruppenchats oft die Rolle eines informellen Logs: leicht durchsuchbar, lockerer berechtigt als Produktion, länger aufbewahrt. Kundenworte ungekürzt einzufügen heißt, genau die Aufzeichnung zu erzeugen, die OWASP nicht stehen lassen will.

HTTPS schützt nur den Hop vor Mithören. Es wischt keinen Klartext, den Sie dem nächsten System schon übergeben haben. Die vorige Notiz hat dasselbe für Query-Strings gesagt: Sie landen in Verlauf, Referer und Zugriffs-Logs. Eine Nummer im Absatz ist dieselbe Klasse von Preisgabe. Der Träger ist ein Satz statt einer URL. Vor dem Versand lautet die Frage nicht „ist dieses Ticketsystem sicher“, sondern „steht in diesem Absatz ein Feld, das diesen Tab nicht verlassen darf“.

Regeln treffen eine Form und eine Prüfziffer. Sie lesen den Satz nicht.

Regelbasierte Schwärzung ist ein enger Auftrag. Ein regulärer Ausdruck findet einen Kandidaten. Eine Prüffunktion wirft Treffer weg, die einen öffentlichen Test nicht bestehen. Eine Prioritätenliste löst Überlappungen. Der Scanner weiß nicht, dass „Max Mustermann“ eine Person ist oder „bitte an der Pforte in der Musterstraße abgeben“ eine Adresse. Er weiß, ob elf Ziffern wie eine Festland-Handyform aussehen, ob achtzehn Ziffern eine Bürger-ID-Prüfung bestehen, ob sechzehn Ziffern den Luhn-Test bestehen, den Karten nutzen.

Das ist ein anderer Weg als „das Ticket an ein Modell schicken und die PII umschreiben“. Ein ausgehender Modellscan übergibt den Ausgangstext an eine weitere verarbeitende Stelle. Ein Gateway-Schwärzer tut dasselbe. Ein Regelscan kann in diesem Tab bleiben: die Eingabe verlässt den Browser nicht, das Ergebnis ist eine maskierte Kopie. Der Preis ist die Abdeckung. Ausweise außerhalb der Liste, selbst gebaute Token-Präfixe und durch Leerzeichen gebrochene Ziffern fehlen.

Eine Prüfziffer senkt Fehlalarme. Sie beweist nicht „diese Person existiert“. Eine 18-stellige chinesische Bürger-ID berechnet das letzte Zeichen nach GB 11643-1999 / ISO 7064 MOD 11-2: die ersten 17 Ziffern mit den Gewichten 7, 9, 10, 5, 8, 4, 2, 1, 6, 3, 7, 9, 10, 5, 8, 4, 2 multiplizieren; Summe modulo 11; Rest auf die Tabelle 10X98765432 abbilden. Rest 2 ergibt X, das für 10 steht. Ein Bestehen heißt „diese Zeichenkette sieht wohlgeformt aus“. Es heißt nicht, dass ein Meldeamt diese Person führt. Karten nutzen den Luhn-Algorithmus aus ISO/IEC 7812: von rechts jede zweite Ziffer verdoppeln, bei mehr als 9 dann 9 abziehen, und die Nummer nur annehmen, wenn die Summe durch 10 teilbar ist. Die meisten 16-stelligen Ketten, die Sie ins Blaue tippen, fallen durch Luhn. Eine Regel sollte sie nicht als Karte behandeln.

Sechs Feldtypen: was eine Regel benennen kann, und wie die Maske aussieht

Stabil benennbar sind Felder mit öffentlichem Format plus zweiter Prüfung. Die Tabelle folgt der Reihenfolge, in der diese Felder im Versandtext meist auftauchen. Die Maskenformen setzen „intelligente“ Maskierung voraus: etwas vom Anfang oder Ende behalten, die Mitte durch Sterne ersetzen. Wechseln Sie zur vollständigen Maske, wenn auch die restlichen Ziffern verschwinden sollen.

Telefonregeln müssen sowohl einen durchgehenden 11-Ziffern-Lauf als auch Nummern mit Leerzeichen, Klammern oder Bindestrichen annehmen. Ein Festland-Handy, das mit 1[3-9] beginnt und 11 Ziffern hat, ist eine öffentliche Nummernform, keine interne Betreibertabelle. Internationale Nummern greift die übliche E.164-Optik: ein führendes + und danach 7 bis 15 Ziffern. Ketten, die zu kurz sind oder in einem längeren Ziffernlauf sitzen, sollten wegfallen, sonst werden Bestellnummern und Sendungsnummern zu Telefonen.

Für deutsche Alltagstexte ist das die erste ehrliche Lücke. Eine nationale Schreibweise wie 030 12345678 ohne Pluszeichen fällt oft weder in die Festland-11-Form noch in die nordamerikanische Trennung. Dieselbe Nummer als +49 30 12345678 trifft die internationale Regel. Vor dem Versand lohnt die E.164-Form – nicht weil sie „deutscher“ wäre, sondern weil die Regel sie überhaupt sieht. Eine Steuer-Identifikationsnummer ist elf Ziffern ohne Buchstaben. Sie sitzt nicht in der 18-stelligen Bürger-ID, nicht in der SSN-Form und nicht in der NINO-Form. Die generische Ausweisregel verlangt Buchstaben und Ziffern. Elf reine Ziffern bleiben deshalb oft stehen – oder werden, wenn sie zufällig wie ein Handy aussehen, falsch als Telefon markiert.

Bei Ausweisen braucht die 18-stellige chinesische Nummer zusätzlich einen Regionscode ungleich null, ein Geburtsjahr im 20. oder 21. Jahrhundert und einen echten Kalendertag. Eine US Social Security Number in der Form AAA-GG-SSSS hat offizielle Ausschlüsse: Bereich 000, 666 oder führende 9; Gruppe 00; Seriennummer 0000. Eine britische National Insurance Number sind zwei Buchstaben, sechs Ziffern und ein Schluss A–D; Präfixe wie BG und GB sind ausgeschlossen. Diese Tests erhöhen die Sicherheit, dass die Kette wie ein Ausweis aussieht. Sie beweisen nicht, dass die Person existiert. Eine deutsche Personalausweisnummer kann als alphanumerisches 6-bis-12-Muster zufällig treffen. Sie ist kein erstklassiges deutsches Format auf der Liste.

Bei Karten trennt die Zahlungsbranche „wie viele Stellen dürfen auf dem Bildschirm stehen“ von „wie kürzen Sie eine gespeicherte PAN“. Der PCI Security Standards Council bekräftigt in der Notiz zu 8-stelligen BINs eine gängige Anzeigeobergrenze, die Marken weiter akzeptieren: erste sechs und letzte vier. Eine Rolle, die zum Rückruf nur die letzten vier braucht, sollte nur die letzten vier sehen. Ein Ticket weiterzugeben ist kein Acquiring. Die letzten vier als Voreinstellung ist die sicherere Versandgewohnheit. Das ist keine PCI-Zertifizierungsbehauptung. Es sagt nur: alle 16 Stellen in den Chat zu kleben überschreitet schon die übliche Anzeigegrenze. Eine IBAN der Form DE89 3704 0044 0532 0130 00 ist kein eigener Typ. Luhn auf 13–19 Ziffern trifft sie nicht. Im deutschen Ticket ist genau diese Kette oft die, die stehen bleibt.

Eine E-Mail-Maske, die nur den lokalen Teil verdeckt und die volle Domain lässt, verrät der Gegenseite weiter, in welcher Firma die Person arbeitet. Schlüsselregeln hängen an öffentlichen Präfixen: klassische GitHub-Personal-Access-Tokens nutzen ghp_ plus 36 Zeichen; fein granulare Tokens nutzen github_pat_. AWS-IAM-Zugriffsschlüssel-IDs beginnen oft mit AKIA plus 16 Zeichen. Stripe-Live-Geheimschlüssel nutzen sk_live_. Diese Präfixe existieren, damit SDKs und Scanner sie erkennen – deshalb kann eine Regel sie treffen. Ein selbst gebautes Token ohne stabiles Präfix oder eine Kette „g h p Unterstrich…“ ist für den Scanner gewöhnlicher Text.

IPs greift der Scanner über gepunktete Dezimalbereiche (jedes Oktett 0–255), damit eine Versionskette wie 1.2.3 seltener trifft. Demos und Canaries gehören in Dokumentationsbereiche, nicht in Produktionsadressen. RFC 5737 reserviert 192.0.2.0/24, 198.51.100.0/24 und 203.0.113.0/24 und sagt, sie dürfen nicht im öffentlichen Routing erscheinen. E-Mail-Demos nutzen example.com, aus den reservierten Namen in RFC 2606, nicht eine echte Firma.

Ausweis und Karte können denselben Ziffernlauf beanspruchen

Eine 18-stellige Bürger-ID besteht aus Ziffern (das letzte Zeichen kann X sein). Füttert jemand eine rein numerische ID in die Kartenregel, besteht Luhn gelegentlich. Sitzen beide Regeln auf einem Absatz, brauchen Sie eine Priorität, sonst wird dieselbe Spanne zweimal maskiert – oder in die falsche Form.

Eine stabile Reihenfolge ist: Ausweis vor Schlüsseln, Schlüssel vor Telefon, Telefon vor E-Mail, E-Mail vor Karte, Karte vor IP. Die Gründe sind konkret. Zuerst der Ausweis, damit eine 18-stellige Identitätsnummer nicht als Karte verschluckt wird. Ein Schlüsselpräfix ist unverwechselbarer als „Ziffern, die wie ein Telefon aussehen“. Ziffern in einer E-Mail sollen die Telefonregel nicht noch einmal zerschneiden. IP ist das breiteste Netz, läuft deshalb zuletzt und frisst seltener Versionsketten oder gepunktete Zahlen in einer Bestellnummer. Bei Überlappung bleibt der Treffer mit höherer Priorität oder der längere.

Schalten Sie „Ausweisnummer“ aus und lassen „Bankkarte“ an, sollte das Gegenteil passieren: dieser Ziffernlauf darf als Karte gelten. Das ist beim Debuggen einer Regel erwartet. Es ist nicht die Standard-Versandpolitik. Standard sind alle sechs Typen an, danach ein menschlicher Durchgang für Namen und Adressen, die Regeln nicht anfassen.

Sterne sind keine Anonymisierung, und sie sind keine fertige Pseudonymisierung

Die DSGVO zieht eine harte Linie, die Maskierung nicht überschreitet. Erwägungsgrund 26 sagt, die Verordnung gilt nicht für anonyme Informationen: Informationen, die sich nicht auf eine identifizierte oder identifizierbare natürliche Person beziehen, oder personenbezogene Daten, die so anonymisiert wurden, dass die Person nicht mehr identifizierbar ist. Er sagt auch, Sie müssen alle Mittel berücksichtigen, die der Verantwortliche oder ein Dritter nach allgemeinem Ermessen wahrscheinlich nutzt, um jemanden zu identifizieren. Art. 4 Nr. 5 definiert Pseudonymisierung als Verarbeitung personenbezogener Daten so, dass sie ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer bestimmten Person zugeordnet werden können, und diese zusätzlichen Informationen müssen getrennt unter technischen und organisatorischen Maßnahmen gehalten werden. Der BfDI verweist auf die EDSA-Klarstellung zur Pseudonymisierung: sie senkt Risiken, hebt den Personenbezug aber nicht auf. Pseudonymisierte Daten bleiben personenbezogene Daten. Erwägungsgrund 26 sagt das. Sterne in der Mitte einer Nummer stehen im Gesetzestext nicht als abgeschlossene Kontrolle.

Intelligente Maskierung lässt absichtlich einen prüfbaren Schwanz: die letzten vier einer Telefonnummer, die letzten vier einer Karte, die E-Mail-Domain, das Schlüsselpräfix. Steht im Ticket außerdem ein Name, eine Straße oder eine interne Kundennummer, reichen diese vier Ziffern oft, um die Person von „identifizierbar“ zurück auf „identifiziert“ zu schieben. Das ist höchstens ein Schritt Richtung Pseudonymisierung. Es ist keine Anonymisierung. Eine vollständige Maske ersetzt den Treffer durch dieselbe Zahl Sterne und nimmt eine Verknüpfung weg. Länge, Position und der umgebende Satz bleiben. Der Satz kann weiter lauten „bitte den Kontoinhaber zurückrufen“ oder „Ausweiskopie liegt im Anhang“.

Deshalb darf „wir haben die Regeln laufen lassen“ nicht als „dieser Absatz darf in eine öffentliche Wissensdatenbank“ oder „das erfüllt eine Zertifizierung“ geschrieben werden. Die Werkzeugseite behauptet keine DSGVO- oder anderen Compliance-Siegel. Der genaue Satz lautet: bekannte Formen wurden durch eine Maske ersetzt; unbekannte Formen wurden nicht angefasst; ob eine bestimmte Person noch identifizierbar ist, beurteilen Sie am Kontext.

Was die Regeln verfehlen, ist oft der Satz, der den Vorfall auslöst

Eine Fehltrefferliste nützt mehr als eine Trefferliste. Erstens: direkte Identifikatoren ohne stabile Ziffernform – Vornamen, Straßen, Arbeitgeber, klinische Notizen, die Schule eines Kindes. Es gibt keine öffentliche „nationale Namenstabelle“, die ein Regex abfragen könnte, und Cloud-Namenserkennung verwechselt weiter gewöhnliche Wörter. Zweitens: umgeschriebene Geheimnisse: „null drei null eins zwei drei vier fünf sechs sieben acht“, Vollbreite-Ziffern, ein Einschub oder ein Zero-Width-Zeichen in der Mitte, ein Screenshot statt Text. Ein Regex sieht die aktuelle Codepunktfolge. Er hört nicht die Nummer, die jemand diktiert hat.

Drittens: Geheimnisse ohne öffentliches Präfix. Eine Datenbank-URL, ein dreiteiliges JWT, ein selbst gebautes token=, ein Sitzungscookie aus Chat oder interner App – keines davon sitzt auf der kurzen Liste ghp_ / AKIA. Viertens: Anhänge und Rich Text: eine Word-Kopfzeile, eine versteckte Tabellenspalte, eine Nummer in der Mail-Signatur, eine Ebene in einem PDF. Regeln scannen nur den Klartext, den Sie in das Feld eingefügt haben. Fünftens: semantische Geheimnisse: ein unveröffentlichter Vertragsbetrag, eine Schwachstellenbeschreibung, eine Beschwerde in den Worten der Kundin oder des Kunden. Das sind keine PII-Formen. Sie weiterzuleiten schadet trotzdem.

Im deutschsprachigen Alltag kommen drei weitere Lücken dazu, die oben schon angelegt sind und hier als Checkliste stehen: die Steuer-Identifikationsnummer (elf Ziffern, kein Buchstabe), die IBAN und oft die nationale Rufnummer ohne +. Wer nur „die Schwärzung ist gelaufen“ in die Übergabe schreibt, hat genau diese Ketten oft unberührt gelassen. Eine Personalausweisnummer kann treffen oder nicht; verlassen Sie sich nicht darauf.

Es gibt auch den „Treffer, aber den falschen“. Bestellnummern, Paketkennzeichen und Tischnebenstellen sehen manchmal wie Telefone aus. Eine Dokumentversion 10.20.30.40 sieht wie IPv4 aus. Prüfziffern und „keine Ziffer links und rechts“ filtern einen Teil. Sie filtern nicht alles. Deshalb sollte ein Ergebnisbereich Treffertypen und Anzahlen nennen, nicht nur einen mit Sternen versehenen Absatz zurückgeben. Sie prüfen, ob der Typ stimmt, nicht ob genug Sterne da sind.

Sofort prüfen: ein Canary ins Feld, dann Network durchsuchen

„Lokale Schwärzung, nichts hochgeladen“ kann sich als Slogan nicht selbst beweisen. Vier Dinge, die Sie in einem Sitz sehen: welche Typen genannt wurden, ob die Maskenform stimmt, ob ein Satz, den Sie stehen lassen wollten, noch da ist, und ob der Ausgangstext als Geschäftsdaten rausging.

Bauen Sie einen Canary ohne echte Identität. Für eine deutsche Rufnummer nehmen Sie die E.164-Form, etwa +49 30 12345678 – eine erfundene Vorwahl-Kombination, nicht Ihre eigene Nummer. Für eine Festland-Handyform ist 13800138000 eine veröffentlichte Dummyform aus Werbung und Doku. E-Mail: canary@example.com. IP: 203.0.113.10. Karte: 4111111111111111. Schlüssel: ein wegwerfbares Token mit öffentlichem Präfix, etwa ghp_ plus 36 Zeichen, die Sie erfinden und danach als verbrannt behandeln. Nutzen Sie niemandes echte Ausweisnummer. Müssen Sie eine Prüfziffer üben, wählen Sie ein unmögliches Geburtsdatum (1. Januar 1900), rechnen das letzte Zeichen und kennzeichnen den Absatz als „fiktiv“.

Betten Sie den Canary in ein gewöhnliches Ticket: „Nutzer canary@example.com kann sich nicht anmelden. Rückruf +49 30 12345678. Quell-IP 203.0.113.10. Testkarte 4111111111111111. Token ghp_…. Lieferung an Musterstraße 12, 10115 Berlin.“ Nach dem Lauf sollten E-Mail, Telefon, IP, Karte und Token in den Trefferzählungen erscheinen und wie in der Tabelle zu Masken werden. „Musterstraße 12, 10115 Berlin“ sollte unverändert überleben. Das ist die Regelgrenze, kein Fehler. Wird die Straße ebenfalls maskiert, sitzen Sie nicht auf einem reinen Regelsatz, oder die Regeln wurden erweitert – dann Fehlalarme getrennt prüfen.

Öffnen Sie danach DevTools Network, aktivieren Sie Preserve log und suchen Sie nach eindeutigen Canary-Ketten: +49 30 12345678, canary@example.com oder das volle Fake-Token. Sie sollten weder in einer XHR- oder Fetch-Anfragezeile, Query oder Body erscheinen noch in Analytics-Query oder -Body. Ein statischer Skriptname mit „privacy“ oder „redact“ ist erwartet. Ausgangstext, der als Geschäftsfeld rausgeht, ist ein Fehlschlag.

1. Schreiben Sie ein Ticket aus einer fiktiven E.164-Nummer, einer example.com-Mail, einer RFC-5737-Adresse, einer Test-PAN und einem präfigierten Fake-Token. Lassen Sie absichtlich eine deutsche Straße im Klartext stehen.
2. Prüfen Sie nach dem Lauf die Treffertypen: die fünf Zahlen- oder Kontenfelder sollten genannt sein; die Straße sollte im Ergebnis stehen.
3. Durchsuchen Sie Network nach dem Canary-Ausgangstext. Jede Geschäfts-Anfrage mit Treffer heißt: die Eingabe hat diesen Tab verlassen.

Der Beweis ist eng. In diesem einen Lauf wurden bekannte Formen zu Masken, der Adresssatz blieb stehen, und der Ausgangstext hat diesen Tab nicht als beobachtetes HTTP-Feld verlassen. Das beweist nicht, dass eine Erweiterung das Feld nie gelesen hat. Das beweist nicht, dass ein echtes Ticket nicht fehlt. Nach einem Browserwechsel oder dem Umschalten einer Regel den Canary erneut laufen lassen.

Die Grenze auf einer Schwärzungsseite üben, die ohne Konto öffnet

Wenn Sie eine Seite wollen, die Typ-Schalter und Trefferzählungen offen hinlegt, beginnen Sie bei MakePwd mit der Datenschwärzung unter UTM entfernen. Sie öffnet ohne Konto und ohne Anmeldung. Scan und Maskierung laufen in diesem Tab. Laut Produktbeschreibung geht der Ausgangstext nicht als Anfrage raus und wird nicht in Analytics geschrieben. Die sechs prüfbaren Typen sind die oben: Telefon, Ausweisnummer, Bankkarte, E-Mail, API Key und IP. Intelligente Maskierung ist die Voreinstellung; Sie können auf vollständige Maske wechseln. Ein Einfügen ist auf 512 KB begrenzt. Die Seite schreibt die Grenzen klar: Sie erkennt nicht jedes Ausweisformat, sie ersetzt keine Compliance-Prüfung, und wichtiger Versand braucht weiter einen menschlichen Durchgang.

Üben Sie nur mit Canaries. Schauen Sie nach einem Lauf drei Stellen gleichzeitig an: die Treffertyp-Zählungen, ob die Straße im Ergebnis stehen blieb, und ob Network den Ausgangstext enthält. Zählungen beantworten „hat es die richtigen Typen genannt“. Die Straße beantwortet „wo hört die Regel auf“. Network beantwortet „wurde hochgeladen“. Bestehen alle drei, können Sie sagen: Ich habe diese Typen maskiert, ich weiß, dass die Adresse noch da ist, und ich habe den Canary auf der Leitung gesucht.

Tracking-Parameter an einer URL sind ein eigener Auftrag. Klebt das Ticket außerdem eine volle URL mit utm_source oder fbclid, zuerst die Query nach Schlüssel entfernen, danach die Nummern im Text. Die Schritte stehen in Welche Tracking-Daten Sie mitschicken, wenn Sie einen UTM-Link in den Chat einfügen. Bleibt nach der Schwärzung ein Geheimnis, das unversehrt ankommen muss, einmalig per Einmal-Link schicken und den Schlüssel im URL-#-Fragment lassen. Eine ganze Datei lokal in Datei verschlüsseln zu .lock / .enc machen (eine Datei, höchstens 5 GB) und dann über Laufwerk oder Mail schicken. Keiner dieser Schritte verlangt ein Konto.

Häufige Fragen

Sind die Daten nach den Sternchen noch personenbezogen?

Meist ja. Die DSGVO nimmt in Erwägungsgrund 26 nur anonyme Informationen aus dem Anwendungsbereich: Daten, die sich nicht auf eine identifizierte oder identifizierbare Person beziehen. Art. 4 Nr. 5 definiert Pseudonymisierung als Verarbeitung, die ohne zusätzlich und getrennt gehaltene Informationen keine Zuordnung mehr erlaubt. Eine Telefonnummer mit den letzten vier Ziffern oder eine E-Mail mit voller Domain plus Ticketkontext lässt sich oft wieder zusammenführen. Regelbasierte Maskierung nähert sich höchstens der Pseudonymisierung. Sie ist keine Anonymisierung.

Kann regelbasierte Schwärzung die menschliche Prüfung ersetzen?

Nein. Regeln treffen Formen und Prüfziffern, nicht den Sinn. Namen, Straßen, diktierte Ziffern, Screenshots und umgeschriebene Token rutschen durch. Wichtigen Versand lesen Sie selbst nach. Die Werkzeugseite behauptet keine DSGVO-Zertifizierung.

Lädt die Schwärzung den Ausgangstext hoch?

Laut Produktbeschreibung laufen Scan und Maskierung in diesem Tab. Der Ausgangstext geht nicht als Anfragekörper raus und wird nicht in Analytics geschrieben. Mit einem fiktiven Canary können Sie in Network genau diesen Lauf prüfen. Das beweist nicht, dass eine Erweiterung das Feld nie gelesen hat.

Wie sende ich ein Geheimnis, das die Schwärzung nicht fertig macht?

Verstreute Telefon- und Ausweisnummern mit Regeln maskieren. Ein ganzes Passwort, unveröffentlichtes Material oder einen Schlüssel, der unversehrt ankommen muss, einmalig per Einmal-Link schicken und den Schlüssel hinter dem URL-#-Fragment lassen. Eine ganze Datei lokal in Datei verschlüsseln zu .lock oder .enc machen und dann per Mail oder Laufwerk schicken.

Drei Dinge vor dem nächsten Versand

Erstens: Einfügen ist Kopieren. Ticket, Chat, Überwachung und Export behalten je eine Zeile. Die aktuelle Seite zu ändern holt keinen Text zurück, der schon weg ist. Zweitens: Regeln treffen nur formatierte, prüfbare Felder. Namen, Straßen, diktierte Ziffern, Steuer-ID, IBAN und selbst gebaute Token sind ein menschlicher Durchgang, und restliche Schwänze plus Kontext können eine Person weiter identifizieren. Drittens: drei Stellen prüfen – Treffertypen, den Satz, den Sie stehen lassen wollten, und eine Network-Suche nach dem Canary.

Wenn die nächste Frage lautet, ob die Query einer vollen URL mitreisen soll, lesen Sie Welche Tracking-Daten Sie mitschicken, wenn Sie einen UTM-Link in den Chat einfügen. Wenn Sie prüfen wollen, dass Klartext diesen Tab nicht als Geschäftsdaten verlassen hat, lesen Sie Im Browser verschlüsseln: so prüfen Sie, dass Klartext das Gerät nicht verlassen hat. Diese Notiz zieht nur eine Linie, die Sie in eine Schlussfolgerung schreiben können: was regelbasierte Schwärzung an einem Tickettext tun kann – und was Sie nicht behaupten dürfen, dass sie getan hat.