Qbi's Weblog

Das Fediverse ist ein dezentrales Netzwerk, wo viele Dienste mittels des Protokolls ActivityPub miteinander kommunizieren können. Hierzu gibt es die schöne Grafik mit dem Baum des Fediverse' und seinen vielen Ästen:

Ein neuer Zweig kam kürzlich hinzu: Threads. Das ist ein Ableger des Meta-Konzern, besser bekannt als Facebook. Mit einem Account bei Instagram lässt sich auch Threads nutzen. Threads setzt auf ActivityPub und kann damit prinzipiell auch mit allen anderen Diensten Daten austauschen.

Nun entstanden Diskussionen, inwieweit dies gewollt ist und ob man Threads als Betreiber:in eines Mastodon- oder anderen Fediverse-Servers sperren solle. Mit einer Sperre ist eine Kommunikation mit Threads auf dem Server nicht mehr möglich. Als Argument wird Datenschutz und der “Vernichtungswille” von Großkonzernen angeführt. Da ich unter der Adresse Freie-Re.de auch einen Mastodon-Server betreibe, habe ich mir dazu auch Gedanken gemacht.

ActivityPub funktioniert als Protokoll im wesentlichen so, dass ein Beitrag in einen Postausgangskorb gelegt wird. Andere Server kommen vorbei und holen diese Nachricht ab. Andere Nutzer:innen werfen eine Nachricht in den eigenen Posteingangskorb und ich hole diese irgendwann dort ab. Das Ganze ist unten sowie auf der Wikipedia-Seite zu ActivityPub genauer beschrieben.

Wenn ich nun Beiträge schreibe, holt Threads diese wie alle anderen aus meinem Postausgang ab. Wie alle anderen, sieht der Server die Inhalte und einige andere Eigenschaften des Beitrages. Was dort genau hinterlegt wird, hängt vom konkreten Dienst ab. Mastodon legt keine zusätzlichen personenbezogenen Daten, wie IP-Adresse oder anderes, ab. Damit kann der fremde Server auch nichts mehr sehen.

Anders sieht es natürlich für die Nutzer:innen von Threads aus. Wer sich dort einen Account anlegt und die App nutzt, gibt eine Vielzahl an Daten an den Dienst. Dazu gehören laut App-Store Kontaktdaten, Standortdaten und viel, viel mehr. Das heißt, wer Bedenken hinsichtlich des Datenschutzes hat, sollte sich gut überlegen, ob ein Account bei Threads eine gute Idee ist.

Für Nutzer:innen aus dem Fediverse sehe ich hier jedoch keine größeren Gefahren. Die Daten, die eh öffentlich sind, können auch von Threads gelesen werden. Dadurch entsteht also kein zusätzliches Risiko.

Das zweite geäußerte Bedenken ist der “Vernichtungswille”. Viele große Konzerne und große Firmen verfolgen eine Strategie, die als Embrace, Extend und Extinguish bezeichnet wird. Das heißt, anfangs wird ein freies Protokoll oder eine freie Software gelobt und gern verwendet. Irgendwann gibt es dann Erweiterungen des Protokolls oder der Software, die nur für diejenigen nutzbar sind, die Kund:innen der Firma sind. Später werden dann alle Verbindungen in die “freie Welt” gekappt und das Produkt ist nur noch für Kund:innen nutzbar. Beispiele finden sich bei Google, Facebook und anderen Konzernen.

Der Ansatz ist auch hier zu befürchten. Das heißt, am Anfang gibt es eine Verbindung in das Fediverse und alle jubeln, dass Threads sich für ein freies Protokoll entschieden hat. Ich kann mir vorstellen, dass dann vielleicht Bilder und Videos nur in schlechter Auflösung ins Fediverse gelangen. Wer das Original sehen will, braucht ein Threads-Konto. Oder man kann nur mit den Accounts bei Threads interagieren, wenn man dort ein Konto hat. Hier könnt ihr eure Fantasie benutzen, wie sich das sinnvoll einschränken lässt, um andere zu Threads zu locken. Wenn dann genügend Leute Threads nutzen, kann die Verbindung ins Fediverse gekappt werden. Nutzer:innen sind dahin abgewandert und eventuell fristet das Fediverse dann ein Nischendasein. Das ist natürlich im Moment eine Vermutung und was genau passieren wird, weißt außerhalb von Meta niemand.

Ich halte es aufgrund der Beobachtungen anderer Firmen für eine erwartbare Entwicklung und für eine, auf die sich die Betreiber:innen einstellen sollten. Doch bringt ein Block von Threads hier etwas?

Wenn sich viele und insbesondere die großen Instanzen auf einen Block einlassen, würde das sicher etwas bringen. Dann fehlen Threads die initiale Zahl an aktiven Konten und sie müssen den Dienst irgendwie anders zum Laufen bekommen. Hier gibt es für den Konzern viele Möglichkeiten und ein Block wird sie einfach bewegen, anfangs einen anderen Weg zu nutzen.

Wenn sich jedoch nur ein kleiner Teil des Fediverse' zu einem Block durchringen kann, wird Threads weiter föderieren und vielleicht obigen Weg verfolgen. Sollte der Extinguish-Teil klarer werden, ließe sich vielleicht durch die Drohung, dass geblockt wird, Druck aufbauen.

Im allgemeinen bin ich der Meinung, dass weder ein präventiver Block noch ein späterer Block langfristig in dem Sinne etwas bringt, dass man den Konzern umstimmen kann. Hier wäre es wichtig, dass sich die Gemeinschaft der Betreiber:innen frühzeitig zusammenrauft und eigene Strategien entwickelt, wie mit der potenziellen Strategie von Threads umgegangen wird. Innerhalb dieser Strategie kann dann ein Block ein Baustein sein.

Aufgrund dieser Überlegungen habe ich mich daher entschieden, mit Threads zu föderieren und diese nicht zu blockieren. Derzeit überlasse ich das den Nutzer:innen. Wenn es irgendwelche anderen Gründe für einen Block geben sollte, würde ich die Gründe prüfen und aufgrund der Bewertung einen Block vornehmen, so wie das auch bei anderen mache.

