Datenschutz - der Untergang des Abendlands?

Ein Gespenst geht um im Internet. Das Gespenst der Datenschutz-Grundverordnung (DSGVO). Entnervte Betreiber von privaten Blogs verlassen das Netz und steigen auf Brieftauben um. Schulhomepages werden geschlossen und Schreibwarengeschäfte melden Hamsterkäufe von Lehrern, die alle verfügbaren Lehrerkalender aufkaufen. Kurz, der Untergang des Abendlandes steht wieder einmal vor der Haustür.

Nein, tut er nicht. Dieser Beitrag versucht, die Umstellung auf ein DSGVO-konformes Blog zu erläutern und einfache Schritte zu zeigen, mit denen Panikattacken vermieden werden. Gleichzeitig gibt es aus meiner persönlichen Erfahrung einige steile Thesen, bei denen nicht nicht allgemeine Zustimmung erwarte, die ich aber für wichtig halte. Dazu gleich ein Disclaimer: dieser Artikel entstand als Reation auf die Diskussion mit einigen Lehrerinnen und Lehrern auf Twitter. Die Zielgruppe sind also die Betreiber privater Blogs, Lehrerhomepages und andere nichtkommerzielle Aktivitäten. Falls Sie einen Onlineshop betreiben oder anderweitig mit Ihrem Onlineauftritt Geld verdienen, sind Sie hier falsch.

TL;DR

Ich beschreibe in diesem Artikel die Schritte, die ich unternommen habe, um meine private Homepage und mein Blog auf die Anforderungen der DSGVO anzupassen, die ab Ende Mai 2018 europaweit gilt. Ziel war, die Seite ohne externe Zugriffe auf Services Dritter und ohne die Weitergabe oder Speicherung personenbezogener zu betreiben.

Inhalt

• Das Ziel
• Der Weg
• https
• Fonts
• Scripts
• Social Media Buttons
• iframes
• YouTube
• Kommentare
• Logfiles
• Referrer Policy
• Fazit

Ziel war es, beim Test der schwedischen Seite https://webbkoll.dataskydd.net/en alles “sauber” zu bekommen. Ich habe das dann als sportliche Herausforderung aufgefasst: bekomme ich meine Homepage sozusagen “self contained”, also ohne die Einbindung externer Ressourcen ausser den üblichen Hyperlinks ans Laufen? Der aktuelle Stand nach etwa einem Abend Aufwand sieht so aus:

Meine Ausgangsbasis war allerdings etwas einfacher gelagert als viele Blogs, die auf WordPress, Drupal et.al. basieren: ich bin bereits vor etwa zweieinhalb Jahren aus einen statischen Seitengenerator umgestiegen, weil mir die Sicherheitslücken von WordPress und der softwaretechsnische Overkill für ein einfaches Blog zu viel waren. Mehr dazu gibt es in diesem Aertikel. Merh dazu im Verlauf des Artikels.

Das Ziel – einfach, datensparsam und DSGVO-sicher

Was war also das Ziel der Umstellung? Ich will ein Blog, dass von meinen Besuchern möglichst gar keine personenbezogenen Daten erhebt. Ich will self contained sein, d.h. keine externen Quellen aufrufen, wenn nicht nötig und datenschutztechnisch sicher. Ich will mich um das DSGVO-Thema nur einmal kümmern und dann Ruhe haben, um Inhalte zu produzieren. Ich will keinen softwaretechnischen Overhead pflegen (MySQL, PHP, App-Server oder anderes). Ich analysiere nicht, wie ich Werbung auf meine Seite platzieren und wer wann wohin klickt, weil es auf meinen Seiten keine Werbung oder Affiliate Links gibt. Ja, das mag jetzt nicht auf alle Leser zutreffen, aber siehe oben das “TL;DR”.

Der Weg

Systementscheidung (die steile These 1)

Nein, ich habe nichts gegen WordPress, Drupal, Typo3 oder alle die anderen CMS-Systeme, ich habe selbst mehrere Jahre WordPress-Sites betrieben. Wie ich auf Twitter schrieb: “WordPress ist nicht per se schlecht”. Es gibt durchaus Einsatz-Szenarien für ein CMS, meiner persönlichen Meinung nach fällt der Betrieb einer privaten Homepage oder eines relativ einfachen Blogs wie diesem hier nicht darunter. Ich benutze einen Generator, der aus meinen Artikeldateien statische HTML-Seiten generiert (und auch nur veränderte Seiten neu erzeugt). Das Ausgabeverzeichnis wird einfach auf meinen Webserver hochgeladen und fertig. Kein PHP, kein MySQL, kein irgendwas, nur HTML-Seiten. Schnell, sicher und robust. Ein paar Argumente, warum ein static site generator IMHO sinnvoller für einen privaten Auftritt ist als die eierlegende Wollmilchsau WP:

• Der Angriffsvektor ist für den Einsatzzweck zu groß.
  Ich muss auf meinem Server PHP, MySQL und das WP-Paket inkl. aller Plugins auf dem aktuellen Stand halten.

• WP-Themes sind deutlich komplexer als die Themeing-Logik fast aller statischen Seitengeneratoren.
  Für das von mir genutzte System (Hugo) benötige ich keine PHP-Kenntnisse, sondern komme mit HTML-Templating und CSS aus, wenn es sein muss, zusätzlich etwas JavaScript.

