Interview zu Corona-Warn-App„Risiken und Maßnahmen nicht ausreichend dargelegt“

Vieles ist gut gelaufen bei der Entwicklung der Corona-Warn-App, doch aus Sicht des Datenschutzes gibt es noch Luft nach oben, findet Kirsten Bock. Im Interview kritisiert sie die Datenschutz-Folgenabschätzung der Anwendung und fordert eine gesetzliche Grundlage, um möglichen Missbrauch zu verhindern.

– Gemeinfrei-ähnlich freigegeben durch unsplash.com Kai Pilger

Kirsten Bock arbeitet hauptberuflich im Datenschutz. Sie ist Mitglied beim Forum der InformatikerInnen für Frieden und gesellschaftliche Verantwortung (FIfF) und eine der Autor:innen von dessen Muster-Datenschutz-Folgenabschätzung (DSFA) für Tracing-Apps.

Noch nicht ausgereift

netzpolitik.org: Mit dem Start der Corona-Warn-App Mitte Juni wurde auch die Datenschutz-Folgenabschätzung veröffentlicht. Telekom, SAP und Robert-Koch-Institut sind damit einer Forderung der Zivilgesellschaft gefolgt. Was ist Ihr erster Eindruck von dem mehr als hundertseitigen Dokument?

Kirsten Bock: Erstmal freuen wir uns, dass die DSFA der Corona-Warn-App veröffentlicht wurde. Das ist eine wichtige Entscheidung. Was man aber vorweg schon sagen kann, ist, dass sich das Team offensichtlich zum ersten Mal mit einer Datenschutz-Folgenabschätzung befasst hat und – um es mal positiv zu formulieren – versucht hat, sich dem Ziel zu nähern. Aus meiner Sicht ist das jedoch noch keine ausgereifte DSFA.

netzpolitik.org: Wo liegt das Problem?

Kirsten Bock
Datenschützerin Kirsten Bock - Alle Rechte vorbehalten privat

Kirsten Bock: Dem Anspruch nach ist dies eine verpflichtende DSFA nach Artikel 35 der Datenschutzgrundverordnung. Damit gehen bestimmte methodische Vorgaben einher. Der Artikel schreibt zum Beispiel vor, dass die Prüfung vor dem Start einer Technologie durchzuführen ist und enthält insofern auch eine Vorgabe, wie man Privacy by Design materiell umsetzt. Das ist in diesem Fall ganz offensichtlich nicht passiert.

Die Datenschutzfolgeabschätzung ist – so wie ich das lese – nachträglich erstellt worden. Das ist eigentlich nicht Sinn und Zweck der Sache. Die Verantwortlichen sehen ein „lebendes Dokument“ und wollen die Folgenabschätzung fortführen. Das ist positiv, aber ein Minimum des Notwendigen für neue, eigenständige Komponenten. Eine DSFA ist eigentlich mit einem klaren Ergebnis abzuschließen und wird danach Gegenstand des Datenschutz-Managementsystems der Verantwortlichen.

netzpolitik.org: Nun war der Zeitraum für die Entwicklung der Tracing-App aber auch ein sehr kurzer.

Kirsten Bock: Das stimmt natürlich. Aber es war von Anfang an klar, dass man eine hohe Zahl von Nutzern dafür gewinnen will. Deshalb wäre es umso wichtiger, dass man nicht einfach drauflos entwickelt. Wenn man so ein Projekt macht, muss man sofort auch ein DSFA-Team an seiner Seite haben, das kontinuierlich das reflektiert, was entwickelt wird.

Nicht nur die App, sondern das gesamte System betrachten

netzpolitik.org: Sie haben mit dem FIfF schon im April eine Muster-Datenschutzfolgeabschätzung für eine mögliche Corona-Tracing-App vorgelegt. Als Debattenbeitrag und Anregung, die in der offiziellen DSFA nun auch als eine Grundlage erwähnt wird. Wo sind Unterschiede?

