Technologie, maximal dämlich genutzt

Neulich so in einem fernen Urlaubsland meiner Wahl. Nutzung von werbefinanzierten Streamingdiensten. Ich will nicht ins Detail gehen und nenne sie stellvertretend mal „YouTube“ und „Spotify“. Beide Dienste jedenfalls verfügen über weitergehende Informationen über mich – oder zumindest gehe ich davon aus, man hört ja so viel von der Datensammelwut der Anbieter. Also z.B. Informationen wie „Mailadresse“, „Name“ und „aus welchem Land wurden bisher die Dienste genutzt“ und „in welcher Sprache wurde bisher Content bevorzugt abgerufen“.

Nun sitze ich also hier im Urlaubsland meiner Wahl – ich will es nicht spoilern, aber es ist nicht deutschsprachig – und erfreue mich an Werbeeinsprengseln in einer mir fremden Sprache. Nämlich der des Urlaubslandes. Die fortschrittliche Technologie erlaubt es also, meinen derzeitigen Standort zu erkennen. Und bezieht dieses (in den 80ern hätte man gesagt: erstaunliche) Wissen dämlicherweise in die Entscheidung ein, in welcher Sprache mir Werbung eingespielt wird. Weil ich natürlich, sobald ich eine Landesgrenze überquere, plötzlich die Sprache des Ziellandes bevorzuge.

Es braucht schon fortgeschrittene KI, um die Wirksamkeit von Werbung derart nachhaltig zu torpedieren. Oder sehr dumme Entscheidungen von Produktverantwortlichen.

Sekunden? Minuten? Egal!

Man geht ja als ITler gerne mit der Zeit. Mindestens, um sich dann darüber aufzuregen, dass früher alles besser war.

Neulich habe ich einen neuen Drucker in Betrieb genommen. Geht jetzt per App. Klingt nach einer guten Idee, und war es letztlich auch. Aber zwischendrin dann etwas Schockierendes: bei der Erstbefüllung der Tintentanks kündigte die App an, dass das Befüllen einer Farbe (bei meinem Modell insgesamt 6) nicht weniger als 40 Minuten dauern soll. Gott sei Dank nur eine falsche Einheit in der App, die gedruckte Schnellanleitung sprach dann korrekt von 40s, und genau so war es.

Weiterer kleiner Zwischenfall: während der Drucker dann die Tinteninitialisierung vornimmt, schlägt die App vor, doch gleich mal währenddessen (der Initialisierungsvorgang dauert nicht weniger als 7 Minuten) das WLAN einzurichten. Gute Idee. Dazu braucht man das Admin-Passwort des Druckers. Das steht nur im Innern des Druckers (beim Anheben der kompletten oberen Einheit). Das Anheben ist aber genau das, was man während der Tinteninitialisierung AUF GAR KEINEN FALL machen darf, wie der Drucker auf seinem Display verkündet. Sagt einem die App aber nicht. Aber der erfahrene Installateur elektrischer Geräte hat vorher natürlich alle papiernen Handbuchfetzen (die meisten davon mit völlig überflüssigen Sicherheitshinweisen der Kategorie „Gerät eingesteckt nicht unter Wasser betreiben“ oder „auf Frequenz 2400 MHz wird mit 53 nW gesendet“) akribisch durchgearbeitet und hat deshalb das Passwort schon vorher notiert. Auch merkwürdig in der App: man hat es für notwendig erachtet, eine eigene Tastatur zu implementieren. Die echt komisch aussieht. Und für die Eingabe sicherer Passwörter gar nicht taugt. Aber man kann einfach auf die Standardtastatur zurückschalten. Könnte für den unbedarften Anwender aber schon eine Extrahürde sein, und der Sinn dahinter erschließt sich mehr jetzt nicht so direkt.

Auch eine App löst halt nicht automatisch alle Probleme, vor allem wenn vom Hersteller schlampig gearbeitet wird. Drucken tut er aber gut. Und das ist in diesem Falle wirklich die Hauptsache.

Fortgeschrittene 2-Faktor-Authentifizierung