• Die Seiten und Posts liegen nicht in irgendeiner Datenbank, sondern als einzelne Dateien vor
  Ich kann jederzeit auf einen einzelnen Artikel mit einem dummen Texteditor zugreifen und Änderungen durchführen. Keine Datenbank, völlig frei in der Wahl des Editors. Ich kann eine Versionsverwaltung meiner Wahl einsetzen.

• Das System ist wesentlich einfacher erfass- und verstehbar.
  Die Lernkurve, um WP wirklich zu beherrschen und sich nicht nur als Endanwender darauf zu verlassen, dass das System und all die Pluings schon tun werden, was sie versprechen, ist meiner Meinung zu hoch. Wie gesagt, wenn Sie eine Agentur sind oder einen PHP-Crack in der Familie haben, ist das etwas Anderes, aber mein Schwerpunkt liegt auf dem Ergebnis, nicht dem Werkzeug.

Hugo ist nicht der einzige Generator, es gibt eine ganze Reihe, von Jekyll, Pelican oder die Auflistung hier. Solche Systeme entsprechen dem Ansatz, den bereits Albert Einstein geäußert hat: “mach es so einfach wie möglich, aber nicht einfacher” :-)

Natürlich können Sie alle Tipps des Artikels auch mit WordPress, Drupal o.ä. nutzen, es ist oft nur schwieriger, die richtige Stelle “unter der Motorhaube” zu finden, vor allem, wenn Sie WP nicht selbst auf einem eigenen Server betreiben und auf Ihren Webhoster angewiesen sind. Das ist ebenfalls ein wichtiger Punkt, den viele Betreiber eines Blogs mit der vermeintlich “einfachen” Lösung WP oder Typo übersehen haben: kompetente Nutzung setzt entsprechendes Werkzeugwissen voraus oder man liefert sich technisch dem Betreiber/Hoster aus. Daher sollte das verwendete System eine möglichst flache Lernkurve aufweisen, über eine entsprechende Community verfügen und Verständnis anstelle von Anwendungswissen ermöglichen.

Was noch dazu kommt: viele Seitenbetrieber setzen jetzt einfach eine “Ich bin einverstanden”-Checkbox ein, um dann auf entsprechende externe Quelle zu verweisen oder eingebettete Inhalte aufzurufen. (Hinweis: Ich bin kein Jurist und alles, was in diesem Artikel steht, ist keine irgendwie geartete rechtliche Beratung, sondern das Ergebnis von Recherche im Netz bzw. dem Studium der DSGVO. Holen Sie sich im Zweifel professionelle Hilfe bei einem Juristen!) Die DSGVO fordert (z.B. in Art. 7 Absatz 1 bzw. 3) aber einiges, was darüber hinausgeht. So müssen Sie den Besuchern eine “informierte Entscheidung” ermöglichen, d.h. Art und Umfang sowie Verwendungszweck der übertragenen Daten genau kennen (wer kann das schon?), dazu muss die Einverständniserklärung nachweisbar sein. Wenn ich also in einigen Wochen auf Ihrer Seite vorbeikomme, die Checkbox abklicke und dann nach einer Woche wissen will, warum und wann ich da zugestimmt habe: können Sie anhand einer rechtssicheren Archivierung meiner Zustimmung nachweisen, dass dem so ist? Ein Widerruf der Einverständniserklärung darf ebenfalls nicht schwieriger sein als das Einverständnis. Muss ich Ihnen also erst eine Mail schrieben, während die Zustimming eine einfache Checkbox war, haben Sie ebenfalls den schwarzen Peter gezogen. Klar sind das Details, aber wichtige Details. Rechtliche Vorgaben müssen komplett befolgt werden, ansonsten müssen Sie sich gar nicht erst die Mühe machen, damit anzufangen. “Halb schwanger” geht nicht… :-)

Grundsätzlich https

Das sollte der Punkt 1 auf der Liste für die datenschutztechnische Überprüfung jedes Onlineauftritts sein. Stellen Sie den Auftritt auf SSL um und zwar so, dass SSL nach Möglichkeit erzwungen wird oder der default ist. Eine detaillierte Einführung in SSL/https würde den Rahmen des Artikels sprengen. Sie müssen für das entsprechende Zertifikat auch kein Geld auf den Tisch legen. Wenn Ihr Webhoster das nicht bereits kostenlos anbietet, können Sie das Zertifikat auch über Let’s Encrypt erhalten.

Das Schriftarten-Thema

Viele Websites nutzen aus dem Internet eingebettete Schriftarten, sei es Google Webfonts oder Adobe Typekit und andere. Ein Schritt dabei, das Verstreuen von Datenspuren Ihrer Nutzer zu unterbinden, ist es, diesen externen Aufruf zu eliminieren. Denn damit wird mindestens die IP-Adresse des Nutzers an die Systeme übertragen und IP-Adressen sind nach aktueller Auffassung personenbezigene Daten (bzw. sollten sicherheitshalber so behandelt werden, da es bei einigen Szenarien noch juristische Diskussionen gibt. Ich bin aber kein Jurist und wollte das Thema daher lieber komplett vermeiden).

