Anmelden
Die Fleißner-Schablone und der IRA-Code sind zwei Transpositionschiffren, die von der Kreativität ihrer Erfinder zeugen.
Sehr viele clevere Methoden zum Verschlüsseln von Texten gerieten im Laufe der Jahre zu Unrecht in Vergessenheit. Deshalb zeigen wir Ihnen einige der Schätze aus der Geschichte der Kryptografie, die es wert sind, genauer betrachtet zu werden. Einerseits, um zu verstehen, warum sie sich als unsicher erwiesen, aber auch, um die hübschen Ideen hinter den Verfahren zu würdigen.
Bisher haben wir uns in dieser Artikelserie mit Pigpen, Playfair, Chaocipher [1] [1], Nyctografie, Büchercodes und der Kryha-Maschine [2] [2] beschäftigt sowie im letzten Teil der Reihe mit der Barbier-Nachtschrift, den Codebüchern und abschließend dem ADFGX-Code [3] [3]. Dieses Mal behandeln wir die Fleißner-Schablone, die ab 1881 in vielen Armeen als Verschlüsselungstechnik zum Einsatz kam, und den IRA-Code von 1925. Damit ist ein System gemeint, das die paramilitärische Irisch-Republikanische Armee verwendet hat, um sicher zu kommunizieren, und das erst Anfang der 2000er vom Kryptologen James Gillogly geknackt wurde.
Beide Verfahren eint, dass es sich bei ihnen um Transpositionschiffren handelt. Das bedeutet, die Buchstaben des Klartextes bleiben erhalten, sie tauschen jedoch ihre Plätze – als würde man ein kompliziertes unleserliches Anagramm des gesamten Textes anfertigen. Solche Verfahren sind zwar schon lange bekannt, kamen jedoch in der frühen Neuzeit selten vor. Der Gedanke liegt nicht fern, dass man lieber ein Verfahren nutzt, das die originalen Buchstaben des Klartextes stärker verschleiert und sie zum Beispiel durch völlig andere Symbole ersetzt (Substitution). Solche Verfahren hielt man lange für sicherer, als den Klartext durcheinanderzubringen. Schließlich sind bei einer Transposition die Buchstaben der Nachricht ja noch da, auch wenn in anderer Reihenfolge. Dass der IRA-Code und die Fleißner-Schablone dennoch breit eingesetzt wurden, macht die Chiffren besonders und ist Grund genug, sie unter die Lupe zu nehmen.
URL dieses Artikels:
https://www.heise.de/-11346251
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise online / dmk)
Das Have-I-Been-Pwned-Projekt hat 821.100 Kontodaten des Messgeräteherstellers Fluke zur Datenhalde hinzugefügt.
Der Messgeräte- und Testequipment-Hersteller Fluke gehört zu den Opfern des jüngsten Beutezugs der Cybergang ShinyHunters. Die Daten haben die Kriminellen Anfang Juli dieses Jahres angeblich aus dem Salesforce-Zugang von Fluke entwendet und sollen insgesamt 21 Millionen Datensätze umfassen, einschließlich einiger sensibler persönlicher Informationen. Das Have-I-Been-Pwned-Projekt (HIBP) hat die Datenbank in die Finger bekommen und die sensiblen Datensätze herausdestilliert sowie zur Datenhalde hinzugefügt.
Der Beitrag bei HIBP [1] führt aus, dass es sich am Ende um 821.100 Kundendatensätze handelt. Insgesamt haben die Täter mehr als 100 GByte an Daten veröffentlicht, die angeblich von Fluke stammen. Laut Troy Hunt, dem Betreiber von Have I Been Pwned, besteht der Datensatz größtenteils aus Kontaktinformationen des Unternehmens. Dazu gehören aber auch mehr als 800.000 eindeutige E-Mail-Adressen, Namen, Telefonnummern sowie Anschriften. Zudem handele es sich um eine große Sammlung an Supportfällen – was zu einem Datendiebstahl bei Salesforce passt.
Wer mit dem Support von Fluke in Kontakt stand, kann auf der Hauptseite von Have I Been Pwned prüfen [2], ob die E-Mail-Adresse und die weiteren persönlichen Informationen dadurch nun in unbefugte Hände gefallen sind. Diese Informationen können Cyberkriminelle etwa nutzen, um gezielte und glaubwürdigere Phishing-Kampagnen aufzusetzen, die sich gegen Fluke-Kunden richten. Wenn die eigene E-Mail-Adresse also bei Have I Been Pwned auftaucht, sollte man daher erhöhte Vorsicht bei Nachrichten walten lassen, die Fluke betreffen. Insbesondere Passwort-Anfragen oder Mails, die zeitlichen Druck aufbauen, sollten nicht beantwortet werden. Gegebenenfalls sind dann Rückfragen direkt bei Fluke über die bekannten Kanäle sinnvoll.
Es handelt sich nicht um das erste Datenleck bei Fluke. Mitte vergangenen November hat etwa die kriminelle Cyberbande cl0p behauptet, Daten bei Fluke [3] abgezogen zu haben. Das geschah mutmaßlich über Sicherheitslücken in Oracles E-Business-Suite (EBS).
URL dieses Artikels:
https://www.heise.de/-11367041
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Apple-Laden in Shanghai: Genug Geld in der Kasse auch für größere Aufkäufe.
(Bild: gob_cu / Shutterstock)
Spezialisierte Prozessoren für Training und Inferenz müssen nicht von Nvidia kommen. Davon ist man offenbar bei Apple überzeugt und streckt die Fühler aus.
Apple soll derzeit aktiv versuchen, interessante KI-Chip-Unternehmen aufzukaufen, um sich von Lieferanten wie Nvidia unabhängiger zu machen. Laut einem Bericht des IT-Fachdienstes The Information geht es spezifisch um Technik für Rechenzentren, also Training und Inferenz. Nachdem Apple für seine Cloud-KI zunächst eigene Private-Cloud-Compute-Server mit Apple-Silicon-Technik [1] (wohl M2 Ultra [2]) verwendet hatte, nutzt Apple mit Siri AI [3] künftig verstärkt Nvidia-Hardware, die bei Google Cloud gehostet wird. Als Basis dienen dabei eigens angepasste Gemini-Modelle. Offenbar kommen außerdem Googles hauseigene TPUs [4] zum Einsatz.
Nach The Information gab es in den vergangenen Monaten unter anderem Gespräche mit Banken [5], die als Broker für Halbleiter-Start-ups tätig sind. Weiterhin gab es offenbar auch schon direkte Gespräche mit solchen Firmen. Apple scheint dabei bereit, höhere Beträge in die Hand zu nehmen – möglicherweise im Milliardenbereich. Die Kriegskasse des iPhone-Konzerns gilt als gut gefüllt.
Dass Apple unter dem ab September antretenden neuen Chef John Ternus [6] bereit ist, größere Akquisitionen zu tätigen, lässt sich schon daran ablesen, dass vor Kurzem für 2 Milliarden US-Dollar das israelische KI-Startup Q.ai [7] übernommen worden war. Die Firma hat ein Prinzip entwickelt, mit dem man „sprachlos“ mit KI-Assistenten kommunizieren kann, indem Mikroausdrücke im Gesicht ausgelesen werden können. Die Kaufsumme ist die zweitgrößte, die Apple jemals für eine Übernahme aufgebracht hat, nur der Kopfhörerhersteller Beats [8] war dem Konzern mit 3 Milliarden Dollar mehr wert.
In welche Richtung Apple tendiert, ist noch unklar. Der iPhone-Hersteller gilt allerdings als sehr erfolgreich, was die Integration von Aufkäufen betrifft. So stellte die Übernahme der Chipfirma PA Semi [9] im Jahr 2008 die Basis für die Apple-Silicon-Chips dar [10], die Apples Hardware-Produkte revolutioniert haben. Die Kaufsumme war mit 278 Millionen Dollar klein.
Apple soll intern versucht haben, Gemini-Modelle auch auf eigenen Servern laufen zu lassen. Das sei aber gescheitert. Ein Vorteil für Apple beim Kauf von KI-Chip-Firmen könnte sein, dass der Konzern Spezialtechnik kauft – es gibt durchaus innovative Ansätze, die über das hinaus gehen, was Nvidia mit Weiterentwicklungen klassischer GPUs leistet. Allerdings ist die Technik nicht marktreif. Eine Integration bei Apple könnte zudem Jahre dauern. Intern soll der Konzern allerdings bereits damit planen, Googles Gemini-Modelle eines Tages doch wieder durch Apple-Technik zu ersetzen.
URL dieses Artikels:
https://www.heise.de/-11366368
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: LCV/Shutterstock.com)
IBM Bob 2.0 soll auch Jahrzehnte alten Code verstehen und modernisieren können – mit KI-Agenten und Premium-Paketen für Z, i und Java.
Mit Bob 2.0 erweitert IBM die KI-gestützte Software-Entwicklung, die den gesamten Software-Lebenszyklus im Enterprise-Bereich abdecken soll. Bob unterstützt Entwickler bei Planung, Code-Generierung, Validierung, Refactoring und Modernisierung.
Ursprünglich im Oktober 2025, als Project Bob eingeführt wurde [1], handelte es sich um den agentenbasierten Nachfolger von Watsonx Code Assistant. Das ist ein KI-gestütztes Entwicklungs-Tool, das tief in die jeweilige Entwicklungsumgebung (IDE) integriert werden kann und Programmieraufgaben nicht nur vorschlägt, sondern proaktiv ausführt. Hierbei kommen eigenständige Premium-Pakete mit getesteten Workflows für ganz spezifische Einsatzfelder ins Spiel: das Bob Premium Package for Java Modernization [2], das Premium Package für IBM i [3] und das Premium Package für IBM Z [4].
Aktuell sind nur Workflows verfügbar, die mit Bob und diesen drei Paketen ausgeliefert werden; mehr Möglichkeiten für die Programmierer soll es erst geben, sobald die neue API-Oberfläche sich bei den bisherigen Anwendern eingespielt hat. Für klassische AIX- und Linux-basierte Systeme auf Power-Servern agiert Bob als intelligenter Partner in der Entwicklungsumgebung (IDE, oft Visual Studio Code), der folgende Stärken ausspielen soll:
Zu den angekündigten Neuerungen der agentenbasierten Software-Entwicklungsplattform [5] gehören Multi-Agenten-Funktionen, integrierte KI-Analysen zu Kosten und Nutzung sowie vorgefertigte, spezialisierte Workflows zur Modernisierung von Legacy-Software, zum Beispiel COBOL- oder RPG-Programmen.
Versprochen wird ein Tool, das die Absichten, die spezifische Codebasis und die eigenen Standards desjenigen Unternehmens „versteht“, in dem es zum Einsatz kommen soll. Dazu kann man in den „Architekten-Modus“ wechseln, wenn es darum geht, komplexe Software-Systeme zu entwerfen, oder aber auch im „Code-Modus“ mit dem KI-System arbeiten, um schneller beim Codieren voranzukommen oder effizient Entwicklungsschritte zu iterieren.
Bob kann laut Hersteller die Codebasis „lesen“ und „verstehen“, Frameworks modernisieren, Refactorings in großem Maßstab durchführen und Software unter Berücksichtigung des gesamten Kontexts auf neue Plattformen migrieren. Mit eingebautem Fachwissen zu Standards wie FedRAMP, HIPAA oder PCI kann die Bereitstellung von sicherem, produktionsreifem Code schneller erfolgen, so das Versprechen.
Die neue Version bringt aber auch erhebliche Änderungen am bisherigen Produkt mit sich, sowohl hinsichtlich der architektonischen Grundlagen, als auch der Funktionen, die den Anwendern zur Verfügung stehen. Bob 2.0 basiert nunmehr auf einer dreistufigen Architektur: den Agenten, dem sogenannten „Harness“ und den Clients.
Ein Agent bietet Funktionen zur Schlussfolgerung und Codegenerierung, während der „Harness“ zusätzlich Aufgaben wie Authentifizierung, Protokollierung und Telemetrie übernimmt. In der KI-Welt liefert ein Harness die Software-Infrastruktur [6], die ein Sprachmodell (wie etwa ein LLM) umgibt und es diesem ermöglicht, eigenständig Aufgaben auszuführen, anstatt nur Fragen zu beantworten. Bei einem Harness wird auch gern die Analogie zum vom Reiten bekannten Zaumzeug bemüht. Er soll dem KI-Modell Leitplanken, Tools und Kontrollmechanismen wie menschliche Freigaben zur Verfügung stellen, damit die KI sicher und fokussiert arbeiten kann.
Diese einheitliche Basis ist eine große Veränderung gegenüber Bob 1.0, bei dem dafür jeweils unterschiedliche Technologien verwendet wurden. Deshalb konnte IBM die erste Version des Produktes zwar schneller auf den Markt bringen, doch wäre der Aufwand für die Weiterentwicklung viel größer gewesen, da jede Änderung mehrmals umgesetzt werden musste.
Nun gibt es auch vorgefertigte Workflows, die Teams an ihre eigenen Umgebungen anpassen und erweitern können, um sicherzustellen, dass die Ergebnisse konsistent und überprüfbar sind – und zwar unabhängig davon, wer sie ausführt. Nutzer können nun auf „Bobalytics“ zugreifen, eine neue Funktion, mit der sie den Verbrauch überwachen, Ressourcen zuweisen und den Überblick behalten können, um die KI entsprechend ihren internen Vorgaben zu skalieren. Außerdem ist es nun für Modelle möglich, mehrere Tools in einem Durchgang anzufordern und gemeinsam auszuführen.
Zudem verwalten Subagenten den Kontext in großem Maßstab. Das ist wichtig, denn jeder explorative Schritt einer KI – sei es das Lesen von Dateien, Suchvorgänge oder Funktionsverfolgungen – kann das Kontextfenster überladen und die Kosten in die Höhe treiben. Jetzt wickeln Bob-Subagenten komplexe Aufgaben in einem isolierten Kontext ab, um schnelle Antworten zu liefern und gleichzeitig die Kosten zu kontrollieren.
Ebenfalls neu sind drei Premium-Pakete für KI-native Workflows, die strukturiert, wiederholbar, auditierbar und speziell für Umgebungen entwickelt wurden, für die andere Werkzeuge nicht ausgelegt sind.
Das Tool wird über ein eigenes Preismodell [7] abgerechnet; statt einer Token-Abrechnungen wird ein Credit-basiertes System namens Bobcoins (Preisübersicht) [8] genutzt. Ein Bobcoin entspricht 0,50 US-Dollar (bzw. rund 0,45 Euro) und wird gemäß der jeweiligen Aufgabenkomplexität abgerechnet. Der Einstiegspreis für Bob Pro liegt bei 20 US-Dollar (40 Bobcoins) pro Monat.
URL dieses Artikels:
https://www.heise.de/-11367017
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: software-architektur.tv)
In der Episode diskutiert Eberhard Wolff mit Dr. Felix Sühlmann-Faul über digitale Souveränität und die Bedeutung des PRIVA SCORE für Architekturentscheidungen.
Digitale Souveränität und Datenschutz gelten vielen Entwicklern als lästige Pflicht, als Hemmschuh für schnelle Umsetzung. Der Techniksoziologe Dr. Felix Sühlmann-Faul sieht das anders: Für ihn sind beide Themen eine Voraussetzung für demokratische Handlungsfähigkeit – und ganz praktisch für die Software-Architektur. In dieser Episode spricht Eberhard Wolff mit Sühlmann-Faul über die Auswirkungen dieses Themenkomplexes und über den von ihm entwickelten PRIVA SCORE.
Felix Sühlmann-Fauls [1] Verständnis von digitaler Souveränität ist stark praxis- und organisationsorientiert. In einem Blogbeitrag beschreibt er sie als die Kontrolle über eigene Daten und digitale Prozesse. Datensouveränität überschneidet sich für ihn eng mit dem Konzept der informationellen Selbstbestimmung: Die Einzelperson müsse entscheiden können, wem sie Daten übergebe, was die empfangende Institution damit mache und zu welchem Zweck. Open-Source-Software bezeichnet er dabei nicht nur als Mittel zum Zweck, sondern als effektivsten Weg zu mehr Souveränität – und skizziert einen phasenweisen Migrationsansatz, der mit einer Bestandsaufnahme beginnt und über Pilotprojekte bis zur Umstellung geschäftskritischer Systeme reicht.
Kern des Gesprächs ist der PRIVA SCORE, den Sühlmann-Faul unter anderem im Rahmen seiner Dissertation entwickelt hat. Das Projekt beschreibt sich selbst als „Datenschutz-Ampel für Digitales“ und als Entscheidungshilfe für die Auswahl datenschutzfreundlicher Apps und digitaler Dienste. Für die Software-Architektur wird das Ampelsystem interessant, wenn es um die Auswahl von Werkzeugen geht: Externe Dienste wie Cloud-Speicher, Messaging, Videokonferenzen oder CRM-Systeme sind heute typische Architekturbausteine.
Eine Ampelbewertung kann Dienste mit schwacher Datenschutzbilanz faktisch disqualifizieren und Alternativen mit besserer Einstufung in den Vordergrund rücken – und damit Sourcing-Strategien beeinflussen, etwa zugunsten EU-basierter Cloud-Angebote gegenüber US-Hyperscalern oder zugunsten DSGVO-konformer Messenger. In der Governance von Softwareprojekten ließe sich ein solches Rating zudem als verbindliches Kriterium einsetzen, etwa als Mindestscore im Freigabeprozess für neue SaaS-Dienste.
Wer sich über das Livestream-Gespräch hinaus für das Thema interessiert: Sühlmann-Faul spricht bei den IT-Tagen 2026, die vom 7. bis 10. Dezember 2026 in Frankfurt stattfinden (Mit dem Code ITT26-SIS-352 erhalten Interessierte 100 Euro Rabatt auf ein Ticket).
Die Ausstrahlung findet am Freitag, 17. Juli 2026, live ab 13:00 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite [3] einbringen.
software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt [4], der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer [5] (Socreatory) und Ralf D. Müller [6] (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet heise Developer über die Episoden.
URL dieses Artikels:
https://www.heise.de/-11364666
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: yu_photo / Shutterstock)
Das aktuelle Perl geht einen weiteren Schritt in Richtung moderner Objektorientierung. Außerdem schließt Perl 5.44 drei Sicherheitslücken.
Das aktuelle Perl 5.44 erlaubt es, innerhalb von Signaturen benannte Parameter mit zugehörigen Default-Werten zu deklarieren:
FreshRSS sub make_colour ( :$red = 0, :$green = 0, :$blue = 0 ) { ... }
make_colour( red => 1.0, blue => 0.5 );
Wie in Raku [1] (ehemals Perl 6) werden sie mit dem Präfix : vor der Sigil gekennzeichnet. Dieser Doppelpunkt ist nicht Teil des Variablennamens, und beim Aufruf muss man die Sigil weglassen.
Benannte Parameter müssen keinen Default-Wert erhalten und sind immer optional. Das ermöglicht die Kombination mit positionalen Parametern. In diesem Fall müssen beim Methodenaufruf immer zuerst die Positionsargumente stehen. Benannte Parameter werden bis mindestens Perl 5.46 experimentell bleiben und erfordern deshalb diesen Zusatz:
use v5.44;
use experimental 'signature_named_parameters';
Neben einer langen Liste an behobenen Fehlern und einigen Performanceverbesserungen wurden auch drei Sicherheitslücken geschlossen, die einen Pufferüberlauf auslösen konnten.
Die Lücke CVE-2026-8376 [2] betrifft reguläre Ausdrücke, die aus alternativen Unicode-Zeichenketten bestehen. Mit CVE-2026-13221 [3] war das Verhalten der Befehle pack und unpack betroffen. CVE-2026-57432 [4] schlug nur bei äußerst großen regulären Ausdrücken zu, die aus mehr als 65.000 alternativen Teilausdrücken bestehen.
Bemerkenswert ist das endgültige Abschalten einer Funktionsweise, die bereits seit Perl 5.12 [5] als veraltet gekennzeichnet ist. Nun ist es endlich nicht mehr gestattet, mittels goto in Schleifen, Subroutinen und ähnliche funktionstragende Blöcke hineinzuspringen.
Eine Übersicht mit allen behobenen Fehlern, Dokumentationsänderungen, Fehlermeldungen und weiteren Interna ist in der Dokumentation zum aktuellen Release [6] einsehbar.
URL dieses Artikels:
https://www.heise.de/-11366654
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Wer ein kulturstiftendes Epos verfilmt, muss mit Finten tricksen und Kompromisse eingehen. Das sorgt für Gesprächsstoff, wie unsere Filmanalyse zeigt.
Christopher Nolan ist einer der wenigen lebenden Regisseure, die sich den Regeln der Filmbranche widersetzen können und trotzdem, oder gerade deswegen, immer wieder Massen ins Kino locken. Wo andere mit computergenerierter Grafik (CGI) und digitalen Filmkameras Kosten sparen, segelt er auf echten Schiffen aus Holz und nimmt sie mit dem größten und teuersten analogen Kinoformat auf, das es gibt. Wenn ihm die Technik der Kameras nicht genügt, lässt er eben neue bauen.
Sein dreizehnter Film „Die Odyssee“, der am 16. Juli in die Kinos kommt, ist sein bisher aufwendigstes Projekt. Dabei musste Nolan, ganz wie seine Hauptfigur Odysseus, zahlreiche Strudel und Klippen umschiffen. Allein die Besetzungsliste rief Kulturkonservative und Identitäre auf die Barrikaden, bevor sie auch nur eine Minute des Films gesehen hatten. Entgegen guter alter griechischer Tradition hatte es der Regisseur nämlich gewagt, die Frauenrollen nicht mit Männern und die der Göttin Athene mit einer Sterblichen zu besetzen. Nolan hilft diese Aufmerksamkeit jedoch ungemein: Wer im aktuellen Kulturkampf mitreden will, kommt nicht umhin, sich den Film anzuschauen (und diesen Artikel zu lesen).
Wir haben den Film bereits vorab gesehen und können dringende Fragen beantworten: Wie interpretiert Nolan die Odyssee? Welche Aspekte verstärkt er, welche drängt er in den Hintergrund? Welches Vorwissen setzt er voraus? Was bringen die IMAX-Kameras tatsächlich – und in welchen Formaten lässt sich der Film sehen? Wo steht das Werk im Kanon des Regisseurs? Trägt das Ensemble? Und wie modern ist Nolans Lesart? Unsere umfangreiche Analyse lässt sich deshalb zweimal lesen: vor der Vorstellung als spoilerfreier Text über Vorgeschichte, Technik, Inszenierung und Ästhetik, danach als Untersuchung der Figuren, der Abweichungen von Homer und der abschließenden Wendung – auf die Gefahrenstellen weisen wir rechtzeitig hin.
URL dieses Artikels:
https://www.heise.de/-11353151
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Manuel Masiero / KI / iX)
Googles offizielle IDE für die Entwicklung von Android-Apps setzt verstärkt auf KI-Integration, unter anderem mit mehreren parallel laufenden Agentenchats.
Android Studio Quail 2 steht als stabiles Release bereit. Gegenüber dem Vorgänger Quail 1 zeichnet sich die Android-IDE durch drei wesentliche Neuerungen aus: eine Multitasking-Architektur für parallele Agentenchats, native LeakCanary-Integration im Profiler sowie eine jetzt vollständig mit Agent Mode integrierte agentengestützte Crash-Analyse in App Quality Insights.
Die parallelen Agentenchats von Android Studio Quail 2 [1] überwinden den bisherigen Engpass, dass sich Agenten-Tasks nur sequenziell abarbeiten ließen. Damit erlaubt es die neue Version Entwicklerinnen und Entwicklern beispielsweise, in einem Tab ein UI-Refactoring zu starten, in einem zweiten eine ProGuard-Regel neu zu definieren und in einem dritten die Dokumentation zu generieren. Jedem Tab lässt sich ein individuelles Modell zuweisen. Worktree-Support gibt es mit den parallelen Agentenchats allerdings nicht.
(Bild: Google)
LeakCanary und App Quality Insights (AQI) greifen Entwicklern unter die Arme, um Fehler aufzuspüren und zu beheben, ebenfalls KI-gestützt. Das Open-Source-Tool LeakCanary [2] steckt nativ im Profiler und spürt Speicherlecks laut Google bis zu fünfmal schneller auf als bisher, indem es die Leak-Nachverfolgung vom Testgerät auf den Entwicklungsrechner verlagert. Der Button „Go to Declaration“ springt zur entsprechenden Codestelle, während „Fix with Agent“ sie nach User-Zustimmung mittels KI-generiertem Codepflaster schließt.
AQI setzt auf den gleichen Modus Operandi. Klicken Developer im AQI-Panel auf ein Crash-Ereignis, erhalten sie eine Zusammenfassung des Problems, in einem eigenen Chat und auf Wunsch noch eine umfassende Erklärung dazu. Beides basiert auf dem jeweils ausgewählten Modell. „Fix with AI“ soll dann ebenfalls für schnelle Abhilfe sorgen.
Google bietet Android Studio Quail 2, dessen tierischer Codename Quail (Wachtel) für die 2026-Generation der IDE steht, für Windows, macOS, Linux und ChromeOS zum Download [3] an. Android Studio Quail 3 [4] ist bereits als Release Candidate verfügbar.
URL dieses Artikels:
https://www.heise.de/-11365583
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: evkaz / Shutterstock.com)
Gut 290 GitHub-Repositorys, die angeblich von Securityanbietern, Toolherstellern und weiteren Firmen sind, verteilen Schadcode zum Abgreifen von Daten.
Angreifer haben hunderte GitHub-Repositorys angelegt, die vermeintlich von bekannten Firmen stammen. Ein Link auf die „official page“ im Readme führt zu einer Seite der Angreifer, die einen Infostealer verteilt.
Die Schadsoftware greift Credentials und vertrauliche Daten von mindestens 19 Webbrowsern und zahlreichen Krypto-Wallets ab. Auch Messenger und Social-Media-Anwendungen sowie Steam-Accounts sind im Fokus der Angreifer.
Der Angriff nutzt keine Schwachstellen aus, sondern setzt auf Brandjacking und Social Engineering. Die Repositorys geben vor, von bekannten Firmen unter anderem aus den Bereichen Security, Entwicklungswerkzeuge, Krypto-Tools, Fintech und Gaming-Software zu stammen. Der Schadcode läuft ausschließlich auf Windows-Rechnern.
Sicherheitsforscher von Arctic Wolf haben den Angriff entdeckt. Der Auslöser war, dass ein Fake-Repository vorgab, von Arctic Wolf zu stammen. Bei den weiteren Untersuchungen haben die Forscher festgestellt, dass die Angreifer insgesamt 292 Repositorys erstellt hatten, von denen GitHub inzwischen die meisten entfernt hat.
Einige Repositorys sind jedoch vermutlich noch aktiv und es ist möglich, dass die Angreifer weitere Fake-Repositorys erstellen.
Der Angriffsvektor ist jedes Mal derselbe. Für das Fake-Repository zu Arctic Wolf enthielt die Markdown-Datei mit dem Readme (README.md) einen Link zur vermeintlichen „official page“ des Anbieters und der Software. Dieser Link führte zu einer Domain der Angreifer, die sich wiederum als Arctic-Wolf-Seite ausgab und ein Paket zum kostenlosen Download angeboten hat.
Der Download-Button trug die Schrift „Download Secure Content“ und zahlreiche Badges wiesen darauf hin, dass die Verbindung sicher und die Software auf Viren geprüft sei.
(Bild: Arctic Wolf)
Der Klick auf den Button löste den Download einer ZIP-Datei aus. Offenbar erzeugte der Server, der das Paket verteilte, im Minutentakt frische Pakete mit jeweils geänderten ZIP-Dateinamen und neuen Namen der Executables.
Neben dem Schadcode enthielt das Archiv viel Beifang, der nach Vermutung der Sicherheitsforscher lediglich dazu dient, die ZIP-Datei auf die erwartete Größe zu bringen. Der eigentliche Schadcode steckte in zwei Dateien: gup.exe zum Laden der Datei libcurl.dll, die wiederum den Infostealer dekodiert und im Speicher ausführt.
Der Infostealer ist laut der Analyse von Arctic Wolf eine Variante des im März von Trend Micro entdeckten BoryptGrab [2], der darauf ausgelegt ist, zahlreiche Daten und Credentials abzugreifen. Allerdings ist der für den Angriff genutzte Schadcode auf ein Minimum reduziert und lädt im Gegensatz zu BoryptGrab keine weiteren Payloads nach.
Die einzelnen Module des Infostealers zielen dabei auf unterschiedliche Browser, Messenger, Krypto-Wallets und mehr.
Die gesammelten Daten schickt die Software schließlich als ZIP-Archiv an einen russischen Server.
(Bild: Arctic Wolf)
Der Infostealer läuft nach dem Start nur einmal durch und versucht nicht, sich als automatisch gestarteter Prozess festzusetzen. Er macht auch keine Anstalten, sich auf andere Systeme zu verteilen.
Auch verzichtet der Schadcode auf Aufräumarbeiten: Alle gesammelten Daten und auch Logdateien der Software bleiben in einem temporären Verzeichnis, das die Software nach getaner Arbeit nicht löscht.
Weitere Details zu den einzelnen Modulen im Infostealer und den spezifischen IP-Adressen der Angreifer finden sich im Arctic-Wolf-Blog [3].
URL dieses Artikels:
https://www.heise.de/-11365096
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Motorola bringt mit dem Edge 70 Max ein neues Oberklasse-Smartphone mit Riesenakku und sehr hellem Display für 799 Euro auf den Markt.
Motorola erweitert seine Edge-Serie um das Edge 70 Max. Das Smartphone soll ab dem 15. Juli in ausgewählten europäischen Märkten erhältlich sein und kostet in der Variante mit 8 GByte RAM und 256 GByte UFS-4.1-Speicher 799 Euro.
Im Mittelpunkt steht der mit 7100 mAh ungewöhnlich große Akku. Motorola setzt dabei auf eine Silizium-Kohlenstoff-Chemie, die eine höhere Energiedichte als klassische Lithium-Ionen-Akkus ermöglichen soll. Geladen wird per USB-C mit bis zu 90 Watt, kabellos sind nach Qi2-Standard bis zu 25 Watt möglich. Zudem unterstützt das Gerät kabelgebundenes Reverse Charging mit 5 Watt.
Auch das Display fällt auf. Das 6,82 Zoll große AMOLED-Panel löst mit 1440 × 3168 Pixeln auf, unterstützt Bildwiederholraten bis 144 Hz und erreicht laut Motorola eine Spitzenhelligkeit von bis zu 7000 Nits. Das Display ist HDR10+-fähig und Pantone-validiert.
Für die Rechenleistung sorgt Qualcomms Snapdragon 8 Gen 5. Motorola kombiniert den SoC mit 8 GByte LPDDR5X-Arbeitsspeicher und integriert ein 5500 Quadratmillimeter großes Vapor-Chamber-Kühlsystem mit Flüssigmetall, das die Abwärme unter Last besser abführen soll. Nach Herstellerangaben steigt die CPU-Leistung gegenüber der vorherigen Snapdragon-Generation um 36 Prozent, die GPU-Leistung um 11 Prozent und die NPU-Leistung um 46 Prozent.
Bei der Kamera setzt Motorola auf einen 50-Megapixel-Sensor vom Typ Sony LYTIA 710 mit optischer Bildstabilisierung. Hinzu kommen eine 8-Megapixel-Ultraweitwinkelkamera mit Makrofunktion sowie eine 32-Megapixel-Frontkamera. Ein Tele gibt es nicht.
Das 221 Gramm schwere Smartphone besitzt einen Rahmen aus Aluminium sowie Gorilla Glass 7i auf Vorder- und Rückseite. Es erfüllt laut Hersteller die Schutzklassen IP68 und IP69 sowie den Militärstandard MIL-STD-810H. Als Betriebssystem kommt Android 16 zum Einsatz. Das Smartphone soll laut Hersteller drei große Android-Updates und bis zu fünf Jahre lang Sicherheitsupdates erhalten.
Ab dem 15. Juli soll das Motorola Edge 70 Max für 799 Euro erhältlich sein. Zum Marktstart legt Motorola nach eigenen Angaben bei Käufen über den eigenen Online-Shop unter anderem die Moto Buds Loop und ein 125-Watt-Netzteil bei.
URL dieses Artikels:
https://www.heise.de/-11364958
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Interessierte Menschen begutachten die KABINE auf einer gemeinsamen Veranstaltung der Uniklinik RWTH Aachen und dem Technischen Hilfswerk und weiteren Beteiligten.
(Bild: Uniklinik RWTH Aachen)
Eine Toilettenkabine soll die medizinische Versorgung im Ernstfall verbessern. Wie das funktioniert, erklärt Dr. Andreas Follmann von der Uniklinik RWTH Aachen.
Wenn nach einer Katastrophe Arztpraxen und Krankenhäuser nicht mehr erreichbar sind, könnte eine handelsübliche Toilettenkabine als telemedizinische Behandlungsstation aushelfen. Mit diesem ungewöhnlichen Konzept wollte ein Forschungskonsortium unter Beteiligung der Uniklinik RWTH Aachen die medizinische Versorgung im Katastrophenfall verbessern. Die mobile Einheit soll laut Uniklinik dort zum Einsatz kommen, wo „Arztpraxen, Krankenhäuser oder Verkehrswege vorübergehend nicht erreichbar oder überlastet sind" oder die Infrastruktur ausgefallen ist. Nach ersten Erprobungen, unter anderem auf dem Musikfestival Parookaville, wurde der Prototyp weiterentwickelt. Im Juli wurde das Forschungsprojekt mit einer öffentlichen Abschlussdemonstration auf dem Gelände des Technischen Hilfswerks in Aachen offiziell beendet.
(Bild: RWTH Uniklinik Aachen)
Im Gespräch erklärt Dr. Andreas Follmann von der Uniklinik RWTH Aachen, Mitglied des Projektkonsortiums, welche Erkenntnisse die Praxistests gebracht haben und warum die Kabine inzwischen rot statt grau ist.
Die Kabine sieht nicht mehr aus wie ein Dixi-Klo, sondern ist jetzt rot. Warum?
Andreas Follmann: Rot ist tatsächlich eine Signalfarbe, wenn es darum geht, gut aufzufallen. Gerade im Katastrophenfall ist das wichtig, weil dort häufig mehrere dieser Toiletten- oder Duschkabinen stehen. Das Ziel ist, dass man diejenige Kabine, die man für medizinische Zwecke aufsuchen muss, direkt findet. Außerdem gibt es Studien, die belegen, dass bei Rot und Orange am wenigsten Vandalismus zu befürchten ist. Das ist ein zusätzlicher psychologischer Effekt.
Hat sich außer der Farbe technisch etwas verändert?
Technisch hat sich kaum was geändert. Wir haben die alte Kabine in mehreren Studien getestet – unter anderem in einer Simulationsstudie, die man sich wie ein Krimi-Dinner vorstellen kann – und beim Musikfestival Parookaville. Das war für uns natürlich extrem spannend, weil es sich um echte Patienten mit echten Problemen handelte. Dort haben wir gemerkt, dass die von uns zuvor ausgewählte Technik dafür sehr gut geeignet war.
Am Anfang dachten wir, das sogenannte Dermatoskop würden wir am wenigsten brauchen. Tatsächlich gab es bei Parookaville aber extrem viele Hautveränderungen. Es war heiß und schwül, entsprechend gab es viele Insektenstiche und Allergien. Viele hatten Probleme mit Grasmilben, bei denen man sich die Hautveränderungen sehr genau ansehen musste, um dann gezielt zum Beispiel eine Salbe zu verschreiben.
Zur Ausstattung gehören neben einem EKG und einer Untersuchungskamera, die mit verschiedenen Aufsätzen etwa als Otoskop fürs Ohr oder als Dermatoskop für die Haut genutzt werden kann, auch weiterhin laientaugliche, über Bluetooth angebundene Medizingeräte.
Gab es trotzdem Anpassungen?
Ja, an der Usability hat sich einiges verändert. Das EKG war vorher eine kleine, scheckkartengroße Box, auf die man zwei Finger legen musste. Mittlerweile gibt es Haltegriffe, an denen man sich einfach festhalten kann.
Außerdem ist der Toilettensitz jetzt Gott sei Dank nicht mehr drin. Wir hatten vorher den Tank genutzt, um Technik reinzubauen. Mittlerweile ist alles etwas kleiner geworden, und es gibt einen richtigen Stuhl darin, den man auch herausstellen kann – so haben auch Menschen mit einem kleinen Rollstuhl die Möglichkeit, sich dort reinzusetzen.
Wir haben zudem Erwachsene mit Kindern hineingesetzt, um zu prüfen, ob die Kameraposition auch für Kinder passt und ob die Begleitperson zumindest teilweise mit hineinkommt. Deshalb haben wir auch einen Stuhl genommen, der höhenverstellbar ist.
Welche Grenzen sind bei der Evaluierung deutlich geworden?
Generell ist der Betrieb noch nicht ganz klar. Wer bevorratet das System? Ist das die Hilfsorganisation oder ein Land oder eine Kommune? Zwischendurch muss vielleicht auch mal gereinigt oder desinfiziert werden. Deshalb ist unsere klare Empfehlung, die Kabinen an sogenannten Katastrophenschutz-Leuchttürmen aufzustellen. Das sind vorab festgelegte Standorte, meist bei der Freiwilligen Feuerwehr oder der Verwaltung, an denen Internet und Strom auch über Notstromaggregate zur Verfügung stehen sollen. Zwar ist die Kabine dank der Solarpaneele und der Satellitenkommunikation für eine gewisse Zeit autark. Trotzdem wünschen wir uns natürlich, dass auch Personal bereitsteht, um Betreuung zur Verfügung zu stellen und vielleicht auch mal Verbrauchsmaterial nachzufüllen.
Ein weiterer Punkt ist die Logistik. Die Toilettenkabinen lassen sich laut Hersteller innerhalb von 30 Minuten aufbauen. Deshalb ist die Frage, ob künftig vielleicht nur noch die Technik eingelagert werden muss, weil die Kabinen ohnehin schnell lieferbar wären. Baut man die Technik zum Beispiel in eine Box, braucht man natürlich viel weniger Lagerkapazität und Wartungsaufwand. Das wäre dann ein modulares Konzept: Die Kabinen kommen separat, und die Box wird einfach an die Wand gehängt.
Die neue Kabine sieht nach der Überarbeitung recht massiv aus. Kann sie noch einfach transportiert werden?
Ja. Es ist eine ganz normale Toilettenkabine aus Kunststoff, die von uns lediglich innen ausgestattet wurde. Nur der Tank wurde entfernt, und es ist ein gerader Boden eingebaut. Die kann man mit zwei Personen problemlos versetzen. Zusätzlich hat sie oben auch eine Kranhalterung. Wir haben sie inzwischen auch schon an einen Kran gehängt, zum Beispiel vom THW. Damit kann man sie sehr schnell positionieren.
Es gibt bereits viele fertige Logistikkonzepte für diese Toilettenkabinen. Toilettenkabinen werden oft auch mit Spülflüssigkeit angeliefert und haben dann ein ähnliches Gewicht. Sie können zum Beispiel über einen Tieflader mit Kran angeliefert und leicht versetzt werden.
Haben Sie versucht, die Kabine günstig zu entwickeln?
Ja. Unser Ziel war immer, sie so günstig wie möglich zu machen. Wir wollten, dass sie unter 5000 Euro kostet.
Die enthaltenen Geräte sollen möglichst einfach funktionieren. Außerdem sollen Teile, auch wenn die Kabine Schaden nimmt, wiederverwendet werden können. Es kann auch sein, dass die gesamte Kabine, ohne Inhalt, entsorgt werden oder ihrem ursprünglichen Zweck zugeführt werden muss. Denkbar wäre auch, dass sich das System ganz ohne die Kabine nutzen lässt – also nur die Technik allein.
Das Konzept ließe sich doch auch außerhalb des Katastrophenschutzes einsetzen?
Ja, deshalb glaube ich auch an diesen modularen Ansatz mit einer Box. Die kann ich natürlich genauso in eine Apotheke hängen. Es kann ja auch mal sein, dass zum Beispiel in einem Gemeindehaus noch ein Raum zur Verfügung steht. Dann brauche ich vielleicht die Kabine gar nicht. Dann würde ich diese Box einfach in einen Raum hängen.
Die Toilettenkabine ist für uns insofern praktisch, da sie kostengünstig ist und weit unter 1000 Euro kostet. Sie kann sogar per Boot transportiert werden, weil sie schwimmfähig ist, oder alternativ auf einem Tieflader. Mit diesem Kranhaken kann man sie theoretisch sogar an einen Helikopter hängen, um sie in ein Dorf zu fliegen, das etwa durch einen Brückeneinsturz von der Außenwelt abgeschnitten ist.
Wie geht es nach dem Forschungsprojekt weiter?
Das Projekt wird vom Bundesministerium für Forschung, Technologie und Raumfahrt gefördert. Das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe ist als assoziierter Partner beteiligt, ebenso das Generalsekretariat des Deutschen Roten Kreuzes in Berlin. Das Forschungsprojekt wurde inzwischen erfolgreich abgeschlossen und live demonstriert [1].
Das DRK ist tatsächlich sehr daran interessiert, mit uns weiterzudenken, welche Ebene für die Bevorratung zuständig sein sollte. Sollte jedes Bundesland zehn Kabinen haben oder jede Kommune, jeder Katastrophenschutz-Leuchtturm eine? Das betrifft auch das Thema Wartung. Die Medizingeräte sind mit Sicherheit in fünf Jahren überholt und müssen erneuert werden.
Es bringt nichts, wenn das Ergebnis, wie so oft bei Forschungsprojekten, am Ende nur in irgendeiner Schublade landet. Man muss im Endeffekt genau diesen Zwischenschritt schaffen: Dass jemand sagt, wir brauchen jetzt 20 Stück davon, und ein Unternehmen bereit ist, sie zu verkaufen.
Gibt es bereits weitere Einsatzideen?
Eine große Überlegung ist, ob man das System nicht auch für Routinezwecke einbinden kann. Wir denken da zum Beispiel an Sanitätswachdienste auf Großveranstaltungen oder daran, im Rahmen der Flüchtlingsversorgung medizinische Hilfe auch im fremdsprachigen Bereich zu gewährleisten. Bis hin zu der Überlegung, ob man eine solche Kabine dort aufstellen könnte, wenn in einem Dorf plötzlich kein Hausarzt mehr verfügbar ist – um zumindest stundenweise an manchen Tagen eine hausärztliche Grundversorgung durch einen anderen Arzt zu gewährleisten.
Welche Software kommt zum Einsatz?
Als Basis für die Software nutzen wir „TeleDoc“, eine zertifizierte Videosprechstunde der Docs in Clouds TeleCare GmbH. Die medizinischen Geräte sind alle in die Software integriert und übertragen ihre Daten per Bluetooth. Im Use Case Parookaville und bei den Simulationsstudien war das sehr stabil. Es ist alles kabelgebunden oder per Bluetooth angeschlossen.
Das Ganze funktioniert als Webplattform. Ich kann es quasi überall auf der Welt nutzen und der Arzt kann sich dank Satellitenkommunikation aus der Ferne zuschalten. Zusätzlich habe ich die Möglichkeit, extern auch LAN anzuschließen – steht die Kabine beispielsweise an einem Katastrophenschutz-Leuchtturm, kann ich gegebenenfalls das lokale Internet nutzen.
URL dieses Artikels:
https://www.heise.de/-11359097
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Die Samsung SSD 980 bekommt eine Nachfolgerin. Die 990 ist rund doppelt so schnell, verwendet allerdings QLC-Speicher.
Samsung stellt die SSD 990 als neues Einstiegsmodell vor. Wie schon die 980er-Vorgängerin fehlt ein Anhängsel wie Pro oder Evo. Unter der Haube hat sich einiges getan: Der Controller wechselt von PCI Express (PCIe) 3.0 auf 4.0, was in etwa mit einer Geschwindigkeitsverdoppelung einhergeht. Vierstellige Modellnummern bleiben bei Samsung bis auf Weiteres PCIe-5.0-Topmodellen vorbehalten.
Auf dem Papier weniger erfreulich ist der Wechsel der NAND-Flash-Speicherbausteine. Kamen bisher Typen zum Einsatz, die drei Bit pro Zelle speichern (Triple Level Cells, TLC), sind es jetzt vier Bit pro Zelle (Quadruple Level Cells, QLC [1] [1]). Das senkt die Schreibleistung beim Kopieren großer Dateien, dürfte sich im alltäglichen Gebrauch bei den meisten aber nur selten bemerkbar machen.
Auf Seiten der Kapazität fallen die Varianten unter einem Terabyte weg. Stattdessen bietet Samsung die SSD 990 neben der 1-TByte-Version jetzt auch eine mit 2 TByte an.
URL dieses Artikels:
https://www.heise.de/-11364577
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: M5Stack)
Das offizielle Flash-Tool für M5Stack-Geräte weist gravierende Sicherheitsmängel auf. Ein Leser hat die Probleme analysiert und sicheren Ersatz entwickelt.
M5Stack-Geräte wie der Cardputer ADV [1] werden über M5Burner verwaltet: Das offizielle Desktop-Tool erlaubt es, Firmware zu durchsuchen, herunterzuladen und direkt auf die Hardware zu flashen. Doch wer M5Burner im Netz betreibt, geht ein erhebliches Risiko ein – das hat unser Leser und Sicherheitsforscher „malloc“ in einer detaillierten Analyse aufgedeckt.
Der User malloc [2] hat den Electron-basierten Closed-Source-Client (frühere Versionen waren noch Open Source) dekompiliert und dabei eine ganze Reihe von Problemen gefunden:
Wer M5Burner aktuell nutzt, sollte das Tool zumindest nicht in öffentlichen oder nicht vertrauenswürdigen WLANs starten. Für Login, Firmware-Verwaltung und Flashen steht m5uploader als quelloffene Alternative [3] (s.u.) bereit.
Die meisten betroffenen M5Stack-Server unterstützen laut Tests von malloc HTTPS bereits problemlos. Die App nutzt es schlicht nicht konsequent. So wurde jeder genutzte Host geprüft. Mit einer Ausnahme (einem Media-Token-Endpunkt auf Port 5003 ohne TLS-Support) wäre ein simples Umstellen der URLs auf https:// bereits ein großer Schritt für die Sicherheit gewesen. Electron bietet zudem sichere Standardeinstellungen (nodeIntegration: false, contextIsolation: true), die M5Burner aktiv deaktiviert.
Bevor malloc seine Analyse veröffentlichte, versuchte er zunächst, M5Stack privat zu kontaktieren. Er suchte nach einer security.txt, einem SECURITY.md im GitHub-Repository des Unternehmens sowie nach einem dedizierten Sicherheitskontakt auf der Website und fand nichts. Da kein privater Meldeweg existierte, entschied er sich, die Schwachstellen direkt öffentlich zu machen. Der Blogpost ist damit gleichzeitig die Erstmeldung an den Hersteller. malloc schreibt dazu selbst, er hätte eine private Meldung bevorzugt, ihm fehlte schlicht die Adresse dafür. Die beschriebene RCE-Lücke ist damit zum Zeitpunkt der Veröffentlichung gegen die aktuelle, ausgelieferte Version von M5Burner aktiv ausnutzbar.
Weil malloc M5Burner nach der Analyse nicht mehr gegen sein eigenes Konto laufen lassen wollte, hat er kurzerhand einen eigenen Client entwickelt und auf GitHub veröffentlicht: m5uploader (github.com/cryptspeak/m5uploader) [4].
Das Python-Tool setzt konsequent auf HTTPS mit Zertifikatsprüfung, verzichtet auf einen eingebetteten Browser und speichert den Session-Token im OS-Keychain. Ein Auto-Updater fehlt bewusst – stattdessen gibt es nur einen Hinweis auf neue Versionen. Firmware-Flashing via esptool ist inzwischen ebenfalls integriert.
URL dieses Artikels:
https://www.heise.de/-11364555
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: heise medien)
Laut Mozilla-Report hat Open-Source-KI einen Wendepunkt erreicht. Der Leistungsabstand zu proprietären Modellen ist gering, Kosten sinken.
Open-Source-KI hat nach Einschätzung von Mozilla einen Wendepunkt erreicht. Der Browserhersteller sieht offene Sprachmodelle nicht länger als technologisch deutlich unterlegen gegenüber proprietären Angeboten wie ChatGPT oder Claude. Laut dem ersten „State of Open Source AI“-Report beträgt der Leistungsabstand zu den führenden geschlossenen Modellen auf Basis der LMSYS Chatbot Arena nur noch rund 3,3 Prozentpunkte. Gleichzeitig seien die Inferenzkosten innerhalb von drei Jahren von rund 20 US-Dollar auf etwa 40 Cent pro Million Token gesunken.
Trotz dieser Entwicklung profitiert das Open-Source-Ökosystem wirtschaftlich bislang kaum. Mozilla zufolge kommen offene Modelle inzwischen auf etwa ein Drittel der realen KI-Nutzung, erzielen aber lediglich rund vier Prozent der Umsätze. Der Report basiert auf einer eigenen Analyse sowie einer weltweiten Umfrage unter mehr als 950 Entwicklern, die Mozilla gemeinsam mit dem Marktforschungsunternehmen SlashData durchgeführt hat.
Nach den Umfragedaten setzen 79 Prozent der befragten Entwickler offene KI-Modelle ein. In produktiven Umgebungen landen sie jedoch deutlich seltener: 51 Prozent haben Open-Source-Modelle produktiv eingeführt, während der Anteil bei proprietären Modellen 63 Prozent beträgt.
Mozilla führt diese Lücke weniger auf die Qualität der Modelle als auf fehlende Infrastruktur zurück. Die Autoren sehen Defizite vor allem bei Werkzeugen für den produktiven Betrieb, Standardisierung und Enterprise-Support. Als häufigste Hürden nennen die Befragten Infrastruktur- und Rechenkosten, Sicherheits- und Compliance-Anforderungen sowie den Aufwand für Betrieb und Skalierung [1]. Auffällig sei zudem, dass der produktive Einsatz offener Modelle mit zunehmender Unternehmensgröße kaum zunehme – anders als bei proprietären Angeboten.
Nach Auswertung verschiedener Benchmarks haben offene Modelle in Bereichen wie Programmierung, allgemeinem Wissen und dem Befolgen von Anweisungen weitgehend zu proprietären Systemen aufgeschlossen. Vorteile sehen die Autoren für geschlossene Modelle weiterhin bei komplexen Reasoning-Aufgaben, langen Kontextfenstern und agentischen Anwendungen.
Regional sieht Mozilla Ostasien und insbesondere China bei der Einführung offener KI-Modelle vorn. Dort sei Open Source inzwischen Teil der nationalen KI-Strategie. Zugleich würden immer mehr Staaten ihre KI-Infrastruktur als strategische Ressource betrachten. Nach Angaben des Berichts [2] wurden 2024 zwölf neue nationale KI-Strategien verabschiedet. Zudem hätten inzwischen 47 Staaten Einschränkungen für die Verarbeitung kritischer Daten im Ausland eingeführt.
Als wichtigste Entwicklung beschreibt Mozilla den Bedeutungsgewinn der Software rund um die eigentlichen KI-Modelle. Entscheidend sei zunehmend die sogenannte agentische Steuerungsschicht [3] (Agentic Harness). Sie legt fest, auf welche Daten ein KI-Agent zugreifen darf, welche Werkzeuge er verwendet, welche Informationen er dauerhaft speichert und welche Aktionen er selbstständig ausführen kann.
Nach Einschätzung von Mozilla [4] beeinflusst diese Schicht das Verhalten eines KI-Systems teilweise stärker als der Wechsel des zugrunde liegenden Sprachmodells. Wer diese Software kontrolliere, bestimme damit maßgeblich die Fähigkeiten und Grenzen von KI-Agenten.
Der Report warnt zugleich vor Sicherheits- und Governance-Problemen [5]. Nutzer würden Anfragen von KI-Agenten in bis zu 93 Prozent der Fälle standardmäßig bestätigen. Mozilla sieht darin Anzeichen für eine zunehmende „Consent Fatigue“: Häufige Zustimmungsabfragen führten dazu, dass Nutzer Berechtigungen kaum noch kritisch prüfen.
Mozilla fordert deshalb stärkere Investitionen in Infrastruktur, Werkzeuge und Governance für offene KI. Zu den konkreten Empfehlungen des Reports zählen unter anderem der Aufbau eines offenen Agentic Harness, die Abkehr von proprietären Metering-Systemen sowie die Schaffung portabler Berechtigungsstandards für KI-Agenten. Andernfalls bestehe die Gefahr, dass sich zwar offene Modelle technisch etablierten, skalierbare KI-Plattformen aber dauerhaft von proprietären Anbietern dominiert würden.
URL dieses Artikels:
https://www.heise.de/-11364615
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Pincasso / Shutterstock.com)
In .NET 10.0 gibt es neuerdings die Methode ExportPkcs12() als Ergänzung zur bestehenden Methode Export().
Eine Neuerung in .NET 10.0 ist die Methode ExportPkcs12() zum Zertifikatsexport mit AES-Verschlüsselung und Hashing via SHA-2-256:
byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pbes2Aes256Sha256, password);Die bisherige Methode Export() verwendet noch veraltete Algorithmen (3DES-Verschlüsselung und SHA1-Hashing). Die alten Verfahren (3DES / SHA1) aus Export() sind allerdings ebenfalls über die neue Methode möglich, wenn man es wirklich will:
byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pkcs12TripleDesSha1, password);Folgender Code zeigt ein Beispiel zum Erstellen und Exportieren eines Zertifikats:
public void Run()
{
CUI.Demo(nameof(FCL10_Certificates));
string certPath = @"c:\temp\meinZertifikat.pfx";
string password = "meinSehrGeheimesPasswort"; // Passwort zum Schutz des Zertifikats
// Selbstsigniertes Zertifikat erstellen
using (var rsa = RSA.Create(2048))
{
var request = new CertificateRequest(
"CN=TestZertifikat",
rsa,
HashAlgorithmName.SHA256,
RSASignaturePadding.Pkcs1);
// Zertifikat für 1 Jahr gültig machen
var cert = request.CreateSelfSigned(
DateTimeOffset.Now,
DateTimeOffset.Now.AddYears(1));
// ALT: Zertifikat mit 3DES-Verschlüsselung und SHA1-Hashing exportieren
// byte[] pfxData = cert.Export(X509ContentType.Pkcs12, password);
// NEU: Zertifikat als AES mit SHA-2-256 exportieren
byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pbes2Aes256Sha256, password);
// NEUE Methode, aber alte Sicherheitsverfahren: 3DES mit SHA-1
// byte[] pfxData = cert.ExportPkcs12(Pkcs12ExportPbeParameters.Pkcs12TripleDesSha1, password);
// PFX-Datei speichern
File.WriteAllBytes(certPath, pfxData);
Console.WriteLine($"Test-Zertifikat erstellt und gespeichert unter: {certPath}");
}
if (!File.Exists(certPath))
{
Console.WriteLine($"Datei nicht gefunden: {certPath}");
}
else
{
// Zertifikat laden
X509Certificate2 cert2 = X509CertificateLoader.LoadPkcs12FromFile(certPath, password);
Console.WriteLine($"Zertifikat geladen von {certPath}:");
Console.WriteLine($"IssuerName: {cert2.IssuerName.Name}");
Console.WriteLine($"Signaturalgorithmus (Hashing): {cert2.SignatureAlgorithm.FriendlyName}");
Console.WriteLine($"Öffentlicher Schlüsselalgorithmus: {cert2.PublicKey.Oid.FriendlyName}");
Console.WriteLine($"Key-Algorithmus OID: {cert2.GetKeyAlgorithm()}");
// Ob für ein Zertifikat-Export (z. B. .pfx/PKCS#12) AES verwendet wurde, steht nicht im Zertifikat selbst, sondern betrifft die Verschlüsselung der Containerdatei. Das Zertifikat enthält nur Infos zu Signatur- und Schlüsselalgorithmus (z. B. RSA, SHA256).
}
}
URL dieses Artikels:
https://www.heise.de/-11363926
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Wolf Hosbach / KI / iX)
Next.js will Sicherheitsmeldungen künftig strukturiert und planbar monatlich veröffentlichen. Kritische Warnungen kommen nach wie vor ad hoc.
Das JavaScript-Framework Next.js hat angekündigt, Sicherheitswarnungen künftig regelmäßig etwa einmal im Monat herauszugeben. Wichtige Updates kommen aber nach wie vor sofort. Das soll die Update-Planung für die Next-Anwenderinnen und -Anwender vereinfachen.
Die neuen monatlichen Sicherheitsnachrichten im Blog [1] liefern einen Zeitplan, für welche Next-Versionen wann Updates zu erwarten sind. Die angekündigten Fixes sind außerdem nach Relevanz sortiert. Vor kritischen und schon verwendeten Lücken warnt Next nach wie vor ad hoc im Blog. Diese Lücken sollten Anwender sofort beseitigen.
Die erste Meldung soll am 20. Juli erscheinen und über kommende Updates für Next 15.5 und 16.2 mit hoher und mittlerer Relevanz informieren.
Next.js reagiert mit der Umstrukturierung wie viele andere Open-Source-Projekte auch [2] auf die durch LLM-Reviews gesteigerte Menge an Sicherheits-Pull-Requests. Im Gegensatz zu anderen Teams hält der Next-Herausgeber Vercel aber am Bug-Bounty-Programm auf Hackerone [3] fest.
URL dieses Artikels:
https://www.heise.de/-11363871
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Social-Media-Feeds, Lootboxen, Grooming, Chatbots: Wie du im Netz die Kontrolle behältst – und wo du dir Hilfe holst, sollte es Probleme geben.
Deine Social-Media [1] [1]-Feeds bei TikTok, Instagram und YouTube sind keine Spiegel deiner Interessen. Sie sind das Ergebnis eines Systems, das darauf angelegt ist, dich so lange wie möglich am Bildschirm zu halten. Das macht sie nicht zum Feind. Aber es macht sie zu etwas, das du im Blick haben und so weit wie möglich steuern solltest.
Dieser Text erklärt die Mechanismen hinter Algorithmen, Lootboxen, Deepfakes, Body-Image-Content und KI-Chatbots. Er zeigt, mit welchen Mitteln du deine Social-Media-Feeds umbaust, sodass sie besser deinen Interessen entsprechen. Und er nennt konkrete Anlaufstellen für den Fall, dass aus einem unguten Gefühl ein echtes Problem wird.
Den TikTok-Algorithmus interessiert nicht, ob dir ein Video guttut. Wie genau dieser Empfehlungsalgorithmus funktioniert [6] [6] – von Verweildauer-Messung bis Dopamin-Kicks –, erklärt dir eine ausführliche Analyse. Ihn interessiert, wie lange du es anschaust, ob du es teilst oder speicherst. So kann es dir passieren, dass du innerhalb kurzer Zeit ganz viele SkinnyTok-, Looksmaxxing- oder Fitspiration-Videos in deinem Feed vorfindest, nur weil du ein paar solcher Videos nicht schnell genug weggewischt hast. Wer mit solchen Videos dauerbespielt wird, bei dem gerät das Selbstwertgefühl leicht ins Wanken.
URL dieses Artikels:
https://www.heise.de/-11332519
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: Richard Seidl)
KI-Personas können das Verhalten von Entwicklerinnen und Entwicklern simulieren, um eine Dokumentation zu prüfen, wie Ingo Eichhorst im Gespräch ausführt.
Dokumentation mit KI zu prüfen, indem man menschliche Verhaltensweisen simuliert: Das ist der Ansatz, den Ingo Eichhorst mitgebracht hat. Mit ihm spricht Richard Seidl darüber, wie sich Personas wie ein Junior-Entwickler oder ein Senior-Entwickler als KI-Agenten in eine CI/CD-Pipeline einbauen lassen, um Dokumentation nicht nur zu bewerten, sondern aktiv damit zu arbeiten. Der Junior-Entwickler verbraucht dabei fast sechsmal so viele Token wie der Senior, weil er an einer missverständlichen URL-Struktur scheitert und sich im Trial-and-Error verliert. Das zeigt direkt, wo man Dokumentation nachbessern muss. Die beiden reden auch darüber, warum das Domänenwissen hinter Code so schwer zu rekonstruieren ist, sobald es einmal verloren ist, und was passiert, wenn eine KI plötzlich zwischen Entwicklern und Management als Übersetzungsschicht wirkt.
„Wir müssen uns von dem Gedanken verabschieden, dass wir immer so einen 100-Prozent-Output bekommen.“ – Ingo Eichhorst
Ingo Eichhorst [2] ist AI Architect, CTO und Tech Trainer mit über zwei Jahrzehnten Erfahrung in Softwareentwicklung und Systemarchitektur. Seit den 1990er-Jahren gestaltet er digitale Systeme und verbindet dabei technologische Exzellenz mit unternehmerischem Denken. Bei Ionos arbeitet er als Engineering Trainer, parallel lehrt er als Visiting Lecturer für Künstliche Intelligenz [3] an der University of Applied Sciences Nordhausen. Nebenberuflich [4] begleitet er mit seinem Unternehmen better be great Start-ups, Scale-ups und NGOs bei der Umsetzung innovativer Technologien in marktfähige Produkte.
Dieses Format fokussiert sich auf Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste betrachten die Dinge, welche die Qualität in der Softwareentwicklung steigern.
Die aktuelle Episode ist auch auf Richard Seidls Blog verfügbar [5].
URL dieses Artikels:
https://www.heise.de/-11362242
Links in diesem Artikel:
Copyright © 2026 Heise Medien
Banken sollen Betrugsopfer künftig öfter und schneller entschädigen und mehr für die Prävention tun. Der Kompromiss lässt den Instituten jedoch viel Spielraum.
Angriffe auf das Onlinebanking von Verbrauchern zielen heute fast immer auf den Menschen statt auf die Technik. Gut gemachte Phishing-SMS oder -Mails suggerieren Sicherheitsprobleme. Betrüger geben sich am Telefon als Bankberater aus und wollen angeblich gegen – ja, Betrug helfen. Die Maschen funktionieren zu oft, erbeutetes Geld ist schnell außer Landes, Strafverfolger haben es schwer. Wenn Betroffene bei ihren Banken Ansprüche geltend machen, unterstellen die Kreditinstitute ihnen jedoch pauschal Sorgfaltspflichtverletzungen und grobe Fahrlässigkeit. Wer sich keinen Anwalt leisten kann, scheitert selbst mit berechtigten Forderungen.
Diesen Problemen will die EU in der neuen Zahlungsdiensteverordnung (Payment Services Regulation, PSR) begegnen. Sie soll es Bankkunden erleichtern, ihre Ansprüche geltend zu machen. Banken sollen bei Identitätsbetrug durch falsche Bankberater oder gefälschte Webseiten Schäden außerdem verschuldensunabhängig erstatten. Die PSR soll den Verbraucherschutz stärken, aber auch dafür sorgen, dass Banken die Betrugsprävention verbessern.
Fraglich ist, ob der Kompromiss zwischen EU-Kommission, -Rat und -Parlament, den diverse Lobbyorganisationen begleitet haben [8] [8], den Verbrauchern wirklich hilft. Wir haben uns den finalen Text der PSR [9] [9] sowie Positionspapiere von Verbraucherschützern und Banken angesehen und mit Experten gesprochen. Zur Einordnung erklären wir, warum die heutigen Haftungsregeln betrogene Bankkunden benachteiligen und warum das in der Praxis der PSR trotz ihrer Ziele so bleiben könnte – aber auch, weshalb sie Kriminellen die Arbeit möglicherweise doch schwerer machen könnte.
URL dieses Artikels:
https://www.heise.de/-11295747
Links in diesem Artikel:
Copyright © 2026 Heise Medien
(Bild: www.makerspet.com)
Ein 3D-gedruckter Saugroboter mit LiDAR, Raspberry Pi und Home Assistant – komplett offline und quelloffen. Das Projekt Oomwoo will zeigen, dass das geht.
Bisherige DIY-Saugroboter navigieren primitiv: Sie fahren blind durch den Raum und prallen dabei wie Betrunkene von Wand zu Wand. Das Open-Source-Projekt Oomwoo will das ändern, indem die gleichen Navigations-Frameworks zum Einsatz kommen, die auch teure kommerzielle Saugroboter verwenden: Mit 2D-LiDAR und dem Nav2-Stack des Open-Source-Frameworks ROS 2 (Robot Operating System) soll der Roboter geplante Pfade abfahren.
Statt alle Komponenten selbst zu entwickeln, setzt das Projekt auf den florierenden Ersatzteilmarkt für chinesische Saugroboter: Motoren, Sensoren und Saugmodule werden etwa über AliExpress bezogen, lediglich Gehäuse, Bumper, Halterungen und Ladestation kommen aus dem eigenen 3D-Drucker.
Sämtliche Projektbestandteile – von den CAD-Dateien über die Firmware bis zur Steuerungssoftware – sind unter der Apache-2.0-Lizenz frei verfügbar. Cloud-Anbindung soll es nicht geben. Der Roboter soll komplett lokal arbeiten und über Home Assistant gesteuert werden.
Hinter Oomwoo steht Entwickler Ilia O., der unter anderem einfache Roboterbausätze für Unterricht und DIY verkauft. Bislang gibt es ein Chassis-Design und einige Simulationen der Steuerungssoftware, dazu viel Zuspruch in den Kommentaren auf der Projektseite [1]. Fertige Nachbauanleitungen fehlen noch, und auch grundlegende Entscheidungen stehen noch aus – etwa welcher Rechner die Navigation übernehmen soll. Sowohl ein Raspberry Pi 5 als auch ein ESP32 mit micro-ROS als auch eine Kombination werden erwogen.
Eine Teileliste [3] ist für Mitte Juli angekündigt. Das Materialbudget soll bei 100 bis 200 US-Dollar plus Raspberry Pi liegen – für einen Roboter, der laut Entwickler mit kommerziellen Geräten der 500- bis 600-Dollar-Klasse mithalten soll.
Der modulare Aufbau soll es Mitwirkenden ermöglichen, unabhängig voneinander an einzelnen Baugruppen zu arbeiten. Ein Bausatz ist angedacht, zwingend nötig soll er aber nicht sein.
Ilia O. nennt die wiederkehrenden [4] Sicherheitsprobleme [5] kommerzieller Saugroboter als Motivation und verweist auf den amerikanischen Sicherheitsforscher Dennis Giese, der seit Jahren die Hardware proprietärer Saugroboter in seinem Projekt robotinfo.dev [6] dokumentiert und dabei regelmäßig Schwachstellen aufdeckt. Bereits auf dem 37C3 Ende 2023 zeigte er unter dem Titel "Sucking Dust and Cutting Grass" [7], wie sich Saugroboter und Mähroboter übernehmen lassen. Oomwoo umgeht das Problem, indem es weder Kamera noch Internetverbindung mitbringt.
An Maker-Saugrobotern herrscht kein Mangel: Der 3D-gedruckte Robot Vacuum Cleaner MARK II auf Arduino-Nano-Basis oder diverse Raspberry-Pi-Zero-Bauten auf GitHub zeigen, dass die Szene das Thema seit Jahren bearbeitet. Das schwedische Projekt Wolley verfolgte einen ähnlich ambitionierten Ansatz, scheint aber seit 2024 eingeschlafen zu sein.
(Bild: www.wolley.se)
Oomwoo ist damit nach aktuellem Stand das erste Projekt, das einen komplett selbst gebauten Saugroboter mit professioneller SLAM-Navigation verbindet. SLAM (Simultaneous Localization and Mapping) bedeutet, dass der Roboter während der Fahrt gleichzeitig eine Karte seiner Umgebung erstellt und seine eigene Position darin bestimmt. Genau so navigieren auch die meisten kommerziellen Saugroboter.
URL dieses Artikels:
https://www.heise.de/-11363023
Links in diesem Artikel:
Copyright © 2026 Heise Medien