Die Schulen im schottischen Bezirk North Ayrshire setzten Ende 2021 Gesichtserkennungssysteme ein, um Schulkinder zu erkennen. Das System sollte die Kinder identifizieren und denen dann die Teilnahme am kostenlosen Schulessen ermöglichen. Diese Praxis sorgte bereits für einige Kritik in UK-Medien und rief auch die dortige Datenschutzbehörde ICO auf den Plan.

Diese hat den Sachverhalt geprüft und kam zu dem Schluss, dass Gesichtserkennung in Schulen im Allgemeinen möglich ist. Allerdings hat der North Ayrshire Council (NAC) gegen verschiedene Bestimmungen in der DSGVO verstoßen. Konkret wurden folgende Punkte benannt:

• Grundsatz der Rechtmäßigkeit, Verarbeitung nach Treu und Glauben, Transparenz
• Informationspflicht
• Speicherbegrenzung
• Datenschutz-Folgenabschätzung

Der NAC wurde empfohlen bei der Datenminimierung und dem Grundsatz der Richtigkeit Verbesserungen vorzunehmen.

Die DSGVO schreibt im Erwägungsgrund 38, dass Kinder einen besonderen Schutz bei der Verarbeitung ihrer Daten genießen, da Kinder sich der betreffenden Risiken, Folgen und Garantien und ihrer Rechte bei der Verarbeitung personenbezogener Daten möglicherweise weniger bewusst sind.

Insbesondere wenn die Verarbeitung sehr tief in die Rechte und Freiheiten eingreift, so muss eine so genannte Datenschutz-Folgenabschätzung vorgenommen werden. Hierbei müssen die konkreten Risiken bewertet und Abhilfemaßnahmen eingebaut werden. Dies erschien der ICO im Falle der Schulen zwingend notwendig, war aber nicht vorhanden.

Die ICO hat sich die Anlage genauer angeschaut und versucht, eine Bewertung entlang der Pflichten der DSGVO vorzunehmen. Das Schreiben an die NAC liest sich wie eine Horrovorstellung.

• NAC were unable to demonstrate that there was a valid lawful basis for the processing.
  Zu gut Deutsch: Für die Verarbeitung gab es keine Rechtsgrundlage. Personenbezogene Daten dürfen aber nur verarbeitet werden, wenn es eine solche gibt. Anfangs wurde wohl behauptet, dass die Schulen Aufgaben des öffentlichen Interesses wahrnehmen. Später ist man dann umgeschwenkt und hat eine Einwilligung als Rechtsgrundlage herangezogen. Allerdings gab es eben keine wirkliche Einwilligung, die den Vorgaben der DSGVO entsprach. Die Eltern scheinen mehr so eine Art allgemeine Einwilligung abgegeben zu haben.
• Die Gesichtserkennung diente hier zur Identifizierung von Kindern. Das sind also biometrische Daten und damit besondere Kategorien personenbezogener Daten. Deren Verarbeitung ist im Art. 9 DSVGO nochmal explizit untersagt und hier gibt es eine Liste von Ausnahmen.
• Einwilligung für Kinder müssen in einem für sie verständlichen Text geschrieben sein. Die ICO schreibt, dass es in der Tat zwei verschiedene Einwilligungsformulare (Erwachsene und Kinder) gab. Der Unterschied zwischen beiden Formularen waren die Worte Ihr Kind und Du. Dazu muss man wohl nichts mehr sagen.
• Die ICO konnte nicht herausfinden, wann welche Daten wirklich gelöscht werden. Die NAC gab an, dass die Bilder fünf Jahre nach dem Ausscheiden oder am 23. Geburtstag der Person gelöscht werden. Warum gerade fünf Jahre ausgewählt wurden oder ob sowohl die Vorlage, die zur Erkennung genutzt wird wie auch die Einzelaufnahmen gelöscht werden, konnte nicht herausgefunden werden.
• Auch zur Datenschutz-Folgenabschätzung ist die ICO eindeutig: We consider that the DPIA we reviewed is unlikely to have complied with Article 35 of the UK GDPR

Insgesamt ist das Schreiben der ICO sowie die Case Study ein schönes Dokument, um mal zu erfahren, wie man es nicht macht. Allerdings schreibt die ICO auch sehr gut und detailliert, wie die Schulen es besser machen könnten.

Ich hoffe ja, dass die Schulen lernen und das System abbauen und nicht wieder benutzen. In Anbetracht der Tatsache, dass vorher dort wie auch an anderen Schulen in Schottland Fingerabdrucksysteme zum Einsatz kamen, habe ich da jedoch wenig Hoffnung.

Die Software Mastodon ist eine neue Erfolggeschichte aus meiner Heimatstadt Jena. Seitdem Elon Musk Twitter übernommen hat, suchen sich viele Menschen ein neues Social-Media-Zuhause und deren Wahl fällt sehr oft auf Mastodon. Andere gehen einen Schritt weiter, nehmen den Code von Eugen Rochko und bauen Server für sich und andere auf. Der Betrieb eines solchen Servers bietet einerseits einige technische Herausforderungen, aber aber auch viele aus dem nicht-technischen Bereich. Ich will in dem Beitrag mal den Augenmerk auf die Pflichten aus der Datenschutz-Grundverordnung (DSGVO) legen. Der Podcast Rechtsbelehrung hat kürzlich noch einen viel weitere Blick genommen. Hört mal in die Folge 112 zu Nutzungsbedigungen, Datenschutz und Digital Services Act rein.

Folgende Punkte gilt es zu beachten:

• Auftragsverarbeitung
• Sicherheit der Verarbeitung
• Betroffenenrechte
• Verzeichnis von Verarbeitungstätigkeiten

DSGVO?

Die erste Frage, die man sich stellen kann, ist, ob die DSGVO überhaupt relevant ist. Mit dem Betrieb eines Mastodon-Servers werden E-Mail-Adressen, Namen und anderes verarbeitet. All dies sind personenbezogene Daten. Damit ist die Verordnung anzuwenden.

Auftragsverarbeitung

