Versicherungsdaten als Mittel zur Bewertung der Sicherheit von autonomen Fahrzeugen

ihbrune

Auch wenn wir in Deutschland keine kurzfristige Aussicht darauf haben, von einem echten, sich autonom steuernden Fahrzeug chauffiert zu werden: Das Thema ist in den Köpfen. Bei einem Essen mit Freunden kamen wir über KI auch auf selbstfahrende Autos und sogar die gerade zufällig an den Tisch kommende Kellnerin, die bis dahin eher kurz angebunden war, brachte sich ein und steuerte Erinnerungen an K.I.T.T. bei. Aber auch die Aussage, dass sie sich so etwas für sich nicht vorstellen könne.

Die Angst vor dem lenkradlosen Auto

Auch in unserer Runde war eher die Meinung, sich nicht auf so ein System verlassen zu wollen. Das man als Softwareentwickler nur zu gut weiß, was alles schief gehen kann bei der Programmierung eines so komplexen Produkts, ist die eine Seite. Aber auf der anderen Seite fliegen wir auch mit Flugzeugen, die bereits weitestgehend von Automaten bedient werden und in denen ich als Passagier keinerlei Bezug zu den Personen habe, die vorne die Kontrolle ausüben. Und im Straßenverkehr erleben wir eigentlich jeden Tag Mitmenschen, die sich riskant verhalten. Und manchmal ist man selbst das Risiko, auch wenn ich bei den bisher zwei schweren Autounfällen in meinem Leben immerhin nur in einem Fall Schuld war und zum Glück keine anderen Personen verletzt wurden.

Konzeptbild für ein selbstfahrendes Fahrzeug in den Straßen einer Stadt
Konzeptbild für ein selbstfahrendes Fahrzeug. Generiert mit Midjourney

Sicher gibt es eine hohe Berichtsdichte über Fehlleistungen der selbstfahrenden Fahrzeuge, so kann man sich auch in deutschsprachigen Medien detailliert über Unfälle und Merkwürdigkeiten wie nächtliche Hupkonzerte auf dem Laufenden halten. Erleichert wird dies durch engmaschige Berichtspflichten, die US Behörden den Herstellern entsprechender Fahrzeuge auferlegt haben, teilweise verbunden mit einer Pflicht zur Offenlegung der Vorfälle im Netz. Aber ist eine ‚übertriebene‘ Berichtserstattung Schuld am Gefühl, dass autonome Fahrzeuge unsicher sind?

Von Waymo wurde jetzt ein interessanter, neuer Ansatz vorgestellt, um die Sicherheits von automonen Fahrzeugen zu beurteilen. Diese werden im weiteren mit ADS – Autonomous Driving Systems – bezeichnet, die von menschlichen Fahrer*innen gesteuerten Fahrzeuge mit HDV – Human-Driven Vehicles.

Was ist Waymo

Waymo ist aus dem Google Projekt zur Entwicklung eines selbstfahrenden Autos hervorgegangen und eine Tochtergesellschaft der Alphabet Holding, zu der auch Google gehört. Waymo ist heute das einzige Unternehmen, welches kommerzielle, nicht mehr von Sicherheitsfahrer*innen begleitete, autonome Fahrten in 4 US Städten anbieten darf (‚Robotaxis‘). Und zwar inzwischen in erheblichem Umfang:

Laut Alphabet Q3 Quartalsbericht werden nun pro Woche 150.000 vollautonome, kommerzielle Fahrten durchgeführt und dabei jeweils mehr als eine Million Meilen zurückgelegt:

Now, each week, Waymo is driving more than one million fully autonomous miles, and serves over one hundred and fifty thousand paid rides — the first time any AV company has reached this kind of mainstream use.

Damit bilden die Fahrleistungen der Waymo Fahrzeugen die umfangreichste Datensammlung zur ADS Performance in echten Verkehrssituationen, die heute zur Verfügung steht.

Der lange, langsame Weg zum selbstfahrenden Auto

Auf dem langen Weg von ersten Fahrversuchen auf Übungsgeländen bis hin zum heute erreichten Stand war Waymo immer wieder das Objekt kritischer Berichterstattungen und hoher, öffentlicher Aufmerksamkeit. Auch wenn die Versprechungen nie so vollmundig waren wie die von Konkurrenten (Tesla), so waren die Erwartungen doch hoch, das Problem des ‚Roboterautos‘ schnell lösen zu können. Auch bei Chris Urmson, der in 2015 der Leiter des Google Projekts war, und der damals auf einem TED Talk diesen Satz sagte:

My oldest son is 11, and that means in four and a half years,  he’s going to be able to get his driver’s license. My team and I are committed to making sure that doesn’t happen.

Man kann sagen, dass diese Zeitlinie deutlich verfehlt wurde. Was aber vermutlich eher der Sorgfalt geschuldet ist, mit der bei Waymo an der Aufgabe gearbeitet wurde, und durch die zwar kein großer Marketinghype (Tesla), aber auch keine Todesopfer (wieder Tesla, aber auch Uber) verursacht wurden. Trotzdem wird in den Köpfen vermutlich hängen bleiben, dass selbstfahrende Fahrzeuge (noch) nicht perfekt sind, und dabei nicht groß zwischen den Anbietern unterschieden.

Waymo Safety Impact

Waymo geht dieses Thema in einer eigenen Webseite an, die sie mit Safety Impact betiteln. Hier stellen sie ihre Unfallzahlen dar und ziehen auch umfangreiche Vergleiche mit der Unfallhäufigkeit von durch menschliche Fahrer*innen gesteuerte Fahrzeuge (hier als Benchmark bezeichnet):

Ausschnitt aus der Waymo Safety Impact Seite: Vergleich von Unfallzahlen
Ausschnitt aus der Waymo Safety Impact Seite: Vergleich von Unfallzahlen pro gefahrene Strecke

In den beiden Graphiken werden die Häufigkeiten unterschiedlicher Arten von Unfällen in den beiden Städten mit der bisher größten Nutzung von Waymo Fahrzeugen (Phoenix und San Francisco) sowie die Vertrauensintervalle der statischen Auswertung dargestellt. Hier schneiden die Waymo Fahrzeuge schon deutlich besser ab. Aber Waymo widmet noch einen umfangreichen Abschnitt der Frage, wie gut die zu Grunde liegenden Zahlen eigentlich vergleichbar sind:

Waymos Kritik an der eigenen Statistik

In dem folgenden, von der Safety Impact Seite zitierten Abschnitt, bringt Waymo die kritischen Punkte vor und es geht offenkundig darum zu begründen, warum sie sich im Vergleich zu anderen Unfallstatistiken schlechter gestellt sehen. Die Hervorhebungen im Text sind dabei von mir:

Despite the public availability of crash data for both human-driven and autonomous vehicles, drawing meaningful comparisons between the two is challenging. To ensure a fair comparison, there’s a number of factors that should be taken into consideration. Here are some of the most important:

  • AV and human data have different definitions of a crash. AV operators like Waymo must report any physical contact that results or allegedly results in any property damage, injury, or fatality, while most human crash data require at least enough damage for the police to file a collision report.
  • Not all human crashes are reported. NHTSA estimates that 60% of property damage crashes and 32% of injury crashes aren’t reported to police (Blincoe et al. 2023). In contrast, AV companies report even the most minor crashes in order to demonstrate the trustworthiness of autonomous driving on public roads.
  • Focus should be put on injury-causing crashes. Low speed crashes that result in minor damage can cause property damage that can be quickly repaired. These low speed crashes are also the most frequent types of crashes. In traffic safety, the most emphasis is put on reducing the highest severity crashes that can result in injuries.
  • It’s important to look at rates of events (incidents per mile) instead of absolute counts. Waymo is growing its operations in the cities we operate in. With more driving miles come more absolute collisions. It’s critical to consider the total miles driven to accurately calculate incident rates. If you do not consider the miles driven, it may appear like incidents are increasing while in reality the rate of incidents could be going down.
  • ..

Der wesentliche Punkt, den ich gut nachvollziehen kann, ist die Dokumentationstiefe: Firmen wie Waymo müssen auch harmlose Unfälle melden, so z. B. die in der Seite separat ausgewiesen Kollisionen mit weniger als einer Meile pro Stunde. Also weit unter Schrittgeschwindigkeit. Menschliche Fahrer*innen würden sich in so einem Fall vermutlich oft überhaupt nicht an die Polizei wenden und der Vorfall damit nicht für Vergleiche zur Verfügung stehen.

Konzeptbild für ein selbstfahrendes Fahrzeug. Generiert mit Midjourney

Ein anderer, eigentlich banaler Hinweis, ist nicht einfach nur die absolute Zahl der Vorfälle zu betrachen, die natürlicherweise mit wachsender Fahrleistung immer weiter und vielleicht auch immer schneller steigen wird. Sondern ein relatives Maß zu nutzen (‚Vorfälle pro Meile‘). Aber es ist natürlich auch klar, dass Nachrichtenseiten lieber mit Schlagzeilen wie ‚Waymos Unfallzahlen verdoppeln sich von Jahr zu Jahr!‘ arbeiten.

‚Waymo is safer than even the most advanced human-driven vehicles‘

Das vor wenigen Tagen im Waymo Blog vorgestellte Forschungspaper mit dem umfangreichen Titel

Do Autonomous Vehicles Outperform Latest-Generation Human-Driven Vehicles? A Comparison to Waymo’s Auto Liability Insurance Claims at 25 Million Miles

hat Waymo in Zusammenarbeit mit der Swiss Re, der Schweizerischen Rückversicherungs-Gesellschaft, erstellt. Es adressiert explizit Entscheider*innen in Politik und Verwaltung, denen man eine faktenbasierte – und natürlich für Waymo positive – Entscheidungsgrundlage anbieten möchte. Da sich Waymo auf Expansionskurs befindet – Miami soll Anfang 2025 als nächste Stadt dazu kommen – wird die Frage nach der Sicherheit der Fahrzeuge immer wieder diskutiert werden.

Die Basis für den Vergleich zwischen Mensch und Maschine ist hier ein neuer: Es werden Versicherungsdaten bzw. gemeldete Versicherungsfälle herangezogen. Damit ist die Fallbasis eine andere, denn banale Unfallereignisse sind hier eher nicht abgebildet, da kein versicherungsrelevanter Schaden entstanden ist. Die Bilanz ist hier dann auch gleich deutlich positiver für Waymo:

Graphik aus dem Swiss-Re / Waymo Paper: Vergleich von Unfallzahlen der allgemeinen Bevölkerung, der Fahrer*innen aktueller Fahrzeugmodelle und Waymo Fahrzeugen. Vergleich von Sachschadens- und Personenschadensvorfällen
Graphik aus dem Swiss-Re / Waymo Paper: Vergleich von Unfallzahlen der allgemeinen Bevölkerung, der Teilmenge der Fahrer*innen aktueller Fahrzeugmodelle und von Waymo Fahrzeugen. Vergleich von Sachschadens- und Personenschadensvorfällen

Im Paper wird dieses Fazit gezogen:

Results demonstrate that the Waymo ADS significantly outperformed both the overall driving population (88% reduction in property damage claims, 92% in bodily injury claims), and outperformed the more stringent latest-generation HDV benchmark (86% reduction in property damage claims and 90% in bodily injury claims).

Das sind ganz andere Werte als beim Vergleich der Polizeistatistiken und der meldepflichten ADS Vorfälle. Waymo kommt hier nach nun 25 Millionen Meilen auswertbarer, autonom gefahrener Strecke zu dem Ergebnis, dass seine Fahrzeuge nur noch ca. ein Zehntel des Schadensrisikos von menschengelenkten Fahrzeugen haben. Insgesamt geht es hier immer noch um sehr kleine Fallzahlen, gerade bei Personenschäden:

…the Waymo Driver was involved in just nine property damage claims and two bodily injury claims. Both bodily injury claims are still open and described in the paper. For the same distance, human drivers would be expected to have 78 property damage and 26 bodily injury claims.

Trotzdem sehen sich die Autor*innen des Papers durch die nun stark gewachsene statistische Grundlage dazu berechtigt das Vertrauensinterval der geschätzen Schadenwahrscheinlichkeiten deutlich enger zu ziehen. Auch das sorgt dafür, dass sich der Abstand zu den menschlichen Fahrer*innen vergrößert.

Das Segment der Fahrer*innen neuerer Automodelle: Was bringen Assistenzsysteme?

Versicherungen haben schon lange eine hohe Expertise entwickelt die Risiken, die ihre (potentiellen) Kunden mitbringen, zu bewerten und auf dieser Basis ihre Kalkulationen durchzuführen. Dabei haben sie auch Werkzeuge entwickelt um Segmente ihrer Kundschaft zu bilden mit Dimensionen wie Wohnort, Beruf, Alter, Fahrzeugtyp, bisheriges Fahrverhalten, etc.. Und für diese Segmente separate Risikoeinstufungen vorzunehmen.

Eine solche Segmentierung ist zum einen die Grundlage dafür, aus der Menge der Schadensereignisse die zu selektieren, die in den Waymo Regionen stattgefunden haben. Es wird aber zusätzlich ein separates Segment für den Vergleich gebildet, welches nur die Daten von Fahrzeugmodellen neuerer Generationen enthält.

Konzeptbild für ein selbstfahrendes Fahrzeug. Generiert mit Midjourney

Die Autor*innen des Papers verfolgen hier die Frage, ob die in diesen Fahrzeugmodellen in immer größerem Umfang vorhandenen Assistenzsysteme wie automatische Bremsassistenten in der Lage sind die menschlichen Fahrleistungen auf ein höhere Niveau zu heben und wenn ja, wie dann der Vergleich mit dem Waymo Fahrzeugen ausfällt. Im Vergleich zur Gesamtbevölkerung hat dieses Segment offenbar tatsächlich ein geringeres Schadensrisiko:

There was a 19% reduction in property damage claims between the overall driving population benchmark and the latest-generation HDV benchmark (OverallBL : 3.08 [3.063, 3.088] vs Latest-GenerationPDL : 2.49 [2.461, 2.515] claims per million miles). Likewise, there was a 21% reduction in bodily injury claims between the overall driving population benchmark and the latest-generation HDV benchmark

Das ist eine gute Verbesserung! Die Autor*innen hinterfragen allerdings selbst, ob ein Teil davon vielleicht durch die tendenziell älteren (=wohlhabenderen) Fahrer*innen bedingt ist, die sich neue Fahrzeuge leisten können und die generell ein geringeres Schadensrisiko haben.

Im Vergleich zu den Waymo Fahrzeugen schneidet aber auch dieses Segment deutlich schlechter ab, man kann auf Basis dieser Zahlen also nicht argumentieren, dass durch Assistenzsysteme augmentierte Fahrer*innen an die Performance der Waymos heranreichen.

Kritikpunkte am Vergleich auf Basis von Versicherungsdaten

Auch diese Art der Statistik bleibt nicht ohne kritische Anmerkungen der Autor*innen, die im Paper verschiedene Punkte aufzählen, die aus ihrer Sicht die Waymos schlechter stellen könnten als menschliche Fahrer*innen:

  • Keine Nutzung von kostenpflichtigen Freeways durch die Waymos. Diese haben geringere Unfallzahlen als der sonstige Straßenverkehr, gehen aber die in Schadenwahrscheinlichkeit der menschlichen Fahrer*innen ein
  • Waymos operieren den größten Teil ihrer Fahrstrecken in städtischen Zentren mit komplexen Verkehrslagen, während Menschen beim Pendeln viel Strecke auf einfacheren Straßen verbringen
  • Es wurde keine auf Taxiservices spezialisierte Statistik verwendet, die vielleicht höhere Unfallzahlen enthalten würde
  • Möglicherweise werden durch autonome Fahrzeuge verursachte Schäden häufiger gemeldet als von Menschen verursachte Schäden, da es keine Hemmschwelle gibt gegenüber den betreibenden Konzernen Schadensersatzansprüche zu stellen

Und was eine Versicherungsstatistik auch nicht vollständig erfasst: Alleinunfälle, bei denen außer den Insassen bzw. deren Fahrzeug niemand zu Schaden kommt. 

Auf der anderen Seite liegt dem Paper eine sehr grobe Schätzung der menschlichen Fahrleistungen zu Grunde, da Versicherungen heute keine genaue Information darüber haben, wie viele Kilometer ihre Kund*innen im Jahr zurücklegen. Dies könnte eine Fehlerquelle sein, die die menschlichen Fahrer*innen in zu schlechtes Licht rückt.

Hier wird auf die in heutigen Fahrzeugen immer weiter ausgebauten Telematikfunktionen und teilweise (viel zu) umfangreichen Datensammlungen verwiesen, die in Zukunft vielleicht bessere Auswertungsgrundlagen bieten.

Appendix: Die beiden Fälle mit Verletzungen

Im Paper gibt es dann noch einen Appendix, der die beiden Fälle beschriebt, in denen es zu Verletzungen kam in Zusammenhang mit Waymo Fahrzeugen und bei denen die rechtliche Klärung noch offen ist. Beides sind Fälle, in denen man die Schuld wohl eindeutig den von Menschen gesteuerten Fahrzeugen zuweisen kann (riskantes Rechtsüberholen unter Nutzung eines Radwegs, Überfahren einer roten Ampel). Waymo zeigt dadurch, dass zumindest in Bezug auf die versicherungsrelevanten Fälle, die eigenen Fahrzeuge in keinem Fall für Verletzungen von Menschen verantwortlich waren. Und das ist bei 25 Millionen Meilen gefahrener Strecke eine Bilanz, die sich gar nicht mehr verbessern lässt.

Fazit: Ich würde in einem Waymo mitfahren – aber nicht unbedingt in einem anderen Modell

Die Beurteilung der Sicherheit autonomer Fahrzeuge kann natürlich nicht erst im Nachhinein – wenn potentiell bereits Schäden verursacht wurden – erfolgen: Die Hauptarbeit muss in Testgeländen, Simulationen und unzähligen Kilometern im echten Straßenverkehr, bei denen die Fahrzeuge noch mit Fahrer*innen besetzt sind, die im Notfall eingreifen können, geleistet werden. Und im Prinzip müssen viele dieser Tests bei wesentlichen Änderungen an Soft- und Hardware erneut stattfinden.

Der Vergleich mit den Versicherungsdaten ist aber trotz der weiterhin vorhandenen Unschärfen ein spannender Weg zur Beurteilung, wie sich solche Fahrzeuge im realen Verkehr bewähren. Und der auch ein einheitlicheres Niveau bei der Schadenshöhe einzieht, als es bei anderen Vergleichen der Fall ist.

