DSGVO am Beispiel des eigenen Blogs
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.
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.
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?
Ich habe mich ja immer gegen dieses "HTML" gewehrt und kenne mich nicht damit aus,
aber:
a) Warum reicht nicht das Ausliefern von validem, statischem HTML ?
b) Wenn man irgendwelche "APIs" dynamisch nachlädt, warum dann nicht wenigstens vom eigenen Server ?
c) Warum haben Internetbrowser keine Einstellmöglichkeiten für
- Links nur einbetten, wenn sie vom gleichen Server kommen, der aufgerufen wurde
- Keinerlei Referrer übermitteln ?
So kann ein Benutzer *selbst* und souverän entscheiden, was er preisgibt.
Youtube und Vimeo kann man genauso verlinken wie Google Maps und OpenStreetMap.
Desweiteren halte ich es nicht für ausreichend, einfach zu sagen, dass man Ressourcen Dritter einbindet, imho müsste man auch noch genau angeben, wessen und wie es mit dem Datenschutz der jeweiligen Anbieter aussieht.
So genau habe ich mich nicht damit beschäftigt, weil ich in meinen Projekten die Ressourcen Dritter meide oder nur als normalen Link bereitstelle. Ganz old school.
P.S.: Warum muss man zum Kommentieren JavaScript einschalten?
P.P.S.: Ein „Formularinhalt löschen“-Button ist ganz schlechte Usability. Noch dazu ohne Rückfrage.
Ich fürchte nur, dass Du nach Artikel 13 (1) c noch jeweils die Rechtsgrundlage dazu schreiben musst (also letztendlich doch wieder alles mit Paragraphen zukleistern).
Ansonsten: prinma und danke!
8 Kommentare