Zusammenfassung

  • Ein individueller Internet-Draft vom 27. Oktober behandelt nachgeahmte Support- und Personalvermittleridentitäten in Nachrichten von Jobbörsen, Marktplätzen und Bildungsdiensten. Er formuliert technische Erwägungen und kein neues Protokoll.
  • Der Entwurf nennt zwei Fallen: Exakte Gleichheit von Unicode-Skeletten kann ähnlich aussehende Namen übersehen; untersuchte Validatoren sollen Hostnamen mit erhaltenen unsichtbaren Formatzeichen akzeptiert haben. Absender, Linkziel und Absicht der Nachricht gehören gemeinsam geprüft.

Ein Nutzer liest eine Nachricht in der Jobbörse. Oben steht „Support“. Diese Beschriftung ist zunächst eine Eingabe eines Kontos, noch keine Berechtigung, für die Plattform zu sprechen. Der Entwurf zur Erkennung ähnlicher Absender setzt bei der einzelnen Nachricht an: Anzeigename, Adresse, Host des Links und geforderte Handlung. Zwischen zwei Konten derselben App sitzt kein Firmen-Mailgateway des Empfängers. Der Betreiber des Postfachs kennt die eigenen Support-Konten und kann die Namensbehauptung dort prüfen, wo Leser sie sehen.

Der Text nennt drei Signalgruppen. Absender- und Link-Domänen werden mit geschützten Namen verglichen. Der Anzeigename und die Adresse können eine Marke auf fremdem Gebiet tragen. Die Nachricht kann Zugangsdaten verlangen, aus dem Dienst herausführen oder sich auf dessen Autorität berufen. Diese Merkmale werden zusammen aussagekräftig. Eine echte Hochschul-Karriereberatung verwendet ebenfalls Wörter aus der Arbeitsvermittlung; eine Sperre allein wegen Namensähnlichkeit trifft sie mit.

Die erste technische Falle steckt in einer vermeintlich sauberen Unicode-Abkürzung. UTS #39 definiert ein Skelett für den Vergleich verwechselbarer Zeichen und Regeln für gemischte Schriften. Der Entwurf beschreibt Fälle, in denen nur exakte Skelettgleichheit einen optisch ähnlichen Namen verpasst: das kleine griechische Kappa und das kleine kyrillische Te werden auf lateinische Vorbilder außerhalb von ASCII abgebildet. Der Vergleich mit einem ASCII-Markennamen bleibt dann ungleich. Der Vorschlag ergänzt die Skelettprüfung um Schrifterkennung und eine begrenzte Editierdistanz.

Die zweite Falle ist buchstäblich unsichtbar. Laut Entwurf akzeptierten mehrere von seinem Autor untersuchte Eingabevalidatoren Hostnamen mit U+00AD, U+200B, U+2060 oder U+FEFF und gaben sie samt Formatzeichen zurück. RFC 5890 beschreibt den IDNA-Rahmen, RFC 5892 die Regeln für Codepunkte und Unicode UTS #46 die Kompatibilitätsverarbeitung. Der Entwurf verlangt die IDNA2008- oder UTS-46-Verarbeitung vor dem Abgleich mit einer Erlaubnisliste und die Zurückweisung von Labels mit Format- oder standardmäßig ignorierbaren Zeichen. Ein „gültig“ für einen Wert, der das Zeichen noch trägt, verleiht der nächsten Komponente eine trügerische Grundlage.

Über die amtliche Rolle entscheidet der Dienst selbst. Er bestimmt, welche Namen geschützt sind, welche Konten sie tragen und ob ein Treffer eine Warnung oder eine Sperre auslöst. Ein Sprachmodell darf beim Kontext helfen, soll den unzuverlässigen Nachrichtentext aber als solchen behandeln und deterministische Absenderbelege nicht überstimmen. Datatracker führt das Papier als individuellen Entwurf mit I-D Exists und angestrebtem Informational-Status.

Im veröffentlichten Entwurf fehlen Namen und Versionen der untersuchten Validatoren sowie eine reproduzierbare Tabelle von Eingaben und Ergebnissen. Sie würde zeigen, welche aktuellen Bibliotheken von dem beschriebenen Fehler betroffen sind.