Ein Kunde beschwert sich über eine kaputte Firewall. Die würde abstürzen und müsse immer wieder rebootet werden. Als Verkäufer sollen wir das Gerät tauschen. Aus dieser eigentlich trivialen Aufgabe wurde eine beinahe unendliche Geschichte.

Fehlerbild

Seit einigen Monaten kann der Kunde beinahe jeden Morgen nicht arbeiten. Manchmal ist es Dienstag und Donnerstag. Man manchmal Montag, Mittwoch und Freitag. Manchmal auch ganz anders. Reboot der Firewall und es geht alles wieder. Logischerweise vermutet er einen Defekt an diesem Gerät und möchte einen Hardware-Tausch.

Andererseits macht der Hersteller Streß, wenn funktionierende Technik (unnötig) getauscht werden soll. Ich brauche also zumindest den Ansatz einer Fehlerursache.

Zunächst stellt sich heraus, daß die Reboots zu regelmäßig sind, um auf einen Hardwareschaden hinzudeuten. Jeden Tag um die gleiche Uhrzeit rebootet das Gerät. Auf Rückfrage sagt der Kunde, daß er die Faxen dicke hatte und per Zeitschaltuhr den Reset erzwingt.

Das Logging liegt nur auf dem Gerät selbst vor, so daß keine Aussagen über die Zeit vor dem Reboot getätigt werden können. Der Kunde aktiviert wieder seinen Syslog-Server, der das anfangs noch entgegen genommen hatte. Mangels Nutzeffekt hat man den Server vor einiger Zeit schon abgeschaltet.

Mit dem Syslog ergeben sich nun neue Einsichten:

  • Irgendwann zwischen drei und fünf Uhr fällt das Interface zum Internet-Modem aus und kommt kurz danach wieder.
  • Es taucht ein Gerät im Syslog auf, daß auch im diese Zeit herum in den Stromsparmodus geht und daraus wieder erwacht. Das Gerät hat leistungsstarke Motoren.
  • Die Firewall macht DHCP in Richtung Internet und erneuert alle 5h ihre 10h-Lease.
  • Die Reboots werden inzwischen manuell über die GUI der Firewall zwischen fünf und sechs Uhr ausgelöst.
  • Vor den Reboots meldet die Firewall, daß sie auf Pakete ins Internet keine Antwort bekommt.

Ursachenforschung

Der auffälligste Punkt ist, daß die Firewall nicht völlig kaputt sein kann, wenn man sie über die GUI rebootet.

Die nächste Korrelation ist das Gerät mit den Motoren. Wenn es an oder aus geht, könnte es Störungen im Stromnetz verursachen und so einen Fehler triggern. Auch könnten hochfrequente Störungen den Internetzugang unterbrechen. Schließlich gibt es da ja einen Interface Reset. Der Kunde sagt, das Gerät sei erst vor einigen Monaten angeschafft worden. Das korreliert auffällig mit dem Zeitpunkt ab dem Störungen auftraten. Der Kunde schließt diese Ursache aber kategorisch aus.

Also bleibt die Frage nach dem Internetzugang. Ein Anruf beim Provider (einem kleineren) bringt neue Erkenntnisse:

  • Vor einigen Monaten ist aufgefallen, daß die Anschlußtechnik beim Kunden nicht regelmäßig rebootet wird.
  • Man hat die Geräte in Richtung des Kunden in die Liste der automatischen Reboot aufgenommen.
  • Die Reboots werden sequentiell ausgeführt, eine Sortierung wird nicht erzwungen. Man möchte es zufällig halten.

Wahrscheinlich passiert folgendes:

  • Der Provider rebootet Teile seines Netzes.
  • Die Zuleitungstechnik vergißt dabei die ausgeteilte DHCP Lease, leitet also keine Daten mehr weiter.
  • Im Schnitt erneuert ein Endgerät 2,5h nach dem Reboot die Lease und es geht wieder.
  • Der Kunde beginnt regelmäßig um 5 Uhr mit Arbeiten.
  • Er bemerkt die fehlende Konnektivität und rebootet die Firewall.
  • Die Firewall holt sich direkt beim Booten per DHCP eine neue Adresse und alles geht wieder.

Man kann jetzt ausrechnen, wie hoch die Wahrscheinlichkeit ist, daß der Kunde um 5 Uhr noch keine Konnektivität hat.

Man kann auch die Firewall einmal so rebooten, daß die Lease immer zwischen 4 und 5 Uhr erneuert wird. Dank der 10h Lease ist dieser Rhythmus ja ziemlich stabil, er verschiebt sich täglich um 4h nach vorn. Das erklärt, warum der Kunde den Effekt nicht jeden Tag hat, sondern im Abstand von zwei bis drei Tagen beobachtet.

Man kann aber auch den Provider bitten, nicht zu rebooten.

Fazit

Internetprovider benutzen die Zeit zwischen Mitternacht und sechs Uhr morgens für beliebige, unangekündigte Arbeiten. In dieser Zeit gibt es keinerlei Funktionsgarantie für alles, was irgendwas mit Telekommunikation zu tun hat. Die gesamte IT-Branche benutzt die Nacht für Wartung, Umbauten und Updates.

Die Fachbegriffe der Informatik kennen es so:

337: Uptime Verfügbar an Werktagen zwischen 9:00 und 12:00, sowie 14:00 bis 17:00. (Microsoft SQL Server 2000 Administrator's Companion)

Denk ich an #Neuland in der Nacht, bin ich um den Schlaf gebracht.

nach Heinrich Heine

Die finale Umsetzung der DSGVO ist nun bald 100 Tage alt. Da läuft mir ein Interview mit dem Landesdatenschutzbeauftragen Herrn Hasse über den Weg, das mich ratlos zurück läßt. Es geht um einen Friseurbesuch.

TLZ: Mir hat ein Friseur neulich erklärt, er könne mir nicht mehr die Haare schneiden, wenn ich sein DSGVO-Formular nicht ausfüllen würde. Das ist doch Unsinn.
Hasse: Mir ist zumindest nicht klar, welche Daten der Friseur da gemeint haben sollte. Wenn es nur darum geht, jemandem die Haare zu schneiden, werden ja keine Daten erhoben. …

Cut-off_ponytail_(close_in)

By Vive la Rosière - Own work, CC BY-SA 3.0

Dies ist für jemanden, der Schulnoten als datenschutzrechtlich relevant ansieht, eine überraschende Aussage.

Was geschieht denn genau beim Friseur?

Man wartet und bekommt die Haare geschnitten. Dann bezahlt und geht man wieder.

Zurück bleiben die Haare.

Haare sind Körpermaterial und damit biometrische Daten.

Die DSGVO sagt dazu in Artikel 9 (Abs 1)

Die Verarbeitung personenbezogener Daten, aus denen die rassische und
ethnische Herkunft, politische Meinungen, religiöse oder
weltanschauliche Überzeugungen oder die Gewerkschaftszugehörigkeit
hervorgehen, sowie die Verarbeitung von genetischen Daten, biometrischen
Daten zur eindeutigen Identifizierung einer natürlichen Person,
Gesundheitsdaten oder Daten zum Sexualleben oder der sexuellen
Orientierung einer natürlichen Person ist untersagt.

Wie gefährlich Haare sind, mußte schon ein Fussballtrainer erfahren. Man kann also nicht behaupten, die Deutschen™ wüßten nichts davon.

Geht man noch einen Schritt weiter und schaut, was mit den Haaren im Friseursalon so passiert, wird es erst richtig spannend. Echthaar ist bei der Perückenherstellung begehrt. Dazu muß es sortiert aufbewahrt werden, was sich natürlich beim einfachen Trimm nicht lohnt.

Die DSGVO sagt dazu in Art 4 (Abs 6)

"Dateisystem" jede strukturierte Sammlung personenbezogener Daten, die
nach bestimmten Kriterien zugänglich sind, unabhängig davon, ob diese
Sammlung zentral, dezentral oder nach funktionalen oder geografischen
Gesichtspunkten geordnet geführt wird;

Eine sortierte Aufbewahrung von Haaren gehört hier zweifelsfrei dazu.

Und was macht der Friseur dann mit dem Langhaar? Verkaufen. Aber das will ich in Hinblick auf Art 46 DSGVO nicht weiter thematisieren.

Was nicht verkauft wird, wird weggeworfen (gelöscht). Auch dafür gibt es entsprechende Reglungen, wie Art 28 DSGVO, da der Entsorger als Auftragsdatenverarbeiter anzusehen ist.

Warum kreide ich das Herrn Hasse an? Weil er nach Art 35 Abs 2 DSGVO im Rahmen der notwendigen Datenschutzfolgeabschätzung als absegnende Stelle involviert ist.

Ein Kunde kann in seiner bei uns gehosteten Umgebung nicht auf ein Share zugreifen, wenn er es nur mit dem kurzen Namen anspricht. Die Fehlermeldung spricht von fehlenden Zugriffsrechten. Mit den langen Namen (angehängter Domain) geht es aber problemlos. Der Fehler ist eine Verkettung unglücklicher Umstände, beteiligte Parteien sind: Der Kunde, ein Kunde des Kunden, Microsoft, Apple und die IETF.

Problem

Greift man auf das Share mit vollem FQDN zu, gibt es keinerlei Probleme:

smb-full-name

Und so soll es auch mit einem kurzen Namen sein, denn der Kunde mag nicht immer seine eigene Domain hinschreiben. Insbesondere dann nicht, wenn der Kurzname sonst überall funktioniert.

Probiert man also im File-Exporer per UNC auf das Share zuzugreifen, klappt das allerdings nicht. Stattdessen poppt eine Fehlermeldung auf:

smb-permission-denied

Obwohl der Zugriff nicht funktioniert, ist das Share aber eingebunden, wie net use zeigt. Nur der Zugriff klappt nicht.

smb-net-use

Witzigerweise gibt es keinerlei Probleme, wenn man im Explorer den kurzen UNC-Pfad an einen Laufwerksbuchstaben bindet. Das ist bei Laufwerk U: im Bild schön zu sehen.

Die Fehlersuche dieses Phänomens dauerte Wochen:

  • Gruppenrichtlinien wurden geprüft
  • Changelogs der Updates und Hotfixes intensiv studiert
  • Mitschnitte der Netzwerkkommunikation zwischen den beteiligten Servern nebeneinander gelegt (evtl. Paketverlust im Netzwerk?)
  • Andere Shares wurden untersucht (keine Probleme dieser Art)
  • Das Share bekam andere Aliasnamen (und die Probleme waren weg)

Am Ende kristallisierte sich heraus, daß der Name des Shares das Problem darstellt. Schon die Änderung eines einzigen Zeichens lies den Effekt verschwinden. Was war also so speziell an dem Namen?

Nein, es heißt nicht com oder nul, jedoch gibt es Dateiendungen, die diese drei Buchstaben haben. Hat sich evtl. eine Anwendung für diese Zeichenfolge zu übereifrig registriert?

Lösung

Auf die richtige Spur kamen wir, als wir die Namensauflösung komplett mitschnitten. Denn die Maschine versucht beim Zugriff auf das Share DNS-Anfrage an die Nameserver eines Kunden (vom Kunden) zu schicken. WTF?

Wenn ein Windows auf ein reines UNC Share zugreift, benutzt es intern einen anderen (moderneren) Codepfad. Deswegen kommt es da auch prima mit IPv6 klar.

Dieser moderne Code benutzt auch aktuellere Standards, z.B. RFC 6762. Dort heißt es:

this document allows any computer user to elect to give their computers
link-local Multicast DNS host names of  the form: "single-dns-label.local."
In this respect the ".local." suffix is treated no differently from any other
search domain that might appear in the DNS search list.

Die IETF hat die proprietäre Entwicklung von Apple standardisiert und dabei Fallbacks aufs klassische DNS mit eingebaut, um auch bei Mischumgebungen noch funktionsfähig zu sein. Microsoft hat diesen Standard irgendwann implementiert.

Kurz und gut, der Client hat die Namensauflösung per Multicast DNS versucht und einen .local. Namen konstruiert. Den hat er angefragt und bekam eine unerwartete Antwort:

smb-conditional-forwarders

Unser Kunde hat mit seinen Kunden z.T. Active-Directory-Trusts zwecks Singe-Sign-One auf gemeinsame Ressourcen im Einsatz. Inzwischen wird lieber über ADFS gearbeitet, aber die alten Lösungen für Bestandskunden sind nach wie vor aktiv.

Für den AD-Trust müssen sich die Nameserver der beiden Domains gegenseitig erreichen können. Dies wird hier per Conditional Forwarder gemacht, um Eingriffe in den normalen Namensraum zu vermeiden.

In dem vorliegenden Fall, ist der Kurzname exakt der Name der AD-Domain beim Kunden (um .local erweitert). Deswegen glaubte der DNS-Server, eine Antwort zu haben, und schickte dem Client die entsprechende Delegation.

Infolge dessen fragt der Client dann selbst direkt bei den Nameservern des Kunden an, bekommt als eine Antwort eine IP Adresse, zu der er sein SMB-Paket schickt … Permission denied.

Fazit

Eigentlich müßte der Kunde des Kunden seine AD-Domain umbenennen. Ich habe den Namen extra unkenntlich gemacht, weil er durch seine Größe doch zu leicht zuzuordnen ist.

Bleibt als Alternative: Das Share wird umbenannt.

Merke:

  • Benutze niemals die Domain .local für eigene Zonen.
  • Benutze niemals einen Namen, der als .local-Domain irgendwie erreichbar sein könnte.

Nach dem Wechsel auf neuere Hardware (10G) und damit verbunden auch auf den aktuellsten Softwarestand von FreeBSD haben die NAT Kisten sporadisch massive Probleme. Ein glücklicher Zufall gestattete zuerst die Diagnose und dann die Lösung des Problems. CPU Last fällt von 90% (pro Prozeß) auf einstellige Werte.

Spikes

Immer wieder kommt es auf einer NAT Kiste zu akuten Performance-Problemen. Dabei bricht der maximal erreichbare Durchsatz pro TCP-Session auf unter 10Mbps zusammen. Oft ist der Gesamtdurchsatz des Systems auf knapp 200Mbps begrenzt, obwohl da drei mal 10G anstecken. (Für den Anschluß des vierten Interfaces fehlt aktuell ein Rack.)

Im CPU Graphen schaut das dann so aus.

stats-thread-peak

Um kurz nach 18 Uhr hatte die betreffende Maschine ein Lastproblem. Allerdings war es schon nach wenigen Minuten wieder weg.

In den meisten Fällen bisher waren die Lastspitzen noch deutlich kürzer, so daß man sie in diesem Graphen nicht mal richtig sieht.

Da allerdings das Problem nur sporadisch auftritt, nicht reproduzierbar ist, und die Beeinträchtigung der Kunden auch nicht lange genug anhält, um zu spezifischen Störungsmeldungen zu führen, war bisher eine Fehlersuche ergebnislos.

Glückliche Zufälle

Gestern erst hatte ich im Zusammenhang mit FreeBSD ein WTF-Erlebnis, das mit NAT zusammenhängt.

Und heute zeigte eine Maschine erstmals einen stabilen Fehlerzustand.

stats-thread-bummer

Wow, was für ein gewaltiger Vorfall! Endlich mal Zeit zum Debuggen.

Mit dem Hintergedanken des gestrigen Erlebnisses im Kopf fiel irgendwann in einem glücklichen Mitschnitt auf, daß es Pakete gibt, bei denen Quell- und Ziel-IP gleich sind. Noch dazu sind diese IPs auch die öffentlichen IPs des NAT.

Ganz offensichtlich kommt es vor, daß irgendein kruder Netzscanner Pakete schickt, die das NAT als gültig ansieht und nattet. Dabei entstehen Pakete, bei denen Quell- und Ziel-IP gleich sind. Und diese landen dann wieder beim NAT. Dabei entstehen Pakete, bei denen Quell- und Ziel-IP gleich sind. Und diese landen dann wieder beim NAT. Dabei entstehen Pakete, bei denen Quell- und Ziel-IP gleich sind. Und diese landen dann wieder beim NAT. Ähm, das Prinzip sollte klar sein.

Also kurz eine Firewallregel hinzugefügt, die Pakete von NAT-IPs an NAT-IPs verwirft.

Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:63647 178.19.233.4:57691 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:64584 178.19.233.4:57691 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny TCP 91.137.21.7:42512 91.137.21.7:3888 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:62012 178.19.233.4:49655 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny UDP 178.19.233.4:6763 178.19.233.4:57691 in via vlan94
Jul 26 17:13:37 server12 kernel: ipfw: 2 Deny TCP 91.137.17.4:14938 91.137.17.4:64906 in via vlan94

Und schon fällt die CPU Last der Netzwerk-Interrupts auf einstellige Prozentzahlen.

Fazit

Ursächlich für den Vorfall ist ein Wechsel von quagga zu bird.

Früher mußten die einzelnen NAT-IPs lokal geroutet werden, nun genügt es, die betreffenden Netze im OSPF zu announcen und sie per ipfw auf den Uplinkports abzugreifen. Eine lokale Route gibt es also nicht mehr.

Sollten solche Pakete trotzdem lokal erzeugt werden, verlassen sie das Gerät und kommen vom nächsten Router wieder zurück. Dabei werden sie wieder dem NAT vorgeworfen.

Es ist zwei glücklichen Zufällen zu verdanken, dieses Problem überhaupt finden zu können: Weil es lange genug andauerte und das betreffende Muster gerade frisch bekannt war.

Und nun können die Kisten endlich mal richtig Last aufnehmen. Ich bin gespannt.

Wir sind alle mit Nokia aufgewachsen, was logischerweise beim Smartphone bei Lumia endete. Die Teile sind zuverlässig, funktional, leicht reparierbar und bekommen langfristige Softwareunterstützung. Ideal, auch wenn sie (aus)sterben.

Heute hat sich der Kleine jammernd beklagt, dass sein 520 komplett kaputt sei. Es zeige nur noch einen blauen Bildschirm mit englischer Schrift an. Daraus schlau werde man aber daraus nicht.

WP_20180725_16_54_38_Pro

Nunja, die Fehlermeldung ist tatsächlich fast unbrauchbar:

  • Das Gerät ist kaputt.
  • Es fehlt die zentrale Konfiguration.
  • Es fehlt eine Datei im Filesystem (oder das ganze Filesystem?)
  • Man möge ein Reparatur-Tool benutzen oder den Hersteller bemühen.

Erstaunlicherweise ist das Windows Device Recovery Tool leicht zu finden und zu benutzen.

Man schließt das kaputte Handy per USB an und hofft das Beste.

wp-detect

Selbstverständlich passierte nichts. Auch nicht, wenn man explizit das Modell vorgab.

Grund dafür war ein USB-Ladekabel, das eben kein Datenkabel war. Diese Teile gehören zerschnitten und zerstört, alternativ thermisch dem Netzteil zugeordnet.

Hat man das richtige Kabel, erkennt der PC auch ein USB-Gerät:

wp-boot-manager

Beim Booten kann man per USB sozusagen ins Handy-BIOS abbiegen. Und das ist die Voraussetzung für das Recovery Tool. Es meldet dann auch gleich:

wp-select

Damit ermittelt das Tool die aktuellste passende Firmware (das Handy selbst hatte keine mehr) und läd sie nach.

wp-download

Der Prozess ist durchaus etwas langwierig, aber dann kommt schon die Installation selbst:

wp-installation

Anschließend bootet das Handy und ist wie frisch aus dem Werk.

wp-auswahl-image

Das ist keine Übertreibung: Die installierte Version ist ein nicht normal verfügbares Image von Windows Phone 8.1, das für die polnische T-Mobile vorgesehen ist.

Bei der Einrichtung muss man dann halt die Sprache von Polnisch (statt Englisch) auf Deutsch umstellen, die Sprachassistenzpakete auswechseln und zwei extra Apps löschen.

Das Kind ist ist jedenfalls zufrieden.

Was mich aber erfreut, ist der völlig problemlose Support für ein solches Altgerät. Selbst für die noch älteren Nokias gibt es entsprechende Recovery Tools. Auch die Installation der bisherigen Apps verlief problemlos. Kein abgeschalteter Store, kein Rumzicken mit RMA-Einsendungen.

Es tut einfach. Und das ist leider selten geworden. Danke.

Manchmal überrascht einen eine Trivialität. Ich wollte das Routing einer Server-IP prüfen, aber der Trace wurde zu mir zurück reflektiert. Wie geht das?

Wunder

traceroute to 178.19.224.48 (178.19.224.48), 30 hops max, 40 byte packets
 1  switch1-9-4-1-vl52.net.iks-jena.de (217.17.197.11)  1.470 ms  1.372 ms  1.304 ms
 2  turm1-g001.net.iks-jena.de (217.17.197.49)  0.382 ms  0.438 ms  0.363 ms
 3  rudo8-t001-116.net.encoline.de (5.102.160.98)  0.613 ms  0.574 ms  0.566 ms
 4  switch3-v93.net.encoline.de (5.102.160.161)  1.465 ms  1.141 ms  1.170 ms
 5  server16-vlan58.net.encoline.de (5.102.160.132)  0.567 ms  0.538 ms  0.541 ms
 6  switch4-v94.net.encoline.de (5.102.160.178)  2.181 ms  1.469 ms  1.686 ms
 7  server16-vlan94.net.encoline.de (5.102.160.185)  0.641 ms  0.635 ms  0.575 ms
 8  switch2-v58.net.encoline.de (5.102.160.129)  9.887 ms  3.478 ms  1.380 ms
 9  rudo7-t000-123.net.encoline.de (5.102.160.90)  0.879 ms  0.740 ms  0.721 ms
10  turm1-g001-116.net.iks-jena.de (5.102.160.99)  0.991 ms  0.942 ms  1.012 ms
11  * * *
12  nat-178-19-224-48.net.encoline.de (178.19.224.48)  1.123 ms  1.052 ms  1.025 ms

Der Trace geht raus, kehrt um, kommt zurück und am Ende meint er das Ziel erreicht zu haben.

Dabei trifft er sogar bestimmte Router mehrfach. Das ist deswegen verwunderlich, weil doch die Router ihre Entscheidung allein anhand der Zieladresse fällen. Wie kann also das Paket in verschiedene Richtungen geroutet werden?

Zunächst erst einmal handelt es sich nicht um ein lokales Phänomen, sondern es funktioniert auch von anderen Quellen aus.

traceroute to 178.19.224.48 (178.19.224.48), 30 hops max, 60 byte packets
...
 4  inexio2.gw.network.manitu.net (89.238.127.62)  4.593 ms  4.594 ms  4.592 ms
 5  209-096-244-077.ip-addr.inexio.net (77.244.96.209)  7.633 ms  7.634 ms  7.642 ms
 6  DE-CIX1.de.lambdanet.net (80.81.193.74)  7.605 ms  7.358 ms  6.739 ms
 7  ae2.irt2.fra25.de.as13237.net (217.71.96.45)  7.881 ms  7.878 ms  7.584 ms
 8  ae5.irt1.han87.de.as13237.net (217.71.96.30)  13.407 ms  13.380 ms  13.390 ms
 9  ae7.irt1.ber02.de.as13237.net (217.71.96.133)  16.610 ms  16.613 ms  16.607 ms
10  bb-erf-02-loc.netz.netkom-line.net (109.73.31.198)  213.352 ms  213.364 ms  213.361 ms
11  tnk-ilm-001-loc.netz.netkom-line.net (109.73.31.195)  22.149 ms  20.946 ms  20.579 ms
12  109.73.31.141 (109.73.31.141)  147.983 ms  147.987 ms  147.974 ms
13  tnk-jen-001-loc.netz.netkom-line.net (109.73.31.193)  19.504 ms  19.453 ms  19.471 ms
14  tnk-jen-001-ipt.netz.netkom-line.net (109.73.31.194)  19.468 ms  19.468 ms  19.467 ms
15  rudo7-t010.net.encoline.de (5.102.160.105)  33.994 ms  34.003 ms  34.002 ms
16  switch2-v123.net.encoline.de (5.102.160.91)  34.350 ms  34.407 ms  34.573 ms
17  server16-vlan58.net.encoline.de (5.102.160.132)  33.875 ms  33.879 ms  33.866 ms
18  switch4-v94.net.encoline.de (5.102.160.178)  34.753 ms  35.605 ms  35.596 ms
19  server16-vlan94.net.encoline.de (5.102.160.185)  34.362 ms  34.259 ms  34.179 ms
20  switch2-v58.net.encoline.de (5.102.160.129)  34.800 ms  35.279 ms  34.905 ms
21  rudo7-t000-123.net.encoline.de (5.102.160.90)  34.440 ms  34.203 ms  34.452 ms
22  rudo5-t001-123.net.encoline.de (5.102.160.89)  34.228 ms  34.449 ms  34.435 ms
23  ar2.ber.de.colt.net (213.61.70.177)  55.706 ms  55.705 ms  55.674 ms
24  212.36.135.22 (212.36.135.22)  55.909 ms  56.438 ms  56.417 ms
25  212.36.135.22 (212.36.135.22)  55.398 ms  55.416 ms  55.389 ms
26  * * *
27  * * *
28  * * *
29  nat-178-19-224-48.net.encoline.de (178.19.224.48)  68.590 ms  68.544 ms  68.691 ms

Wow. Hin- und Rückrouting in einem Trace! Man sieht sehr schön den asymmetrischen Rouingweg.

Aber was passiert da?

Schnüffeln

Die Ursache sollte ausschließlich am angesprochenen Server zu suchen sein. Alles andere wäre eine grobe Überraschung, denn dann müßten die Geräte im Transportweg irgendeine Manipulation vorgenommen haben.

Also ein Mitschnitt auf den Außeninterfaces des betroffenen Servers aktiviert:

13:39:51.074580 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 13, length 20
13:39:51.074601 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.077408 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 14, length 20
13:39:51.077414 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.077939 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 15, length 20
13:39:51.077944 IP 5.102.160.132 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.078590 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 16, length 20
13:39:51.079237 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.082388 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 17, length 20
13:39:51.084253 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.084855 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 18, length 20
13:39:51.088146 IP 5.102.160.178 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.088802 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 19, length 20
13:39:51.088848 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.092134 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 20, length 20
13:39:51.092176 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.092892 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 21, length 20
13:39:51.092934 IP 5.102.160.185 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.093756 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 22, length 20
13:39:51.093774 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 22, length 20
13:39:51.097201 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.100803 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 23, length 20
13:39:51.100823 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 23, length 20
13:39:51.101499 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.102261 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 24, length 20
13:39:51.102280 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 24, length 20
13:39:51.102924 IP 5.102.160.129 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.103742 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 25, length 20
13:39:51.103763 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 25, length 20
13:39:51.103870 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.106558 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 26, length 20
13:39:51.106577 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 26, length 20
13:39:51.106687 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.107389 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 27, length 20
13:39:51.107408 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 27, length 20
13:39:51.107510 IP 5.102.160.90 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.108284 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 28, length 20
13:39:51.108302 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 28, length 20
13:39:51.108652 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.111847 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 29, length 20
13:39:51.111866 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 29, length 20
13:39:51.112220 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.113013 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 30, length 20
13:39:51.113032 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 30, length 20
13:39:51.113386 IP 5.102.160.99 > 217.17.192.34: ICMP time exceeded in-transit, length 36
13:39:51.114062 IP 217.17.192.34 > 178.19.224.48: ICMP echo request, id 60099, seq 31, length 20
13:39:51.114080 IP 178.19.224.48 > 217.17.192.34: ICMP echo request, id 60099, seq 31, length 20
13:39:51.115606 IP 217.17.197.43 > 217.17.192.34: ICMP time exceeded in-transit, length 36

Man sieht sehr schön, wie anfangs die Echo-Pakete mit einem Timeout beantwortet werden.

Kurz darauf (ab Sequenznummer 22) tauchen plötzlich Echo-Pakete auf, bei denen Quell- und Ziel-Adresse vertauscht sind. Diese entstehen offenbar direkt nach dem Eingang des ersten Paketes.

Nun dient die Kiste ein (Carrier Grade)-NAT. Ihr Zweck ist es also Pakete umzuschreiben und zwar so, daß möglichst wenig Pakete verloren gehen. Schließlich dient NAT ja dazu, Verbindungen zu ermöglichen! Eine Firewall oder Paketfilter würde Pakete verwerfen. NAT dagegen muß so gut wie möglich raten, wo das Paket eigentlich hin soll.

In diesem Fall geht das NAT systematisch vor:

  • Es nattet die fremde Quell-Adresse auf die eigene öffentliche IP.
  • Und es nattet die eigene öffentliche Ziel-IP zu – tja wohin, achja, da ist ja ein ganz frischer Eintrag in der NAT Tabelle …

Fertig ist der Spiegel.

Gefährlich?

Kann man das mit allen Protokollen machen? Wenn ja, könnte man trivial unter falscher Flagge segeln, oder?

Tracing the path to 178.19.224.48 on TCP port 80, 30 hops max
 1  switch1-9-4-1-vl4.net.iks-jena.de (217.17.192.125)  6.742 ms  2.125 ms  1.139 ms
 2  turm2-g001-5.net.iks-jena.de (217.17.197.50)  0.228 ms
    turm1-g001.net.iks-jena.de (217.17.197.49)  0.350 ms
    turm2-g000-3.net.iks-jena.de (217.17.197.34)  0.265 ms
 3  rudo8-t001-116.net.encoline.de (5.102.160.98)  0.449 ms  0.468 ms  0.423 ms
 4  switch3-v93.net.encoline.de (5.102.160.161)  1.414 ms  1.570 ms  2.359 ms
 5  server16-vlan58.net.encoline.de (5.102.160.132)  0.489 ms  0.431 ms  0.418 ms
 6  switch4-v94.net.encoline.de (5.102.160.178)  1.443 ms  1.166 ms  1.921 ms
 7  server16-vlan94.net.encoline.de (5.102.160.185)  0.429 ms  0.473 ms  0.444 ms
 8  switch4-v94.net.encoline.de (5.102.160.178)  14.355 ms  2.695 ms  1.462 ms
 9  server16-vlan94.net.encoline.de (5.102.160.185)  0.473 ms  0.495 ms  0.465 ms
...

Nein, man kann nicht. Und das ist gut so™.

Die aktuell kochende Debatte zur Reform des Urheberrechts, insbesondere im Zusammenhang mit dem Internet ist ebenso spannend wie ermüdend. Es gilt dabei in der erster Linie zu verstehen, was den jeweiligen Gegenpart antreibt.

Die Erschaffer

Jedes Werk hat einen Erschaffer. Der Akt des Erschaffens ist eine Investition von Zeit, Können und Material. Auch der Akt der Aufführung ist eine solche Investition. Und wofür? Für den Konsumenten. Im Idealfall zahlt der dann dem Erschaffer für seine Leistungen einen Preis.

Es ist allerdings schwierig - sowohl für den Erschaffer als auch für den Konsumenten, für das Werk zusammen zu kommen. Hierbei braucht es Hilfe.

Die Rechteverwerter

Auslöser des Ganzen Spektakels ist die sterbende Branche der Rechteverwerter. Dies ist eine Gruppe von kommerziellen Vermittlern zwischen Erschaffenden und Konsumenten. Sie spekulieren auf zukünftige Talente, indem sie sie frühzeitig unter Vertrag nehmen, leidlich finanziell ausstatten und zu Erfolgserlebnissen führen. Hat man Glück mit der Spekulation werden große Geldsummen umgesetzt, an denen der Vermittler beteiligt wird. Davon kann er auch Fehlschläge abfedern. Sei es ein Buch, ein Musikstück, ein Film, eine Skulptur, ein Bild, ein Theaterstück, eine Fernsehserie, ein Computerspiel oder etwas anderes.

Die Rechteverwerter haben mit dem Urheberrecht ein Mittel in der Hand, mit der sie dem Schaffenden die Verwertung seiner Werke abkaufen. Er kann dann oft selbst nicht auftreten, ohne eine Vereinbarung mit seinem eigenen Verwerter getroffen zu haben, d.h. ein Teil seiner Einnahmen abführen zu müssen.

Voraussetzung dieses Modells ist, dass die Aufführungen unter Kontrolle des Vermittlers bleiben. In der einfachsten Form wird der Vermittler die Aufführung selbst organisieren. Um eine Amortisation der Anfangskosten und Fehlinvestitionen sicher zu stellen, werden die Verwertungsrechte sehr lang gewährt, auch über den Tod des Erschaffers hinaus. Die Idee dahinter ist, dass einige wenige zentral agierende Vermittler so viel Fehlinvestitionen vornehmen können, dass ein reiches kulturelles Leben für alle gedeihen kann.

Wie in allen Fällen verselbstständigen sich Teile des Konzepts und es gibt unerwünschte Missbildungen. So kann ein Vermittler wesentlich zu hart mit vermeintlichen Aufführungen umgehen, bspw. wenn Kinder beim Laternenumzug singen. Auch Gerechtigkeitsfragen sind ein immer wieder auftretender Knackpunkt, insbesondere, wenn es um die weitere Finanzierung der Fehlinvestitionen geht. Was kulturell wertvoll ist, muss nicht zwangsläufig eine sprudelnde Geldquelle sein.

Eine besondere Form der Vermittlungstätigkeit ist im Journalismus anzutreffen: Die erzeugten Produkte haben eine Halbwertszeit von wenigen Tagen, erfordern aber oft einen erheblichen Aufwand, um seriös zu sein. Entsprechend hoch ist der Druck, die wenigen Ergebnisse schnell, häufig und exklusiv zu vermarkten. Ein wesentliches Problem ist dabei die leichte Reproduktion des Produktes (einer Nachricht). An dieser Stelle wäre es dem Vermittler (der Zeitung) sehr recht, wenn sämtliche - auch ansatzweise reproduzierten - Kopien der Nachricht unter Kontrolle des Vermittlers blieben. Dies ist der Kern des Leistungsschutzrechtes. Es wird ebenfalls unter der Annahme formuliert, viele Fehlinvestitionen zu kompensieren und damit eine Vielfalt an Meinungen zu erhalten.

Das Internet

Der Kerngedanke des Internets ist dagegen die Idee, jede Form von Vermittlung zu vermeiden: "Jeder hat das Recht zu senden" und "Jeder hat das Recht sich aus öffentlich verfügbaren Quellen zu informieren" sind zwei Aussagen, die das Grundgesetz als Meinungs(äußerungs)freiheit und Rezipientenfreiheit bezeichnet. Diese Offenheit des Internet führt zu einen bis dahin unbekannten Meinungspluralismus und einem gigantischen kulturellem Reichtum, der jedem zur Verfügung steht.

Unglücklicherweise kann nicht jeder jedem jederzeit zuhören. Stattdessen muss man seine zeitlich beschränkte Aufmerksamkeit auf wenige von einem selbst ausgewählte Informationen konzentrieren. Welche das sind, entscheidet die Aufmerksamkeitsökonomie.

Was man aber tun kann, ist andere auf eine Quelle hinzuweisen. Dieses Konzept der Referenzierung einer Quelle nennt man Verlinkung. Mit einem kurzen kontextbezogenen Hinweis wird der Interessierte an die Originalstelle verwiesen. Der Hinweistext dient dabei als Motivation, zum fremden Angebot zu wechseln.

Referenzierung führt also vom eigenen Angebot weg zu einem Fremden. Es ist eine aktive Abgabe des Nutzers an andere. Dies ist das vollständige Gegenteil dessen, was bei einem Verwertungsmodell umgesetzt werden soll: Der Konsument soll maximal viel Ressourcen bei nur einem Produkt investieren.

So gesehen liegt dem Internet eine kommunistische Idee zugrunde: Jeder bietet an, was er kann und jeder nutzt, was er braucht. Auch das führt zu Vielfalt, nicht aber zu finanzieller Sicherheit für den Erzeuger. Internet kann man halt nicht essen.

Die angebotenen Monetarisierungsmöglichkeiten sind derzeit beschränkt: Man kann die gewonnene Aufmerksamkeit verkaufen indem man Werbung einblendet, oder man fordert vorab eine Bezahlung der Leistung ein (Paywall). Auf der Strecke bleiben dabei alle Dienstleister, die den Abruf der Information überhaupt erst ermöglichen: Niemand zahlt die Einnahmen anteilig an die Hersteller der Browser, der Betriebssysteme, der Webserver oder gar an die Transporteure der Daten. Die Infrastruktur wird als gegeben hingenommen.

Die Verweise selbst, die oft schon viel von der Information verraten, bleiben dabei komplett außen vor. Wer an dieser Stelle ein Geschäft aufzieht, indem er Verweislisten anbietet und die Aufmerksamkeit des Besuchers bei sich behält, kann die Geldflüsse zu sich umleiten. Das ist genauso wie eine Zeitung das Geld einsammelt, indem sie die Arbeit der Journalisten zusammenfasst und vervielfältigt. Interessanterweise unterscheidet sich hier das Vertragsverhältnis: Für einen Link im Internet braucht man keinen Vertrag, für einen Abdruck in der Zeitung schon.

Man könnte einfach hingehen und das Problem ignorieren. Wer interessante, wertvolle, oder aufmerksamkeitsheischende Inhalte anzubieten hat, wird durch viele Referenzen viele Konsumenten zugespielt bekommen und kann dann selbst monetarisieren.

Um aber gute Werbeverträge zu bekommen, braucht man einen Vermittler. Schon wieder Vermittler? Ja, allerdings liegt das Risiko komplett beim Erschaffer, denn eine Vorfinanzierung gibt es nicht.

Lösungsmöglichkeit

Wie kommt man aus diesem Dilemma heraus?

Es bedarf der Möglichkeit eines Vertragsschlusses zur Referenzierung, alternativ Micropayments. Könnte der Erschaffer (oder sein Rechteverwerter) eine korrekt, bezahlte Referenzierung ermitteln, so könnte er die Paywall nach außen verlagern und das Geld an den referenzierenden Plattformen auf Vertragsbasis abgreifen.

Was es dazu braucht ist eine andere Art der Referenzierung. Diese muss bis durch den Verbindungsaufbau hindurch den Nachweis der Abrechnung gestatten. Mit dem klassischen LINK-Element geht das nicht.

Gäbe es ein Element (ich nenne es mal das RECHTS), das den Verkauf von Referenzierungsrechten gestattet, so könnten die großen Plattformen entsprechenden Kontingente erwerben und damit auf die interessanten und spannenden Inhalte verweisen.

Es geht um die <right
  prepaid="U3BpZWdlbC5PbmxpbmU9UGF5Okdvb2dsZToxMjM0NTYK"
  href="https://spiegel.example/123456"
>Freiheit des Internets</right> und die Zukunft unserer Gesellschaft.

Wer kein Plattformbetreiber ist, kann trotzdem auf die Inhalte referenzieren, indem er auf die Micropayment-Schnittstelle des Verwerters verweist.

Es geht um die <right
  payment="gemacoin:springer"
  currency="EUR"
  view="0.0001" click="0.001"
  href="https://spiegel.example/123456"
>Freiheit des Internets</right> und die Zukunft unserer Gesellschaft. 

Da bei dieser PayPerUse Methode nicht sicher gestellt ist, dass entsprechende Zahlungen erfolgen, wurde der Preis zum Anzeigen des Referenzierungstextes auf ein Hundertstel-Cent festgelegt. Der Browser verhindert dann die Anzeige des Referenzierungentextes.

linktax

Das Anklicken kostet dann ein Zehntel-Cent. In beiden Fällen wird eine spezielle Form der TCP-Kommunikation zum Webserver aufgemacht, die sicher stellt, dass die Bezahlmethode auch ausgeführt wurde. Erfolgt der Zugriff ohne diese Methode (z.B. per LINK), dann lehnt der Webserver die Anfrage mit 402 - Payment required ab oder lenkt auf eine extra Paywall um.

Zusätzlich ermöglicht diese spezielle Art des Verbindungsaufbaus, dass die Access- und Transitprovider an den Einnahmen der Verwertungsgesellschaften teilhaben. Die Gelder, die durch das RIGHT-Element von den großen Plattformen zu den Erschaffern oder deren Verwertern strömen, sind ja nicht nur für die Leistungen der Erschaffer, sondern auch für die Dienstleistung, die die Provider erbringen, indem sie die Konsumenten zuführen.

Fazit

Der Wunsch aller an einem Werk beteiligter Personen und Unternehmen an entsprechender Entlohnung ist nachvollziehbar. Da das Internet in seiner jetzigen Form das nicht leisten kann, muss es um ein entsprechendes Element der entgeltpflichtigen Referenzierung ergänzt werden. Mittels dieser Erweiterung ist es allen, die auf einer Entlohnung bestehen, möglich, die notwendigen Einnahmen zu generieren.

Es steht jedem frei, seine Werke im Internet mit den kommunistischen Links oder den entgeltpflichtigen Rechts referenzieren zu lassen. Lassen wir also die Rosinenpickerei. Auf beiden Seiten. Verlinken wir nicht mehr auf kommerzielle Inhalte, lassen wir Rechts im Internet gedeihen.

Aktuell wird wieder die Sau der Zensur (Filterung vor Veröffentlichung) und Monetarisierung (Leistungsschutzrecht) durchs globale Dorf getrieben. Und ich muß feststellen, daß das Internet tatsächlich ein Rechtsfreier Raum ist. Aber dagegen kann man etwas tun.

Was ist das Problem mit Links?

Links sind im Internet weit verbreitet. Sie gestatten die Nutzung fremder Leistungen durch Verweis auf die oder Einbindung der fremde Leistung ohne ein Entgelt einzutreiben.

Auf diese Weise ist es selbstverständlich unmöglich, durch kreative Arbeit im Internet Geld zu verdienen.

Und was kann man dagegen tun?

  • Entweder man läßt zu, daß existierende Technik kaputt geklagt wird.
  • Oder man definiert eine neue Technik, die die Probleme punktgenau löst.

Das Internet darf kein rechtsfreier Raum sein

Also definiert man sich Rechts. Rechts sind wie Links, nur halt für die Content-Industrie.

Und sie haben alles, was die "geistiges Eigentum"-Vertreter wüschen:

  • Verweise können entgeltpflichtig werden.
  • Heruntergeladene Inhalte können vor unerwünschter Nachnutzung geschützt werden.
  • Schnellwege für die Datenauslieferung können vereinbart werden.

Und wie geht das? Per Definition bei der IETF.

Im der DSGVO steht drin, daß man seinen Datenschutzbeauftragten bei der Aufsichtsbehörde zu melden hat. Der zuständige Landesdatenschutzbeauftragte hier in Thüringen hat dafür ein sehr interessantes Formular erstellt.

Das Formular

Zum einen ist das Formular keine online-Einreichung, die dem TLfDI die Arbeit erleichtern würde. Stattdessen ist handelt es sich um ein Microsoft Word-Dokument, das man ausfüllen und ausdrucken soll. Anschließend ist das Dokument auf dem Postweg zu versenden, da in der Einreichungsaufforderung keine eMail-Adresse angeben wird.

Der Inhalt des Formulars ist ebenfalls überraschend:

2018-05-24-161013_626x678_scrot

Da stellt sich die Frage, ob denn die Angaben überhaupt alle benötigt werden. Wozu braucht die Aufsichtsbehörde beispielsweise die Webseite des bestellten Datenschutzbeauftragten?

Und dann stellt sich die Frage, was man da eigentlich melden muß.

  • Die verantwortliche Stelle ist ja noch klar.
  • Kommt bei Datenschutzbeauftragter aber nun der Datenschutzbeauftragte hin oder nur dann, wenn es ein interner ist?
  • Oder wird ein interner DSB als externer gemeldet, bei dem das Auswahlfeld externer auf Nein gestellt wurde?

Für die Kirchgemeinde kann ich das gut ausfüllen. Zuerst die Gemeinde, dann der örtlich zuständige DSB der Landeskirche, und dann der extern bestellte DSB des Verbands der evangelischen Kirchen in Berlin. Auf Beschluß der Landessynode wurde also der (externe) DSB an Stelle des (örtlichen) DSB für zuständig erklärt. Aber sonst?

Das Leak

Öffnet man aber die Eigenschaften des Dokumentes (was ich getan habe, weil das Dokument sich heute am Tag verändert zu haben schien), dann staunt man:

2018-05-24-154240_520x675_scrot

Autsch.

Wo meldet man diesen Datenschutzverstoß eigentlich?

Update

Seit heute früh (25.5.2018) gibt es ein neues Formular. Der Link zum alten Formular wird redirected.

Diesmal ist es besser ...

2018-05-25-131455_282x221_scrot

Danke.

Da nun keine Notwendigkeit für die Speicherung dieser personenbezogenen Daten besteht, habe ich auch die Klarnamen und E-Mail-Adressen unkenntlich gemacht.

Ich hatte kürzlich geschrieben, wie man die DSGVO als Blogger umsetzen kann. Der Text ist ziemlich abstrakt geworden, weil ich einen generellen Leitfaden beibehalten wollte. Nun also mal konkret für meine eigene Webseite.

Analyse

Ich schrieb: Man nehme sich seine Webseite her, und schau im Entwickler-Modus des Browsers erst einmal nach, welche Datenquellen die Webseite so alles einbindet.

Bei Firefox drücke ich F12 für den Entwickermodus und wähle den Reiter Netzwerk aus. Dann lade ich die Seite erneut mit F5.

2018-05-22-102920_715x381_scrot

Es fällt auf, das bei allen Zugriffen das Schlosssymbol aktiv ist. Das bedeutet die Zugriffe erfolgen über HTTPS. Wenn möglich sollte man HTTPS benutzen, besonders aber, wenn man Formulare benutzt. Den Punkt habe ich also schon mal erfüllt, es extra aufzuschreiben ist aber nicht nötig.

Als nächstes sticht ein Zugriff auf einen externen Server ins Auge: Ein Stylesheet wird fonts.googleapis.com nachgeladen. Das werde ich dokumentieren müssen.

Weiter mit der Faktensammlung: Wie schaut's mit Cookies aus? Unter Einstellungen - Privacy findet sich der Punkt Cookies.

2018-05-22-110102_973x407_scrot

Ohja. Das ist eine ganze Menge. Allerdings bin ich aktuell auch als Bearbeiter im Backend angemeldet und das ist keine öffentliche Funktion. Löscht man alle diese Cookies und versucht es nochmal (z.B: von einem anderen Rechner aus), so bleibt die Liste leer. Wie schön.

Die grundlegende Analyse ist damit schon abgeschlossen. Bleiben nun die gewollten Eigenschaften der Webseite, also die Dinge, die ich bewußt entwickelt, eingeschaltet und aktiviert habe. Die findet man natürlich nicht automatisch, sondern die weiß man als Autor. Im Zweifel hilft ein Blick über die verschiedenen Bereiche der eigenen Webseite, um das Gedächtnis aufzufrischen.

Was ist denn nun besonders an der Seite? Achja, Kommentare. Und da kann man sich tatsächlich einen Cookie setzen lassen, der die Angaben des Formulars automatisch vorab ausfüllt. Den wird man erwähnen müssen. Dabei fiel mir auf, daß das Formular den Cookiebutton automatisch aktiviert hat. Das habe ich gleich mal umgestellt.

Des weiteren habe ich interaktive Inhalte auf der Seite. Auf die will ich nicht verzichten, also muß ich sie beschreiben.

Und damit ist die Analyse schon beendet.

Eigner Server

Jetzt geht's ans Eingemachte: Was tut eigentlich mein Webserver so?

Ich weiß, daß er Logfiles führt. Die lese ich zwar nur bei Bedarf (und den hatte ich schon) und mache keine Statistik damit.

Und dann gibt's noch Logfiles für verschiedene Fehlerzustände. Die sind verdammt umfangreich, denn ich will wissen, was genau den Fehler ausgelöst hat.

Bleibt noch die Frage, wie lange die Logfiles liegen bleiben: Aha, eine Woche. Das scheint mir angemessen, denn ich brauche diese Zeit vor allem nach einem langen Wochenende.

Schreiben wir's auf:

Beim Zugriff auf diese Webseiten übermittelt der Browser des Besuchers
automatisch Daten über die gewünschte Ressouce, die IP-Adresse, an die
die Daten übermittelt werden sollen, gegebenenfalls auch spezifische Daten
aus vorherigen Anfragen (Cookies, Referer, Formulare, etc.).

Ein Teil dieser Daten wird automatisch geloggt, um den technischen Betrieb
sicherstellen zu können. Diese Daten werden grundsätzlich nur zur manuellen
Post-Mortem-Analyse herangezogen anderenfalls automatisch nach sieben
Tagen gelöscht.

Fertig.

Cookies

Meist ein heißer Punkt. Aber auch hier habe ich Glück, denn normalerweise setze ich keine Cookies, da ich auf Anmeldungen verzichte.

Nicht-angemeldete Nutzer erhalten grundsätzlich keine Cookies seitens des Webservers.

Und der Cookie bei Formularen?

Auf explizite Aufforderung des Nutzers werden die Angaben für Stammdaten
des Kommentarfeldes per Cookie im Browser gespeichert. Dieses dient dazu,
bei späterer Nutzung des Kommentarfelds diese Daten schon initial einzutragen.
Dieser Cookie wird vom Browser spätestens nach einem Jahr gelöscht,
eine manuelle Löschung ist jederzeit vom Nutzer selbst in seinem Browser möglich.
Eine Speicherung des Cookies auf Serverseite erfolgt nicht.

Der Teil mit der Anmeldung zwecks Bearbeitung betrifft nur mich allein. Aber der Vollständigkeit halber schreibe ich es auf. Es schadet ja nicht.

Mit dem Beginn einer Anmeldung oder Registrierung wird ein Session-Cookie
gesetzt, der dazu dient, den Nutzer bis zur Abmeldung wieder zu erkennen.
Dieser Cookie wird automatisch gelöscht, wenn der Browser geschlossen wird.
Eine Speicherung des Cookies auf Serverseite erfolgt nicht.

Für angemeldete Nutzer können weitere Cookies gesetzt werden,
um verschiedene Workflows technisch umzusetzen. Eine Speicherung dieser
Cookies auf Serverseite erfolgt nicht.

Nur für administrative Aufgaben ist eine Anmeldung notwendig,
die normale Nutzung erfolgt generell ohne Anmeldung. 

Und schon wieder fertig.

Externe Server

Warum mache ich das eigentlich? Weil ich es allein kann. Ich bin schlicht nicht in der Lage, abertausende von Besonderheiten von Browsern in verschiedenen Konfigurationen korrekt mit einem gewünschten Style zu beliefern. Ich kann das auch nicht mal eben kopieren, weil die Auslieferung ja browserabhängig ist. Und selbst wenn ich kopieren könnte, darf ich das überhaupt? Ganz zu schweigen davon, daß ich es nicht aktuell halten könnte. Deswegen binde ich diese Inhalte ja extern ein, von jemanden der es kann.

Grundsätzlich werden alle Inhalte direkt vom Server ausgeliefert.

Eine Einbettung externer Inhalte erfolgt automatisch dann, wenn die Inhalte
technisch nicht lokal bereit gestellt werden können. Dies betrifft generell die
browserabhängige Bereitstellung von Javascript/CSS/Font-Daten für eine
einheitliche Darstellung der Webinhalte. Typischerweise werden diese Daten
vom Browser gecached und nur einmal direkt geholt. Eine Korrelation zwischen
den einzelnen Webseiten-Besuchen und dem Nachladen dieser Ressourcen
ist also nicht zwingend gegeben.

Soweit so klar. Was ist mit Videos? Ich nehme gern mal ein Video auf und lasse es von YouTube streamen. Warum? Weil ich es lokal nicht kann. Der Aufwand wäre unverhältnismäßig.

Fallweise können auch Videos einbettet sein, um auf die nur extern
vorhandenen Streamingressoucen zugreifen zu können. 

Warum ist das alles überhaupt erwähnenswert? Weil es den Nutzer dazu bringt, evtl. Daten an Dritte weiter zu reichen.

In all diesen Fällen sendet der Browser des Besuchers selbst
entsprechende Daten an den jeweiligen externen Server.

Fertig.

Interaktive Inhalte

Jetzt ist meine Spielwiese dran. All die schönen Tools.

Es wäre sinnfrei, jedes Tool im Detail zu erklären. Dazu kommt, daß die meisten Tools komplett im Browser des Nutzers ablaufen. Schließlich will ich die Last ja nicht auf meinem Server haben.

Auf der Webseite können interaktive Inhalte angeboten werden.
Diese werden – soweit technisch möglich – als Javascript im Browser des Nutzers ausgeführt.

Unglücklicherweise kann Javascript nicht beliebige Dinge im Browser machen und braucht externe Informationen, die es nur vom ausliefernden Server bekommen kann (Same-Origin-Policy). Diese Zugriffe sind zu dokumentieren. Sie unterscheiden sich aber nicht wesentlich von normalen Zugriffen.

Werden bestimmte Inhalte dynamisch auf der Serverseite ermittelt,
so wird grundsätzlich kein weiteres Log über diese Aktionen geführt.
Beim Auftreten von Verarbeitungsfehlern können zur Fehlersuche
beliebig detaillierte Logs geführt werden. Diese werden automatisch
nach sieben Tagen gelöscht.

Und dann habe ich noch Scantools, die selbst aktiv nach außen greifen.

Einzelne aktive Inhalts können auch selbst Zugriffe auf andere
externe Ressourcen durchführen, z.B. einen Sicherheitsscan über
vom Nutzer definierte Netzbereiche.

Fertig.

Kommentare

Was gibt es persönlicheres an Daten als nutzergenerierte Inhalte? Die will ich haben, denn die machen die Würze eines Blogs aus.

Es ist grundsätzlich möglich, bereit gestellte Inhalte zu kommentieren.
Diese Kommentare sind öffentlich einsehbar und werden
von Suchmaschinen indiziert.

Wenn man einen Kommentar schreibt, will man diskutieren und agiert als handelnde Person. Welche Persönlichkeit man darstellen will, ist dabei egal. Darüber hinaus habe ich aber auch mit Mißbrauch und Rückfragen zu tun. Da möchte ich neben dem öffentlichen Kommentar auch direkt kommunizieren können. Und anhand der IP, der einzigen Information die man nicht beliebig wählen kann, möchte ich auf schweren Mißbrauch reagieren können.

Bei der Erstellung eines Kommentars wird der Nutzer gebeten,
seinen Namen und seine E-Mail-Adresse anzugeben.
Die Angabe eines Weblinks ist optional.

Der angegebene Name und die optionale URL werden zusammen
mit dem Kommentar angezeigt. Dies dient der Verbesserung
der Kommunikation, da dies die Zuordnung der Beiträge in einer
Diskussion ermöglicht. Der Name und die URL werden nicht validiert.

Die E-Mail-Adresse wird nicht angezeigt. Sie dient ausschließlich
der Kontaktaufnahme mit dem Kommentator zu administrativen
Zwecken. Sie wird bei der Eingabe nicht validiert.

Die IP Adresse des Kommentators wird automatisch erfaßt und wie
die anderen Angaben zusammen mit dem Kommentar gespeichert.
Dies dient dazu, einen Kommentar zweifelsfrei einer Quelle zuzuordnen.
Diese IP wird herausgegeben, wenn Strafverfolgungsbehörden anfragen.
Darüber hinaus wird die IP herangezogen, um automatisch
Kommentarspam zu blockieren.

Da hier nun erstmals und im engeren Sinne personenbezogene Daten verarbeitet werden, sollte man auch über Korrektur- und Löschmöglichkeiten informieren.

Es besteht kein Anspruch auf Veröffentlichung von Kommentaren.
Kommentare werden administrativ gelöscht, wenn sie störend oder
themenfremd sind. Eine manuelle Löschung von Kommentaren ist möglich,
wenn die Löschanfrage mit der passenden E-Mail-Adresse abgesendet wurde
und die Löschung nicht einen thematischen Zusammenhang zerstört.

Klingt schräg? Mag sein, aber ich lasse mir nicht vorschreiben, was ich bei mir zu veröffentlichen habe. Des weiteren habe ich auch einen dicken Hals bei Personen, die Geschichtsklitterung betreiben wollen. Da müssen dann schon ernsthaft triftige Gründe her, um die Abwägung zugunsten einer Änderung oder Löschung ausschlagen zu lassen.

Beschwerde

Da man sich schlecht bei mir selbst über mich beschweren kann, stellt sich die Frage, wer mir denn auf die Finger schauen darf.

Für einen eigenen Datenschutzbeauftragten bin ich … Hallo? Vergeßt es.

Trotzdem muß ich herausfinden, wer für mich zuständig ist. Denn das kann man im Fall einer Beschwerde kaum dem Nutzer überlassen. Er wird sonst von Pontius zu Pilatus geschickt und kommt nie an der richtigen Stelle an.

In meinem Fall ist das einfach: Der Landesdatenschutzbeauftragte.

Bei Beschwerden wenden Sie sich bitte an den Thüringer Landesbeauftragten
für den Datenschutz und die Informationsfreiheit (TLfDI).

Den werde ich dann noch bei meiner zuständigen Aufsichtsbehörde (TLfDI) formgerecht melden.

Noch Fragen?