Skip to content

Einbindung von Flickr doch konform zur DS-GVO

GDPR
GDPR & ePrivacy Regulations von Dennis van der Hejden. Original bei Flickr

Vor kurzem stellte ich mir hier im Blog die Frage, ob man noch Bilder des Dienstes Flickr einbinden kann. Nach meiner Prüfung kam ich zu dem Schluss, dass dies nicht mehr der Fall ist und entfernte die Bilder aus meinem Blog.

Heute hielt ich einen Workshop, der u.a. auch die Datenschutz-Grundverordnung zum Thema hatte. Dort fragte mich ein Teilnehmer, ob denn das Land Thüringen eine korrekte Datenschutzerklärung (DSE) hat. Der folgende Abschnitt brachte mich dann doch ins Staunen:

Flickr

Innerhalb unseres Onlineangebotes können Funktionen und Inhalte des Dienstes Flickr eingebunden sein. Flickr ist ein Foto- und Bilder-Dienst des amerikanischen Unternehmens SmugMug Inc. (67 E. Evelyn Ave, Suite 200
Mountain View, California, U.S.)Wenn Sie selber Flickr aktiv nutzen und ein Bild oder Video veröffentlichen, können wir ihn ebenfalls sehen, wenn Sie ihn jedermann zugänglich gemacht haben oder wenn wir Ihnen über Flickr folgen. Ebenfalls können wir Ihre Angaben auf Flickr sehen, wenn thueringen.de Ihrem Profil folgt. Einzelheiten zur Verarbeitung der Daten bei Flickr und den Sichtbarkeitseinstellungen entnehmen Sie bitte den Datenschutzbedingungen von Flickr bzw. Oath (ehemals Yahoo): policies.oath.com/ie/de/oath/privacy/index.html  

Das heißt, das Land Thüringen ist der Meinung, rechtmäßig Flickr-Bilder einbinden zu können. Wie kann das sein?

Weder Flickr noch Yahoo! noch eine der anderen Firmen steht bisher auf der Privacy-Shield-Liste. Und die Datenschutzbedingungen von Flickr gaben doch bisher auch nichts her. Aber: Unter anderen ist das Datenschutzcenter von Oath mit verlinkt. Dort steht gleich am Anfang:

Für Produkte oder Dienste von Oath, auf die ohne Anmeldung bei einem Account zugegriffen wird, gilt diese Datenschutzerklärung für diese Produkte und Dienste ab 25. Mai 2018.  

Flickr gehört mit zu Oath. Also gelten diese Bedingungen auch für Flickr. In der DSE steht drin, dass die Oath (EMEA) Limited in Dublin diese Dienste bereitstellt und damit wohl Verantwortlicher im Sinne der DS-GVO ist. Also werden die Daten von einem Unternehmen mit Sitz in der EU verarbeitet und die DS-GVO möchte ja den freien Verkehr personenbezogener Daten fördern (oder zumindest nicht einschränken).

Weiterhin erklärt Oath, dass sie die Standardvertragsklauseln der EU-Kommission verwenden bzw. nur Daten mit Unternehmen austauschen, die nach Privacy Shield zertifiziert sind.

Insgesamt scheint die Datenschutzerklärung den Anforderungen der Art. 13 und 14 DS-GVO zu entsprechen. Und auch inhaltlich ist es jetzt so, dass man wohl doch bedenkenlos Bilder von Flickr in seinem Blog einbinden kann.

Blog entflickt

In einem Beitrag vor ein paar Tagen kam ich zu der Ansicht, dass spätestens mit der Anwendung der Datenschutz-Grundverordnung am 25. Mai 2018 Flickr nicht mehr genutzt werden kann. Das bedeutete für mich, dass ich mein Blog auf Bilder prüfen muss, die über Flickt eingebunden werden. Soweit ich das sehe, ist das jetzt abgeschlossen. Es sollten keine Bilder mehr über Flickr und andere fremde Quellen kommen.

Weiterhin habe ich geprüft, ob ich bei YouTube-Videos die Domain youtube-nocookie.com verwende. Auch dies sollte jetzt der Fall sein. Damit kommen die Videos hier im Blog entweder von obiger YouTube-Seite oder von media.ccc.de.

Solltet ihr noch Sachen finden, die von woanders eingebunden werden, freue ich mich über einen Hinweis in den Kommentaren.

Kann man Flickr-Fotos noch einbinden?

