Viele Entwickler setzen viel zu oft leichtfertig irgendwelche Bibliotheken und Toolkits ein, ohne sich wirklich damit zu beschäftigen, was die eigentlich genau treiben. 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”.
Aber es ist halt fahrlässig und zum Teil Faulheit. Man braucht Crashreports? Super, gibt’s schon. Eine Abhängigkeit rein, paar Einstellungen gesetzt, läuft.
Das betrifft auch nicht nur große Firmen. Das machen einzelne Entwickler, kleine Softwarebuden, usw. Die Erwartungshaltung, dass Software in kurzer Zeit fertig werden muss und möglichst im Wochen-Turnus neue Funktionen erhalten muss, befeuert das Problem und die oberflächliche Herangehensweise nur weiter. Gute Software, die richtig durchdacht und optimiert wird, gibt es immer seltener, bzw. geht immer häufiger in der Masse an rausgerotzter Software unter.
Mag ja sein, aber was soll das für eine Rechtfertigung sein?
Von Seiten der Coder mag das vertretbar sein zu sagen: die stehen unter Druck und nehmen das was am schnellsten Ergebnisse liefert.
Von Seiten des Unternehmens ist das in keiner Weise vertretbar, erst recht nicht bei einem Unternehmen wie der Telekom. Die kennen die nötigen Rechtsnormen. Und scheißen drauf.
Und da kann man nicht mehr mit „Zeitdruck“, „Faulheit“, etc. argumentieren. In anderen Bereichen nehmen die sich auch sehr viel Zeit und Geld, oder was meinst du wieviel Winkeladvokaten da beschäftigt sind noch den letzten Cent an Steuern wieder zurückzuholen.
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.
@aksdb@yA3xAKQMbq bei großen Prozessen gibt es keine Fahrlässigkeit.
Die Telekom hat genug Geld und hat Verantwortliche die sich für bestimmte Dinge entscheiden. In diesem Fall haben die sich dagegen entscheiden es ordentlich zu machen. Das ist Vorsatz.
Fahrlässigkeit ist wenn einer den Gurt für die Ladungssicherung anbringt aber nicht ausreichend festzieht.
Wenn das nicht Vorsatz wäre, kannst du das Konzept von Gesetzen wegwerfen, weil dann meint keiner nie was und alles ist aus Versehen.
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.
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.
Dafür, dass du nichts rechtfertigen möchtest, gibst du dir aber redlich Mühe, auch noch für den dämlichsten Quatsch eine „Erklärung“ zu finden.
Wie ich gerade schon in einem anderen Kommentar sagte: es handelt sich hier auch nicht um irgendeinen seltsamen Bug, der nur unter einer bestimmten Bedingung auftritt, und den irgendein l33t h4x0r gefunden hat. Die App sendet direkt nach Start Daten, die sie nicht senden darf.
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.
Ich glaube eher, du hast den Blogpost nicht verstanden.
Um nachzuvollziehen, dass eine Anwendung ohne Einverständnis Dinge anpingt, brauche ich das nicht „auf Herz und Nieren“ zu überprüfen. Da schaltet man einen Proxy zwischen, startet die App, und dann sieht man das. Audit beendet.
Sowas zählt zur zentralen Sorgfaltspflicht bei der Entwicklung digitaler Produkte.
Viele Entwickler setzen viel zu oft leichtfertig irgendwelche Bibliotheken und Toolkits ein, ohne sich wirklich damit zu beschäftigen, was die eigentlich genau treiben. 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”.
Aber es ist halt fahrlässig und zum Teil Faulheit. Man braucht Crashreports? Super, gibt’s schon. Eine Abhängigkeit rein, paar Einstellungen gesetzt, läuft.
Das betrifft auch nicht nur große Firmen. Das machen einzelne Entwickler, kleine Softwarebuden, usw. Die Erwartungshaltung, dass Software in kurzer Zeit fertig werden muss und möglichst im Wochen-Turnus neue Funktionen erhalten muss, befeuert das Problem und die oberflächliche Herangehensweise nur weiter. Gute Software, die richtig durchdacht und optimiert wird, gibt es immer seltener, bzw. geht immer häufiger in der Masse an rausgerotzter Software unter.
Mag ja sein, aber was soll das für eine Rechtfertigung sein?
Von Seiten der Coder mag das vertretbar sein zu sagen: die stehen unter Druck und nehmen das was am schnellsten Ergebnisse liefert.
Von Seiten des Unternehmens ist das in keiner Weise vertretbar, erst recht nicht bei einem Unternehmen wie der Telekom. Die kennen die nötigen Rechtsnormen. Und scheißen drauf.
Und da kann man nicht mehr mit „Zeitdruck“, „Faulheit“, etc. argumentieren. In anderen Bereichen nehmen die sich auch sehr viel Zeit und Geld, oder was meinst du wieviel Winkeladvokaten da beschäftigt sind noch den letzten Cent an Steuern wieder zurückzuholen.
Gar keine? Oder warum hab ich von “fahrlässig” gesprochen? Erklärung != Rechtfertigung.
Aha.
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.
@aksdb @yA3xAKQMbq bei großen Prozessen gibt es keine Fahrlässigkeit.
Die Telekom hat genug Geld und hat Verantwortliche die sich für bestimmte Dinge entscheiden. In diesem Fall haben die sich dagegen entscheiden es ordentlich zu machen. Das ist Vorsatz.
Fahrlässigkeit ist wenn einer den Gurt für die Ladungssicherung anbringt aber nicht ausreichend festzieht.
Wenn das nicht Vorsatz wäre, kannst du das Konzept von Gesetzen wegwerfen, weil dann meint keiner nie was und alles ist aus Versehen.
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.
Lol, ja danke, weiss ich auch.
Dafür, dass du nichts rechtfertigen möchtest, gibst du dir aber redlich Mühe, auch noch für den dämlichsten Quatsch eine „Erklärung“ zu finden.
Wie ich gerade schon in einem anderen Kommentar sagte: es handelt sich hier auch nicht um irgendeinen seltsamen Bug, der nur unter einer bestimmten Bedingung auftritt, und den irgendein l33t h4x0r gefunden hat. Die App sendet direkt nach Start Daten, die sie nicht senden darf.
Da gibt es nichts dran zu „erklären“.
Na was glaubst du denn, wieso ich in meinem initialen Kommentar den Entwicklungsprozess kritisiere?!
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.
Ich glaube eher, du hast den Blogpost nicht verstanden.
Um nachzuvollziehen, dass eine Anwendung ohne Einverständnis Dinge anpingt, brauche ich das nicht „auf Herz und Nieren“ zu überprüfen. Da schaltet man einen Proxy zwischen, startet die App, und dann sieht man das. Audit beendet.
Sowas zählt zur zentralen Sorgfaltspflicht bei der Entwicklung digitaler Produkte.
Genau so läuft es in der Realität aber ja gerade nicht ab! Darum kritisier ich das doch!
Das ist sogar gleich im ersten Satz meines Kommentars!
Billigend in Kauf nehmen ist Eventualvorsatz:
https://de.wikipedia.org/wiki/Eventualvorsatz
Danke für die Korrektur. Dann ist wohl beides möglich.