Ein Hilfsmittel ist der Google Webfont Helper, mit sich die benötigten Schriftarten als Archiv herunterladen lassen. Diese werden dann einfach in ein Verzeichnis auf Ihrem Webspace entpackt. Nun muss nur noch der Verweis in allen Stylesheets (den .css Dateien) auf die lokale Kopie anstelle der externen URL geändert werden.

In Ihren Stylesheets sieht die EInbindung einer Schrift (hier am Beispiel von OpenSans von Google Webfonts) in etwa so aus:

@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: local('Open Sans Regular'), 
       local('OpenSans-Regular'), 
       url(https://fonts.gstatic.com/s/opensans/v15/mem8YaGs126MiZpBA-UFVZ0bf8pkAg.woff2) format('woff2'),
       url(https://fonts.gstatic.com/s/opensans/v15/mem8YaGs126MiZpBA-UFVZ0bf8pkAg.woff) format('woff');
}

Diese externe URL, die auf die Google Font-Server zeigt, ersetzen Sie nun durch den lokalen Pfad auf Ihrem Webserver, an dem die heruntergeladenen Schriftarten liegen. Beispiel (hier liegen die Schriftarten im gleiche Ordner wie die css-Dateien):

@font-face {
  font-family: 'Open Sans';
  font-style: normal;
  font-weight: 400;
  src: url('open-sans-v15-latin-regular.eot'); /* IE9 Compat Modes */
  src: local('Open Sans Regular'), 
       local('OpenSans-Regular'),
       url('open-sans-v15-latin-regular.woff2') format('woff2'), /* Super Modern Browsers */
       url('open-sans-v15-latin-regular.woff') format('woff'), /* Modern Browsers */
       url('open-sans-v15-latin-regular.ttf') format('truetype'), /* Safari, Android, iOS */
       url('open-sans-v15-latin-regular.svg#OpenSans') format('svg'); /* Legacy iOS */

Durchsuchen Sie alle CSS-Dateien nach entsprechenden Einträgen. Auch hier zeigt sich der Vorteil eines Generators wie Hugo: ich kann einfach mit einer Suche in meinem Homepage-Verzeichnis nach z.B. “font.gstatic.com” suchen und muss mir keine Gedanken über irgendwelche per PHP zusammengebastelte Stylesheets machen. Außerdem wird dadurch auch die notwendige Datenschutzerklärung kleiner, denn nun müssen wir uns um das Google-Thema keine Gedanken mehr machen. Wenn das erledigt ist, kommen als nächstes extern eingebundene JavaScript-Bibliotheken an die Reihe.

Scripts lokal hosten statt vom CDN laden

Fast jeder Webauftritt nutzt mittlerweile Javascript in irgendeiner Form. Unabhängig von der philosophischen Diskussion, ob Javascript nötig ist oder nicht, passiert hier bei einem Aufruf einer externen Bibliothek das Gleiche wie bei Schriftarten oder Social Media Plugins: es werden unter Umständen Daten Ihrer Besucher an die externe Quelle übertragen. Dazu suchen Sie in den Schablonen bzw. Themes Ihrer Seiten nach externen Scripts (also mit einer Quelle ausserhalb Ihrer Domain, erkennbar am Attribut src= und einer externen URL). Als Beispiel hier der Aufruf der sehr verbreiteten Bibliothek JQuery in einer HTML-Seite:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/2.2.4/jquery.min.js"></script>

Von dieser Quelle alden Sie nun das Script herunter und legen es in einen Ordner Ihres Webauftritts (das geht sehr einfach per Kommandozeile und wget oder curl oder zur Not per Browser). Anschließend wird die Quelle dee Scripts auf den lokalen Speicherort abgeändert:

<script type="text/javascript" src="/static/js/jquery.min.js"></script>

Auch hier gilt wieder den Gebot des Augenmaßes. Nicht alle externen Quellen sind böse. Aber die rechtlichen Anforderungen sind so, dass Sie vor dem Zugriff, bei dem Daten übermittelt werden könnten, das Einverständnis des Benutzers einholen müssen. Dazu reicht es übrigens nicht, einfach eine dumme Checkbox anzuzeigen mit einem “Ja, OK”. DerBenutzer muss laut DSGVO eine “informierte Entscheidung” treffen können, d.h. Sie müssen alle übertragenen Daten im voraus benennen und auch, was damit passiert. Darüber hinaus müssen Sie dieses Einverständnis dokumentieren! Also schön abspeichern, welcher Benutzer wann für was zugestimmt hat …

Das leidige Thema “Social Media Plugins”

Ein oft genutzter Ausweg aus der datenschutztechnischen Klemme bei Social Media Plugins sind die bisher oft verwendeten “2 Klick-Lösungen”. Diese werden von vielen Juristen als problematisch gesehen, sobald die DSGVO in Kraft tritt, siehe z.B. den Artikel “Datenschutzgrundverordnung: Endet die Ära der Social Media Plugins?” der IT-Recht Kanzlei München. Wie am Ende dieses Artikels auch beschrieben, kommt eine gute Alternative kommt vom Heise Verlag in Form des “Shariff”, mit dem Links datenschutzkonform geteilt werden können. Dieser Weg erfordert aber entweder Anpassung am Server bzw. den Einsatz eines entsprechenden Plugins (z.B. für WP), bietet aber eine sichere Möglichkeit, falls Share-Buttons genutzt werden sollen. Auch auf meinen Seiten finden Sie am Ende der Seite einen Link mit “Share”, der erst nach einem Klick die entsprechenden Links zu den Diensten anbietet und erst dann beim Klick auf diese Daten überträgt und diese aber extern wie im Heise-Artikel beschrieben aufruft, so dass keine Daten übertragen werden.

Was bei den 2Klick-Lösungen bzw. den anderen Ansätzen (mit Ausnahme des “Shariff”, zu den Details siehe den Link oben) noch dazu kommt: die DSGVO fordert naxh Art. 7 Abs. 1 DSGVO, dass der Webseitenbetreiber nachweisen muss, dass eine Einwilligung erteilt wurde. Das bedeutet also, mit der oft genannten Checkbox und einem “Abklicken” ist man nicht aus der Sache raus, denn dieser Klick muss im System sauber dokumentiert, mithin üblicherweise in einer eigenen Datenbank abgelegt werden. Dazu kommt, dass nach Art. 7 Abs. 3 der Widerruf der Einwilligung so einfach sein muss, “wie die Erteilung der Einwilligung”. Wenn also für den Widerruf erst eine persönliche Mail an den Betreiber der Seite erforderlich ist, widerspricht dies ebenso der DSGVO.

Aus diesem Grund kommt hier die steile These #2: weg mit den Share-Buttons, der Aufwand (auch beim Benutzen) ist höher als der Ertrag. Warum bin (nicht nur) ich der Meinung, dass der Verzicht auf Social Media Plugins der einfachste und sicherste Weg ist? Ein gute gebautes Blog besitzt für jeden Artikel einen Permalink, also eine URL, unter der genau dieser Artikel von aussen mit einer stabilen URL erreichbar ist. Alles, was ein Benutzer tun muss, ist es, den Link in die Zwischenablage zu kopieren (das geht ebenfalls fast überall mit einem Klick) und dann in der Social Media App seiner Wahl einzusetzen. Ist der Benutzer im Browser bereits beim entsprechenden Dienst angemeldet (was bei einer App auf dem Smartphone sowieso der Fall ist), dann muss nur noch der kopierte Link eingefügt werden. Tadaa! – alle erledigt, keine Daten wurden übertragen, alles ist sicher, ich muss keine Plugins pflegen und eine Datenschutzerklärung aktuell halten oder eine Auftragsdatenverarbeitungsvereinbarung abschließen. Dazu kommt, dass das Kopieren und Einfügen von Hyperlinks keine rocket science ist. Damit haben wir eine echte “win-win” Situation. Ich habe keinen Aufwand, der Benutzer ist sich sicher, dass ich keine Daten abgreife oder an irgendwelche Dienste übertrage und alle sind glücklich. Auf zum nächsten Punkt auf der Liste …

Keine iFrames

Gerade das Einbetten von externem Content wird mit der DSGVO ein Problem. So wird der Youtube-Player über einen iframe eingebettet und damit holen wir uns alles Mögliche ins Haus, was Google/Youtube für interessant befindet. Aus DSGVO-Sicht also ein No-Go. Ich verstehe, dass gerade das unproblematische Einbetten per iframe bisher eine beqeueme Lösung war, aber mein Ziel war es ja, keine Daten an Dritte zu übertragen. Daher fallen iframes zukünftig weg. Um den Besuchern der Seite dennoch einen halbwegs vertrauten Anblick für eingebundene Videos zu bieten, gibt es einen relativ leichten Weg. Über die URL https://img.youtube.com/vi/YOUTUBE-VIDEO-ID/0.jpg kann ich ein Thumbnail des Videos anfordern. Es gibt noch Aufrufe für kleinere oder höher aufgelöste Versionen. Mehr Informationen finden sich hier.

Was ich damit baue, ist ein Konstrukt, das dieses Thumbnail-Bild anzeigt, das gleichzeitig ein Links auf das eigentliche Youtube-Video ist (welches über die URL https://www.youtube.com/watch?v=YOUTUBE-VIDEO-ID erreichbar ist). Zusätzlich blende ich noch ein Youtube-Icon über die FontAwesome-Icons ein.

<!-- Beispiel für einen SHortcode mit Hugo (gohugo.io) -->
<!-- So auch für alle anderen CMS verwendbar, nur die Parameterübergabe anpassen -->
<div class="youtubevideo">
  <a href="https://www.youtube.com/watch?v={{ index .Params 0 }}" target="_blank">
    <img src="https://img.youtube.com/vi/{{ index .Params 0 }}/0.jpg">
    <div class="youtubeoverlay fas fa-youtube-square" />
  </a>
</div>

Das Ergebnis sieht dann so aus wie in meinem “Pseudo-Player” unten und öffnet das Youtube-Video in einem neuen Tab. Damit erfolgt keine Datenübertragung, wir haben nur externe Links. Da wir die Referer unterdrücken (s. weiter unten), erfährt Youtube auch nicht, wer das Video anfordert. Beim Abspielen in einem neuem Tab ist dann sichergestellt, dass die datenschutzrelevanten Verantwortlichkeiten bei Youtube liegen.

Über das target="_blank" wird ein neuer Tab genutzt, meine Seite bleibt damit offen. Alles in allem sicherlich nicht so “elegant” wie das Embedding per iframe, aber dafür aus Datenschutz-Sicht wesentlich besser. Wieder ein Punkt erledigt …

Update 2018-04-12 Beginn

Noch “schönere” YouTube-Links

Ich habe nach einer Diskussion auf Twitter gelernt, dass viele Betreiber von Blogs (wohlgemerkt, wir sprechen hier von privaten Blogs und Homepgaes als Zielgruppe) unbedingt gerne die Einbettung von Videos behalten würden, weil Besucher dann auf “ihrer” Seite bleiben. So, nun habe ich zwei Nachrichten, eine gute und eine unter Umständen weniger gute. Wie immer gibt es die weniger gute zuerst: die Besucher können weg, die müssen nur den Tab mit Ihrem Blog schließen. In dieser Hinsicht ist das Web wie ein Schaufenster: wenn der Inhalt nicht interessant genug ist, bleiben die Leute nicht stehen. Das gilt auch für diesen Blogpost, in den ich einiges an Arbeit gesteckt habe. Das kümmert aber jemanden nicht, der es nicht interessant findet. Dann muss ich halt interessantere Artikel schreiben. :-)

Nun zur guten Nachricht: es habe mit etwas Rumspielen eine Möglichkeit gefunden, die Videos noch etwas hübscher einzubinden als die oben gezeigte Methode. Je nach verwendetem Blog oder CMS-System ist dabei etwas HTML-Arbeit oder Anpassung an den Templates erforderlich, ist aber keine rocket scicence.

Das Prinzip: Hinter dem Bildlink mit dem Video-Thumbnail (das Bild wird über die gleiche URL wie oben erzeugt) steckt der Aufruf von ein paar Zeilen JavaScript. Die öffnen ein neues, etwas kleineres Fenster, in dem sich das Video öffnet. Jetzt bleibt die eigene Seite auf dem Desktop “unter” dem Video sichtbar. Nach dem Ansehen wird das Fenster mit einem Klick geschlossen und schon ist Ihr Besucher wieder da.

Hier das entsprechende Script, dass irgendwo auf der Seite untergebracht wird:

<script type="text/javascript">
	function yt(videoID) {
		url = "https://www.youtube.com/watch?v=" + videoID;
		window.open(url, 
			        "_blank", 
			        "innerHeight=360,innerWidth=480,top=200,left=200,toolbar=no");
	}
</script>

Als Parameter wird nur die VideoID übergeben, also z.B. lrCDaGuAITU. Das passiert innerhalb des Links. An dieser Stelle habe ich auch gleich das Overlay mit dem “Play”-Button von YouTube vereinfacht, weil es bei einigen Lesern Probleme mit ihren CMS-Templates gab. Man kann nämlich auch SVG direkt als Inhalt eines Bildes eintragen (über eine data-URL). Mehr Informationen finden Sie hier. Immer, wenn ich denke, ich habe HTML/CSS zumindest minimal verstanden, kommt das Zeug und tritt mir gegen das Schienbein…

Die Ersetzung für ein eingebettetes Video, das früher so aussah:

<iframe width="560" height="315" 
        src="https://www.youtube.com/embed/lrCDaGuAITU" 
        frameborder="0" 
        allow="autoplay; encrypted-media" allowfullscreen>
</iframe>

sieht jetzt dann so aus:

<a href="javascript:yt('lrCDaGuAITU')">
	<img src='data:image/svg+xml;utf8,<svg width="480" height="360" xmlns="http://www.w3.org/2000/svg"><g><title>background</title><rect fill="none" id="canvas_background" height="362" width="482" y="-1" x="-1"/></g><g><title>Layer 1</title><g stroke="null" id="svg_1"><path stroke="null" id="svg_2" fill=" #FF0000" d="m298.9,151.3c-1.4,-5.2 -5.5,-9.3 -10.7,-10.7c-9.5,-2.6 -47.5,-2.6 -47.5,-2.6s-38,0 -47.5,2.5c-5.1,1.4 -9.3,5.6 -10.7,10.8c-2.5,9.5 -2.5,29.2 -2.5,29.2s0,19.8 2.5,29.2c1.4,5.2 5.5,9.3 10.7,10.7c9.6,2.6 47.5,2.6 47.5,2.6s38,0 47.5,-2.5c5.2,-1.4 9.3,-5.5 10.7,-10.7c2.5,-9.5 2.5,-29.2 2.5,-29.2s0.1,-19.8 -2.5,-29.3z" class="st0"/><polygon stroke="null" id="svg_3" fill=" #FFFFFF" points="228.60000610351562,198.6999969482422 260.20001220703125,180.5 228.60000610351562,162.3000030517578 " class="st1"/></g></g></svg>' 
	     width="480" 
	     height="360" 
	     border="0" 
	     style="background:URL(https://img.youtube.com/vi/lrCDaGuAITU/0.jpg) center center black;" />
</a>

Aussehen tut das dann so (vieeel schönerer Play-Button ;-))

Update 2018-04-12 Ende

Update 2018-05-13 Beginn

Update 2018-05-13 Ende

Kommentarfunktionen – gibt es eine Alternative?

Viele Blogs erlauben keine Kommentare per Formulare mehr. Das bedeutet nicht, dass keine Kommentare mehr möglich sind. Wie bei mir ist eine Kontaktaufnahme per Mail oder Social Media (z.B. Twitter-DM) immer möglich und wenn der Kommentar konstruktiv ist, wird er in den Artikel eingebaut bzw. am Ende ergänzt (wie gesagt, das komplette Neugenerieren meine Blogs dauert ca. 2 Sekunden). Damit muss ich nach wie vor Kommentare prüfen, aber das müsste ich bei einem Formular auch. Ich bin damit aber aus der Verantwortung raus, dass jemand einen rechtlich bedenklichen Kommentar online stellt, nur weil ich einen Account mal freigeschaltet habe. Zusätzlich führt dies dazu, dass wirklich nur Leute Kommentare schreiben, die an einer Diskussion interessiert sind.

Es gibt sicherlich auch Methoden, das mit einem Kontaktformular zu erledigen, aber auch hier sind alle bisher weiter oben genannten Punkte hinsichtlich Erfüllung der DSGVO zu beachten. Die einfachste Art ist dabei noch ein “Mailto-Formular”. Also ein Webformular mit folgender Aktion:

<form action="mailto:you@yourdomain" method="get" enctype="text/plain">

Damit erfolgt die Zusendung des Formularinhalts per Mail (natürlich gelten auch hier die Regeln für das Einverständnis der Übermittlung personenbezogener Daten, die mit der Methode oben nicht anfallen, weil mich da jemand aktiv von seinem System kontaktiert). Auch hier gilt: nicht praktikabel für kommerzielle Seiten, aber das ist nicht die Zielgruppe. Allein die Implementierung eines Double Opt-Ins wäre mir einfach zu viel Arbeit für einen privaten Online-Auftritt.

Update 2018-04-12 Beginn
kein Blog muss an Vereinsamung sterben. Es gibt auch andere Möglichkeiten, Beiträge im Blog zur Diskussion zu stellen, ohne sich das ganze Thema Datenschutz aufzuhalsen. Einfach auslagern, den Link auf den eigenen Blogpost z.B. auf Reddit teilen, hier gibt es Communities von https://www.reddit.com/r/education/ über https://www.reddit.com/r/MacOS/ bis hin zu https://www.reddit.com/r/latin/ für alle Lateinlehrer unter meinen Lesern.

Die Diskussion wird sich meiner Meinung nach immer mehr in den Bereich der sozialen Medien verlagern. Das mag für einige Blogbetreiber bedauerlich sein, weil dann auf der “eigenen” Seite nicht mehr so viel los ist, aber die Diskussion ist nicht weg, sie findet nur an einem Ort statt. Und das Beste: keine Arbeit mit der DSGVO! :-)

