© etiamos, 123RF

Ist die DSGVO ist ein bürokratisches Monster, gegen das kein Webadmin ankommt? Falsch: Mit etwas XML, XSLT, PHP und Wissen kann jeder den Informationspflichten genügen und für mehrere Sites sich ähnelnde Texte aus einem Baukasten generieren. Nebenbei lässt sich lernen, wie ein PHP-Skript flugs XML bearbeitet.

Die DSGVO [1] treibt die Webadmins vor sich her. Medienberichte und eine Menge Schwarzmaler im Netz brachten Kleinbetriebe und Selbstständige sogar dazu, ihre Webseiten abzuschalten – irgendwer könnte ja abmahnen. Auch wenn die wettbewerbsrechtliche Grundlage für Abmahnungen wegen DSGVO-Verstößen stark umstritten ist, die deutsche Bundesregierung hektisch an einem Anti-Abmahngesetz bastelt und die Aufsichtsbehörden zurückrudern und sich von Bestrafern zu Beratern wandeln wollen, erscheint es doch richtig und wichtig, eine ordentliche Datenschutzerklärung auf die eigenen Webseiten zu packen.

Dass der Gesetzgeber, selbst für verschwurbelten Texte bekannt, in der DSGVO eine leichte Verständlichkeit der Datenschutzhinweise vorschreibt, wirkt ironisch. Gleichwohl dürfte klar sein, dass auf einer deutschen Webseite ein portugiesischer Text nicht als leicht verständlich durchgeht. Bei mehrsprachigen Sites braucht der Webadmin also mehrere Versionen. Verständlichkeit ist zumindest aus Sicht des Autors weiterhin mit Texten, die 18 Seiten lang und in feinstem Anwaltsdeutsch verfasst sind, kaum zu erreichen. Vielmehr sollte die Erklärung knapp und klar informieren.

Die schon von sich aus umfangreichen Pflichtangaben regelt Art. 13. Danach muss der Verantwortliche, also der Anbieter der Webseite samt gesetzlichem Vertreter (Geschäftsführer, Vorstandsvorsitzenden) und dessen Datenschutzbeauftragtem – soweit benannt – angegeben sein. Es ist zusammenfassend aufzuzählen, welche Daten der Betreiber zu welchen Zwecken auf welcher Rechtsgrundlage erhebt und wie lange speichert. Einige Juristen meinen, dass zur Nennung der Rechtsgrundlage die Angabe des Artikels der DSGVO nötig ist, also beispielsweise Art. 6, Nr. 1 lit. b.

Soweit man Daten an Dritte, dazu zählen nach Ansicht der Aufsichtsbehörden auch die Auftragsverarbeiter, weitergibt, sollen diese aufgelistet sein. Ob die Namen wirklich aller Auftragsverarbeiter nötig sind, ist allerdings noch nicht abschließend geklärt. Die meisten Aufsichtsbehörden gestatten zumindest bei vielen Verarbeitern eine Zusammenfassung. Bei gemeinsamer Verantwortung (Art. 26) erscheint es dagegen plausibel, alle Verantwortlichen zu benennen.

Ist ein Interesse berechtigt?

Die häufig unzureichend strapazierten “berechtigten” Interessen zur Datenerhebung müssen benannt und beschrieben sein. Für sie ist, wenn auch nicht in der Datenschutzerklärung, eine Rechtsgut-Abwägung erforderlich: Wie stehen sie im Vergleich zu den Rechten des Betroffenen? Die Datenschutzkonferenz hat in ihren Kurzpapieren [2] beispielsweise Tracking eine klare Absage erteilt. Die Werbeindustrie dagegen hält es aus berechtigten Interessen (!) für zulässig; ihre Rechtsgutabwägung dazu erscheint jedoch oberflächlich. Wer Apply Magic Sauce [3] kennt, weiß, was aus Trackingdaten alles zu erfahren ist.

Zudem müssen die Datenschutzhinweise dem Betroffenen seine Rechte vor Augen führen: Auskunft (Art. 15), Korrektur (Art. 16), Löschung (Art. 17) oder – soweit gesetzliche oder vertragliche Notwendigkeiten einer Löschung entgegenstehenden – Sperre (Art. 18). Bei einigen Sonderfällen gibt es zusätzliche Widerspruchsrechte (Art. 21) und das Recht auf Datenübertragbarkeit (Art. 20).

Letzteres dürfte vor allem für Foren und Social Media greifen, hat jedoch einen großen Haken: Was soll bei der Übertragung mit Posts von Freunden, Namensnennungen von Dritten sowie Bildern, auf denen andere zu sehen sind, passieren? Auch deren Daten würden weitergegeben. Außerdem ist das “standardisierte Dateiformat” nicht definiert.

