Das iPhone ist seit mehreren Generationen bereit für die elektronische SIM-Karte, die sich einfach online kaufen lässt. So sparen Sie damit unterwegs.
Ich habe gehört, dass es Möglichkeiten gibt, bei der Internetversorgung im Ausland zu sparen. Lohnt sich im Urlaub eine eSIM für das Reiseland und wie richte ich sie ein?
In Ländern, in denen „Roam like at Home [1]“ bei Ihrem Provider nicht greift, kann eine eSIM eines regionalen oder globalen Anbieters die Mobilfunkkosten tatsächlich erheblich senken.
Modelle ab iPhone XS, XR und SE 2 sind dafür bestens gerüstet, denn sie besitzen mindestens eine eSIM, ab dem iPhone 13 [2] sogar zwei. Parallel aktiv sind allerdings immer nur zwei SIMs – entweder eine physische und eine eSIM oder zwei eSIMs [3].
Vor der Buchung lohnt sich ein Vergleich: Erkundigen Sie sich zunächst beim heimischen Anbieter nach speziellen Reisepaketen. Bei deutschen Providern wie der Telekom oder Aldi Talk gibt es oft günstige Tarife für die Dauer einer Reise, einige behandeln zudem das Vereinigte Königreich wie ein EU-Land.
Findet sich nichts Passendes, suchen Sie nach Anbietern im Zielland – eine KI wie ChatGPT oder Copilot liefert meist brauchbare Vorschläge, wenn Sie Reiseziel und gewünschte Leistungen genau benennen. Einen ersten Eindruck zur Netzabdeckung erhalten Sie auf der Website nperf.com [4].
Beim Aktivieren einer eSIM können Sie direkt entscheiden, ob Sie die eSIM zu Hause oder nur im Ausland verwenden möchten.
Die Einrichtung selbst ist inzwischen denkbar unkompliziert: Bei vielen Anbietern lässt sich das eSIM-Profil direkt aus der jeweiligen App heraus aktivieren. Das iPhone führt Sie dann durch einen kurzen Einrichtungsdialog, in dem Sie unter anderem festlegen können, ob die neue eSIM für Reisen oder den Alltag genutzt werden soll.
Eine eSIM richten Sie am einfachsten über einen QR-Code ein. Klappt das nicht, benötigen Sie vom Anbieter weitere Daten.
Wichtig: Richten Sie die eSIM möglichst bereits zu Hause im stabilen WLAN ein. Beginnt der Nutzungszeitraum mit der Aktivierung, verzögern Sie diese bis zum Reisebeginn. Vergeben Sie zudem einen aussagekräftigen Namen wie den Tarifnamen, um die eSIM eindeutig von Ihrem Heimattarif zu unterscheiden. Sobald die Reise-eSIM aktiv ist, deaktivieren Sie in den Einstellungen unter „Mobilfunk > [Ihre Haupt-SIM]“ die Option „Datenroaming“, um zu verhindern, dass diese im Hintergrund teure Verbindungen aufbaut. iMessage und FaceTime funktionieren übrigens weiterhin mit Ihrer Hauptrufnummer, auch wenn die Daten über die Reise-eSIM laufen.
Sollte die Aktivierung scheitern, löschen Sie die eSIM nicht einfach, denn die meisten Anbieter erlauben nur eine einmalige Freischaltung. Kontaktieren Sie stattdessen den Support – und nehmen Sie die Servicekontaktdaten sicherheitshalber mit in den Urlaub.
URL dieses Artikels: https://www.heise.de/-11377550
BBEdit 16: Echte Traditions-App mit neuer Version.
(Bild: Bare Bones Software)
Neues von Bare Bones Software: Der Code- und Texteditor BBEdit findet in Version 16 Text jetzt auch in Bildern und liefert auch sonst einige Neuerungen.
Das Mac-Urgestein BBEdit gehört zu den Apps, die erst auf den zweiten Blick beeindrucken. Hinter dem recht schnörkellosen Erscheinungsbild des Editors verstecken sich etliche Funktionen, die es in sich haben. Version 14 brachte etwa eine Notizenverwaltung mit sowie Unterstützung für das Language-Server-Protokoll (LSP), das Entwicklern erweiterte Hilfestellungen in Quellcode anbietet.
Version 15 führte Spickzettel (Cheatsheets) zum schnellen Nachschlagen ein sowie AI-Chat-Worksheets für die Kommunikation mit ChatGPT und eine Minimap, die eine grobe Übersicht des Gesamtdokuments gewährt.
Text in Bildern suchen
Die aktuelle Version 16 der nur auf Englisch verfügbaren App ergänzt die mächtige Multi-File-Suche um die Fähigkeit, Bilder zu finden, die den gesuchten Text enthalten. Diese Fähigkeit ist hinter dem Options-Button versteckt und basiert auf Apples VisionKit-Framework. Das kann zwar auch Apples Fotos-App, doch BBEdit durchsucht beliebige Ordner und findet damit auch andere Dateitypen.
URL dieses Artikels: https://www.heise.de/-11378102
Nur wenn alle Gruppenteilnehmer den Chatverlauf detailliert vergleichen, haben sie eine Chance die, Manipulation zu erkennen.
(Bild: DavideAngelini/Shutterstock.com)
Alle Mitglieder eines Gruppenchats sollten dieselben Inhalte sehen. Die üblichen Chat-Dienste stellen das nicht sicher. Das ist riskant.
Gruppenchats der großen Messaging-Dienste Whatsapp, iMessage, Signal und Threema sind zwar gut Ende-zu-Ende-verschlüsselt, sodass Unbefugte nicht mitlesen können. Gegen Manipulation der angezeigten Inhalte in Gruppenchats sind sie aber nicht geschützt, wenn der Täter ein legitimes Gruppenmitglied ist oder das Gerät eines Mitglieds kontrolliert. Solchen Angreifern ist es möglich, Chatnachrichten zu senden, die die selbe Identifikationsnummer tragen, aber bei unterschiedlichen Empfängern unterschiedlichen Inhalt haben. Damit fällt die sogenannte transcript consistency: Die Chatteilnehmer haben plötzlich unterschiedliche Versionen des Chats und wissen das nicht.
Die falschen Mitteilungen können sogar in Zitaten anderer Chatteilnehmer erhalten bleiben, so dass ein Chatteilnehmer eine völlig falsche Vorstellung vom Chatverlauf haben kann. Beispiel: Die Chatrunde stimmt einem Vorschlag einhellig zu, doch ein Chatteilnehmer sieht Zustimmung zu einem völlig anderen Vorschlag. Oder: Ein böswilliges Gruppenmitglied schickt einen Hyperlink in die Runde, der zu einem lustigen Katzenbild führt. Nur einem Gruppenmitglied schickt der Täter einen Link, der Malwaredownload auslöst. Die Gruppe antwortet auf den lustigen Link mit Heiterkeit und Danksagung, was die Zielperson zum Klick auf den Link verleitet.
Oder: Die Einladung zu einem wichtigen Treffen ergeht für einen Teil der Teilnehmer für Montag, für andere, die der Angreifer lieber nicht dabeihaben möchte, für einen anderen Tag, nachdem bereits alle Beschlüsse gefasst sind. Oder: Den Moderatoren eines Chats werden stets lautere Inhalte gezeigt, während bestimmte Mitglieder mit unlauteren bedacht werden. Und so weiter und so fort.
Nutzt ein Teilnehmer unter dem selben Nutzerkonto mehrere Endgeräte für den Gruppenchat, können ihm unterschiedliche Inhalte auf unterschiedlichen Endgeräten zugemittelt werden (außer bei Threema, das dabei das Manko fehlender Forward Secrecy [1] aufweist). Auch die Unterdrückung einer Nachricht je nach Endgerät ist bei den drei anderen Diensten möglich. Das alles funktioniert, ohne Bruch von Verschlüsselung, nicht nur für Textmitteilungen, sondern auch für Multimedia-Inhalte. Zudem lassen sich Abstimmungen auf verschiedene Art und Weise manipulieren.
So geht Gruppenchat
Das hat eine österreichische Gruppe aus IT-Sicherheitsforschern um Gabriel Gegenhuber herausgefunden und Anfang Februar den vier Kommunikationsdiensten gemeldet. Obwohl Gruppenchats inzwischen auch für (kriegs)wichtige politische Entscheidungen auf oberster Ebene genutzt werden, plant keiner der vier Betreiber unmittelbare Maßnahmen um das Grundproblem auszumerzen.
Ende-zu-Ende-verschlüsselte Gruppenchats können auf unterschiedliche Weise realisiert werden. Threema, iMessage und früher auch Signal setzen auf paarweise Kommunikation: Sendet ein Teilnehmer eine Nachricht an die Gruppe, schickt sein Client im Hintergrund tatsächlich jeweils eine Kopie der Nachricht an jeden anderen Teilnehmer. Je größer die Gruppe, desto effizienter ist das derzeit von Signal und Whatsapp eingesetzt Verfahren, bei dem nur eine Nachricht vom Client an den Server geht, der sie dann an die anderen Chatteilnehmer weiterleitet („server fan-out‟). Nur für die ursprüngliche Übermittlung der notwendigen Verschlüsselungsschlüssel kommuniziert der Absender direkt mit den anderen Kommunikationspartnern.
Die Forscher haben für die böswilligen Mitteilungen offizielle (Signal und Threema) respektive inoffizielle (Whatsapp, iMessage) Clients genutzt und durch Softwarepatches angepasst. Auf Empfängerseite kam die übliche Software der Messagingdienste für Android, iOS, Linux, macOS, Windows, sowie Webbrowser zum Einsatz.
Paarweise Kommunikation
Bei paarweiser Kommunikation in Gruppenchats, wie Threema und iMessage sie einsetzen, ist der Trick naheliegend: Der Absender schickt, unter Verwendung des selben Nachrichten-ID, einfach unterschiedliche Inhalte an unterschiedliche Empfänger. Signal unterstützt, wohl aus Gründen der Rückwärtskompatibilität, sowohl paarweise Kommunikation als auch server fan-out.
Zudem können Whatsapp und Signal trotz standardmäßigem server fan-out dazu gebracht werden, automatisch auf paarweise Kommunikation zurückzufallen. Das tritt ein, wenn ein Empfänger eine Nachricht nicht entschlüsseln kann. Er fordert dann eine neuerliche Übertragung in paarweiser Kommunikation, schließlich müssen ja nicht alle Gruppenteilnehmer die Nachricht noch einmal erhalten, nur weil einer an ihrer Entschlüsselung scheitert.
Und dieses Scheitern kann absichtlich ausgelöst werden: Wie erwähnt, nutzen Whatsapp und Signal paarweise Kommunikation zur ursprünglichen Übermittlung der Entschlüsselungsschlüssel. Dort setzt der Angreifer an: Er sendet dem Zielclient absichtlich einen Schlüssel, mit dem dieser die „normalen‟ Chatnachrichten des Absenders gar nicht entschlüsseln kann. Dann löst jede normale Nachricht einen Fehler mit der Bitte um neuerliche, direkte Zusendung aus. Daraufhin schickt der böswillige Absender die gefälschte Nachricht mit der ID-Nummer der echten Nachricht.
Server fan-out
Doch auch im server-fan-out-Verfahren, bei dem der Client eine Nachricht an den Server schickt, der sie dann an die Gruppenmitglieder verteilt, ist Manipulation möglich. Die erwähnte Kann-ich-nicht-entschlüsseln-Fehlermeldung des Empfängers bittet zwar um neuerliche Zumittlung mit der paarweisen Methode. Doch diesen Teil der Bitte kann der Angreifer ignorieren und die verfälschte Nachricht als server fan-out absenden.
Dann geht die verfälschte Nachricht zwar an alle Gruppenmitglieder, deren Clients sehen aber die ID einer bereits erhaltenen Nachricht. Daher verwerfen sie die „Kopie‟ ohne Fehlermeldung und prüfen nicht, ob sie die neue Nachricht überhaupt entschlüsseln können. Nur die Zielperson erhält die falsche Nachricht, weil sie das Original nicht entschlüsseln konnte.
Aufgrund des besonders hohen Datenschutzes bei Signal gibt es dort noch einen zweiten Angriffsvektor: Während Whatsapp auf dem Server eine Liste aller Mitglieder einer Gruppe führt, tut Signal das nicht. Der Absender muss jeder Nachricht eine Liste aller Gruppenteilnehmer beilegen und kann dabei bestimmte Teilnehmer unter der Tisch fallen lassen. Sie erhalten diese Nachricht dann nicht, merken aber nichts von der Lücke.
Schwindel bei Zitaten
Ist eine falsche Nachricht einmal zugestellt, bleibt sie auch in Zitaten erhalten, beispielsweise wenn andere Gruppenmitglieder darauf reagieren und ihre Meinung zu dem zitierten Inhalt kundtun. Denn die Zitatfunktion überträgt aus Gründen der Datensparsamkeit standardmäßig nicht den eigentlichen Inhalt, sondern verweist nur auf die ID der zitierten Nachricht. Damit sieht der Empfänger eines Zitats dabei also stets jene Nachricht, die ihm ursprünglich zugemittelt wurde, sei es das Original oder die falsche Nachricht.
Gibt es die referenzierte Nachricht nicht, verweigern Threema und iMessage das Zitat. Signal und Whatsapp fallen jedoch darauf zurück, den Inhalt des Zitats zu übermitteln. Das ist durchaus nützlich, den ein neu zur Gruppe Hinzugestoßener soll ja mitreden können. Allerdings eröffnet das dem Angreifer die Möglichkeit, den angeblich zitierten Inhalt beliebig zu definieren. Das geht auch in 1-zu-1 Chats, ohne Gruppe. Hier ist zu hoffen, dass der Empfänger noch weiß, was er (nicht) von sich gegeben hat.
Signal blendet unter den angeblich zitierten Inhalt immerhin einen Hinweis ein, dass es die zitierte Nachricht nicht finden kann. Bei Whatsapp fehlen solche Hinweise. Und speziell der Desktop-Client Signals erlaubt Zitate von Nachrichten, die erst nach dem Zitat verschickt werden.
Schwindel mit Abstimmungen
Besonderen Spaß dürften die Forscher mit der Abstimmungs-Funktionen der vier Dienste gehabt haben. Keiner sichert die gestellte Frage kryptographisch ab. Bei iMessage, Signal und Threema kann ein Angreifer, der eine Abstimmung erstellt, unterschiedlichen Gruppenmitgliedern unterschiedliche Fragen stellen. Bei binären Fragen (ja/nein) unter Whatsapp, das Abstimmungen mittels Hash absichert, kann er die Antwortmöglichkeiten mit einander austauschen. Was der eine als Ja-Stimme erachtet, ist für den andern womöglich eine Nein-Stimme.
Zudem kann er bei Whatsapp bestimme Mitglieder von der Stimmenzählung ausschließen, in dem er etwa durch absichtliches Einfügen eines unsichtbaren Leerzeichens den Hashwert verändert. Stimmt der Hashwert dann nicht überein, verwirft Whatsapp die abgegebene Stimme einfach.
Bei Threema und Signal ist auch das Abstimmungsergebnis nicht sicher. Threema sieht vor, dass der Ersteller der Abstimmung den Stimmenstand allen Gruppenmitgliedern mitteilt. Da er einzelnen Mitgliedern verfälschte Nachrichten senden kann, kann er die angezeigten Stimmen einzelner Teilnehmer verändern, streichen oder hinzufügen.
Bei Signal verkündet zwar der Server das Abstimmungsergebnis. Doch kann der Angreifer im Voraus solche Mitteilungen erfinden und versenden. Das spätere, echte Abstimmungsergebnis wird von jenen Signal-Clients, die bereits ein gefälschtes Endergebnis erhalten haben, als vermeintliches Duplikat verworfen.
Schwindel durch Abstimmende
Dem nicht genug können auch die Abstimmenden Unfug treiben, indem sie unterschiedlichen Gruppenmitgliedern unterschiedliche Entscheidungen zusenden. Damit laufen die beim jeweilige Empfänger angezeigten Abstimmungsergebnisse auseinander. Bei Threema ist sogar möglich, mit manipulierten Nachrichten mehr als eine Stimme auf einmal in die Waagschale zu werfen, sowie versteckte Stimmen nachzureichen. Bei iMessage kann ein Täter im Namen anderer Gruppenmitglieder abstimmen.
Bei Whatsapp haben die Forscher entdeckt, dass iOS-Clients Abstimmungen anders verarbeiten als Android-Clients. Das können Angreifer ausnutzen, beispielsweise indem sie nur Gruppenmitglieder mit Android-Client abstimmen lassen. Gleichzeitig verrät Whatsapp, welcher Client genutzt wird. Das erlaubt unter Umständen Rückschlüsse auf den Aufenthaltsort des Teilnehmers, beispielsweise wenn er Whatsapp nur im Büro mit Windows nutzt, oder mit Linux nur Zuhause, oder umgekehrt.
Abhilfe
Auseinanderlaufen von Inhalten von Gruppenchats ist für den einzelnen Teilnehmer schwer zu erkennen. Hinzu kommt, dass sensible Chats oft auf automatische Löschung der Inhalte nach kurzer Zeit setzen. Dadurch werden die Manipulationsbeweise automatisch vernichtet.
Das Grundproblem manipulierter Inhalte ist systembedingt, speziell paarweise Kommunikation eröffnet Lücken. Mit Verzicht darauf wäre viel erreicht, das würde aber aufwändiges Redesign erfordern.
Für Signal und Whatsapp, die primär auf server fan-out setzen und nur subsidiär auf paarweise Kommunikation zurückgreifen, haben die Forscher Vorschläge, wie die Probleme reduziert werden könnten: Verbot paarweiser Kommunikation, außer für die ursprünglichen Schlüssel, weil es dort im gegebenen Konzept notwendig ist. Clients sollten unerbetene, neuerliche Zusendungen von Nachrichten generell verwerfen. Bittet ein Client um neuerliche Zumittlung einer Nachricht, sollte das allen Gruppenmitgliedern mitgeteilt werden, um Aufmerksamkeit zu schaffen. Zeitstempel sollten nur vom Server akzeptiert werden, und jede Veränderung der Gruppenzusammensetzung sollte auf technischer Ebene zur automatisch Erstellung einer neuen Gruppe führen.
Vor allem aber sollten Vorgänge transparent gemacht werden: Fehlgeschlagene Entschlüsselung sollte ebenso angezeigt werden, wie neuerliche Zusendung einer früheren Nachricht – samt Warnung, dass der Inhalt einer solchen Nachricht von dem anderen Teilnehmern angezeigten Inhalt abweichen kann. Zudem sollte für jeden Gruppenteilnehmer automatisch eine Statistik geführt werden, die offenlegt, wo sich Entschlüsselungsfehler und neuerliche Versendungen häufen. Denn das ist verdächtig.
Die Autoren
Ein anderer Weg wäre, die Ende-zu-Ende-Verschlüsselung auszuschalten, so dass jeder bei jedem alles mitlesen kann. Davon hält Studienautor Gegenhuber (früher an der Universität Wien, jetzt an der Interdisciplinary Transformation University in Linz tätig) nichts: „Ohne Ende-zu-Ende-Verschlüsselung ist man vollständig vom Server abhängig, und der könnte dann beliebig Nachrichten manipulieren oder unterdrücken. Außerdem könnte der Serverbetreiber alles mitlesen.‟
„Ende-zu-Ende-Verschlüsselung ist eine große und wichtige Errungenschaft‟, betonte Gegenhuber gegenüber heise online. „Dabei wird jedoch Vertrauen und die Verantwortung für Validierung vom Server zum Client verschoben. Und der kann bösartig sein. Daher ist transcript consistency wichtig.‟
Mit Gegenhuber haben Moritz Grefner, Matthäus Wininger, David Schmidt und Aljosha Judmayer (allesamt Universität Wien) sowie Maximilian Günther (SBA Research) die Sache erforscht. Sie haben ihr gemeinsames Paper unter dem Titel Send and Pretend: Exploiting Transcript Consistency Issues in End-to-End Encrypted Group Chats in der Nacht auf Donnerstag bei Github [3] und Zenodo online [4] gestellt. Dort stehen auch Programmcode und Beweisvideos zum Download bereit.
Das Team hat alle vier Dienstebetreiber am 6. Februar informiert. Apple hat laut Forscherteam den Empfang bestätigt. Meta Platforms hat 1.000 US-Dollar Belohnung ausgeschüttet und Verbesserungen bei Abstimmungen in Whatsapp angekündigt. Threema möchte das Teilproblem der Möglichkeit zur Abgabe mehrerer Stimmen angehen.
Keiner der Drei hat demnach angekündigt, das Grundproblem fehlender transcript consistency in Gruppenchats anzugehen. Auch das von einer nichtkommerziellen Stiftung betriebene Signal plant keine Sofortmaßnahmen, möchte sich aber dann dem Problem widmen, wenn es gröbere Arbeiten an der Gruppenchat-Funktion in Angriff nimmt.
URL dieses Artikels: https://www.heise.de/-11384095
Nur wenn alle Gruppenteilnehmer den Chatverlauf detailliert vergleichen, haben sie eine Chance die, Manipulation zu erkennen.
(Bild: DavideAngelini/Shutterstock.com)
Alle Mitglieder eines Gruppenchats sollten dieselben Inhalte sehen. Die üblichen Chat-Dienste stellen das nicht sicher. Das ist riskant.
Gruppenchats der großen Messaging-Dienste Whatsapp, iMessage, Signal und Threema sind zwar gut Ende-zu-Ende-verschlüsselt, sodass Unbefugte nicht mitlesen können. Gegen Manipulation der angezeigten Inhalte in Gruppenchats sind sie aber nicht geschützt, wenn der Täter ein legitimes Gruppenmitglied ist oder das Gerät eines Mitglieds kontrolliert. Solchen Angreifern ist es möglich, Chatnachrichten zu senden, die die selbe Identifikationsnummer tragen, aber bei unterschiedlichen Empfängern unterschiedlichen Inhalt haben. Damit fällt die sogenannte transcript consistency: Die Chatteilnehmer haben plötzlich unterschiedliche Versionen des Chats und wissen das nicht.
Die falschen Mitteilungen können sogar in Zitaten anderer Chatteilnehmer erhalten bleiben, so dass ein Chatteilnehmer eine völlig falsche Vorstellung vom Chatverlauf haben kann. Beispiel: Die Chatrunde stimmt einem Vorschlag einhellig zu, doch ein Chatteilnehmer sieht Zustimmung zu einem völlig anderen Vorschlag. Oder: Ein böswilliges Gruppenmitglied schickt einen Hyperlink in die Runde, der zu einem lustigen Katzenbild führt. Nur einem Gruppenmitglied schickt der Täter einen Link, der Malwaredownload auslöst. Die Gruppe antwortet auf den lustigen Link mit Heiterkeit und Danksagung, was die Zielperson zum Klick auf den Link verleitet.
Oder: Die Einladung zu einem wichtigen Treffen ergeht für einen Teil der Teilnehmer für Montag, für andere, die der Angreifer lieber nicht dabeihaben möchte, für einen anderen Tag, nachdem bereits alle Beschlüsse gefasst sind. Oder: Den Moderatoren eines Chats werden stets lautere Inhalte gezeigt, während bestimmte Mitglieder mit unlauteren bedacht werden. Und so weiter und so fort.
Nutzt ein Teilnehmer unter dem selben Nutzerkonto mehrere Endgeräte für den Gruppenchat, können ihm unterschiedliche Inhalte auf unterschiedlichen Endgeräten zugemittelt werden (außer bei Threema, das dabei das Manko fehlender Forward Secrecy [1] aufweist). Auch die Unterdrückung einer Nachricht je nach Endgerät ist bei den drei anderen Diensten möglich. Das alles funktioniert, ohne Bruch von Verschlüsselung, nicht nur für Textmitteilungen, sondern auch für Multimedia-Inhalte. Zudem lassen sich Abstimmungen auf verschiedene Art und Weise manipulieren.
So geht Gruppenchat
Das hat eine österreichische Gruppe aus IT-Sicherheitsforschern um Gabriel Gegenhuber herausgefunden und Anfang Februar den vier Kommunikationsdiensten gemeldet. Obwohl Gruppenchats inzwischen auch für (kriegs)wichtige politische Entscheidungen auf oberster Ebene genutzt werden, plant keiner der vier Betreiber unmittelbare Maßnahmen um das Grundproblem auszumerzen.
Ende-zu-Ende-verschlüsselte Gruppenchats können auf unterschiedliche Weise realisiert werden. Threema, iMessage und früher auch Signal setzen auf paarweise Kommunikation: Sendet ein Teilnehmer eine Nachricht an die Gruppe, schickt sein Client im Hintergrund tatsächlich jeweils eine Kopie der Nachricht an jeden anderen Teilnehmer. Je größer die Gruppe, desto effizienter ist das derzeit von Signal und Whatsapp eingesetzt Verfahren, bei dem nur eine Nachricht vom Client an den Server geht, der sie dann an die anderen Chatteilnehmer weiterleitet („server fan-out‟). Nur für die ursprüngliche Übermittlung der notwendigen Verschlüsselungsschlüssel kommuniziert der Absender direkt mit den anderen Kommunikationspartnern.
Die Forscher haben für die böswilligen Mitteilungen offizielle (Signal und Threema) respektive inoffizielle (Whatsapp, iMessage) Clients genutzt und durch Softwarepatches angepasst. Auf Empfängerseite kam die übliche Software der Messagingdienste für Android, iOS, Linux, macOS, Windows, sowie Webbrowser zum Einsatz.
Paarweise Kommunikation
Bei paarweiser Kommunikation in Gruppenchats, wie Threema und iMessage sie einsetzen, ist der Trick naheliegend: Der Absender schickt, unter Verwendung des selben Nachrichten-ID, einfach unterschiedliche Inhalte an unterschiedliche Empfänger. Signal unterstützt, wohl aus Gründen der Rückwärtskompatibilität, sowohl paarweise Kommunikation als auch server fan-out.
Zudem können Whatsapp und Signal trotz standardmäßigem server fan-out dazu gebracht werden, automatisch auf paarweise Kommunikation zurückzufallen. Das tritt ein, wenn ein Empfänger eine Nachricht nicht entschlüsseln kann. Er fordert dann eine neuerliche Übertragung in paarweiser Kommunikation, schließlich müssen ja nicht alle Gruppenteilnehmer die Nachricht noch einmal erhalten, nur weil einer an ihrer Entschlüsselung scheitert.
Und dieses Scheitern kann absichtlich ausgelöst werden: Wie erwähnt, nutzen Whatsapp und Signal paarweise Kommunikation zur ursprünglichen Übermittlung der Entschlüsselungsschlüssel. Dort setzt der Angreifer an: Er sendet dem Zielclient absichtlich einen Schlüssel, mit dem dieser die „normalen‟ Chatnachrichten des Absenders gar nicht entschlüsseln kann. Dann löst jede normale Nachricht einen Fehler mit der Bitte um neuerliche, direkte Zusendung aus. Daraufhin schickt der böswillige Absender die gefälschte Nachricht mit der ID-Nummer der echten Nachricht.
Server fan-out
Doch auch im server-fan-out-Verfahren, bei dem der Client eine Nachricht an den Server schickt, der sie dann an die Gruppenmitglieder verteilt, ist Manipulation möglich. Die erwähnte Kann-ich-nicht-entschlüsseln-Fehlermeldung des Empfängers bittet zwar um neuerliche Zumittlung mit der paarweisen Methode. Doch diesen Teil der Bitte kann der Angreifer ignorieren und die verfälschte Nachricht als server fan-out absenden.
Dann geht die verfälschte Nachricht zwar an alle Gruppenmitglieder, deren Clients sehen aber die ID einer bereits erhaltenen Nachricht. Daher verwerfen sie die „Kopie‟ ohne Fehlermeldung und prüfen nicht, ob sie die neue Nachricht überhaupt entschlüsseln können. Nur die Zielperson erhält die falsche Nachricht, weil sie das Original nicht entschlüsseln konnte.
Aufgrund des besonders hohen Datenschutzes bei Signal gibt es dort noch einen zweiten Angriffsvektor: Während Whatsapp auf dem Server eine Liste aller Mitglieder einer Gruppe führt, tut Signal das nicht. Der Absender muss jeder Nachricht eine Liste aller Gruppenteilnehmer beilegen und kann dabei bestimmte Teilnehmer unter der Tisch fallen lassen. Sie erhalten diese Nachricht dann nicht, merken aber nichts von der Lücke.
Schwindel bei Zitaten
Ist eine falsche Nachricht einmal zugestellt, bleibt sie auch in Zitaten erhalten, beispielsweise wenn andere Gruppenmitglieder darauf reagieren und ihre Meinung zu dem zitierten Inhalt kundtun. Denn die Zitatfunktion überträgt aus Gründen der Datensparsamkeit standardmäßig nicht den eigentlichen Inhalt, sondern verweist nur auf die ID der zitierten Nachricht. Damit sieht der Empfänger eines Zitats dabei also stets jene Nachricht, die ihm ursprünglich zugemittelt wurde, sei es das Original oder die falsche Nachricht.
Gibt es die referenzierte Nachricht nicht, verweigern Threema und iMessage das Zitat. Signal und Whatsapp fallen jedoch darauf zurück, den Inhalt des Zitats zu übermitteln. Das ist durchaus nützlich, den ein neu zur Gruppe Hinzugestoßener soll ja mitreden können. Allerdings eröffnet das dem Angreifer die Möglichkeit, den angeblich zitierten Inhalt beliebig zu definieren. Das geht auch in 1-zu-1 Chats, ohne Gruppe. Hier ist zu hoffen, dass der Empfänger noch weiß, was er (nicht) von sich gegeben hat.
Signal blendet unter den angeblich zitierten Inhalt immerhin einen Hinweis ein, dass es die zitierte Nachricht nicht finden kann. Bei Whatsapp fehlen solche Hinweise. Und speziell der Desktop-Client Signals erlaubt Zitate von Nachrichten, die erst nach dem Zitat verschickt werden.
Schwindel mit Abstimmungen
Besonderen Spaß dürften die Forscher mit der Abstimmungs-Funktionen der vier Dienste gehabt haben. Keiner sichert die gestellte Frage kryptographisch ab. Bei iMessage, Signal und Threema kann ein Angreifer, der eine Abstimmung erstellt, unterschiedlichen Gruppenmitgliedern unterschiedliche Fragen stellen. Bei binären Fragen (ja/nein) unter Whatsapp, das Abstimmungen mittels Hash absichert, kann er die Antwortmöglichkeiten mit einander austauschen. Was der eine als Ja-Stimme erachtet, ist für den andern womöglich eine Nein-Stimme.
Zudem kann er bei Whatsapp bestimme Mitglieder von der Stimmenzählung ausschließen, in dem er etwa durch absichtliches Einfügen eines unsichtbaren Leerzeichens den Hashwert verändert. Stimmt der Hashwert dann nicht überein, verwirft Whatsapp die abgegebene Stimme einfach.
Bei Threema und Signal ist auch das Abstimmungsergebnis nicht sicher. Threema sieht vor, dass der Ersteller der Abstimmung den Stimmenstand allen Gruppenmitgliedern mitteilt. Da er einzelnen Mitgliedern verfälschte Nachrichten senden kann, kann er die angezeigten Stimmen einzelner Teilnehmer verändern, streichen oder hinzufügen.
Bei Signal verkündet zwar der Server das Abstimmungsergebnis. Doch kann der Angreifer im Voraus solche Mitteilungen erfinden und versenden. Das spätere, echte Abstimmungsergebnis wird von jenen Signal-Clients, die bereits ein gefälschtes Endergebnis erhalten haben, als vermeintliches Duplikat verworfen.
Schwindel durch Abstimmende
Dem nicht genug können auch die Abstimmenden Unfug treiben, indem sie unterschiedlichen Gruppenmitgliedern unterschiedliche Entscheidungen zusenden. Damit laufen die beim jeweilige Empfänger angezeigten Abstimmungsergebnisse auseinander. Bei Threema ist sogar möglich, mit manipulierten Nachrichten mehr als eine Stimme auf einmal in die Waagschale zu werfen, sowie versteckte Stimmen nachzureichen. Bei iMessage kann ein Täter im Namen anderer Gruppenmitglieder abstimmen.
Bei Whatsapp haben die Forscher entdeckt, dass iOS-Clients Abstimmungen anders verarbeiten als Android-Clients. Das können Angreifer ausnutzen, beispielsweise indem sie nur Gruppenmitglieder mit Android-Client abstimmen lassen. Gleichzeitig verrät Whatsapp, welcher Client genutzt wird. Das erlaubt unter Umständen Rückschlüsse auf den Aufenthaltsort des Teilnehmers, beispielsweise wenn er Whatsapp nur im Büro mit Windows nutzt, oder mit Linux nur Zuhause, oder umgekehrt.
Abhilfe
Auseinanderlaufen von Inhalten von Gruppenchats ist für den einzelnen Teilnehmer schwer zu erkennen. Hinzu kommt, dass sensible Chats oft auf automatische Löschung der Inhalte nach kurzer Zeit setzen. Dadurch werden die Manipulationsbeweise automatisch vernichtet.
Das Grundproblem manipulierter Inhalte ist systembedingt, speziell paarweise Kommunikation eröffnet Lücken. Mit Verzicht darauf wäre viel erreicht, das würde aber aufwändiges Redesign erfordern.
Für Signal und Whatsapp, die primär auf server fan-out setzen und nur subsidiär auf paarweise Kommunikation zurückgreifen, haben die Forscher Vorschläge, wie die Probleme reduziert werden könnten: Verbot paarweiser Kommunikation, außer für die ursprünglichen Schlüssel, weil es dort im gegebenen Konzept notwendig ist. Clients sollten unerbetene, neuerliche Zusendungen von Nachrichten generell verwerfen. Bittet ein Client um neuerliche Zumittlung einer Nachricht, sollte das allen Gruppenmitgliedern mitgeteilt werden, um Aufmerksamkeit zu schaffen. Zeitstempel sollten nur vom Server akzeptiert werden, und jede Veränderung der Gruppenzusammensetzung sollte auf technischer Ebene zur automatisch Erstellung einer neuen Gruppe führen.
Vor allem aber sollten Vorgänge transparent gemacht werden: Fehlgeschlagene Entschlüsselung sollte ebenso angezeigt werden, wie neuerliche Zusendung einer früheren Nachricht – samt Warnung, dass der Inhalt einer solchen Nachricht von dem anderen Teilnehmern angezeigten Inhalt abweichen kann. Zudem sollte für jeden Gruppenteilnehmer automatisch eine Statistik geführt werden, die offenlegt, wo sich Entschlüsselungsfehler und neuerliche Versendungen häufen. Denn das ist verdächtig.
Die Autoren
Ein anderer Weg wäre, die Ende-zu-Ende-Verschlüsselung auszuschalten, so dass jeder bei jedem alles mitlesen kann. Davon hält Studienautor Gegenhuber (früher an der Universität Wien, jetzt an der Interdisciplinary Transformation University in Linz tätig) nichts: „Ohne Ende-zu-Ende-Verschlüsselung ist man vollständig vom Server abhängig, und der könnte dann beliebig Nachrichten manipulieren oder unterdrücken. Außerdem könnte der Serverbetreiber alles mitlesen.‟
„Ende-zu-Ende-Verschlüsselung ist eine große und wichtige Errungenschaft‟, betonte Gegenhuber gegenüber heise online. „Dabei wird jedoch Vertrauen und die Verantwortung für Validierung vom Server zum Client verschoben. Und der kann bösartig sein. Daher ist transcript consistency wichtig.‟
Mit Gegenhuber haben Moritz Grefner, Matthäus Wininger, David Schmidt und Aljosha Judmayer (allesamt Universität Wien) sowie Maximilian Günther (SBA Research) die Sache erforscht. Sie haben ihr gemeinsames Paper unter dem Titel Send and Pretend: Exploiting Transcript Consistency Issues in End-to-End Encrypted Group Chats in der Nacht auf Donnerstag bei Github [3] und Zenodo online [4] gestellt. Dort stehen auch Programmcode und Beweisvideos zum Download bereit.
Das Team hat alle vier Dienstebetreiber am 6. Februar informiert. Apple hat laut Forscherteam den Empfang bestätigt. Meta Platforms hat 1.000 US-Dollar Belohnung ausgeschüttet und Verbesserungen bei Abstimmungen in Whatsapp angekündigt. Threema möchte das Teilproblem der Möglichkeit zur Abgabe mehrerer Stimmen angehen.
Keiner der Drei hat demnach angekündigt, das Grundproblem fehlender transcript consistency in Gruppenchats anzugehen. Auch das von einer nichtkommerziellen Stiftung betriebene Signal plant keine Sofortmaßnahmen, möchte sich aber dann dem Problem widmen, wenn es gröbere Arbeiten an der Gruppenchat-Funktion in Angriff nimmt.
URL dieses Artikels: https://www.heise.de/-11384095
Die Patchrate bleibt bei Google dank der Schwachstellenforschung mit künstlicher Intelligenz weiterhin auf einem sehr hohen Niveau. Mit einem neuen Chrome-Update hat der Konzern wie schon Ende Juni abermals fast 400 Sicherheitslücken geschlossen. Auch für andere Chromium-basierte Webbrowser wie Edge, Brave und Vivaldi dürften in Kürze entsprechende Updates folgen.
Die genaue Anzahl der geschlossenen Chrome-Lücken liegt laut der neuen Release-Ankündigung dieses Mal bei 370. Sieben davon sind als kritisch eingestuft. Weitere 71 haben einen hohen, 170 einen mittleren und die verbleibenden 122 einen niedrigen Schweregrad.
Für ein paar Funde schüttete Google Bug-Bounty-Prämien aus. Spitzenreiter ist dabei die Sicherheitslücke CVE-2026-17657, für die der Entdecker 36.000 US-Dollar erhielt. Danach folgen CVE-2026-17728 (10.000 US-Dollar), CVE-2026-17758 (5.000 US-Dollar) und CVE-2026-17898 (3.000 US-Dollar). Für weitere vier Lücken gab es jeweils Prämien zwischen 500 und 2.000 US-Dollar.
Chrome-Update dichtet Lücken ab
Hinweise auf eine aktive Ausnutzung einer der gepatchten Lücken scheint es bisher nicht zu geben. Angesichts der großen Angriffsfläche sollten Anwender das jüngste Chrome-Update aber dennoch nicht unterschätzen. Früher oder später dürften sich Angreifer der ein oder anderen Lücke bedienen, um Chrome-Nutzer zu attackieren.
Wer sich davor schützen will, sollte seinen Chrome-Browser zügig auf Version 151.0.7922.71/.72 für Windows und Mac respektive 151.0.7922.71 für Linux aktualisieren. Viele der damit gepatchten Lücken klaffen direkt in der Chromium-Codebasis, so dass auch andere darauf basierende Webbrowser wie Microsoft Edge, Vivaldi und Brave voraussichtlich in den kommenden Tagen mit entsprechenden Updates versorgt werden.
Details zu den 370 Schwachstellen hält Google aus Sicherheitsgründen derzeit noch unter Verschluss. Damit räumt der Konzern Anwendern zunächst ausreichend Zeit ein, um ihre Webbrowser zu aktualisieren. Auch bei anderen Softwareprojekten ist die Patchrate aufgrund von KI in den letzten Monaten rapide angestiegen.
Wir öffnen unsere neue Community für weitere Mitglieder! Möchtest du in konstruktiver und respektvoller Atmosphäre mit anderen IT-Experten über deine Themen sprechen? Sei dabei und melde dich an!
Effizienter, pragmatischer hätte die Energiewende werden sollen. Bei der Diskussion um die Einspeisevergütung wurde das wohl vergessen.
Private Solaranlagen erzeugen Strom dort, wo er auch verbraucht wird, meistens zumindest.Bild:
Getty Images/Ina Fassbender
Bundeswirtschaftsministerin Katherina Reiche hat das "Rundum-Sorglos-Paket" beendet. Das Kabinett hat sich auf den endgültigen Referentenentwurf des Erneuerbare-Energien-Gesetzes geeinigt.
Wobei damit nur die Sorgen derer vergrößert werden, die eine private Solaranlage errichten oder ein lokales Windrad planen wollen. Netzbetreiber und Energiekonzerne können so weitermachen wie bisher.
Wie das Ziel, in vier Jahren mindestens 80 Prozent des Stroms aus erneuerbaren Energien zu erhalten, ökonomisch effizient erreicht werden soll, bleibt das Geheimnis der Wirtschaftsministerin. Denn Möglichkeiten zur sinnvollen Anpassung der aktuellen Regelungen gibt es eigentlich genug.
Modernisierung des Netzes bleibt fraglich
Zwar reagiert die Gesetzesänderung auf das Problem, dass die Stromnetze vielerorts in den Mittagsstunden oder bei kräftigem Wind überlastet werden, schiebt die Verantwortung dafür aber zukünftig einfach den Betreibern der Anlagen zu. Kümmern diese sich nicht selbst darum, dass keine Überproduktion stattfindet, haben sie Pech gehabt.
Gleichzeitig wurde die Chance verpasst, eine echte Effizienzsteigerung im Stromnetz zu etablieren. Es fehlt weiterhin ein Recht auf Überbauung von Netzverknüpfungspunkten.
Solche Punkte besitzen eine bestimmte Leistungsgrenze, die zum Beispiel eine Solaranlage in den sommerlichen Mittagsstunden schnell erreichen kann. Dreht man dagegen größere Teile dieser Anlage nach Osten und Westen, entfällt diese Mittagsspitze, aber die Maximalleistung der Anlage bleibt gleich. Der Netzanschluss wird dann nie ausgelastet, aber die komplette Infrastruktur wird auf den Transport dieser nur noch theoretischen Maximalmenge ausgelegt.
Noch eklatanter ist dies bei der Kombination von Windkraft, Photovoltaik und Batteriespeichern. Theoretisch könnten sie ihre gemeine Leistung voll einspeisen, was praktisch aber unmöglich beziehungsweise unsinnig ist. An dieser Stelle ließe sich der Netzausbau deutlich pragmatischer gestalten, denn viele dieser Netzverknüpfungspunkte sind auf die Spitzenleistung einzelner Anlagen ausgelegt, die diesen Wert nur an wenigen Stunden im Jahr erreichen. Der Rest ist verschenkte Netzkapazität.
Zumindest das Argument für ein Ende der Einspeisevergütung ab 2027 gebauter privater Photovoltaikanlagen sitzt. Auch bei Überproduktion wird der eingespeiste Strom weiterhin bezahlt, während andernorts Anlagen abgeregelt werden müssen. Das zu beenden, ist richtig.
Auch richtig ist, nicht wie ursprünglich geplant direkt den Rotstift anzusetzen, sondern Übergangsregelungen zu schaffen. Bis 2030 sollen noch Zahlungen fließen, dann gibt es einen Zuschuss zur Direktvermarktung.
Gleichzeitig fehlen echte Alternativen. Bei der Direktvermarktung stehen Privathaushalte großen Marktteilnehmern gegenüber. Das kann nur für eine Seite gut ausgehen. Und die Chance, die Problematik wie in Österreich per Energy Sharing zu lösen, wurde schlicht verpasst. Das zugehörige Gesetz, das den Aufbau von Energiegemeinschaften hätte vorantreiben können, gilt längst als Fehlschlag zugunsten der Netzbetreiber.
Komplett unberührt bleiben immerhin Balkonkraftwerke, die maximal 800 Watt direkt in die Steckdose einspeisen. Zumal die Regelung mittlerweile alle Erzeugungsarten umfasst, somit auch Batteriespeicher. Ähnlich verhält es sich bei größeren Anlagen, wenn diese mit einem Speicher verbunden sind. Wer den größten Teil seines Stroms selbst verbraucht, belastet nicht das Netz und ist zudem auf keine zusätzliche Vergütung angewiesen, die bei geringer Einspeisung ohnehin niedrig ausfallen würde.
Kein Mut, kaum Pragmatismus, wenig Effizienz
Und dennoch nimmt man am Ende zukünftigen Solaranlagenbesitzern eine verlässliche Förderung, ohne alternative Wege zu bereiten. Man lässt Windkraftanlagenbetreiber, die sich längst durch bürokratische Wirren kämpfen müssen, ein höheres Risiko tragen. Ein kluger Netzausbau wird dagegen weiter auf sich warten lassen.
Wo Kapazitäten vorhanden sind, zumindest die meiste Zeit, werden sie nicht konsequent genutzt, und der Impuls für eine schnellere Digitalisierung, damit auch Haushalte ihre Stromkosten durch gezieltes Verbrauchen steuern können, bleibt aus.
So sieht keine effiziente Nutzung eines der stabilsten Stromnetze der Welt aus. Die Novelle des EEG zeugt eher von Mutlosigkeit, auch die großen Betreiber und Erzeuger in die Pflicht zu nehmen, denn von Pragmatismus bei der Energiewende, die eigentlich die Resilienz der Netze erhöhen und die Abhängigkeit von Energieimporten verringern soll.
Die Bahn macht mal wieder Plus. Auch die Zahl der Passagiere ist gestiegen – die hohen Spritpreise sollen Pendler vom Auto zur Bahn gebracht haben.
Ein ICE der Deutschen Bahn am Berliner HauptbahnhofBild:
RALF HIRSCHBERGER / AFP via Getty Images
Medienberichten zufolge soll die Bahn erstmals seit sieben Jahren wieder einen Gewinn in ihrem Kernbereich eingefahren haben. Dem Spiegel zufolge soll im ersten Halbjahr 2026 ein Betrag im dreistelligen Millionenbereich erwirtschaftet worden sein. Auch die Bild-Zeitung berichtet entsprechend.
Im ersten Halbjahr 2025 hatte die Bahn im Vergleich noch Verluste in Höhe von 760 Millionen Euro verzeichnet. Auch bei der Passagieranzahl soll es den Informationen zufolge einen neuen Rekord geben: 960 Millionen Fahrgäste nutzten im ersten Halbjahr 2026 Züge der Bahn. Im Vorjahreszeitraum waren es noch 17 Millionen weniger.
Der Bild-Zeitung zufolge sollen die hohen Kraftstoffpreise der Hauptgrund für den Anstieg der Fahrgastzahl sein. Pendler seien vom Auto auf die Bahn umgestiegen, was durchaus denkbar ist, da die Preise bei der Bahn weitgehend stabil geblieben sind. Auch im Fernverkehr soll seit April 2026 die Nachfrage gestiegen sein. Allerdings waren die Fahrgastzahlen bereits 2025 gestiegen.
Sanierung der Bahn ist oberste Priorität
Bahn-Chefin Evelyn Palla soll die Zahlen am 30. Juli 2026 vorstellen. Palla ist seit ihrem Antritt als Bahn-Chefin im Oktober 2025 bemüht, die Sanierung der Bahn voranzutreiben. Zu Pallas Kernzielen gehört die Verbesserung der Pünktlichkeit der Bahn. Vor allem der Fernverkehr ist notorisch unpünktlich: Im März 2026 erreichten 62,1 Prozent der Züge ihre Ziele mit maximal sechs Minuten Verspätung, was eine Verbesserung gegenüber den Vormonaten darstellte.
Im internationalen Vergleich ist das aber immer noch ein schlechter Wert. In der Schweiz etwa sind die Züge bei einer Pünktlichkeit von über 90 Prozent – und maximal drei Minuten zu spät. Auch in anderen Nachbarländern liegen die Pünktlichkeitsquoten eher im Bereich zwischen 80 und 90 Prozent, bei weniger generösem Zeitpuffer.
2015 lag die Pünktlichkeitsquote des Bahn-Fernverkehrs noch bei 74,4 Prozent. Als Gründe für die Verschlechterung gelten das teils marode Schienennetz, daraus resultierende Baustellen sowie Überlastung von Knotenbahnhöfen, vor denen sich Züge immer wieder stauen.
Athen wollte Meta, TikTok und X zur staatlichen Alterskontrolle verpflichten. Doch der EU-Rechtsrahmen macht den nationalen Alleingang weitgehend wirkungslos.
Bereits seit 2025 kündigt die griechische Regierung an, Kinder und Jugendliche unter 14 Jahren von sozialen Netzwerken fernhalten zu wollen.
Maßnahme zur Chefsache erklärt
Es ist ein ähnlicher Vorstoß, wie ihn aktuell auch Frankreich ins Auge fasst. Das griechische Verbot soll ab 1. Januar 2027 gelten. Premier Kyriakos Mitsotakis hat die Maßnahme des Jugendschutzes zur Chefsache erklärt. Vor rund drei Monaten wandte er sich persönlich an die Jugend.
Der Regierungschef versuchte, die Maßnahme gegenüber der Jugend zu begründen. Er gab den Zeitplan vor. Für den Juli 2026 kündigte er das entsprechende Gesetz an.
Das Prestigeprojekt verschwindet im Kleingedruckten
Formal hielt Mitsotakis sein Versprechen. Am 7. Juli wurden die neuen Regelungen veröffentlicht. Doch statt eines eigenständigen Jugendschutzgesetzes fanden sie sich lediglich in den Artikeln 75 bis 78 der "Sonstigen Bestimmungen" einer Gesetzesnovelle des Justizministeriums zum Schutz vor strategischen Klagen gegen öffentliche Beteiligung (SLAPP – Strategic Lawsuit Against Public Participation).
Noch im Sommer soll das Gesetz durch das Parlament verabschiedet werden.
Dass das Prestigeprojekt ausgerechnet in den "Sonstigen Bestimmungen" eines fachfremden Gesetzes untergebracht wurde, spricht kaum dafür, dass die Regierung ihren großen Wurf selbst noch für einen politischen Erfolg hält.
Tatsächlich fehlen in der endgültigen Fassung der öffentlichen Beratung wesentliche Elemente, die im April pompös angekündigt wurden. So sollten die internationalen Plattformen der sozialen Medien dazu gezwungen werden, die "Kids-Wallet" genannte App des griechischen Staats für die Altersverifikation von Jugendlichen einzusetzen.
Entsprechend sollten Erwachsene ihre Volljährigkeit exklusiv über die "GovGr"-Wallet-App beweisen.
Meta, X, TikTok und andere Plattformen wären damit verpflichtet worden, sich an die staatliche griechische Altersverifikation anzubinden. Die Regierung präsentierte die "Kids Wallet" als europäisches Vorbild und kündigte an, beim digitalen Jugendschutz eine Führungsrolle innerhalb der EU übernehmen zu wollen.
Im Inland konnte "Kids-Wallet" so eingerichtet werden, dass Kiosk-Besitzer, Verkäufer von alkoholischen Getränken und Spielhallenbesitzer bei der Altersverifikation keine persönlichen Daten zu Gesicht bekommen, sondern nur einen QR-Code, den sie mit einer speziellen App lesen müssen.
Die Regierung feierte sich für diese Innovation. Aus ihren Kreisen hieß es wiederholt, man wolle innerhalb der EU als Antreiber für mehr Jugendschutz wirken.
Doch genau an diesem Anspruch scheiterte der Plan. Die großen Plattformen zeigten keinerlei Bereitschaft, ihre Systeme an die griechische Wallet anzubinden. Vor allem aber musste Athen einräumen, dass der europäische Rechtsrahmen einen solchen nationalen Alleingang gar nicht zulässt.
Mitgliedstaaten dürfen Plattformen keine zusätzlichen Verpflichtungen auferlegen, die über das EU-Recht hinausgehen.
Ohne EU-Rechtsgrundlage bleiben den Plattformen freie Hand
Kommunikativ versucht die Regierung, den Rückzug nicht als solchen erscheinen zu lassen. Der Minister für digitale Verwaltung, Dimitris Papastergiou, erklärte im staatlichen Fernsehen ERT, dass "dies nichts ändert an den Absichten der Regierung, unsere Kinder in der neuen digitalen Welt zu schützen".
Auf die Frage, ob ein 14-Jähriger ab dem 1. Januar 2027 Zugang zu sozialen Medien haben wird, antwortete er:
"Wenn die Plattform sicher ist, dass das Kind 14 Jahre alt ist, sollte sie den Zugang verweigern. Besteht Unsicherheit bezüglich des Alters, sollte ein angemessenes und überprüfbares Verfahren zur Altersverifizierung eingesetzt werden. Wir beziehen auch unsere eigenen Applikationen dabei mit ein – diese sind in der Gesetzesbegründung erwähnt."
Papastergiou bestand darauf, dass die Regierung nicht von den ursprünglichen Plänen abweichen würde. Bei der Altersüberprüfung könnten "die Plattformen jedes bewährte Verfahren zur Altersbestätigung des Nutzers nutzen". Denn, "andernfalls drohen ihnen die hohen Bußgelder gemäß der Verordnung für digitale Dienste in Europa".
Faktisch wird sich für viele Minderjährige wenig ändern. Wer heute bei der Altersabfrage mit wenigen Klicks ein falsches Geburtsdatum eingibt, wird das voraussichtlich auch nach dem 1. Januar 2027 machen können.
Welche Verfahren zur Alterskontrolle eingesetzt werden, bleibt den Plattformen überlassen. Gerade die verpflichtende Anbindung an die staatliche "Kids Wallet" war jedoch das Herzstück der ursprünglichen Ankündigungen. Ohne die Verpflichtung der Plattformen, die staatliche griechische Altersverifikation einzusetzen, gleichen die neuen Regeln einem zahnlosen Tiger.
So bleibt vom groß angekündigten Gesetz vor allem eine politische Absichtserklärung. Nun setzt die griechische Regierung ihre Hoffnungen auf ein einheitliches Vorgehen der EU-Kommission.
Jetzt hofft die griechische Regierung auf einen Vorstoß der EU-Kommission.
URL dieses Artikels: https://www.heise.de/-11383043
Wi-Fi 6, Zigbee, Thread, Bluetooth und Ethernet auf einem Chip: Espressifs ESP32-S31 richtet sich an anspruchsvollere IoT- und Maker-Projekte.
Espressif hat den ESP32-S31 in die Serienproduktion geschickt. Damit gelangt ein weiterer ESP32 in Maker-Hände. Espressif setzt hier auf zwei 32-Bit-RISC-V-Kerne mit bis zu 320 MHz Taktfrequenz. Einer der Kerne besitzt einen 128 Bit breiten Datenpfad, kann also größere Datenmengen auf einmal verarbeiten. Auch mit SIMD-Befehlen kann er umgehen, also dieselbe Rechenoperation gleichzeitig auf mehrere Daten anwenden. Dazu kommen 512 KByte SRAM und ein 40-MHz-Koprozessor.
Interessant wird der Chip vor allem bei der Konnektivität. Der ESP32-S31 [1] kombiniert 2,4-GHz-Wi-Fi-6, Bluetooth 5.4 inklusive Low Energy Audio und Bluetooth Classic sowie IEEE 802.15.4 für Zigbee und Thread. Matter wird sowohl über WLAN als auch Thread unterstützt. Zusätzlich integriert der ESP32-S31 einen Gigabit-Ethernet-Controller für 10/100/1000 Mbit/s, benötigt für die Netzwerkverbindung aber weiterhin einen externen PHY (Physical Layer, der die digitalen Ethernet-Daten in elektrische Signale für das Netzwerkkabel umsetzt und umgekehrt). Wer bisher für ein Smart-Home-Gateway mehrere Funkmodule und einen separaten Ethernet-Baustein eingeplant hat, kann die Einkaufsliste also etwas kürzen.
Viele Funktionen integriert
Auch für Displays, Kameras und Audio legt Espressif nach. Der Chip integriert einen Digital Video Port (DVP) für Kameras, kann mehrere Displays gleichzeitig ansteuern, mit bis zu 14 kapazitiven Touch-Kanälen umgehen, JPEG-Dateien in Hardware enkodieren und 2D-Grafik darstellen. Zwei I2S-Controller und eine hardwarebasierte Synchronisation für Bluetooth-Audio zielen auf Lautsprecher, Bedienpanels und Sprachgeräte. Dazu kommen USB 2.0 High-Speed OTG, CAN FD, SD/MMC, SPI, I2C, UART, PWM, A/D-Wandler und weitere klassische Mikrocontroller-Peripherie. Ein CORDIC-Hardwarebeschleuniger ist ebenfalls dabei; er berechnet Funktionen wie Sinus, Kosinus oder Wurzeln besonders effizient. Für selbst gebaute Smart-Home-Zentralen, Touch-Displays, Kamera-Projekte oder lokale Sprachinterfaces ist dieser ESP die richtige Wahl.
Für Maker dürfte vor allem das ESP32-S31-WROOM-3-Modul interessant sein. Laut aktuellem Vorab-Datenblatt stehen 54 GPIOs zur Verfügung. Vorgesehen sind Varianten mit 8, 16 oder 32 MByte Flash und 16 MByte PSRAM. Der ESP32-S31 unterstützt grundsätzlich jedoch bis zu 256 MByte externen Flash sowie bis zu 64 MByte PSRAM – die tatsächlich verfügbare Speicherausstattung hängt von der jeweiligen Modulvariante ab. Das Modul misst 22 × 30 × 3,5 mm.
Espressif unterstützt den ESP32-S31 bereits über ESP-IDF sowie unter anderem mit ESP-Matter, ESP-GMF, ESP-BLE-MESH und ESP-BLE-Audio. Nach der ursprünglichen Vorstellung im März hat der Hersteller am 27. Juli die Serienproduktion bekannt gegeben.
Für 5,49 Euro ist der EWSP32-S31-WROOM-3 bereits auf Aliexpress [2] erhältlich.
Wer mehr über das ESP-Universum wissen will, findet alles dazu in unserem Hardware-Kompass [3].
URL dieses Artikels: https://www.heise.de/-11382965
Stackable stellt die Data Platform 26.7 auf Qualität und Supply-Chain-Sicherheit um. Neben SLSA-Provenance drohen bei der Registry-Logik Breaking Changes.
Für die Veröffentlichung der neuen Version 26.7 seiner Stackable Data Platform weicht das gleichnamige Unternehmen vom üblichen Release-Rhythmus ab. Statt neuer Produktfeatures stand dabei laut Ankündigung die Qualitätssicherung der modularen, auf Kubernetes basierenden Open-Source-Plattform im Mittelpunkt. SDP 26.7 zeichnet sich demnach durch den Abbau technischer Schulden, die Stabilisierung von CI-Pipelines und das Bereinigen instabiler Tests aus. Die Verbesserungen reichen von der dynamischen Registry-Auswahl über erhöhte Supply-Chain-Sicherheit bis zum neuen zentralen Verzeichnis, dem Stackable Hub. Zwar liegen die wichtigsten Neuerungen somit eher unter der Oberfläche. Sie sollen aber insbesondere Betreibern regulierter Infrastrukturen und all jenen zugutekommen, die Operatoren außerhalb des Standardwegs installieren wollen.
Laut Blogbeitrag zum neuen Release [1] liefert Stackable dennoch eine Reihe von Updates, darunter Apache Airflow 3.2.2, Apache Superset 6.1.0, OpenSearch 3.6.0, Trino 481, Apache NiFi 2.9.0, Open Policy Agent 1.16.2 sowie die LTS-Versionen Apache Spark 4.1.2 und Apache Druid 37.0.0. Zudem wurden 133 Schwachstellen behoben – davon 10 kritische und 62 als hoch eingestufte CVEs. Unterstützt werden Kubernetes 1.31 bis 1.36 sowie Red Hat OpenShift 4.18 bis 4.22.
Dynamische Registry-Auswahl – ein Breaking Change mit Folgen
Die folgenreichste Änderung betrifft die Art, wie Operatoren ihre Produktimages beziehen. Bisher war die Registry oci.stackable.tech fest im Code hinterlegt. Anpassungen für Air-Gap-Umgebungen oder interne Mirror-Registries erforderten Helm-Werte pro Produkt oder Eingriffe in die Containerd-Konfiguration auf Knotenebene – ein Workaround, der mit wachsender Plattformgröße zunehmend unhandlich wurde.
Ab Version 26.7 ersetzt Stackable diese Logik durch einen konfigurierbaren Mechanismus. Über den neuen CLI-Parameter --image-repository beziehungsweise die Umgebungsvariable IMAGE_REPOSITORY bestimmen die Operatoren, woher sie ihre Produktimages beziehen. Wird ein Operator über den Helm-Chart oder das OLM-Manifest (Operator Lifecycle Manager) installiert, setzt die Plattform diesen Wert automatisch passend zur Registry, aus der der Operator selbst stammt. Ein Operator, der aus quay.io/stackable kommt, zieht seine Produktimages damit automatisch ebenfalls von quay.io. Stackable veröffentlicht seine Artefakte – inklusive der Operator-Helm-Charts – künftig direkt aus den CI-Pipelines nach quay.io, statt sie manuell zu spiegeln.
Für Installationen außerhalb von Helm oder OLM ist das ein echter Breaking Change. Wer Operatoren per eigenem Deployment-YAML, Kustomize oder ArgoCD betreibt, muss --image-repository explizit im args-Block des Operator-Containers setzen – etwa als --image-repository=oci.stackable.tech/sdp oder mit dem Pfad einer internen Mirror-Registry. Wer eigene Helm-Charts pflegt, muss zusätzlich den Wert image.repository anpassen: Er darf den Operatornamen nicht mehr enthalten. Statt oci.stackable.tech/sdp/airflow-operator lautet der Wert künftig nur noch oci.stackable.tech/sdp. Fehlt die Anpassung, finden die Operatoren ihre Images nicht mehr – die Pods bleiben mit ImagePull-Fehlern hängen. Ein Testlauf in einer separaten Umgebung vor dem Produktiv-Upgrade ist dringend empfohlen.
Unterm Strich wandert die Registry-Portabilität damit von produktspezifischen Workarounds in die Plattformlogik. Für Air-Gap-Szenarien lässt sich IMAGE_REPOSITORY gezielt auf eine interne Registry lenken, sofern die Produktimages konsistent dorthin gespiegelt sind – ein Gewinn für souveräne, interoperable Architekturen.
SLSA-Provenance und SPDX-SBOMs: Nachvollziehbare Lieferkette
Der zweite große Themenblock ist die Supply-Chain-Sicherheit. Ab Version 26.7 liefern alle Container-Images von Stackable – sowohl Produkt- als auch Operator-Images – eine SLSA-Build-Provenance-Attestation (Supply-chain Levels for Software Artifacts [4]). Die Provenance (Herkunft) entsteht über den slsa-github-generator und erreicht SLSA Level 3: Ein vertrauenswürdiger, vom Projekt-Build getrennter Builder erzeugt und signiert die Attestation, sodass ein kompromittierter Buildjob sie nicht fälschen kann. Signiert wird keyless über Sigstore mit GitHub Actions als OIDC-Identity-Provider.
Ergänzend zu den bereits vorhandenen CycloneDX-SBOMs hängt nun an jedem Image auch eine SBOM im SPDX-Format als OCI-Attestation. Zur Verifikation empfiehlt Stackable den slsa-verifier, der stets gegen die Digest-Referenz statt gegen Tags arbeitet. Alternativ lässt sich cosign einsetzen.
Für Betreiber in regulierten Sektoren wie dem Finanz- und Gesundheitswesen sowie der öffentlichen Verwaltung ist das mehr als eine Formalie. Anforderungen aus NIS2 [5], dem EU Cyber Resilience Act [6] oder ISO 27001 verlangen zunehmend den Nachweis, woher Software-Artefakte stammen und ob sie unterwegs manipuliert wurden. Mit der Provenance lässt sich für jedes Image belegen, aus welchem Git-Repository und Commit heraus es gebaut wurde und welche Build-Infrastruktur beteiligt war. Die SPDX-SBOMs erfassen jede enthaltene Bibliothek samt Version und damit die Grundlage für automatisierte CVE-Scans und Policy-Prüfungen. Admission-Controller wie Kyverno oder OPA/Gatekeeper lassen sich so konfigurieren, dass nur Images mit gültiger Signatur und passenden Attestationen in den Cluster gelangen.
Stackable Hub: Ein zentrales Verzeichnis für die Plattform
Neu ist der Stackable Hub unter hub.stackable.tech. Der öffentliche, schreibgeschützte Katalog ist als zentrale Anlaufstelle für alle Fragen rund um SDP-Releases gedacht – und schließt damit eine Lücke zwischen Dokumentation und tatsächlich ausgeliefertem Stand.
Der Hub bietet drei durchsuchbare Bereiche: eine Übersicht aller veröffentlichten SDP-Releases mit Erscheinungs- und End-of-Support-Datum, eine Komponenten-Timeline mit den exakten Versionen jedes enthaltenen Open-Source-Produkts sowie eine CRD-Referenz mit vollständigen .spec-Schemas, die sich nach SDP-Release filtern lassen. Wer wissen will, welche Apache-Kafka-Version in Release 25.11 enthalten war oder wie das Schema eines TrinoCluster-Objekts in Version 26.3 aussieht, findet die Antwort dort ohne Deployment.
Für Tooling und Automatisierung steht eine CORS-fähige JSON-API unter /api/v1/ bereit, ohne Authentifizierung, direkt einbindbar in CI-Jobs, Skripte und MCP-Server. Zusätzlich steht für LLM-Tools ein llms.txt-Endpunkt als Klartext-Zusammenfassung des Hubs bereit, damit ein Assistent aktuelle SDP-Daten in den Kontext einordnen kann, anstatt Versionsnummern zu erraten. Der bisherige CRD- und SBOM-Browser soll künftig in den Hub überführt werden.
Ein Schritt zu mehr Nachvollziehbarkeit und Portabilität
Den drei zentralen Neuerungen ist eines gemeinsam: die dynamische Registry-Auswahl, SLSA-Provenance mit SPDX-SBOMs und der Stackable Hub lassen die Stoßrichtung des Anbieters erkennen, zu noch mehr Nachvollziehbarkeit und Portabilität der Plattform. Weniger Abhängigkeit von fest verdrahteten Defaults, dafür mehr kryptografisch prüfbare Herkunftsnachweise und maschinenlesbare Metadaten für die eigene Automatisierung. Ein kompletter Überblick aller Änderungen in SDP 26.7 findet sich in den Release Notes [7].
URL dieses Artikels: https://www.heise.de/-11380921
Unter bestimmten Bedingungen können Angreifer TeamViewer-Remotesessions unter macOS erstellen.
Wer auf einem Mac TeamViewer Remote Full Client oder TeamViewer Remote Hosts nutzt, sollte die Fernverwaltungssoftware aus Sicherheitsgründen auf den aktuellen Stand bringen.
Hürden für einen Angriff
In einem Beitrag warnen die Entwickler [1], dass Angreifer unter bestimmten Voraussetzungen die Zwei-Faktor-Authentifizierung (2FA) umgehen können (CVE-2026-12703 „hoch“). Damit solch eine Attacke aber überhaupt klappt, müssen die Optionen 2FA for Connections und Unattended Access aktiviert sein. Zusätzlich muss ein Angreifer über einen gültigen Account mit Device-Management-Rechten verfügen.
Ist das alles gegeben, kann ein Angreifer über einen nicht näher ausgeführten Weg den Fernzugriff auf einen Mac über den Unattended-Access-Pfad initiieren. Dabei gibt es keine 2FA-Abfrage und ein Angreifer kann direkt eine Session aufbauen.
Derzeit gibt es dem Softwarehersteller zufolge keine Hinweise auf Attacken. Um Systeme vor möglichen Angriffen zu schützen, müssen Admins sicherstellen, dass TeamViewer Remote Full Client oder TeamViewer Remote Hosts jeweils in der reparierten Version 15.80 installiert sind. Alle vorigen Ausgaben sollen verwundbar sein.
URL dieses Artikels: https://www.heise.de/-11382884
In aktuellen Versionen haben die Entwickler von Apache Traffic Server mehrere Sicherheitslücken geschlossen.
Apache Traffic Server ist über 38 Softwareschwachstellen attackierbar. Angreifer können unter anderem über DoS-Attacken Abstürze auslösen oder Sicherheitsmechanismen umgehen. Bislang gibt es seitens des Softwareherstellers keine Hinweise auf laufende Attacken. Admins sollten die reparierten Ausgaben zeitnah installieren.
Apache Traffic Server ist ein Caching-Proxy-Server und findet vorwiegend in Content Delivery Networks (CDN) Verwendung. Er ist darauf ausgelegt, Millionen Nachfragen pro Sekunde zu verarbeiten.
Mehrere Sicherheitsprobleme
Nutzen Angreifer die Schwachstellen erfolgreich aus, können sie etwa Geo-Kontrollen (CVE-2026-22068 „hoch“) und IP-Zugriffskontrollen (CVE-2026-58159 „mittel“) umgehen. Zusätzlich sind an verschiedenen Stellen DoS-Attacken möglich. Etwa durch das Versenden von präparierten HTTP-Headern kann es zu Abstürzen kommen (CVE-2026-58154 „hoch“).
So, der Hasenstall steht da. Wäre doch gut, wenn man damit gleich auch kühlen könnte, oder?
(Bild: Clemens Gleich / Heise Medien)
Eine Wärmepumpe kann meistens auch kühlen. Wir erklären, worauf es bei der Heizungsplanung ankommt, wenn Heizen und Kühlen implementiert werden sollen.
Eine Wärmepumpe und eine Klimaanlage unterscheiden sich funktionell hauptsächlich in der Prozessrichtung: Die Wärmepumpe konzentriert Wärmeenergie aus der Umgebung und gibt sie ins Hausinnere ab. Die Klimaanlage dagegen konzentriert Wärme aus dem Haus und gibt sie an die Umgebung ab. Wenn der Kältekreislauf des Geräts den Prozess umkehren kann, sind beide Varianten möglich.
Viele Split-Klimaanlagen können mit dem Kompressor heizen und viele Zentralheizungs-Wärmepumpen können auch kühlen. Die Prozessumkehr nutzen die Hersteller zum Beispiel, um den Radiator von Luft-Wasser-Wärmepumpen bei Vereisung periodisch abzutauen. Man kann sie mit etwas zusätzlicher Technik allerdings auch dazu nutzen, kühles statt warmes Wasser durchs Haus zu pumpen. Dazu muss man jedoch einiges beachten bei Planung und Bau – manches ist nicht sofort offensichtlich.
Dieser Artikel beleuchtet typische Fallstricke rund um Kondensat, Verteilung, Pufferspeicher, Thermostattechnik und Sensorik. Er spezifiziert, was eine Kühlung über Wärmepumpe und Fußbodenheizung leisten kann und was nicht und welche baulichen Voraussetzungen dazu gegeben sein müssen. Zuletzt widmet er sich noch der Frage, ob man ohne Fußbodenheizung mit Konvektoren statt Heizkörpern ebenfalls kühlen und heizen könnte. Kurz vorab: Ja, das geht. Aber es ist selten sinnvoll.
URL dieses Artikels: https://www.heise.de/-11378924
Mit spezieller Hardware lassen sich Unterhaltungen aufzeichnen und zusammenfassen. Nötig ist solche Hardware nicht, zeigt die App Granola für die Apple Watch.
Geräte zur KI-gestützten Transkription und Zusammenfassung von Besprechungen und anderen Unterhaltungen erfreuen sich zunehmender Beliebtheit – etwa die von Plaud AI [1]. Der Vorteil: Sie sind kompakt, unauffällig und dienen allein dem Zweck der Aufzeichnung; Bearbeitung und Sichtung erfolgen dann am Smartphone oder auf einem Server. Doch ist es überhaupt notwendig, fast 200 Euro allein für die Hardware zu zahlen, wenn ein Handy mit passender App oder eine Smart Watch das eigentlich gleich miterledigen könnten?
Hinzu kommt, dass die Geräte meistens ein kostenpflichtiges Abonnement verlangen, um sie sinnvoll nutzen zu können. Der britische Anbieter Granola.ai will nun mit einer Apple-Watch-App in diese Lücke stoßen.
Ein Klick auf die Watch
Granolas Software [2], die vorhandene Programme des Anbieters für macOS, Windows und iPhone ergänzt, läuft direkt auf der Computeruhr und zeigt Zusammenfassungen nach Abschluss einer Aufnahme auch gleich auf der Uhr an. Wer mehr mit den Inhalten anstellen möchte – etwa das gesamte Transkript ansehen – greift zur iPhone-App [3].
Die Bedienung der Watch-App ist einfach: Mit einem Knopf wird die Aufnahme gestartet und kann später pausiert oder fortgesetzt werden. Gut hörbare Töne sowie Vibrationen zeigen, dass die Transkription aktiv ist. Anschließend dauert es je nach Aufzeichnungslänge etwas, bis die Cloud-Verarbeitung abgeschlossen ist. Granola.ai verwendet intern offenbar Frontier-Modelle von OpenAI und Anthropic.
In unserem Kurztest klappte die Transkription sowohl auf Englisch als auch Deutsch fehlerfrei, und die Zusammenfassung war ebenfalls gelungen. Granola.ai fragt Nutzer zuvor, in welcher Branche sie tätig sind, was womöglich dabei hilft, das Modell entsprechend anzupassen. Diese Angabe ist allerdings nicht Pflicht. Mit der iPhone-App sind auch ausgehende Telefonate transkribierbar, solange man den Lautsprecher anlässt.
Störend im Betrieb fiel auf, dass die Watch-App bei der Aufnahme offen sein muss, man kann also etwa nicht auf eingehende Benachrichtigungen reagieren. Granola.ai nervt damit, dass man sich entweder mit Microsoft-ID oder Google-Konto anmelden muss. Das soll dazu dienen, berufliche Kalender in die Anwendung zu holen. Es ist allerdings nicht zwangsweise notwendig, den Kalender freizugeben. Logins mit Apple-Konten sind nicht vorgesehen; als dritten Weg kann man nur geschäftliche Konten (Single Sign On, SSO) nutzen.
Alternative: MacWhisper auf dem iPhone
Granola.ai sieht derzeit nicht vor, direkt auf dem iPhone Abos abzuschließen. Stattdessen schließt man es über die macOS- oder Windows-App ab. Die Transkriptionen scheinen keine zeitliche Beschränkung zu haben; allerdings reduziert die kostenlose Variante die Zeit, in der man die Notizen einsehen und durchsuchen kann. Uneingeschränkte Besprechungen samt History kosten 14 US-Dollar im Monat.
Als Alternative lohnt sich ein Blick auf die iPhone-Version von MacWhisper [4]. Diese transkribiert ohne Cloud lokal auf dem Gerät und kann kostenlos verwendet werden, außer man möchte den enthaltenen Chatbot verwenden.
URL dieses Artikels: https://www.heise.de/-11382621
Apple soll abschließend entschieden haben, wer die Screens für seinen neuen OLED-MacBook-Formfaktor liefert. LG und BoE bleiben offenbar außen vor.
Apple wird bei seinem kommenden MacBook Ultra [1] offenbar nur einen einzigen Display-Lieferanten einsetzen, was womöglich zu einer Preiserhöhung führt. Laut einem Bericht des koreanischen Elektronikfachblatts The Elec hat sich die Procurement-Abteilung des Konzerns entschlossen, das OLED-Panel, vermutlich in Tandem-Konfiguration, von Samsung zu erwerben. Mögliche Zweit- oder Dritt-Lieferanten wie LG Display (ebenfalls Korea) oder BoE [2] (China) haben nicht das Rennen gemacht. Damit ist Apple von nur einem Hersteller abhängig – etwas, was Apple etwa beim iPhone gerne vermeidet, wo sich LG und Samsung die High-End-Geräte teilen und BoE zum Teil für günstigere Geräte für den chinesischen Markt zum Einsatz gekommen ist.
Probleme mit der Logistik
The Elec zufolge war es Apple nicht gelungen [3], die notwendigen Volumina zu erreichen. Das soll auch damit zu tun haben, dass Samsung Display einen neueren Prozess (Generation 8.6) als LG (Generation 6) verwendet hat. Daher sei es logistisch zu komplex gewesen, mit zwei Display-Lieferanten zu arbeiten, und Apple entschied sich allein für Samsung. In den kommenden Jahren könnte sich das laut dem Bericht jedoch ändern, wobei LG offenbar nicht vor 2029 bereit ist.
LG Display gehört derzeit zu den wichtigsten Anbietern von Displays in LCD-Bauweise für MacBook und MacBook Pro, für das iPad Pro M5 [4] übernimmt das Unternehmen Teile der OLED-Herstellung. Dabei soll es auch bleiben. LCDs werden noch über Jahre der Standard bei den MacBooks sein, mit dem MacBook Ultra, das angeblich erstmals auch in einem Mac einen Touchscreen [5] erhält, beginnt jedoch die Technikänderung. Als Nächstes könnten unter anderem Standard-MacBook Pro und MacBook Air folgen, doch das wird noch dauern. Laut The Elec soll Samsung anfangs 2,5 Millionen Panel liefern, die Massenproduktion startet im August. Apple kauft 14- und 16-Zoll-Displays.
MacBook Ultra mit neuem Formfaktor
Das MacBook Ultra soll den seit Jahren bestehenden MacBook-Pro-Formfaktor ergänzen. Zu den Neuerungen gehört neben OLED und Touchscreen ein dünneres Gehäuse. Einige der Anschlüsse könnte Apple weglassen, um Platz zu sparen. Im Hinblick auf Chips sollen angeblich erneut M5 Pro und M5 Max verbaut werden, die schon im aktuellen MacBook Pro [6] aus dem Frühjahr stecken.
Der Grund: Der M6 kommt angeblich nicht als Pro- und Max-Variante, die Apple erst mit dem M7 im kommenden Jahr wieder herstellen will. Derzeit erwarten wir das MacBook Ultra im Oktober. Beobachter rechnen damit, dass der Preis jenseits von 2000 Euro beginnen könnte. Ein konkurrenzloser OLED-Lieferant dürfte die Tarife kaum eindämmen helfen.
URL dieses Artikels: https://www.heise.de/-11380092
Samsung-Schriftzug an einer Hecke: Apple braucht viel RAM.
(Bild: Sundry Photography/Shutterstock.com)
Apple erwägt, sich erstmals in China mit RAM zu versorgen, weil die „großen Drei“ nicht liefern können und ihre Preise ständig erhöhen. Samsung plant Abhilfe.
Samsung Electronics plant, seine DRAM-Kapazität kurzfristig auszubauen. Koreanischen Medienberichten zufolge soll die Anlage des Konzerns in Hwaseong am Gelben Meer kurzfristig ihren Output um 15 Prozent erhöhen, um Großkunden wie Apple besser zu versorgen. Bestehende Anlagen sollen erweitert und konsolidiert werden – ergänzt um eine neue „End Fab“, um die Wafer-Handhabung effizienter zu gestalten und den gesamten Output zu erhöhen, heißt es. Es soll dabei zu einer Spezialisierung auf „general purpose DRAM“ kommen, sich also nicht um die von Nvidia & Co. benötigten High-Bandwith-Memory-Chips (HBM) drehen.
Apple streckt Fühler nach China aus
Laut SEDaily.com [1] reagiert Samsung Electronics damit auch auf Apples Versuche, DRAM-Komponenten zumindest für in China verkaufte iPhones von dortigen Herstellern wie CXMT [2] zu erwerben. Allerdings untersagt die US-Regierung dieses Vorhaben bislang, da der RAM-Hersteller, der gerade erfolgreich an die Börse gegangen [3] ist, als Lieferant (beziehungsweise „nahestehendes Unternehmen“) für das chinesische Militär auf der amerikanischen Sanktionsliste steht.
Apple befindet sich in Sachen Speicherlieferungen derzeit zwischen Baum und Borke: Der gigantische Bedarf an DRAM-Modulen für iPhone, iPad, Mac & Co. lässt sich nur dadurch decken, dass der Konzern die stark erhöhten Preise der drei großen Lieferanten SK Hynix, Micron [4] und Samsung Electronics bezahlt. Das alte Modell, bei dem Apple aufgrund seiner gigantischen Stückzahlenabnahme die Tarife herunterhandeln konnte, greift nicht mehr, denn KI-Chip-Hersteller wie Nvidia kaufen noch mehr und nehmen wertvollen Wafer-Platz weg. Apple hatte zuletzt seine Preise für Macs, iPads und Zubehör [5] teils deutlich erhöht. Als Nächstes dürften nun die iPhones [6] dran sein.
Vergleichsweise schnelle Produktionssteigerung
Gegenüber SEDaily.com sagte ein „Insider“, das Unternehmen ziele darauf ab, die General-Purpose-DRAM-Produktion von Samsung Electronics bereits bis Ende des Jahres um 15 Prozent im Vergleich zum Jahresanfang zu steigern.
Haupt-Fab und End-Fab würden kombiniert, so dass die Wafer chargenweise weitertransportiert werden können. Das erleichtere die Logistik deutlich. Aktuell leidet selbst Samsungs eigene Mobilfunktochter unter der RAM-Inflation.
URL dieses Artikels: https://www.heise.de/-11381065
Stackable stellt die Data Platform 26.7 auf Qualität und Supply-Chain-Sicherheit um. Neben SLSA-Provenance drohen bei der Registry-Logik Breaking Changes.
Für die Veröffentlichung der neuen Version 26.7 seiner Stackable Data Platform weicht das gleichnamige Unternehmen vom üblichen Release-Rhythmus ab. Statt neuer Produktfeatures stand dabei laut Ankündigung die Qualitätssicherung der modularen, auf Kubernetes basierenden Open-Source-Plattform im Mittelpunkt. SDP 26.7 zeichnet sich demnach durch den Abbau technischer Schulden, die Stabilisierung von CI-Pipelines und das Bereinigen instabiler Tests aus. Die Verbesserungen reichen von der dynamischen Registry-Auswahl über erhöhte Supply-Chain-Sicherheit bis zum neuen zentralen Verzeichnis, dem Stackable Hub. Zwar liegen die wichtigsten Neuerungen somit eher unter der Oberfläche. Sie sollen aber insbesondere Betreibern regulierter Infrastrukturen und all jenen zugutekommen, die Operatoren außerhalb des Standardwegs installieren wollen.
Laut Blogbeitrag zum neuen Release [1] liefert Stackable dennoch eine Reihe von Updates, darunter Apache Airflow 3.2.2, Apache Superset 6.1.0, OpenSearch 3.6.0, Trino 481, Apache NiFi 2.9.0, Open Policy Agent 1.16.2 sowie die LTS-Versionen Apache Spark 4.1.2 und Apache Druid 37.0.0. Zudem wurden 133 Schwachstellen behoben – davon 10 kritische und 62 als hoch eingestufte CVEs. Unterstützt werden Kubernetes 1.31 bis 1.36 sowie Red Hat OpenShift 4.18 bis 4.22.
Dynamische Registry-Auswahl – ein Breaking Change mit Folgen
Die folgenreichste Änderung betrifft die Art, wie Operatoren ihre Produktimages beziehen. Bisher war die Registry oci.stackable.tech fest im Code hinterlegt. Anpassungen für Air-Gap-Umgebungen oder interne Mirror-Registries erforderten Helm-Werte pro Produkt oder Eingriffe in die Containerd-Konfiguration auf Knotenebene – ein Workaround, der mit wachsender Plattformgröße zunehmend unhandlich wurde.
Ab Version 26.7 ersetzt Stackable diese Logik durch einen konfigurierbaren Mechanismus. Über den neuen CLI-Parameter --image-repository beziehungsweise die Umgebungsvariable IMAGE_REPOSITORY bestimmen die Operatoren, woher sie ihre Produktimages beziehen. Wird ein Operator über den Helm-Chart oder das OLM-Manifest (Operator Lifecycle Manager) installiert, setzt die Plattform diesen Wert automatisch passend zur Registry, aus der der Operator selbst stammt. Ein Operator, der aus quay.io/stackable kommt, zieht seine Produktimages damit automatisch ebenfalls von quay.io. Stackable veröffentlicht seine Artefakte – inklusive der Operator-Helm-Charts – künftig direkt aus den CI-Pipelines nach quay.io, statt sie manuell zu spiegeln.
Für Installationen außerhalb von Helm oder OLM ist das ein echter Breaking Change. Wer Operatoren per eigenem Deployment-YAML, Kustomize oder ArgoCD betreibt, muss --image-repository explizit im args-Block des Operator-Containers setzen – etwa als --image-repository=oci.stackable.tech/sdp oder mit dem Pfad einer internen Mirror-Registry. Wer eigene Helm-Charts pflegt, muss zusätzlich den Wert image.repository anpassen: Er darf den Operatornamen nicht mehr enthalten. Statt oci.stackable.tech/sdp/airflow-operator lautet der Wert künftig nur noch oci.stackable.tech/sdp. Fehlt die Anpassung, finden die Operatoren ihre Images nicht mehr – die Pods bleiben mit ImagePull-Fehlern hängen. Ein Testlauf in einer separaten Umgebung vor dem Produktiv-Upgrade ist dringend empfohlen.
Unterm Strich wandert die Registry-Portabilität damit von produktspezifischen Workarounds in die Plattformlogik. Für Air-Gap-Szenarien lässt sich IMAGE_REPOSITORY gezielt auf eine interne Registry lenken, sofern die Produktimages konsistent dorthin gespiegelt sind – ein Gewinn für souveräne, interoperable Architekturen.
SLSA-Provenance und SPDX-SBOMs: Nachvollziehbare Lieferkette
Der zweite große Themenblock ist die Supply-Chain-Sicherheit. Ab Version 26.7 liefern alle Container-Images von Stackable – sowohl Produkt- als auch Operator-Images – eine SLSA-Build-Provenance-Attestation (Supply-chain Levels for Software Artifacts [4]). Die Provenance (Herkunft) entsteht über den slsa-github-generator und erreicht SLSA Level 3: Ein vertrauenswürdiger, vom Projekt-Build getrennter Builder erzeugt und signiert die Attestation, sodass ein kompromittierter Buildjob sie nicht fälschen kann. Signiert wird keyless über Sigstore mit GitHub Actions als OIDC-Identity-Provider.
Ergänzend zu den bereits vorhandenen CycloneDX-SBOMs hängt nun an jedem Image auch eine SBOM im SPDX-Format als OCI-Attestation. Zur Verifikation empfiehlt Stackable den slsa-verifier, der stets gegen die Digest-Referenz statt gegen Tags arbeitet. Alternativ lässt sich cosign einsetzen.
Für Betreiber in regulierten Sektoren wie dem Finanz- und Gesundheitswesen sowie der öffentlichen Verwaltung ist das mehr als eine Formalie. Anforderungen aus NIS2 [5], dem EU Cyber Resilience Act [6] oder ISO 27001 verlangen zunehmend den Nachweis, woher Software-Artefakte stammen und ob sie unterwegs manipuliert wurden. Mit der Provenance lässt sich für jedes Image belegen, aus welchem Git-Repository und Commit heraus es gebaut wurde und welche Build-Infrastruktur beteiligt war. Die SPDX-SBOMs erfassen jede enthaltene Bibliothek samt Version und damit die Grundlage für automatisierte CVE-Scans und Policy-Prüfungen. Admission-Controller wie Kyverno oder OPA/Gatekeeper lassen sich so konfigurieren, dass nur Images mit gültiger Signatur und passenden Attestationen in den Cluster gelangen.
Stackable Hub: Ein zentrales Verzeichnis für die Plattform
Neu ist der Stackable Hub unter hub.stackable.tech. Der öffentliche, schreibgeschützte Katalog ist als zentrale Anlaufstelle für alle Fragen rund um SDP-Releases gedacht – und schließt damit eine Lücke zwischen Dokumentation und tatsächlich ausgeliefertem Stand.
Der Hub bietet drei durchsuchbare Bereiche: eine Übersicht aller veröffentlichten SDP-Releases mit Erscheinungs- und End-of-Support-Datum, eine Komponenten-Timeline mit den exakten Versionen jedes enthaltenen Open-Source-Produkts sowie eine CRD-Referenz mit vollständigen .spec-Schemas, die sich nach SDP-Release filtern lassen. Wer wissen will, welche Apache-Kafka-Version in Release 25.11 enthalten war oder wie das Schema eines TrinoCluster-Objekts in Version 26.3 aussieht, findet die Antwort dort ohne Deployment.
Für Tooling und Automatisierung steht eine CORS-fähige JSON-API unter /api/v1/ bereit, ohne Authentifizierung, direkt einbindbar in CI-Jobs, Skripte und MCP-Server. Zusätzlich steht für LLM-Tools ein llms.txt-Endpunkt als Klartext-Zusammenfassung des Hubs bereit, damit ein Assistent aktuelle SDP-Daten in den Kontext einordnen kann, anstatt Versionsnummern zu erraten. Der bisherige CRD- und SBOM-Browser soll künftig in den Hub überführt werden.
Ein Schritt zu mehr Nachvollziehbarkeit und Portabilität
Den drei zentralen Neuerungen ist eines gemeinsam: die dynamische Registry-Auswahl, SLSA-Provenance mit SPDX-SBOMs und der Stackable Hub lassen die Stoßrichtung des Anbieters erkennen, zu noch mehr Nachvollziehbarkeit und Portabilität der Plattform. Weniger Abhängigkeit von fest verdrahteten Defaults, dafür mehr kryptografisch prüfbare Herkunftsnachweise und maschinenlesbare Metadaten für die eigene Automatisierung. Ein kompletter Überblick aller Änderungen in SDP 26.7 findet sich in den Release Notes [7].
URL dieses Artikels: https://www.heise.de/-11380921
Gmail REST API, Microsoft Graph und JSON Schema: Himalaya 2.0 richtet die Mail-CLI stärker auf Automatisierung aus.
Die Kommandozeilen-Mailsoftware Himalaya 2.0.0 unterstützt Gmail über die Gmail REST API sowie Outlook- und Microsoft-365-Postfächer über Microsoft Graph. Neben den klassischen Verfahren IMAP und SMTP erhält das Projekt so Zugriff auf Funktionen wie Gmail-Labels und -Threads sowie Graph-spezifische Ordner-, Nachrichten- und Anhangsoperationen.
Himalaya ist ein in Rust geschriebener, zustandsloser E-Mail-Client für die Shell. Er bündelt mehrere Backends hinter einer gemeinsamen Befehlsoberfläche, darunter IMAP, SMTP, JMAP, Maildir und m2dir. Die Software richtet sich vor allem an Nutzer, die E-Mail-Funktionen aus Skripten, Terminal-Workflows oder eigenen Frontends heraus nutzen wollen; eine separate TUI befindet sich in Entwicklung.
Gmail- sowie Outlook- und Microsoft-365-Postfächer ließen sich schon vor Version 2.0.0 [1] über IMAP und SMTP einrichten. Neu ist daher nicht die grundsätzliche Kompatibilität mit diesen Anbietern, sondern der Zugriff auf deren jeweilige API. Die einheitlichen Mail-Befehle bleiben erhalten. Für Funktionen eines bestimmten Protokolls oder Anbieters stellt Himalaya zusätzliche Unterbefehle wie gmail und msgraph bereit.
Die Gmail-Anbindung deckt unter anderem Profile, Labels, Nachrichten, Anhänge, Entwürfe, Threads, Verlauf und Einstellungen ab. Das Graph-Backend bietet Zugriff auf Profile, Mail-Ordner, Nachrichten und Anhänge. Beide Backends authentifizieren sich mit einem OAuth-2.0-Bearer-Token.
Einrichtungsassistent prüft Verbindungen direkt
Die Entwickler haben den Einrichtungsassistenten deutlich ausgebaut. Er erkennt erreichbare Dienste wie IMAP/SMTP, JMAP, Gmail und Microsoft Graph und fragt die passende Anmeldemethode anschließend in einem separaten Schritt ab. Bei IMAP und SMTP wählt der Nutzer einen SASL-Mechanismus wie PLAIN, LOGIN, SCRAM-SHA-256 oder OAUTHBEARER; bei JMAP stehen HTTP-Authentifizierungsarten wie Basic und Bearer zur Wahl.
Der Wizard testet IMAP- und SMTP-Verbindungen bereits während der Konfiguration. Schlägt die Anmeldung fehl, gibt Himalaya keine Konfiguration aus, die später ohnehin nicht funktioniert. Außerdem kann der Assistent bekannte Postfachrollen als Aliase vorbelegen. Bei JMAP ermittelt er sie direkt am Server, für Gmail und Microsoft Graph kennt er die festen Systemordner. Bei IMAP setzt er derzeit nur den Inbox-Alias automatisch.
Dadurch funktionieren Befehle ohne explizite Postfachangabe mit dem voreingestellten Inbox-Alias. Soweit das jeweilige Backend die Ordner kennt, lassen sich auch Ziele wie Gesendet, Entwürfe oder Papierkorb über sprechende Aliase angeben.
Der Aufruf ohne Unterbefehl hat sich allerdings geändert: himalaya startet nun den Wizard, statt wie bisher die Nachrichtenübersicht des Standardkontos anzuzeigen. Die erzeugte Kontokonfiguration gibt das Tool als TOML auf der Standardausgabe aus. Nutzer müssen sie selbst in ihre Konfigurationsdatei umleiten, etwa mit himalaya > ~/.config/himalaya/config.toml. Bestehende Installationen sollten daher bisherige Aufrufe und Skripte prüfen.
Bessere Grundlage für Skripte und externe Werkzeuge
Für Automatisierungen führt Himalaya den Befehl json-schema ein. Er erzeugt für jeden Befehl mit strukturierter Ausgabe eine JSON-Schema-Datei, sofern das zugehörige Backend in die verwendete Himalaya-Version einkompiliert ist. Andere Programme können damit die JSON-Ausgabe validieren und daraus etwa in Python, Rust oder TypeScript typisierte Datenmodelle erzeugen.
Auch die Übergabe vollständiger MIME-Nachrichten vereinheitlicht die neue Version. Befehle zum Senden oder Speichern akzeptieren Nachrichten nun konsistent aus einer Datei, als direkt übergebenen Rohtext oder über die Standardeingabe. Externe Werkzeuge lassen sich dadurch leichter einbinden: Ein MIME-Generator kann eine Nachricht auf die Standardausgabe schreiben, Himalaya übernimmt anschließend den Versand oder speichert sie im gewünschten Ordner. Neu ist außerdem, dass messages send --save <POSTFACH> eine versandte Nachricht zusätzlich in einem ausgewählten Postfach ablegen kann. Mit messages add --send lässt sich eine eingelesene Nachricht speichern und zugleich versenden.
Für Spezialfälle bietet Version 2 zudem direkten Zugriff auf IMAP- und SMTP-Kommandos. Mit imap raw und smtp raw können Anwender Protokollbefehle ohne zusätzliche Verarbeitung an den Server senden. Das eignet sich für Tests, Fehlersuche oder proprietäre Erweiterungen, setzt aber genaue Kenntnisse der jeweiligen Protokolle voraus.
Mehr Modularität, aber auch Umstellungen
Himalaya kann nun über Unix-Sockets mit einem lokalen, bereits authentifizierten IMAP- oder SMTP-Proxy kommunizieren. Das eignet sich etwa für Setups mit einem vorgeschalteten Sitzungsproxy. Über den Unix-Socket handelt Himalaya keine eigene SASL-Authentifizierung aus. Ein Proxy wie sirup kann so eine bereits angemeldete Sitzung bereitstellen, sodass Himalaya für das Speicher-Backend keine zweite Verbindung aufbaut.
Die Entwickler haben außerdem die DNS-Auflösung im Wizard geändert. Bevor Himalaya auf Cloudflares Resolver 1.1.1.1 zurückfällt, nutzt es einen explizit konfigurierten Resolver oder den Resolver des Betriebssystems. Das kann verhindern, dass die für die Mailserver-Suche verwendete Domain an einen zusätzlichen externen DNS-Dienst geht. Zugleich hilft die Änderung in Netzen, die öffentliche Resolver sperren.
Version 2.0.0 streicht zugleich ältere Integrationswege. Himalaya entfernt die eingebauten Composer- und Reader-Konfigurationen sowie Befehle wie compose-with, reply-with und read-with. Für komplexere Entwürfe sollen Nutzer künftig externe Programme einsetzen, die MIME-Nachrichten erzeugen und ihre Ausgabe an messages send oder messages add übergeben.
Auch die IMAP-Befehlshierarchie wurde vereinfacht. Sie orientiert sich nun stärker an der flachen Befehlsliste des Protokolls. Statt tiefer verschachtelter Untergruppen stehen Verben wie select, create, append, store und fetch direkt zur Verfügung.
URL dieses Artikels: https://www.heise.de/-11382819
JetBrains hat eine kritische Sicherheitslücke in TeamCity geschlossen. Angreifer können CI/CD-Pipelines kompromittieren und Befehle auf dem Server ausführen.
Eine kritische Sicherheitslücke bei TeamCity betrifft alle On-Premises-Versionen der Build‑ und Deployment‑Server. Sie erlaubt es Angreifern, CI/CD-Pipelines zu kompromittieren. JetBrains rät dringend zum Update und hat bereits entsprechende Updates bereitgestellt. Cloud-Kunden müssen nicht handeln.
Die am 10. Juli gemeldete Sicherheitslücke betrifft das TeamCity agent polling protocol. JetBrains stuft sie mit dem CVE-Eintrag (Common Vulnerabilities and Exposures) CVE-2026-63077 als kritisch [1] ein, mit einem CVSS-Score von 9.8/10. Zum Zeitpunkt der Veröffentlichung waren keine aktiven Angriffe bekannt, wie JetBrains in seinem Blogeintrag schreibt. [2]
Nutzen Bedrohungsakteure die Sicherheitslücke aus, können sie sämtliche Authentifizierungsmechanismen des Tools umgehen und anschließend beliebige Betriebssystembefehle auf dem Server ausführen. Je nachdem, welche Rechte der Serverprozess besitzt, kann ein erfolgreicher Angriff TeamCity‑Daten, Konfigurationen und gespeicherte Zugangsdaten offenlegen oder den Serverzustand manipulieren.
Um Cyberbedrohungen möglichst wenig Angriffsfläche zu bieten, empfiehlt JetBrains Entwicklerinnen und Entwicklern, den Zugriff auf On-Premises-Server auf vertrauenswürdige Netzwerke zu beschränken und die Server mit minimal erforderlichen Betriebssystemrechten zu betreiben. TeamCity‑Server sollten zudem auf dedizierten Hosts laufen, die von den Build‑Agenten getrennt sind.