Was noch dazu kommt (und was sich vielleicht jeder Betreiber eines Blogs mal ganz unabhängig vom Thema DSGVO fragen sollte): für mich als Leser vieler Blogs war immer problematisch, neue Kommentare mitzubekommen. Das endet dann mit mehr als 30 Accounts auf allen möglichen Blogs für die dumme Notification. Da liegt dann einer meiner Mailadressen rum, ich muss das in meinem Mailworkflow wieder behandeln und und und. So gesehen ist mir eine gewisse Zentralisierung der Diskussion ganz lieb.

<rant mode="on">
Natürlich wäre es schön, wenn es noch eine große Gemeinde von RSS-Nutzern gäbe und vor allem gute RSS-Reader. Danke an dieser Stelle an Google, dass sie den RSS-Reader beerdigt und eine funktioniernede Technologie mit großer Breitenwirkung in den Abgrund gestürzt haben.
<rant mode="off">

Update 2018-04-12 Ende

Anonymisierte Logs

Im Mai letzten Jahres hat der BGH festgestellt, dass auch dynamische IP-Adressen personenbezogene Daten sind. Damit müssen Betrieber von Webauftritten auch die Speicherung der Zugriffe in den Logfiles des Webservers überdenken. Um die Zuordnung zu unterbinden, kann z.B. das letzte Byte der IPv4-Adresse genullt werden, was viele Provider bereits jetzt anbieten. Damit bleibt für eine Auswertung immer noch genug übrig, die Datensätze sind aber damit nicht mehr einer Person zuzuordnen.

