iX 12/2020
S. 6
Leserbriefe
Dezember 2020

Leserbriefe Dezember 2020

Nicht nachvollziehbare Auswahl

(Codescanner: Werkzeuge zur automatischen Codeanalyse; iX 11/2020, S. 68)

Ich verstehe im Artikel „Quelltext im Fokus“ nicht die Auswahl der Tools – warum gerade diese 35? Und was sind die Beweggründe, aus ihnen dann genau vier näher zu beleuchten?

SonarQube fehlt aus meiner Sicht in dieser Liste. Von der Open-Source- bis zur Enterprise-Version gibt es die Software in der Cloud oder on Premises. Zig Sprachen werden unterstützt. Das Tool integriert sich nahtlos in gängige CI/CD-Pipelines, umfasst – in der kommerziellen Version – eine Managementsicht. Ferner bietet das Tool einen interessanten Ansatz, zwischen Legacy-Code und neuem Code zu unterscheiden. Zudem gibt es eine aktive Community, die Plug-ins entwickelt und pflegt.

Jan Hill, via E-Mail

Plug-in nicht weiterentwickelt?

(Objektspeicher: Ceph als IMAP-Backend für Dovecot; iX 9/2020, S. 132)

Ein interessantes Thema – aber leider ist, wenn ich das richtig sehe, die Entwicklung vor 1,5 Jahren eingeschlafen und es ist nichts weiter passiert. Oder vertue ich mich?

Dirk Brennemann, via E-Mail

Die von Ihnen vorgebrachten Bedenken sind mir nicht neu, ich habe mir beim Schreiben des Artikels ganz ähnliche Fragen gestellt. Ich konnte das Set-up jedoch so, wie es in der Dokumentation des Plug-ins vermerkt ist, aufsetzen. Es sind mir keine Fehlfunktionen aufgefallen. (Martin Gerhard Loschwitz)

Code nicht übertragbar

(Embedded-Software: C++-Metaprogrammierung mit Templates für eingebettete Systeme; iX 10/2020, S. 144)

Standard-C++ ist das ganze ja nicht: Der Code beinhaltet Undefined Behavior, das nicht unbedingt portabel auf andere Controller oder Compiler/Versionen übertragbar ist – zumindest nicht, ohne den Assemblercode zu prüfen. So reicht eine volatile-Variable seit C++11 nicht aus, um Data Races zwischen Interrupt-Handler und sonstigem Code zu vermeiden. Es müsste schon ein atomic sein.

Auch sind while(true);-Endlosschleifen Undefined Behavior. Wenn wirklich ein unerwarteter Interrupt kommt, den man nicht einfach mit reti oder reset ignorieren will, sollte man bei einem Controller zumindest eine Diagnosemöglichkeit vorsehen (LED, Pin), außer, wie gesagt, der Platz ist wirklich zu knapp.

Peter Sommerlad, via E-Mail

Was die volatile-Variable betrifft, haben Sie natürlich recht. Mangels std::atomic unter Atmel Studio 7 würde man beispielsweise auf die Makros unter www.nongnu.org/avr-libc/user-manual/group__util__atomic.html zurückgreifen, um einen Codeblock zu erzeugen, dessen atomare Ausführung garantiert ist.

Da der Fokus des Artikels nicht die korrekte Behandlung von unerwarteten Interrupts war, haben wir uns mit while(true); bewusst für eine möglichst einfache Variante entschieden. Es ging uns in erster Linie darum, dass wir für die Variante mit und ohne unseren Dispatcher für den Größenvergleich den gleichen Code im BADISR_vect haben. Mit dieser Variante kann man zumindest beim Debuggen einen Break­point an diese Codestelle setzen und nachsehen, welcher Interrupt ausgelöst wurde. Eine Variante für den Normalbetrieb würde natürlich ganz anders aussehen (z. B. die erwähnte LED/PIN-Variante).

Bezüglich der Standardkonformität mit C++: Der Code ist durch die Verwendung des „computed goto“ leider kein standardkonformes C++. GCC und Clang unterstützen es dennoch beide. (Dirk Petrautzki)

Verwirrendes Recht

(DSGVO-Archivierung: Löschung personenbezogener Daten; iX 11/2020, S. 58)

Vielen Dank für den folgenden Hinweis im Artikel: „Das bedeutet aber nicht, dass eine Löschung nur dann stattfinden muss, wenn er dieses Recht explizit geltend macht. Wann immer keine gesetzliche Rechtfertigung oder wirksame Einwilligung des Betroffenen vorliegt, müssen personenbezogene Daten gelöscht werden.“

Art. 17 Abs. 1 ist meines Erachtens verwirrend. Warum muss ich als Betroffener etwas geltend machen, wozu der Verantwortliche verpflichtet ist, es zu tun? Häufig findet man in der Literatur nur den Löschanspruch der Betroffenen. Die Überschrift des Artikels lautet auch „Recht auf Löschung“ und nicht „Löschungspflicht“, während beispielsweise Art. 13, 14 explizit von einer Informationspflicht sprechen. Somit suggeriert man nach meinem Verständnis, dass der Betroffene selber aktiv werden muss, wie in Art. 15, 16, 18 DSGVO. Die Geltendmachung der Löschpflicht durch einen Betroffenen dürfte somit eigentlich nie vorkommen müssen, auch wenn natürlich Widerspruch und Widerruf erst einmal durch den Betroffenen initiiert werden müssen.

