Missing Link: Datenschutz, DAUs und Developer – wer darf Software kontrollieren?
Seite 2: Grenzen von Plug-and-Play
"Ein vollständiges Plug-and-Play ohne Wenn und Aber ist aus verschiedenen Gründen unrealistisch", anerkennt auch Marit Hansen, Datenschutzbeauftragte des Landes Schleswig-Holstein und eine starke Stimme für den technischen Datenschutz.
Natürlich sollten Entwickler und Provider sehr viel mehr für eine einfache Benutzbarkeit tun, damit Dienste und Produkte so ausgeliefert werden, dass ein Risiko möglichst gering ist und Datenschutz und Sicherheit von Anfang an eingebaut sind, unterstreicht sie. In Europa ist das sogar Pflicht. Dinge wie Klartext in der Cloud zu speichern, bei vernetzten Autos Signale ohne Beschränkung der Reichweite aussenden oder auch DNS-Daten ohne Not quer durch die Welt zu verteilen oder mitzuloggen, entspricht den Vorgaben der Datenschutzgrundverordnung nicht.
Die Nutzer müssen zudem, unterstreicht Hansen, "auf Basis von verständlichen Informationen bewusst entscheiden können, ob und wann sie mehr Daten freigeben oder mehr Verarbeitung erlauben". Da ist er wieder, der "informed consent", über den die Techniker so die Nase rümpfen.
DNS ist insbesondere in Firmenumgebungen eine wichtige Informationsquelle und kann dabei helfen, die Sicherheit zu verbessern. Allerdings bedeutet die bevorstehende Einführung sicherer DNS-Dienste, dass viele dieser Techniken absehbar Probleme bekommen werden.
Übrigens sind sie laut Artikel 25 DSGVO auch gar nicht direkt angesprochen. Der Artikel richtet sich, konstatiert Hansen, "an diejenigen, die die personenbezogenen Daten verarbeiten und für die Verarbeitung verantwortlich sind, dazu gehören Entwickler und Hersteller erst einmal nicht." Aber: die Verantwortlichen müssen doch bei der Auswahl der Verarbeitungssysteme das Prinzip "Datenschutz by Design & by Default" sehr wohlberücksichtigen und dies bei den Herstellern einfordern. "Das passiert leider aktuell noch zu wenig", mahnt die Datenschützerin.
Was sie Entwicklern wie Providern zugesteht, ist zudem, dass es große Unterschiede gibt, was den Schutzbedarf anbelangt. Die Unterschiede könnten technisch begründet sein oder davon abhängen, "wo die am Dienst beteiligten Service Provider ihren Sitz oder ihre Server haben, welchem Recht sie unterliegen und welche unvorhergesehene Zugriffe auf Daten oder Rechner – durch Behörden oder andere – möglich sind. Einige User mögen daher Service Provider oder Komponenten in ihrer eigenen Jurisdiktion bevorzugen, andere eben gerade nicht", sagt sie.
Dieser Gedanke wurde auch von den Befürwortern von HTTPS als Transport für DNS ins Feld geführt. Wer DNS in einem Land (oder Netz) braucht, das auf staatlichen Druck hin stark gefiltert wird, könnte durch den zentralen, externen DoH-Server profitieren. Dass großen Netzbetreibern ausgerechnet jetzt, wo sie Verkehr zu verlieren drohen, einfällt, dass sie ihren Nutzern eigentlich die Wahl geben sollten, wo ihre DNS-Anfragen beantwortet werden sollten, ist nach Ansicht der DoH-Befürworter eher dem Kontrollverlust, als der Idee von der informierten Einwilligung in Verarbeitungsprozesse geschuldet.
Zu den staatlichen Aufgaben gehört es nach Hansens Ansicht einerseits, im Bereich der Standardisierung dafür Sorge zu tragen, dass dort Datenschutz und Sicherheit eingebaut werden. Andererseits ist der Staat auch aufgerufen, das Bewusstsein und Verständnis über die Risiken und Schutzkonzepte in der Bevölkerung zu verbessern, "ohne dass jede und jeder zum Informatik-Profi werden muss", sagt die Datenschützerin.
Trau, schau, wem
Ganz praktisch gesprochen rät sie in der Frage, wie viel Technik zumutbar ist, Nutzer bei der Installation und Konfiguration über die wichtigen sicherheits- und datenschutzrelevanten Entscheidungen aufzuklären und ihnen Empfehlungen durch ihre Provider oder auch durch Stellen ihres Vertrauens zu geben.
"Hier wären auch Konfigurationsfiles oder Wizards von Verbraucherschützern, Datenschützern, Sicherheitsexperten oder Vereinen denkbar," sagt sie. Der Auftrag an die Entwickler sei es, dies zu ermöglichen und zu unterstützen. In der Dokumentation sollten Beispiele für typische Konfigurationen gegeben werden. "Das würde auch den Verantwortlichen erleichtern, die für ihre Verarbeitung datenschutzfreundlichen Voreinstellungen zu wählen", erklärt sie.
Bei risikoreicher Verarbeitung sollten außerdem deutliche Warnungen gegeben werden, etwa wenn geheime Schlüssel weitergeben werden, eine Verschlüsselung deaktiviert oder Dritte Zugriff auf das eigene Gerät nehmen (als Fernwartung). Manchmal kann es notwendig sein, dass die entsprechenden Aktionen unterbunden werden, das hätten die Betreiber festzulegen und transparent zu machen. Darüber, wie diese Empfehlung der Datenschützerin auf die Nutzung von DoH-Servern anzuwenden ist, dürfte in den kommenden Monaten noch heftigst gestritten werden.
Bei aller Unzulänglichkeit der Nutzer, die Transparenz über mögliche Risiken oder an einem Dienst beteiligte Partner oder Dritte erlaubt zumindest eine erste Entscheidung darüber, wem – welchem Softwareentwickler, welchem Provider und welcher Jurisdiktion – sie trauen wollen.
Die Idee, dass es jedermann möglich sein sollte, seine Software zu kontrollieren, klingt gut und ist auch in Entwicklerkreisen noch nicht vollkommen aufgegeben. Vielleicht werden künftige Nutzergenerationen vertrauter mit der Technik sein oder besser ausgebildet, meint ein IETF-Entwickler. "Dann könnten wir vielleicht schlauere Modelle für die Interaktion zwischen Nutzer und Netz entwickeln und dem Nutzer die Wahl geben", sagt er. "Von allein passiert das aber sicher nicht. Wir sollten nicht davon ausgehen, dass das Aufwachsen mit dem Internet automatisch dazu führt, dass man versteht, wie es funktioniert."
Empfohlener redaktioneller Inhalt
Mit Ihrer Zustimmmung wird hier ein externes Video (Kaltura Inc.) geladen.
Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Kaltura Inc.) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.
(tiw)