Der Einsatz von Analyse-Tools wie Google Analytics (hier nur als Beispiel, es gibt natürlich auch andere Systeme) ist aus meiner Sicht sehr bedenklich. Nicht nur aus dem oben genannten Grund und der damit nötigen Vereinbarung zur Auftragsdatenverarbeitung, sondern ich als Nutzer des Web möchte so wenig als möglich ausspioniert werden. Ganz ehrlich: wie viele Homepage-Betreiber, die GA beispielsweise bei einem gehosteten Paket von WordPress, Drupal oder anderen mitgeliefert bekommen, können damit kompetent umgehen und benötigen die zusätzlichen Möglichkeiten im Vergleich zu einer Auswertung der Serverlogs. Ich will ja nur wissen, welche meiner Artikel erfolgreich sind, welche Dateien wie oft abgerufen werden. Dafür reicht das Logfile des Webservers vollkommen aus, alles andere ist für einen privaten Auftritt Overkill.

Eine kleine Gegenüberstellung der beiden Ansätze findet sich hier auf StackExchange.

Referer Policy

Wenn Sie einen Link im Browser anklicken, dann wird der Browser im Normalfall die Adresse der gerade aktiven Seite an das Ziel des Links übertragen (der sogenannte Referer. Ja, mit einem “r”). Diese Information im Header des HTTP-Requests gibt also die vollständige Adresse preis, von der Sie kommen. Diese Information wird auch übertragen, wenn externe Quellen (z.B. Scripts oder Schriftarten) geladen werden. Was übrigens auch erklärt, warum ich weiter oben auch alle Scripts lokal kopiert habe.

