Kommunikationsprotokoll

Ein Kommunikationsprotokoll ist ein Regelsatz, der den Ablauf einer Kommunikation regelt. Einem technikbasierten Informationsaustausch liegt in jedem Fall ein definiertes Protokoll zugrunde, wohingegen direkter zwischenmenschlicher Kommunikation oft kein bewusstes Protokoll zugrunde liegt, weshalb sie auch so fehleranfällig ist.

Zwischenmenschlich

Der Begriff des Protokolls im zwischenmenschlichen Bereich tritt zumeist als sogenanntes Diplomatisches Protokoll auf, also als eine Regelung, nach der z.B. die Treffen von Staatsoberhäuptern ablaufen. Daneben gibt es eine Vielzahl expliziter und impliziter Protokolle, die teils kulturell bedingt sind und demzufolge von Ort zu Ort und von Zeit zu Zeit variieren und andere, die sich aus der Funktionsweise des Gehirns ergeben haben. Kulturell bedingt ist z.B., dass es üblich ist, dass Mitarbeiter, die sich am Tagesbeginn in Deutschland treffen, sich gegenseitig mit "Guten Morgen" begrüßen, dass man die Übergabe einer Gabe mit einem "Bitte" begleitet und die Annahme mit einem "Danke". Kognitiv bedingt ist es, dass man jemanden anschaut, wenn man ihm zuhört.

Technisch

Die Vielfalt der technischen Protokolle ist so zahlreich wie die Anzahl der unterschiedlichen technischen Geräte. Die Nodes des Internets verständigen sich z.B. mittels TCP/IP, während Peripheriegeräte sich mit ihrem Host, also mit dem Rechner an den sie angestöpselt sind, heutzutage meist per USB-Protokoll verständigen und per Funk angeschlossene Geräte z.B. Bluetooth oder W-LAN als Protokoll für die Luftschnittstelle verwenden.

Der Benutzer wird nach Möglichkeit von der Handhabung dieser rein technischen Protokolle fern gehalten, um die Bedienung zu vereinfachen und Fehlbedienungen zu minimieren. So muß ein Bluetooth-Kopfhörer meist nur einmal eingeschaltet werden und als neues Gerät im Bluetooth-Menü eines Smartphones durch einfaches Antippen bestätigt werden, um sich in Folge jedes mal selbsttätig zu Verbinden, sobald Smartphone und Kopfhörer betriebsbereit und in Reichweite zueinander (10 m) sind.

E-Mail

Eine Besonderheit stellen die E-Mail-Protokolle dar, weil hier der Mensch noch sehr direkt in den Kommunikationsprozess eingebunden ist.

Adressierung

Notwendigerweise muss eine Mail einen Empfänger haben. Man kann zwar gegen eine Wand reden, aber keine E-Mail irgendwohin oder nirgendwohin schicken. Das erlaubt das Simple Mail Transfer Protocol (SMTP) nicht, dass seit 1982 im Einsatz ist und somit bedeutend älter als das HTTP ist, dass dem zugrunde liegt, was wir heutzutage WWW oder Internet nennen. In so fern man auf eine empfangene Mail antwortet, ergibt sich der Empfänger automatisch aus der Absenderadresse der Ursprungsmail. Der E-Mail-Client übernimmt die Einsetzung der Adresse in dem Fall automatisch. Schreibt man eine Initiativ-Mail, muß man die korrekte Adresse des Empfängers wissen und selber eintragen. Hier muss der Mensch sich also direkt mit dem Protokoll auseinandersetzen und wird zur potenziellen Fehlerquelle. Man muss wissen, dass eine korrekte E-Mail-Adresse so aufgebaut ist: <Mailbox-Name>@<Server-Name>. Das Abtippen solcher Adressen ist die häufigste Fehlerquelle. Dabei sollten Syntaxfehler, wie das Einfügen von Leerzeichen vom E-Mail-Client abgefangen werden, was aber Thunderbird nicht tut, weshalb derartige Fehler meistens vom E-Mail-Server abgefangen werden, wodurch der Benutzer am Versenden an derartig falsche Adressen gehindert wird. Dahingegen kann keine Technik den Benutzer daran hindern oder darauf aufmerksam machen, wenn er Mails an falsche aber existierende Adressen verschickt. Und es ist unvorhersagbar, was der falsche Empfänger dann mit der Mail machen wird. Er könnte sie z.B. kommentarlos löschen, woraufhin der Absender keine Möglichkeit hat, den Fehler zu bemerken. Mails an nicht existierende Adressen werden normalerweise zeitnah zurückgeschickt.