Kirsten Bock: Was ich erwartet hätte, ist eine Auseinandersetzung nicht nur mit der Corona-App als solcher, sondern mit dem gesamten Verfahren. Dazu gehört etwa auch die Serverinfrastruktur. Die wird in dieser DSFA zwar angesprochen, aber es fehlen genauere Information: Was passiert da eigentlich genau? Was wird geloggt? Wird das gelöscht? Wie lange werden Daten aufbewahrt? Wir finden hierzu unterschiedliche Angaben zum einen im Glossar der DSFA und zum anderen im Haupttext. Es gibt ja unterschiedliche Serverfunktionen für die unterschiedlichen Funktionalitäten der App. Es wäre deshalb zwingend erforderlich, zu beschreiben, was da eigentlich passiert.

netzpolitik.org: Sie meinen die Übermittlungsserver, über die die Tagesschlüssel der positiv getesteten Personen verteilt werden?

Kirsten Bock: Genau. Wir haben es hier dann ja letztlich mit Krankheitsinformationen zu tun. Auch wenn die IDs für sich genommen wenig Aussagegehalt haben, hängen sie ja doch immer an der Person beziehungsweise an dem Handy, das sie hochlädt. Wenn ich diesem Server nicht vertraue im Hinblick auf die Verkehrsdaten, kann ich mir diese ganze Diskussion um Pseudonymisierung der Daten eigentlich sparen. Wenn hier Verkehrsdaten nicht von Inhaltsdaten getrennt werden und zusammen im Back-End verbleiben, habe ich ein Problem in der ganzen Architektur.

netzpolitik.org: Weil die Betreiber der Server über die Metadaten potenziell re-identifizieren könnten, wer die Tagesschlüssel hochlädt, also wer an Covid-19 erkrankt ist?

Kirsten Bock: Genau.

netzpolitik.org: Und das wird in dem Dokument nicht dargelegt?

Kirsten Bock: Die Risiken und Maßnahmen werden meines Erachtens nicht ausreichend dargelegt.

netzpolitik.org: Benennt die Folgenabschätzung denn zumindest dieses Risiko, dass es vonseiten des Betreibers zumindest potenziell zur Re-Identifikation kommen könnte?

Kirsten Bock: Nein, und das ist ein weiteres grundsätzliches Problem: Es fehlt in dem Papier eine datenschutzspezifische Risikomodellierung. Das liegt wahrscheinlich daran, dass es einfach keine hinreichende Orientierung an operativem Datenschutz gibt. Aus Datenschutzsicht ist ja nicht jemand Externes Hauptangreifer auf die Rechte und Freiheiten, sondern der Verantwortliche selbst. Deshalb hätte dargelegt werden müssen, wie die Grundsätze aus Artikel 5 DSGVO [Anm. der Red.: Zweckbindung, Datenminimierung, Nachvollziehbarkeit etc.] umgesetzt werden und diese hätten als Risikokriterien herangezogen werden müssen.

Nichtwissen ist keine Option

netzpolitik.org: Das klingt ein bisschen grundsätzlich. Wir hatten ja eine intensive öffentliche Debatte, an deren Ende die datenschutzfreundlichere Variante umgesetzt wurde. Braucht es da überhaupt noch so eine ausführliche Folgenabschätzung?

Kirsten Bock: Natürlich ist es ein Erfolg, dass am Ende diese dezentrale Variante ausgewählt wurde. Aber die ausführliche Folgenabschätzung braucht es schon allein deshalb, weil sie gesetzlich vorgeschrieben ist und der Prozess des „Datenschutz durch Technikgestaltung“ auch formal begleitet werden soll. Wir wissen wie gesagt nicht genau, was auf dem Server passiert und das kann sich ja auch jederzeit ändern. Wir vertrauen darauf, dass die Serverbetreiber das tun, was sie uns versprechen. Das kann nur nachvollzogen werden, wenn das tatsächlich kontrolliert erfolgt.