Im Netz gibt es Generatoren für Datenschutzhinweise, beispielsweise [4]. Die sehen viele Datenschutzbeauftragte sehr kritisch. Auch aus anderem Grund kann der Gang zum Anwalt lohnen: Für eine einmalige Gebühr, für die er seine passend zusammengestellten Textbausteine verkauft, ist der Anwalt in der Haftung für seine Beratungsleistung und muss bei Mängeln in der Erklärung den Kopf hinhalten. Diesen Vorteil bieten die Generatoren nicht. (Ebenfalls ohne Haftung ist der auf [5] hinterlegte Mustertext.)

Ruf nach Automatisierung

Die Mindestinformationen, welche die Art. 12 bis 14 verlangen, sind für eine Firma mit mehreren ähnlichen Webauftritten eigentlich immer die gleichen – auch wenn die eine Site Cookies nutzt, die andere Gewinnspiele ausschreibt und auf der dritten ein anderer Geschäftsführer die Verantwortung trägt. Da erscheint es logisch, wenn der Datenschutzbeauftragte (siehe Kasten “Wer braucht einen Datenschutzbeauftragten?”) keine Lust verspürt, x-mal den nahezu gleichen Text Korrektur zu lesen oder nötige Textänderungen zu machen.

Also soll eine Automatisierung her, möglichst einfach, möglichst idiotensicher, leicht verteilbar und gesichert gegen Angreifer. Die Grundidee ist simpel: Eine zentrale Quelle hält alle Textbausteine vor, die irgendwo auf den Seiten auftauchen sollen. Jede Seite besitzt ihre Konfiguration, die vorgibt, welche Bausteine zu verwenden sind, sowie weitere Angaben enthält, wie die Daten des Verantwortlichen, des Datenschutzbeauftragten und so weiter.

Das Ganze könnte dann ein zentraler Server (à la »dsgvo.example.org«) ausliefern, ein CSS und notfalls eine XSL-Transformation verschönern das Design. Die jeweilige Seite kann die Ausgabe einfach verlinken oder zum Beispiel in ein Iframe einbinden, sodass das Ergebnis gut ins Seitenlayout passt. Solche Art Flexibilität war das Ziel für den Autor, als er sein Projekt GDPR [5] startete.

Modular aufgezogen

Für die Textbausteine in den einzelnen Sprachen denkt mancher gleich an eine Datenbank. Doch angesichts der geringen Datenmenge lohnt die kaum. Günstiger kommt eine XML-Datei, die alle Bausteine enthält. Das nötige XML ist schnell spezifiziert, neben den Bausteinen mit Sprachversion und eindeutiger Kennung bedarf es einiger grundlegender Formatierungen wie Überschriften. Als praktisch erweisen sich zudem Tags, die das Setup durch Inhalte aus Konfigurationsdateien ersetzen, beispielsweise den Firmennamen und -sitz oder den Geschäftsführer.

Listing 1 zeigt das Grundgerüst, eine vollständige Beispieldatei sowie passende DTD liegen auf der Projekt-Seite [5] bereit. Jedes »element« ist ein eigener Textbaustein, identifiziert über das Attribut »name«. Für jeden Baustein lassen sich Varianten in allen auf den Websites angebotenen Sprachen anfertigen.

Mehrmals übernimmt »insert« Daten aus dem Konfigfile, was es leicht macht, pro Site einen anderen Ansprechpartner anzugeben. In der Praxis hat es sich als hilfreich erwiesen, auf der Webseite neben dem Datenschutzbeauftragten noch mindestens eine weitere Kontaktadresse zu nennen, etwa einen allgemeinen Ansprechpartner für die Webseite. Andernfalls wenden sich Leute mit jeder Art Problem an den Datenschutzbeauftragten – der gehört ja irgendwie zur Firma und wird meine Anfrage schon richtig weiterleiten.

Da schon die Textbausteine in XML beschrieben sind, bietet es sich an, für die Konfigurationsdateien, die pro Seite erforderlich sind, auch XML zu verwenden. Listing 2 zeigt eine solche Seitenkonfiguration auszugsweise, ein vollständiges Beispiel findet sich wieder auf [5].