Neulich im Dunstkreis von Zahlungsdienstleistungen. Ich wollte bei einem Vertrag meine Mobilfunknummer ändern. Übers Webinterface eingeloggt und die Nummer geändert. Ein Popup informiert mich darüber, dass das leider gar nicht so einfach möglich sei, denn die Mobilfunknummer werde mittels SMS-TAN als zweiter Faktor für Authentifizierung genutzt. Ich hätte die Wahl zwischen Brief-TAN – dann müsse ich aber beim Service-Center anrufen und dies veranlassen – oder könnte die App nutzen, dort die Mobilfunknummer ändern, und bekäme dann eine SMS-TAN.

So weit, so plausibel – natürlich ging ich davon aus, dass ich dazu dann zwei Handys (oder in Zeiten von Dual-SIM: zwei Rufnummern) benötige, einmal die alte hinterlegte Nummer und einmal die neu zu hinterlegende Nummer. Die Frage „warum kann ich nicht einfach mit der alten Nummer und einer SMS-TAN die neue Nummer authentifizieren“ stellte ich mir, beantwortete sie mir aber mit dem naheliegenden „die Software kann das vermutlich nicht, weil einer vergessen hat, diesen Fall zu spezifizieren“.

Also die App auf dem neuen Handy installiert, über die App eingeloggt (gleiche Credentials wie das Webinterface), Mobilfunknummer geändert, und die SMS-TAN auf die neue (!) Mobilfunknummer bekommen. Also auf dasselbe Gerät, auf der die App läuft.

Freunde: so funktioniert das nicht mit der 2-Faktor-Authentifizierung. Das ist einfach nur Bullshit und Pseudo-Security.

 

Windows-Fehlermeldung des Monats

Neulich am Windows 10-Rechner meiner Wahl. Daten werden auf einen USB-Stick kopiert zwecks Transfer zu einem nicht netzwerkfähigen Gerät. Zielformat FAT32. Kommt bei einer Datei mittendrin folgende Fehlermeldung:

„Fehler x80240022: Im Laufwerk befindet sich eine falsche Diskette. Legen Sie %2 (Datenträgernummer: %3) in Laufwerk %1 ein.“

Nur echt mit nicht aufgelösten Platzhaltern. Das einzig Gute, was man über diese Fehlermeldung sagen kann: sie ist dermaßen absurd neben der Spur, dass man wenigstens nicht in Versuchung kommt, einer falschen Fährte zu folgen.

Gruseliger als diese Fehlermeldung – und da liegt die Latte wahrlich hoch – ist nur, wenn man nach der Fehlernummer googelt und diverse Artikel in der Microsoft-Knowledge-Base darüber findet. Mein Favorit: wenn der Fehler unter Windows 2000 auftaucht, wenn man den Microsoft Defender updated, muss man die Root Certificates erneuern oder installieren…

Gedanken zum aktuellen Log4j-Problem

Viele haben sich schon zu unterschiedlichen Aspekten des aktuell in der Sonne der Aufmerksamkeit stehenden Log4j-Remote-Code-Execution-Problems-durch-clever-formulierten-User-Input-der-geloggt-wird geäußert. Mir fällt dabei vor allem auf, dass die meisten Kommentatoren zwar kleine Teilaspekte des zugrundeliegenden Problems meist korrekt beschreiben, es aber an abwägendem sowohl-als-auch eher mangelt. Denn m.E. ist diese Misere keins von den Problemen, die eine einfache Lösung haben.

Ich kann mit vielen der bereits von Anderen genannten Teilaspekte mitgehen. Ja, in Java kann man z.B. durch fortgeschrittene Featuritis und Libraritis und Frameworkitis sehr komplexe Lösungen bauen, die keiner mehr durchschaut. Aber das geht in praktisch jeder Programmiersprache, außer in denen, die schon unhandlich werden, sobald man versucht mäßig komplexe Probleme zu lösen. Hier ein Java-Spezifikum zu sehen ist komplett absurd. Ja, 3rd-party-Abhängigkeiten die man nicht durchverstanden hat sind potenziell gefährlich. Aber selbstgebaute Lösungen sind ebenfalls gefährlich. Ja, der Zeitdruck und die inadäquate Bezahlung in vielen Softwareprojekten ist eine der vielen Problemursachen. Aber auch ohne Zeitdruck und mit unendlichen Mitteln können Katastrophen programmiert werden. Ja, man sollte danach streben, möglichst einfache Lösungen zu bauen. Aber einfache Lösungen, die gleichzeitig problemadäquat sind, fallen auch nicht vom Himmel und brauchen Zeit und Geld – Vereinfachung ohne es zu einfach zu machen ist eine hohe Kunst.