Am Anfang steht die Frage, wo die Software installiert werden soll. Es könnte der eigene Server zu Hause sein, ein Raspberry Pi oder ein Server, der bei einem Provider in einem Rechenzentrum gemietet wird. In all diesen Fällen liegt die komplette Verantwortung in euren Händen. Hier müsst ihr euch später Gedanken zur Sicherheit machen. Aber hinsichtlich Auftragsverarbeitung können wir einen Haken machen. Denn dies ist nicht der Fall.

Wenn ihr ein “Fertigangebot”, wie masto.host, nutzt, dann beauftragt ihr eine fremde Firma mit der Verarbeitung der personenbezogenen Daten. Dies ist dann eine Auftragsverarbeitung. Damit müsst ihr sicherstellen, dass sich euer Anbieter auch an die DSGVO hält und auch ausreichende Sicherheitsmaßnahmen eingebaut hat. Die Anbieter haben für den Nachweis meist Listen mit technischen und organisatorischen Maßnahmen, Zertifikate oder anderes. Hier solltet ihr einen Blick drauf werfen und abschätzen, ob das euren Anforderungen genügt.

Der zentrale Punkt ist dann ein Vertrag zur Auftragsverarbeitung. Dieser Vertrag muss sich an die Vorgaben des Art. 28 DSGVO halten. Praktisch haben die Anbieter meist vorgefertigte Verträge, die ihr nur herunterladen und unterschreiben müsst.

Mit diesem ersten Schritt habt ihr die erste Hürde überwunden und könnt zur Installation oder Konfiguration des Servers schreiten.

Sicherheit der Verarbeitung

Beim Installieren und Einrichten des Servers (wie auch später im laufenden Betrieb) ist es sinnvoll, sich Gedanken über die Sicherheit zu machen.

Die DSGVO möchte ein angemessenes Sicherheitsniveau haben. Dies muss der Art der verarbeiteten Daten und dem Risiko entsprechen. Dabei muss der Stand der Technik und die Kosten der Einführung mit berücksichtigt werden. Doch welche Daten verarbeitet ihr? Soweit ich das sehe, sind das bei einem Mastodon-Server:

• Name und Profilname
• E-Mail-Adresse
• Passwort
• öffentliche Toots und “private” Nachrichten

Dabei sind Name, Profilname und öffentliche Toots Daten, die die Person mit der Verwendung des Dienstes auch veröffentlicht. Hier ist der Schutzbedarf eher gering. Meiner Meinung nach sind nur die E-Mail-Adresse, das Passwort und die privaten Nachrichten Daten, wo sich tiefergehende Gedanken über die Absicherung “lohnen”. Andererseits werden all diese Daten in einer Datenbank liegen. Somit ist es sinnvoll, die Datenbank als Ganzes zu betrachten.

Die konkreten Überlegungen hängen davon ab, wie ihr den Server betreibt, also steht der bei euch zu Hause oder im Rechenzentrum, läuft der auf einer eigenen Maschine oder auf einem Rechner, der von vielen anderen benutzt wird etc.? Mit den untenstehenden Fragen will ich ein paar Denkanstöße hinsichtlich von Sicherheitsmaßnahmen geben. Denkt mal bitte darüber nach, wie das bei eurem Server aussieht und ob dieser hinreichend abgesichert ist:

• Zugang zum Server: Ein Schutz besteht schon, wenn niemand den Server “anfassen” kann. Das heißt, Personen, die keine Berechtigung haben, sollten auch keinen physischen Zugang zu dem Gerät bekommen. Wie sieht das bei euch aus? Steht das Gerät in einem stark frequentierten Raum oder separat in einem abgeschlossenem Raum? Gibt es Fenster und Türen, durch die Menschen einfach an das Gerät kommen? Stellt euch einen Einbrecher vor und fragt euch, wie leicht oder schwer es dieser Person fallen könnte, direkt auf euren Server zuzugreifen. Anhand dessen könnt ihr euch dann Maßnahmen überlegen, die dies erschweren. Wenn es ein Server in einem Rechenzentrum ist, erübrigen sich diese Gedanken meist. Denn hier gibt es meist Zugangsrichtlinien, die kontrolliert werden und auf die ihr auch keinen Einfluss habt.
• Zugriff auf die Daten: Wenn es nun jemand zum Server geschafft hat, soll die Person möglichst keinen Zugriff auf die Daten bekommen. Dies könnte passieren, wenn diese Person vor dem Rechner steht und versucht, euer Passwort zu erraten oder über SSH Rateversuche unternimmt. Eventuell hat sich Schadsoftware auf der Maschine breit gemacht und liest Daten aus. Bei Überlegungen zu dem Punkt ist eure Kreativität gefragt. Auf welche Weise könnte ein Angreifer Zugriff auf eure Daten bekommen und wie unterbindet ihr das?
• Abhören der Daten: Beim Einloggen in den Server oder auch bei der Benutzung des Servers könnte es sein, dass Unbefugte versuchen, mitzuhören. Es wäre möglich, dass jemand eure Kommunikationswege (E-Mail, Messenger etc.) überwacht, um Daten mitzulesen. An der Stelle bruacht ihr ebenfalls Maßnahmen. In der Regel sind das verschiedene Verschlüsselungsmaßnahmen. Das heißt, die Webseite muss über TLS erreichbar sein, eure Mails und anderen Kommunikationen müssen mindestens transportverschlüsselt sein. Wenn ihr die Daten physisch umher tragt, solltet ihr ebenfalls über eine Verschlüsselung nachdenken.
• Verfügbarkeit der Daten und des Dienstes: Vermutlich gebt ihr keine Garantien hinsichtlich der Verfügbarkeit ab. Dennoch kann es schnell passieren, dass euer Dienst im Nirvana verschwindet. Hitze, Staub und Feuchtigkeit können dem Server zusetzen. Wenn der im Rechenzentrum steht, haben sich andere Gedanken gemacht. Wenn der Server auf euren Maschinen läuft, müsst ihr euch diese Gedanken machen. Weiterhin ist ein Backup ein wichtiger Schritt. Denkt darüber nach, wie die Datenbank und die einzelnen Dateien gebackupt werden können und testet regelmäßig die Wiederherstellung.