01 <?xml version="1.0"?>
02 <!DOCTYPE gdpr SYSTEM "gdpr.dtd">
03 <gdpr>
04   <element name="org" lang="de">
05 <h1>Hinweise zum Datenschutz</h1>
06
07 <p><insert value="org/name" /><br />
08 <insert value="org/street" /><br />
09 <insert value="org/postcode" /> <insert value="org/town" /></p>
10
11 <p>Vertreten durch: <insert value="org/represented" /></p>
12   </element>
13
14   <element name="sitecontact" lang="de">
15 <p>Ansprechpartner für die Webseite: <br />
16 <insert value="site/name" /><br />
17 <insert value="site/email" /><br /></p>
18   </element>
19
20   <element name="intro" lang="de">
21 <p>Wir verarbeiten Ihre Daten im Einklang mit den gesetzlichen Anforderungen. ?</p>
22
23 <p>usw. usf.</p>
24   </element>

01 <?xml version="1.0"?>
02 <!DOCTYPE config_gdpr SYSTEM "config.dtd" >
03 <config_gdpr>
04   <settings>
05    <h_level add="0" />
06    <use_individual_xsl use="false" />
07    <languages>
08      <language default="true">de</language>
09    </languages>
10   </settings>
11   <values>
12    <org>
13      <name>ACME Ltd.</name>
14      <street>42, North Sample Av.</street>
15      <postcode>0815</postcode>
16      <town>Sampling, S.A.</town>
17      <represented>CEO: John Doe</represented>
18      <email>info@example.com</email>
19    </org>
20    <site />
21    <dpo>
22      <name>D. Ata</name>
23      <email>dpo@example.com</email>
24    </dpo>
25    <authority>
26      ?
27    </authority>
28   </values>
29   <use>
30     <element value="org" use="true" />
31     <element name="sitecontact" use="false" />
32     <element name="intro" use="true" />
33     <element name="generaldata" use="true" />
34     ?
35   </use>
36   ?
37 </config_gdpr>

Frei ausgesucht

Ein Skript zu schreiben, das die beiden XML-Dateien zusammenführt und zu einer Seite wie in Abbildung 1 verarbeitet, gelänge in Perl genauso wie mit PHP, Python und anderen Sprachen – reine Geschmackssache. Der Autor entschied sich für PHP; Lesern, die eine Python- oder Perl-Variante umsetzen, gewährt er auf seiner Projektseite [5] mietfrei einen WG-Platz.

Abbildung 1: So kann das per PHP zusammengesetzte Ergebnis aussehen.

PHP kennt mehrere XML-Parser: Simple XML [6] und XML-Parser [7]. Für das angepeilte Ziel, ein robustes Parsing-Skript, das der Webadmin einmal entwickelt und nie mehr anzufassen braucht, reicht die PHP-Extention Simple XML leicht aus.

Ordentlich aufgeräumt

Im ersten Schritt fertigt sich Simple XML ein Speicherabbild der XML-Datei an, es enthält alle Bausteine. Jetzt heißt es aufräumen. In den Zeilen 3 bis 6 von Listing 3 sucht eine Xpath-Expression alle Sprachversionen, die nicht der gewünschten entsprechen, und wirft sie raus. Das Skript sucht hier nach allen Tags, deren Attribut »lang« nicht den Wert der im Konfigfile gewünschten Sprachversion hat. Die Funde streicht »unset()« einfach aus dem Speicherabbild.

Dann heißt es, aus dem Konfigfile die geforderten Bausteine holen – alle anderen können weg. Die Zeilen 10 bis 13 vollführen dazu einen Kunstgriff: Eine Xpath-Suche im Konfigfile findet alle Elemente, die als nicht zu benutzen markiert sind (deren Attribut »use« »false« ist). Mit dieser Element-Liste erfolgt eine Xpath-Suche in der Datenschutzerklärung.

01 [...]
02
03 foreach ($gdpr->xpath("/gdpr/element[@lang!='$use_lang']") as $notused)
04   {
05     unset($notused[0][0]);
06   }
07
08 [...]
09 foreach ($config->xpath("/config_gdpr/use/element[@use='false']/@name") as $notused)
10   {
11     unset($gdpr->xpath("/gdpr/element[@name='$notused']")[0][0]);
12   }
13
14 [...]
15 if (isset($config->xpath("/config_gdpr/values/".$insert["value"])[0]) )
16   {
17     $insert[0]= $config->xpath("/config_gdpr/values/".$insert["value"])[0]->__toString();
18   }
19
20 [...]
21 $gdpr_xml = preg_replace("~</?((element)|(insert))( .*?\")*?>~","",$gdpr->asXML());
22
23 [...]

Richtig angeheftet

