Aha.
Da ist in den meisten Fällen kein böser Wille. Da sitzt natürlich keiner und denkt sich “hehe, die dummen Nutzer zock ich jetzt ab und mach einen Deal mit Google/Facebook”.
Natürlich ist da böser Wille. Vielleicht nicht im Maschinenraum, aber dann auf jeden Fall weiter oben.
Es kommt niemand daher und sagt: „ach die arme Buchhaltung, ist immer völlig überfordert, da ist kein böser Wille“ wenn die Schlagzeile „Telekom unterschlägt 5 Mrd € Steuern“ heißt, oder?
Du verstehst den Unterschied zwischen Vorsatz und Fahrlässigkeit anscheinend nicht. Oder du verstehst die Analyse der Daten in dem Blogpost völlig falsch und leitest daraus Vorsatz ab. Dann argumentierst du allerdings seltsam.
Danke, ich verstehe den Unterschied und den Blogpost sehr gut.
Ein Unternehmen der Größe Telekom macht derartige Dinge nicht „fahrlässig“.
Wenn ich ein Produkt in Verkehr bringe, bin ich als Unternehmen verpflichtet, das auf Einhaltung aller einschlägigen Normen zu kontrollieren.
Es ist jetzt kein arkanes Wissen, dass es die DSGVO u.ä. gibt, da wird nicht versehentlich gegen irgendeinen obskuren Paragrafen von 1897 verstoßen. Es geht um den Kernbereich der Rechtsnormen für digitale Produkte.
Ein Unternehmen, welches ganze Kanzleien beschäftigt, entscheidet sich ganz bewusst dafür diese Sachen nicht zu kontrollieren bevor sie in Verkehr gebracht werden.
Das ist dann mindestens Eventualvorsatz.
Kanzlein und “Winkeladvokaten” (wie du es vorhin nanntest) machen keine Code- und Sicherheitsanalysen. Wenn denen die Entwicklungsabteilung nicht sagt, dass sie irgendwas machen, was geprüft werden muss, prüft auch keiner. Und wenn in der Entwicklungsabteilung keiner weiß, dass ihr Crashreporter PII leaked, gibt’s aus ihrer Sicht auch nichts zu prüfen.
Ich denke auch eher das läuft unter billigend in Kauf genommen und fahrlässig als unter Vorsatz.
Bei dem Dependency-Dschungel in modern entwickelten Anwendungen ist das halt auch Sackgang. Selbst mit einem gut gepflegten SBOM fällt sowas ggf. nicht auf.
Letztlich hätte man halt genau die Analyse machen lassen müssen, die Kuketz gemacht hat. Also die App einem Security Spezialisten geben, der das Ding auf Herz und Nieren prüft, und alle Datenflüsse ermittelt. Die hätte man dann wiederum einem Datenschützer vorlegen müssen, der das bewertet. Dann zurück zum Architekten, der die technische Notwendigkeit eruiert.
Und da sind wir halt wieder bei dem viel zu schnellen Entwicklungszyklus, der heutzutage erwartet wird. So eine Prüfung passt halt besser in ein Wasserfall-Modell, als zu agiler Softwareentwicklung. Und bei der Zeit (und Geld), die solche Prüfungen kosten, macht man das halt nicht jede Woche.