Ihr könnt natürlich noch viel mehr Maßnahmen einsetzen und den Schutz deutlich erhöhen. Die obige Aufstellung soll euch ein paar Anstöße liefern. Das Grundschutzkompendium des BSI ist u.a. eine Quelle, wo verschiedene Maßnahmen mit aufgelistet sind.

Rechte der betroffenen Personen

Die DSGVO gibt den betroffenen Personen einige Rechte. Diese sollen wissen, dass Daten von ihnen verarbeitet werden, welche das sind, wie lange etc. Die Rechte müsst ihr beim Betrieb eines Servers natürlich auch gewährleisten.

Datenschutzhinweise

Wenn Daten erhoben werden, beginnt für euch eine Pflicht, die Menschen zu informieren. Dies geschieht in der Regel über Datenschutzhinweise auf der Webseite. Der Artikel 13 der DSGVO enthält genaue Hinweise, welche Daten dort aufzuführen sind. Ich habe euch exemplarisch mal Hinweise anderer Instanzen verlinkt. Dort könnt ihr sehen, solche Informationen aussehen können.

• Datenschutzhinweise von legal.social
• Datenschutzhinweise von podcasts.social
• Datenschutzbestimmungen von mastodon.social
• Datenschutzhinweise von chaos.social

Auskunftsrecht

Nun können die betroffenen Personen jederzeit zu euch kommen und euch um eine Auskunft zu den verarbeiteten Daten bitten. Das bedeutet, zunächst müsst ihr prüfen, ob ihr überhaupt Daten dieser Person verarbeitet und falls ja, ist dann eine Auskunft zur Verarbeitung zu machen.

Wichtig ist hier zunächst, dass ihr einen solchen Antrag überhaupt wahrnehmt. Vermutlich werden sich die meisten über eine Mastodon-Nachricht oder eine E-Mail an euch wenden. Das heißt, ihr solltet sicherstellen, dass ihr regelmäßig eure Direktnachrichten und E-Mails lest. Denn ihr müsst spätestens innerhalb eines Monats nach Eingang auf die Nachricht reagieren.

Wenn ich davon ausgehe, dass jemand mit einem Mastodon-Konto auf eurem Server eine solche Anfrage stellt, so können die erforderlichen Angaben dem untenstehenden Verzeichnis der Verarbeitungstätigkeiten entnommen werden.

Sollte nun jemand ohne Account bei eurem Mastodon-Server eine Anfrage stellen, wird es spannend. Denn unter Umständen verarbeitet ihr auch dessen Daten. Soweit ich das sehe, müssten die folgenden Punkte mit in der Auskunft erwähnt werden. Bitte kopiert dies jedoch nicht einfach hier von der Seite, sondern prüft das nochmal nach. Wenn ihr zu einem anderen Ergebnis kommt, freue ich mich natürlich über eine Rückmeldung.

• Zweck der Verarbeitung: Betrieb eines Mastodon-Servers, Austausch und Kommunikation
• Kategorien personenbezogener Daten: Name, Mastodon-Benutzername, Uhrzeit des Beitrags, verwendete Software, Inhaltsdaten, (ggf. IP-Adresse und weiteres)
• Empfänger: Besucher:innen der Webseite, andere Mastodon-Benutzer:innen
• Speicherdauer: Hier musst du in deine Einstellungen schauen.
• Drittlandübermittlung: Wenn dein Server oder auch dein Anbieter außerhalb der EU agiert, wäre das hier mit zu erwähnen.
• Weiteres: Daneben musst du die User auf deren Rechte hinweisen. Genaueres siehe Art. 15 DSGVO.

Löschrecht

Neben einer Auskunft kann jemand auch die Löschung seiner Daten verlangen. Das könnte sowohl jemand mit als auch ohne Konto bei eurem Server sein. Im ersteren Fall wird ein Löschantrag sicher schwierig, denn die Person hat ja noch ein Konto. Damit wäre eine weitere Verarbeitung vermutlich notwendig und es gäbe keinen Löschanspruch.

Wenn jemand ohne Konto eine Löschung verlangt, wird es schon schwieriger. Diesen Fall diskutiert Enno Lenze auch in seinem Beitrag “Weg von Twitter, hin zu Mastodon?”.

Datenschutzverletzungen

Wenn euer Server gehackt werden sollte, so gibt es auch seitens der DSGVO Pflichten, die auf euch zukommen. Einerseits ist das eine Meldepflicht in Richtung der Aufsichtsbehörden und andererseits eventuell auch eine Information der betroffenen Personen.

Eine Datenschutzverletzung kann dabei vieles sein. Im Allgemeinen muss es sich um eine Verletzung der Sicherheit handeln, die zu

• Vernichtung
• Verlust
• Veränderung
• unbefugter Offenlegung oder
• Zugang durch Unbefugte

führt. Also wären

1. ein versehentliches Löschen der Datenbank,
2. Ransomware, die alle Daten verschlüsselt,
3. ein Datenbankdump, der auf der Webseite frei zum Download steht oder
4. ein “klassisch” gehackter Server

Beispiele für Datenschutzverletzungen. Es wäre sinnvoll, dass ihr euch immer mal wieder Gedanken macht, was in eurem Fall konkret Datenschutzverletzungen sein können. Oftmals stellt man fest, dass auch schon triviale Sachen in die Definition passen und gemeldet werden müssen.

Ich will die obigen Beispiele kurz diskutieren:

1. Wenn ihr für die Datenbank ein Backup habt, spielt ihr das ein und der Server läuft wieder. In dem Fall ist aus meiner Sicht kein besonderes Risiko für die betroffenen Personen entstanden. Daher gehe ich nicht von einer Meldepflicht aus. Allerdings solltet ihr gemäß Art. 33 Abs. 5 DSGVO den Vorgang dokumentieren. Also kurz aufschreiben, was passierte und was ihr gemacht habt.
2. Eine Ransomware, die nur die Daten verschlüsselt, könnte auch durch Aufspielen eines Backups “bekämpft” werden und der Fall wäre wie der oben zu behandeln. Allerdings müsst ihr sicherstellen, dass es keinen Fremdzugriff gab und das ist gerade bei aktueller Schadsoftware nicht der Fall. Das heißt, hier wird sehr oft auf die Daten zugegriffen, die heruntergeladen etc. In solch einem Fall liegen die personenbezogenen Daten in den Händen Fremder. Also besteht ein Risiko für die Betroffenen. Es empfiehlt sich eine Meldung an die Aufsichtsbehörden und ich würde hier sogar eine Meldung an die Betroffenen befürworten.
3. Wenn der Dump nur kurze Zeit auf der Seite war und ihr Fremdzugriffe ausschließen könnt oder wenn der Dump verschlüsselt ist, könnte man wie bei 1. auf die Meldung verzichten. Aber gerade wenn das nicht der Fall ist, wäre eine Meldung an die Betroffenen und die Aufsichtsbehörden Pflicht.
4. Ein gehackter Server ist immer ein Grund für eine Meldung an die Behörden. Es sei denn, ihr könnt durch spezielle Sicherheitsmaßnahmen im Vorfeld ausschließen, dass es einen Zugriff auf personenbezogene Daten gab.

In einer Meldung über eine Datenschutzverletzung muss folgendes stehen:

1. Art der Verletzung
2. Kategorien und Zahl der betroffenen Personen
3. ungefähre Zahl der Datensätze
4. Beschreibung der Folgen der Verletzung
5. Beschreibung der Maßnahmen, die ihr ergriffen habt.

Ich würde euch empfehlen, euch bereits vorher Gedanken über eine solche Meldung zu machen. Das macht es im konkreten Fall oft leichter, die Meldung abzusetzen.

Verzeichnis von Verarbeitungstätigkeiten

Ein recht “spannender” Punkt ergibt sich aus dem Art. 30 DSGVO. Demnach wäre ein Anbieter eines Mastodon-Servers verpflichtet, ein Verzeichnis von Verarbeitungstätigkeiten (VVT) zu führen. Das ist eine Auflistung von Vorgängen oder Prozessen bei denen personenbezogene Daten verarbeitet werden. In diesem Punkt steckt meist viel Detailarbeit. Beim Betrieb eines Mastodon-Servers müsste man zumindest die Verarbeitung durch den Server selbst sowie Kommunikation per E-Mail mit erfassen. Alles weitere hängt von euren Gegebenheiten ab. Ich habe untenstehend mal einen Versuch unternommen, die Einträge aufzuschreiben. Korrekturen sind herzlich willkommen.

VVT zum Serverbetrieb

• Name und Kontaktdaten des Verantwortlichen: Das solltet ihr leicht ermitteln können.
• Zweck der Verarbeitung: Bereitstellung einer öffentlichen Kommunikationsplattform auf der Basis des ActivityPub-Protokolls
• Kategorien betroffener Personen: Besucher:innen, Nutzer:innen
• Kategorien personenbezogener Daten: Name, Mastodon-Username, Uhrzeit, verwendete Software, Inhaltsdaten, Verbindungsdaten
• Empfänger: Andere Mastodon-Server, Dritte
• Übermittlung in Drittländer: keine (oder Nennung, falls ihr sowas einsetzt) oder, aufgrund des Charakters des Dienstes, immer
• Löschung der Daten: Nennung, wann ihr welche Daten löscht. Hier gibt es Unterschiede zwischen Nutzungsdaten, wie IP-Adresse, und Inhaltsdaten, wie Beiträgen.
• IT-Sicherheitsmaßnahmen: Nennung der Sicherheitsmaßnahmen, die ihr implementiert habt. Es ist meist besser, das in einem eigenem Dokument aufzuschreiben und darauf zu verweisen.

VVT für E-Mails

• Name und Kontaktdaten des Verantwortlichen: Das solltet ihr leicht ermitteln können.
• Zweck der Verarbeitung: Elektronische Kommunikation
• Kategorien betroffener Personen: Nutzer:innen, Dritte
• Kategorien personenbezogener Daten: Name, E-Mail-Adresse, Verbindungs- und Inhaltsdaten
• Empfänger: eventuell andere Admins des Dienstes (überlegt, wer die Mails noch “sieht”)
• Übermittlung in Drittländer: keine (oder Nennung, falls ihr sowas einsetzt)
• Löschung der Daten: E-Mails als Geschäftsbriefe 6 Jahre Aufbewahrung, E-Mails als steurrechtliche Unterlagen 10 Jahre Aufbewahrung
• IT-Sicherheitsmaßnahmen: Nennung der Sicherheitsmaßnahmen, die ihr implementiert habt. Es ist meist besser, das in einem eigenem Dokument aufzuschreiben und darauf zu verweisen.

Weiteres und Fragen

Beim Schreiben dieses Artikels fiel mir auf, dass es noch viel mehr Dinge geben könnte, auf die man ein Auge haben müsste bzw. es gäbe andere Spezialfälle, die man auch diskutieren könnte. Ich habe mich letztlich entschieden, diese wegzulassen. Falls du beim Lesen des Beitrags Fragen hast oder dir Themen fehlen, schreibe am besten einen Kommentar (oder nutze andere Wege). Ich versuche, darauf zu antworten oder den Beitrag entsprechend anzupassen.

Kürzlich stolperte ich über einen Tweet des Spitzenkandidaten der FDP, Thomas L. Kemmerich. Darin steht »Bei der DSGVO haben wir Maß und Mitte verloren. Hier muss Datenschutz bedeutend praxisnäher gestaltet werden für Fußballvereine, Ehrenamt und Handwerker. […]« Das wirft natürlich die Frage auf, wie er und sein Unternehmen es damit halten.

Kemmerich ist Vorstandsvorsitzender der Friseur Masson AG. Also besuchte ich die Webseite des Unternehmens und schaute mich dort um. Im Hintergrund lasse ich ein kleines Plugin laufen, welches mir Anfragen an andere Seiten anzeigt. Der weiße Punkt in der Mitte ist der Aufruf der Originalseite. Die Dreiecke weisen darauf hin, dass meine Daten noch an weitere Webseiten weitergegeben wurden. Insgesamt waren es 19 fremde Seiten. Darunter sind Unternehmen wie Facebook, Google, Doubleclick, Squarespace usw.