Update: 11 Tage nach dem untenstehenden Blogpost hat sich die Lage doch grundlegend geändert. Ich habe in einem neuen Beitrag beschrieben, warum es mittlerweile doch rechtmäßig ist, Flickr-Bilder einzubinden. Daher kann der untenstehende Beitrag ignoriert werden.


Ich bin gerade dabei, mein Blog durchzuschauen, was ich an fremden Inhalten einbinde oder was nach den Bestimmungen der Datenschutz-Grundverordnung (DS-GVO) relevant wäre. Dabei fiel mir auf, dass ich an einigen Stellen den Fotodienst Flickr verwende. Das heißt, ich habe auf deren Seiten Bilder gespeichert und für Beiträge werden diese Bilder hier mit eingebunden.

Wie verhält sich dies nun nach der DS-GVO? Wenn jemand einen Blogbeitrag mit einem solchen Flickr-Bild besucht, dann sehe (oder im Sinne der DS-GVO erhebe) ich bzw. mein Server die IP-Adresse des Besuchers. Unter anderem zählt diese als personenbezogenes Datum. Durch den Abruf des Bildes werden diese personenbezogenen Daten in ein unsicheres Drittland übertragen. Denn Flickr gehört US-Firmen (Yahoo! bzw. SmugMug) und deren Server stehen in den USA. Nun sagt der Artikel 35 DS-GVO, dass die Daten trotzdem in solche unsicheren Staaten übertragen werden kann, wenn es ein angemessenes Schutzniveau gibt. Dies kann durch verschiedene Faktoren passieren. Im Falle der USA ist der so genannte Privacy Shield eine der Varianten. Die US-Unternehmen können sich zertifizieren lassen und in eine Liste eintragen. Steht ein Unternehmen auf der Liste, ist der erste Schritt getan. Da ein solches Unternehmen personenbezogene Daten in meinem Auftrag verarbeitet, wäre wohl noch ein Auftragsverarbeitungsvertrag abzuschließen und die Datenschutzerklärung entsprechend zu ergänzen.

Im Falle von Flickr suchte ich also nach einem Eintrag in der Liste beim Privacy Shield. Dort fand ich weder einen Eintrag zu Flickr noch zu Yahoo! oder SmugMug. Auch anderweitige Suchen brachten mich nicht weiter. Damit muss ich wohl davon ausgehen, dass Flickr eben nicht nach Privacy Shield zertifiziert ist. Jetzt könnte ich versuchen, einen Vertrag gemäß der Standardvertragsklauseln der EU mit Flickr abzuschließen. Ich halte es aber für fraglich, dass Flickr dies mit jedem seiner Kunden tun wird und dass dies auch bis zum 25. Mai 2018 unterschrieben ist.

Daher ist es wohl so, dass eben kein geeignetes Datenschutzniveau gewährleistet werden kann und damit auch keine Bilder von Flickr eingebunden werden können. Zumindest dann nicht, wenn man der DS-GVO folgen will. Das heißt für mich, dass ich dies jetzt ändern werde und die Bilder lokal ausliefere.

Natürlich bin ich kein Jurist. Das oben Geschriebene ist daher als Meinung eines informierten Laien zu verstehen. Falls ihr andere Argumente oder Meinungen habt, freue ich mich über Kommentare.

Onion Services zum Mitnehmen

Eines meiner Hauptthemen hier im Blog ist Tor bzw. die Anonymität. So versuche auch ich dogfooding zu betreiben, also Tor beim täglichen Browsen zu verwenden. Hin und wieder stoße ich dabei auf Probleme. Entweder ich stoße auf die CAPTCHAs von CloudFlare oder die Seite öffnet sich gleich gar nicht. In letzteren Fällen wird Tor aktiv ausgesperrt. Doch was tun, wenn man die Seiten dennoch per Tor besuchen will?

Zum Glück gibt es das »Darknet«. :-) Mittels Tor Onion Services ist es möglich, beliebige Seiten zu spiegeln. Das heißt, eine Rechner ruft die Seite auf und liefert das Ergebnis über eine Onion-Seite aus. Bei der praktischen Umsetzung hilft das Enterprise Onion Toolkit (EOTK).

Untenstehend findet ihr einige Onion Services, die ich für mich oder andere aufgesetzt habe. Wenn ihr weitere Wünsche habt, hinterlasst einen Kommentar. Ich erwarte, dass die Liste im Laufe der Zeit weiter wächst:

Ich erhielt eine Nachfrage, Wikipedia auch als Onion Service anzubieten. Die Seite lässt sich über Tor problemlos aufrufen und sperrt Bearbeitungen von Tor-Servern. Alec Muffett hat dies schon versucht und mir dringend abgeraten, dies ebenfalls zu tun. Hier erscheint es sinnvoller, Überzeugungsarbeit bei Wikipedia zu leisten.

Schreibt eure Provider wegen der Vorratsdatenspeicherung an!

Seit nun mehr als zehn Jahren wird um die Vorratsdatenspeicherung gerungen. Verordnungen und Gesetze wurden verabschiedet, Klagen dagegen bestritten und gewonnen. Es gab unzählige Demonstrationen und Aktionen gegen diese Form der Überwachung. Am 1. Juli 2017 soll es nun soweit sein, dass wieder ein Gesetz zur Vorratsdatenspeicherung eingeführt und umgesetzt wird. Auch hier gibt es einige laufende Verfassungsbeschwerden. Digitalcourage plant am 29. Juni 2017 Proteste gegen das Gesetz. Die SpaceNet AG klagte gegen das Gesetz und nun beschloss das Oberverwaltungsgericht des Landes Nordrhein-Westfalen, dass das Gesetz gegen europäisches Recht verstösst. Diese Entscheidung betrifft nur die SpaceNet AG. Andere Provider müssen entsprechend nachziehen. Um an der Stelle etwas Druck aufzubauen, will ich verschiedene Provider anschreiben und diese auffordern oder bitten, es der SpaceNet gleich zu tun. Unten findet ihr mein Musterschreiben. Ihr könnt es gern verwenden oder verbessern.

Sehr geehrte Damen und Herren,

das Oberverwaltungsgericht des Landes Nordrhein-Westfalen (OVG) hat mit Beschluss 13 B 238/17 vom 22. Juni 2017 entschieden, dass die zum 1. Juli 2017 umzusetzende Vorratsdatenspeicherung (VDS) gegen europäisches Recht verstößt. Damit wurde die Klägerin von der Speicherpflicht entbunden. Ich möchte Sie hiermit bitten, sich ebenso für die Grundrechte Ihrer Kundinnen und Kunden einzusetzen und eine ähnliche Entscheidung für Ihr Unternehmen zu erwirken.

Das Gesetz zur Einführung einer Speicherpflicht und einer Höchstspeicherfrist für Verkehrsdaten (VerkDSpG) verpflichtet Internetserviceprovider (ISP) spätestens ab dem 1. Juli 2017 anlasslos eine Reihe von Verkehrsdaten zu speichern. Diesem Gesetz geht die Richtlinie 2006/24/EG über die Vorratsspeicherung von Daten und die deutsche Umsetzung im Gesetz zur Neuregelung der Telekommunikationsüberwachung und anderer verdeckter Ermittlungsmaßnahmen sowie zur Umsetzung der Richtlinie 2006/24/EG zuvor. Das Bundesverfassungsgericht erklärte diese Regelungen in dem Urteil 1 BvR 256/08 vom 2. März 2010 für verfassungswidrig und damit nichtig. Am 8. April 2014 hob dann der europäische Gerichtshof (C-293/12, C-594/12) die Richtlinie auf, da diese gegen verschiedene Rechte aus der europäischen Grundrechtscharta verstößt.

Der deutsche Provider SpaceNet AG klagte nun gegen das im Dezember wieder eingeführte Gesetz und bekam am 22. Juni 2017 vor dem OVG NRW Recht. Das Gericht beschloss, dass die Vorratsdatenspeicherung gegen europäisches Recht verstößt. Die SpaceNet AG muss damit die VDS nicht umsetzen.

Das Urteil betrifft allerdings nur einen Provider. Ohne eine ähnlich gelagerte Entscheidung müssen andere ISP die VDS umsetzen. Daher möchte ich Sie bitten, sich für die Grundrechte Ihrer Kundinnen und Kunden einzusetzen und ein ähnlich gelagertes Urteil zu erwirken. Ich bitte Sie, mir mitzuteilen, ob Sie für Ihr Unternehmen derartige Schritte planen oder ob Sie ggf. anderweitig gegen die VDS vorgehen wollen.

Ich danke Ihnen vorab für Ihre Bemühungen und verbleibe

mit freundlichen Grüßen

Hoffen wir, dass sich möglichst viele Provider gegen die VDS stark machen und das Gesetz endlich gekippt wird!

Update: Golem berichtet, dass Vodafone keinen Eilantrag stellen will und Telefónica/O2 die Sachlage prüft.

Gedanken zur Sicherheit bei Wikipedia