Beim gerade aktuellen Problem kann man es sich einfach machen und sagen „was kann an Logging schon so schwer sein“. Ja dann nehmt doch einfach System.out.println, wenn das ausreichend ist. Kurze Zeit später werdet ihr feststellen, dass es ganz nützlich wäre, mehrere Logkanäle zu bedienen. Den Loglevel von außen konfigurierbar zu machen. Beim Schreiben von Logfiles jedes einzelne File nicht zu groß werden zu lassen. Auf Effizienz beim Loggen achten, also am besten asynchron arbeiten. Und die Log-Datenbank xy anbinden. Für das Loganalysetool der Wahl den Timestamp der Logmeldung parametrierbar zu machen. Ich glaube nicht, dass eine signifikante Anzahl der Log4j-Features „einfach so“ eingebaut wurden, da steckt schon jeweils ein valider Usecase dahinter. Und es hat seinen Grund, warum es nicht nur Log4j gibt, sondern auch JUL oder Logback oder tinylog – oder der gute alte IBM LogManager, falls den noch jemand kennt. Wer die Features eines Log4j nicht will oder braucht, versteckt sich hinter slf4j und überlässt dem Kunden die Auswahl der finalen Logimplementierung – aber öffnet gleichzeitig einen interessanten neuen Angriffsvektor, wenn Schadcode beim Deployment als slf4j-implementierendes Jar eingeschleust wird. Und wenn ich dann nach aufwändiger Analyse zum Schluss komme, dass Logback alle meine Wünsche erfüllt, kommt morgen eine neue Anforderung um die Ecke, die nur durch Log4j abgebildet werden kann – was dann? Anforderung ablehnen? Lib wechseln? Von vorne anfangen?

Man soll sich keinen Illusionen hingeben. Was bei Log4j passiert ist, kann mit jeder Programmiersprache, auf jedem Betriebssystem, ja sogar auf jeder CPU passieren. Spectre konnte über JavaScript im Browser ausgenutzt werden – noch so viele Schichten zwischen Quellcode und Ausführung haben uns nicht vor den Auswirkungen eines CPU-Bugs geschützt. Schon im guten alten Z80 gab es „illegale“ Opcodes, die trotzdem etwas Vernünftiges gemacht haben, als Seiteneffekt der Implementierung. Nur 8500 Transistoren, und trotzdem ein solcher „Bug“ (oder „Feature“, je nachdem wen man fragt). Der aktuelle Apple M1 Max besteht aus 57 Milliarden Transistoren. Natürlich nicht direkt vergleichbar, weil jede Menge Cache damit realisiert ist, aber auch durch Caches können ja interessante Effekte entstehen (Stichwort Seitenkanalangriff). Jedenfalls ein geeignetes Beispiel für die immens gewachsene Komplexität auf allen beteiligten Ebenen.

Ich bin auch ein Fan davon, mit möglichst wenigen Abhängigkeiten in meinen Java-Anwendungen auszukommen. Aber diese Strategie trägt eben auch nicht unendlich weit. Beispiel: wenn Persistenzierung in einer Datenbank gefragt ist, kann man von Hand JDBC machen oder Hibernate verwenden oder JPA oder JDO oder was auch immer das Framework der Wahl so mitbringt. Oder man speichert seine Daten in einer simplen Datei. Oder doch über BerkeleyDB oder SQLite? Wenn die Anforderung lautet, einen Webservice zu schreiben, beginnt man dann mit seinem eigenen Server und seiner eigenen Security-Schicht, oder nimmt man doch was von der Stange und vertraut darauf, dass die Profis es entwickelt haben? Ist eine Bibliothek, die hundert unnütze Funktionen zusätzlich zu den für mich nützlichen zehn bietet, denn notwendigerweise die falsche Wahl, wenn die Konkurrenzbibliothek mit nur zwanzig unnützen Funktionen z.B. closed source ist oder viel weniger Nutzer hat oder eine viel kleinere Community? Oder alles drei? Ist es wirklich sinnvoll, sich auf den Featureumfang der Java-Plattform zu beschränken und sklavisch auf 3rd-party-Libs zu verzichten – ist denn sichergestellt, dass die „Bordmittel“ wirklich von höherer Qualität sind als Drittbibliotheken?