Was sagen denn die Datenschutzhinweise auf der Webseite? Laut der Datenschutz-Grundverordnung (DS-GVO) müssen Kontaktdaten des Verantwortlichen und die des Datenschutzbeauftragten (DSB) genannt werden. Doch die Kontaktdaten eines DSB sucht man auf der Seite vergebens. Heißt das, dass kein DSB benannt wurde? Die Friseur Masson AG wies im Jahresabschluss vom Jahr 2017 eine Zahl von 160 Beschäftigten aus. Das BDSG fordert schon ab 10 Personen, die ständig mit der automatisierten Verarbeitung personenbezogener Daten beschäftigt sind, eine solche Position. Da scheint es schwer vorstellbar, dass bei 160 Beschäftigten keine solche Pflicht anfällt.

Die Datenschutzhinweise gehen auf eine Weitergabe der Daten an Instagram und Google Maps ein. Ich konnte weder eine Erwähnung von Facebook, Google, Doubleclick, Alphabet, Squarespace oder anderen finden. Das heißt, ein argloser Besucher, der sich über die Datenverarbeitung informieren will, bekommt hier nur sehr halbherzige Informationen.

Das Analysewerkzeug Webkoll findet insgesamt 111 Anfragen an 17 eindeutige Rechner und 6 Cookies von fremden Quellen. Über all das schweigen sich die Datenschutzhinweise aus. Da muten sich die schwachen Algorithmen bei der TLS-Verschlüsselung fast wie eine Lappalie an.

Natürlich muss der obligatorische Satz in den Datenschutzhinweisen nicht fehlen:

Die Betreiber dieser Seiten nehmen den Schutz Ihrer persönlichen Daten sehr ernst. 

Wie ernst das zu nehmen ist, muss jeder für sich selbst entscheiden. Herr Kemmerich hat mit dem Tweet ein Indiz gegeben, wie ernst er es selbst mit dem Datenschutz meint.

Ende 2018 veröffentlichte die CNIL einige Statistiken zu deren Arbeitsaufwand durch die EU-Datenschutzgrundverordnung (DS-GVO). Ich fragte mich damals, wie das wohl bei den deutschen Aufsichtsbehörden so aussieht. Also fragte ich dort nach.

Ich schickte eine E-Mail an alle 16 Landesbehörden sowie an die Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI). In der Mail bat ich um Auskunft, wie viele Datenschutzbeauftragte gemeldet wurden, wieviel Datenschutzpannen bisher gemeldet wurden und wieviel Anfragen insgesamt eingetroffen sind. Wie sahen die Antworten so aus?

Anfragen

Alle Behörden antworteten durch die Bank, dass es einen enormen Anstieg der Anfragen gegeben hat. In einigen Fällen schrieb man von einer Verdrei- bis Vervierfachung der Anfragen. Leider erhielt ich nicht von allen konkrete Zahlen. Legt man die Meldungen mit Zahlen zugrunde, so liegt die Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen mit mehr als 10.000 Anfragen an der Spitze aller Bundesländer. Dies erscheint auch logisch, da das Bundesland entsprecht groß ist. Auf der anderen Seite sprach die Landesbeauftragte von Bremen von etwa 30 monatlichen Anfragen (ggü. durchschnittlich 18 vor dem Mai 2018). Sachsen als Flächenland meldete mir 776 Anfragen in den sechs Monaten von Mai bis November 2018 zurück. Das entspricht knapp 130 Anfragen pro Monat.

Beschwerden

Leider hatte ich in meiner E-Mail das Wort Anfragen verwendet. Bei der Beantwortung stellte sich heraus, dass zwischen einfachen Anfragen und Beschwerden unterschieden wird. So wurden beim TLfDI 284 Beschwerden angelegt und Hessen verzeichnete über 1200 Beschwerden.

Anzahl der gemeldeten Datenschutzbeauftragten

Mit der DS-GVO sind die Firmen verpflichtet, Datenschutzbeauftragte (DSB) an die Behörden zu melden. Hier interessierte mich, wieviel Meldungen bei den Behörden eingegangen sind. Das Bayerische Landesamt für Datenschutzaufsicht (BayLDA) meldete bereits im August die Zahl von 10.000. Im benachbarten Baden-Württemberg waren es mit 23.000 mehr als doppelt so viele. Aber auch hier liegt Nordrhein-Westfalen mit 24.800 DSB an der Spitze.

Beim BfDI gingen mit 1270 die wenigsten Meldungen ein. Ich würde vermuten, dass auch da einige fehlgeleitete Meldungen darunter sind. Denn zumeist sollten die Meldungen im jeweiligen Bundesland abgegeben werden. Wie schon bei den Anfragen hat Bremen mit etwas mehr als 1500 die wenigsten Meldungen zu verzeichnen. Schaut man in die anderen Bundesländer so haben das Saarland (knapp 2100) und Sachsen-Anhalt (2100) recht wenige erhalten. Aber auch der Freistaat Thüringen liegt mit ca. 3550 Meldungen weit hinten.

Meldungen zu Datenpannen

Wenn es zu Problemen bei der Verarbeitung personenbezogener Daten kommt, so muss gegenüber den Behörden eine Meldung abgegeben werden. Das heißt, wenn Seiten gehackt, Daten unbefugt gelöscht werden oder es andere Probleme mit der IT-Sicherheit gibt und dabei Risiken für die Menschen entstehen, entsteht eine solche Pflicht. Hier hatte mich interessiert, wieviele Meldungen entstanden sind.

Mit Abstand die meisten Meldungen gingen beim BfDI ein. Dort wurden knapp 4700 Meldungen verzeichnet. Hier wäre eine Übersicht nach einzelnen Bundesländern interessant. Denn vermutlich stammen diese aus dem kompletten Bundesgebiet.