Kürzlich fragte mich Sebastian Wallroth, ob ich nicht eine Folge seines Podcasts Wikistammtisch mit gestalten könne. Natürlich sagte ich zu und so entstand die Folge 14 der Sendung.

Das Thema sollte Sicherheit und Wikipedia sein. In der Sendung konzentrierten wir uns auf die Wikipedianer, die Texte lesen und editieren wollen. Dies sollte allen Menschen auf der Welt möglich sein. Daher war Tor und offene Proxys einer unserer Diskussionspunkte. Weiterhin sprachen wir HTTPS bzw. TLS kurz an. Passwortsicherheit und Mailverschlüsselung waren weitere Punkte, die wir ansprachen. Ich hätte natürlich noch viel länger zu dem Thema erzählen können. :-) Einige Punkte will ich untenstehend kurz erläutern.

Sicherheit in der Wikipedia für Anwender

Die meisten Menschen nutzen die Wikipedia, um Artikel bzw. Lemmata zu lesen. Einige bearbeiten Artikel. Aber es gibt unter den Leuten, die ich als Anwender sehe noch weitere Rollen:

  • Sichter: Diese Leute haben durch ihre Mitarbeit einen Vertrauensstatus gewonnen und deren Änderungen werden automatisch sichtbar. Weiterhin können sie Änderungen anderen anschauen und diese Änderungen als frei von Vandalismus markieren. Dadurch wird die Version auch unangemeldeten Besuchern angezeigt (siehe Gesichtete Artikel).
  • Administrator: aus der Hilfeseite:
    Sie haben die Möglichkeit, Benutzer zu (aktiven) Sichtern zu machen, ihnen diesen Status zu entziehen, Benutzer zu sperren und solche Sperren wieder aufzuheben. Außerdem können sie einzelne Versionen einer Seite löschen, so dass diese nur noch für Administratoren einsehbar sind.

    Das heißt, diese Benutzergruppe hat besondere Rechte. und darf insbesondere auf personenbezogene Daten zugreifen.

  • Bürokrat: Diese dürfen andere Benutzerrollen vergeben. Insbesondere dürfen sie auch Personen zu Administratoren ernennen.
  • Checkuser: Dieser Personenkreis kann sehr tiefgreifende Änderungen vornehmen und diese sollten ihren Zugang entsprechend stark schützen.
  • Daneben gibt es noch weitere Rollen. Diese unterscheiden sich aus meiner Sicht nicht großartig von einem normalen angemeldeten Benutzer.

Nicht angemeldete Anwender

Personen, die die Wikipedia besuchen, ohne sich ein Benutzerkonto angelegt zu haben, haben einige Anforderungen bezüglich der IT-Sicherheit. So wollen sie bei der Eingabe der URL http://de.wikipedia.org/ auch auf der Wikipedia-Seite landen.

Nach der Eingabe der URL macht das System zunächst eine DNS-Abfrage und erhält die IP-Adresse zurück. Diese Antwort kann natürlich gefälscht werden. Hier wäre es sinnvoll, wenn die Anfrage schon in einer gesicherten Form zurückkommt, so dass zumindest Fälschungen erkannt werden. Ich verweise mal auf die 33. Sendung des Datenkanals zu DNSSEC.

Nun versucht der Browser die Wikipedia-Seite zu besuchen. Wie ich beim Wikistammtisch erwähnte, erfolgt der die Eingabe zumeist per HTTP. Die diversen Wikipedia.org-Seiten sind einigen Browsern vorab bekannt und werden sofort per HTTPS geladen. Dies geschieht ohne das jemand eingreifen muss. Sollte ein Browser dieses Vorwissen nicht haben, so sagt der Webserver der Wikipedia, dass der Browser zur HTTPS-Version der Webseite wechseln soll. Die HTTPS-Version ist von einer externen Stelle (Certificate Authority) bestätigt und so wird versucht sicherzustellen, dass sich niemand zwischen die Verbindung mogeln kann. Damit ist nun eine Verbindung zu einer Seite aufgebaut, wo Anwender sicher sein können, dass es sich um die Wikipedia handelt. Ausnahmen hatte ich im Podcast beschrieben.

Wenn sich Personen auf den Seiten der Wikipedia bewegen, wollen sie die Inhalte sehen und weder Werbung noch Schadsoftware erhalten. Hier hat der Serverbetreiber eine Verantwortung sich um die Sicherheit der Server wie auch der Anwendung zu kümmern. Hin und wieder kommt es vor, dass in Server eingebrochen wird, um Schadsoftware zu verteilen. Ähnliches passiert bei Werbenetzwerken. Auch da wird gern versucht, über Werbung Schadsoftware zu verteilen.