Offener Versand

Mails werden wie Postkarten versendet. Den Inhalt kann jede Stelle mitlesen, über die der Datenstrom verläuft. Man kann die Inhalte zwar verschlüsseln, nicht aber die Adressen von Absender und Empfänger. Daher ist es ganz leicht, durch das Mitlesen des Internetverkehrs nicht nur E-Mail-Adressen zu sammeln, sondern auch festzustellen, wer mit wem kommuniziert. Man kann zwar mittels SMTPS (SMTP-secure) verhindern, dass beim Anmelden an den Server das Passwort mitgelesen werden kann, aber die Adressen lassen sich so nicht schützen, weil der Transport zwischen den Mail-Servern offen ist.

Transportprobleme

Der für den Empfang zuständige Mail-Server kann ausfallen. Dass führt zu einer Anzahl von erfolglosen Auslieferungsversuchen und schlussendlich zu einer um Stunden oder Tage verzögerten Fehlermeldung an den Absender. Ebenso kann die Mailbox des Empfängers "voll" sein. auch das führt zu einer - allerdings zeitnahen - Fehlermeldung. Sollte der Empfänger seine Mails nicht abrufen, z.B. weil er tot ist, ergibt das keine Fehlermeldung. Auch Fehlfunktionen in den Eingangsfiltern des Empfängers oder falsch-positive SPAM-Erkennung führt zu keiner Fehlermeldung, aber i.d.R. zum Verlust der Mail. Falsch-positive SPAM-Erkennungen auf dem Transportweg, also die Eintragung des sendenden Mail-Servers auf eine Blocklist führt zu einer Meldung über diesen schwer behebbaren Fehler.

Message Disposition Notification

Message Disposition Notification kurz MDN ist ein High-Level-Protokoll, das mit dem Benutzern direkt interagiert. Es fängt damit an, dass der Absender eine Empfangsbestätigung vom Empfänger anfordert. Dazu fügt der Mail-Client folgende Zeile in den E-Mail-Header ein:

• Disposition-Notification-To: <E-Mail-Adresse>

Daraufhin würde ein korrekt konfigurierter Mail-Client beim Empfang solcher Mail den Benutzer fragen, ob er bereit ist, den Empfang der Mail zu quittieren. Wenn ja, wird automatisch eine Empfangsbestätigung erstellt, die ihrerseits wie eine Mail auf dem selben Weg zurück geschickt wird, auf dem die bestätigte Mail hereingekommen ist und dann dem Absender der Mail angezeigt wird. Diese Bestätigungsmail wird aber nicht, wie normale Mails, auch in den GESENDET-Ordner des bestätigenden Empfängers kopiert. Sie "kostet" den Empfänger also maximal einen Klick.

Dadurch kann der Absender sehen, dass seine Mail von jemandem empfangen wurde. Sie ist also nicht im SPAM gelandet, gelöscht worden, noch auf dem Weg oder sonst wie untergegangen. Da man Mail-Clients auch so konfigurieren kann, dass sie jede MDN automatisch beantworten (oder nie), ist es nicht zulässig, aus einer Empfangsbestätigung zu schließen, dass die Mail auch gelesen wurde. Leider unterstützen nicht alle Mail-Clients das Anfordern oder Bestätigen von MDNs. Thunderbird unterstützt fallweise oder generelle Anforderung von MDNs und fallweise oder automatische Bestätigung sowie generelle Ignoranz von MDNs.

Positive Delivery Status Notifications (DSN) werden noch weniger unterstützt und dienen dazu, lediglich die Auslieferung an den letzten Mail-Server zu bestätigen, nicht das Abholen durch den Mail-Client. Vor- und Nachteil liegen darin, dass der individuelle Empfänger keinen Einfluss auf die Handhabung der DSN hat.

Der Nutzen von Protokollen

In einem rein technischen Kontext machen Protokolle die Datenübertragung überhaupt erst möglich. Teile der Protokolle, die als verzichtbar angesehen werden könnten, dienen dazu, die Sicherheit der Übertragung zu verbessern, also Übertragungsstörungen zu erkennen und möglichst zu kompensieren, so dass die übertragenen Daten vollständig und fehlerfrei übertragen werden, auch wenn die Übertragungsbedingungen mal nicht ideal sind.