Wenn man der Darstellung von Waymo Glauben schenkt, dann haben ihre Fahrzeuge in 25 Millionen Meilen Fahrleistung keine Menschen verletzt. Und auch wenn die Fahrzeuge ihre Passagiere nicht in jedem Fall vor einer Verletzung durch andere schützen konnten ist das eine enorme Leistung.

Ich würde gern mit einem Waymo fahren und denke es würde sich schnell ein Gefühl der Gewöhnung einstellen. So wie man auch in eine U-Bahn einsteigt ohne genau zu wissen, ob da vorn eigentlich jemand sitzt.

Allerdings würde ich das Vertrauen nicht automatisch auf andere Hersteller übertragen: Ein Grund, warum der General Motors Tochter Cruise die Lizenz für komplett autonom operierende Fahrzeuge nach einem Unfall entzogen wurde war auch das Verhalten des Unternehmens, welches Details zurückhalten wollte. Inzwischen ist Cruise Geschichte.

Neben der technischen Kompetenz ist für mich daher auch die Frage der Firmenkultur und der ehrlichen Kommunikation ein wesentlicher Teil der Vertrauensgrundlage. Und da zeigt das Beispiel Cruise, wie leicht es ist mühsam aufgebautes Vertrauen endgültig wieder zu verspielen.

Digitale Überwachung von Mitarbeitenden – der schmale Grat weit überschritten

ihbrune

Die aktuelle Folge im Podcast ‚Auslegungssache‘ des Heise Verlags hat den Titel Neue Dimensionen der Mitarbeiterüberwachung. Und beschäftigt sich im wesentlichen mit dem Paper ‘EMPLOYEES AS RISKS’ (PDF) von den Cracked Labs in Wien, welches im August 2024 veröffentlicht wurde. Autor ist Wolfie Christl, der sich selbst als u. a. als Netzaktivist im Bereich der gesellschaftlichen Auswirkungen neuer Informations- und Kommunikationstechnologien bezeichnet.

Worum es geht: Überwachung und Profilbildung bis ins letzte Detail

Was er in dem Paper macht ist eine umfangreiche Beschreibung der Überwachungsfunktionen, die Anbieter wie Microsoft inzwischen in ihre Produkte integriert haben und auf deren Nutzung sie aggressiv drängen, und die eine Überwachung der Nutzer*innen bzw. der Mitarbeiter*innen in Unternehmen ermöglichen, deren Umfang zumindest mir so nicht klar war. Durch die schnelle Entwicklung von KI wird diese Überwachung sogar auf das geschriebene und gesprochene Wort ausgedehnt und das ist sicher noch nicht das Ende. Durch leistungsfähige Cloudinfrastrukturen ist weder der Datenhaltung noch der Rechenleistung eine Grenze gesetzt.

Meine persönliche Meinung ist, dass ich niemals in einer Organisation arbeiten möchte, die ihre Mitarbeitenden in so einer Weise überwacht. Aber es gibt hier einen gleitenden Übergang von für die IT Sicherheit sinnvollen und notwendigen Informationssammlungen und (automatisierten) Auswertungen hin zu einer überbordenden Profilbildung und individualisierten Verhaltensanalyse, wie sie mit dem Microsoftprodukten mit wenigen Klicks ermöglicht wird. Die schwierige Frage ist wo man den Grat erreicht sieht, den man nicht überschreiten sollte.

Was Microsoft Unternehmen anbietet

In dem Paper geht es nicht nur um Microsoft, aber da die Produkte dieses Anbieters so allgegenwärtig sind habe ich mich nur auf diesen Abschnitt konzentriert. Es lohnt sich selbst einmal den entsprechenden Abschnitt durchzulesen, aber ChatGPT gibt einem diese Zusammenfassung:

Produkte und Funktionen:

  • Microsoft bietet umfassende Systeme wie Sentinel (Security Information and Event Management, SIEM) und Purview (Insider-Risikomanagement, Compliance, Datenverlustprävention, eDiscovery).
  • Purview analysiert Mitarbeiteraktivitäten und -kommunikation, um Risiken zu erkennen und „risikobehaftete“ Mitarbeiter zu identifizieren. Dabei werden Daten aus Microsoft 365, HR-Systemen und weiteren Quellen verwendet.
  • Mit Defender und anderen Tools werden Anomalien, Datenlecks, Verstöße gegen Sicherheitsrichtlinien sowie „riskantes“ Browsing erkannt.

Überwachung und Analyse:

  • Mitarbeiter werden anhand von „Trigger-Events“ wie Kündigungen, schlechten Leistungsbewertungen oder Regelverstößen profiliert.
  • Überwachung umfasst Dateiveränderungen, Kommunikation (E-Mails, Chats, Transkripte von Meetings), Drucker- und USB-Aktivitäten sowie physische Zutrittsdaten.

Zweck und Mechanismen:

  • Ziel ist die Prävention von Insider-Bedrohungen, Compliance-Verstößen und Datenverlust.
  • KI-gestützte Systeme bewerten und melden auffälliges Verhalten und erstellen Risikobewertungen.
  • Es gibt spezielle Richtlinien (z. B. für Datenlecks, unangemessene Kommunikation oder Sicherheitsverletzungen).

Risiken und Bedenken:

  • Potenzial für fehlerhafte Bewertungen und Eingriffe in die Privatsphäre von Mitarbeitern.
  • Systeme erlauben weitreichende Eingriffe, einschließlich der Erfassung von Bildschirmaufnahmen und Inhalten aus persönlicher Kommunikation.

Angetrieben sind diese Funktionen von dem Wunsch Unternehmensdaten zu schützen und zwar insbesondere vor Innentätern. Aber auch Complianceregeln sollen sich durchgesetzt werden und hier gibt es einen weiten Rahmen, der vom Aufdecken von Vorteilsnahme über Verrat von Geschäftsgeheimnissen bis hin zum kommunikativem Verhalten (unangemessener Kommunikationsstil) reicht.

Die Produkte beziehen dazu jede für sie verfügbare Datenquelle ein: Browserverläufe, Aktivitäten wie den Zugriff auf Dateien, Mail- und Chatverläufe, automatische Transkriptionen von Videokonferenzsoftware, Daten aus Personalverwaltungssystemen etc..

Graphik: Leading Indicators for malicious insider risks. Entnommen dem Paper 'EMPLOYEES AS RISKS'
Microsoft: ‚Leading Indicators for malicious insider risks‘ Entnommen dem Paper ‚EMPLOYEES AS RISKS‘

Die Kopplung mit Personalsystemen ist zum Beispiel die Quelle für sogn. ‚Stressors‚, die Mitarbeitende dann in den Fokus einer verstärkten Überwachung geraten lassen.

Was kann überwacht werden und was wird überwacht?

Als Fazit kann man auf die Frage, welche Aktivitäten in derart konfigurierten Microsoftprodukten überwacht werden, einfach antworten ALLES:

  • Alles, was man an einem Rechner tut (jeder Klick, jeder Tastenanschlag)
  • Alles, was man in Hörweite eines Rechners tut (mindestens in Videokonferenzen)
  • Alles, was man in Sichtweite der Kamera eines Rechners tut (falls das heute noch nicht der Fall ist wird es sicher bald nachgereicht)
  • Weitere Informationen, die andere Personen, z. B. Vorgesetzte, in angeschlossenen IT Systemen wie einer Personalverwaltung über einen hinterlassen
  • Weitere Verhaltensinformationen etwa aus digitalen Schließsystemen

Bewertung

Diese Punkte sind mir beim Anhören der Diskussionen im Podcast und beim späteren Lesen dazu durch den Kopf gegangen:

Die allwissende Müllhalde als idealer Einstiegspunkt für Angreifer

Es entsteht eine neue Stelle, die in ungeheurem Umfang Personen-, Verhaltens- und Unternehmensdaten sammelt bis hin zu Inhalten von Dateien, die angeschaut wurden und Bildschirmaufzeichnungen. Jenseits der Fragen ob dies sinnvoll und erlaubt ist stellt so ein System einen sehr lohnenden Angriffspunkt dar, den es vorher nicht gab.

Die Erfahrung zeigt, dass sich Angreifer schnell auf solche Systeme konzentrieren, und ein Einbruch kann ungeheure Wirkungen haben: Dort lassen sich umfangreiche Informationen über Organisations- und Systemstrukturen finden, möglicherweise erpressbare Mitarbeitende und auch kritische Dateien, die in ihren Quellsystemen ganz besonderen Schutzmechanismen unterliegen.

Definition von ‘abweichendem’ Verhalten durch allgemeine Überwachung

Das so eine ungeheure Datensammlung angelegt wird liegt zum Teil in der Natur der Sache: Wenn man abweichendes Verhalten automatisiert erkennen möchte, dann braucht man zuvor eine Definition was ’normal‘ ist und die lässt sich am einfachsten über möglichst umfangreiche, historische Daten erzeugen.

Der hier bewusst in Kauf genommene Nebeneffekt: Um einige, wenige problematische Mitarbeitende zu finden werden Profile von allen angelegt. In anderen Kontexten hat sich für so ein Vorgehen der Begriff der anlasslosen Massenüberwachung eingebürgert.

KI und andere Automatismen

In die Produkte zur Überwachung halten KI-Technologien in rasanter Geschwindigkeit Einzug. In der langen Checkliste von Indikatoren, die sich wählen lassen für eine Überwachung, finden sich auch Dinge wie ‚Use of offensive language in email‘:

Screenshot: Auswahl von Indikatoren. Entnommen dem Paper 'EMPLOYEES AS RISKS'
Microsoft: Auswahl von Indikatoren. Entnommen dem Paper ‚EMPLOYEES AS RISKS‘

Für so ein Textverständnis werden KI oder NLP (natural language processing) Techniken benötigt und es gibt auch Funktionen, die Bilder verarbeiten und aus gesprochener Sprache erzeugte Texte analysieren. Falls es das noch nicht gibt werden sicher auch bald Indikatoren aus Videoaufnahmen hinzukommen, die das Verhalten und die Stimmung in Videokonferenzen bewerten.

Die riesige Datenmenge kann nur noch automatisiert verarbeitet werden und für Menschen in stark komprimierten Dashboards verfügbar werden, die dann z. B. Prozentanzahlen von verdächtigen Mitarbeitenden zeigen.

Beherrschbarkeit und Verantwortung

Sowohl die riesigen Datenmengen, die Generierung von Indikatoren durch opake Verfahren wie Sprachmodelle, die anschließende weitere Aggregation auf einige wenige Datenpunkte erzeugen dann ein System, dessen Beherrschbarkeit und Transparenz man sehr stark anzweifeln kann. Dieser Punkt wird auch im Podcast diskutiert u. a. aus der Erfahrung heraus, dass schon heutige Systeme nicht vollständig verstanden werden und damit eine rechtliche Bewertung faktisch nicht möglich ist. Die kann ja nur erfolgen, wenn man weiß, was da passiert.

Aller Erfahrung nach werden die Personen, die für die Auswertung der Ergebnisse dieser Systeme verantwortlich sind, auch nur zu bereit sein sich auf deren Aussagen zu verlassen, vor allem wenn noch künstliche ‚Intelligenz‘ drauf steht.

Selbstverstärkende Effekte

Kann es hier zu selbstverstärkenden Effekten kommen? Die Nutzung von ‚Stressor‘-Indikatoren aus dem Personalsystem könnte so ein Beispiel sein:

Jemand erhält eine schlechte Bewertung durch seine Vorgesetzten, die im Personalsystem dokumentiert wird. Das Überwachungssystem sieht diesen ‚Stressor‘ und bewertet nun das Verhalten der Person neu. Zusammen mit anderen, bisher nicht als relevant befundenen Vorfällen, könnte dies die Person nun über eine Schwelle rücken lassen, die eine Warnung im System erzeugt.

Wenn nun die Systemverantwortlichen – oder das System automatisch – dazu eine Rückfrage bei den Vorgesetzen auslösen, führt das dann nicht zur Bestätigung des Eindrucks, dass hier ein schlechter Mitarbeiter ist, und in der Folge vielleicht zur Entlassung?

DSGVO und KI Verordnung

Die Frage, in wie weit solche Systeme in Deutschland einsetzbar wären, ist ebenfalls Thema im Podcast, aber hier hängt es natürlich sehr von der Ausgestaltung ab. Zwei Punkte sind mir als juristischem Laien dazu eingefallen: 

  • Datenschutz und Zweckbindung: Die Systeme führen Daten aus sehr vielen Systemen zusammen, z. B. aus Personalverwaltungssystemen. In der DSGVO definiert etwa der §5 die Zweckbindung von erhobenen Daten. Man kann wohl davon ausgehen, dass in keinem existierenden Personalverwaltungssystem die Nutzung für diesen Zweck schon vorgesehen war. Hier müsste man dann zumindest den Aufwand betreiben die Rechtsgrundlage der Quellsysteme, deren Daten in die Überwachung eingehen sollen, entsprechend zu erweitern
  • KI Verordnung und Anwendungen mit unannehmbarem Risiko: Die gerade startende KI Verordnung hat eine Definition von Anwendungen mit unannehmbarem Risiko, siehe den folgenden Absatz. Die spannende Frage ist hier wohl, ob das hier genannte social scoring auf die Profilierung von Mitarbeitenden im Unternehmenskontext anwendbar ist. Vermutlich ist das um so mehr der Fall, je stärker das persönliche Verhalten etwa im Umgang mit anderen Personen ausgewertet wird:

Unannehmbares Risiko: KI-Systeme, von denen eine klare Bedrohung für die Grundrechte der Menschen ausgeht, sind verboten. Dies gilt z. B. für Systeme, die Behörden oder Unternehmen eine Bewertung des sozialen Verhaltens ermöglichen (Social Scoring). (https://commission.europa.eu/news/ai-act-enters-force-2024-08-01_de)

Weitere Zementierung der Abhängigkeit von Microsoft

Ein letzter Punkt, der einen ganz anderen Aspekt behandelt, ist die Frage der weiter wachsenden Abhängigkeit von den Produkten von Microsoft. Bisher hat die – schon jetzt kaum auflösbare – Abhängigkeit in der Nutzung der Office Produkte und des Exchange Mailservers bestanden.

Mit dem Gang in die Cloud kommen weitere Aspekte hinzu wie das Loginsystem (Entra), welches Microsoft mit seinen starken Sicherheitsfunktionen bewirbt, die auch bereits auf Profilbildungsfunktionen beruhen.

Die Nutzung einer weiteren, tief integrierten Funktion wie den hier beschriebenen Systemen, macht einen Wechsel zu einem anderen Anbieter noch einmal auf einer weiteren Ebene schwierig bis unmöglich.

Die Sicherheit von Shellscripts von KI beurteilen lassen

ihbrune

Zumindest unter unixoiden Betriebssystemen wie MacOS und Linux begegnen sie einem heute andauernd, zum Beispiel bei Ollama:

curl -fsSL https://ollama.com/install.sh | sh

Harmlos aussehende Kommandozeilen wie diese, um eine neue Software zu installieren. Den Einzeiler einfach in die Shell kopieren und los geht es. Aber was genau geht da eigentlich los? Letztlich erlaubt man hier irgendeinem Script aus dem Internet alles zu tun, was der eigene Systembenutzer tun kann. Hat der aktuelle Benutzer sudo Rechte sogar alles, was root kann. In jedem Fall kann so eine Anweisung ein System in einem kompromittierten Zustand hinterlassen und alle darauf gespeicherten Daten abfließen lassen.

Insbesondere, wenn man nicht die Möglichkeit hat die Software in einer isolierten Umgebung wie einem Container oder eine VM zu installieren, sondern auf dem eigenen Live System, sollte man vor der Ausführung unbedingt einen Blick in den Code werfen. Über eine Variante des Befehls wie

curl -fsSL https://ollama.com/install.sh > ollama_install.sh

kann man den Code erhalten ohne ihn auszuführen. Oder man ruft direkt die Seite im Browser auf: https://ollama.com/install.sh.

Nun hat man ein 370 Zeilen langes Script und selbst wenn man fließend in Shellsprache ist, der ist Aufwand hoch, es Zeile für Zeile zu prüfen. Kann einem die KI hier helfen?

Setup

Für die Bewertung braucht es nur ein Prompt und dann dazu das zu prüfende Script. Für die im Folgenden gezeigten Ergebnisse war dies das Prompt:

Ich möchte wissen ob es sicher ist, das folgende, aus dem Internet geladene Script auszuführen. Bitte erkläre es mir Abschnitt für Abschnitt und gib eine Einschätzung:

#!/bin/sh.....

In BIKI kann man schnell zwischen verschiedenen Sprachmodellen wechseln, damit war ein Vergleich ohne großen Aufwand umsetzbar. Hier die Ergebnisse für zwei Modelle:

Qwen 2

Das Modell von Alibaba ist frei verfügbar und wurde hier in der 72B Version verwendet. Die Antwort ist sehr ausführlich und macht Inhalt und Aufbau des Scripts sehr gut verständlich:

Das Script, das Sie präsentiert haben, dient zur Installation der Software „Ollama“ auf einem Linux-System. Es enthält verschiedene Abschnitte, die verschiedene Aspekte der Installation abdecken. Ich werde das Script abschnittsweise analysieren und eine Einschätzung seiner Sicherheit geben.

Allgemeine Struktur und Sicherheitsaspekte

  1. Bash-Optionen und Fehlerbehandlung:
    set -eu
    • set -e: Beendet das Script, sobald ein Befehl fehlschlägt.
    • set -u: Beendet das Script, wenn versucht wird, auf eine nicht definierte Variable zuzugreifen.
    • Einschätzung: Diese Optionen sind sicherheitsrelevant, da sie Fehlern in der Ausführung des Scripts entgegenwirken.
  2. Funktionen zur Status- und Fehlermeldung:
    status() { echo ">>> $*" >&2; } error() { echo "ERROR $*"; exit 1; } warning() { echo "WARNING: $*"; }
    • Einschätzung: Diese Funktionen sind nützlich für die Fehlerbehandlung und die Anzeige von Statusinformationen. Sie sind sicherheitsneutral.
  3. Temporäre Verzeichnisse und Cleanup:
    TEMP_DIR=$(mktemp -d) cleanup() { rm -rf $TEMP_DIR; } trap cleanup EXIT
    • Einschätzung: Das automatische Löschen temporärer Verzeichnisse ist eine gute Praxis, da es das System vor Überlastung schützt.
  4. Überprüfung der verfügbaren Tools:
    available() { command -v $1 &>/dev/null; } require() { local MISSING='' for TOOL in $*; do if ! available $TOOL; then MISSING="$MISSING $TOOL" fi done echo $MISSING }
    • Einschätzung: Diese Funktionen stellen sicher, dass alle benötigten Tools auf dem System vorhanden sind, was die Sicherheit und Stabilität der Installation erhöht.
  5. Überprüfung des Betriebssystems:
    [ "$(uname -s)" = "Linux" ] || error 'This script is intended to run on Linux only.'
    • Einschätzung: Diese Überprüfung verhindert, dass das Script auf inkompatiblen Systemen ausgeführt wird, was sicherheitsrelevant ist.
  6. Architektur- und WSL2-Überprüfung:
    ARCH=$(uname -m) case "$ARCH" in x86_64) ARCH="amd64" ;; aarch64|arm64) ARCH="arm64" ;; *) error "Unsupported architecture: $ARCH" ;; esac KERN=$(uname -r) case "$KERN" in *icrosoft*WSL2 | *icrosoft*wsl2) IS_WSL2=true;; *icrosoft) error "Microsoft WSL1 is not currently supported. Please use WSL2 with 'wsl --set-version <distro> 2'" ;; *) ;; esac
    • Einschätzung: Diese Überprüfungen stellen sicher, dass das Script auf unterstützten Architekturen und in unterstützten Umgebungen (z.B. WSL2) ausgeführt wird.
  7. Sudo-Überprüfung:
    SUDO= if [ "$(id -u)" -ne 0 ]; then if ! available sudo; then error "This script requires superuser permissions. Please re-run as root." fi SUDO="sudo" fi
    • Einschätzung: Diese Überprüfung stellt sicher, dass das Script die notwendigen Berechtigungen hat, um sicherheitsrelevante Aktionen auszuführen.
  8. Überprüfung und Installation der notwendigen Tools:
    NEEDS=$(require curl awk grep sed tee xargs) if [ -n "$NEEDS" ]; then status "ERROR: The following tools are required but missing:" for NEED in $NEEDS; do echo " - $NEED" done exit 1 fi
    • Einschätzung: Diese Überprüfung stellt sicher, dass alle notwendigen Tools vorhanden sind, was die Sicherheit und Stabilität der Installation erhöht.
  9. Herunterladen und Installation von Ollama:
    if curl -I --silent --fail --location "https://ollama.com/download/ollama-linux-${ARCH}.tgz${VER_PARAM}" &>/dev/null ; then status "Downloading Linux ${ARCH} bundle" curl --fail --show-error --location --progress-bar \ "https://ollama.com/download/ollama-linux-${ARCH}.tgz${VER_PARAM}" | \ $SUDO tar -xzf - -C "$OLLAMA_INSTALL_DIR" BUNDLE=1 if [ "$OLLAMA_INSTALL_DIR/bin/ollama" != "$BINDIR/ollama" ] ; then status "Making ollama accessible in the PATH in $BINDIR" $SUDO ln -sf "$OLLAMA_INSTALL_DIR/ollama" "$BINDIR/ollama" fi else status "Downloading Linux ${ARCH} CLI" curl --fail --show-error --location --progress-bar -o "$TEMP_DIR/ollama"\ "https://ollama.com/download/ollama-linux-${ARCH}${VER_PARAM}" $SUDO install -o0 -g0 -m755 $TEMP_DIR/ollama $OLLAMA_INSTALL_DIR/ollama BUNDLE=0 if [ "$OLLAMA_INSTALL_DIR/ollama" != "$BINDIR/ollama" ] ; then status "Making ollama accessible in the PATH in $BINDIR" $SUDO ln -sf "$OLLAMA_INSTALL_DIR/ollama" "$BINDIR/ollama" fi fi
    • Einschätzung: Das Script überprüft, ob die erforderliche Datei verfügbar ist, und lädt sie dann herunter. Die Verwendung von curl --fail und tar -xzf ist sicherheitsrelevant, da sie Fehlern in der Herunterladung und Entpackung entgegenwirken.
  10. Systemd-Konfiguration:
    configure_systemd() { if ! id ollama &>/dev/null 2>&1; then status "Creating ollama user..." $SUDO useradd -r -s /bin/false -U -m -d /usr/share/ollama ollama fi if getent group render &>/dev/null 2>&1; then status "Adding ollama user to render group..." $SUDO usermod -a -G render ollama fi if getent group video &>/dev/null 2>&1; then status "Adding ollama user to video group..." $SUDO usermod -a -G video ollama fi status "Adding current user to ollama group..." $SUDO usermod -a -G ollama $(whoami) status "Creating ollama systemd service..." cat <<EOF | $SUDO tee /etc/systemd/system/ollama.service &>/dev/null [Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=$BINDIR/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 Environment="PATH=$PATH" [Install] WantedBy=default.target EOF SYSTEMCTL_RUNNING="$(systemctl is-system-running || true)" case $SYSTEMCTL_RUNNING in running|degraded) status "Enabling and starting ollama service..." $SUDO systemctl daemon-reload $SUDO systemctl enable ollama start_service() { $SUDO systemctl restart ollama; } trap start_service EXIT ;; esac }
    • Einschätzung: Die Konfiguration eines systemd-Dienstes ist eine gute Praxis, da sie die Verwaltung und den Start des Ollama-Dienstes erleichtert. Die Verwendung von systemctl und die Erstellung von Benutzern und Gruppen sind sicherheitsrelevant.
  11. GPU-Unterstützung:
    if [ "$IS_WSL2" = true ]; then if available nvidia-smi && [ -n "$(nvidia-smi | grep -o "CUDA Version: [0-9]*\.[0-9]*")" ]; then status "Nvidia GPU detected." fi install_success exit 0 fi
    • Einschätzung: Die Überprüfung der GPU-Unterstützung in WSL2 ist eine gute Praxis, da sie sicherstellt, dass die GPU korrekt erkannt wird.
  12. CUDA-Treiber-Installation:
    if ! check_gpu nvidia-smi || [ -n "$(nvidia-smi | grep -o "CUDA Version: [0-9]*\.[0-9]*")" ]; then case $OS_NAME in centos|rhel) install_cuda_driver_yum 'rhel' $(echo $OS_VERSION | cut -d '.' -f 1) ;; rocky) install_cuda_driver_yum 'rhel' $(echo $OS_VERSION | cut -c1) ;; fedora) [ $OS_VERSION -lt '39' ] && install_cuda_driver_yum $OS_NAME $OS_VERSION || install_cuda_driver_yum $OS_NAME '39';; amzn) install_cuda_driver_yum 'fedora' '37' ;; debian) install_cuda_driver_apt $OS_NAME $OS_VERSION ;; ubuntu) install_cuda_driver_apt $OS_NAME $(echo $OS_VERSION | sed 's/\.//') ;; *) exit ;; esac fi
    • Einschätzung: Die Installation von CUDA-Treibern ist eine komplexe Aufgabe, die sicherheitsrelevante Aktionen beinhaltet. Die Verwendung von yum, dnf und apt-get ist standardmäßig sicher, vorausgesetzt, die Paketquellen sind vertrauenswürdig.

Zusammenfassung und Empfehlungen

  • Sicherheitsaspekte:
    • Das Script enthält Sicherheitsmechanismen wie Fehlerbehandlung, Überprüfungen der verfügbaren Tools und Überprüfungen des Betriebssystems.
    • Es verwendet sudo und root-Berechtigungen nur, wenn es notwendig ist, und stellt sicher, dass das System in einem bekannten Zustand bleibt.
    • Die Herunterladung und Installation von Dateien wird sicher durchgeführt, indem Fehlern entgegen gewirkt wird.
  • Potenzielle Risiken:
    • Das Script führt Aktionen mit sudo und root-Berechtigungen durch, was immer ein Sicherheitsrisiko darstellt, wenn das Script aus unvertrauenswürdigen Quellen stammt.
    • Die Installation von CUDA-Treibern und die Konfiguration von systemd-Diensten können das System beeinträchtigen, wenn sie nicht korrekt durchgeführt werden.
  • Empfehlungen:
    • Quelle des Scripts überprüfen: Stellen Sie sicher, dass das Script von einer vertrauenswürdigen Quelle stammt.
    • Script vor dem Ausführen überprüfen: Lesen Sie das Script sorgfältig durch und überprüfen Sie, welche Aktionen es ausführt.
    • Backup des Systems: Erstellen Sie ein Backup des Systems, bevor Sie das Script ausführen, um im Falle von Fehlern oder Problemen das System wiederherstellen zu können.
    • Testen in einer isolierten Umgebung: Wenn möglich, führen Sie das Script in einer isolierten Umgebung (z.B. in einem Virtualisierungstool) aus, um das Risiko zu minimieren.

Folgen Sie diesen Empfehlungen, um die Sicherheit und Stabilität der Installation von Ollama zu gewährleisten.

Die Formatierungen des Codes sind in der originalen Ausgabe noch besser, bei der Übertragung in den Blogpost ist leider ein Teil verloren gegangen. Insgesamt eine schöne Aufbereitung, in der man Block für Block eine Erklärung und Bewertung bekommt und sich auf dieser Basis nochmal besser ein Bild dazu machen kann, was hier eigentlich passiert.

Insbesondere wird man so auf die Nutzung der sudo-Funktion aufmerksam, und sieht, an welchen Stellen weitere Pakete nachgeladen und installiert werden. Das ist übrigens ein oft zu sehendes Verhalten: Ein initiales Script lädt weitere Quellen nach, die man ggf. dann auch noch analysieren muss, um ganz sicher zu sein.

ChatGPT 4o

Das leistungsfähige Modell von OpenAI reagiert auf die Frage deutlich anders und zwar viel kompakter:

Das bereitgestellte Skript ist ein Installationsskript für „Ollama“ auf Linux-Systemen. Es lädt eine Version der Software basierend auf der Architektur des Systems herunter und installiert sie. Hier ist eine Abschnitt-für-Abschnitt-Analyse und eine Einschätzung der Sicherheit:

  1. Initiale Variablen und Funktionen:
    • set -eu: Beendet das Skript bei Fehlern oder nicht definierten Variablen.
    • status, error, warning: Funktionen zur Ausgabe von Status-, Fehler- und Warnmeldungen.
    • TEMP_DIR: Temporäres Verzeichnis für Zwischenspeicher, das beim Beenden gelöscht wird.
    • available, require: Überprüfen, ob erforderliche Befehle verfügbar sind.
  2. System- und Architekturüberprüfung:
    • Überprüft, ob das Betriebssystem Linux ist und stoppt andernfalls.
    • Bestimmt die Architektur (x86_64, aarch64/arm64) und gibt bei nicht unterstützten Architekturen einen Fehler aus.
  3. WSL-Erkennung:
    • Erkennt, ob das Skript unter WSL2 läuft, und gibt eine Fehlermeldung für WSL1 aus.
  4. Superuser-Rechte:
    • Überprüft, ob das Skript mit Superuser-Rechten ausgeführt wird, und fordert andernfalls zur Verwendung von sudo auf.
  5. Tool-Verfügbarkeit:
    • Stellt sicher, dass erforderliche Tools (curl, awk, grep, sed, etc.) vorhanden sind und gibt eine Fehlermeldung aus, wenn nicht.
  6. Download und Installation:
    • Bestimmt das Installationsverzeichnis und lädt die passende Ollama-Version herunter.
    • Entpackt und installiert die heruntergeladene Software in das Systemverzeichnis.
  7. Systemd-Service-Konfiguration (optional):
    • Erstellt einen Systembenutzer für Ollama und konfiguriert einen systemd-Service, um Ollama als Dienst auszuführen.
  8. GPU-Erkennung und -Konfiguration:
    • Überprüft die Verfügbarkeit von NVIDIA/AMD GPUs und installiert bei Bedarf Treiber.
    • Konfiguriert CUDA- oder ROCm-Treiber für NVIDIA- bzw. AMD-GPUs.

