Vorschauen von Bestätigungsbenachrichtigungen: Aktionsdetails schützen

Vorschauen von Bestätigungsbenachrichtigungen verdienen dieselbe Bedrohungsmodellierung wie die angekündigte Aktion. Eine Anfrage zum Bereitstellen von Code, zum Aufrufen einer Kunden-API oder zum Ausführen eines Remote-Befehls kann sensible Fakten offenlegen, bevor jemand auf „Bestätigen“ drückt. Wenn diese Information auf einem gesperrten Smartphone, einem gemeinsam genutzten Desktop, einem Display im Konferenzraum oder einem gespiegelten Wearable erscheint, hat das Bestätigungssystem bereits einen Teil der Aktion preisgegeben.

Der häufigste Fehler besteht darin, die Benachrichtigung als harmlose technische Zwischenschicht zu behandeln. Sie ist ein Ausgabekanal mit eigener Zielgruppe, eigener Aufbewahrung und eigenen Zugriffskontrollen. Entwirf sie als bewusst begrenzte Aufforderung, eine geschützte Entscheidungsansicht zu öffnen. Behandle sie nicht als Miniaturversion des Bestätigungsbildschirms.

Ein gesperrter Bildschirm ist eine Offenlegungsgrenze

Ein gesperrter Bildschirm kann für Kollegen, Familienmitglieder, Besucher, Kamerasysteme und alle sichtbar sein, die an einem Schreibtisch vorbeigehen. Der Besitzer kann in der Nähe sein, doch Nähe ist keine Authentifizierung. Dieser Unterschied wirkt offensichtlich, bis eine Bestätigungsmeldung einen Produktions-Hostnamen, einen Kundennamen, eine Incident-Bezeichnung oder die erste Zeile eines Shell-Befehls anzeigt.

Viele Teams stufen eine Benachrichtigung als wenig sensibel ein, weil sie keinen geheimen Wert enthält. Dieser Test greift viel zu kurz. Ein Endpunkt wie billing-prod.internal, ein Pfad wie /customers/28471/refund oder eine Meldung wie Rotate compromised access token kann Systeme, Beziehungen und den Betriebszustand verraten. Ein Angreifer, der solche Bruchstücke sammelt, braucht kein Bearer-Token, um sich einen Vorteil zu verschaffen.

Überlege, was ein Beobachter aus den einzelnen Feldern ableiten kann:

• Ein Ziel kann einen Kunden, eine Region, ein Produkt oder einen Produktionsdienst erkennen lassen.
• Eine Operation kann verraten, dass ein Konto geändert wird, eine Rückerstattung aussteht oder ein Vorfall läuft.
• Eine Agent-Identität kann zeigen, an welchem Repository oder welcher Aufgabe ein Entwickler arbeitet.
• Ein Begründungsfeld enthält oft kopierten Tickettext, Benutzereingaben oder Incident-Notizen.
• Ein Ergebnis kann Daten offenlegen, die die Aktion abgerufen hat, bevor der Nutzer eine Entscheidung getroffen hat.

Der Sperrbildschirm ist nur die erste Offenlegungsgrenze. Betriebssysteme können denselben Text nach dem Entsperren in einem Benachrichtigungszentrum anzeigen. Eine Desktop-Benachrichtigung kann im Verlauf bleiben, nachdem jemand einen gemeinsam genutzten Arbeitsplatz verlassen hat. Eine Smartwatch kann sie spiegeln. Bildschirmaufzeichnungen, Fernwartungssoftware und Videokonferenzen können sie erfassen. Die Vorschau muss all diese Situationen überstehen.

Die Dokumentation zur Platform Security von Apple beschreibt den Sperrbildschirm als geschützten Gerätezustand und stellt die Benutzerauthentifizierung in den Mittelpunkt des Zugriffs auf geschützte Daten. Dieses Modell macht Benachrichtigungstext nicht automatisch zu geschützten Daten. Apps müssen selbst entscheiden, was sie an den Benachrichtigungsdienst senden und was sie vor der Authentifizierung darstellen. Behandle die Datenschutzeinstellung des Betriebssystems als eine Schutzschicht, nicht als Erlaubnis, sensible Inhalte in die Nachricht zu schreiben.

Die Meldung sollte Aufmerksamkeit verlangen, nicht die Anfrage offenlegen

Eine sichere Vorschau teilt mit, dass eine Aktion geprüft werden muss, und liefert genug Dringlichkeit, um sie zu priorisieren. Sie gibt die Aktion nicht wieder. Genau diese Unterscheidung verwischen Teams häufig: Benachrichtigungskontext ist kein Bestätigungskontext.