Auf Basis von Post-hoc-Erkenntnissen klug daher schwätzen („hättet ihr mal nicht Log4j verwendet“ – ersetze Log4j durch „Intel-CPU“ oder „OpenSSL“ oder „PHP“ oder „Linux“ oder „Docker“ oder „IIS“ oder „Applets“) kann jeder. Aber was ist die „richtige Strategie“ im Angesicht des Ungewissen, wenn man vor einer erheblichen zu implementierenden Komplexität steht, die nicht mal schnell ein Profi-Entwickler im Alleingang und minimalen Abhängigkeiten hindengelt (und dieser Profi dann auch dauerhaft für die Wartung zur Verfügung stehen muss)? Es wird letztlich immer eine Abwägungsfrage bleiben. Tritt kein Problem auf, war die Abwägung tendenziell richtig – oder man hat einfach nur Glück gehabt.

Vermutlich ist das die einzige vielversprechend Strategie. Einfach Glück haben.

Da fällt mir ein: schon 2015 habe ich unter der schönen Wortschöpfung „Abstraktionskaskade“ diese Problematik beleuchtet. Und schon damals war ich nicht der erste.

Gastbeitrag: Ein Nachruf für meinen Audi A6 Avant

Vorwort von hubersn: Jeder große Blog veröffentlicht regelmäßig Gastbeiträge. Vermutlich ist die Kausalität dieser Korrelation so, dass der Blog erst mal groß wird und dadurch zu Gastbeiträgen kommt. Ich versuche es jetzt mal andersrum. Denn das Schicksal wollte es so, dass mein lieber Freund und Kollege Roland ein ähnliches Schicksal erfuhr wie ich – ein hoffentlich nur temporärer, kurzer Wechsel von einem „Wunschfahrzeug“ zu einem „war-gerade-übrig-Fahrzeug“. Da hier im IT-Blog regelmäßig über schlechte Usability und bescheuerte Oberflächen geschimpft wird, erschien mir sein Beitrag sehr passend – mein Beitrag zu diesem Thema folgt demnächst. Aber genug der Vorrede, lassen wir Roland zu Wort kommen…

Es war ein trauriger Tag. Ich verabschiedete mich nach drei Jahren von meinem geliebten, geleasten Firmenwagen. Der Nachfolger sollte ein A5 Cabrio werden… aber mein Chef hatte eine andere Idee.

Und so erlebte ich völlig neue Erfahrungen. Ich hätte nicht gedacht, dass Audi noch so viel Vorsprung durch Technik hat. Aber eins nach dem anderen. Ein Jetzt-Ex-Kollege hat einen wenige Monate neuen Volvo V90 hinterlassen und mein Chef sagte, jetzt fährst Du den mal. Ich sagte maximal ein Jahr – ich hatte da so eine Vorahnung. China und Schweden. Geht das gut?

Guten Mutes fuhr ich also mit dem V90 los. Ich fahre jede Woche gut 400 Kilometer Autobahn und da ruft mich gerne eine Kollegin an. Auf einer der ersten Fahrten war das mal wieder der Fall. Auf dem BlackBerry unserer Firma hat sie mich nicht erreicht. Warum? Ich habe es bisher nicht geschafft, dem Volvo beizubringen, dass ich zwei aktive Mobilverbindungen benötige. Vielleicht lese ich doch irgendwann die im Auto integrierte Anleitung, die man nur im Stand lesen kann. Es gibt ja keine Beifahrer, die während der Fahrt lesen können – so etwas ist in Europa nicht denkbar. Zum Glück kennt meine Kollegin meine private Nummer. Ich gehe ans Telefon, wir sprechen kurz. Dann fragt sie mich leicht verwirrt, was ich denn gerade mache. Sie dachte, ich wäre im Auto unterwegs. Ich sage, dass ich im Auto unterwegs bin. Sie meint, es gäbe so laute Nebengeräusche und sie versteht mich so schlecht. Ich sage nur: „Ich fahre jetzt Volvo“.