Das BayLDA kommt dann an Platz 2 und hat mit 2005 weniger als die Hälfte der Meldungen des BfDI. Die Anzahl der Meldungen auf Platz 3 (NRW) halbiert sich dann noch einmal (1032). Baden-Württemberg (> 700) und Hessen (640) werden auf die weiteren Plätze verwiesen.

Auf den hinteren Plätzen liegen wiederum Bremen (29), Sachsen-Anhalt (>50), Saarland und Thüringen (<70).

Neben den reinen Zahlen würde mich eine Statistik über die Inhalte der Datenpannen interessieren. Auch fände ich es schön, die Zahl im Verhältnis zu den Firmen im jeweiligen Bundesland auszuwerten.

Sonstiges

Bei den obigen Zahlen fehlen zwei Bundesländer. Der Landesbeauftragte für Datenschutz und Informationsfreiheit Mecklenburg-Vorpommern schrieb mir zurück, dass aufgrund des Arbeitsaufkommens eine Antwort nicht möglich sei. Vom Hamburgischen Beauftragten für Datenschutz und Informationsfreiheit erhielt ich bis zum heutigen Tag keine Rückmeldung.

Der Thüringer Landesbeauftragte für den Datenschutz und die Informationsfreiheit (TLfDI) verschickte in den letzten Tagen eine freiwillige Umfrage an 17.000 Thüringer Unternehmen. Wie der MDR berichtet, soll damit ein besserer Überblick über den Datenschutz und die Umsetzung der DS-GVO in Thüringen erreicht werden. Mich haben auch schon einige Unternehmen angesprochen, die den Bogen erhielten und wissen möchten, wie sie sich verhalten sollen.

Die Teilnahme ist freiwillig. Das heißt, Unternehmen können sich selbst entscheiden, ob sie teilnehmen wollen. Dr. Hasse sagte dem MDR, dass er aber auch eine verpflichtende Umfrage in Erwägung zieht, sofern zu wenige Anworten kommen.

Unternehmen haben für die Antwort eine Woche Zeit. Ich finde diese Frist recht kurz. Gerade in der Weihnachtszeit liegen meist die Prioritäten an anderer Stelle und so landete das Schreiben in vielen, mir bekannten Fällen entweder im Papierkorb oder auf einem Stapel von später zu bearbeitenden Vorfällen. Meine Vermutung ist, dass der Rücklauf bis Weihnachten eher dürftig ist. Eine längere Antwortfrist wäre hier durchaus angemessen gewesen.

Der Fragenbogen (lokale Kopie) gliedert sich in sieben Teile:

1. Datenschutzbeauftragter (DSB)
2. Verzeichnis von Verarbeitungstätigkeiten
3. Rechtsgrundlagen nach Art. 6 DS-GVO
4. Informationspflichten
5. Betroffenenrechte
6. Datenschutz-Folgenabschätzung
7. Auftragsverarbeitung

Dies sind auch wichtige Bereiche im Rahmen der Umsetzung der DS-GVO, die von allen Unternehmen berücksichtigt werden sollten. Einzig das Thema IT-Sicherheit spiegelt sich nicht in der Umfrage wider.

Viele Unternehmen fragen sich nun, ob es Probleme bei der Beantwortung des Fragebogen gibt. Ich würde ja erwarten, dass Unternehmen den Fragenbogen nur dann beantworten, wenn sie sich Gedanken zum Datenschutz gemacht haben. Andere werden vermutlich die Freiwilligkeit eher so auslegen, dass die den nicht abschicken. Die offene Frage ist nun, wo Probleme bei den Antworten entstehen können.

Datenschutzbeauftragter

Im Bereich zum Datenschutzbeauftragten versuchen die ersten vier Fragen zu eruieren, ob es eine Pflicht zur Benennung eines DSB gibt und die fünfte Frage klärt dann, ob ein DSB ernannt wurde.  Wenn es hier ein Unternehmen gibt, welches einerseits die Pflicht zur Benennung eines DSB hat, andererseits aber keinen ernannt hat, wäre das aus meiner Sicht ein eindeutiges Signal, genauer hinzuschauen. Als Behörde würde ich hier mal genauer hinschauen.

Gerade Unternehmen, die sich dieser Pflicht entziehen, fahren ein größeres Risiko. Denn der DSB muss der Behörde gemeldet werden. Eine Behörde könnte auf die Idee kommen, sich eine Auflistung aller Unternehmen mit mehr als 20 Beschäftigten (oder einer anderen Zahl) zu besorgen. Diese könnte mit der Liste der gemeldeten Verantwortlichen abgegllichen werden. Die Unternehmen mit mehr als 20 Beschäftigten ohne DSB könnte sich die Behörde zumindest genauer anschauen. Wenn man dann hier noch nach den Schwerpunkten unterscheidet (Eine IT-Firma mit den Kriterien wird eher einen haben müssen als ein Produktionsbetrieb.), ließen sich vermutlich recht schnell die Firmen ermitteln, die einen DSB haben müssen, aber keinen haben.

Die Fragen 6 und 8 überschneiden sich, denn Frage 6 möchte wissen, ob es einen externen DSB gibt, während Frage 8 sich nach einem internem erkundigt. Dies hätte in einer Frage abgehandelt werden können. Ich verstehe hier nicht, warum dies auf zwei Fragen verteilt wurde bzw. was passiert, wenn beide mit Ja beantwortet werden.

In der siebenten Frage soll angekreuzt werden, ob der DSB eine natürliche oder juristische Person ist. In verschiedenen Kommentaren zur DS-GVO wurde immer wieder angemerkt, dass der DSB eine natürliche Person sein sollte. Begründet wird dies nach meiner Erinnerung insbesondere mit dem Fachkundenachweis. Den kann eine natürliche Person führen, für eine juristische wird das schon schwerer.

Die folgenden Fragen beschäftigen sich dann auch mit der Fortbildung. Hier wird gefragt, wann die letzte Fortbildung war. Gerade im Hinblick auf den 25. Mai 2018 sollte die letzte entweder in diesem oder im vorigen Jahr liegen. Ansonsten sollte man sich schon fragen, wie der DSB seine Fachkunde erworben hat.