Der Bestätigungskontext muss dem Operator eine informierte Entscheidung ermöglichen. Dafür können das genaue Ziel, die Operation, der Berechtigungsumfang, der Agent-Prozess, die Argumente, die erwartete Wirkung und der Ablaufzeitpunkt erforderlich sein. Der Benachrichtigungskontext soll die richtige Person zurück in diese geschützte Ansicht führen. Dafür braucht er deutlich weniger.

Eine nützliche Vorschau auf dem Sperrbildschirm könnte bei einer gewöhnlichen Aktion so aussehen:

Action approval needed
A development agent requests access to a protected service.
Expires in 4 minutes. Open the app to review.

Der Text vermittelt Dringlichkeit und den groben Umfang. Er sagt nicht, ob der Dienst Gehaltsabrechnungen, Quellcode, Zahlungen oder einen internen Vorfall verarbeitet. Er verrät weder URL, Methode, Befehl, Branch, Abfrage noch die Identität eines Kunden.

Vergleiche das mit einer Meldung, wie sie in echten Systemen auftauchen kann:

Approve POST https://payments.example.internal/v1/refunds/28471
Agent requests bearer token for customer refund. Reason: duplicate charge.

Auch die zweite Meldung druckt das Bearer-Token nie aus und legt trotzdem viel zu viel offen. Sie identifiziert einen sensiblen Dienst, eine Aktion, ein kundenbezogenes Objekt und ein finanzielles Ereignis. Jeder, der die Vorschau lesen kann, erfährt etwas, wozu er nicht berechtigt war.

Verwende für Vorschautexte ein kleines Vokabular. „Approval needed“, „access request waiting“ und „review required“ reichen oft aus. Ergänze eine grobe Risikoklasse, wenn sie beeinflusst, wie schnell jemand reagieren sollte: „external action“, „production access“ oder „sensitive read“. Die Bezeichnung darf nicht so genau sein, dass sie den Zweck zunichtemacht. „Production database export“ ist keine grobe Kategorie.

Der authentifizierte Bildschirm sollte das Gegenteil tun. Er muss die Anfrage so konkret machen, dass der Operator sie sicher ablehnen oder bewusst bestätigen kann. Details dort aus Datenschutzgründen zu verbergen, führt zu blinder Bestätigung und damit zu einem anderen Fehler.

Die Redigierung muss erfolgen, bevor die Benachrichtigung die App verlässt

Ein Benachrichtigungs-Payload braucht ein eigenes Schema. Erstelle es nicht, indem du im letzten Moment einen vollständigen Bestätigungsdatensatz kürzt, und verlasse dich nicht auf eine Liste von Zeichenketten-Ersetzungen. Dieser Abkürzung folgen Teams, weil der vollständige Datensatz bereits existiert und seine Darstellung einfach wirkt. Sie scheitert, sobald ein neues Feld hinzukommt, eine URL in einen Untertitel wandert oder eine Begründung kopierte sensible Daten enthält.

Erstelle aus einer Aktionsanfrage zwei ausdrückliche Projektionen. Eine versorgt die authentifizierte Bestätigungsansicht, die andere die Vorschau. Das Vorschau-Modell sollte nicht einmal Felder für rohe URLs, Header, Befehlsargumente, Antwortausschnitte, Geheimnisnamen oder freie Begründungen besitzen.

Dieses Pseudocode-Beispiel zeigt die Struktur:

type ApprovalRecord {
  requestId
  agentAuthority
  destination
  operation
  arguments
  credentialReference
  userReason
  expiry
  riskClass
}

type NotificationPreview {
  requestId
  title
  body
  expiryText
  riskClass
}

function makePreview(record):
  return NotificationPreview(
    requestId = opaqueId(record.requestId),
    title = "Action approval needed",
    body = previewBody(record.riskClass),
    expiryText = formatExpiry(record.expiry),
    riskClass = record.riskClass
  )

Die entscheidende Eigenschaft ist nicht die Formulierung, sondern die Einbahnstruktur der Daten. NotificationPreview kann nicht versehentlich destination enthalten, weil das Feld fehlt. Ein Reviewer kann diese Grenze prüfen. Ein Test kann jedes neue Vorschaufeld ablehnen, das eine unbegrenzte Zeichenkette enthält.