Die schönste Neuerung im Volvo ist das große, glänzende Touch-Display über der Mittelkonsole. Da freut man sich. Super hell und nur im Nachtmodus dimmbar. Ja, tatsächlich funktioniert der Drehknopf links neben dem Lenkrad nur im Nachtmodus – wirkt sich aber selbstverständlich auf den Tagmodus aus. Man muss also einen Tunnel finden, um tagsüber die Einstellung zu ändern. Schon mal das Wort Benutzerfreundlichkeit in Schweden gehört? Nix „lindra“ im Volvo.

Das ist aber nicht die größte Schwäche des tollen Displays. Das ist der Touch selbst. Man wird wahnsinnig in Kombination mit Android Auto. Ob es an Google oder Volvo liegt ist mir egal. Im Stand kann man Audible, Amazon Music und Google Maps wenn man sich am Rand des Displays festhält ja noch halbwegs bedienen. Aber während der Fahrt wird das zum Geduldsspiel. Man tippt lässig, um eine Aktion auszuführen. Das Display scrollt hoch und runter ganz munter aber Aktionen ausführen – seltenst. Da muss man vorausschauend fahren und an roten Ampeln die Playlist auswählen – mit ruhiger Hand. Wer keine ruhige Hand hat – Finger weg vom Volvo!

Es gibt ein zweites, mattes Display hinter dem Lenkrad. Vom Audi gewohnt, suche ich heute nach 6 Monaten immer noch nach dem Schalter, welcher die Karte da vorne verdrängt und mir sinnvolle Dinge anzeigt. Fehlanzeige. Oder zu gut versteckt im Handbuch? Tipps nehme ich gerne entgegen.

Von A nach B fährt inzwischen jedes Auto. Wenigstens meistens. Mein Audi konnte bei 220 km/h noch die Kurve alleine fahren. Beim Volvo ist bei knapp 140 km/h Schluss. Ist ja klar. Die Schweden haben sich für die Höchstgeschwindigkeit 120km/h entschieden. Da darf man alles darüber nicht testen und schaltet einfach ab. Und dann ist der Volvo ein Nervenbündel beim Spurhalten. Zuckelt links und rechts anstatt ruhig und elegant wie der Audi zu fahren. Was für ein Rückschritt zu einem mindestens drei Jahre älteren Audi. Vorsprung durch Technik kann ich da bestätigen.

Man erträgt es halt und wendet sich den guten Dingen im Volvo zu. Die Sitze sind wirklich gut. Leder. Und der Volvo speichert alle möglichen und unmöglichen Einstellungen in einem Fahrerprofil im Schlüssel. Leider auch wenig durchdacht. Ich würde lachen, wenn es nicht so traurig wäre. Umluft kann man auch ganz einfach mit wenigen Berührungen der sehr großen Schaltflächen aktivieren. Umständlicher als jeder Knopf wie man es von früher kennt. Vor Touch im Auto. Gute Zeiten waren das, sage ich euch. Mit viel Tippen und Wischen findet man viele Einstellungen. Während der Fahrt nur ratsam, wenn man den Zappelphilipp von Pilot-Assistent aktiviert. Und immer schön hin- und herschauen, ob im matten Display das Lenkrad grün ist, sonst zappelt nichts mehr von alleine am Lenkrad. Dann ist der Assistent plötzlich aus.

Lustig – eher traurig – ist auch der Assistent, der verhindern soll, dass man beim Rückwärts- oder langsam Vorwärtsfahren nichts beschädigt. Das Ding geht aber manchmal plötzlich aus und man merkt es nicht. Damit ist es irgendwie sinnlos geworden, oder?