Deshalb ist es auch unbedingt notwendig, dass die DSFA öffentlich ist. Wer auf Open Source setzt, sollte immer auch die Datenschutz-Folgenabschätzung veröffentlichen. Damit Ankündigung und Realität miteinander abgeglichen werden können und die Risiken klar auf dem Tisch liegen. Die DSFA bietet begleitende Einordnung und Kontrolle. Das führt uns aber direkt zum nächsten Problem.

netzpolitik.org: Welches wäre das?

Kirsten Bock: Die Verantwortlichen ziehen sich in einem sehr relevanten Bereich auf Nichtwissen zurück, das geht für eine Datenschutzfolgenabschätzung überhaupt nicht. Ich spreche die Prozesse an, die auf Betriebssystemebene bei Google und Apple laufen. Also dieser ganze ENF-Bereich, da heißt es in der Folgenabschätzung: Naja, das läuft ja bei denen und da können wir nur den Informationen vertrauen, die sie uns liefern, aber prüfen können wir das nicht. Das positive ist: Diese Lücke wird deutlich gemacht. Denn das könnte ja auch einfach unter den Tisch fallen. Das Problem ist nur, dass man als Verantwortliche an diesem Punkt nicht stehen bleiben und sagen kann: Ja, tut uns leid, das können wir nicht prüfen.

netzpolitik.org: Die Verantwortlichen machen hier Sicherheitsbedenken geltend. Wenn bekannt wäre, wie genau das Verfahren bei Apple und Google funktioniert, wäre es angreifbar. Lassen Sie das Argument gelten?

Kirsten Bock: Nein. Wenn man in Bereiche gerät, in denen Fachleute zu dem Schluss kommen, dass eine öffentliche Darstellung problematisch ist, weil sie neue Risiken birgt, dann muss man eine vertrauenswürdige dritte Person hinzuziehen und das Ganze testen lassen. Da sind wir im Bereich Zertifizierung. Da müssten dann zumindest die Kriterien offengelegt werden, nach denen geprüft wurde. Und dann kann man so eine Prüfung, die nicht öffentlich erfolgt, auch in eine DSFA einbeziehen. Aber man kann sich nicht zurückziehen und sagen: Da vertrauen wir mal den Playern und dabei belassen wir es.

Vertrauen ist gut, ein Gesetz wäre besser

netzpolitik.org: Wenig überraschend kommen Telekom, SAP und das Robert-Koch-Institut in ihrer Folgenabschätzung insgesamt zu dem Schluss, dass die Risiken beherrschbar sind und dass genug Maßnahmen ergriffen wurden, um sie zu einzudämmen. Bedeutet Ihre Kritik an dem Dokument im Umkehrschluss, dass sie an diesem Ergebnis zweifeln?

Kirsten Bock: Das große Problem ist, dass die Zusagen, die derzeit gemacht werden, nirgends festgeschrieben sind. Die App ist sehr weit verbreitet und ihre Funktionalität kann mit wenigen Handgriffen verändert werden. Das Robert-Koch-Institut behält sich das ja auch vor. Wir können also nicht sicherstellen, dass der Zustand erhalten bleibt, in dem die App ihre Arbeit rechtskonform erledigt. Man kann die Sicherheit hier outsourcen und sagen: die Zivilgesellschaft wird das schon überprüfen – wir machen so viel wie möglich öffentlich und da gucken dann immer Leute drüber. Das ist der jetzt gewählte Weg und das ist bis zu einem bestimmten Punkt auch gut und vertrauensbildend. Aber natürlich kann die Verantwortliche nicht ihre gesamte Verantwortlichkeit externalisieren. Sondern sie muss eben selbst die DFSA in einem Datenschutz-Managementsystem fortschreiben, das wäre eine Maßnahme.

netzpolitik.org: In der Muster-Folgenabschätzung haben Sie mit dem FIfF eine andere Maßnahme in den Vordergrund gestellt.