Frage 13 und 14 möchte wissen, ob der DSB gemeldet und veröffentlicht wurde. Beides sind Pflichten nach der DS-GVO.  Dies sollten die betreffenden Unternehmen also getan haben, wenn sie einen DSB ernannt haben.

Verzeichnis der Verfahrenstätigkeiten

Zunächst wird die Existenz abgefragt. Nach meinem Eindruck müssen 100% der angefragten Unternehmen ein solches Verzeichnis haben. Sollte hier jemand Nein ankreuzen, würde ich das als Gelegenheit nutzen, um genauer nachzufragen. Die nächste Frage möchte nur wissen, ob die bereitgestellten Formulare hilfreich waren.

Erlaubnistatbeständen nach Art. 6 DS-GVO

Die erste Frage möchte wissen, ob jedem Vorgang ein Erlaubnistatbestand zugeordnet werden kann. Das Datenschutzrecht sagt nun, dass alle Verarbeitung personenbezogener Daten verboten ist, es sei denn, es gibt eine Erlaubnis. Das heißt, ein Nein würde hier klar zum Ausdruck bringen, dass das Unternehmen Daten rechtswidrig verarbeitet.

Die weiteren Fragen klären, bei welchen Erlaubnistatbeständen es Probleme gab und wie die Einwilligung eingesetzt wird. Soweit ich es beurteilen kann, haben Leute eher mit der Interessenabwägung Probleme. Nach der landläufigen Meinung würden viele jeden Vorgang über eine Einwilligung regeln. Hier wäre ich sehr gespannt auf die Antworten der Unternehmen.

Informationspflichten

Beim Abschnitt zu Informationspflichten wird gefragt, wie diese umgesetzt werden. Hier gibt es eine Liste mit fünf Möglichkeiten. Die zweite Frage zielt auf die Webseite ab und will wissen, ob die überarbeitet wurde, um Informationspflichten zu erfüllen. Wenn ich ein halbes Jahr (oder etwas länger) zurück denke, so steckten dort viele Unternehmen Aufwand hinein. Wer dies andererseits nicht getan hat, der hat eine wesentliche Pflicht aus der DS-GVO nicht erfüllt.

Betroffenenrechte

Bezüglich der Betroffenenrechte wird nach einem Prozess für die rechtzeitige Bearbeitung der Anfragen und zu eventuell aufgetretenen Problemen gefragt. Hier würde ich keine Probleme erwarten, egal wie geantwortet wird.

Datenschutz-Folgenabschätzung

Dem schließen sich Fragen zur Datenschutz-Folgenabschätzung (DSFA) an. Hier frage ich mich insbesondere, wie die Antwort auf die dritte Frage gewertet wird. Das TLfDI möchte wissen, ob der DSB (sofern benannt) einbezogen wurde. Das Wort “einbezogen” klingt für mich eher passiv und würde der DS-GVO entsprechen. Denn der Art. 35 Abs. 2 DS-GVO sagt, dass der Rat des DSB einzuholen ist. Das heißt, falls überhaupt eine DSFA durchgeführt wurde, so sollte der DSB mit einbezogen worden sein. Antwortet man hier jedoch Nein, stellt sich für mich die Frage, warum nicht. Die Antwortmöglichkeit “nicht zutreffend” wirft bei mir weitere Fragezeichen auf. Denn einerseits könnte dies angekreuzt werden, wenn keine DSFA durchgeführt wurde. Wenn jedoch eine durchgeführt wurde, so würde ich das nur ankreuzen, wenn es keinen DSB gäbe. Dies kann aber wiederum ein Verstoß gegen § 38 Abs. 1 BDSG-neu sein.

Auftragsverarbeitungsverträge

Der letzte Abschnitt möchte wissen, ob bestehende Auftragsverarbeitungsverträge an die DS-GVO angepasst wurden und ob die Formulierungshilfe nützlich war. Die Erneuerung von Auftragsverarbeitungsverträgen war einer der Hauptaufwände, die ich bei verschiedenen Unternehmen sah. Nach gängiger Ansicht mussten auch alle erneuert werden. Was kreuzt aber ein Unternehmen an, welches nur einige, aber nicht alle erneuert hat? Oder was kreuzt ein Unternehmen an, welches keine solche Verträge hat? Gerade im letzten Fall läge hier nahe, Nein auszuwählen. Wenn ich eine Behörde wäre, würde ich bei einem Nein jedoch wiederum stutzig werden.

Abschluss

Insgesamt bietet der Fragebogen aus meiner Sicht einige Stolperfallen. Ich würde erwarten, dass Unternehmen, die sich bisher nicht um die DS-GVO gekümmert haben, den Fragebogen eher links liegen lassen. Allerdings fände ich es wunderbar, wenn diese Unternehmen zumindest den Fragebogen als Anstoß nehmen, um sich mit den Pflichten nach der DS-GVO auszusetzen.

Die französische Datenschutzbehörde CNIL hat sich kürzlich zum Arbeitsaufwand seit der Anwendbarkeit der Datenschutz-Grundverordnung (DS-GVO) geäußert. Die Zahlen finde ich recht beeindruckend.

Sie schreiben, dass im Gesamtjahr bisher 9.700 Beschwerden eingegangen sind. Davon sind etwa 6.000 seit dem 25. Mai entstanden. Das heißt, es gab einen enormen Anstieg der Beschwerden seit der Anwendbarkeit der DS-GVO.

Interessant finde ich auch die Zahl der gemeldeten Datenpannen. Sofern ich den Artikel richtig verstehe, gab es durchschnittlich sieben Meldungen am Tag oder insgesamt 1.000. Weiterhin gibt es 32.000 Datenschutzbeauftragte.

Der Bericht listet dann weitere Maßnahmen, die das CNIL gemacht hat. Insgesamt finde ich das sehr interessant und mich würde interessieren, wie die Lage in Deutschland ist. Vielleicht äußern sich die Aufsichtsbehörden in den nächsten Tagen.

(Übersetzung kam von Google Translate bzw. Deepl )