Das ist ein datenschutztechnischer Alptraum (vor allem in Verbindung mit Cookies). Damit kann Ihr Surfverhalten nachvollzogen werden, es wird deutlich, dass Sie eine Seite für einen Versicherungsvergleich von der Seite einer Suchtberatung aus aufrufen und was Sie sich sonst noch alles ausmalen können. Weitere Informationen finden Sie in der Wikipedia. Sie sollten daher für Ihre Webseiten auf jeden Fall in den Templates (den Schablonen für die Erstellung der Seiten aus Ihren Artikeln) eine Headerzeile für eine sogenannte “Referer Policy” einfügen. Das ist eine Zeile im <head>-Kopfbereich der HTML-Seite mit folgendem Inhalt:

<meta name="referrer" content="no-referer">
oder
<meta name="referrer" content="same-origin">

Die erste Angaben unterdrückt die Weitergabe des HTTTP Referer komplett, die zweite Methode erlaubt das nur, solange sich der Ziel-Link in der gleichen Domain befindet (damit können Sie die Herkunft der Anfrage in Ihrem Webauftritt verwenden, aber externe Ziele erhalten diese Information nicht). Weitere Informationen dazu erhalten Sie z.B. im Mozilla Developer Network. Ich habe für meine Seiten die Option <meta name="referrer" content="same-origin"> gewählt.