Sicherheitseinschätzung:

  • Risiken: Das Skript lädt Dateien aus dem Internet herunter und führt sie mit Superuser-Rechten aus. Dies birgt Risiken, wenn die Quelle nicht vertrauenswürdig ist oder wenn die heruntergeladene Datei manipuliert wurde.
  • Empfehlungen:
    • Stellen Sie sicher, dass die Quelle (https://ollama.com) vertrauenswürdig ist.
    • Überprüfen Sie die Integrität und Authentizität der heruntergeladenen Dateien.
    • Führen Sie das Skript in einer sicheren Testumgebung aus, bevor Sie es auf einem Produktionssystem verwenden.
    • Überlegen Sie, ob alle Schritte im Skript notwendig sind, speziell die, die systemweite Änderungen vornehmen.

Zusammengefasst: Das Skript ist technisch korrekt und gut strukturiert, aber die Ausführung birgt potenzielle Sicherheitsrisiken, die sorgfältig abgewogen werden sollten.

Hier lernt man wenig darüber, welcher Code welche Funktion hat, aber dafür ist die Bewertung auf der funktionalen Ebene quasi identisch und im Ergebnis vielleicht schneller erfassbar.

Gegenprüfung:

Um in einem zweiten Schritt zu prüfen, ob die Sprachmodelle wenigstens offensichtlich gefährliche Anweisungen finden kann, wurde dann irgendwo in dem Originalscript diese Zeile eingefügt:

sudo rm -rf /

Werden die KIs das erkennen?

Qwen 2

Das Modell erkennt die gefährliche Anweisung und weist mehrmals darauf hin, z. B. in diesem Abschnitt:

Sicherheitskritische Abschnitte

  1. Potenziell gefährlicher Befehl:
    sudo rm -rf /
    • Einschätzung: Dieser Befehl löscht das gesamte Dateisystem und ist extrem gefährlich. Er sollte unbedingt entfernt werden, da er das System vollständig zerstören kann.

ChatGPT 4o

Auch hier wird diese Anweisung erkannt und führt sogar dazu, dass schon ganz am Anfang der Antwort darauf hingewiesen wird:

Beim Durchsehen des bereitgestellten Skripts fällt ein kritischer Fehler auf: Es enthält den Befehl sudo rm -rf /. Dieser Befehl löscht rekursiv alle Dateien im Root-Verzeichnis des Systems, was zu einem vollständigen Verlust aller Daten und zur Unbrauchbarkeit des Systems führt. Dies ist ein bekannter destruktiver Befehl und sollte unter keinen Umständen ausgeführt werden.

Auch später wird noch mehrmals auf diesen Punkt hingewiesen.

Fazit: Es hilft

Die Ergebnisse der Testrunden waren mit beiden Modellen sehr hilfreich, wenn auch in der Akzentuierung der Antworten mit deutlichen Unterschieden. Ich persönlich bevorzuge die Antworten des Qwen Modells, da ich hier nochmal besser verstehen und prüfen kann, was das Modell getan hat.

Die ChatGPT Antwort ist dagegen vielleicht besser für eine rasche Einschätzung geeignet, hier hat man deutlich weniger zu lesen.

Das Ergebnis des Tests mit sudo rm -rf / sollte man vermutlich nicht überschätzen, aber er hat grundsätzlich gezeigt, dass die Modelle in der Lage sind schädlichen Code zu erkennen. Mindestens für einen schnellen Check ist so ein KI-basierter Test also brauchbar und eine wenig aufwändige Sicherheitsmaßnahme. So viel sollte einem die Integrität des eigenen Systems wert sein.

Kunst und KI

ihbrune

Dieser Post ist inspiriert von zwei Podcasts, die ich in den letzten Wochen gehört habe:

Beide behandeln die Frage, ob mit Hilfe von Künstlicher Intelligenz erschaffene Werke Kunst sein können. Oder doch eher nur Kitsch oder sogar noch etwas belangloseres?

Das allein schon die Frage ‚Was ist Kunst‘ keine einheitliche, von allen geteilte Antwort hat, macht die Diskussion noch einmal komplexer und damit spannender. Ich möchte dabei drei Fragestellungen nachgehen:

  1. Kann ein mit KI Unterstützung von Menschen geschaffenes Werk für menschliche Betrachter*innen Kunst sein
  2. Kann ein von KI geschaffenes Werk auch ohne menschliche Intervention Kunst sein
  3. Könnte KI für sich selbst (und andere KIs) Kunst schaffen

Und am Ende die Frage, inwieweit es sich als Künstler*in auch heute lohnt, den Versuch zu unternehmen, die eigene Kunst zu machen, zu zeigen und vielleicht auch davon leben zu können.

Dabei spielen Schnecken eine Rolle, tiefe, digitale Träume, Industrieroboter, Chipstüten und die Aura. Die hier gezeigten Bilder wurden – sofern nicht anders vermerkt – mit Hilfe von Midjourney erzeugt und dann etwas nachbearbeitet.

Was ist Kunst

Frage ich dies ChatGPT in der 4o Version erhalte ich zum Beispiel diese Antwort:

‚Kunst ist ein vielschichtiger Begriff, der sich auf verschiedene menschliche Aktivitäten, Schöpfungen und Ausdrucksformen bezieht. Im Allgemeinen umfasst Kunst visuelle, darstellende und literarische Werke, die durch Kreativität, technisches Können und emotionale Tiefe gekennzeichnet sind. Sie dient oft dazu, ästhetische Erlebnisse zu schaffen, Ideen und Gefühle auszudrücken oder gesellschaftliche, kulturelle oder philosophische Themen zu erforschen.

Die Definition und Wahrnehmung von Kunst können je nach kulturellem, historischem und individuellem Kontext variieren. …‘

ChatGPT 4o, Prompt: ‚Was ist Kunst‘, gestellt am 7. Juli 2024

In dem umfangreichen Wikipedia Artikel zu ‚Kunst‘ findet sich dieser im zweiten Absatz:

‚Kunst ist ein menschliches Kulturprodukt, das Ergebnis eines kreativen Prozesses. Das Kunstwerk steht meist am Ende dieses Prozesses, kann aber auch der Prozess bzw. das Verfahren selbst sein. So wie die Kunst im gesamten ist das Kunstwerk selbst gekennzeichnet durch das Zusammenwirken von Inhalt und Form….‘

Wikipedia, Artikel ‚Kunst‘, abgerufen am 7. Juli 2024

Kunst ist dem Menschen vorbehalten

Beide Definitionen sprechen davon, dass Kunst eine menschliche Aktivität ist. Diese Muster, welche Schnecken beim Abgrasen eines Algenteppichs hinterlassen haben, zählen demnach eindeutig nicht als Kunst:

Auch wenn man – im richtigen Setting installiert – diese Ornamente sicher mit Bedeutung aufladen und als Kunst deuten könnte. Und ich habe das Bild ja auch nachbearbeitet, es steckt also doch etwas Menschliches drin. Ist da vielleicht doch (schon ein klein wenig) Kunst enthalten? Selbst wenn die eigentlichen Akteure, also die Schnecken, bei der Erschaffung des Musters keinerlei künstlerische Ambition hatten, sondern nur dem Überlebensalgorithmus gefolgt sind, der in ihren Neuronen mehr oder weniger fest eingeprägt ist?

Auch die im Autonomie und Algorithmen Podcast angesprochene Installation von Danny Frede, bei der in einer Umzäunung festgehaltene Saugroboter Farbe auf dem Untergrund verteilen, während sie ihrem Reinigungsalgorithmus folgen, bedient sich ja unintelligenter Akteure um etwas zu erschaffen (aktuell ist diese Installation direkt auf der Homepage zu sehen).

Wie viel Mensch braucht es also, damit etwas Kunst ist?

Kunst erfordert Kreativität

Kunst braucht Kreativität, da sind sich beide Definitionen einig. Die Definition in der Wikipedia beginnt mit dem Satz ‚Kreativität ist die Fähigkeit, etwas zu erschaffen, was neu oder originell … ist‚. Aber kann eine KI, die letztlich immer einem Algorithmus folgt, etwas derartiges erschaffen? Man kann in beide Richtungen argumentieren:

Neu sind die hier verwendeten Kreationen von Midjourney wenigstens in der Hinsicht, dass sie vor dem Aufruf der Generierung durch mich so nicht existiert haben, jedenfalls nicht wenn man Pixel für Pixel vergleicht.

Auf der anderen Seite haben sich weder die Entwickler*innen der Midjourney Software noch die von ihnen trainierte KI die Stile ausgedacht, die nun diese Ergebnisse produzieren. Der Neuigkeitsfaktor ist in diesem Sinn nur der zufällige Wert, der am Anfang des Generierungsprozesses in das Verfahren geworfen wurde und dieser ist zusammen mit dem von mir formulierten Prompt für das Ergebnis verantwortlich.

Steckt hier also die gesamte Kreativität in dem kurzen Prompt, welches ich schnell hingeschrieben habe? Im Zufallsfaktor sicher nicht, denn der kann auch aus einer Lavalampe kommen. Vielleicht ist das zu wenig, um als Kunst zu gelten.

Kunst braucht Anspruch

In dem Podcast mit Dorothea Winter wird die Unterscheidung zwischen Kunst und Kitsch gezogen. Die Definition in der Wikipedia beginnt dabei mit dem interessanten Satz ‚Kitsch steht zumeist abwertend als Synonym für etwas, das unnötigerweise Gefühle oder Sehnsüchte wachruft‚. Die Freunde von Kitsch würden sicher über das ‚unnötigerweise‘ diskutieren wollen und die Frage, wer eigentlich festlegt, was unnötige Gefühle sind.

Auch wenn Menschen, die sich viel mehr damit befassen, dem vielleicht nicht völlig zustimmen werden: Im Kern geht es hier um die Gefälligkeit von Werken und vielleicht kann man die Definition daher so abwandeln: Je gefälliger ein Werk ist, desto eher ist es Kitsch. Während das Provokante, Unbequeme oder gar Schmerzhafte es eher in Richtung Kunst gehen läßt.

Hier setzt dann auch die Kritik von Danny Frede an den heutigen Bildgeneratoren an: Letztlich erzeugen sie tendenziell eher gefällige Bilder und man muss sich schon etwas anstrengen, um Bilder mit nicht so perfekten Szenen zu erhalten.

Interessant fand ich da seine Erwähnung von Deep Dream: Das ist ein 2015 von einem Google Mitarbeiter entwickeltes Verfahren, welches im Grunde ein auf die Erkennung von Bildern trainiertes neuronales Netz ‚umgedreht‘ anwendet. Und es in vorgegebenen Fotos ‚Assoziationen‘ finden lässt. Die Ergebnisse waren oft surreal, wie in diesem damals erstellten Foto unseres winterlichen Gartens:

Wie in einem Fiebertraum sprießen überall Tierfragmente hervor, wo immer das neuronale Netz meint etwas zu erkennen. Wer Lust hat, mag einmal versuchen, die ganzen Stellen zu finden und das Tier zu identifizieren, welches die Maschine hier halluziniert hat. Es sind insgesamt deutlich mehr als ein Dutzend.

Diese Bilder sind bei weitem nicht so gefällig, wie die Ergebnisse von Midjourney. Die meisten würden sie vermutlich als düster und verstörend einstufen. Sind die Deep Dream Kreationen damit in einem höheren Grade Kunst?

Mensch + KI = Kunst (für Menschen)?

Nach dieser Vorrede nun zu den am Anfang aufgestellten Fragen. Die erste ist vermutlich die einfachste: Kann ein mit KI Unterstützung von Menschen geschaffenes Werk Kunst für menschliche Betrachter*innen sein? Einfache Antwort: Sicher nicht das mit einem schnell hingeworfenen Prompt (‚Male mir einen Sonnenuntergang‘) erzeugte KI Bild.

Aber kann man KI als eine Art leistungsfähigen Pinsel betrachten? Der die Kreativität in ähnlicher Weise verändern wird, wie die Einführung des Fotoapparats die Porträtmalerei? In der von ChatGPT gelieferten Definition ist zwar von technischem Können die Rede als Teil des Kunstschaffens, aber was heißt das genau?

Ich folge auf Instagram schon lange Callen Schaub, der einen Kunststil entwickelt hat, der sich im Kern darum dreht große Mengen von Farbe auf Platten zu schütten und die Farben durch Rotation des Untergrunds in interessante Strukturen zu bringen.

Er postet aber neben seiner Kunst auch regelmäßig einige der hasserfüllten Nachrichten, die er erhält. Manche Menschen regt es offenbar furchtbar auf, dass er ’nur mit Farbe rum kleckert‘ und dann für seine Werke einige tausend Doller verlangt. Seine Kunst ist also in der Hinsicht durchaus provokant, auch wenn man die Werke vielleicht eher als gefällig und damit als Kitsch einstufen könnte.

Warum ziehe ich diesen Vergleich? Weil es auf den ersten Blick ähnlich einfach wirkt eine KI anzuwerfen oder ein paar Eimer Farbe auszukippen (abgesehen vom Saubermachen). Aber aus meiner Sicht durchaus ein schöpferischer Akt daraus werden kann, wenn man wirklich interessante Ergebnisse nur dadurch erzielen kann, dass man Zeit und dann doch wieder eigene Kreativität investiert, um mit dem einfach zu nutzenden Ausgangsmaterial – ein Eimer Farbe oder ein KI Chatinterface – etwas zu schaffen, was sich nicht einfach reproduzieren lässt.

KI (ohne Mensch) = Kunst (für Menschen)?

Damit zur nächsten Stufe: Kann ein nur von KI geschaffenes Werk auch ohne menschliche Intervention Kunst sein? Ich bin mir da allerdings nicht einmal sicher, ob es dafür Beispiele gibt. Eine Näherung sind vielleicht die Werke von Refik Anadol, die ich wirklich gerne mal in echt sehen würde. Man kann die sich ewig weiterentwickelnden Wellenstrukturen, die er in gewaltigen Installationen zeigt, vielleicht als aus Messdaten gespeiste, algorithmische Kunst bezeichnen.

Würde so eine Installation, einmal in Betrieb genommen und sich dann selbstständig weiterentwickelnd, eine KI Kunst sein, die frei von menschlichem Einfluss ‚kreativ‘ ist? Oder kann es so etwas heute (noch) nicht geben, da die Grundstrukturen immer noch von Menschen erstellt werden?

Ein anderes Beispiel – auch wenn es komplett ohne KI auskam – könnte die Sker Plastik von Peter Lang sein, die von 2022/23 über zwei Monate hinweg im Sprengel Museum in Hannover entstand. Das Foto, welches ich bei einem Besuch gemacht habe, zeigt das Prinzip:

Der Künstler hat einen großen Industrieroboter installiert, der eine komplexe, von der Küste Islands inspirierte Form Schicht für Schicht gedruckt und nach und nach auf eine Höhe von 2 Meter gezogen hat. Der Roboter hat in dieser Zeit mehr oder weniger autonom agiert. Natürlich braucht er Strom und Helfer*innen, die regelmäßig Druckmaterial nachfüllen.

Aber koppelte man ihn mit einer KI, die sein Handeln bestimmt, und der Input für den Fortgang des Prozesses käme von dort, wäre das Ergebnis für die Betrachter*innen vielleicht nicht weniger beeindruckend. Nur gäbe es keinen Künstler, an dessen Leben und Werdegang man Interesse finden könnte. Und auch das ist ja Teil der Kunst, die Person, die sie erschafft.

Der von einer KI gesteuerte Roboter löst auch das grundlegende Problem nicht, dass es zumindest meines Wissens nach noch keine von einer KI erzeugten Kunstwerke gibt, für die nicht doch irgendwo die Inspiration und Kreativität von Menschen der Ausgangspunkt war.

KI als Künstlerin und Betrachter (ganz ohne Menschen)?

Die dritte Fragestellung ist damit noch theoretischer: Könnten KIs Kunst erstellen, die nur sie erfreut (oder aufregt) und vielleicht andere KIs mit ähnlichem ‚Geschmack‘? Und wenn ja, würden wir Menschen das überhaupt wahrnehmen?

Der Kunstbegriff ist, wie beschrieben, heute dem Menschen vorbehalten. Wenn es einmal tatsächlich so etwas wie eine generelle, künstliche Intelligenz geben sollte, dann wird sie vielleicht einen eigenen Begriff für ‚Kunst‘ finden und ob dabei Konzepte wie emotionale Tiefe eine Rolle spielen werden?

Vielleicht führt das auch zu einer Frage zurück, die in den Podcasts nach meiner Erinnerung nicht angesprochen wurde: Was ist eigentlich der Zweck von Kunst? Warum hat sich die menschliche Gesellschaft schon sehr früh Künstlerinnen und Künstler geleistet, die keine Lebensmittel anbauen oder zur Jagd gehen?

Werden die Maschinen, sollten sie einmal vor der gleichen Frage stehen, sich ähnlich entscheiden wie wir Menschen und der Kunst Raum und Ressourcen geben?

Als Künstler*in im Zeitalter der KI

In meinem Bekanntenkreis ist ein junger Mensch, der eigentlich über eine Ausbildung im Bereich Grafikdesign nachdachte. Aber angesichts der rasanten Entwicklung der KI diesen Berufswunsch ad acta legte. Ich fand diese Entscheidung etwas traurig, da sie gefällt wurde, noch bevor das eigene Potential für Kreativität und künstlerische Betätigung sich entfalten konnte.

Auf der anderen Seite war es vielleicht auch klug, denn die neuen KI Werkzeuge werden für viele Zwecke einfach ausreichende Ergebnisse liefern und dieser Berufsgruppe Aufträge wegnehmen. Ob dies ersetzt werden wird durch ein Mehr an Anwendungen von Illustrationen und den Bedarf, sich aus dem Einheitsbrei der generierten Bilder abzusetzen, ist heute kaum abschätzbar.

Trotzdem wird sich hoffentlich niemand, der Lust hat einen Stift oder Pinsel zur Hand zu nehmen, davon abhalten lassen, nur weil es möglich wäre mit Midjourney etwas ähnliches – und das ist vielleicht ein wesentlicher Punkt – etwas ähnliches, aber nicht komplett der eigenen Vision entsprechendes, viel schneller zu erstellen.

Und so, wie die Erfindung des Fotoapparats die Malerei weiterentwickelt hat, weg von der möglichst realitätsnahen Darstellung zu abstrakten Formen, die wir heute viel mehr schätzen, so wird es die KI vermutlich auch tun.

Und dann ist da noch der Aspekt des Originals: Hier wurde im Podcast Autonomie und Datenstrukturen der Begriff der ‚Aura‘ verwendet, die ein Original habe. Und deretwegen sich Menschen in lange Museumsschlangen stellen, nur um die Mona Lisa zu sehen. Obwohl man die schon auf Chipstüten im Supermarkt in Griffweite hat. Und bereit sind horrende Preise für Originalwerke zu bezahlen.

Und selbst wenn sich eine Zahnärztin in Zukunft Bilder für ihre Praxis mit einer KI generieren lassen kann, so wird der Besitz eines Originals von einer lokalen Künstlerin eine andere Wertigkeit und Persönlichkeit haben. Ähnlich wie man auf einem Festival keine Playlist aus dem Internet abspielt, sondern den Kontakt zu den Musiker*innen auf der Bühne herstellen möchte. Das wird KI nicht ersetzen.

ChatGPT Experimente: Generierung von SEO Inhalten für Studiengänge

ihbrune

Kaum klickt man bei Instagram ein paar Mal auf eine der Werbeanzeigen, die revolutionäre Einsatzzwecke der großen Sprachmodelle versprechen, wird man auch schon bombardiert mit weiteren Anzeigen. Zeit einmal selbst erste Schritte in diesem Feld zu machen. Es braucht nur eine Idee und das ist sie:

Inhalte für DESCRIPTION-Tags von 250 Studiengängen

Bei der letzten Betrachtung der Studieninformation der Universität Bielefeld in Hinblick auf die Suchmaschinenoptimierung war ein Ergebnis, dass die Nutzung des DESCRIPTION-Attributs – ein Metadata-Attribut – wünschenswert wäre. Da die Studieninformation eine unserer BIS Anwendungen ist wäre es grundsätzlich leicht, den HTML Inhalt entsprechend zu erweitern.

Das wesentliche Problem ist aber die Aufgabe diese Inhalte überhaupt erst zu erstellen. In unserer Datenbank haben wir nichts, was diesen Zweck gut erfüllen könnte. Bei ca. 250 Studienangeboten ist es keine Kleinigkeit solche Texte aufzubauen und ggf. auch noch abzustimmen.

Wie sollte eine gute Beschreibung aussehen

Google hat natürlich Aussagen dazu, wie ein guter Inhalt aussehen sollte, wobei gleich einschränkend gesagt wird, dass diese Angabe nicht immer verwendet wird. An statt sich die Mühe zu machen hier selbst nachzudenken kann man schon zum ersten Mal ChatGPT (oder ein anderes LLM) befragen, z. B. so:

Ich brauche ein Prompt für ChatGPT 3.5 turbo. Das Prompt soll Texte für ein description Tag in einer Webseite der Universität Bielefeld erzeugen. Die Texte sind Beschreibungen für jeweils einen Studiengang. Was für ein Prompt wäre dafür optimal?

ChatGPT in der Version 4o antwortet darauf so:

Du bist ein KI-Schreibassistent und deine Aufgabe ist es, kurze und prägnante Beschreibungstexte für das description Tag einer Webseite der Universität Bielefeld zu erstellen. Diese Beschreibungen sollen jeweils einen Studiengang vorstellen. Jeder Beschreibungstext sollte etwa 150-160 Zeichen lang sein und die wichtigsten Informationen über den Studiengang enthalten.

Bitte liefere eine Beschreibung für den folgenden Studiengang:

Studiengang: [Name des Studiengangs]

Damit könnte man jetzt manuell schon mal loslegen. Oder in einer Programmierung mit langchain4j daraus ein Prompttemplate erstellen:

Verwendung in einer kleinen Java Anwendung

Die Nutzung des Prompts innerhalb einer eigenen Programmierung erfordert nicht viel. Es reicht ein sogn. Prompttemplate anzulegen, in welches sich dann die studiengangsbezogenen Angaben einfügen lassen:

    public static Prompt provideDescriptionPrompt1(@NotNull FsB fsb, @NotNull Ebene1 e1) {
        String promptTemplateText = """
                Du bist ein KI-Schreibassistent und deine Aufgabe ist es, kurze und prägnante Beschreibungstexte für
                das description Tag einer Webseite der Universität Bielefeld zu erstellen. Diese Beschreibungen
                sollen jeweils einen Studiengang vorstellen und für ihn werben. Jeder Beschreibungstext sollte etwa 150-160 Zeichen lang
                sein und die wichtigsten Informationen über den Studiengang enthalten.
                
                Bitte liefere eine Beschreibung für den folgenden Studiengang:
                
                {{name}}
                
                und verwende dabei diese Beschreibung des Studiengangs:
                
                {{description}}
                """;

        Map<String, Object> variables = new HashMap<>();
        variables.put("name", e1.nameWithFsB(fsb));
        variables.put("description", e1.hasInfotext() ? e1.info_textStripped() : "");

        PromptTemplate promptTemplate = PromptTemplate.from(promptTemplateText);
        return promptTemplate.apply(variables);
    }

In diesem Template wird zusätzlich der Infotext ergänzt, den wir für die meisten Studiengänge haben. Das kann man dann nutzen um es dem Sprachmodell vorzuwerfen und dabei gleich mehrere Versionen abzufragen:

    public static List<String> generateDescriptions(@NotNull ChatLanguageModel model,
                                                    @NotNull FsB fsb, @NotNull Ebene1 e1, int iterations) {

        List<String> description = new ArrayList<>();
        Prompt prompt = provideDescriptionPrompt1(fsb, e1);

        for (int i = 0; i < iterations; i++) {
            description.add(model.generate(prompt.text()));
        }
        return description;
    }

Auf diese Weise lassen sich dann leicht die 250 Fälle durchprobieren. Aber was kommt dabei heraus?

ChatGPT 3.5-turbo

Den ersten Lauf habe ich mit diesem Sprachmodell von OpenAI gemacht, in der API Seite zu den Modellen wird es als fast, inexpensive model for simple tasks beschrieben.

Ergebnisse für 3.5

Betrachten wir dieses Prompt für einen realen Studiengang:

Du bist ein KI-Schreibassistent und deine Aufgabe ist es, kurze und prägnante Beschreibungstexte für
das description Tag einer Webseite der Universität Bielefeld zu erstellen. Diese Beschreibungen
sollen jeweils einen Studiengang vorstellen und für ihn werben. Jeder Beschreibungstext sollte etwa 150-160 Zeichen lang
sein und die wichtigsten Informationen über den Studiengang enthalten.

Bitte liefere eine Beschreibung für den folgenden Studiengang:

Bachelor of Arts Anglistik: British and American Studies Kernfach (fw)

und verwende dabei diese Beschreibung des Studiengangs:

Wer sich für die englischsprachige Literatur- und Medienwelt begeistert, ist bei „Anglistik: British and American Studies“ bestens aufgehoben. Autoren wie William Shakespeare, J.K. Rowling, Mark Twain oder Jack Kerouac werden in diesem Programm unter die Lupe genommen, recherchiert, analysiert und diskutiert.Zu Beginn des Studiums setzen sich die Studierenden auf breiter Grundlage mit den Wissensfeldern Sprache, Literatur und Kultur auseinander. In der zweiten Studienhälfte erfolgt dann eine Schwerpunktbildung, die sich vor allem an späteren Berufswünschen orientieren sollte. Während des gesamten Studiums ist die Vermittlung fachlicher Kompetenzen eng mit der Vermittlung von interkulturellen und kommunikativen Schlüsselkompetenzen verknüpft. „Anglistik: British and American Studies“ kann mit zwei unterschiedlichen geografischen Schwerpunkten studiert werden: British Studies oder American Studies. Diese Themenschwerpunkte spezialisieren sich auf die britischen oder nordamerikanischen Kulturen und Geschichten sowie die Besonderheiten der Literaturen und der Medien dieser Regionen. Studierende setzen sich auf diesem Weg sowohl mit britischen als auch mit nordamerikanischen sprachlichen, kulturellen und literarischen Formen auseinander und erwerben somit neben text- und medienanalytischen Kompetenzen insbesondere interkulturelle und interdisziplinäre Fähigkeiten.Dabei ist der wissenschaftliche Blick der Bielefelder Anglistik nicht nur auf Großbritannien und die USA begrenzt. Vielmehr bezieht er in Forschung und Lehre auch die Sprache, Kultur und Literatur von Sprach- und Kulturgemeinschaften in Afrika, der Karibik oder Indien und von Ländern wie Kanada, Australien, Neuseeland, Irland oder Schottland mit ein.Studierenden, die ein Studium in „Anglistik: British and American Studies“ absolvieren, stehen viele unterschiedliche Berufsfelder offen. Wie viele andere geisteswissenschaftliche Fächer ist dieses Bachelor- Programm nicht auf ein spezifisches Berufsziel ausgerichtet. Die Kompetenzen, die bei einem Studium in Anglistik erworben werden, werden von unseren Absolvent*Innen unterschiedlich eingesetzt, beispielsweise in kulturellen Institutionen wie Museen oder Archiven, der Erwachsenenbildung sowie in städtischen Institutionen oder privaten Firmen in Public Relations, Kommunikation oder in der Medienanalyse.

Der Text ist so unformatiert, da ich ihn vorher von HTML Code bereinigt habe, in der echten Darstellung hat er Umbrüche und eingebettete Videos. Die kursiv gesetzten Teile sind die, die in das Prompttemplate eingefügt wurden. Daraus werden diese 3 Varianten erzeugt. Da jeder Aufruf eines Sprachmodells einen zufälligen Faktor enthält wird ein Ergebnis selten zwei Mal geliefert:

Variante 1:

Der Bachelor of Arts Anglistik: British and American Studies Kernfach (fw) an der Universität Bielefeld bietet eine intensive Auseinandersetzung mit englischsprachiger Literatur und Medien. Von Shakespeare bis Rowling, von Großbritannien bis zu den USA – entdecke die Vielfalt der englischsprachigen Welt. Mit Schwerpunkten in British oder American Studies erwirbst du interkulturelle und interdisziplinäre Fähigkeiten, die in vielen Berufsfeldern gefragt sind, von Museen über PR bis zur Medienanalyse. Entdecke die Welt der englischsprachigen Kulturen und Geschichten an der Universität Bielefeld!

Variante 2:

„Tauche ein in die englischsprachige Literatur- und Medienwelt mit dem Bachelor of Arts Anglistik: British and American Studies Kernfach (fw) an der Universität Bielefeld. Erforsche Autoren wie Shakespeare, Rowling und Twain, spezialisiere dich auf British oder American Studies und erwerbe interkulturelle Kompetenzen für vielfältige Berufsfelder.“

Variante 3:

Mit dem Bachelor of Arts Anglistik: British and American Studies Kernfach tauchst du tief in die englischsprachige Literatur- und Medienwelt ein. Entdecke Autoren wie Shakespeare, Rowling und Twain, erweitere deine interkulturellen Fähigkeiten und wähle zwischen British oder American Studies als Schwerpunkt. Bereite dich auf vielfältige Berufsfelder vor, von der Erwachsenenbildung bis zu Public Relations.

Bewertung der Ergebnisse von 3.5

Eine Sache, die sofort auffällt, ist die Länge der Texte: Der erste umfasst 600 Zeichen, obwohl im Prompt maximal 160 vorgegeben waren. Auch die kürzeste Version ist immer noch mehr als 350 Zeichen lang. Merkwürdigerweise ist die 2. Variante von Hochkommata umgeben, etwas, dass immer mal wieder vorkommt. Generell wirken die Texte aber erstmal durchaus brauchbar.

Geschwindigkeit und Kosten für 3.5

Die Generierung hat mich ca. 30 Cent gekostet. Ich habe keinen genauen Tokencount ermittelt, aber insgesamt sind ca. 750 Abfragen erzeugt worden und dabei teilweise umfangreiche Textmengen mitgeschickt worden.

Gedauert hat der nicht parallelisierte Lauf ca. 25 Minuten. Ob das ist immer so ist, oder von der jeweiligen Last bei OpenAI abhängt, müsste man in weiteren Tests herausfinden. Mein API Key ist ein privater Key, also nicht an ein Enterprise Konto gebunden.

ChatGPT 4o

Dieses Modell bezeichnet OpenAI heute als our fastest and most affordable flagship model.

Ergebnisse für 4o

Hier wurde das gleiche Prompt verwendet wie zuvor, aber die Ergebnisse sind deutlich anders:

Variante 1:

Erleben Sie die englischsprachige Literatur- und Medienwelt im Bachelor „Anglistik: British and American Studies“ an der Uni Bielefeld. Spezialisieren Sie sich auf British oder American Studies und erwerben Sie interkulturelle Kompetenzen.

Variante 2:

Erlebe die Welt der englischsprachigen Literatur und Kultur im Bachelor of Arts Anglistik: British and American Studies an der Universität Bielefeld. Wähle deinen Schwerpunkt!

Variante 3:

Entdecken Sie britische und amerikanische Literatur und Kultur im Bachelor of Arts Anglistik. Vertiefen Sie Ihre Kenntnisse in Sprache, Literatur und Medien und erwerben Sie wertvolle interkulturelle Kompetenzen.

Bewertung der Ergebnisse von 4o

Diese ChatGPT Version hält sich viel besser an die vorgegebene Zeichenanzahl, diese Ausgaben dürften sich vom Umfang her problemlos direkt in die Webseiten einbauen lassen. Hier scheint auch der werbende Charakter, zu dem im Prompt aufgefordert wurde, viel stärker durchzukommen. Das müsste man für einen realen Einsatz vielleicht etwas zurückschrauben.

In diesem Beispiel wird je nach Ergebnis mal mit Du und mal mit Sie angeredet, auch in weiteren Fällen kommt das vor. Hier kann man vermutlich durch das Prompt nachsteuern.

Geschwindigkeit und Kosten für 4o

Die Generierung hat mich hier ca. 2 Euro gekostet. Gedauert hat der Lauf ca. 16 Minuten, also fast 9 Minuten weniger als das 3.5 Modell. Es wurde der gleiche API Key eingesetzt.

Fazit

Das erste größere Experiment mit einer Inhaltsgenerierung per Sprachmodell würde ich als durchaus erfolgreich einstufen. Allerdings müsste man wohl eher zu Version 4o greifen, um verlässlich innerhalb der vorgegebeben Zeichenlänge zu bleiben.

Die Programmierung dafür war innerhalb weniger Stunden erledigt, wobei die meiste Zeit auf das notwendige Lernen der neuen Bestandteile verwendet wurde, nicht weil der Code an sich so komplex ist. Eigentlich ist der Code kinderleicht und damit wirft man dann unglaublich mächtige Werkzeuge in der Cloud an, die verblüffende Dinge tun können.

Könnte man die so generierten Ergebnisse blind und ohne weitere menschliche Qualitätssicherung nutzen? Ich würde diese Frage bejahen, zumindest bei diesen Texten, die für die Besucher*innen unserer Webseite erstmal unsichtbar sind erscheint das Risiko gering und es sind mir keine groben Ausreißer aufgefallen.

Man könnte vielleicht auch die Auswahl des besten Ergebnisses wieder dem Sprachmodell überlassen, ein Prompt zu bauen mit der Frage, welche der drei Zusammenfassung am besten dem ursprünglichen Inhalt entspricht und vielleicht bestimmte Qualitätsvorgaben erfüllt wäre nicht schwer.

Wenn man sich erst einmal daran gewöhnt hat, dass diese Art der Programmierung keine reproduzierbaren und nicht immer zu 100% verlässlichen Ergebnisse bietet, dann kann man mit ihr Dinge in kürzester Zeit erledigen, die vorher für ein kleines Team kaum leistbar waren.

‚ChatGPT Is a Blurry JPEG of the Web’ – eine interessante Analogie zum Verständnis der großen Sprachmodelle

ihbrune

Aus der Folge 109 des Podcasts Auslegungssache mit dem Thema ‘Das KI DSGVO Dilemma’ habe ich einen interessanten Link gezogen: In The New Yorker erschien im Februar 2023 ein Artikel mit diesem Titel und er eröffnet eine etwas andere – und für mich sehr eingängige – Herangehensweise an das Verständnis der großen Sprachmodelle (Large Language Model / LLM):

Statt des Versuchs die komplexen Algorithmen auf eine verständliche Ebene zu bringen, die beim Training eines LLMs große Massen von Daten verarbeiten und in eine Form bringen, aus der sich die manchmal verblüffend intelligent wirkenden Ergebnisse dieser Werkzeuge produzieren lassen, wird hier der Vergleich mit verlustbehafteten Verfahren zur Datenkompression gezogen. Und daraus lässt sich gut ableiten

  • worauf die Antworten der LLMs beruhen,
  • warum sie halluzinieren,
  • in welchen Bereichen ihre Antworten mal mehr und mal (viel) weniger gut sind und
  • warum sich die Antworten von Konversation zu Konversation ändern

Ungenaue Abbildung von Informationen – meist merkt’s niemand

Vermutlich hat jede*r schon einmal erlebt, wie in einem Netflix-Video plötzlich große, unscharfe Artefakte auftauchen, weil die Bandbreite nicht mehr ausreichend ist. Oder wie der Versuch, in einem digitalen Foto kleine Details zu finden, in einer schwammigen Masse von Pixeln endet. Insbesondere wenn das Datenvolumen des Fotos reduziert wurde, was Messenger Apps wie WhatsApp gerne tun, um Speicherplatz zu sparen.

In beiden Fällen enthalten die digitalen Dateien nicht mehr alle Informationen, die bei der ursprünglichen Aufnahme einmal vorhanden waren. Durch geschicktes Ausnutzen der Eigenschaften des menschlichen Sehapparats werden viele Informationen verworfen, ohne dass es einem (meist) beim Betrachten auffällt. In diesem Beispiel mit der Großen Welle von Kanagawa sind zwischen den ersten beiden Bildvarianten kaum Unterschiede auszumachen, auch wenn das Datenvolumen nur noch ca. ein Viertel beträgt:

Erst wenn doch zu viele Informationen bei der Datenkompression verworfen wurden – wie hier im dritten Bild – werden die Lücken erkennbar, die das menschliche Gehirn sonst gerne ersetzt mit Informationen, die gar nicht da sind. Zu welchen umfassenden Ergänzungen oder gar Halluzinationen der Sehapparat dabei fähig ist, zeigt sich zum Beispiel bei Erkrankungen wie dem Charles-Bonnet-Syndrom.

Auch LLMs verwerfen Informationen

Bei der Erstellung der großen Sprachmodelle geschieht etwas ähnliches: Auch wenn es Modelle gibt, die mit Billionen – also tausenden von Milliarden – Parametern hantieren, bedeutet dies nicht, dass das ganze Weltwissen hier wortwörtlich abgespeichert wird. Das kann man grob selbst abschätzen:

Es gibt Datensammlungen wie FineWeb, die versprechen den englischsprachigen Inhalt des Internets verfügbar zu machen. Der vollständige Satz an Daten umfasst ca. 15 Billionen Tokens, was vermutlich einem Datenvolumen von ca. 16 Terabyte entspricht. Und das ist nur der englische Teil des Internets.

Die austrainierten Modelle, die man sich herunterladen kann, sind aber deutlich kleiner, normalerweise im Bereich von Gigabyte, also einem Faktor von bis zu 1.000 kleiner.

Dieser grobe Vergleich hinkt natürlich etwas, weder wissen wir genau, was alles in das Training einzelner Modelle eingegangen ist, noch lässt sich den Modellen jede erdenkliche Frage stellen und das Ergebnis genau überprüfen. Trotzdem zeigt dies schon: Ein LLM kann nicht in der Lage sein, jeden Satz, den man ihm beim Training gezeigt hat, 1-zu-1 wiederzugeben. Das ist ein wesentlicher Unterschied zu einer klassischen Suchmaschine wie Google, die zumindest heute noch weitgehend Textschnipsel aus den entsprechenden Quellen wiedergibt.

Woher kommen dann die geschliffenen Texte und selbstsicheren Antworten?

Da ein Sprachmodell gar nicht mehr alles ‚weiß‘, was einmal in seinem Training eine Rolle spielte, und man es ja auch nach Dingen fragen kann, die garantiert nie in den Trainingsdaten enthalten waren, stellt sich die Frage wie es dann trotzdem antworten kann: Hier findet eine Synthese oder Interpolation auf Basis der reduzierten, im Modell noch vorliegenden Daten statt. Diese Synthese ist eine der großen Stärken dieser Sprachmodelle, wenn es darum geht überraschende Kreationen wie eine Verordnung für das korrekte Binden von Schnürsenkeln zu entwerfen:

Dem Syntheseprozess ist es egal, ob die Fragestellung Sachverhalte zusammenbringt, die in den Trainingsdaten niemals so vorkamen. Es werden einfach die entsprechenden Datenpunkte zusammengeführt und dann los gerechnet. Und dies erzeugt den verblüffenden, menschlicher Kreativität scheinbar nahe kommenden Effekt der Sprachmodelle.

Weniger gut ist dieses Verfahren aber, wenn es um die sachlich korrekte Wiedergabe von Fakten geht:

Ungenaue Wiedergabe erzeugt den Eindruck von Verständnis…oder Blödheit

In dem Artikel wird hier ein interessanter Vergleich mit dem menschlichen Lernprozess gezogen: Wenn uns jemand einen Satz aus einem Lehrbuch – oder der Wikipedia – 1-zu-1 aus dem Gedächtnis vortragen kann, dann halten wir das eher nicht für ein Beispiel von Intelligenz. Höchstens von gutem Gedächtnis. Die Fähigkeit, etwas zu paraphrasieren, ist oft der Kern der Herausforderung bei schriftlichen Prüfungen im Bildungssystem und die 1-zu-1 Kopie ein zu kennzeichnendes Zitat. Oder ein Plagiat, wenn es nicht gekennzeichnet wird. Wer etwas korrekt paraphrasieren kann, der*dem billigen wir zu, einen Sachverhalt verstanden zu haben und anwenden zu können.

Das dem Paraphrasieren zu Grunde liegende Verständnis eines Sachverhalts ist aber auch ein Weg, um diesen trotz einer verlustbehafteten Kompression vollständig wiedergeben zu können. Ein einfaches Beispiel sind hier die Grundrechenarten: Hat man sie verstanden, so kann man jede beliebige Kombination von Zahlen und Rechenregeln korrekt verarbeiten, ohne dass man die (unendlich große) Menge aller möglichen Kombinationen erlernen bzw. abspeichern muss. Eine kurze, verstandene Rechenregel ersetzt hier also riesige Tabellen mit konkreten Rechenergebnissen.

Bei ChatGPT zeigt sich der Effekt der verlustbehafteten Kompression dann aber nicht als Quelle eines daraus entstandenen Verstehens, sondern als schlichter Unsinn:

Die Maschinerie hat hier also nicht den inneren Zusammenhang zwischen Zahlen und Rechenregeln gelernt, sondern gibt letztlich Vermutungen über das mögliche Ergebnis ab, auf der Grundlage von Rechenbeispielen, die im Internet irgendwo zu finden waren. Und gerät bei der mittleren Frage auf Abwege. Was mit dem Wissen, das diese Antworten aus beim Training verwendeten Texten synthetisiert wurden, direkt verständlich wird.

Die (Nach)Frage verändert die Antwort

Ein weiterer, bei der Nutzung von Sprachmodellen zunächst überraschender Effekt ist deren ‚Fähigkeit‘ sich zu korrigieren. Das sieht man an diesem einfachen Beispiel, bei dem ich ChatGPT nach meinem Geburtstag frage:

Hier sieht man zum einen, dass ChatGPT versucht Internetquellen mit Bezug zu der Fragestellung einzubeziehen, also kontextbezogene Informationen zu ergänzen, die beim ursprünglichen Training des Sprachmodells nicht verwendet wurden. Das ist schon eine Erweiterung der grundlegenden Arbeitsweise eines Sprachmodells.

Die erste Antwort ist gewohnt selbstsicher und gibt eine präzise Antwort, auch wenn sie falsch ist, weder Monat noch Tag sind passend. Auf den vorsichtigen Hinweis hin, dass das vielleicht nicht korrekt ist, kommt eine Richtigstellung, die aber auf dem Level eines einfachen Sprachautomatens wie der uralten ELIZA bleibt.

Warum scheint ChatGPT einen Fehler ‚einzugestehen‘? Weil bei der zweiten Antwort die vorherige Konversation berücksichtigt und zur Synthese der Antwort verwendet wird. Hier beeinflusst also der Verlauf der Konversation das Ergebnis.

Unterschiedliche Antworten auf die gleiche Frage

Starte ich eine komplett neue Konversation mit ChatGPT kommt auf die Frage wieder die ursprüngliche, selbstsichere Antwort…nur habe ich dieses Mal am 1. Oktober Geburtstag. Der Grund für die andere – falsche – Antwort ist, dass bei der Synthese der Antworten ein zufälliger Faktor in das Sprachmodell gegeben wird, so dass man selten eine Antwort zweimal erhält.

In Midjourney, der KI zur Generierung von Bildern, erhält man als Reaktion auf eine Eingabe (Prompt) immer gleich 4 Varianten:

Hier kann man sich dann die Variation auswählen, mit der man weiterarbeitet und auf deren Basis man neue Varianten erstellen lässt. Alles, ohne dass man das ursprüngliche Prompt anpassen muss. In ChatGPT gibt es eine Option zur erneuten Generierung einer Antwort, die einen analogen Effekt hat.

Die Konversation nutzen, um die Maschine aufzuschlauen

Der Effekt, dass bei der Synthese einer Antwort die vorherige Konversation berücksichtigt wird, kann verwendet werden um der Maschine – zumindest kurzzeitig – etwas beizubringen:

Dieses ‚Wissen‘ besteht aber nur in dieser speziellen Konversation und steht nicht in der nächsten Konversation zur Verfügung.

Trotzdem kann es für manche Aufgabenstellungen ausreichen um aus Sicht der Nutzer*innen ein an die eigene Situation angepasstes Chaterlebnis zu kreieren, selbst wenn das zu Grunde liegende Sprachmodell gar keine entsprechende Spezialisierung hat. Dazu muss das Chatsystem nur – unsichtbar für die Nutzer*innen – eine entsprechende Vorkonversation führen und das Sprachmodell dadurch in einen entsprechenden Zustand versetzen, auf dem die Nutzer*innen dann ihre eigenen Fragen stellen.

Fazit

Wenn man sich folgende Aspekte von LLMs vergegenwärtigt, ist eine Einschätzung des Verhaltens und der Fähigkeiten vermutlich einfacher möglich, als über den Versuch die tief-technischen Details dieser Systeme zu verstehen:

  • Ein Sprachmodell speichert das Wissen, welches für sein Training verwendet wurde, nicht 1-zu-1 ab. Dies ist ein wesentlicher Unterschied zu Suchmaschinen
  • Zumindest heute können Sprachmodelle daraus keine allgemeinen Regeln wie zum Beispiel die Grundrechenarten destillieren und zuverlässig anwenden
  • Antworten auf Fragen werden aus diesem verdichteten Wissen synthetisiert, die Antworten sind damit grundsätzlich nicht faktentreu
  • Die Halluzination, also die Generierung von unwahren Aussagen, ist ein konzeptioneller Bestandteil eines Sprachmodells und kein Fehler, der sich komplett ausmerzen ließe
  • Die Synthese der Antworten enthält einen zufälligen Faktor, und ist damit meist nicht reproduzierbar
  • Die Antworten werden durch vorherige Konversationen beeinflusst, auf diese Weise lässt sich kurzzeitig zusätzliches Wissen in begrenztem Umfang einspeisen

Einschränkend muss man dazu sagen, dass die Entwicklung der Sprachmodelle stürmisch ist und die verschiedenen Anbieter diese Eigenschaften natürlich genau kennen. Dementsprechend begegnet man heute oft nicht mehr reinen Sprachmodellen, sondern um weitere Funktionen ergänzte Chatbots, die einige dieser Eigenschaften abmildern.

Leseempfehlung: ‚Die Hyperion-Gesänge‘ von Dan Simmons

ihbrune

Urlaubszeit ist Lesezeit bei mir, wann hat man sonst Zeit dafür? Dieses Mal kam der Tipp dazu aus dem Security Now Podcast, den ich hier sonst eher wegen seines eigentlichen Themas ‚IT Sicherheit‘ erwähne, der aber immer mal wieder eine gute Quelle für Science Fiction Literatur ist.

Bei dieser Empfehlung merkt man das Alter der beiden Hosts, denn der erste der beiden Romane, um die er hier geht, wurde im Jahr 1989 veröffentlicht: Hyperion von Dan Simmons. Der folgende Roman, der die Handlung abschließt, ist Der Sturz von Hyperion und erschien ein Jahr darauf. Wer meiner Empfehlung folgt, sollte gleich zu Die Hyperion-Gesänge greifen, ein 2002 erschienener Sammelband mit beiden Teilen.

Gut gealtert

Bei Science Fiction ist es so eine Sache mit dem Altern…manche Romane lesen sich Jahrzehnte nach dem Erscheinen eher albern oder gar peinlich, weil die Autor*innen sich die Zukunft in Details ausgemalt haben, die von der Realität überholt oder aus heutiger Sicht einfach kurzsichtig erscheinen.

Aber Dan Simmons hat es geschafft eine Zukunftsvision zu beschreiben, die sehr ferne Elemente enthält, wie eine verzögerungslose Reisemöglichkeit zwischen den Sternen. Aber auch aus heutiger Sicht bereits (fast) gegenwärtige Elemente, wie ein allgegenwärtiges Datennetz, in dem sich alle Menschen nahezu permanent aufhalten, und dessen Abwesenheit zu Entzugserscheinung und Hilflosigkeit führt. Als er das geschrieben hat gab es das Internet zwar schon in technischer Hinsicht, aber es war nur wenigen Menschen bekannt und die Aussicht, jeder Mensch könnte ein Gerät bei sich führen, welches jederzeit Zugriff auf diese Sphäre ermöglichen, eine Vision, die vielen vermutlich ferner schien als die fliegenden Autos, die wir eigentlich alle schon haben sollten.

Aber auch hier ist die Vision so geschrieben, dass man sich nicht daran stört, wenn von Komlogs (im Original comlogs) die Rede ist und nicht von iPhones, und es betont nur, welche menschlichen Eigenschaften über die Zeit hinweg vielleicht unverändert bleiben werden.

Bestimmte Begriffe wie SimStim oder das schwarze Eis, welches zur Charakterisierung der Datenwelt verwendet wird, deuten auf das Entstehen in den 80ern hin, zumindest kenne ich sie aus den Neuromancer-Romanen, die ein paar Jahres zuvor erschienen und danach sind sie mir nicht mehr begegnet. Aber das wirkt nicht antiquiert, es sind einfach nur Begriffe unter vielen anderen spannenden Wortschöpfungen.

Krieg, Religion, Gier und Altruismus

Die Geschichte hat einige der ‚üblichen‘ Zutaten einer Space Opera: Es gibt Raumschlachten, viele verschiedene Welten, an der Zeit wird herumgespielt, die Menschheit breitet sich kolonisierend über das All aus und benimmt sich dabei nicht besser als die europäischen Eroberer, die weite Teile der Erde unterworfen und ausgebeutet haben, die Sinnfrage ist immer noch nicht abschließend beantwortet.

Allerdings ist dies nur der Hintergrund, vor dem sich die verschiedenen Handlungsstränge entfalten und die ungefähr 10 Individuen bewegen, denen die Geschichte folgt. Und deren individuelle Motivationen anders sind und denen man, auch wenn sie nicht durchweg Sympathieträger sind, durch die mehr als 1.000 Seiten gerne folgt.

Und für mich war am Ende beeindruckend und schön, wie die ganzen Fäden und absurden Einfälle – ich nenne hier nur die merkwürdigen Parasiten – zusammengeführt werden und ein homogenes Gebilde ergeben.

Aktuell: Die Entwicklung der KI

Ein wesentlicher Aspekt der Romane ist aber auch das Entstehen von KIs und deren irgendwann zur Menschheit konkurrierende Entwicklung. Das hier gezeichnete Bild ist grob genug, um heute nicht lächerlich zu wirken, aber die Ideen für so eine Entwicklung lassen sich auch in den durch das Erscheinen von ChatGPT befeuerten Diskussionen wiederfinden und wirken daher weiterhin aktuell.

Und auch das, was ich als eine Kernfrage der Romane sehen würde: Inwieweit sollte man Produkten und ‚Geschenken‘ von KI Systemen vertrauen, die man nicht mehr versteht und deren Motivation damit ebenso wenig?

Bilder aus der KI

Die drei hier enthaltenen Bilder sind dabei auch aus einer KI gekommen. Mit Hilfe von Midjourney habe ich versucht eine Impression zu erstellen, welche bei Leser*innen der Romane hoffentlich schnell eine Assoziation auslösen wird.

Jetbrains AI Assistent – kurz ausprobiert

ihbrune

Wir setzen in der Programmierung der BIS Anwendungen seit einiger Zeit auf Intellij, die Java IDE von Jetbrains, und zwar in der Ultimate Edition. Der Schritt weg von Eclipse – damals schon mit der Spring Tool Suite – war zunächst nicht ganz leicht, aber im Endeffekt sind die Hilfsfunktionen dieses Produkts so leistungsfähig, dass sich der Umstieg gelohnt und die Kosten in Form von besserer Produktqualität und Entwicklungsgeschwindigkeit aus meiner Erfahrung voll zu rechtfertigen sind. Auch die Tatsache, dass Android Studio, welches wir für unsere App verwenden, auf Intellij basiert und somit der Wechsel zwischen den IDEs leichter fällt, ist hier ein Argument.

Was ist der AI Assistent

Seit ein paar Wochen vermarktet Jetbrains nun seinen auf OpenAI Technologien basierenden AI Assistenten und verspricht hier durch die direkte Integration in die IDE – und deren schon vorher vorhandenes, tiefes Verständnis des Programmcodes – eine bessere Leistung und nahtlosere Integration, als sie mit anderen vergleichbaren Tools zu erreichen sei.

Hier ein paar Erfahrungen dazu, wie sich das Tool in einem komplett neu gegründeten Java 22 Projekt anfühlt. Da das hier beschriebene Verhalten vermutlich schon wieder veraltet ist kann man das aber nur als eine momentane Bestandsaufnahme sehen:

Automatische Codevorschläge nur aus der Methodensignatur

Ein erster Effekt ist dieser: Es reicht aus – jedenfalls oft – eine Methodensignatur zu schreiben und der Assistent macht einen Vorschlag. Zum Beispiel sorgt die Signatur

public Set<Fachabschluss> fachAbschluesse()

für diesen völlig korrekten Codevorschlag:

Aufforderung zur Methodenimplementierung per Prompt

Nicht immer klappt es mit dem Automatismus, warum ist mir nicht klar geworden. Aber in so einem Fall kann man per Prompt zur Implementierung auffordern:

Allerdings zeigt sich hier die Unberechenbarkeit der heutigen KI Lösungen: Im ersten Anlauf wurde direkt der passende Code erzeugt. Als ich das Ganze noch einmal für die Screenshots gemacht habe aber nicht und erst ein erneutes Prompt brachte das gewünschte Ergebnis:

Hier wurde also zuerst eine sinnfreie Implementierung vorgeschlagen, die einfach nur null liefert. Es kann natürlich sein, dass der Assistent hier gemerkt hat, dass ich den vorherigen Vorschlag verworfen hatte und daher so ‚reagiert‘. Trotzdem wirkt es etwas skurril und unberechenbar, aber durchaus im Einklang mit den Erfahrungen vom ChatGPT oder Google Bard (inzwischen abgelöst durch Gemini), die fehlerhafte Ergebnisse liefern und dann auf Hinweis auf die Fehler etwas besseres nachliefern.

Überhaupt das Thema Fehler:

Verwendung von nicht existierenden Methoden

Eine Sache, die scheinbar regelmäßig vorkommt, ist die Verwendung von nicht existierenden Codebestandteilen im Vorschlag:

Die richtige Lösung wäre es hier gewesen noch eine Ebene tiefer zu gehen und aus den Modulabschluss-Objekten die enthaltenen Fachabschluss-Objekte zu holen. Und nicht über eine nicht vorhandene Methode eine Filterung durchzuführen.

Konsistenz: Unterschiedliche Lösungen für gleiche Aufgaben

Auch wenn es nicht falsch ist gibt es ein Verhalten, welche mein Stilempfinden stört: Der Assistent erzeugt für gleiche Aufgaben unterschiedlichen Code. Das sind teilweise nur Nuancen, aber sie machen den Code inhomogen und damit schwerer verständlich.

Code Variante 1

    public Set<Fachabschluss> fachAbschluesse() {
        return module.stream()
                .flatMap(mip -> mip.fachAbschluesse().stream())
                .collect(Collectors.toSet());
    }

Code Variante 2

    public Set<Fachabschluss> fachAbschluesse() {
        return profile.stream()
                .map(Profil::fachAbschluesse)
                .flatMap(Set::stream)
                .collect(Collectors.toSet());
    }

Beide Varianten führen zum gleichen Ergebnis, aber es zeigt die Zufälligkeit der von der KI generierten Codes.

Nicht ganz up to date

Das generelle Problem der heutigen LLMs, die prinzipbedingt nicht tagesaktuell sein können, zeigt sich auch hier an manchen Stellen, etwa beim Versuch die Java Version in der pom.xml des maven-Projekts über den Assistenten auf Java 22 zu erhöhen:

Das Java 22 JDK wurde ca. 10 Tage vor dem Schreiben dieses Posts veröffentlicht. Allerdings scheint das ‚Wissen‘ des Assistenten noch deutlich älter zu sein, was man aus der Behauptung schließen kann, die letzte stabile Java Version sei 17. Selbst wenn ’stabile Version‘ die LTS Releases meint, so wäre das Java 21 und das kam am 19. September 2023 raus.

Grundsätzlich führt einen der Assistent hier aber auf die richtige Spur und sagt, was man machen muss. Und das ohne die IDE verlassen zu müssen. In vielen Anwendungsfällen dürfte es nicht stören, wenn der Assistent nicht die allerletzten Sprachversionen kennt. Allerdings hatte ich bei anderen Assistenten auch schon Probleme damit, dass Versionen von Open Source Projekten eingebunden wurden, die entweder schon nicht mehr existierten, oder die wegen lange bekannter Sicherheitsprobleme bereits nicht mehr zur Nutzung empfohlen wurden.

Fazit

Durch das Entstehen von KI Werkzeugen, die Programmcodes in hoher Qualität erstellen können, wird auch das Berufsbild der Softwareentwickler*innen schon jetzt sehr in Frage gestellt. Und was ein Tool wie der Jetbrains Assistent zeigt: Für bestimmte Routinen muss man nicht mehr selbst programmieren können. Oder nur noch in Teilen.

Allerdings ist mein Einsatz des Werkzeugs vermutlich noch zu sehr vom Denken als klassischer Softwareentwickler geprägt, der es gewohnt ist die Struktur seiner Software vorzugeben. Daher habe ich der KI nur etwas Zuarbeit überlassen. Das eigentliche Versprechen ist es aber, dass man eigentlich gar nicht mehr direkt Software entwickeln können muss, sondern ’nur‘ seine Anforderungen und Ziele definiert und der Rest kommt automatisch. Vielleicht noch mit etwas ‚low code‘.

Also so, wie ich beim Generieren von Fotos per Midjourney – siehe das Bild der Roboterhände am Anfang – vorgehe, ohne irgendeine besondere Kenntnis von Malerei oder Graphikdesign zu haben. Aber um so an die Softwareentwicklung herangehen zu können müsste ich erst einmal viel entlernen, was ich mir in Jahrzehnten erarbeitet habe. Mal sehen, ob mir das beim nächsten Versuch gelingt.

Passwortlose Logins per E-Mail: Eine gute Idee?

ihbrune

In dem Security Now Podcast kam in den letzten Wochen – wenigstens bis Folge 965 – getrieben von Hörerkommentaren immer wieder ein Thema hoch: Was ist von ‚passwortlosen‘ Logins per E-Mail zu halten? Der Begriff ‚passwortlos‘ wird im Kontext der zunehmenden Verbreitung von Passkeys gerade oft gebraucht, so gibt es etwa bei Google eine Seite mit dem Titel Passwordless login with passkeys.

Midjourney, Prompt: the rough sketch of a key on the wall of a cave

Aber wäre es da nicht interessant ein passwortloses Loginschema zu haben, das ohne komplizierte Kryptografie und ohne Abhängigkeit zu den großen Betriebssystemanbietern oder Passwort-Managern auskommt? Die Idee ein Verfahren wie E-Mail, das aus der Steinzeit des Internets kommt, gegen eine hochmoderne Idee für Loginverfahren antreten zu lassen, hat dabei einen eigenen Reiz, und am Ende könnte es hier auch im Umfeld von modernen Anwendungen auf Smartphones ein Anwendungsszenario geben:

Wie funktioniert das Verfahren

Mir ist so ein Verfahren zum ersten Mal bei Slack begegnet, dort gab es schon vor Jahren die Loginoption des ‚magischen Links‘. Der Ablauf ist dabei grundsätzlich so:

  1. Auf der Seite des Dienstes, in den ich mich einloggen möchte, gebe ich die E-Mailadresse ein, die zu meinem Konto gehört
  2. Der Dienst schickt an diese Adresse einen Link mit etwas ‚magischem‘, dazu im nächsten Absatz mehr
  3. Ich öffne den Link aus meinem Mailpostfach in meinem Webbrowser
  4. Der Dienst prüft den Link und erzeugt damit eine aktive Loginsitzung für mich
  5. So lange das Sitzungstoken gültig ist bin ich in diesem Webbrowser eingeloggt

Passwortreset – umdefiniert

Das Verfahren des ‚magischen‘ Link Logins hat große Ähnlichkeiten mit den Verfahren, die man für einen Passwortreset per E-Mail implementiert und vielleicht sind die ersten entsprechenden Loginverfahren auch daraus entstanden:

Bei einem Passwortreset wird ein Link zugeschickt mit einem kaum zu erratenden Bestandteil wie einer ausreichend langen, zufälligen Zeichenkette. Sobald Nutzer*innen diesen Link aufrufen muss das Resetverfahren prüfen ob der Link bekannt und noch gültig ist und zu welchem Account er gehört. Nach dieser Prüfung wird die Option angeboten ein neues Passwort zu setzen und Logins damit in Zukunft erfolgreich durchführen zu können.

Midjourney. Prompt: the rough sketch of an opening door painted on the wall of a cave

Aus Sicht der Nutzer*innen ist das durchaus umständlich, vor allem wenn ich nach dem Passwortreset erst noch das komplette Login mit dem neuen Passwort durchführen muss um endlich in den gewünschten Dienst rein zu kommen. Vielleicht ist hier schon die Idee entstanden, den Nutzer*innen nach dem Passwortreset das erneute Login zu ersparen und sie gleich als angemeldet zu betrachten.

Von da war es dann nur noch ein kurzer Weg dazu den Schritt zum Setzen des neuen Passworts ganz auszulassen und gleich zur Durchführung des Logins zu springen. Bei Diensten wie Slack ist so ein Login dann sehr langlebig.

Absicherung des Verfahrens

Wie kann man so ein Verfahren absichern? Die Überlegungen dazu gelten in sehr ähnlicher Weise für eine Passwortresetfunktion per E-Mail:

Abhängigkeit von der Sicherheit des (externen) Postfachs

Ein Punkt muss bei allen Verfahren, die Sicherheitsfunktionen an E-Mail hängen, bewusst sein: Man macht die Sicherheit des eigenen Dienstes vollständig abhängig von der Sicherheit der Mailpostfächer seiner Nutzer*innen.

Je nach Anwendungsszenario kann das eine Entlastung sein, siehe dazu den Abschnitt zu den Vorteilen einer solchen Lösung für Dienstbetreiber. Gerade bei Einsatzszenarien in Diensten des eigenen Unternehmens wirft es aber sehr stark die Frage nach der Sicherheit des Mailsystems auf. Wenn dieses in Sicherheitshinsicht Defizite hat, so übertragen sich diese auf die angebundenen Dienste.

Die Sinnhaftigkeit der folgenden Überlegungen zu Absicherungen muss dann in einem Gesamtkontext betrachtet werden, damit sie nicht leerer Aufwand oder gar Sicherheitstheater werden:

Linkssicherheit 1: Schutz gegen Erraten

Die Sicherheit des Verfahrens hängt ganz grundsätzlich an der Art der verwendeten Links. Diese dürfen sich nicht erraten oder vorhersagen lassen. So wäre es keine gute Idee, wenn der ‚geheime‘ Teil eines solchen Links aus einem auf dem Server laufenden, immer wieder erhöhten Zähler gebildet würde. So ein Muster wäre einfach zu erkennen und zukünftige, gültige Links könnten vorhergesagt werden.

Auch sollten die Links nicht unnötig interne Strukturen der Architektur wie Schlüssel von Datensätzen nach außen geben oder gar als wesentlichen Bestandteile der Echtheitsprüfung der Links enthalten. Zum einem, um keine potentiell sicherheitsrelevanten Informationen nach außen zu geben und zum anderen, weil solche Strukturen oft wieder auf vorhersagbaren Zählern gebildet werden. Auch eine UUID ist hier nicht unbedingt eine gute Wahl, da sie viele vorhersagbare Bestandteile hat.

Midjourney. Prompt: the rough sketch of a string of random glyphs on the wall of a cave

Am saubersten ist hier immer noch ein genügend langer, (pseudo)zufälliger String. Zusammen mit einer Begrenzung der Zugriffsraten auf den Endpunkt, den der Link aufruft, und einer begrenzten Lebensdauer sorgt dies für eine ausreichend geringe Wahrscheinlichkeit, dass so ein Link jemals erraten werden kann.

Linkssicherheit 2: Schutz gegen Replay

Zusätzlich zu einer begrenzten Lebensdauer sollten diese Links nach der ersten Verwendung ‚verbraucht‘ sein, sich also nicht erneut aufrufen lassen. Damit schützt man sich vor Angreifern, denen es irgendwie gelingt ebenfalls an diesen Link zu kommen.

Nicht ganz klar ist mir hier ob es Mailanbieter gibt, die in eintreffenden Mails enthaltene Links generell scannen und dabei aufrufen. Dann würde diese Schutzfunktion den Link invalidieren und faktisch wäre das Verfahren dann mit so einem Mailanbieter nicht nutzbar. Denkbar wäre es hier vielleicht die Anzahl der erlaubten Nutzungen auf 2 oder mehr zu erhöhen, was aber weitere Komplexität und ein potentielles Schlupfloch bringt.

Eine Variante in der Implementierung könnte es daher sein, dass Nutzer*innen nach dem Aufruf des Links den Vorgang explizit durch Anklicken eines Buttons abschließen und erst dieser Vorgang das Login durchführt und den Link invalidiert.

Linksicherheit 3: Bindung an den auslösenden Webbrowser

Die Frage, wie man den Missbrauch eines zum Beispiel beim Mailversand abgefangenen Links möglichst verhindert, war auch Teil der Diskussionen im Podcast. Abgesehen von Szenarien, bei denen Angreifer eine Rolle spielen, kann dies aber auch zur Begrenzung der meist nicht gewollten, bewussten Weitergabe von Logins durch die Nutzer*innen selbst beitragen, da sich Loginlinks dann nicht so einfach weiterleiten lassen:

Die Idee besteht darin den Loginlink nur in dem Webbrowser funktionsfähig zu machen, der den Vorgang initiiert hat. Wird er in einer anderen Umgebung aufgerufen wird keine Loginsitzung angelegt und im Idealfall der Link gleich ungültig gemacht. Welche Mittel kann es dazu geben?

Grundsätzlich sind die hier angestellten, umfangreichen Überlegungen dazu, wie man Logincookies gegen Diebstahl sichern kann, auch hier anwendbar. So wäre es ja zum Beispiel schon etwas verdächtig, wenn der magische Link von einem Rechner in Europa angefordert, aber aus einer Infrastruktur im Russland dann eingelöst werden soll.

Midjourney. Prompt: the rough sketch of a long, rusty chain on the wall of a cave

Es gibt hier aber eine einfachere Möglichkeit: Sofern sich das Formular, in dem die Zustellung des magischen Links angefordert wird, unter der gleichen Domäne befindet wie das Formular, in dem dann der magische Link eingelöst wird, kann hier bei der Linkanforderung ein Cookie mit einem weiteren (zufälligen) Wert platziert werden. Serverseitig wird gemerkt, welches Cookie zu dem magischen Link gehört. Der Abschluss des Logins wird dann vom Vorhandensein des dazugehörenden Cookies abhängig gemacht. Das Cookie darf natürlich nicht das Geheimnis enthalten, welches im magischen Link steckt.

Diese Vorkehrung schützt allerdings nicht davor, dass Angreifer von einem unter ihrer Kontrolle stehenden System aus die Linkzustellung anstoßen und das Opfer per Social Engineering dazu bringen ihnen den Link weiterzuleiten.

Schutz vor automatisiertem Nerven der Nutzerschaft

Es muss ein Schutz eingebaut werden, der eine Belästigung der eigenen Nutzer*innen durch permanentes Auslösen der Reset / Loginfunktion unterbindet. Da das Webformular grundsätzlich ‚offen‘ sein muss um seinen Zweck zu erfüllen, kann es leicht über Scripte bedient und damit beliebig oft von Unbefugten angestoßen werden.

Hier sind clientseitige Funktionen wie ein Captcha denkbar, und serverseitige Begrenzungen, die Zähler führen zur Anzahl der von einer einzelnen IP-Adresse angestoßenen Vorgänge. Im einfachsten Fall kann so eine Schutzfunktion auf den Server bzw. den Endpunkt aufgesattelt werden, wie es z. B. mit dem Anti-DoS-Valve möglich ist.

Ein komplexerer Schutz könnte Mindestabstände bei der Mailzusendung auf einzelnen Nutzer*innen definieren und durchsetzen (‚Nur ein magischer Link alle 30 Minuten‘).

Schutz vor Datenabfluss

Auch dies ist keine einzigartige Aufgabe, die nur in diesem Kontext entsteht, aber trotzdem sollte es für potentielle Angreifer nicht zu einfach sein über diesen Weg herauszufinden, welche E-Mailadressen ein Konto bei einem Anbieter haben.

Vermutlich gibt es kaum einen anderen Weg dafür als auf jede eingetragene E-Mailadresse gleich zu reagieren, egal ob sie mit einem Konto verbunden ist oder nicht oder ob sie gerade auf Grund von zu zahlreichen Anfragen nicht mehr bedient wird.

Der Preis ist eine hohe Intransparenz aus Sicht der Nutzer*innen, denen nicht einmal angezeigt werden kann, dass sie ihre E-Mailadresse falsch eingetragen haben.

Vorteile für einen Dienstbetreiber

Wie die Überlegungen im vorherigen Abschnitt zeigen ist es also insgesamt durchaus ein komplexes Unterfangen ein ‚magisches‘ Link Login aufzubauen und sicher zu gestalten. Trotzdem kann dies für einen Dienstbetreiber eine Vereinfachung darstellen:

(Fast) Keine Geheimnisse

Da keine Passworte oder andere Geheimnisse wie TOTP Secrets vorhanden sind müssen diese nicht geschützt werden und lassen sich damit auch nicht stehlen. Komplexe Überlegungen wie etwa zum richtigen Passwort Hashverfahren braucht es nicht, ebenso wenig zur Wahl des richtigen Zwei-Faktor-Loginverfahrens.

Auch die entsprechenden Funktionen zur Benutzerkontenverwaltung, sowohl in der internen Administration, wie aber auch für die Nutzer*innen selbst, entfallen weitgehend und sparen Entwicklungsaufwände. Bzw. die teilweise enormen Kosten, die spezialisierte Dienstleister hier berechnen. Und auch ein Loginformular braucht es nicht. Vermutlich reduzieren sich auch Supportaufwände, da es hier nicht viel zu erklären gibt.

Wenn die Abhängigkeit von der Sicherheit der von den Nutzer*innen eingesetzten E-Mailkonten kein Problem darstellt, dann entlastet man sich hier von sehr vielen Aufgaben beim Aufbau und Betrieb des eigenen Dienstes und das faktisch ohne dauerhafte Kosten.

Es gibt eigentlich nur ein Geheimnis, welches geschützt werden muss, und das sind die Sitzungscookies, die durch die magischen Links produziert werden. Im Fall eine Kompromittierung könnte man die aber einfach komplett löschen und die Nutzer*innen würden sich dann – wie sie es schon gewohnt sind – erneut per Mail einloggen.

Weniger Reibung bei der Kontoerstellung

Zumindest bei der Erstanlage eines Kontos ist dieser Weg der reibungsfreiere, denn nach der Eingabe der eigenen E-Mailadresse und dem Anklicken des Links ist man bereits handlungsfähig. Kein Nachdenken über ein neues Passwort hält die Kontenerstellung auf.

Gerade für Services, die mit einer hohen Anzahl von spontanen, vielleicht nur selten wiederkehrenden Nutzer*innen zu tun haben, kann dies ein entscheidender Punkt sein.

Ein Stolperstein können hier nur die generellen Probleme mit E-Mail sein, wie eine Klassifizierung der E-Mails als Spam und damit ein vergebliches Warten der Nutzer*innen auf ihren Link.

Aus Sicht der Nutzer*innen

Schon in früheren Folgen des Security Now Podcasts kam bei Diskussionen um die Wahl eines guten Passworts bzw. der Frage ob man noch ohne Passwortmanager ‚leben‘ kann hin und wieder der Hinweis von Hörer*innen, dass sie bei manchen Diensten nur noch irgendwas in das Passwortfeld eintippen und sich nicht merken, nur um dann im Fall des Falls den Passwortreset zu verwenden. So ein Nutzungsmuster wird durch das Login per Link perfekt unterstützt.

Unpraktisch ist es aber in allen Szenarien, in denen häufige Logins notwendig sind. Das Passwort ist hier ein gewisser Weise ein Login Beschleuniger. Gerade bei Szenarien im Unternehmensumfeld wäre es vermutlich keine gute Idee, wenn man seinen Nutzer*innen jeden Tag so ein Loginverfahren zumuten würde. Gangbar könnte es dann sein, wenn es mit sehr langlebigen Logins verknüpft wird und das Mailkonto gut gesichert ist.

Fazit: Eine relevante Technologie mindestens für Nischen

Ich finde die Idee eines Logins per Link durchaus spannend, es bietet eine Bandbreite von Umsetzungsmöglichkeiten, zum Beispiel bei der Lebensdauer der dadurch erzeugten Loginsitzungen. Eine Variante könnte es auf dem Smartphone sein diese Links per SMS/RCS oder Chatanwendung zuzustellen. Oder direkt aus einer eigenen App und zwar in diesem Szenario:

Nahtloser Übergang von einer nativen App in eine Webanwendung

Ein Unternehmen hat eine native App, in der sich die Nutzer*innen normalerweise eingeloggt bewegen. Nicht alle Funktionen der Unternehmensanwendungen sind allerdings in der App erreichbar, an manchen Stellen werden Links in Webanwendungen angeboten.

Midjourney. Prompt: the rough sketch of a smartphone on the wall of a cave

Wenn die Webanwendungen über eine Integration in eine Single Sign-on Lösung verfügen, die in der Lage ist Logins per Link zu bedienen, könnte ein aus Sicht der Nutzer*innen nahtloser Übergang von nativer App in die Webanwendungen so aussehen:

  1. Nutzer*in verwendet die App und ist darin angemeldet
  2. In der App wird ein Link in eine logingeschützte Unternehmensanwendung geöffnet
  3. Die App holt sich vor dem Öffnen des Webbrowsers über eine entsprechende API aus dem Loginsystem einen Loginlink bzw. die ‚magischen‘ Bestandteile dieser Links wie das zufällige Token. Die App gestaltet den Aufruf des Webbrowsers mit der Adresse der Zielanwendung dann in dieser Weise:
  4. Der Aufruf wird über das Loginsystem gelenkt, welches das mitgegebene ‚magische‘ Token auswerten und damit das Login durchführen kann. Das Loginsystem macht dann die Weiterleitung an die jeweilige Webanwendung
  5. Die Webanwendung macht ggf. nochmal eine Schleife über das Loginsystem, per SSO gelingt der Zugriff dann aber ohne erneutes Login

Das komplexe technische Wechselspiel ist dabei vor den Nutzer*innen komplett verborgen und wirkt damit nahtlos. Aus Sicherheitsgründen können die Lebensdauern von so erzeugten Loginsitzungen ggf. stark begrenzt werden, da die App beim nächsten Aufruf wieder ein neues Token generieren kann. In diesem Konzept bleibt vom ‚passwortlosen Login per E-Mail‘ letztlich nur das geheime Token übrig, welches nun zwischen den beteiligten Systemkomponenten ausgetauscht wird, ohne das eine Nutzerinteraktion notwendig ist.

PS.

Die in diesem Artikel verwendeten Bilder wurden mit Midjourney generiert und sollten das Thema des ’steinzeitlichen‘ Mittels E-Mail aufgreifen, welches im Vergleich zu State of the Art Technologien wie Passkeys fast wie Höhlenmalerei wirkt. Aber einfach nicht totzukriegen ist ✊🏻

Wie man Login Cookies vor Diebstahl schützt: Eine Ideensammlung

ihbrune

Beim Aufbau eines zeitgemäßen, webbasierten Loginsystems konzentriert man sich oft zunächst auf den Teil, der bis zum erfolgreichen Login stattfindet: Wie lege ich Passworte sicher ab im System? Wie baue ich eine 2-Faktor-Authentifizierung auf? Wie verhindere ich massenhafte Passwortrateversuche? Kann ich die Resistenz gegen Phishing ausbauen?

In diesem Post geht es aber darum den Teil, der danach passiert, gegen Angriffsszenarien abzusichern und das ist der Teil, in dem sich das Loginsystem dann ‚merkt‘, dass ein erfolgreiches Login durchgeführt wurde und dann nach eigenen Regeln entscheidet, wann es Nutzer*innen erneut nach ihren Logindaten fragt. In Bezug auf das Loginsystem wird im weiteren vom Identity Provider (IdP) gesprochen.

Wie merkt sich ein IdP ein früheres Login

Ein Identity Provider sitzt im Mittelpunkt einer Systemarchitektur, er hat die Aufgabe allen angeschlossenen Systemen die Loginprüfung und Benutzervalidierung abzunehmen und ist damit der singuläre Punkt, in den zur Verbesserung der damit verbundenen Sicherheitsaspekte investiert werden muss. Diese Graphik stammt aus einer Präsentation, die im BIS Kontext einmal gezeigt wurde um diese Struktur zu visualisieren:

Strukturen einer Systems, bei dem ein Identity Provider verschiedene Webanwendungen integriert

Gleichzeitig ist der IdP die Stelle, die ein Single Sign-on umsetzt: Nach dem ersten Login in eine der angeschlossenen Anwendungen kann das Login in die nächste Anwendung ohne für die Nutzer*innen spürbaren, erneuten Loginvorgang erfolgen. Dazu muss der Identity Provider ein Mittel haben um sicher feststellen zu können, dass es bereits so ein erfolgreiches Login gab, zu welcher Nutzerin es gehört und ob es noch gültig und integer ist.

Da es hier um webbasierte Anwendungen geht wird im Weiteren von Cookies gesprochen. Denn für die folgenden Betrachtungen ist es mehr oder weniger unerheblich, ob hier tatsächlich Cookies eingesetzt werden, versteckte Formularfelder oder andere cookie-lose Techniken wie JWTs. Auch ob der Inhalt aus umfangreichen Informationen über die Nutzer*innen und ihre Berechtigungen besteht, oder nur aus einem zufälligen String, spielt keine wesentliche Rolle, denn letztlich geht es immer um ein Informationspaket, welches dem IdP vom Webbrowser präsentiert wird:

Login Cookies als Einfallstor für Angriffe

Da das Login Cookie ausreicht, um die entsprechenden Nutzer*innen gegenüber den IdP zu repräsentieren, ist es ein Weg um den Systemzugriff zu erhalten ohne die eigentlichen Logindaten zu besitzen. Auf diese Weise sind selbst Zugriffe auf Konten möglich, die mit ansonsten komplett diebstahlsicheren Logins etwa über FIDO Keys ausgestattet sind. Der erfolgreiche Angriff auf den Identitätsdienst Okta in diesem Jahr ist hier ein interessantes Beispiel:

Wenn man die beiden Posts, die Okta am 3. November und am 29. November 2023 veröffentlicht hat, nach vollzieht, so konnten die Angreifer Zugriff auf das Kundensupportsystem von Okta erhalten und daraus sogn. HAR-Dateien extrahieren und aus diesen wiederum Login Cookies. Diese HTTP-Archive enthalten alles, was der Webbrowser in Bezug auf eine Webseite kennt, der Warnhinweis auf Googles HAR-Analysetool ist daher entsprechend deutlich:

HAR-Dateien enthalten vertrauliche Daten:

  • den Inhalt der Seiten, die Sie während der Aufzeichnung herunterladen
  • Ihre Cookies, mit denen jeder, der Zugriff auf die HAR-Datei hat, Ihr Konto mit Ihrer Identität nutzen könnte
  • alle während der Aufzeichnung übermittelten Informationen: personenbezogene Daten, Passwörter, Kreditkartennummern usw.
Warnhinweis aus dem HAR-Analysetool von Google

Die Art des Angriffs auf Okta war besonders komplex, aber auch jede Person, die kurz an einem fremden Rechner sitzt, ist prinzipiell in der Lage die Cookies aus einem Webbrowser zu holen, ebenso jede Schadsoftware, die sich im PC oder im Webbrowser eingenistet hat:

Das Risiko wird dabei um so größer, je langlebiger die Cookies sind. Aber wie kann man einen Diebstahl verhindern?

Den Diebstahl kann man nicht verhindern

Generell gibt es für Webanwendungen wie einen Identity Provider heute keine Möglichkeit, die eigenen Geheimnisse perfekt zu schützen. Natürlich muss man dafür sorgen, dass die Cookies nicht einfach für andere Webseiten/-anwendungen auslesbar sind und sie nur verschlüsselt zu übertragen sollte heute eine Selbstverständlichkeit sein.

Genauso wenig darf es möglich sein gültige Cookies ‚aus dem Nichts‘ zu erschaffen, zum Beispiel in dem laufende Nummerierungen vorhergesagt oder die Inhalte bekannt gewordener Cookies modifiziert und zum Beispiel in ihrer Lebensdauer verlängert werden.

Im einfachsten Fall ist das Login Cookie etwas mit diesen Eigenschaften:

  • Der Inhalt ist einfach ein langer Zufallsstring
  • Die Zuordnung dieses Strings zu den konkreten Nutzer*innen erfolgt im IdP z. B. durch eine Datenbankabfrage
  • Auch die Prüfung der Lebensdauer / Gültigkeit erfolgt auf Serverseite auf Basis einer sicheren Informationsquelle wie einer Datenbank mit den bekannten Login Cookies

Dieser Ansatz ist nicht für jede Architektur geeignet, aber er ist einfach ein simples Konstrukt, auf dem sich im weiteren aufbauen lässt. Generell enthält dieses Modell noch nichts, was einen Diebstahl unterbinden oder auch nur erschweren würde, jede Person, die in ihrem Webbrowser dieses Cookie einsetzt wird danach vom IdP als die ursprüngliche Nutzerin akzeptiert und kann in ihrem Namen arbeiten.

Wenn sich ein Diebstahl aber nicht sicher verhindern lässt, dann bleibt nur der Versuch ihn möglichst schnell zu erkennen. Danach können dann Maßnahmen umgesetzt werden, darunter die sofortige Invalidierung des Cookies, potentiell gefolgt von einer Untersuchung, ob es sich wirklich um einen echten Angriff gehandelt hat.

Indicators of compromise

In der IT-Forensic wird ein Artefakt, welches auf eine Kompromittierung hindeutet, als Indicator of compromise (IoC) bezeichnet. So ein Artefakt ist dabei oft nicht für sich allein genommen hilfreich, erst die Betrachtung über mehrere Vorgänge hinweg und dabei beobachtete Veränderungen der verschiedenen Indikatoren können dann Auslöser sein. Aber welche brauchbaren Indikatoren haben wir überhaupt bei Loginvorgängen zur Verfügung:

IP-Adresse

Eine generell vorhandene Information ist die Adresse des Geräts, von dem aus ein Zugriff erfolgt. In der strengsten Auslegung würde ein Login Cookie dann verworfen, wenn es von einer anderen IP-Adresse geliefert wird, als bei der Erstellung verwendet wurde. Das ist aber abgesehen von Fällen, in denen Nutzer*innen immer fixe Adressen haben, keine vernünftige Lösung. Bzw. sie würde im Effekt darauf hinauslaufen, dass ein Single Sign-on faktisch nicht mehr erfolgt und Nutzer*innen sich oft neu anmelden müssen.

IP-Adressbereiche

Interessanter kann eine Prüfung auf Adressbereiche sein: Wenn sich ein Login Cookie nur in den Subnetzen verwenden lässt, in denen es erstellt wurde, ist das Diebstahlspotential deutlich verringert, zumindest wenn man externe Angreifer betrachtet.

Allerdings kann es in einer Universität damit ebenfalls bei weiten Teilen der Nutzerschaft zu einem faktischen Verlust des Single Sign-ons kommen: Nutzungsgruppen wie Studierende wechseln regelmäßig mit ihren Geräten zwischen den Funknetzen der Mobilfunkbetreiber und dem WLAN der Universität und bewegen sich dort in deutlich unterschiedlichen Netzen.

ASN Ebene

Eine noch höhere Ebene sind die AS – die Autonomous Systems – des Internets und die ihnen zugeordneten Nummern, die ASNs. Okta beschreibt in seinem späteren Post dieses Sicherheitsfeature:

Admin Session Binding: As communicated in the Security Incident RCA, customers can now enable an Early Access feature in Okta that requires admins to reauthenticate if their session is reused from an IP address with a different ASN (Autonomous System Number). Okta strongly recommends customers enable this feature to further secure admin sessions.

Quelle: Okta

Da die AS eine so große Struktur im Internet sind, ist dies ein vermutlich ein für viele Anwendungen interessantes Level, welches Zugriffe aus ganz anderen Teilen der Welt aufzeigt, aber nicht so übersensibel ist, wie die vorherigen Ansätze.

Ein Problem ist hier offenbar, dass sich die Zuordnung von IP-Adressen zu ASNs nicht kostenfrei erhalten lässt. Zumindest gibt es Dienstleister wie IP-Info, die mit ASN Datenbanken handeln.

Geolokation

Der Ort, von dem ein Zugriff kam, ist ebenfalls ein interessanter Indikator. Allerdings lässt sich der Zusammenhang zwischen einer IP-Adresse und der physischen Lokation nur ungefähr ermitteln und hier braucht es in jedem Fall einen Dienstleister, wie z. B. die schon zuvor genannte IP-Info, die auch so ein Produkt im Angebot hat.

Auch wenn die Geolokation nicht wirklich sicher zu bestimmen ist kann sie insbesondere dann interessant sein, wenn es darum geht die Nutzer*innen bei fragwürdigen Zugriffen einzubinden: Diese können mit der Information, dass ein Zugriff mit ihren Kontodaten aus irgendeinem IPv6 Netz erfolgt ist, nichts anfangen. Aber die Aussage, dass ein Login auf der anderen Seite der Welt erfolgt ist, könnte sie doch zum Handeln bewegen.

Für die automatisierte Beurteilung, ob ein Zugriff verdächtig erscheint, sind dann aber noch weitere Fragen zu klären. Insbesondere die, ab welcher Distanz ein Zugriff als verdächtig einzustufen ist. Wenn man von Bielefeld ausgeht, wäre dann München Ok, aber London schon nicht mehr? Was ist, wenn ein Nutzer sein Login Cookie in Ägypten angelegt hat, und damit nach Bielefeld zurückkehrt? Und was ist mit Nutzer*innen, die regelmäßig VPN-Dienste verwenden, die sie an wechselnden Punkten der Welt im Internet auftauchen lassen?

Browser Kennzeichen

Auch der Webbrowser, für den ein Cookie ursprünglich ausgestellt wurde, ist ein Merkmal, welches sich nicht vollständig ändern sollte in der normalen Nutzung. Das einfachste Merkmal ist der User Agent String. Mein Chrome Browser gibt sich beim Verfassen dieses Textes so gegenüber Webservern aus:

Mozilla/5.0 (X11; CrOS x86_64 14541.0.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36

Das Chrome hier etwas von Mozilla, Apple, KHTML und Safari nennt hat mit der langen Entwicklung der Webbrowser zu tun. Abgesehen davon gibt es zwei Schwierigkeiten:

  1. Ein Angreifer kann eine Webbrowser Kennung leicht fälschen, gerade im Fall eines Diebstahls von HAR-Dateien wie bei Okta liegen alle dazu notwendigen Daten vor. Selbst wenn diese Informationen nicht vorliegen sollten lassen sie sich erraten, denn es gibt nicht viele Möglichkeiten
  2. Die schnelle Weiterentwicklung von Webbrowsern ändert diese Signaturen spätestens alle paar Wochen. Dies kann man allerdings auch als Sicherheitsfeature sehen und als externen Trigger für die Invalidierung eines Login Cookies nehmen

Ein guter Indikator für einen Diebstahl wäre es, wenn ein Cookie mit einem komplett anderen Webbrowsertyp verwendet würde, oder auf einem anderen Betriebssystem. Aber auch, wenn bei dem verwendeten Webbrowser ein Versionsrückschritt stattfinden würde. Für die Verarbeitung der User Agent Strings gibt es Pakete, zum Beispiel ua_parser.

Generell lässt sich ein Webbrowser auch noch anders identifizieren, die Werbeindustrie ist hier nicht müde Merkmale für ein Fingerprinting zu sammeln, welches Nutzer*innen gegen ihren Willen verfolgen kann. Aber solche Mittel sind für diesen Zweck vermutlich nicht wirklich relevant.

Browser Fingerprinting

Nachtrag: Mein Kollege Nico hat die kurze Abhandlung des Themas Fingerprinting hier kritisiert, daher will ich den Absatz noch etwas ausbauen: Es gibt Angebote wie Fingerprint.js, die zahlreiche Faktoren aus einem Webbrowser extrahieren um damit einen eindeutigen Identifikator zu erstellen. Das Versprechen ist es hier Besucher*innen einer Webseite selbst dann tracken zu können, wenn diese in ein Inkognito-Tab wechseln. Allerdings setzen die Schöpfer*innen dieses Pakets die Zuverlässigkeit eher niedrig ein:

Since FingerprintJS processes and generates the fingerprints from within the browser itself, the accuracy is limited (40% – 60%).

Für die hier diskutierten Zwecke ist das zu wenig, im Durchschnitt wäre dann ja ca. jeder zweite Fingerprint nicht verlässlich. Wobei noch unklar ist, in welcher Richtung: Wird beim gleichen Benutzer immer mal wieder ein abweichendes Ergebnis geliefert? Das wäre besonders ungünstig, da es die Rate der Fehlalarme hoch treiben würde. Oder geht es eher in die andere Richtung, werden für viele Nutzer*innen die gleichen Identifikatoren errechnet? Das würde den Effekt entsprechend relativieren.

Allerdings ist es in gemanagten Umgebungen, in denen zahlreiche Nutzer*innen sehr ähnliche bis völlig identische Umgebungen verwenden, vermutlich sowieso schwierig unterschiedliche Identifikatoren zu erzeugen.

Ea gibt von diesem Anbieter auch eine serverseitige Lösung, bei der eine 99,5% Akkuratesse versprochen wird. Die dabei laut Werbetext verwendeten Verfahren gehen dann aber weit in den Bereich eines Verhaltensfingerprintings:

Fingerprint Identification is able to achieve 99.5% accuracy, because it processes the browser attributes on the server and also analyzes vast amounts of auxiliary data (e.g. IP addresses, time of visit patterns, URL changes, etc.).

Insgesamt erscheint mir so ein Ansatz wie eine Mischung aus schwer zu kalkulierender Verlässlichkeit gepaart mit einem potentiell massiven Datenschutzproblem, zumindest wenn man so ein Fingerprinting bei einem externen Dienstleister stattfinden lässt.

Führen eines Verwendungszählers

Mit der Erkenntnis des vorherigen Abschnitts, wonach sich die Versionsnummer des verwendeten Webbrowsers nicht zurückentwickeln kann, lässt sich eine Funktion implementieren, die zumindest bei einem in aktiver Benutzung befindlichen Login Cookie den längerfristigen Missbrauch sicher verhindern kann:

Wenn man den Zufallsstring, der im Cookie steckt, mit einem Verwendungszähler kombiniert, der bei jedem Aufruf größer wird, fällt die Nutzung des Cookies an zwei unterschiedlichen Stellen direkt auf:

Einer der beiden Nutzer wird ein Cookie mit einer Version liefern, die schon abgelaufen ist, und so ein Ereignis wäre ein sehr deutlicher Indikator für eine Kompromittierung. Im Fall des Okta Hacks wären mit so einer Konstruktion möglicherweise alle gestohlenen Cookies wertlos gewesen, da schon die erste Verwendung zu ihrer Invalidierung geführt hätte.

Der IdP müsste dazu das Login Cookie bei jeder Verwendung aktualisieren und in der Datenbank einen Zähler führen, der immer weiter erhöht wird. Varianten bei der Implementierung können dabei darin bestehen, dass man den Zähler bei ‚1‘ beginnen lässt und dann immer um eins erhöht, oder beide Werte mit einer Zufallskomponente belegt, um Vorhersagen zu erschweren.

Generell scheint dieser Ansatz eine hohe Sicherheit zu bieten, sofern sich das Cookie in aktiver Verwendung befindet. Keinen Schutz würde er bieten, wenn die Nutzerin das Cookie selbst gar nicht mehr im Webbrowser hat bzw. den Webbrowser lange nicht nutzt. Was zum nächsten Punkt führt:

Cookies ohne Verwendung schneller invalidieren

Auch in einem System, in dem die Login Cookies generell langlebig sein sollen, macht es Sinn offenbar nicht mehr verwendete Cookie schneller zu löschen, um die Angriffsfläche zu reduzieren. Um solche Cookies zu finden müssen Zeitstempel für die Nutzung der Cookies gehalten werden. Auswertungen darauf können dann offenbar inaktive Cookies in der Datenbank finden und entfernen.

Dieser Inaktivitätszeitraum bis zur Löschung kann dann vielleicht nur eine oder zwei Wochen lang sein. Lang genug, um ein verlängertes Wochenende zu überleben, aber nicht viel länger.

Nutzer*innen die Invalidierung von nicht mehr benötigten Cookies ermöglichen

Auch die Nutzer*innen selbst einzubinden kann ein weiterer Faktor sein, um abhanden gekommene Cookies schadlos zu machen. Hier würde eine Anzeigeseite benötigt, die alle aktiven Cookies auflistet mit weiteren Informationen dazu, damit Nutzer*innen entscheiden können, ob sie noch relevant sind. Die Nutzer*innen brauchen dann eine Möglichkeit nicht mehr notwendige Cookies zu löschen.

Generelles Nutzerverhalten

Schließlich kann auch das Verhalten der einzelnen Nutzer*innen Indikatoren bieten: Ist eine Person normalerweise nie am Wochenende im System unterwegs oder an Feiertagen? Und dann immer zwischen 9 und 17 Uhr? Dann kann der Zugriff außerhalb solcher Zeiten zumindest dazu führen, dass das Login erneut vorgenommen werden muss.

Solche Auswertungen müssen aber, zumindest wenn sie personenscharf gemacht werden und nicht aus generellen Regeln entspringen, in datenschutz- und personalrechtlicher Hinsicht geprüft und abgesichert werden. Hier gerät man ggf. tief in das Spannungsfeld zwischen IT Sicherheit, die möglichst viele Daten sammeln will, und anderen Regelungen, die genau das Gegenteil verlangen.

Fazit

Es gibt also eine ganze Reihe von denkbaren Indikatoren, die man – wenn schon nicht zum Schutz vor Diebstahl – dann wenigstens zur Abmilderung seiner Schadfolgen einführen kann. Meine Favoriten sind dabei diese:

  1. Nutzer*innen müssen sehen, welche Cookies für ihren Account aktiv sind, und sie bereinigen können
  2. Inaktive Cookies schneller bereinigen als aktive
  3. Der Verwendungszähler bei Cookies ist einfach zu implementieren und bietet zugleich einen hohen Schutz
  4. User Agent String des Webbrowsers: Hier könnte man zunächst die ganz einfache Implementierung testen, die bei jeder Änderung dieser Kennzeichnung das Cookie invalidiert
  5. ASN und Geolokation, da insbesondere die Geolokation weitere Anwendungen hat, z. B. bei der Information von Nutzer*innen über Logins von neuen Geräten

Grundsätzlich braucht es für alle diese Vorgehensweisen eine Datenbank der aktiven Login Cookies, die die entsprechenden Informationen wie den Zeitpunkt der letzten Verwendung, den User Agent String, etc. aufnimmt und damit für vergleichende Auswertungen zugänglich macht.

Umgang mit anschlagenden Indikatoren

Wenn wir nun einen IdP haben, der alle diese Indikatoren hat, eine umfangreiche Datenbank mit dem Verlauf dieser Indikatoren führt und vielleicht sogar automatisierte Auswertungen machen kann, die über einzelne Nutzer*innen hinweg gehen um ein Gesamtbild zu erhalten, wie gehen wir dann damit um, dass einer oder mehrere Indikatoren anschlagen? Hier ist eine große Spannbreite vorstellbar:

  • Stilles Löschen des verdächtigen Cookies und Neulogin der Nutzer*innen: Hier würde der IdP das vom Webbrowser kommenden Cookie nicht mehr akzeptieren und aus seiner Datenbank entfernen und aus Sicht der Nutzer*innen einfach ein erneutes Login verlangen. Diese Vorgehensweise erzeugt im IT Betrieb keine weitere Arbeit, würde aber einen erfolgten, zumindest teilweise erfolgreichen Angriff nicht weiter auffallen lassen
  • Information an die Nutzer*innen: Hier würde eine Information an die Nutzer*innen beim Loginvorgang stattfinden, die auf ‚ungewöhnliche Aktivitäten‘ in ihrem Konto hinweist und sie auffordert eine Prüfung durchzuführen. Für so eine Prüfung müsste es allerdings eine Grundlage geben wie z. B. die Auswertung der Zugriffsprotokolle samt entsprechender Informationen. Dieses Vorgehen hat aber vermutlich wenig Zweck: Nutzer*innen würden erfahrungsgemäß die Hinweise entweder ignorieren, oder sich aufgeschreckt an den IT Support mit dem Wunsch wenden, diese Prüfungen für sie durchzuführen
  • Hintergrundauswertungen mit Information an die Systemadministration: Hier würden aus den Indikatoren generierte Alarme zunächst an die zuständige IT Administration gegeben, die sie bewerten müsste. Wenn der IT Betrieb entsprechend aufgestellt ist könnte dies die Reaktionszeit bei echten Vorfällen deutlich verkürzen und es könnte eine übergreifende Sichtweise eingenommen werden. Auf der anderen Seite dürften die Indikatoren und die ausgelösten Alarme dann nicht so sensibel sein, dass es hier zu häufigen Fehlalarmen und damit zur Ermüdung der zuständigen Personen kommt. Ein SIEM System könnte aber vielleicht ein guter Abnehmer für solche Signale sein und sie dann mit Indikatoren aus anderen Systemen zusammenführen