Um in den Textbausteinen fallweise Text einzusetzen, das Datum der letzten Änderung, den Namen des Datenschutzbeauftragten und so weiter, gibt es eigene Tags. Die muss das Skript nicht einmal kennen, um sie sinnvoll zu ersetzen – bis auf wenige Ausnahmen dürfen die Werte im Konfigfile einfach mit gleichem Namen definiert sein (Zeilen 17 bis 20 in Listing 3). Zwei Ausnahmen sind das Datum der letzten Änderung und ein frei definierbarer Zusatztext, der unter »additional« steht. Das Datum der letzten Änderung übernimmt das Skript von der XML-Datei der Datenschutzerklärung.

Leider kann Simple XML nur innerhalb von XML-Tags ersetzen, sodass diese als Platzhalter stehen bleiben. Das wäre für ein ordentliches (X)HTML unschön. Zur Abhilfe stattet das Skript der Regular-Expressions-Welt eine Kurzbesuch ab: Mit »asXML()« wandelt Simple XML in der Zeile 24 die aktuelle XML-Repräsentation in einen String um, und »preg_replace()« befreit ihn von seinem Tag-Ballast. In ähnlicher Weise erhöht es aus ästhetischen Gründen den Level der Überschriften, sofern konfiguriert.

Passend aufgemöbelt

Damit aus der XML-Datei gepflegtes XHTML wird, geht es ihr noch mit einer XML Stylesheet Language Transformation (XSLT) an die Wäsche. Ein Beispiel für so ein Stylesheet zeigt Listing 4. Hier ist den gestalterischen Wünschen zusammen mit einem CSS schier keine Grenze gesetzt. Da der Webadmin im Konfigfile für jede Seite ein gesondertes XSLT hinterlegen darf, kann er den einzelnen Datenschutzerklärungen nahezu jedes Design überstülpen.

01 <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
02   <xsl:output method="html" encoding="utf-8" indent="yes" />
03   <xsl:template match="gdpr">
04     <html>
05     <head>
06       <title>Datenschutz-Hinweis</title>
07     </head>
08     <body>
09       <xsl:copy-of select="node()" />
10     </body>
11     </html>
12   </xsl:template>
13 </xsl:stylesheet>

Einrahmen und installieren

Das PHP-Skript selbst sollte möglichst robust ausgelegt sein – bei Zugriffen ins Dateisystem, wie für das Konfigfile nötig, geht schnell was daneben. Denn die anzuzeigende Seite kommt als Parameter von außen, denen sollte der Admin bekanntlich besser nicht trauen.

Daher nutzt das Skript den übergebenen Seitennamen nicht unmittelbar, sondern ersetzt ihn über das assoziative Array »site_to_config« in einen Dateinamen. Das löst auf simple Weise das Risiko, dass jemand statt »main.xml« zum Beispiel »/etc/passwd« übergibt.

Vor der Installation ist zu überlegen, wo die Datenschutzerklärung lagern soll, das Skript soll ja mehrere Unternehmens-Websites bedienen. Das Ausliefern kann ein eigener Webserver (in der Art »dsgvo.example.com«) übernehmen. Es ist klug, nur das PHP-Skript in ein Verzeichnis zu tun, das der Webserver ausliefert. Alle anderen XMLs, XSLs und DTDs liegen außerhalb des Web-Root und sind für HTTP-Requests unerreichbar, was Information Leakages vorbeugt.

Der Verzeichnisbaum kann aussehen wie in Listing 5. »gdpr/www« ist das Document-Rootverzeichnis für »dsgvo.example.com«, nur hier greift der Apache zu, »gdpr/data« liefert er nicht aus. Wer ungern auf »dsgvo.example.com/gdpr.php?…« verlinkt, darf »gdpr.php« natürlich in »index.php« umbenennen – das interessiert das Skript selbst nicht.

Wer die Verzeichnisse wie vorgeschlagen wählt, sollte in »$default_path« das korrekte Verzeichnis zu den Konfigurationsdateien eintragen und prüfen, ob der Webserver-Prozess die nötigen Leserechte hat, Schreibrechte braucht er nicht.

01 gdpr/
02   +-www/
03   | +- gdpr.php
04   + data/
05     +- gdpr.xml
06     +- gdpr.dtd
07     +- gdpr.xsl
08     +- config.dtd
09     +- config_site1.xml

Geht doch

Der Artikel zeigt: Webadmins und Datenschutzverantwortliche brauchen sich von der DSGVO nicht in die Knie zwingen zu lassen. Vor der einfach zu handhabenden technischen Umsetzung der Informationspflichten sind freilich diverse Fragen zu klären zur bisherigen und künftigen Datenverarbeitung (siehe Kasten “Basismaßnahmen”). Am Ende jedoch greift Zahn in Zahn.