Leite keinen rohen Begründungstext durch einen Bereinigungsfilter und betrachte die Sache damit als erledigt. Begründungen enthalten regelmäßig Vorgangstitel, eingefügte Befehle, E-Mail-Adressen, Kontokennungen und interne Namen. Redigiermuster übersehen Formate, die niemand vorhergesehen hat. Ein fester Text aus einer Aufzählung ist sicherer als ein bereinigter, vom Nutzer kontrollierter Satz.

Auch undurchsichtige IDs brauchen Sorgfalt. Eine Bestätigungs-ID wie APR-10482 mag harmlos wirken, aber eine vorhersehbare Nummer gibt einem Beobachter einen Datensatz, den er mit einem sichtbaren Ticket oder einem späteren Gespräch verknüpfen kann. Verwende eine ID ohne geschäftliche Bedeutung, die nicht als Berechtigungstoken dienen kann. Noch besser: Lass sie aus der Vorschau weg, sofern Support-Abläufe sie nicht wirklich benötigen.

Bewahre die vollständige Anfrage im verschlüsselten Anwendungsspeicher oder in einem anderen authentifizierten Datensatz auf, nicht im Text der Benachrichtigung. Ein Benachrichtigungssystem kann Text länger aufbewahren, als die Meldung selbst sichtbar bleibt. Deine Aufbewahrungsregeln greifen nicht, wenn ein anderes Subsystem eine Kopie hält.

Datenschutzeinstellungen des Geräts helfen, dürfen das Design aber nicht tragen

Betriebssysteme erlauben meist, Vorschauen von Benachrichtigungen bei gesperrtem Gerät auszublenden. Diese Einstellung ist nützlich. Ein Produkt für Aktionsbestätigungen darf jedoch nicht voraussetzen, dass sie aktiviert, verstanden und auf allen Geräten einer Person einheitlich angewendet wird.

Manche Menschen benötigen sichtbare Vorschauen, um Meldungen zu sortieren. Manche Organisationen verwalten die Einstellungen. Manche Geräte haben keinen Sperrcode. Manche Nutzer lesen Warnungen auf einem Desktop, dessen Bildschirm bereits entsperrt ist, während ein Kollege hinter ihnen steht. Eine App, die sensible Texte sendet und sagt, „Nutzer können Vorschauen ausschalten“, überlässt eine Sicherheitsentscheidung dem unzuverlässigsten Moment der Einrichtung.

Plane für drei Bedingungen:

1. Das Betriebssystem zeigt die vollständige Benachrichtigung auf einem gesperrten Display.
2. Das Betriebssystem verbirgt den Text, zeigt aber Titel oder App-Namen.
3. Das Display ist entsperrt, doch andere Personen können es sehen.

Die erste Bedingung bestimmt deinen Payload. Wenn der Text dort sicher ist, lassen sich die beiden anderen leichter beurteilen. Ist er dort unsicher, macht eine Benutzereinstellung den Fehler nur unregelmäßig sichtbar.

Leite aus dem Gerätezustand nicht zu viel ab. Eine Anwendung kann wissen, dass ihr eigenes Fenster entsperrt ist, aber oft nicht, wer die Benachrichtigung betrachtet. Selbst ein zuverlässiges Signal für den gesperrten Zustand berücksichtigt weder Projektoren noch externe Monitore oder Bildschirmfreigaben. Die sichere Vorschau sollte auch nach der Authentifizierung sicher bleiben, weil die Bedingungen der physischen Betrachtung außerhalb der Kontrolle der App liegen.

Eine Ausnahme ist erwähnenswert: Eine lokale, authentifizierte Benachrichtigung innerhalb eines Anwendungsfensters darf dieselben Details wie die Bestätigungsansicht anzeigen, weil die App den Zugriff auf dieses Fenster bereits kontrolliert. Das ist keine Systembenachrichtigung. Verwechsle einen geschützten Posteingang in der App nicht mit einem Banner auf dem Sperrbildschirm, nur weil beide das Wort „Benachrichtigung“ verwenden.

Bestätigungsschaltflächen in Benachrichtigungen schwächen die Entscheidungsgrenze

Eine „Bestätigen“-Schaltfläche in einer Benachrichtigung wirkt effizient. Sie ist aber auch eine attraktive Abkürzung für versehentliche Bestätigungen, erzwungene Entscheidungen und verlorenen Kontext. Jemand sieht ein abgeschnittenes Banner, tippt auf eine vertraute Schaltfläche und autorisiert eine Aktion, ohne ihr tatsächliches Ziel oder ihre Wirkung zu prüfen.