Das gleiche gilt für zwischenmenschliche Protokolle. Redundanzen in der menschlichen Sprache ermöglichen das Aufdecken von Fehlern und gelegentlich auch die unmittelbare Kompensation. Z.B. ist in "Herbert ist heute gekommen. Er hat seine Schulden bezahlt." das Wort "er" eine Redundanz. "Herbert ist heute gekommen und hat seine Schulden bezahlt." wäre genau so verständlich. "Herbert ist heute gekommen, hat seine Schulden bezahlt." wäre auch verständlich, aber grammatikalisch falsch. "Herbert ist heute gekommen. <unverständlich> hat seine Schulden bezahlt." wäre ein Übertragungsfehler, der beim Empfänger kompensiert werden kann. "<unverständlich> ist heute gekommen. <unverständlich> hat seine Schulden bezahlt." ist ein mehrfacher Übertragungsfehler, der nicht mehr beim Empfänger kompensiert werden kann. Hier wird eine Rückfrage (die ein Protokollelement ist) notwendig.

Wenn der Gesprächspartner wegschaut und mit seinen Blicken umherschweift, ist das ein impliziter Hinweis auf eine gestörte Übertragung und macht eine Rückfrage erforderlich. Unprofessionelle Rückfragen wie: "Hörst Du mir überhaupt zu?" können mit einem halbautomatischen "Ja, sicher." beantwortet werden und sind daher völlig wertlos. Offene Fragen wie: "An was denkst du gerade?", sind eher geeignet, die Situation zu klären und nicht nur festzustellen, ob das Letztgesagte überhaupt angekommen ist.

Shadow Banning Detection

Angesichts der rapide zunehmenden Nutzung von Shadow Banning zur Unterdrückung und Marginalisierung von Dissidenten, muß man bestehende Protokolle aktivieren und weitere Protokolle etablieren, um versteckte Zensur mindestens zu detektieren und möglichst auch zu kompensieren oder zu umgehen. Der blinde Glaube, dass eine Mail einfach deshalb ihren Empfänger erreicht hat, weil man keine Fehlermeldung bekommen hat, ist gefährlich. In Zeiten der Hybriden Kriegsführung ist die Denkungsart "Es hat funktioniert, weil ich es gemacht habe." unzulässig. Alles muß ständig überprüft werden. Und bei Handlungen im virtuellen Raum ist sogar der Erfolgsmeldung, die eigentlich das Ergebnis einer Überprüfung sein sollte, zu misstrauen. Cyberwar bedeutet nicht nur, dass Übertragungen gestört werden. Es bedeutet auch, dass Protokollelemente gefälscht werden, um gestörte Übertragungen wie erfolgreiche Übertragungen erscheinen zu lassen. Ein Intelligentes Protokoll hat also immer eine Ebene mehr, als notwendig erscheint. Eine MDN anzufordern erscheint zwar nutzlos, wenn man sich klar macht, dass nicht nur der Transport der Mail unterdrückt werden kann, sondern auch eine falsche MDN verschickt werden könnte. Allerdings wäre eine "verschwundene" Mail lediglich ein unklares technisches Problem. Eine gefälschte MDN hingegen wäre der Beweis für gezielte Manipulation. Wenn ich z.B. weiß, dass mein Kommunikationspartner sonntags keine Mails ließt, weil er Sonntags immer Medien-Fasten-Tag hat, ich aber sonntags eine MDN von ihm bekomme, ist die Manipulation schon aufgeflogen. Eine effektive Manipulation des Protokolls erfordert also derart intime Kenntnisse der beteiligten Personen, dass eine automatisierte Durchführung nicht möglich, sondern personeller Einsatz erforderlich ist. Das widerspricht aber den Grundsätzen des Shadow Banning, das darauf aufbaut, das der Algorithmus kostengünstig gegen den Menschen arbeitet. Anders herum bedeutet die Nicht-Nutzung der technischen Protokolle, sich den Angriffen durch feindliche Algorithmen wehrlos auszusetzen. In jeder vitalen Beziehung sollte also mindestens das Protokollelement Lebenszeichen regelmäßig genutzt werden, um Beziehungsstörungen möglichst frühzeitig zu detektieren.