Sprich: Gibt es einen Fall, wo ein Verantwortlicher der (unverzüglichen) Löschung der pbD eines Betroffenen aufgrund der Geltendmachung eines Betroffenen nachkommen muss und die Speicherung der Daten zum Zeitpunkt der Geltendmachung des Löschrechts keine Löschpflichtverletzung darstellt? Es geht hier nicht um das Spezialrecht auf Vergessenwerden gegenüber Suchmaschinen, sondern um den Fall a) bis f) in Abs. 1, wo eben auch eine Löschpflicht des Verantwortlichen besteht und im Falle der Geltendmachung nur festgestellt würde, dass der Verantwortliche seiner Pflicht nicht nachgekommen ist oder – korrekterweise – die Geltendmachung gegenstandslos ist, weil der Verantwortliche seiner Pflicht nachgekommen ist.

Marco Brück, via E-Mail

Ihr Hinweis auf einen vermeintlichen Widerspruch ist korrekt. Die relevante Vorschrift aus der Datenschutz-Grundverordnung ist an diesem Punkt möglicherweise irreführend. Grundsätzlich unterscheiden Juristen zwischen der Geltendmachung von Ansprüchen und deren Durchsetzung. Für die Durchsetzung benötigt der Anspruchsinhaber gegebenenfalls gerichtliche Hilfe, für die Geltendmachung jedoch nicht. Wenn eine Person zu einem Tun oder Unterlassen ohnehin verpflichtet ist, muss ich dies an sich nur noch durchsetzen, eine Geltendmachung ist nicht mehr erforderlich. Insofern scheint Art. 17 I DSGVO in der Tat etwas verwirrend. Aus rein juristischer Sicht schadet die Vorschrift aber auch nicht, denn wenn ich ein Recht geltend mache, obwohl dies gar nicht zwingend erforderlich ist, entsteht mir rechtlich auch kein Nachteil. Andererseits könnte eine solche Verwirrung aber zur Folge haben, dass Anspruchsinhaber von einer Durchsetzung (!) absehen, weil sie – irrig – der Meinung sind, dass sie ihr Recht vor der Durchsetzung zunächst geltend machen müssen, und sich davon aus welchen Gründen auch immer abhalten lassen. Das wäre so sicher nicht im Sinne des EU-Gesetzgebers.

Der EU-Gesetzgeber wollte mit Art. 17 I DSGVO die Bedeutung der Löschung von personenbezogenen Daten herausstreichen und auch, dass der Betroffene – und nicht etwa nur eine staatliche Stelle – dies auch geltend machen und durchsetzen kann. Und dies sollte in allen EU-Mitgliedsstaaten in gleicher Weise rechtlich funktionieren, also etwa auch in Staaten, in denen der dargelegte und mitunter feine Unterschied zwischen Geltendmachung und Durchsetzung vielleicht so nicht existiert. Deswegen gibt es ja die Auslegung – und jeder EU-Staat und dessen Gerichte legen EU-Recht nach ihren eigenen Regeln aus. Dabei müssen sie allerdings den Grundsatz beachten, dass dem EU-Recht größtmögliche Wirkungskraft zukommen muss. Andererseits bedeutet dies auch, dass – wie hier – vermeintliche Widersprüche nicht zulasten von Sinn und Zweck ­einer Regelung wie der DSGVO gehen dürfen. Ein wesentlicher Grundsatz bei der Auslegung ist der Versuch, den „Willen des Gesetzgebers“ zu ermitteln. Wenn man sich die für eine Auslegung einer EU-Verordnung sehr wichtigen sogenannten Erwägungsgründe anschaut, geben bei der DSGVO etwa die Erwägungsgründe 39 und 65 wichtige Argumente für dieses Verständnis von Art. 17 I DSGVO. (Tobias Haar)

Ergänzungen und Berichtigungen

Maschinelles Lernen: ML mit Python in PostgreSQL; iX 11/2020, S. 132

Aufgrund eines Druckfehlers steht in den Quellenangaben ein falscher Link. Die korrekte Adresse lautet: ix.de/ztbv

Markt + Trends: IT-Recht & Datenschutz; iX 8/2020, S. 32

Der Praxisleitfaden des BDI ist fertig. Er findet sich unter: ix.de/zcxp

Die iX-Redaktion behält sich Kürzungen und auszugsweise Wiedergabe der Leserbriefe vor. Die abgedruckten Zuschriften geben ausschließlich die Meinung des Einsenders wieder, nicht die der Redaktion.

Der direkte Draht zu

Direktwahl zur Redaktion: 0511 5352-387

Redaktion iX | Postfach 61 04 07
30604 Hannover | Fax: 0511 5352-361
E-Mail: post@ix.de | Web: www.ix.de

Für E-Mail-Anfragen zu Artikeln, technischen Problemen, Produkten et cetera steht die Redaktion gern zur Verfügung.

post@ix.de
Redaktion allgemein
akl@ix.de
Alexandra Kleijn
ane@ix.de
Alexander Neumann
avr@ix.de
André von Raison
cle@ix.de
Carmen Lehmann
csc@ix.de
Carina Schipper
fo@ix.de
Moritz Förster
jd@ix.de
Jürgen Diercks
mdo@ix.de
Madeleine Domogalla
map@ix.de
Matthias Parbel
mfe@ix.de
Markus Feilner
mm@ix.de
Michael Mentzel
nb@ix.de
Nicole Bechtel
odi@ix.de
Dr. Oliver Diedrich
rme@ix.de
Rainald Menge-Sonnentag
sih@ix.de
Silke Hahn
sun@ix.de
Susanne Nolte
un@ix.de
Bert Ungerer
ur@ix.de
Ute Roos

Listing-Service:
Sämtliche in iX seit 1990 veröffentlichten Listings sind über den iX-FTP-Server erhältlich: ftp.heise.de/pub/ix/