Kirsten Bock: Richtig, es wäre angezeigt gewesen, dass man die Funktionalität des Systems in einem Gesetz festschreibt. Da müsste dann der Gesetzgeber die Hosen runterlassen und festlegen, zu welchen Zwecken Daten verarbeitet werden. Wenn das Gesetz festschreibt, dass die App in jeder Hinsicht immer freiwillig sein muss, dann kann das eine positive Wirkung haben. Natürlich könnte es aber auch so ausgehen, dass der Gesetzgeber sagt: Wenn du im Krankenhaus arbeitest, dann verlange ich von dir die Installation der App und dann musst du das Ding auch immer bei dir tragen.

netzpolitik.org: Das heißt, nicht in jedem Fall wäre ein Gesetz die weniger eingriffsintensive Variante.

Kirsten Bock: Das kommt darauf an. Im Moment ist es ja so, dass die App auf einer Einwilligungslösung basiert. Da kann man sich sehr drüber streiten, ob überhaupt in jedem Fall die Voraussetzungen der freiwilligen Einwilligung gegeben sind. Aber die Einwilligung hat erstmal den Vorteil, dass ich als ein Individuum sagen kann: Das Ding will ich nicht, dem traue ich nicht und ich nutze das nicht. Nur: In einer demokratischen Gesellschaft sollten die wesentlichen Dinge wie der Zweck, Datenkategorien und Rechtsfolgen durch ein Gesetz geregelt werden. In diesem Fall schon allein deshalb, weil so viele Personen betroffen sind.

netzpolitik.org: Die Autor:innen der offiziellen Datenschutzfolgen-Abschätzung kommen zu dem Ergebnis, dass es kein Spezialgesetz braucht.

Kirsten Bock: Das wird sich zeigen. Wir sind zu dem Schluss gekommen, dass es eine gesetzliche Grundlage braucht, weil wir in den allermeisten Fällen die datenschutzrechtliche Voraussetzung für die freiwillige Einwilligung nicht sehen. Viele Menschen installieren die App nicht freiwillig, sondern aus dem Gefühl heraus, sie müssten einen solidarischen Beitrag an die Gesellschaft leisten – was ja auch positiv ist, aber eben nicht freiwillig im datenschutzrechtlichen Sinne.

Das gilt erst Recht, wenn Unternehmen diese App jetzt verpflichtend machen. Wir haben ja bereits von Fällen gehört. Wenn Arbeitgeber plötzlich die Installation verlangen oder Menschen ohne App nicht mehr im lokalen Supermarkt einkaufen können, werden sie sich beschweren. Das wird dann auch nochmal juristisch interessant werden, wenn es Prüfungen und Klagen gibt. Da werden auch die Datenschutzbehörden tätig werden müssen, um Prüfungen vorzunehmen und um die Rechtsfragen zu klären, die sich um die App ranken.

netzpolitik.org: Vielen Dank für das Gespräch!

Deine Spende für digitale Freiheitsrechte

Wir berichten über aktuelle netzpolitische Entwicklungen, decken Skandale auf und stoßen Debatten an. Dabei sind wir vollkommen unabhängig. Denn unser Kampf für digitale Freiheitsrechte finanziert sich zu fast 100 Prozent aus den Spenden unserer Leser:innen.