Fazit

Ist es mehr Aufwand als 10 Minuten? Ja, definitiv. Ich habe bei dieser Umstellung auch wieder jede Menge Dinge gelernt. Wie immer gilt hier auch der schöne Spruch: “wenn Du etwas verstehen willst, versuche es jemand zu erklären”.

Ist es unmöglich oder zuviel Aufwand? Nein, ebenfalls definitiv nicht. Niemand muss meiner Meinung nach seine Seiten vom Netz nehmen.

Ist es schwieriger bei der Nutzung eines CMS oder Blogsystems wie WordPress, Drupal oder Typo? Ja, auf jeden Fall. Vor allem dann, wenn Sie bisher einfach die von Ihrem Provider gehostete Version oder eine Plattform wie blogspot genutzt haben. Komfort bedeutet bis zu einem gewissen Grad immer das Aufgeben von Optionen und Freiheiten.

Ich glaube aber, dass die DSGVO nicht nur Aufwand und Probleme verursacht, sondern durchaus auch eine große Chance ist. Denn zum ersten Mal sind alle Online-Angebote in der EU datenschutztechnisch geleichberechtigt. Services (z.B. im Bildungsbereich) aus anderen Ländern werden sich dann nutzen lassen, ohne immer alles erst mit den deutschen Regelungen abgleichen zu müssen. Auch datenschutztechnisch wächst Europa damit ein Stück weit zusammen.

Der Zwang, sich mit dem Thema als Betreiber einer Website oder eines Blogs zu befassen, hat auch etwas Gutes. Vieles, was aus Gründen der Bequemlichkeit oder weil es “cool” aussieht, bisher einfach eingebunden und genutzt wurde, wird jetzt einer kritischen Evaluierung unterworfen. Benötige ich für mein privates Blog wirklich die Analysewerkzeuge, die große Konzerne mit merhsprachigen Online-Shops nutzen? Soll ich wirklich die Daten meiner Besucher quer durch das Web blasen, nur weil es für mich einfacher ist? Wollen wir einfach Dinge benutzen, ohen zu wissen, welche datentechnischen Konsequenzen ihr Einsatz hat? Ich jedenfalls nicht (mehr). Ja, natürlich wird sich das Aussehen bzw. der Komfort etwas ändern. Aber wie bereits wieter oben bei den Social Media Plugins beschrieben bin ich der Meinung, dass das Kopieren und Einfügen einer URL in eine Social Media App einfach genug ist, um es dem Besucher meiner Seiten zuzumuten. Vor allem, wenn ich den Besuchern erklären, dass ich dies tue, um die Daten meiner Besucher zu schützen. Niemand wird IMHO da etwas dageben haben.

Epilog

Dieser Artikel ist “work in progress”. Ich werde nach und nach sicherlich noch Ergänzungen einfügen, den Artikel erweitern oder auf andere Tools verweisen. Sollten Sie Kommentare haben, kontaktieren Sie mich (die entsprechenden Social Media Links finden Sie links unter meinem Portrait). Wenn ich dann noch einen oder zwei Besucher überzeugen konnte, sich mit Generatoren für statische Seiten wie Hugo zu beschäftigen, umso besser.

Kommentare

Ein Kommentar von 3abda1e3efe874c2418d7c2802486ae596e73bfe193587728db70b2573bed5f0 im Mai 2018:

Hallo, danke für den super Beitrag. Eine Frage zur IP in Server-Logs, ein paar Mal habe ich die IP aus dem Access Log schon benötigt um Probleme, oder vor allem Attacken bzw unberechtigte Zugriffe herauszufinden. Was ist deine Meinung dazu? Ist das ein berechtigtes Interesse zumindest für ein paar Wochen die IP zu speichern?

Da ich kein Jurist bin, kann ich hierzu keine Auskunft geben. In diesem Fall sollte Auskunft bei Fachleuten geholt werden. Noch eine Anmerkung zum Aspekt “unberechtigte Zugriffe” per Analyse der IP-Adressen im Serverlog zu finden: da in der weit überwiegenden Zahl der Zugriffe dynamische IP-Adressen aus einem Provider-Pool vergeben werden, ist es IMHO nicht sinnvoll, aus einer in der Vergangenheit gesehenen IP bei einem erneuten Besuch auf den gleichen Benutzer zu schließen. Insofern ist dies wahrscheinlich sowieso ein stumpfes Schwert.

Ein Kommentar von e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 im Mai 2018:

Wo steht in der DSGVO, dass man den referer entfernen soll?

Folgt man dem in der DSGVO vorgegebenen Grundsatz der “Datenminimierung” bzw. “Datensparsamkeit” (z.B. Art. 5, Absatz 1), dann wird klar, dass alles an personenbezogenen Daten, was für eine Funktion nicht unbedingt notwendig ist, zu vermeiden ist. Nun ist der Referrer in einem HTTP-Request nicht unbedingt personenbezogen, aber dennoch lassen sich damit mit den heute verfügbaren Mitteln Informationen für ein Profiling gewinnen. Aus Rücksicht auf meine Besucher gebe ich daher bei einem Link zu einer externen Quelle nicht weiter, woher diese Anfrage kommt. Ich bin mir im Klaren darüber, dass mein kleines Blog nun bestimmt nicht wichtig genug ist, um Quelle für ein Profiling zu sein, aber es ist ein Anfang. Wwer denkt, dass sich aus Daten, die öffenltich auf Webseiten zu finden sind, keine interessanten Datenzusammenhänge destillieren lassen, der sollte sich diesen Artikel durchlesen und das Video ansehen: http://www.dkriesel.com/blog/2016/1229_video_und_folien_meines_33c3-vortrags_spiegelmining – danach denken Sie anders!

Ein Kommentar von e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 im Mai 2018:

Wenn ich nichts übersehen habe, wird doch sehr wohl noch Inhalt von Dritten geladen und zwar das Thumbnail von YouTube. Dabei wird ja schon mal die IP Adresse gesendet und niemand hält YouTube auf, bei der Gelegenheit ein Cookie zu setzen. Da hilft dann auch das lokale Hosten der Fonts nichts. Grundsätzlich stimme ich zu, dass es in der Regel einfach ist, die Datenerhebung auf ein Minimum zu reduzieren, aber es geht eben nicht, ohne Abstriche am Inhalt und dem Funktionsumfang zu machen.

Nein, natürlich hält YouTube niemand auf, ein Cookie zu setzen, das gilt generell für jeden HTTP-Request. Ich kann auch eine HTML-Seite anfordern und in der Antwort kommt ein Cookie-Header mit zurück. Das würde aber bei “einfachen” Hyperlinks keinen Sinn machen und natürlich sollte man bei einem solchen Ansatz auch erst einmal nachsehen, was da kommt. Geht ja auch ganz einfach: curl -o 'thumbnail.jpg' -v 'https://img.youtube.com/vi/xx7Lfh5SKUQ/1.jpg'. Das Ergebnis:

 % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 172.217.21.14...
* TCP_NODELAY set
* Connected to img.youtube.com (172.217.21.14) port 443 (#0)
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0* TLS 1.2 connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate: *.google.com
* Server certificate: Google Internet Authority G3
* Server certificate: GlobalSign
> GET /vi/xx7Lfh5SKUQ/1.jpg HTTP/1.1
> Host: img.youtube.com
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Type: image/jpeg
< Timing-Allow-Origin: https://imasdk.googleapis.com
< Content-Length: 2306
< Date: Sun, 27 May 2018 13:39:45 GMT
< Expires: Sun, 27 May 2018 15:39:45 GMT
< ETag: "0"
< X-Content-Type-Options: nosniff
< Server: sffe
< X-XSS-Protection: 1; mode=block
< Cache-Control: public, max-age=7200
< Age: 22
< Alt-Svc: hq=":443"; ma=2592000; quic=51303433; quic=51303432; quic=51303431; quic=51303339; quic=51303335,quic=":443"; ma=2592000; v="43,42,41,39,35"
<
{ [873 bytes data]
100  2306  100  2306    0     0  17264      0 --:--:-- --:--:-- --:--:-- 17208
* Connection #0 to host img.youtube.com left intact

Wie sich zeigt, wird kein Cookie gesetzt. Es bliebe auch die Möglichkeit, die Vorschaubilder von einem server-seitigen Script vorzuladen und dann vom eigenen Server aus auszuliefern. Oder letzlich einfach einen Link auf das Youtube-Video zu setzen. Die Frage ist IMHO, ob die vorher vorhandene Funktion (das schöne Vorschaubildchen) die Nachteile aufwiegt. Es ist wie so viele eine Abwägung zweier Anforderungen…