Zur Verarbeitung: Ich habe Grünschnitt transportiert und die klapprige Kofferraumabdeckung entfernt. Danach schnell wieder einbauen. Denkste. Die rastet irgendwie nicht ein. Ich wollte schon den Hammer holen. Beim Audi flutscht das nur so. Klack und fertig. Okay. Beim Audi wiegt das Ding das Zehnfache. Wirkt solide und funktioniert. Und dann frisst die Volvo Abdeckung auch noch eine Ecke meiner besten Wellensteyn-Jacke! Die Ablage oben sollte man niemals für Jacken benutzen! Das steht bestimmt im Handbuch. Habe ich ja nicht gelesen. Bin da halt noch Papier gewöhnt. Beim Öffnen frisst der Einzug die Jacke an und gibt sie nicht mehr her! Schließlich musste ich die Jacke herausreißen und damit eine Ecke am Kragen abreißen.

Neulich dann der Höhepunkt. Mein Chef fährt mit und ist ganz begeistert, wie toll das Auto ist. Nun muss man wissen, dass mein Chef das älteste Technik-Kind der Welt ist, Porsche fährt und jeden Technikschnickschnack liebt. Er kennt sich aus und steigt ein und meint, dass man da aber toll sitzt und das wäre ja ein super Display. Wow! Gestochen scharf. Ich meine nur: Aber nicht bedienbar – touch.

Das probiert der Chef begeistert aus und will mit Google Maps das Ziel eingeben. Er versucht den Knopf für das Mikrofon auszulösen. Wir fahren bereits. Beim 5. Versuch klappt es – wir stehen an der Ampel. Google findet das Ziel und Chefe will es auswählen zum Starten der Navigation. Im Heslacher Tunnel beweise ich ihm, dass man das Display tatsächlich abblenden kann – nur im Tunnel. Schon nach dem Tunnel schaffen wir es die Navigation zu starten. Jetzt bräuchten wir wieder einen Tunnel, damit wir das Display wieder heller machen können. Google lenkt uns nach rechts vorbei am nächsten Tunnel. Blöd gelaufen.

Ich denke, beim nächsten Gespräch mit meinem Chef gesteht er mir im Frühjahr ein Cabrio zu. Ich bin ja als Bereichsleiter durchaus ein Mitarbeiter, den man halten will, oder?

Roland

Die zunehmende Entmündigung des Nutzers

Gerade hat sich mein Kindle eigenmächtig upgedated. Als ich ihn ein paar Minuten unbeaufsichtigt zwecks Lesepause, aber noch verbunden mit dem WLAN, liegen gelassen habe. Und es hat Minuten gedauert. Und er hat den alten Lesezustand leider vergessen. Ich hatte vor ein paar Tagen das Update noch explizit abgelehnt aufgrund von „never change a running system“.

Das ist eine zunehmende Unsitte von IT aller Art, gar nicht mehr auf die Zustimmung des Nutzers zu warten, ihn gar nicht mehr zu informieren was denn das Update so macht. Ihm die Entscheidung zu überlassen. Wäre auch nicht das erste Mal, dass Features von einer Version zur nächsten einfach Verschwinden. Zurück zu einer älteren Version kann man ja auch nur noch in den seltensten Fällen. Der Traum eines modularen Upgrademechanismuses, wo man „pick and mix“ mit gewünschten und unerwünschten Updates machen kann, ist ja schon seit Jahrzehnten ausgeträumt. Langfristige Stabilität und Support etwas von gestern – Vorwärtsstrategie scheint das neue Zauberwort.

Irgendjemand wird jetzt sicher „Security“ sagen. Ja, dann macht es doch einfach sicher. Ein stabiler Branch mit aktuellen Sicherheitspatches. Einen Development-Branch für die Mutigen. Das wäre das allermindeste, denn bei der üblichen Qualität heutiger Softwareentwicklung bedeutet ja jede Änderung ein neues Sicherheitsrisiko. Und bei einem komplett vernagelten System wie dem Kindle kann Security wohl kaum ein Argument sein, oder jemand hat wirklich Scheiße gebaut.

Ich hasse Intransparenz. Besonders, wenn es um meine eigenen Geräte geht. Macht im Web was ihr wollt. Aber nicht auf meinen Geräten.