13 Ergänzungen

  1. Hallo,
    danke für das spannende Interview! Das ist vielleicht etwas OT, aber:
    Kennt Ihr zufälligerweise eine Quelle, die eine Bewertung der in der Darmstädter Studie beschriebenen Angriffe vornimmt?

    LNP und Tim schaffen es ja leider beide, die Inhalte unrichtig wiederzugeben. Da kommt es gar zu Strohmann-Aussagen wie „Deutschlandweite Massenüberwachung per CWA geht nicht“ – obwohl die App das komplett-Tracking aller infizierten *einer Stadt* beschreibt.

    Es muss doch eine/n Expert*in geben, der das korrekt wiedergeben und beurteilen kann…

    Danke!

  2. Erster Überflug erstes Lob: „Viele Menschen installieren die App nicht freiwillig, sondern aus dem Gefühl heraus, sie müssten einen solidarischen Beitrag an die Gesellschaft leisten“

    Das finde ich wichtig, da auch durchaus „die Politik“ in persistenter Weise die de-facto Werbetrommel bemüht hat, sowie das mit den Arbeitgebern ziemlich offen lässt. Da ist eine Menge ungutes Potential drinnen, und interessanterweise auch sehr direkt einsehbar: tatsächlich ergibt sich aus den genannten Umständen der erste Schritt einer Gewöhnung an „solche Maßnahmen“, was in einem aufgeklärten Land nicht akzeptiert werden sollte, sofern Aufklärung irgendwie wichtig bleiben soll.

  3. Seite 2: Vorausgehende Hinweise

    Dieses Dokument basiert – soweit die Funktionalität, die Datenverarbeitung und der Umfang der Datenverarbeitung in dem Expositionsbenachrichtigungswerkzeug (Exposure Notification Framework (ENF)) der Unternehmen Apple Inc. und Google Inc. beschrieben wird – auf den verfügbaren Beschreibungen zu diesem Framework. Eigene Erkenntnisse über die innere Funktionsweise können nicht gewonnen werden, da dieses Framework aus
    Sicherheitsgründen in einer Art und Weise implementiert ist, die eine Untersuchung
    ausschließen. Insoweit wurde bei der Erstellung dieses Dokuments auf die Richtigkeit der Verarbeitung in den Frameworks und der Beschreibungen vertraut, wie auch beim Betrieb der Frameworks auf die Richtigkeit der Datenverarbeitung und deren Beschreibung vertraut wird.

    Seite 112: Risiken durch die Verwendung von Dritt-Technologien
    Der Umstand, dass die CWA App die Konnektivitäten und das ENF von Google und Apple verwendet, stellt ein erhebliches Risiko dar, …
    Gleiches gilt hinsichtlich des Angewiesenseins der CWA App auf den internationalen BLE-Standard sowie die Hardwarekomponenten des Smartphones …

    Es ist anzunehmen, dass Apple und Google durch eine Änderung des ENF auch zur Verknüpfung der dort verarbeiteten Tagesschlüssel und RPIs mit einer geräte- (z. B. Werbe-ID) oder nutzerspezifischen Kennung (z. B. Apple-ID oder Google-Konto) in der Lage sind. Derartige Risiken bestehen allerdings bei jeder Drittanbieter-App, die Schnittstellen eines Betriebssystems oder technische Komponenten des Smartphones nutzt. Allerdings haben die Nutzer durch die Verwendung eines Android- bzw. iOS-Smartphones zum Ausdruck gebracht, dass sie grundsätzlich Vertrauen zu diesen Herstellern haben oder sich jedenfalls mit den Datenschutzrisiken, die mit der Verwendung eines Smartphones dieser Hersteller für
    persönliche Zwecke einhergehen, abgefunden oder andernfalls ihr Nutzungsverhalten entsprechend angepasst haben (z. B. durch Deaktivierung der Ortungsdienste).

    ===
    Fazit: Wer ein Smartphone betreibt, bekundet durch sein Nutzerverhalten, dass er dem Hersteller prinzipiell vertraut oder sich damit abgefunden hat, die Verwendung seiner Daten nicht mehr vollständig kontrollieren zu können.

    Oder anders formuliert: Wer ein Smartphone besitzt, hat entweder prinzipielles Vertrauen in die Technik, die er benutzt, oder aber hat sich damit abgefunden, dass gezwungenermaßen eine Technologie benutzt werden muss , der in zentral bedeutsamen Bereichen nicht vertraut werden kann.

    Wer ein Smartphone betreibt, der hat damit einen ersten Schritt gemacht, seine Datensouveränität aufzugeben. Schon dieser Umstand kann einem Smartphone-Besitzer in einer Technologiefolgenabschätzung vorgeworfen werden, um als Softwarehersteller daraus einen Rechtfertigungsnutzen zu ziehen, etwa um eigene Verantwortung herabzusetzten.

  4. Sehr geehrte Netzpolitik-Redaktion,
    dies ist ein sehr interessanter Artikel. Aber hier wird von der Corona-Warn-App nur im Zusammenhang der globalen Player wie Google u. Apple gesprochen. Mich würde aber interessieren, ob man die App auch z.B. auf ein Linux-Handy oder auf einem Raspberry Pi installieren kann und wie sieht es dort mit dem Datenschutz aus? Da die Daten ja dann nicht vom eigenen Handy kommen und man die App, wenn Sie nicht mehr benötigt wird, komplett löschen kann, sollte die Nutzung auf so einem Gerät doch unproblematisch sein, oder?
    Viele Grüße
    Horst Meyer

    1. Ich bin von der Transparenz der Entwicklung der CWA so begeistert, dass ich sie installiert habe und die Installation empfehle. Mein Problem war dabei, dass ich Google und Apple nicht vertraue und ich daher daher „Ausnahmeregelung“ bezüglich meiner eigenen Richtlinie für ein Extra-Handy mit den Google-Apps brauchte.
      Aber wenn jede systemrelevante Entwicklung so transparent wie die CWA wäre, dann wäre mein Vertrauen in digitale Agenden deutlich höher.
      Sicher gibt es immer Verbesserungspotential. Aber es gibt sooo viel, was sooo viel schlimmer ist (bei den G-Apps angefangen und bei dem in Corona-Zeiten unsinnigerweise systemrelevant gewordenen Whatsapp erst recht.)
      Ich würde mich freuen, wenn dieses Positivbeispiel mehr in den Fokus gerückt würde, auch als Lehrbeispiel wie es besser geht. Manchmal ist ein Positivbeispiel besser geeignet Leuten klar zu machen, was sie da eigentlich noch so an Wanzen-Apps mit sich herum tragen. Vielleicht lässt sich dann aus der CWA ein ganz neuer Vertrauensstandard ableiten. Und den bräuchten wir dringend.

    2. Bin zwar nicht die Redaktion, antworte aber trotzdem ;-)

      Welche Marktanteile haben Smartphones, die ein Betriebssystem nutzen, das nicht von Apple oder Google stammt? Die mögen zwar (technisch, Datenschutz) ihre Vorteile haben, mengenmäßig sind sie aber irrelevant. Die Frage nach dem Raspi versteh ich nicht. Wer trägt sowas mit sich rum? Ohne immer-dabei ist es witzlos. Daher, nein, auf keinem der beiden läßt sich die App installieren (und ich erwarte auch nicht, das sich daran noch was ändert).

    3. warum sollte die App auf einen RasPi installiert werden können? Was macht das für einen Sinn??

      1. Der Sinn ist der selbe wie auf einem Handy: zum Contact-Tacing. (Raspberry Pies 2 und neuer haben Bluetooth Low Energy, könnten also theoretisch dazu genutzt werden. Oder ein Raspberry Zero + Akku)

  5. Da es offenbar im Alltag Arbeitgeber und andere für den Anwender wichtige Organisationen gibt, die den Anwender unter Druck setzen, die Nutzung der Warn-App nachzuweisen, kann diese App folglich so wie sie ist nicht empfohlen werden.
    Bürger werden damit generell unter Druck gesetzt, technische Informationen an Dritte weiterzugeben, bzw. gar dem AG zu Kontrollzwecken Zugang zum Smartphone zu verschaffen.
    Dabei werden dann regelmäßig Rechte Dritter verletzt, die der Anwender zu schützen zugesagt hatte, da die kontrollierende Instanz Zugriff auf das Smartphone erhält.
    Somit kommt es, insebedondree wegen des breiten öffentlichen Drucks, unter dem Vorwand allgemeiner Gesundheitspflege, sehr wahrschrinlich zur Etablierung regelmäßiger schwerer Verletzungen von Datenschutz.
    Das wurde im Design nicht beachtet und mögliche Gegenmaßnahmen sind nicht vorgesehen.

  6. Guten Tag,

    vielen Dank für das Interview. Ist es doch sehr spannend zu sehen auf, welchen hohen Niveau aktuell kritisiert wird.
    Leider ist mir nicht klar was ein datenschutzspezifische Risikomodellierung sein soll. Ein Risikomodell ist für mich ein auf statisitik basierendes Rechenmodell, welches eine Wahrscheinlichkeit zum Beispiel eines Ausfalls ausdrückt. Also zum Beispiel der Schufascore ist die Quintessenz eines Risikomofdells. Ist so was damit gemeint?
    Auch operativer Datenschutz ist mir nicht klar. Ist damit eine Person gemeint oder eine Methode? Ich habe keine Informationen über eine Methode nur über Personen gefunden.
    Für mich war der Text an dieser Stelle zumindest mal unverständlich.

    Vielen Dank und Beste Grüße
    Peter

    1. Datenschutz ist prinzipbedingt ein hochkomplexes Thema, bei dem ohne hohes Niveau keine zutreffenden Informationen erlangt werden können. Wer von „Kritik auf hohem Niveau“ spricht, suggeriert jedoch, dass er die Argumentationen für übertruebrn spitzfindig hält.

      Genau diese Haltung ist weit verbreitet. Datenschutz kann jedoch nur als Kette verstanden werden, die sm schwächsten Glied reißt.

      Daher sind viele geliebte Anwendungen de facto nicht digitaltauglich für Alltagsanwendungen, auch wenn es noch so schön wäre wenn.

    2. Hallo Peter,
      vielen Dank für das positive Feedback :)
      Bei einer datenschutzspezifischen Risikomodellierung werden die Grundrechte in Bezug genommen, d.h. das Risiko für Betroffene, dass ein Grundrechtseingriff unangemessen intensiv ist, also eine Verarbeitung stärker in die Rechte und Freiheiten von Personen eingreift als dies verhältnismäßig ist. In dem Modell ist insbesondere der Verantwortliche als Angreifer auszuweisen. Die Risikokriterien ergeben sich aus Art. 5 DSGVO und den Betroffenenrechten. Zu beachten ist dabei der Erwägungsgrund 75 der DSGVO. Daraus kann abgeleitet werden, das Risiken mögliche Schäden sind. Schäden können zB durch folgende Ereignisse entstehen: Unbefugte oder unrechtmäßige Verarbeitung, Intransparente Verarbeitung, Verweigerung der Betroffenenrechte, Verwendung der Daten durch die Verantwortliche zu inkompatiblen Zwecken, usw.

      Der Begriff des operativen Datenschutzes bezeichnet die real wirksamen Aktivitäten in Form von Schutzmaßnahmen abgeleitet aus den Anforderungen der DSGVO. Davon abzugrenzen ist der normative Datenschutz.

      Ich hoffe, damit werden die Begriffe klarer.

  7. „das läuft ja bei denen und da können wir nur den Informationen vertrauen, die sie uns liefern, aber prüfen können wir das nicht“?

    Schon merkwürdig, dass der Source der API nicht veröffentlicht wird – wo doch zimindest Google mit AOSP einen Teil von Android sowieso veröffentlicht. Was soll diese Geheimhaltung bringen? Security by obscurity ist doch lange widerlegt ;)

    Und die alternativen ROMs, die viele ältere Handies am Leben halten sind dann auch raus.

Dieser Artikel ist älter als ein Jahr, daher sind die Ergänzungen geschlossen.