Die Benachrichtigung sollte nur Aktionen anbieten, die die Entscheidungsgrenze erhalten. „Zur Prüfung öffnen“ ist sicher, weil der Operator damit zur authentifizierten App gelangt. „Schließen“ ist sicher, wenn das Schließen die Anfrage weder ablehnt noch bestätigt oder stillschweigend verlängert. Eine Schaltfläche mit der Aufschrift „Bestätigen“ ist bei wichtigen Aktionen nicht sicher, selbst wenn das Betriebssystem vor ihrer Ausführung das Entsperren des Geräts verlangt.

Authentifizierung und informierte Zustimmung sind zwei verschiedene Prüfungen. Die Geräteauthentifizierung bestätigt, dass jemand mit Zugriff auf das entsperrte Gerät die Schaltfläche gedrückt hat. Sie bestätigt nicht, dass diese Person die vollständige Anfrage gesehen oder ausreichend Zeit hatte, sie zu beurteilen. Der Bestätigungsbildschirm sollte die Entscheidung an die Anfragedetails binden, zeigen, ob sich seit dem Erscheinen der Meldung etwas geändert hat, und für eine sensible Aktion eine neue Bestätigung verlangen.

Das ist bei Agent-Anfragen besonders wichtig. Ein Agent kann viele Aktionen erzeugen, die aus der Entfernung ähnlich aussehen. Ein Benachrichtigungstitel wie „SSH access request“ unterscheidet keine schreibgeschützte Statusprüfung von einem destruktiven Befehl. Die geschützte Ansicht muss die konkrete Absicht zeigen, bevor der Operator die Aktion freigibt.

Sallyports Autorisierungsablauf hält die eigentliche Aktionsentscheidung in der authentifizierten App, statt eine Betriebssystembenachrichtigung in eine Fernbedienung für den Agent-Zugriff zu verwandeln. Diese Trennung ist weniger spektakulär als eine Bestätigung mit nur einem Tippen und bewährt sich besser, wenn Anfragen weitreichende Folgen haben.

Biete auch keine Option „Diese Entscheidung merken“ in der Benachrichtigung an. Dauerhafte Berechtigungsänderungen verdienen eine eigene, ausdrückliche Oberfläche, einen klaren Umfang und eine Möglichkeit zur Prüfung oder zum Widerruf. Ein schläfriger Fingertipp auf dem Sperrbildschirm ist kein guter Ort, um dauerhafte Befugnisse zu schaffen.

Risikoklassen sollten Folgen beschreiben, ohne Ressourcen zu benennen

Eine vage Meldung bringt Menschen dazu, jede Benachrichtigung zu öffnen. Eine zu detaillierte Meldung verrät das geschützte Objekt. Risikoklassen lösen einen Teil dieses Konflikts, wenn sie die Kategorie der Folgen statt der Ressource beschreiben.

Verwende Kategorien, die sich daran orientieren, was eine Aktion bewirken kann. Eine Aktion kann beispielsweise geschützte Informationen lesen, einen internen Dienst ändern, eine externe Anfrage senden oder einen Vorgang ausführen, der sich nur schwer rückgängig machen lässt. Diese Kategorien geben dem Reviewer einen Grund, die Arbeit zu unterbrechen, ohne Datenbank, Kunden oder Hostnamen offenzulegen.

Vermeide Bezeichnungen, die Zugriffssensibilität und betriebliche Dringlichkeit vermischen. „Hohe Priorität“ sagt wenig über die Wirkung einer Bestätigung aus. „Production write“ vermittelt mehr, kann aber ebenfalls verraten, dass ein Produktionssystem beteiligt ist. Ob diese Formulierung sicher ist, hängt von der Umgebung ab. Eine Person, die allein auf einem privaten Gerät arbeitet, mag sie akzeptieren. An einem gemeinsam genutzten Support-Schalter sollte eine allgemeinere Bezeichnung verwendet werden.

Definiere das Vokabular schriftlich und ordne es der Aktion zu, bevor die Benachrichtigung erstellt wird. Wenn Entwickler den Titel frei formulieren können, rettet dich auch das sorgfältigste Schema nicht. Eine einfache Regel für Reviews lautet: Jede Zeichenkette, die aus einem Agent, einem Nutzer, einer URL, einem Befehl, einem Request-Body oder einer entfernten Antwort stammt, ist in Vorschauen verboten.

Eine praktische Zuordnung sieht so aus:

Die Tabelle ist eine Richtlinie für Autoren und Entwickler, kein Versprechen, dass jede Aktion sauber in vier Kategorien passt. Wenn eine Aktion gemischte Auswirkungen hat, wähle die ernstere Kategorie. Eine Benachrichtigung, die etwas zu früh Aufmerksamkeit verlangt, kostet einen Moment. Eine Benachrichtigung, die eine externe Übertragung unter „Zugriffsanfrage“ verbirgt, führt zu einer falschen Entscheidung.

Benachrichtigungsverlauf und gespiegelte Geräte brauchen eine eigene Prüfung

Teams testen häufig das erste Banner und hören dann auf. Der vollständige Offenlegungsweg umfasst gespeicherte Benachrichtigungen, Zusammenfassungen, Spiegelungen auf Wearables, Desktop-Weiterleitungen und alle verwalteten Geräte, die dieselben Kontoalarme empfangen.

Beginne mit einer echten Anfrage, die absichtlich erkennbare Testdaten enthält: einen erfundenen Kundennamen, einen erfundenen internen Host, eine erfundene E-Mail-Adresse und ein erfundenes Befehlsargument. Verwende für Datenschutztests keine echten Produktionswerte. Löse die Anfrage aus und prüfe anschließend jede Stelle, an der der Text auftauchen kann.

Verwende vor einer Veröffentlichung diese Testfolge:

1. Sperre das primäre Gerät und löse die Bestätigungsanfrage aus.
2. Prüfe Banner, Sperrbildschirmliste und Benachrichtigungszentrum nach dem Entsperren.
3. Aktiviere konfigurierte Benachrichtigungsweiterleitungen oder Spiegelungen auf Wearables und prüfe deren Verlauf.
4. Erfasse den Bildschirm über die von deinem Team verwendeten Wege für Fernwartung und Bildschirmfreigabe.
5. Lass die Anfrage ablaufen oder löse sie auf und prüfe anschließend, ob veralteter Text sichtbar bleibt.

Notiere an jeder Stelle den exakt dargestellten Titel und Text. Ein erfolgreicher Test lautet nicht „Die Vorschau war auf meinem Smartphone verborgen“. Er lautet: „Keines der Testmerkmale erschien außerhalb der authentifizierten App.“ So werden auch Lokalisierungsfehler erkannt. Eine sichere englische Vorlage kann unsicher werden, wenn der übersetzte Text länger ist und eine interne Kennung in eine sichtbare Zeile verschiebt.

Achte besonders auf gruppierte Benachrichtigungen. Ein System kann die jüngste Meldung, eine Anzahl oder eine aus mehreren Warnungen zusammengesetzte Zusammenfassung anzeigen. Wenn jede einzelne Vorschau sicher ist, muss auch die Gruppe sicher sein. Verwendet dein Gruppierungscode einen Aktionsnamen wie „drei Rückerstattungsanfragen“, hat er sensible Details über einen Nebenweg wieder eingeführt.

Die Aufbewahrung von Benachrichtigungen verändert auch die Reaktion auf Vorfälle. Der Widerruf einer Agent-Sitzung verhindert künftige Anfragen, kann aber keinen Text zurückholen, der bereits in den Benachrichtigungsverlauf eines Nutzers oder auf ein gespiegeltes Gerät kopiert wurde. Deshalb gehört die Minimierung der Vorschau vor die Autorisierungs- und Audit-Prüfung, nicht erst nach einem Vorfall.

Audit-Datensätze brauchen Details, Vorschauen Zurückhaltung

Sicherheitsteams machen Vorschauen manchmal vage, weil auch ihre Audit-Datensätze vage sind. Sie befürchten, dass detaillierte Datensätze Informationen preisgeben. Damit werden zwei getrennte Systeme mit unterschiedlichen Zielgruppen vermischt.

Ein Audit-Datensatz sollte vollständig genug sein, um die Autorisierungsentscheidung zu rekonstruieren: welcher Agent-Prozess die Aktion gestartet hat, unter welcher Berechtigung er lief, Ziel, Operation, Zeitpunkt, Entscheidung und Ergebnis. Sensible Werte müssen weiterhin sorgfältig behandelt werden, doch Ermittler brauchen sachliche Details. Eine Vorschau sollte davon nichts enthalten, solange die Person sich nicht in der App authentifiziert hat.