Weiter gibt es in den USA die »Expectation of Privacy«, die sich aus dem Vierten Verfassungszusatz ergibt. Auch in Deutschland haben wir ein starkes Datenschutzrecht. Hier wäre es interessant zu wissen, welche personenbezogenen Daten die Wikipedia speichert und natürlich wie lange. Derzeit wird von der Seite ein Cookie gesetzt, der zwei Monate Gültigkeit hat und nur über einen sicheren Kanal (HTTPS) übertragen wird. Weitere Cookies werden nach Beendigung der Browsersitzung gelöscht. Die Foundation hat eine längere Erklärung zu den Cookies. Wenn ein Artikel bearbeitet wird, so verbleibt die IP-Adresse im Logbuch der letzten Änderungen.

Angemeldete Benutzer

Wenn sich jemand entscheidet, ein Benutzerkonto anzulegen, kommen weitere Betrachtungen hinzu. Insondere stellt sich die Frage nach der Sicherheit des Passworts. Für mich ist hier wesentlich, dass das Wikipedia-Passwort verschieden zu anderen sein sollte. Was die Länge und die Gestalt des Passworts betrifft, sollte man sich überlegen, wie wichtig das Konto ist. Denn wenn jemand das Passwort errät, kann diese Person im Namen des andere Bearbeitungen durchführen und am Ende wird das Konto vielleicht gesperrt. Das heißt, der Schaden für normale Benutzer hält sich in Grenzen. Daher würde ich die Anforderungen an das Passwort nicht so hoch ansetzen.

Die Lage ändert sich, wenn jemand CheckuserAdministrator bzw. Bürokrat ist. Diese Rollen habenhat wesentlich mehr Rechte und der potenzielle Schaden ist größer. Daher würde ich erwarten, dass es bei diesen Rollen stärkere Anforderungen an das Passwort bzw. andere Authentifizierungsverfahren gibt.

Im Podcast sprachen wir das Thema Mail an. So bekommt ein angemeldeter Nutzer verschiedentlich Mails. Facebook hat eine Möglichkeit geschaffen, einen OpenPGP-Schlüssel in seinem Profil zu hinterlegen. Alle Mails von Facebook kommen dann automatisch verschlüsselt und signiert an. Dadurch ist es unter anderem recht einfach Spam von echten Facebook-Mails zu unterscheiden. Es wäre wundervoll, wenn Wikipedia auch diese Möglichkeit bieten würde.

Sicherheit in der Wikipedia für andere

Wie ihr seht, sind die obigen Betrachtungen schon recht lang geworden. Aber innerhalb des Wikipedia-Universums gibt es noch andere Personengruppen. So betreiben Administratoren die Server. Das heißt, sie pflegen die Hard- wie auch die Software. Welche Anforderungen müssen diese Personen erfüllen? Auch gibt es einen Personenkreis, der die Software programmiert. Hier kann man sich ebenfalls Gedanken zu den Anforderungen bezüglich der Sicherheit machen. Doch beides wird sehr lang und viel. Daher lagere ich das mal auf einen eventuellen zukünftigen Artikel aus.

Wunsch für die Zukunft

Im Rahmen meiner Überlegungen zur Sicherheit in und um die Wikipedia fiel mir noch ein großer Wunsch ein:

Es wäre phantastisch, wenn die Wikipedia als Tor Onion Service zur Verfügung stehen würde. Dies macht es gerade Leuten in zensierten Ländern viel einfacher, die Seiten zu erreichen. Die Webseite ist von einem Ende zum nächsten verschlüsselt und es macht es Angreifern viel schwerer, die Verbindung aufzubrechen. Unter anderem macht es Facebook mit der Seite https://facebookcorewwwi.onion/ vor. Aber auch DuckDuckGo (http://3g2upl4pq6kufc4m.onion/) sowie Debian und Tor selbst betreiben viele Seiten im Tor-Netz. Daher wäre Wikipedia ein wundervolles Beispiel für einen weiteren Tor Onion Service, der vermutlich vielen Menschen großen Nutzen bringt.

Update: In der Diskussion wies mich Raymond darauf hin, dass Administratoren doch nicht die großen Rechte haben, die ich vermutete. Diese sind erst bei Checkusern gegeben. Daraufhin habe ich den Artikel angepasst.

cronjob