Der Unterschied ist bei einem Fehler wichtig. Stell dir vor, ein Agent fordert einen Remote-Befehl an. Die Meldung lautet „Approval needed“, und der Reviewer öffnet die App. Die geschützte Ansicht zeigt Befehl, Host, Sitzungsidentität und Ablaufzeit. Der Reviewer lehnt ab. Später untersucht ein Engineer den Grund und benötigt den zugehörigen Datensatz. Die Audit-Spur kann diese Frage beantworten, ohne dass die ursprüngliche Benachrichtigung den Befehl über jede Display-Oberfläche tragen musste.

Sallyport trennt Sitzungs- und Aktivitätsjournale von der Benachrichtigungsverarbeitung. Beide Journale werden aus einem verschlüsselten, hashverketteten Audit-Log abgeleitet. So kann ein Operator Aktionen prüfen und die Audit-Kette offline verifizieren, ohne Vorschauen auf dem Sperrbildschirm als Ersatz für Belege zu verwenden.

Platziere keine Audit-Hashes, Datensatzauszüge oder rohen Korrelations-IDs in der Benachrichtigung. Sie sind in der geschützten Oberfläche und in Untersuchungswerkzeugen nützlich. Auf einer öffentlichen Oberfläche erzeugen sie Kennungen, die Beobachter sammeln und miteinander verknüpfen können.

Eine Benachrichtigung sollte ablaufen, wenn die zugrunde liegende Entscheidung abläuft. Der geschützte Datensatz sollte diesen Zeitpunkt klar angeben. Öffnet jemand eine alte Meldung, muss die App den aktuellen Status der Anfrage abrufen. Lass niemals zu, dass ein zwischengespeicherter Benachrichtigungstext jemanden davon überzeugt, dieselbe Anfrage zu bestätigen, die vor fünf Minuten existierte.

Schreibe Vorschriften für Vorschauen als Tests und versuche, sie zu brechen

Eine Richtlinie wie „Sensible Inhalte vermeiden“ scheitert unter Zeitdruck. Verwandle sie in Assertions, die mit dem Benachrichtigungs-Builder ausgeführt werden, und in Testfälle, die Reviewer lesen können.

Der nützlichste Test ist eine Sperrliste von Datenquellen, nicht eine fragile Sperrliste von Wörtern. Lehne jedes Vorschaufeld ab, das aus URL, Host, Befehlstext, Header, Body, Zugangsdatenbezeichnung, freier Begründung, entfernter Antwort, E-Mail-Adresse oder Kontokennung stammt. Erlaube anschließend nur eine kleine Auswahl fester Vorlagen und begrenzter Kategorien.

Ein kompakter Testfall könnte so aussehen:

record.destination = "https://claims-prod.internal/cases/FAKE-784"
record.arguments = "--account [email protected] --export"
record.userReason = "Customer Northstar reports a disputed claim"
record.riskClass = EXTERNAL_ACTION

preview = makePreview(record)

assert preview.title == "Action approval needed"
assert preview.body == "An external action requires review."
assert preview doesNotContain "claims"
assert preview doesNotContain "FAKE-784"
assert preview doesNotContain "fake.person"
assert preview doesNotContain "Northstar"

Die positiven Assertions sind genauso wichtig wie die negativen. Sie verhindern, dass eine spätere Änderung eine sichere feste Meldung durch einen vagen leeren Hinweis ersetzt, den Nutzer irgendwann einfach wegwischen. Teste auch Ablauftexte, Lokalisierung, gruppierte Meldungen und die Darstellung für Barrierefreiheit. Screenreader können Inhalte vorlesen, die durch visuelles Kürzen verborgen bleiben. Deshalb muss die Ausgabe für Barrierefreiheit dasselbe eingeschränkte Vorschau-Modell verwenden.

Lass schließlich jemanden, der das Feature nicht geschrieben hat, die Vorschauen lesen und nach betrieblichen Hinweisen suchen. Diese Person erkennt, was der Autor nicht mehr wahrnimmt: einen Projektnamen, eine vertraute Umgebungsbezeichnung oder den internen Spitznamen eines Dienstes. Kann ein informierter Außenstehender die geschützte Aktion ableiten, enthält die Benachrichtigung zu viele Informationen.

Setze als Standard die am wenigsten spezifische Meldung ein, die noch eine rechtzeitige menschliche Reaktion auslöst. Lege die für eine echte Bestätigung erforderlichen Belege hinter die Authentifizierung und führe jede Abkürzung zurück zu diesen Belegen. Dieses Design kostet möglicherweise einen Tipp. Es verhindert, dass jeder gesperrte Bildschirm zu einem stillen Offenlegungskanal wird.