Nachdem Trumps globale Importsteuern scheiterten, sind seit Freitag neue Zölle auf Waren aus 60 Ländern in Kraft – diesmal mit Zwangsarbeit als Begründung.
Die 45. Änderung der US-Einfuhrzollsätze innerhalb von 18 Monaten trat am frühen Freitagmorgen um 0:01 Uhr Ortszeit in Kraft – exakt in dem Moment, als die vorherigen Zölle ausliefen. Zufall war das keiner.
Die Trump-Regierung hat damit ein Instrument gefunden, das nach Einschätzung von Handelsrechtlern gerichtsfester sein dürfte als die im Februar vom Supreme Court gekippten "Reziprokzölle [1]".
Gerichtsniederlage als Konstruktionsproblem
Im April 2025 hatte Trump unter dem Schlagwort "Liberation Day" Zölle von bis zu 50 Prozent [2] auf Importe aus aller Welt verhängt – gestützt auf ein nationales Notstandsgesetz.
Das Oberste Gericht erklärte diese Maßnahmen im Februar 2026 für rechtswidrig [3]: Der Präsident habe seine Befugnisse überschritten. Die Folge war eine Rückerstattungswelle; von den rund 166 Milliarden US-Dollar, die der Staat mit diesen Zöllen eingenommen hatte, wurden bisher etwa 81 Milliarden zurückgezahlt.
Als Überbrückung verhängte das Weiße Haus einen pauschalen Zehn-Prozent-Zoll auf alle globalen Einfuhren – mit einer Laufzeit von 150 Tagen. Dieser lief am Freitag aus. Was folgte, war kein Abbau des Zolldrucks, sondern dessen Neubegründung: Die neuen Abgaben stützen sich auf Sektion 301 des Handelsgesetzes von 1974, ein Instrument, das bereits frühere Gerichtsprüfungen überstanden hat.
Zwangsarbeit als juristische Verpackung
Die offizielle Begründung lautet: 60 Handelspartner würden zu wenig gegen die Einfuhr von Waren unternehmen, die unter Einsatz von Zwangsarbeit hergestellt wurden. US-Handelsbeauftragter Jamieson Greer erklärte [4] laut der Nachrichtenagentur Reuters, die USA verfügten seit fast hundert Jahren über ein entsprechendes Importverbot und setzten es konsequent durch. "Es wird höchste Zeit, dass unsere Handelspartner dasselbe tun", sagte Greer.
Länder mit einem Verbot von Zwangsarbeits-Importen zahlen zehn Prozent, Länder ohne ein solches Gesetz 12,5 Prozent. Auf diese 60 Handelspartner entfallen laut Greer rund 99 Prozent der gesamten US-Importe. Ausgenommen sind unter anderem Öl und Gas, Düngemittel, bestimmte Lebensmittel sowie Waren, die bereits unter Sicherheitszöllen nach Section 232 fallen – also Autos, Stahl, Aluminium und Kupfer.
Die Handelsexpertin Caroline Freund, Dekanin der UC San Diego School of Global Policy and Strategy, formulierte [5] gegenüber der BBC direkt: Es gehe hier "nicht um Zwangsarbeit". Trump suche schlicht "einen rechtlichen Grund, die Zölle aufrechtzuerhalten".
Das eigentliche Ziel – Handelsbilanzdefizit senken, verarbeitendes Gewerbe stärken – sei unverändert. Das Ergebnis dieser Politik bisher: Das Handelsbilanzdefizit lag im Mai rund 40 Prozent höher als zu Beginn von Trumps Zollregime, die Beschäftigung im produzierenden Gewerbe sank weiter.
Unterschiedliche Folgen für EU und China
Die Reaktionen der betroffenen Länder fallen je nach ihrer Verhandlungsposition unterschiedlich aus. Die EU erhält einen Satz von zehn Prozent, der laut einem Sprecher der Europäischen Kommission mit den im vergangenen Jahr vereinbarten Obergrenzen des bilateralen Handelsabkommens vereinbar sei. Das schaffe "positive Dynamik" für weitere Gespräche, hieß es aus Brüssel.
Allerdings läuft parallel eine zweite Untersuchung nach Sektion 301 – diesmal wegen angeblicher Überkapazitäten – die 16 weitere Handelspartner betrifft, darunter abermals die EU, China, Japan und Südkorea.
China, das mit 12,5 Prozent belegt wird, wies die Zwangsarbeits-Vorwürfe zurück. "Es gibt keine Zwangsarbeit in China", sagte Außenamtssprecherin Mao Ning. Mehrere internationale Menschenrechtsorganisationen widersprechen dem mit Blick auf die Situation der muslimischen Minderheiten in Xinjiang. Trumps Berater haben chinesischen Unterhändlern signalisiert, die Zölle auf chinesische Waren schrittweise wieder auf jene 20 Prozent anheben zu wollen, die im Handelsabkommen vom November 2025 vereinbart wurden.
Was bleibt, ist ein Muster: Wenn ein Rechtsmittel scheitert, folgt das nächste – mit demselben Ziel und einer neuen Begründung. Ob der neue Anlauf gerichtsfest genug ist, um Trumps Zollpolitik dauerhaft zu tragen, werden die Klagen entscheiden, die Handelsexperten bereits erwarten.
URL dieses Artikels: https://www.heise.de/-11377662
Die 890 Millionen Euro sind nur der sichtbare Teil des Konflikts – die eigentliche Auseinandersetzung gilt den Regeln für die KI-Suche von morgen.
Die Europäische Kommission hat Google mit einer Geldstrafe von 890 Millionen Euro belegt. Das Besondere an dieser Entscheidung ist jedoch nicht die Höhe der Strafe, sondern dass Brüssel erstmals die Grundsätze des Digital Markets Act (DMA) erstmals ausdrücklich auch auf KI-gestützte Suchfunktionen und die neue Generation von KI-Assistenten anwendet.
Die eigentliche Bedeutung der Entscheidung reicht weit über die Geldstrafe hinaus. Die Kommission will augenscheinlich damit den Wettbewerb im KI-Sektor sichern und die Suchmaschinen der Zukunft grundlegend verändern.
Die 890-Millionen-Euro-Strafe teilt sich auf in 460 Millionen Euro wegen Selbstbevorzugung in der Google-Suche und 430 Millionen Euro wegen wettbewerbswidriger Praktiken im Google Play Store, wie aus der offiziellen Mitteilung der EU-Kommission [1] hervorgeht.
Brüssel will Googles KI-Vorsprung begrenzen
Die eigentliche Sprengkraft liegt nicht in der Höhe der Strafe, sondern in den Forderungen der EU: Konkurrierende KI-Assistenten sollen auf Android-Geräten gleichwertigen Zugang zu zentralen Funktionen erhalten – genau wie Googles eigener Dienst Gemini.
Zeitlich fällt die Entscheidung mit neuen Leitlinien der Kommission zusammen, die den DMA ausdrücklich auf KI-Dienste und Android-Interoperabilität ausdehnen, wie aus einer früheren Pressemitteilung [2] hervorgeht.
Die EU-Kommission begründet ihr Vorgehen damit, dass sie die "zukunftssicheren" Instrumente des DMA nutzen müsse, um auf neue Technologien wie künstliche Intelligenz zu reagieren und faire Märkte zu gewährleisten. Darauf machte man in Brüssel schon im April aufmerksam [3].
Google warnt vor Sicherheitsrisiken
Google wehrt sich in einem Blog-Beitrag [4] vehement. Der Konzern argumentiert, die DMA-Vorgaben gefährdeten Privatsphäre, Sicherheit und Produktqualität, da sensible Suchdaten mit Dritten geteilt und Android-Funktionen für Drittanbieter geöffnet werden müssten.
Transatlantische Spannungen nehmen zu
Die Maßnahmen führen zu viel beachteten politischen Spannungen mit der Regierung der USA. US-Präsident Donald Trump bezeichnete EU-Digitalstrafen als "Erpressung", und der US-Handelsbeauftragte kritisierte das Vorgehen als "aggressiv" gegenüber US-Technologiefirmen (New York Times [5]).
Kartelluntersuchung läuft
Unabhängig davon läuft zudem ein weiteres Wettbewerbsverfahren gegen Google. So untersucht die Kommission kartellrechtlich [6], ob Google Web- und YouTube-Inhalte ohne angemessene Vergütung oder Opt-out-Möglichkeit für das Training seiner KI-Modelle nutzt und sich so einen unfairen Vorteil verschafft.
Die eigentliche Bedeutung der Entscheidung liegt deshalb weniger in den 890 Millionen Euro als in einem Machtwechsel: Erstmals versucht die EU, die Regeln für KI-gestützte Suchmaschinen festzulegen, bevor sich neue Monopole dauerhaft verfestigen.
URL dieses Artikels: https://www.heise.de/-11377636
Um KI erfolgreich in Code-Audits einzusetzen, ist die Wahl des Modells gar nicht so wichtig. Entscheidend ist der Workflow, damit man nicht in Funden versinkt.
KI als Spürhund für bessere Pentests und Codereviews einzusetzen, klingt im ersten Moment naheliegend. Aber ein Selbstläufer ist das nicht. Das zeigen die vielen Klagen der Open-Source-Projekte, die vor einer Flut von KI-Meldungen vermeintlicher Lücken stehen. Wie man seinen Workflow dafür anpassen muss, warum Mozilla das vorbildlich wuppt und wo jetzt der Flaschenhals liegt – das erklärt Stephan Zeisberg, Titelautor der neuen iX 8/2026.
Stephan Zeisberg ist Head of Research bei Security Research Labs (SRLabs) und forscht zu KI-gestützten Codeaudits und Schwachstellenanalyse.
(Bild: iX)
Wenn KI so viele Lücken aufspürt, müsste die Softwarewelt damit doch sicherer werden. Warum geraten stattdessen viele Open-Source-Projekte und Security-Teams gerade jetzt unter Druck?
Weil das reine Erzeugen einer Schwachstellen-Meldung inzwischen die billigste Stufe im Prozess geworden ist. Der eigentliche Wert entsteht aber erst weiter oben. Ein Befund wird erst dann zu Sicherheit, wenn ein Mensch prüft, ob er echt ist, ob er im konkreten System erreichbar ist und ob ein Patch das Problem wirklich löst. Genau dort sitzt jetzt der Engpass. curl hat sein Bug-Bounty-Programm im Januar eingestellt, HackerOne den Internet Bug Bounty im März pausiert, Node.js sein eigenes Bounty kurz danach suspendiert, und Linus Torvalds nennt die Linux-Kernel-Security-Liste im Mai öffentlich „almost entirely unmanageable“.
Alle geben denselben Grund an: KI-Werkzeuge produzieren plausibel klingende Reports schneller, als die Empfängerseite sie triagieren, verifizieren und beheben kann. Der Anteil echter Schwachstellen in diesen Reports ist niedrig geblieben, was massiv gestiegen ist, ist das Volumen. Wer nur mehr Findings zählt, misst nicht mehr Sicherheit, sondern die Belastung des Systems. Sicherer wird die Welt erst, wenn die Verifikationsseite mit der Discovery-Seite mitwächst, und das tut sie gerade nicht.
Was ist denn wichtiger für den Erfolg KI-gestützter Audits – ein möglichst starkes Modell oder doch eher der Workflow?
Beides zählt, aber der Hebel liegt eindeutig im Workflow, vor allem für Teams, die KI-Audits gerade erst einführen. Ein zusätzlicher Punkt auf einem Coding-Benchmark bringt weniger als eine ordentliche Reproduktions-Stufe im Prozess. Das zeigt Mozilla mit Firefox 150: 271 geschlossene Sicherheitsbugs in einem einzigen Release, darunter ein 20 Jahre alter Fehler in der XSLT-Engine, kamen nicht aus einem neuen Modell allein. Sie kamen aus einer Pipeline, in der jedes Modell-Finding einen reproduzierbaren Testfall mitbringen muss. Das Modell liefert Kandidaten, die Pipeline sortiert das Rauschen aus.
Mozilla hat seit Jahren eine Fuzzing-Infrastruktur mit reproduzierbaren Test-Cases, automatisierter Deduplizierung und integriertem Triage-Prozess aufgebaut. Darauf haben sie die agentische Test-Pipeline gesetzt, die das KI-Modell zwingt, jeden Befund mit einem reproduzierbaren Testfall zu belegen und die Reproduktion selbst zu fahren. Was sich nicht reproduzieren lässt, fällt raus, bevor ein Mensch es sieht. Der Punkt, der leicht übersehen wird: Neu ist nicht der Baustein, sondern die Kombination.
Umgekehrt gilt: Das stärkste Modell ohne diese Disziplin produziert mehr Rauschen, nicht mehr Sicherheit. Die 80 Prozent Falsch-Positive, die für 2024 und 2025 vielfach berichtet wurden, galten für Modelle, die ohne Reproduktions-Stufe direkt auf eine Codebasis angesetzt wurden. Mit einer disziplinierten Pipeline fällt der Wert deutlich. Welches Modell darauf läuft, ist am Ende zweitrangig gegenüber der Frage, ob überhaupt eine Pipeline da ist.
Und was sollte ein Team tun, das mit KI-Codeaudits starten will, aber nicht die ausgefeilte Infrastruktur Mozillas zur Verfügung hat?
Vor allem: nicht früh und breit einsetzen. Genau das produziert die Triage-Tretmühle, in der Reviewer nur noch Tool-Output aussortieren, statt selbst zu lesen. Was in der Praxis funktioniert, ist ein disziplinierter Einsatz in drei getrennten Stufen. KI vor dem Audit, um die Codebasis zu kartieren, Module und Eintrittspunkte zu identifizieren. KI während des Audits als Navigations- und Recherche-Hilfe. Und KI nach dem manuellen Review als zweite Sicht, die bekannte Muster prüft. Die Reihenfolge ist entscheidend: Wenn KI die erste Sicht liefert, prägt sie den Ersteindruck der Reviewer. Wenn sie die letzte Sicht ist, findet sie, was Menschen entgangen ist.
Dazu vier Regeln: Jedes KI-Finding braucht einen falsifizierbaren Reproduktionsfall, sonst bleibt es Hypothese. Die Findings-Menge wird pro Code-Bereich gedeckelt, damit die KI ihre Kandidaten selbst priorisiert; sonst lernen Reviewer, den ganzen Kanal zu ignorieren. Threat-Modell und die Einschätzung des Schweregrads bleiben in menschlicher Hand. Und wo KI auch Code schreibt, greift eine zusätzliche Schwelle mit dokumentierter Absicht und Negativ-Testfällen. Für Solo-Maintainer, die kritische Open-Source-Bibliotheken alleine tragen, ist das übrigens kein realistisches Programm. Dort ist die Antwort weniger ein besserer Workflow als eine gemeinschaftlich finanzierte Triage-Kapazität.
In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne [4] oder hinterlassen Sie einen Kommentar im Forum.
URL dieses Artikels: https://www.heise.de/-11377461
Competition between intelligent vehicles and merely electrified ones has just begun
Decorations hang from a stage at Toyota Woven City, a real-world prototype city designed as a "living laboratory" for testing and developing future technologies in mobility, sustainability and urban living, developed by Toyota Motor together with Woven byBild:
REUTERS/Daniel Leussink
For years, Toyota and other Japanese automakers were pilloried as global laggards in the electric vehicle revolution.
Tesla sales rocketed, Chinese EV brands took the world by storm and European regulators were planning for an all-electric future. Meanwhile, Japanese players stubbornly stuck to hybrid vehicles, hydrogen fuel cells and fuel-efficient gasoline engines.
Weil der konzernweite KI-Einsatz die Ausgaben für Tokens in die Höhe treibt, führt SAP ein striktes dreistufiges Controlling-System ein.
SAP-Finanzchef Dominik AsamBild:
CNBC via Reuters Connect
SAP will ein System zur Kontrolle der steigenden Ausgaben für künstliche Intelligenz einführen. "Die Token-Kosten steigen bei uns in diesem Jahr stark", sagte Finanzchef Dominik Asam dem Handelsblatt und CNBC. "Wir gehen bei SAP gerade vom Pilotieren zum Industrialisieren über, deswegen bringen wir über das klassische Controlling Effizienz rein." Tokens gelten als zentrale Maßeinheit für den Einsatz und die Abrechnung von KI.
Den Angaben zufolge plant SAP ein dreistufiges Modell. In der Stufe Basic werden die Kosten auf 100 Euro pro Monat limitiert. Beschäftigte in vielen technischen Bereichen werden der Stufe Pro zugeordnet und erhalten 500 Euro Budget. Für eine kleine Gruppe von Intensivnutzern sieht SAP die Stufe Pro Max mit einer Obergrenze von monatlich 5.000 Euro vor. Mit Zustimmung einer Führungskraft sind einmalig sogar 50.000 Euro möglich.
Der größte deutsche Softwarekonzern kommentierte den Plan nicht weiter.
KI: Genehmigung durch Vorgesetzte einholen
Das System beinhaltet einige Kontrollen. Beschäftigte erhalten laut einer Präsentation bei Erreichen von 50 und 80 Prozent ihres Budgets automatisch Hinweise. Wer dauerhaft mehr Kapazitäten benötigt, muss eine Genehmigung durch Vorgesetzte einholen.
"Wir haben bei SAP große Fortschritte gemacht, wie wir die Token-Kosten kontrollieren und optimieren", sagte Asam dem Handelsblatt. "Wir haben heute eine granulare Transparenz, in welchen Organisationseinheiten wie viele Tokens wofür gebraucht werden." Finanzabteilung und interne IT hätten bei der Entwicklung des Systems eng zusammengearbeitet.
Die Geschäftspläne, die nicht von Science-Fiction-Romanen zu unterscheiden sind, überzeugen nicht mehr.
Einst flog ein Tesla Roadster mit der ersten Falcon Heavy in Richtung Mars.Bild:
SpaceX
Es ist so weit: Die Aktien der KI-Firma Tesla und der KI-Firma SpaceX verlieren drastisch an Wert. Die einst für Elektroautos und Raumfahrt bekannten Unternehmen wurden von ihrem CEO Elon Musk in den letzten Jahren zu KI-Firmen erklärt, um an der Investitionsblase teilzuhaben. Dabei wurde das Kerngeschäft vernachlässigt und die Produktentwicklung vollständig den Vorstellungen Musks unterworfen. Jetzt zeigen sich die Folgen.
Der ehemals weltweit führende Elektroautohersteller konnte trotz der Schließung der Straße von Hormus und weltweit steigender Benzinpreise keinen Profit mit dem Verkauf von Elektroautos mehr machen. Dadurch nahm die Enttäuschung nach der Aktionärskonferenz zum zweiten Quartal 2026 überhand. Trotz Verkäufen von 480.000 Autos – während der größten Ölkrise seit den 1970er Jahren – lagen die Profite unter den Erwartungen der Anleger. Der Aktienkurs fiel von über 380 US-Dollar auf unter 310 US-Dollar.
Das Unternehmen musste zu große Rabatte und Nullzinsfinanzierungen gewähren, um die veralteten Modelle 3 und Y überhaupt verkaufen zu können. Dadurch, und wegen zu großer anderer operativer Kosten, verlor es in dem Quartal trotz der hohen Verkaufszahlen über eine Milliarde US-Dollar an Cashflow. Die Luxusmodelle S und X, die zusammen mit 3 und Y einst das Wort S3XY bilden sollten, wurden eingestellt. Der Cybertruck wurde zu einem historischen Flop der Autoindustrie und wird inzwischen weithin mit dem Ford Edsel von 1958 verglichen.
Profite stammen von SpaceX-Aktien
Die dritte Version des stationären Megapack-Akkuspeichers wurde ins Jahr 2027 verschoben. Verschiebungen wie die des Verkaufs des Tesla Semitrucks aufs nächste Jahr und der Einführung von Full-Self-Driving für den Autopiloten ist längst zum Ritual geworden. Der Roadster ist eine mythische Gestalt. Das Robotaxi wird ohne fertigen Autopiloten in Produktion geschickt. Mild ausgedrückt: ein Geschäftsrisiko.
Der Optimus-Roboter, inzwischen vorgeblicher Kernbestandteil des Tesla-Geschäfts, ist kein kommerzielles Produkt, er tut ohne Fernsteuerung noch immer nicht viel und auch mit Fernsteuerung nichts, was die Massenfertigung rechtfertigen würde. Von den lange Zeit vorgebrachten Plänen, jährlich 20 Millionen Autos zu verkaufen, ist schon länger nichts mehr zu hören.
Ein Großteil der Tesla-Profite des Quartals waren zudem Kursgewinne der SpaceX-Aktien in Tesla-Besitz. Seit dem 30. Juni hat die SpaceX-Aktie aber drastisch an Wert verloren. Sie wurde mit einem nominellen Wert von 135 US-Dollar ausgegeben und hatte an der Börse einen ersten Preis von rund 160 US-Dollar. Am selben Tag stieg sie auf rund 180 US-Dollar und in den Tagen danach bis zu einer Spitze von rund 220 US-Dollar. Inzwischen ist sie auf rund 112 US-Dollar gefallen und fällt weiter.
Starship macht viel Aufwand ohne wirtschaftlichen Nutzen
Dabei wird das Starship ein zunehmend problematischer Aspekt des Geschäfts von SpaceX, nicht nur, weil schon der einfache Abbruch eines Teststarts am 16. Juli zu einem Kursverfall führte. Der Aufwand für die Entwicklung ist gigantisch. Anfang Juli wurde bekannt, dass SpaceX das 1000. Merlin-1D-Triebwerk für die erste Stufe der Falcon 9 Raketen fertiggestellt hat. Damit wurden über 100 erste Stufen für Falcon 9 und Falcon Heavy gebaut, die inzwischen 675 Missionen mit weiteren 675 Merlin-Vakuum-Triebwerken durchführten.
Bei der Vorstellung des Raptor-3-Triebwerks trug das letzte Raptor-2-Triebwerk die Seriennummer 569. Vom Raptor 1 wurden über 50 Triebwerke hergestellt und die Seriennummern des Raptor 3 nähern sich der 200. Mit insgesamt über 800 Triebwerken wurde keine einzige Nutzlast in den Orbit gebracht, obwohl sie mit ihrer höheren Effizienz und dem dreifachen Schub pro Flug fast die vierfache Nutzlast transportieren können sollten. Hätte SpaceX eine teilweise wiederverwendbare Rakete wie die Falcon 9 mit Raptor-Triebwerken entwickelt, wären längst Hunderte Flüge mit 70 bis 100 Tonnen Nutzlast durchführbar gewesen.
Ab 6. August wird es Firmenmitarbeitern von SpaceX erlaubt sein, erste Aktienpakete am Markt zu verkaufen. Es ist zu erwarten, dass das große Angebot die Nachfrage übersteigen und die Aktienpreise weiter fallen lassen wird. Kein Wunder also, dass immer vehementer eine Fusion von Tesla und SpaceX gefordert wird, solange die nach allen objektiven Kriterien grotesk überbewertete SpaceX-Aktie noch nennenswerte Preise erzielt.
Der Ausgabepreis der SpaceX-Aktie wurde – das ist unüblich – von Elon Musk festgesetzt. Normalerweise wird der Preis von den am Börsengang beteiligten Banken ermittelt. Die verdienen ihr Geld jedoch mit einem geringen Prozentsatz am Verkaufspreis der auf den Markt gebrachten Aktien. Sie sind damit befangen und waren entsprechend geneigt, der überhöhten Bewertung von 1,8 Billionen US-Dollar zuzustimmen.
Unternehmensbewertung jenseits aller Realität
Dieser Wert wurde augenscheinlich gewählt, um Elon Musk durch die von ihm gehaltenen Unternehmensanteile für kurze Zeit auf dem Papier um ersten Billionär der Welt zu machen. Er entsprach außerdem dem Hundertfachen der rund 18 Milliarden US-Dollar Umsatz von SpaceX, bei etwa 5 Milliarden US-Dollar Verlust. Typischerweise werden Aktien nach ihrem Kurs-Gewinn-Verhältnis bewertet, wobei ein Verhältnis größer als 20 auf eine deutliche Überbewertung hindeutet. Ein Kurs-Umsatz-Verhältnis von 100, bei gleichzeitigen großen Verlusten von rund 25 Prozent des Umsatzes, spottet jeder Beschreibung.
Üblicherweise werden Aktien auch erst mit einem Jahr Handelsgeschichte und einem Jahr Profiten in Aktienindizes aufgenommen. Aber die Nasdaq machte für SpaceX eine Ausnahme, setzte die Aktie schon nach zwei Wochen und trotz der riesigen Verluste auf den Index und erzwang damit ihren Kauf durch alle Indexfonds, die dem Kurs sämtlicher Aktien der Nasdaq folgen. Der Kurs der SpaceX-Aktie sank dennoch.
Die entscheidende Frage lautet daher nicht, wie SpaceX heute sein Geld verdient, sondern womit das Unternehmen künftig seinen Börsenwert rechtfertigen will. Der Börsenprospekt gibt darauf einige aufschlussreiche Antworten.
Von Mars bis Cyberpunk ist alles dabei
Die aktuelle Wachstumsstrategie von SpaceX beinhaltet demnach neben dem Ausbau der Nutzlastkapazität der Raumfahrt und des Starlink-Netzwerkes vor allem den "Aufbau einer Mondökonomie mit Frachttransport, Energieversorgung und industrieller Fertigung auf dem Mond". Geplant ist zudem die weitere Monetarisierung von KI und der ehemaligen Twitter-Plattform X sowie der Ausbau der irdischen KI-Infrastruktur und der eigenen Chipfertigung. Geschäftswachstum soll durch orbitale KI und "digital human augmentation" gesichert werden – ein Konzept, das auch die von Musk gegründeten Firma Neuralink verfolgt und Science-Fiction-Lesern aus Cyberpunk-Romanen bekannt ist.
Das sind lediglich die aktuellen Geschäftsbereiche, in denen SpaceX sofortiges Wachstum erzielen will. Um die Börsenbewertung zu rechtfertigen, ist weiteres Wachstum in Zukunftsmärkten erforderlich.
Die Zukunftsmärkte von SpaceX ist terrestrischer Punkt-zu-Punkt-Transport, also Passagierflüge mit dem Starship – das bislang bei fast der Hälfte der Testflüge explodierte. Hinzu kommen Weltraumtourismus und industrielle Fertigung im Orbit. Vermutlich ist damit der Erdorbit gemeint.
Die Liste wird fortgesetzt mit Passagier- und Frachttransport sowie Energieerzeugung und – erneut – industrieller Fertigung auf Mond und Mars. Das ist eine Wiederholung; es bleibt unklar, warum hier nicht einfach die Ausweitung der Wachstumsstrategie auf den Mars genannt wird. Hinzu kommt Asteroidenbergbau.
SpaceX sieht weltweit mögliche Umsätze von 370 Milliarden US-Dollar für Raumfahrt und Raumtransport. Starlink soll jährlich 670 Milliarden US-Dollar adressieren; ein Markt für weitere 740 Milliarden US-Dollar soll sich im Mobilfunk finden und weitere 200 Milliarden in Geschäfts- und Regierungsaufträgen. Hinzu kommen 26.500 Milliarden US-Dollar Marktvolumen von KI.
Raumfahrt ist also in der Selbstbeschreibung des Geschäfts von SpaceX ein ebenso vernachlässigbarer Nebenaspekt wie das Autogeschäft bei Tesla. Dabei wird noch nicht einmal auf das am Anfang des Prospekts genannte Ziel eingegangen, das "Licht des Bewusstseins zu den Sternen zu erweitern".
SpaceX hofft auf ein Viertel des weltweiten BIP
Der Gesamtmarkt, den SpaceX bedienen will, entspricht heute rund einem Viertel des Bruttoinlandsproduktes der Erde. Über die Außenhandelsbeziehungen der Erde mit dem Mond, dem Mars und den Kolonien des Asteroidengürtels sowie deren Wirtschaftslage lagen zu Redaktionsschluss keine konkreten Zahlen vor. Auch der wichtige Aspekt der Zölle beim Handel mit der Erdprovinz USA, wo sich der Firmensitz von SpaceX befindet, ist unbekannt.
Die Bewertung von Tesla und SpaceX beruht längst nicht mehr auf Elektroautos oder Raumfahrt, sondern auf Erwartungen an KI und Zukunftsmärkte, von denen bisher weit mehr in Science-Fiction-Romanen als in Wirtschaftsmagazinen zu lesen war, ohne dass sich die Realität seither so weitgehend verändert hätte. Genau diese Differenz zwischen den Erwartungen der Geschäftsleitung und der objektiven Realität scheint sich nun zunehmend in den Aktienkursen niederzuschlagen.
Um KI erfolgreich in Code-Audits einzusetzen, ist die Wahl des Modells gar nicht so wichtig. Entscheidend ist der Workflow, damit man nicht in Funden versinkt.
KI als Spürhund für bessere Pentests und Codereviews einzusetzen, klingt im ersten Moment naheliegend. Aber ein Selbstläufer ist das nicht. Das zeigen die vielen Klagen der Open-Source-Projekte, die vor einer Flut von KI-Meldungen vermeintlicher Lücken stehen. Wie man seinen Workflow dafür anpassen muss, warum Mozilla das vorbildlich wuppt und wo jetzt der Flaschenhals liegt – das erklärt Stephan Zeisberg, Titelautor der neuen iX 8/2026.
Stephan Zeisberg ist Head of Research bei Security Research Labs (SRLabs) und forscht zu KI-gestützten Codeaudits und Schwachstellenanalyse.
(Bild: iX)
Wenn KI so viele Lücken aufspürt, müsste die Softwarewelt damit doch sicherer werden. Warum geraten stattdessen viele Open-Source-Projekte und Security-Teams gerade jetzt unter Druck?
Weil das reine Erzeugen einer Schwachstellen-Meldung inzwischen die billigste Stufe im Prozess geworden ist. Der eigentliche Wert entsteht aber erst weiter oben. Ein Befund wird erst dann zu Sicherheit, wenn ein Mensch prüft, ob er echt ist, ob er im konkreten System erreichbar ist und ob ein Patch das Problem wirklich löst. Genau dort sitzt jetzt der Engpass. curl hat sein Bug-Bounty-Programm im Januar eingestellt, HackerOne den Internet Bug Bounty im März pausiert, Node.js sein eigenes Bounty kurz danach suspendiert, und Linus Torvalds nennt die Linux-Kernel-Security-Liste im Mai öffentlich „almost entirely unmanageable“.
Alle geben denselben Grund an: KI-Werkzeuge produzieren plausibel klingende Reports schneller, als die Empfängerseite sie triagieren, verifizieren und beheben kann. Der Anteil echter Schwachstellen in diesen Reports ist niedrig geblieben, was massiv gestiegen ist, ist das Volumen. Wer nur mehr Findings zählt, misst nicht mehr Sicherheit, sondern die Belastung des Systems. Sicherer wird die Welt erst, wenn die Verifikationsseite mit der Discovery-Seite mitwächst, und das tut sie gerade nicht.
Was ist denn wichtiger für den Erfolg KI-gestützter Audits – ein möglichst starkes Modell oder doch eher der Workflow?
Beides zählt, aber der Hebel liegt eindeutig im Workflow, vor allem für Teams, die KI-Audits gerade erst einführen. Ein zusätzlicher Punkt auf einem Coding-Benchmark bringt weniger als eine ordentliche Reproduktions-Stufe im Prozess. Das zeigt Mozilla mit Firefox 150: 271 geschlossene Sicherheitsbugs in einem einzigen Release, darunter ein 20 Jahre alter Fehler in der XSLT-Engine, kamen nicht aus einem neuen Modell allein. Sie kamen aus einer Pipeline, in der jedes Modell-Finding einen reproduzierbaren Testfall mitbringen muss. Das Modell liefert Kandidaten, die Pipeline sortiert das Rauschen aus.
Mozilla hat seit Jahren eine Fuzzing-Infrastruktur mit reproduzierbaren Test-Cases, automatisierter Deduplizierung und integriertem Triage-Prozess aufgebaut. Darauf haben sie die agentische Test-Pipeline gesetzt, die das KI-Modell zwingt, jeden Befund mit einem reproduzierbaren Testfall zu belegen und die Reproduktion selbst zu fahren. Was sich nicht reproduzieren lässt, fällt raus, bevor ein Mensch es sieht. Der Punkt, der leicht übersehen wird: Neu ist nicht der Baustein, sondern die Kombination.
Umgekehrt gilt: Das stärkste Modell ohne diese Disziplin produziert mehr Rauschen, nicht mehr Sicherheit. Die 80 Prozent Falsch-Positive, die für 2024 und 2025 vielfach berichtet wurden, galten für Modelle, die ohne Reproduktions-Stufe direkt auf eine Codebasis angesetzt wurden. Mit einer disziplinierten Pipeline fällt der Wert deutlich. Welches Modell darauf läuft, ist am Ende zweitrangig gegenüber der Frage, ob überhaupt eine Pipeline da ist.
Und was sollte ein Team tun, das mit KI-Codeaudits starten will, aber nicht die ausgefeilte Infrastruktur Mozillas zur Verfügung hat?
Vor allem: nicht früh und breit einsetzen. Genau das produziert die Triage-Tretmühle, in der Reviewer nur noch Tool-Output aussortieren, statt selbst zu lesen. Was in der Praxis funktioniert, ist ein disziplinierter Einsatz in drei getrennten Stufen. KI vor dem Audit, um die Codebasis zu kartieren, Module und Eintrittspunkte zu identifizieren. KI während des Audits als Navigations- und Recherche-Hilfe. Und KI nach dem manuellen Review als zweite Sicht, die bekannte Muster prüft. Die Reihenfolge ist entscheidend: Wenn KI die erste Sicht liefert, prägt sie den Ersteindruck der Reviewer. Wenn sie die letzte Sicht ist, findet sie, was Menschen entgangen ist.
Dazu vier Regeln: Jedes KI-Finding braucht einen falsifizierbaren Reproduktionsfall, sonst bleibt es Hypothese. Die Findings-Menge wird pro Code-Bereich gedeckelt, damit die KI ihre Kandidaten selbst priorisiert; sonst lernen Reviewer, den ganzen Kanal zu ignorieren. Threat-Modell und die Einschätzung des Schweregrads bleiben in menschlicher Hand. Und wo KI auch Code schreibt, greift eine zusätzliche Schwelle mit dokumentierter Absicht und Negativ-Testfällen. Für Solo-Maintainer, die kritische Open-Source-Bibliotheken alleine tragen, ist das übrigens kein realistisches Programm. Dort ist die Antwort weniger ein besserer Workflow als eine gemeinschaftlich finanzierte Triage-Kapazität.
In der Serie "Drei Fragen und Antworten" will die iX die heutigen Herausforderungen der IT auf den Punkt bringen – egal ob es sich um den Blick des Anwenders vorm PC, die Sicht des Managers oder den Alltag eines Administrators handelt. Haben Sie Anregungen aus Ihrer tagtäglichen Praxis oder der Ihrer Nutzer? Wessen Tipps zu welchem Thema würden Sie gerne kurz und knackig lesen? Dann schreiben Sie uns gerne [4] oder hinterlassen Sie einen Kommentar im Forum.
URL dieses Artikels: https://www.heise.de/-11377461
Die United-Internet-Töchter GMX und Web.de führen jetzt Passkeys ein. Sie verbessern damit die Sicherheit und den Schutz vor Phishing.
Der Passwort-Nachfolger Passkey [1] zieht in weitere Dienste ein. Jetzt legen auch die United-Internet-Töchter GMX und Web.de nach und bieten Kunden den besseren Zugangsschutz an.
Nach wie vor ist Phishing von Zugangsdaten ein großes Problem. Ständig versuchen Cyberkriminelle, Opfer zu finden, ihnen die Zugangsdaten abzuluchsen und damit dann weiteren Schaden anzurichten. Das sollen Passkeys erschweren: Sie verknüpfen einen Zugang direkt mit einem Gerät oder Passwortmanager. Der Zugriff von anderen Maschinen aus ist ohne die privaten Schlüssel nicht möglich. Damit gelingt Angreifern kein Zugriff mehr über Nutzername und Passwort und gegebenenfalls in ausgeklügelteren Angriffen ausgeforschte Einmal-Zeichenfolgen der Mehr-Faktor-Authentifizierung.
Anmelden ohne Passwort
Passkeys erhöhen nicht nur die Sicherheit, sondern auch den Komfort. Zur Anmeldung an einer Webseite oder einem Dienst ist nur ein biometrischer Nachweis der Identität nötig, etwa über Fingerabdruckscanner, Lächeln in die Kamera oder die Freigabe über das Smartphone. Nutzerinnen und Nutzer müssen sich keine Passwörter mehr merken.
Um in den Genuss des einfachen Passkey-Logins zu kommen, müssen Interessierte ihn bei GMX und Web.de zunächst einrichten. Das ist aber schnell erledigt, wenn man das Handy zur Hand hat. Auf „Login“ bei dem jeweiligen Angebot klicken, dort „iPhone, iPad oder Android-Gerät“ auswählen und dann den QR-Code scannen. Dann muss „Passkey verwenden“ angeklickt und die Anmeldung mittels Biometrie oder PIN bestätigt werden. GMX hat eine ausführlichere Anleitung [2] online eingestellt, ebenso findet sich eine bei Web.de [3].
Sowohl GMX als auch Web.de erklären weiter, dass die Aktivierung von Passkeys ohne Risiko abläuft. Der Zugang mittels Passwort funktioniert auch weiterhin parallel. Das dient auch als Backup, wenn der Login mittels Passkey fehlschlägt, das Handy verloren geht oder schlicht nicht zur Hand ist. Mit einigen Passwort-Managern wie Bitwarden lassen sich Passkeys auch so abspeichern, dass sie geräteübergreifend nutzbar sind.
URL dieses Artikels: https://www.heise.de/-11377564
Die Buchstaben AI umfliegen Haken und Warndreiecke.
(Bild: tadamichi/Shutterstock.com)
Ein IT-Forscher hat mit der chinesischen KI Kimi K3 mehrere Zero-Day-Lücken in der redis-Datenbank entdeckt. Updates bestätigen die Funde.
Die Entwickler der quelloffenen In-Memory-Datenbank redis haben aktualisierte Versionen veröffentlicht, die mehrere Schwachstellen darin schließen. Sie bestätigen damit Sicherheitslücken, die ein IT-Forscher mit der chinesischen KI Kimi K3 gefunden hat. Die steht in Konkurrenz zu den aktuellen Spitzenmodellen von OpenAI und Anthropic [1] und beweist damit nun, dass sie tatsächlich Schwachstellen aufspüren kann.
Der User „Chaofan Shou“ hat auf X [2] gepostet, dass er mit der KI des chinesischen Start-ups Moonshot AI in 90 Minuten insgesamt 19 Zero-Day-Schwachstellen in der bis dahin aktuellen Fassung 8.8.0 der redis-Datenbank gefunden hat. Kimi K3 hat dabei auch Proof-of-Concept-Code (PoC) erstellt, um das Ausnutzen der Lücken zu demonstrieren. Shou hat ein GitHub-Repository mit den PoCs [3] veröffentlicht.
In der Nacht zum Freitag hat das redis-Projekt nun mehrere aktualisierte Versionen veröffentlicht, die zumindest Teile der vorgestellten Sicherheitslecks stopfen. redis 8.8.1, 8.6.5, 8.4.5, 8.2.8, 7.4.10, 7.2.15 und 6.2.23 [4] bessern mehrere der Schwachstellen aus. Die Entwickler bestätigen damit die Sicherheitslücken, im Beispiel etwa für den Exploit „P88W“ [5] aus dem Schwachstellenrepository.
Updates zügig anwenden
Eine Einordnung des Schweregrads der Lücken sowie etwa CVE-Schwachstelleneinträge fehlen derzeit noch. Allerdings macht es der verfügbare Proof-of-Concept-Code Angreifern leichter, die Sicherheitslecks zu missbrauchen. IT-Verantwortliche sollten daher zügig auf die aktualisierte redis-Version ihres eingesetzten Entwicklungszweigs updaten. Quellcode steht bereit, die Linux-Distributionen dürften kurzfristig ebenfalls Aktualisierungen in der Softwareverwaltung bereitstellen.
Die Kimi-K3-KI von Moonshot AI erfährt eine große Nachfrage. Der Anbieter hat neue Abonnements aufgrund von GPU-Engpässen vorerst gestoppt. Der Beleg, dass Kimi K3 Schwachstellen aufspürt und Exploit-Code erzeugt, dürfte das Interesse daran weiter wachsen lassen. Das war bislang Domäne etwa von Anthropics Mythos oder Fable [6] oder OpenAIs Codex Security [7].
URL dieses Artikels: https://www.heise.de/-11377360
Meta und Ray-Ban machen ihre Smart Glasses alltagstauglicher: Die neue Blayzer setzt vor allem auf besseren Sitz, höheren Komfort und mehr „Brillengefühl“.
Der französisch-italienische Optikriese EssilorLuxottica hat in Zusammenarbeit mit Meta das Portfolio an KI-Brillen seiner Marke Ray-Ban erweitert: Hinzugekommen sind die hier getestete, Blayzer Optics (Gen 2) mit rechteckigem Gestell und die Scriber Optics (Gen 2) in ründlicher „Panto“-Form, erhältlich jeweils in den Größen Standard und Large sowie in vier Farben. Sie richten sich laut Hersteller vor allem an Menschen, die Gläser mit Sehstärken benötigen. Der Partner Apollo-Optik bietet die neuen „Optics“-Brillen passend dazu aktuell nur mit Sehhilfen an, in den Online-Stores von Meta und Ray-Ban bekommt man sie aber auch ohne Korrekturgläser.
Die spezielle Ausrichtung auf Brillenträger ist zunächst nicht unbedingt klar ersichtlich. Immerhin lassen sich bei den Ray-Bans mit Meta-Technik schon seit der ersten Generation ab Werk Einstärken- und Gleitsichtgläser mitbestellen beziehungsweise nachträglich beim Optiker einsetzen. Dass man bei den neuen Modellen höhere Werte (von – 12 bis + 6 Dioptrien) angeben kann als bei den ersten Meta-Brillen (damals zwischen −6,00 und +4,00 Dioptrien), ist erfreulich, gilt aber etwa auch für die zweite Generation der Ray-Ban Wayfarer.
Erst bei genauerem Hinsehen sieht man, dass sich die neuen Modelle gleich an mehreren Stellen individuell auf den Träger anpassen lassen. Und dann wird auch klar, in welche Richtung Meta und Ray-Ban mit den neuen Modellen gehen.
URL dieses Artikels: https://www.heise.de/-11362534
iPhones, Macs und Co. werden immer teurer. Apple versucht, das mit einem neuen Mietangebot auszugleichen. Dabei hilft der Finanzdienst Klarna.
Apple hat zusammen mit dem schwedischen „Pay Later“-Anbieter Klarna [1] ein neues Mietmodell für Hardware-Produkte aufgesetzt. Das sogenannte Apple Upgrade soll laut einem Medienbericht in der kommenden Woche zunächst in den USA starten. Es dürfte dem Konzern dabei helfen, auch in Zeiten der RAM- und NAND-Inflation [2] hohe Stückzahlen abzusetzen, indem Kunden ihre Geräte zu vergleichsweise günstigen Raten leasen und dazu regelmäßig austauschen.
Unterschiede zum iPhone Upgrade
Neu ist dabei, dass das Apple Upgrade offenbar für fast alle größeren Hardware-Produkte des Konzerns zu gelten scheint, also iPhone, Mac, iPad sowie Apple Watch. In den USA und auch in Deutschland [3] wurde bislang für iPhones das sogenannte iPhone Upgrade offeriert. Dabei wird das Handy über 24 Monate finanziert und kann nach 11 Raten unter bestimmten Bedingungen gegen ein neues Modell ausgetauscht werden.
Laut einem Bericht der Finanznachrichtenagentur Bloomberg [4] handelt es sich beim Apple Upgrade um „eine der größten Veränderungen“ für den Geräteverkauf des Konzerns. Wie üblich ist dabei nicht Apple selbst der Leasinggeber, stattdessen verlässt sich der Konzern auf einen Partner. Klarnas Aktie konnte von dem Bericht profitieren und stieg zeitweise zweistellig.
Keine Geräteversicherung enthalten
Apple scheint sich beim Apple Upgrade am Fahrzeug-Leasing zu orientieren. Dabei kann man – gegen Zuzahlung – das Gerät am Ende des Leasings behalten, frühzeitig auf ein neues Modell umsteigen oder das Leasing beenden, wobei es jeweils zur Gebührenpflicht an Klarna kommen kann. iPhones und Apple-Uhren werden für 24 Monate gemietet, Mac und iPad mindestens für 36 Monate. Apple plant, das Programm mit geringeren Leasing-Ratenzahlungen zu bewerben, als derzeit für die „echte“ Finanzierung aufgebracht werden muss.
iPhone Upgrade und andere Finanzierungsoptionen sollen in den USA dann wegfallen. Während iPhone Upgrade zumindest in den USA auch den AppleCare-Versicherungsschutz umfasste, soll dieser beim Apple Upgrade nicht verfügbar sein. In den USA hatte Apple den Dienst zuletzt im vergangenen Jahr als Apple Care One zu einem Aboangebot zusammengefasst [5]. Zuvor war eine Einmalzahlung innerhalb von 60 Tagen der Standard. Apple soll schon seit längerem erwogen haben, seine Hardware künftig auch zu vermieten – ein internes Projekt wurde allerdings dann aufgegeben. Mit Klarna wurde nun ein externer Partner gefunden.
URL dieses Artikels: https://www.heise.de/-11375568
Ab macOS 28 können Macs eine Variante des traditionellen Dateiformats nicht mehr lesen. Apple machte nun neue Angaben dazu, was Nutzer vorab tun sollten.
Alles APFS: Wenn es nach Apple geht, ist sein ab 2017 eingeführtes neues Dateisystem [1], das insbesondere für SSD-Medien geeignet ist, künftig Standard auf der Hardware des Konzerns. Das traditionsreiche Mac OS Extended alias HFS+, das macOS-Nutzer noch vielfach verwenden, beispielsweise für Backup-Festplatten, soll in den kommenden Jahren komplett verschwinden. In einem ersten Schritt streicht Apple mit macOS 28 die Legacy-Kompatibilität zur verschlüsselten Variante [2] von HFS+. In absehbarer Zeit dürfte HFS+ aber gänzlich wegfallen. Nun hat Apple wichtige Anpassungen an einem Supportdokument vorgenommen, was User von verschlüsselten Mac-OS-Extended-Datenträgern künftig beachten müssen.
Schneller direkt umwandeln
Hieß es bislang, dass Nutzer vorhandene HFS+ [3]-Encrypted-Volumes zunächst langwierig entschlüsseln müssen, um sie dann wieder im verschlüsselten APFS-Format anzulegen, um ein ähnliches Datenschutzniveau zu erreichen, bietet Apple nun eine weitere Option an: Das Festplattendienstprogramm (Disk Utility) kann aus verschlüsselten HFS+-Medien auch ohne Umwege solche in verschlüsseltem APFS machen. Das geht, indem man den Datenträger in der Seitenleiste auswählt und dann über das „Bearbeiten“-Menü (oder das Kontextmenü) schlicht den Unterpunkt zum Umwandeln nach APFS wählt.
Das soll mit jeglichen Datenträgern, egal ob Festplatte oder SSD, möglich sein, gilt allerdings nicht für Time-Machine-Backup-Medien [4]. Die alte Option mit Entschlüsselung, Umwandlung von HFS+ nach APFS und anschließender Verschlüsselung hat Apple ersatzlos gestrichen. Offenbar war dem Konzern aufgefallen, dass es auch eine direkte Umwandlungsoption gibt. Neu ist diese eigentlich nicht.
Backup gleich in APFS anlegen
Trotz der Möglichkeit, verschlüsselte HFS+-Datenträger ohne Umwege in verschlüsseltes APFS umzuwandeln, sollte man vor dem Start des Vorgangs ein Backup des HFS+-Mediums anlegen. Der Konvertierungsprozess gilt zwar als sicher, ist jedoch ein schwerer Eingriff in die Datenintegrität, weshalb man auf Nummer sicher gehen sollte. Das Backup-Medium sollte man dann gleich im verschlüsselten APFS-Format anlegen, um spätere Probleme zu umgehen.
Neben der oben beschriebenen Direktumwandlung gibt Apple Nutzern vor Erscheinen von macOS 28, das im Herbst 2027 erwartet wird, noch zwei weitere Möglichkeiten: Das Entschlüsseln des verschlüsselten HFS+-Mediums (was direkt geht) oder dessen Umformatierung nach AFPS oder verschlüsseltes APFS. Vor der Umformatierung muss ein Backup angelegt werden, weil dann alle Daten verloren gehen und später wieder aufgespielt werden müssen.
URL dieses Artikels: https://www.heise.de/-11375576
Bislang gibt es die offizielle Apple-Kreditkarte nur in den USA. Dortige Nutzer bekommen dort nun mehr Transparenz über ihre Einkäufe.
Mit iOS 27 [1], das im September erwartet wird, führt Apple bei seiner hauseigenen Kreditkarte eine neue Funktion ein, die im Zeitalter der Abodienste [2] äußerst nützlich sein könnte: In der Apple Wallet werden künftig sogenannte Recurring Payments, also wiederkehrende Zahlungen, gelistet. Dabei kann man sich sogar in einem Kalender anzeigen lassen, wann die nächste Abbuchung vom Kartenkonto zu erwarten ist. Wer also die Übersicht verloren hat, wann wieder einmal eine Subskriptionszahlung fällig wird, bekommt hier eine leicht zugängliche Liste. Das Problem: Die 2019 gestartete Apple Card [3] wird nach wie vor nur in den Vereinigten Staaten (mit entsprechendem Wohnsitz) angeboten. Ob Apples neuer Zahlungspartner, JPMorgan [4], hier etwas ändert, ist noch unklar. Immerhin startete dieser mit seiner Privatkundenmarke Chase gerade in Deutschland ein Tagesgeldkonto [5].
Apple Card direkt in der Wallet eingebaut
Apple hatte versucht, die Apple Card möglichst kundenfreundlich zu gestalten, auch wenn es zwischenzeitlich am Kundenservice haperte [6], was jedoch auch am inzwischen ausgeschiedenen Partner Goldman Sachs [7] gelegen haben soll. Die Apple-Kreditkarte bietet uneingeschränkte Cash-Back-Zahlungen (zwei Prozent auf reguläre Einkäufe, drei Prozent bei Apple) und ist im Gegensatz zu den meisten konkurrierenden US-Angeboten komplett gebührenfrei. Allein die Zinsen können, sollte man die Karte nicht sinnvollerweise monatlich abbezahlen, (sehr) hoch sein.
Der Nutzungsbeginn der Apple Card gestaltet sich dank tiefer iPhone-Integration sehr einfach: Neukunden können die Karte direkt in der Apple Wallet abschließen und dann auch gleich via Apple Pay nutzen. Eine physische Karte aus Titan samt PIN wird per Post nachgeschickt, um sie auch an Verkaufsstellen ohne NFC-Funktion nutzen zu können, die jedoch auch in den USA immer seltener werden. Die Verwaltung der Karte erfolgt ebenfalls in der Apple Wallet, samt Übersicht und Zahlungseinstellungen. Ein Sparkonto (Apple Card Savings Account [8]) wird ebenfalls angeboten.
Wie die Aboübersicht für die Apple Card funktioniert
Die neue Aboübersicht für die Apple Card in iOS 27 funktioniert allerdings nur, wenn man die Karte etwas länger verwendet hat. Ob eine Zahlung „recurring“ ist, wird allein aus der Vergangenheit geschlossen. Die Apple Wallet schaut also in die Apple-Card-Historie, um daraus zu schließen, wann eine nächste regelmäßige Zahlung erfolgt. „Die angezeigten Daten und Beträge sind Prognosen, die auf Ihrem Transaktionsverlauf basieren, und sind möglicherweise nicht exakt. Regelmäßige Ausgaben werden unter Umständen fälschlicherweise als wiederkehrend angezeigt“, schreibt Apple dazu.
Der Konzern selbst kann dafür allerdings nichts: Abozahlungen werden üblicherweise nicht über ein festes System abgewickelt, bei dem Kreditkartenausgebern eine Terminliste übermittelt wird, sondern die Zahlungen werden vonseiten des Abounternehmens angestoßen. Entsprechend besteht nur die Möglichkeit, nach der Historie zu gehen. Fehlerhaft markierte Einträge können korrigiert werden.
URL dieses Artikels: https://www.heise.de/-11375580
98 Prozent unserer DNA galten lange als Müll. Nun zeigt sich: Das dunkle Genom steuert Krankheiten. Erste Therapien sind aber noch Jahrzehnte entfernt.
Als Wissenschaftler im April 2003 das menschliche Genom entschlüsselt hatten, waren sie verblüfft. Nach 13 Jahren Arbeit und – nach heutigen Preisen – rund 2,5 Milliarden Euro Kosten offenbarte sich eine überraschende Wahrheit: Nur etwa zwei Prozent unserer drei Milliarden DNA-Bausteine enthalten Anleitungen für Proteine.
Die restlichen 98 Prozent wurden zunächst als "Junk-DNA" abgetan – genetischer Müll ohne erkennbaren Nutzen. Diese Einschätzung erwies sich jedoch als spektakulärer Irrtum.
Heute wissen Forscher: Das dunkle Genom stellt ein komplexes Steuerungssystem [1] dar, das reguliert, wann und wie stark unsere Gene arbeiten.
Transposone: Wie springende Gene die Evolution prägten
Den Löwenanteil von etwa 50 Prozent aber bilden sogenannte Transposone [2] – springende Gene, die ihre Position im Erbgut wechseln können. Die Biologin Barbara McClintock entdeckte diese springenden Gene bereits 1944 bei der Untersuchung von Mais. Erst 1983 erhielt sie für ihre Entdeckung den Nobelpreis.
Heute ist klar: Diese genetischen Relikte haben die Evolution teils maßgeblich geprägt. Ein Transposon könnte zum Beispiel für den Verlust des Schwanzes bei den Vorfahren der Menschenaffen verantwortlich sein, was wiederum zur Entwicklung des aufrechten Gangs führte.
Endogene Retroviren: Uralte Virenreste formen die Plazenta
Das dunkle Genom besteht zum Teil aber auch aus Überbleibseln uralter Eindringlinge; konkret von virusähnlichen Elementen: Etwa fünf Prozent sind Reste ehemaliger Retroviren [3], die sich vor Jahrmillionen in das Erbgut unserer Vorfahren eingenistet haben.
Noch erstaunlicher: Säugetiere haben sich virale Gene angeeignet, um Plazenten zu bilden, das Organ, das Föten mit allem Lebensnotwendigen versorgt. Verschiedene Säugetiergruppen haben für ihre Plazenten jeweils unterschiedliche Virengene gekapert – ein Prozess, der sich mehrfach unabhängig voneinander ereignete.
TAF1-Gen und XDP: Wenn die Gen-Steuerung versagt
Diese uralten Virenreste in unserem Erbgut sind normalerweise stillgelegt. Doch wenn diese Kontrolle versagt, können sie Krankheiten auslösen. Auf der philippinischen Insel Panay tritt etwa eine unheilbare Bewegungsstörung XDP besonders häufig auf. Genetiker fanden heraus, dass alle Betroffenen eine einzigartige Variante des Gens TAF1 tragen – mit einem Transposon mittendrin, das die Genfunktion auf schädliche Weise reguliert.
Auch bei chronischen Krankheiten spielt das dunkle Genom eine zentrale Rolle. Genomweite Assoziationsstudien, die nach genetischen Variationen bei großen Personengruppen suchen, zeigen: Die meisten mit Alzheimer, Diabetes oder Herzkrankheiten verbundenen Variationen liegen nicht in den proteinkodierenden Bereichen, sondern im dunklen Genom.
Denn das dunkle Genom produziert sogenannte nicht-kodierende RNAs. Die dirigieren, wie unser Genom auf die Umwelt reagiert. Wenn wir dem dunklen Genom durch Rauchen, schlechte Ernährung oder Bewegungsmangel dauerhaft falsche Signale geben, können diese RNA-Moleküle den Körper in einen Krankheitszustand versetzen [4].
VHL-Gen: Wie reaktivierte Retroviren Tumorzellen bekämpfen
In Krebszellen gerät das dunkle Genom besonders durcheinander. Bei Nierenkrebs wird zum Beispiel ein Gen namens VHL beschädigt, das normalerweise als Sauerstoffsensor der Zelle fungiert. Die Folge: Die Krebszelle erhält also fälschlicherweise das Signal, es herrsche Sauerstoffmangel. Dieser Fehlalarm aktiviert Teile des dunklen Genoms, insbesondere endogene Retroviren.
Und diese reaktivierten Virenreste dienen als rote Flaggen für das Immunsystem, das es wie echte Viren bekämpft. Und während das Immunsystem das tut, zerstört es gleichzeitig die Krebszellen.
Bleibt die Frage, ob und wenn ja wie sich dieser Mechanismus therapeutisch nutzen lässt. Mehrere Unternehmen entwickeln bereits Krebsimpfstoffe, die gezielt Proteine aus dem dunklen Genom angreifen. Es kann aber noch Jahrzehnte dauern, diese neuen Erkenntnisse in praktische Therapien umzusetzen.
Präzisere Medizin mit weniger Nebenwirkungen
Auch in anderen Bereichen eröffnet das dunkle Genom neue Möglichkeiten. Forscher untersuchen, ob reaktivierte Virenelemente im Blut als Frühwarnsystem für Krebs dienen könnten. Andere prüfen, ob schädliche endogene Retroviren stumm geschaltet werden können, um Autoimmunerkrankungen zu behandeln.
Endogene Retroviren wurden auch mit altersbedingten Entzündungen in Verbindung gebracht. Es wurde sogar schon vorgeschlagen, antiretrovirale Therapie zu nutzen, um Alterung und altersbedingte Entzündungen zu verlangsamen.
Die Erkundung geht weiter
Aber noch sind die grundlegenden Regeln, wie die verschiedenen Elemente des dunklen Genoms miteinander kommunizieren und Genaktivität regulieren, weitgehend unbekannt. Ebenso rätselhaft bleibt, wie sich komplexe Wechselwirkungen über lange Zeiträume in Krankheitsmerkmale verwandeln.
Aber es existieren mittlerweile Werkzeuge, um dies zu untersuchen. Eines dieser Werkzeuge ist die Geneditierung. Diese wird zum Beispiel genutzt, um mehr über die Entstehung der Bewegungsstörung XDP zu lernen, indem es die TAF1-Gen-Transposon-Insertion in Mäusen nachbildet.
Ein noch ehrgeizigeres Projekt sieht vor, synthetische DNA-Stücke von Grund auf zu bauen und in Mauszellen einzupflanzen. Die Reise in die Tiefen unseres Erbguts hat gerade erst begonnen. Was einst als genetischer Müll galt, entpuppt sich als Schatzkammer der Evolution – und möglicherweise als Schlüssel zu neuen Therapien.
URL dieses Artikels: https://www.heise.de/-11375708
Start einer seegestützten ballistischen Rakete im Pazifik, Anfang Juli 2026.
(Bild: Chinesische Marine)
Stiller Test, laute Botschaft: Peking schließt die letzte Lücke seiner nuklearen Triade. Warum dies die Machtsymmetrie empfindlich verschiebt. Eine Analyse.
Der chinesische Drache zeigt seine Zähne. Anfang Juli 2026 feuerte [1] die Volksbefreiungsarmee erstmals eine U-Boot-gestützte ballistische Rakete mit Übungssprengkopf von einem Atom-U-Boot aus in den Pazifik – und demonstrierte damit, wozu ihre Atomstreitkräfte künftig fähig sein sollen.
Der Test, den Peking als Erfolg wertet [2], war in eine Marineübung eingebettet, die parallel zu gemeinsamen Manövern mit russischen Streitkräften stattfand [3]. Doch die eigentliche Botschaft reicht weiter: Der Abschuss könnte den Moment markieren, in dem China die letzte Lücke seiner nuklearen Abschreckung schließt.
Auffällige Vorwarnung
Der Übungsgefechtskopf sei "präzise im vorgesehenen Seegebiet" eingeschlagen, erklärte [4] Marinesprecher Wang Xuemeng über den offiziellen WeChat-Kanal der Marine. Der Abschuss sei Teil der regulären Jahresausbildung gewesen [5], völkerrechtskonform und nicht gegen einzelne Staaten gerichtet.
Dennoch löste [6] die Übung in der Region heftige Reaktionen aus. Japan, Australien und Neuseeland übten [7] scharfe Kritik. China betonte [8] jedoch, alle betroffenen Staaten vorab informiert zu haben – dies wurde unter anderem von Papua-Neuguineas Außenminister Justin Tkatchenko bestätigt. Neuseeland reagierte [9] erst im Nachhinein und erklärte [10], Wellington sei "zutiefst besorgt über Chinas Tests atomwaffenfähiger Waffen".
Auffällig ist, dass Peking den Test überhaupt öffentlich bestätigte – solche Vorgänge wurden in der Vergangenheit mindestens unkommentiert gelassen. Die ungewöhnliche Offenheit deutet auf eine bewusste, auf Außenwirkung orientierte Kommunikation hin.
Hier liegt die Brisanz: Erstmals ist öffentlich dokumentiert, dass Chinas strategische Atom-U-Boote Raketen abfeuern können [11] – der Beleg für eine einsatzfähige nukleare Zweitschlagfähigkeit zur See.
Washington reagierte alarmiert [12] und warf Peking vor, sein Atomarsenal schnell und intransparent auszubauen; die Vorwarnzeit für den Test sei unzureichend gewesen – obwohl Dritte die Vorab-Information bestätigt hatten. Noch unmittelbarer betroffen zeigte [13] sich Taipeh: Die Rakete soll über den westlichen Pazifik geflogen sein, jenen Raum also, über den im Krisenfall US-Verstärkung für die Insel anlaufen müsste.
Historischer Schritt
So sehr sich die chinesische Militärführung bemühte, den Vorgang als Routine herunterzuspielen – so außergewöhnlich ist er. Erst zum dritten Mal überhaupt schoss [14] Peking eine Langstreckenrakete in den Pazifik.
Frühere chinesische Interkontinentalraketentests erfolgten [15] über steile Flugbahnen innerhalb Chinas und erlaubten keine vollständige Erprobung realer Einsatzbedingungen. Der Test könnte somit auch der Validierung von Navigationssystemen, Flugbahn, Zielgenauigkeit sowie der Erfahrung des realistischen Wiedereintritt in die Atmosphäre gedient haben.
Entscheidend bei der Triade ist, dass selbst wenn ein Gegner mit einem Erstschlag Teile der Atomstreitkräfte zerstört, mindestens eine Komponente einsatzfähig bleiben und zurückschlagen können muss – nur so wird ein nuklearer Angriff unattraktiv [21].
Bislang existierten [22] kaum öffentlich bekannte Tests einer chinesischen JL-2 oder JL-3 von einem tatsächlich operierenden U-Boot. Hinzu kamen [23] amerikanische Vermutungen, der U-Boot-Typ 094 sei lauter als seine russische oder amerikanische Konkurrenz, sowie Zweifel an der Raketen-Reichweite.
Zweitschlag unter Wasser
Entscheidend aktuell ist dennoch nicht allein die Rakete, sondern die Abschussplattform. Ein Start von einem strategischen Atom-U-Boot gilt als wesentlich anspruchsvoller als von Land, weil Kommunikation, Feuerleitsystem, Navigation, Raketenausstoß in großer Tiefe sowie die Stabilität des Bootes ineinandergreifen müssen.
Sicherheitsexperte Collin Koh analysiert [24], wonach gerade Startverfahren, Feuerleitung und Führungs- und Kontrollsysteme (C3) entscheidend seien, um eine glaubwürdige seegestützte Nuklearabschreckung aufzubauen. Der Test lässt somit erstmals darauf schließen, dass Peking dem gewachsen ist.
Der militärische Wert liegt im Sinne eines "Gleichgewicht des Schreckens" darin, dass sie auch nach einem gegnerischen Erstschlag unentdeckt bleiben und anschließend zurückschlagen können. Experten interpretieren [25] die jüngste Entwicklung daher als wichtigen Schritt hin zu einer glaubwürdigeren chinesischen Zweitschlagfähigkeit.
Detailfrage mit Sprengkraft
Unklar bleibt, welcher Raketentyp getestet wurde. Der Generalsekretär des taiwanischen Nationalen Sicherheitsrats vermutet [26] eine ältere, leistungsschwächere JL-2; auch Bildanalysen des veröffentlichten Materials deuten [27] darauf hin.
Chinesische Staatsmedien und Militärexperten gehen hingegen [28] von der moderneren JL-3 aus, deren Reichweite auf 10.000 bis 12.000 Kilometer geschätzt wird. Sie würde es chinesischen U-Booten erlauben, Ziele auf dem US-Festland aus relativ geschützten Gewässern nahe der eigenen Küste zu erreichen. Dafür spricht [29], dass die JL-3 sich derzeit auf modernisierten Typ-094A/Jin-Klasse-Booten in der Einführung befindet und China zuletzt gehäuft und politisch forciert stets sein modernstes Gerät präsentierte.
Ein eindeutiger Nachweis fehlt bislang, verspricht aber zusätzlichen strategischen Zündstoff: Bereits 2024 warnte [30] der Pentagon-Bericht vor genau jener Schwelle, die mit einer erprobten JL-3 erreicht wäre. Die Marine der Volksbefreiungsarmee ließ Fragen zum genauen Typ bislang womöglich bewusst unbeantwortet.
Regional, global, offensiv?
Der Test muss auch vor dem größeren Panorama einer sich verändernden chinesischen Marinedoktrin [31] gelesen werden: China baut seine Marine von einer Küstenflotte zu einer global operierenden Streitmacht aus. Dennoch kann die maritime Strategie unter dem Motto "Near Seas Defense, Far Seas Protection" als Vorwärtsverteidigung zur Sicherung von Frieden und Freihandel gelesen werden [32]– auch der aktuelle Test kann als Zweitschlagfähigkeit defensiv dargestellt werden.
Ob das der Realität entspricht, darf angesichts der Rüstungsspirale im Indopazifik und der aufziehenden, sich verschärfenden Großmächtekonkurrenz bezweifelt werden. Im Sinne einer realistischer oder defensiv-neorealistischen [33] Abschreckungstheorie lässt [34] sich der Aufbau von Zweitschlagskapazitäten auch als Beitrag zu einem Gleichgewicht des Schreckens und einer aktiven Friedenssicherung deuten.
Bigotterie und Realismus
Die eigentliche Ironie liegt nicht im Militärischen, sondern im Politischen: Ausgerechnet jene Staaten, die ihre Militärpräsenz im Pazifik seit Jahren ausbauen und als Beitrag zur globalen "Stabilität" anpreisen, reagieren nun empört, wenn Peking Fähigkeiten demonstriert, über die sie selbst längst verfügen.
Die Folgen zeichnen sich ab: In Taipeh dürfte der Test die Furcht vertiefen, dass sich das Kräfteverhältnis zu Ungunsten der Insel verschiebt. In Washington wächst derweil der Druck, die U-Boot-Jagd und die Raketenabwehr auszubauen und Japan, Australien und die Philippinen militärisch enger einzubinden – die klassische Rüstungsspirale, die solche Demonstrationen regelmäßig beschleunigen, statt sie zu verhindern.
Der Juli-Test ist also weit mehr als ein erfolgreicher Raketenabschuss: Er macht Chinas nukleare Abschreckung zur vollständigen strategischen Realität. Dass die Unruhe in den westlichen Hauptstädten größer war als alles, was ein einzelner Einschlag im Pazifik rechtfertigt, zeigt: Dort hat man verstanden, was sich verschoben hat. Ein Land, dessen Atomwaffen einen Erstschlag überstehen, lässt sich nicht mehr erpressen. Ein Krieg gegen China ist seit diesem Juli eine andere, unkalkulierbarere Rechnung.
URL dieses Artikels: https://www.heise.de/-11377312
Erstmals stützt sich eine Mordanklage in Athen nur auf KI-Analysen. Doch die Technik hinterlässt Zweifel: Ein Beschuldigter saß zur Tatzeit in Haft.
Den Griechen steht der erste große KI-Prozess bevor. Ein aufsehenerregender Kriminalfall, bei dem sich die Anklage ausschließlich auf durch die künstliche Intelligenz gefundene Beweise stützt. Die fraglichen Taten und Verbrechen liegen sechzehn Jahre zurück.
Am 5. Mai 2010 demonstrierte gefühlt ganz Griechenland gegen die ersten Sparmaßnahmen, die der Staatspleite folgten. Die Gewerkschaften GSEE, ADEDY und PAME hatten zum Generalstreiktag mit einem Marsch zum Parlament am Syntagma-Platz aufgerufen. Rund 150.000 Menschen befanden sich demonstrierend im Zentrum Athens.
Drei Tote nach Brandanschlag von 2010
Doch nicht alle streikten. Im renovierten neoklassizistischen Gebäude der Marfin-Egnatia-Bank in der Stadiou-Straße 23 mussten die Bankangestellten zum Dienst antreten. Der Notausgang zum Hinterhof des Gebäudes war verriegelt, der Aufgang zum Flachdach auch.
Quer gegenüber war die Ianos-Buchhandlung geöffnet. Dorthin flüchtete gegen 13 Uhr der Journalist Ilias Provopoulos, dessen Kamera die wichtigsten Beweise liefern sollte. Wie er berichtete, kam es in der Nähe der Buchhandlung zu Vorfällen, bei denen Gruppen vermummter Männer mit der Polizei zusammenstießen. Daraufhin suchten er und andere Bürger in der Buchhandlung, die im ersten Stock ein Café beherbergt, Schutz vor dem Tränengas.
Es war 14:00 Uhr, als sich elf vermummte Männer vom Demonstrationsmarsch abspalteten und Molotowcocktails auf das Bankgebäude warfen. Die Schaufensterscheibe wurde mit einem Vorschlaghammer eingeschlagen. Brennbare Flüssigkeit wurde hineingegossen und trotz des Flehens der Bankangestellten wurden brennende Molotow-Cocktails hineingeworfen.
Der Eingang des dreistöckigen Gebäudes stand fast sofort in Flammen. Dichter, schwarzer Rauch erfüllte das gesamte Gebäude. Angestellte und Kunden im Erdgeschoss versuchten, sich in Sicherheit zu bringen.
Die Angestellten im obersten Stockwerk hatten keine Zeit mehr zur Flucht. Laut Zeitungsbericht waren die Zwischentüren der Stockwerke aus Angst vor einem Eindringen von Demonstranten in die Bank verschlossen worden. Angeliki Papathanasopoulou (32 Jahre, im vierten Monat schwanger), Epaminondas Tsakalis (36 Jahre) und Paraskevi Zoulias (35 Jahre) wurden tot geborgen. Sie waren im dritten Stock des Gebäudes von den Flammen eingeschlossen und erstickt.
Beweisfotos, die ohne KI nur Vermummte zeigen
Provopoulos gelangen bei mehr als 200 Digitalaufnahmen sechs entscheidende Fotos. Als Reporter mit Demonstrationserfahrung waren ihm die späteren Brandstifter frühzeitig aufgefallen. Er konnte sie keiner der ihm bekannten Gruppen zuordnen und drückte vom ersten Stock der Buchhandlung aus auf den Auslöser seiner Kamera.
Die Fotos gelangten noch am selben Nachmittag zu den Strafverfolgern. Diese konnten jedoch nicht viel damit anfangen. Denn die Abgebildeten waren vermummt.
Obwohl sich die Strafverfolger sechzehn Jahre lang um Aufklärung bemühten, kamen sie vor der Einführung der KI keinen Schritt weiter. Sie wussten lediglich, wer von den fotografierten Vermummten zur Gruppe gehörte.
Die Strafverfolger nummerierten sie: "8", der das Fenster einschlug, analog dann "2", der den Benzinkanister entleerte und ins Gebäude warf. "3", der das Feuer legte. "4", der neben den anderen stand, und so weiter.
Tatsächlich ging der Polizei vor einigen Jahren einer aus der Gruppe ins Netz. Nur wusste das damals niemand. Der Mann wurde wegen eines geplanten Bombenanschlags verhaftet. Dabei beschlagnahmten die Fahnder einen Laptop mit zahlreichen Fotos. Unter diesen Fotos war eine Gruppe von Freunden des Verhafteten im Urlaub.
Die Bilder waren rund ein Jahr vor den Ereignissen rund um die Marfin-Bank auf der Insel Ikaria entstanden. Zu Hilfe kam den Polizisten der als "griechisches FBI" genannten Spezialeinheit eine vor rund 15 Monaten am 8. April 2025 abgeschickte, verschlüsselte, anonyme Email.
Darin stehen die Namen von Verdächtigen und unter anderem:
"Herr Staatsanwalt, seit 16 Jahren trage ich ein Geheimnis mit mir herum, das mich nicht zur Ruhe kommen lässt. Ich sende es Ihnen, weil ich einerseits nicht an Gerechtigkeit im Jenseits glaube und andererseits es nicht ertragen kann, dass die Mörder auch heute noch ihr Leben weiterführen, als wäre nichts geschehen."
Der Fernsehsender Mega-TV zitiert zudem:
"Ich erwarte nichts Weiteres. Wenigstens trage ich nicht dieselbe Last. Ich habe gesagt, was ich für mich behalten hatte. Mal sehen, ob dieses neue FBI etwas bewirken kann oder nur das tut, was ihnen passt und einfach ist."
Die Beamten nutzten die KI zur Foto- und Videoanalyse. Videos vom 5. Mai 2010 wurden ebenso überprüft wie die Fotos von Provopoulos und auch die Fotos vom beschlagnahmten Laptop. Mittels KI wurden die Vermummungen entfernt und Gesichter rekonstruiert.
Die KI identifizierte zudem wiederkehrende Muster. Nummer "8", auch als "der Große" bezeichnet, hatte sowohl im Urlaub als auch auf der Demo einen Rucksack mit einem gemalten Logo der Punk-Gruppe Dead Kennedys. Zudem weisen die Fotos vom Rucksack gleiche Abriebmerkmale an den Reißverschlussführungen auf.
Das Gesicht von den Urlaubsfotos ist laut KI identisch mit einem möglichen rekonstruierten Gesicht des Vermummten vor der Marfin-Bank. Es handelt sich um einen 42-jährigen Mann, der nun in einem Hochsicherheitstrakt in Nafplio in U-Haft sitzt. Ihn belastet zudem die anonyme E-Mail-Nachricht, in der sein Name steht.
Ein weiterer 42-jähriger, von den Fahndern "Enaeritis" genannt, wurde auf gleiche Weise identifiziert. Auch bei ihm war der Rucksack im Urlaub und auf der Demo dabei. Zudem trug er laut KI die exakt gleichen Schuhe. Die beiden Rucksäcke wurden auch auf älteren Fotos der Verdächtigen aus dem Jahr 2008 identifiziert.
"Enaeritis" heißen in Griechenland spezialisierte Handwerker, die in großen Höhen (z. B. an Wohnhäusern, Strommasten, Bäumen) mit spezieller Sicherheitsausrüstung und Seilen, aber ohne Gerüste arbeiten. Die Dritte im Bunde der nun Verhafteten sitzt noch in Abschiebehaft im Vereinigten Königreich. Die 46-Jährige arbeitet am Gatwick-Airport in London, wohin sie ausgewandert war.
Bei ihr stützt sich die KI auf weniger Details bei der Kleidung oder Ausstattung. Einzig der Körpertyp und die Technik des geflochtenen Zopfs dienen den Beamten als Beweis. Sie selbst stimmt ihrer Auslieferung zu und ist zuversichtlich, ihre Unschuld beweisen zu können.
Wie treffsicher ist die KI?
Vonseiten der Anwälte der Verhafteten werden die KI-Beweise ernsthaft infrage gestellt. Die künstliche Intelligenz würde nicht die Präsenz der Angeklagten, sondern lediglich von ihnen zugeordneten Gegenständen beweisen, heißt es.
Hinsichtlich der wegen Verjährung übriger Straftaten einzig möglichen Anklage wegen Mordes gibt es offenbar noch ein weiteres Problem. Einer der beiden 42-jährigen, Polykarpos Georgiadis, wandte sich per Brief über die anarchistische Mediengruppe OmniaTV an die Öffentlichkeit.
Der bekannte Anarchist schreibt von einem Komplott. Er gibt zu, dass sein Name zweifelsfrei in der anonymen E-Mail steht. Allerdings gäbe es ein physisches Problem, das ihn als Täter ausschließe. Er habe vom August 2008 bis September 2013 im Zuchthaus Korydallos eingesessen [1] und könne deshalb unmöglich am 5. Mai 2010 bei der Brandstiftung dabei gewesen sein.
Die Anwälte der Beschuldigten sehen daher politische Motive hinter der aktuellen Strafverfolgung.
Unabhängig davon müssen Ermittler und Staatsanwalt den Richtern beweisen, dass die KI als Indizienlieferant glaubwürdig ist. Denn allein auf die anonyme E-Mail-Nachricht kann sich keine Anklage stützen.
Es dürfte angesichts der bereits jetzt bekannten Widersprüche ein interessanter Prozess werden. Zumindest für die Anordnung der Untersuchungshaft scheinen Haftrichter und Staatsanwalt der KI mehr zu vertrauen als den Daten der größten Haftanstalt des Landes.
URL dieses Artikels: https://www.heise.de/-11373023
Die Buchstaben AI umfliegen Haken und Warndreiecke.
(Bild: tadamichi/Shutterstock.com)
Ein IT-Forscher hat mit der chinesischen KI Kimi K3 mehrere Zero-Day-Lücken in der redis-Datenbank entdeckt. Updates bestätigen die Funde.
Die Entwickler der quelloffenen In-Memory-Datenbank redis haben aktualisierte Versionen veröffentlicht, die mehrere Schwachstellen darin schließen. Sie bestätigen damit Sicherheitslücken, die ein IT-Forscher mit der chinesischen KI Kimi K3 gefunden hat. Die steht in Konkurrenz zu den aktuellen Spitzenmodellen von OpenAI und Anthropic [1] und beweist damit nun, dass sie tatsächlich Schwachstellen aufspüren kann.
Der User „Chaofan Shou“ hat auf X [2] gepostet, dass er mit der KI des chinesischen Start-ups Moonshot AI in 90 Minuten insgesamt 19 Zero-Day-Schwachstellen in der bis dahin aktuellen Fassung 8.8.0 der redis-Datenbank gefunden hat. Kimi K3 hat dabei auch Proof-of-Concept-Code (PoC) erstellt, um das Ausnutzen der Lücken zu demonstrieren. Shou hat ein GitHub-Repository mit den PoCs [3] veröffentlicht.
In der Nacht zum Freitag hat das redis-Projekt nun mehrere aktualisierte Versionen veröffentlicht, die zumindest Teile der vorgestellten Sicherheitslecks stopfen. redis 8.8.1, 8.6.5, 8.4.5, 8.2.8, 7.4.10, 7.2.15 und 6.2.23 [4] bessern mehrere der Schwachstellen aus. Die Entwickler bestätigen damit die Sicherheitslücken, im Beispiel etwa für den Exploit „P88W“ [5] aus dem Schwachstellenrepository.
Updates zügig anwenden
Eine Einordnung des Schweregrads der Lücken sowie etwa CVE-Schwachstelleneinträge fehlen derzeit noch. Allerdings macht es der verfügbare Proof-of-Concept-Code Angreifern leichter, die Sicherheitslecks zu missbrauchen. IT-Verantwortliche sollten daher zügig auf die aktualisierte redis-Version ihres eingesetzten Entwicklungszweigs updaten. Quellcode steht bereit, die Linux-Distributionen dürften kurzfristig ebenfalls Aktualisierungen in der Softwareverwaltung bereitstellen.
Die Kimi-K3-KI von Moonshot AI erfährt eine große Nachfrage. Der Anbieter hat neue Abonnements aufgrund von GPU-Engpässen vorerst gestoppt. Der Beleg, dass Kimi K3 Schwachstellen aufspürt und Exploit-Code erzeugt, dürfte das Interesse daran weiter wachsen lassen. Das war bislang Domäne etwa von Anthropics Mythos oder Fable [6] oder OpenAIs Codex Security [7].
URL dieses Artikels: https://www.heise.de/-11377360
Im App Store landen immer mehr Apps, die per Prompt entwickelt wurden. Claude Code macht es Interessierten noch ein bisschen einfacher.
Anthropic hat die macOS-Version von Claude Code aufgerüstet: Entwickler von iOS-Apps bekommen nun die Möglichkeit, das Ergebnis ihrer Prompt-Arbeiten direkt in einem Simulator-Fenster einzusehen, wie man es sonst von Xcode kennt. Aktuell wird die Integration noch als Beta tituliert, ist aber bereits clever umgesetzt: Computer Use [1], also die Erlaubnis für Claude zur direkten Steuerung des Mac, ist dafür nicht notwendig.
Claude Code CLI braucht weiter Computer Use
Technisch bedient sich Claude Code für macOS [2] beim in Xcode integrierten iOS-Simulator. Entsprechend muss Apples Entwicklungsumgebung [3] installiert sein, was bei den meisten Developern standardmäßig der Fall sein dürfte. Mit aktivem Simulator kann Claude Apps, die es laufen lässt, sehen und mit ihnen interagieren [4] – sowie die Prompt-Schritte weiter iterieren, bis das Ergebnis stimmt. Der Nutzer kann den iOS-Simulator jederzeit auch selbst nutzen, um auszuprobieren, wie sich eine App aktuell anfühlt.
Wer Claude Code per Kommandozeile im Terminal (Claude Code CLI) nutzt, ist allerdings weiterhin auf Computer Use angewiesen. Dabei bedient der Programmieragent die Maus. Sollte Xcode nach Installation keine aktiven Simulatoren anzeigen, muss zuerst die notwendige Runtime heruntergeladen werden [5] – das geht entweder in den Xcode-Einstellungen oder über das Kommando xcodebuild -downloadPlatform iOS im Terminal.
Großer Vibe-Coding-Hype im App Store
Der direkt in Claude Code integrierte Simulator dürfte die Erstellung von iOS-Apps per Vibe-Coding noch einfacher machen, als dies bislang schon möglich ist. Apples App Store wird seit der Verbreitung von Coding-Agenten wie Claude Code, OpenAI Codex oder Gemini Code Assist mit immer mehr neuen Apps konfrontiert [6], deren Qualität manchmal zu wünschen übrig lässt, da nun auch Nutzer mit wenig bis gar keiner Programmiererfahrung leicht eigene Anwendungen entwickeln können. Apple selbst integriert Vibe-Coding-Werkzeuge auch schon direkt in Xcode [7].
Erste Hinweise zur Verwendung des iOS-Simulators in Claude Code für macOS beschreibt Anthropic in einem neuen Supportdokument [8]. Achten sollte man unter anderem darauf, dass Claude Code den Simulator zwischenzeitlich automatisch herunterfährt und die Zahl der Sessions beschränkt. Auch muss man die notwendigen Permissions beachten, damit der Coding-Agent mit dem virtuellen iPhone agieren kann.
URL dieses Artikels: https://www.heise.de/-11375592
Die neue, auf Racket basierende Sprache Rhombus erlaubt mächtige, flexible und saubere Makroprogrammierung bei einfach zu lesender Syntax.
Traditionell müssen sich Programmierer beim Thema Makroprogrammierung zwischen zwei Extremen entscheiden: einem mächtigen Makrosystem oder einer leicht lesbaren Syntax. Die neue Sprache Rhombus, am 22. Juni 2026 in Version 1.0 erschienen, will beides gleichermaßen: einen einsteigerfreundlichen Blick auf einen alten Makro-Syntax-Streit und eine moderne Antwort darauf.
Rhombus [1] ist stabil und basiert auf der ausgereiften Racket-Plattform, ist als Sprache aber noch jung und hat ein kleines Ökosystem. Also eher etwas zum Erkunden als eine naheliegende Wahl für das nächste Produktionsprojekt.
Kurz gefasst ist Rhombus eine universelle, dynamische Sprache [5] mit funktionalem Kern. Daten sind standardmäßig unveränderlich, Funktionen und Ausdrücke stehen im Mittelpunkt und Pattern Matching (das Verzweigen anhand der Struktur von Daten) zieht sich durch die ganze Sprache. Dynamisch heißt dabei, dass Typen grundsätzlich zur Laufzeit geprüft werden, wie in Python oder Ruby. Zusätzlich bringt Rhombus ein vollwertiges Klassensystem für objektorientiertes Arbeiten und optionale, geprüfte Typangaben mit. Ob Entwicklerinnen und Entwickler funktional, objektorientiert oder gemischt arbeiten wollen, bleibt ihnen überlassen.
Konzeptionell ruht Rhombus auf drei technischen Schichten.
Shrubbery Notation: die Oberflächensyntax, also das, was man tippt, ist einrückungs- und whitespace-sensitiv, ähnlich wie bei Python. Ein Doppelpunkt : öffnet einen Block, ein senkrechter Strich | markiert Alternativen, und die Einrückung gruppiert zusammengehörigen Code. Diese Schicht ist bewusst generisch und wiederverwendbar gehalten.
Enforestation: eine Variante des sogenannten Pratt-Parsings (ein Verfahren, das Operator-Vorrang auflöst, also etwa weiß, dass Punkt- vor Strichrechnung kommt). Der Clou: Dieses Parsing läuft während der Makro-Expansion (also während die Makros den Code umschreiben). Dadurch können selbst definierte Infix-Operatoren echte Vorrangregeln haben und trotzdem ins saubere Makrosystem eingreifen.
Binding Spaces (mehrere Namensräume): Derselbe Bezeichner kann je nach Kontext etwas anderes bedeuten, etwa einen Wert, ein Bindemuster, eine Annotation (Typangabe) oder einen Operator.
Die Besonderheit: Vieles, was in anderen Sprachen fest in den Compiler eingebaut ist, ist in Rhombus eine Bibliothek: Pattern Matching, Klassen, typ-artige Annotationen und neue Kontrollstrukturen. Dieses Konzept ist dann für die einfach zu handhabende Markoprogrammierung entscheidend.
Technisch steht Rhombus auf solider Grundlage: Es läuft eben auf der Racket-Plattform, kompiliert über Chez Scheme (eine besonders schnelle Scheme-Implementierung) zu nativem Maschinencode und nutzt die etablierten Racket-Werkzeuge. Dabei ist es quelloffen und kostenlos, wahlweise unter der MIT- oder der Apache-2.0-Lizenz. Dateien tragen die Endung .rhm und beginnen mit der Zeile #lang rhombus (analog zu #lang racket).
Rhombus verhält sich also zu Racket wie Kotlin zu Java oder Elixir zu Erlang. Eine modernere Sprache auf bewährter Laufzeitumgebung.
Ein Rundgang durch den Code
Wer schon einmal programmiert hat, erkennt das meiste sofort wieder. So sieht zum Beispiel Hallo-Welt in Rhombus aus:
#lang rhombus
println("Hallo, Bob!")
Die erste Zeile #lang rhombus legt fest, in welcher Sprache die Datei geschrieben ist, danach folgt direkt der Code. Auch eine kleine Funktion bleibt übersichtlich:
Eine Funktion beginnt mit fun, der Doppelpunkt öffnet ihren Rumpf, die Einrückung füllt ihn (+& verbindet dabei zwei Texte). Heraus kommt „Hallo, Bob!“. Alles wirkt wie eine ganz gewöhnliche, moderne Sprache, ungefähr im Stil von Python oder Swift.
Werte definiert man mit def. Beim Rechnen lohnt ein genauer Blick: +& verbindet Text, + rechnet mit Zahlen.
#lang rhombus
def name = "Welt"
def jahr = 2026
println("Hallo, " +& name +& "!")
println(jahr + 1)
Ausgabe (als Kommentar):
// Hallo, Welt!
// 2027
Eine Funktion, wie oben im Beispiel gruesse, gibt automatisch ihren letzten Ausdruck zurück, ein return ist nicht nötig. Neu ist hier die ::-Schreibweise: Sie hängt an einen Parameter eine geprüfte Annotation, also eine Art Typangabe. a :: Int bedeutet, dass a eine ganze Zahl sein muss, und :: Int hinter der Parameterliste sagt dasselbe über den Rückgabewert. Passend zum dynamischen Charakter prüft Rhombus solche Annotationen zur Laufzeit; ein statisches Typsystem ist es also nicht.
#lang rhombus
fun addiere(a :: Int, b :: Int) :: Int:
a + b
println(addiere(20, 22))
Ausgabe: // 42
Listen schreibt man in eckigen Klammern. Die for-Form kann zweierlei: eine neue Liste aufbauen (eine Comprehension) oder mit einem Akkumulator einen Wert aufsummieren. Ein Akkumulator ist dabei eine Sammelvariable, die in jedem Durchlauf einen neuen Wert erhält und so das Zwischenergebnis über die Durchläufe hinweg fortschreibt:
#lang rhombus
def zahlen = [1, 2, 3, 4, 5]
def quadrate = for List (z: zahlen):
z * z
println(quadrate)
def summe = for values(akku = 0) (z: zahlen):
akku + z
println(summe)
Ausgabe:
// [1, 4, 9, 16, 25]
// 15
Apropos Zahlen: Rhombus rechnet exakt. (3 + 4) / 2 ergibt nicht die Gleitkommazahl 3.5, sondern denselben Wert als exakten Bruch 7/2.
Pattern Matching, also das Verzweigen anhand der Struktur von Daten, durchzieht die ganze Sprache. Mit match prüft man der Reihe nach mehrere Muster, jeweils hinter einem |. Das erste passende Muster gewinnt. Beachten Sie das dritte Muster [x, y]: Es trifft nur auf Listen mit genau zwei Elementen zu und zerlegt sie gleich in x und y.
#lang rhombus
fun beschreibe(ding):
match ding
| 0: "die Null"
| n :: Int: "die Zahl " +& n
| [x, y]: "ein Paar: " +& x +& " und " +& y
| other: "etwas anderes"
println(beschreibe(0))
println(beschreibe(42))
println(beschreibe([3, 4]))
println(beschreibe("hallo"))
Ausgabe:
// die Null
// die Zahl 42
// ein Paar: 3 und 4
// etwas anderes
Schön zu sehen: Die Muster mischen konkrete Werte (0), Annotationen (n :: Int) und Strukturen ([x, y]) in einer einheitlichen Schreibweise.
Pattern Matching in der IDE von DrRacket: Die Funktion beschreibe prüft die Muster der Reihe nach, wobei das erste passende gewinnt.
Auch ein einheitliches Klassensystem gehört dazu. Eine Klasse definiert man kurz und bündig, und dasselbe Muster, mit dem man Objekte erzeugt, lässt sich auch zum Zerlegen verwenden:
#lang rhombus
class Rechteck(breite, hoehe)
fun flaeche(r :: Rechteck):
r.breite * r.hoehe
def r = Rechteck(10, 5)
println(r)
println(flaeche(r))
def Rechteck(b, h) = r
println("Breite: " +& b +& ", Hoehe: " +& h)
Ausgabe:
// Rechteck(10, 5)
// 50
// Breite: 10, Hoehe: 5
Die vorletzte Zeile ist bemerkenswert: def Rechteck(b, h) = r benutzt den Klassennamen nicht zum Erzeugen, sondern zum Auseinandernehmen eines Rechtecks. Genau dafür sorgen die erwähnten Binding Spaces, in denen Rechteck je nach Position etwas anderes bedeutet.
Ein weiteres Element ist die Ellipse ..., mit der sich Wiederholungen kompakt ausdrücken lassen. Das Muster [x, ...] bindet alle Elemente einer Liste auf einmal, und beim Aufbauen verteilt sich die Rechnung elementweise:
Über diese Beispiele hinaus bietet Rhombus generische, unveränderliche funktionale Datenstrukturen mit guter Laufzeitkomplexität (etwa Anhängen in O(log n), also auch bei vielen Elementen schnell) und hierarchische Namensräume. Mitgeliefert sind laut Homepage Bibliotheken für HTML, JSON, XML, HTTP, Zeichnen, GUIs, Parsing und FFI-Bindings (also Anbindungen an fremde, meist C-Bibliotheken).
Bis hierhin sieht Rhombus aus wie eine moderne, aufgeräumte Sprache. Der eigentliche Clou kommt mit den Möglichkeiten der Makroprogrammierung.
Das Problem mit den Makros
Für Entwicklerinnen und Entwickler, die in Sprachen wie PHP, Java oder Ruby zu Hause sind, ist Makro vielleicht nur ein vages Wort. Und falls sie aus der C- oder C++-Welt kommen: Deren #define-Makros sind nur simple Textersetzung und etwas ganz anderes als das, worum es bei Rhombus geht.
In den allermeisten Sprachen steht der Vorrat an Bausteinen fest. Schlüsselwörter wie if, for oder class und Operatoren wie + oder * hat die Sprachdefinition ein für alle Mal festgelegt. Anwender kombinieren diese Bausteine zu Programmen, aber sie können keine neuen erfinden. Wer ein eigenes Schlüsselwort oder einen eigenen Operator verwenden möchte, müsste dafür den Compiler der Sprache selbst umbauen.
Ein Makro durchbricht diese Grenze. Es ist Code, der anderen Code erzeugt oder umschreibt, und zwar zur Compile-Zeit, also bevor das fertige Programm läuft. Anders gesagt: ein kleines Programm, dessen Ausgabe wiederum Programmtext ist. Etwas in dieser Richtung kennen manche von Ruby, wo sich Methoden mit Metaprogrammierung zur Laufzeit erzeugen lassen. Doch Rubys Ansatz hat zwei Grenzen. Erstens passiert das zur Laufzeit. Zweitens erzeugen Entwickler damit nur Methoden und Objekte innerhalb von Rubys fester Syntax. Ein neues Schlüsselwort, einen eigenen Operator oder eine eigene Kontrollstruktur lässt sich so nicht hinzufügen. Die Syntax selbst bleibt unantastbar.
Anders bei Lisp: Lisp ist eine der ältesten Programmiersprachen überhaupt, Ende der 1950er-Jahre entstanden, und Stammvater einer ganzen Sprachfamilie, zu der auch Scheme und Racket gehören. Berühmt, manche sagen berüchtigt, ist sie für zwei Dinge: ihr extrem mächtiges Makrosystem und ihre vielen Klammern.
Lisp-Makros laufen im Unterschied zu Ruby zur Compile-Zeit, bevor ein Programm überhaupt startet. Das Makro formt das Programm schon in dieser Phase um. Der Compiler liest zuallererst den Quelltext und baut daraus einen Syntaxbaum. Das ist eine strukturierte Darstellung des Programms, die festhält, was ein Ausdruck ist und was zusammengehört. Lisp-Makros arbeiten auf diesem Baum und verstehen also die Struktur des Programms. Dadurch können sie echte neue Syntax hinzufügen, eigene Operatoren und Schlüsselwörter eingeschlossen.
Sie sind außerdem hygienisch, verwechseln also nie versehentlich Variablennamen aus Ihrem Code mit anderen, ein Stolperstein, an dem simple Textersetzung gerne scheitert. So lässt sich die Sprache gefahrlos und ohne jeden Compiler-Umbau per Bibliothek erweitern.
Die jahrzehntealte Zwickmühle
Der Preis für diese Macht ist die berüchtigte Klammerflut, die sogenannte S-Expression-Syntax (von „symbolic expressions“, symbolische Ausdrücke). In Lisp wird alles als Liste in Klammern geschrieben, und die Operation steht vorne. Statt 1 + 2 schreibt man (+ 1 2), statt f(x) schreibt man (f x). Das gilt ausnahmslos, auch für das, was anderswo eigene Schlüsselwörter sind. Aus der Bedingung x > 0 wird (> x 0), und sogar ein if ist nur eine Liste: (if Bedingung Dann-Zweig Sonst-Zweig). Weil sich diese Listen ineinander verschachteln, türmen sich die Klammern. „Wenn x größer als 0, dann f(x), sonst g(x)“ sieht so aus: (if (> x 0) (f x) (g x)).
Genau das ermöglicht aber erst die Makro-Macht von Lisp: Es gibt keine Sondersyntax. Ein if sieht aus wie ein Funktionsaufruf, ein Funktionsaufruf wie eine Rechnung, alles ist dieselbe Art verschachtelter Liste. Programm und Datenstruktur sehen nicht nur ähnlich aus, sie sind dasselbe. Ein Makro bekommt den Code einfach als verschachtelte Liste und darf ihn umbauen wie beliebige andere Daten. Klammern und Makro-Macht bedingen einander.
Für die meisten Menschen ist diese Schreibweise schwer zu lesen. Es gab über die Jahre etliche Versuche, eine gewohnte Infix-Syntax (also x > 0 statt (> x 0)) auf Lisp zu setzen, doch fast immer ging dabei die Makro-Macht verloren.
Das Highlight von Rhombus: die Sprache selbst erweitern
Das Versprechen von Rhombus ist nun: volle Makro-Macht bei normaler Syntax. Das Konzept basiert auf der Struktur der Sprache, dass alle Bausteine (wie Klassen, match, die ::-Annotationen usw.) Bibliotheken sind und nicht in Stein gemeißelte Compiler-Magie. Was Bibliotheken können, können Entwicklerinnen und Entwickler auch.
Ein Beispiel wäre ein eigener Operator: +/+ als Durchschnitt zweier Zahlen. In vielen verbreiteten Sprachen geht das gar nicht, in anderen etwa Swift oder Haskell nur in engen Grenzen. In Rhombus schreibt man ihn selbst:
#lang rhombus
operator (a +/+ b):
~stronger_than: +
(a + b) / 2
println(10 +/+ 20)
println(3 +/+ 4)
println(2 + 10 +/+ 20)
Ausgabe:
// 15
// 7/2
// 17
Hier wird das exakte Rechnen sichtbar: 3 +/+ 4 ergibt 7/2, den exakten Bruch statt einer Gleitkommazahl. Wichtiger noch: +/+ ist ein vollwertiger, selbst erzeugter Infix-Operator. Trifft er auf andere Operatoren, braucht er Vorrangregeln. Die gibt man in Rhombus relativ an, mit ~stronger_than oder ~weaker_than, im Beispiel mit ~stronger_than: +. Genau deshalb rechnet Rhombus 2 + 10 +/+ 20 als 2 + (10 +/+ 20) und gibt 17 aus. Ohne diese Vorrangangabe würde Rhombus die Mischung nicht raten, sondern eine ausdrückliche Klammerung verlangen.
Ein selbst definierter Operator +/+ in DrRacket: 3 +/+ 4 ergibt den exakten Bruch 7/2, und dank der Vorrangregel ~stronger_than ergibt 2 + 10 +/+ 20 die 17.
Noch eine Stufe tiefer geht ein echtes Makro, also ein eigenes Schlüsselwort, das zur Compile-Zeit umgeschrieben wird. Hier verwandelt zweimal e schon vor der Ausführung den Ausdruck in e + e:
import: rhombus/meta open holt im Listing die Werkzeuge zum Schreiben von Makros. expr.macro definiert ein neues Schlüsselwort für den Ausdruck. Die einfachen Anführungszeichen '...' umschließen Syntax, nicht Text, und $e ist ein Platzhalter für ein Stück Code. Das Makro sagt: Wo immer zweimal e steht, ersetze es vor dem Lauf durch e + e. Das ist keine Textersetzung, sondern eine Umformung auf der echten Programmstruktur. Und sie ist hygienisch, verwechselt also keine Variablennamen aus Makro und Aufrufstelle.
Ein eigenes Makro in DrRacket: zweimal 21 wird zur Compile-Zeit zu 21 + 21 und ergibt 42.
operator und expr.macro sind keine Sonderfunktionen, sondern derselbe Mechanismus, mit dem auch class, match und for gebaut sind. Sie arbeiten mit denselben Mitteln wie die Sprachautoren. An genau dieser Kombination scheiterten andere Versuche jahrzehntelang.
Ausprobieren: DrRacket und Kommandozeile
Am bequemsten startet man für Rhombus mit DrRacket, der etablierten, seit Jahren gepflegten, grafischen und integrierten Entwicklungsumgebung (IDE) des Racket-Projekts. Ursprünglich für die Lehre entworfen, gilt sie als besonders einsteigerfreundlich. DrRacket vereint zwei Bereiche in einem Fenster: Oben schreibt man im Editor das Programm, ein Klick auf „Run“ führt es aus. Unten erscheint eine interaktive Konsole (REPL, Read-Eval-Print-Loop), in der man nach dem Lauf einzelne Ausdrücke ausprobieren kann. Dazu kommen Debugger, Syntaxprüfung und eine direkte Anbindung an die Dokumentation.
DrRacket mit dem Hallo-Welt-Programm: oben der Editor, unten die REPL mit der Ausgabe. Ein Klick auf „Run“ startet das Programm.
Rhombus-Dateien öffnet man in DrRacket genau wie Racket-Dateien: Datei mit #lang rhombus am Anfang und der Endung .rhm laden, „Run“ klicken, fertig. Wer lieber im Terminal arbeitet, ruft schlicht racket datei.rhm auf.
Für die Installation gibt es mehrere Wege. Am unkompliziertesten lädt man von der Rhombus-Homepage [6] das fertige Komplettpaket „Combined Rhombus + Racket Install“ herunter, ein Installer-Image, das Rhombus, Racket und die DrRacket-IDE in einem Rutsch einrichtet. Fertige Installer gibt es für Windows, macOS und Linux, jeweils als 64-Bit-Version für Intel/AMD und ARM; für Linux zusätzlich in 32-Bit-Varianten.
Das Paket-Ökosystem ist dasselbe wie bei Racket, wobei das Kommandozeilenwerkzeug raco heißt. Ein Programm lässt sich als fertige Anwendung weitergeben. raco exe datei.rhm übersetzt es in eine eigenständige, nativ kompilierte Datei, und raco distribute ordner datei bündelt diese zusammen mit der nötigen Laufzeit in einen Ordner, den man auf andere Rechner mit demselben Betriebssystem kopieren kann. Dort startet das Programm dann ohne installiertes Racket oder Rhombus.
Dabei handelt es jedoch nicht um eine einzelne, statisch gelinkte Datei wie bei Go oder Rust. Die Racket-Laufzeit ist komplett dabei, weshalb schon ein Hallo-Welt-Programm auf einige Megabyte kommt. Ein Build ist plattformgebunden, universelle Binaries für alle Systeme gibt es nicht.
Technisch perfekt, Verbreitung fragwürdig
So beeindruckend die Technik ist, ein paar Vorbehalte gehören dazu. Rhombus ist mit Version 1.0 brandneu, und das Ökosystem noch klein. Die realistische, den Einsatz betreffende Frage ist also weniger, was die Sprache kann, als ob sie Verbreitung findet. Das Team selbst gibt sich nicht unkritisch und nennt die Shrubbery-Notation ausdrücklich „nicht perfekt“. Und der vielleicht größte Schatten: Racket selbst hat es trotz jahrzehntelanger technischer Brillanz nie in den Mainstream geschafft. Rhombus erbt diese Eigenschaften mitsamt dem Risiko.
Auf der Habenseite steht dafür echte technische Reife. Version 1.0 verspricht eine Stabilität und Pflege auf dem Niveau, das Racket seit Jahrzehnten bietet. Rhombus ist also kein Wochenend-Experiment, sondern baut auf einer Basis auf, die sich lange bewährt hat.
Ein persönlicher Vorbehalt zum Schluss: Man kann auch ohne Makros glücklich und produktiv programmieren. Die allermeisten Programme dieser Welt sind ohne selbst gebaute Syntax entstanden, und ihre Autoren haben nichts vermisst. Ein mächtiges Werkzeug verführt auch dazu, es überall einzusetzen. Wer einen Hammer in der Hand hält, sieht schnell in jedem Problem einen Nagel, und ein Makro, das sich eine eigene Sprache erfindet, kann ein Projekt ebenso gut in private Dialekte zersplittern, die außer dem Autor niemand mehr flüssig liest. Die eigentliche Kunst liegt deshalb nicht darin, gute Makros zu schreiben, sondern zu wissen, wann man es besser lässt.
URL dieses Artikels: https://www.heise.de/-11368404
Schon Ende Juni zeigte sich Github überfordert mit der großen Menge an Bug-Reports, die bei dem Unternehmen mittlerweile aufgrund des Einsatzes moderner KI-Tools in der Schwachstellenforschung eintreffen. Jetzt hat der Plattformbetreiber sein Bug-Bounty-Programm überarbeitet, um dieser Entwicklung zu begegnen. Viele Forscher erhalten damit künftig geringere Prämien. Doch das trifft nicht auf alle zu.
Wie Github in einer Ankündigung schildert, will das Unternehmen in Zukunft vor allem jene Sicherheitsforscher belohnen, die wiederholt besonders hochwertige Berichte einreichen und sich bei der Koordination als entsprechend kompetent erweisen.
Forscher in dieser Kategorie können auf Basis einer Einladung einem VIP-Programm beitreten und profitieren daraufhin von höheren Prämien, schnelleren Reaktionszeiten und einer engeren Zusammenarbeit mit dem Security-Team von Github. Die Auszahlungen richten sich wie gewohnt nach dem Schweregrad der jeweiligen Funde:
Niedig: 1.000 US-Dollar
Mittel: 7.500 US-Dollar
Hoch: 20.000 US-Dollar
Kritisch: 30.000 US-Dollar oder mehr
Neulinge müssen sich erst beweisen
Damit bleiben die Auszahlungen für VIP-Forscher auf ähnlich hohem Niveau wie vor der Änderung. Wer nicht zum VIP-Kreis gehört, muss hingegen mit deutlich geringeren Auszahlungen rechnen. Für gemeldete Lücken gibt es dann 10.000 US-Dollar bei kritischem, 5.000 US-Dollar bei hohem, 2.000 US-Dollar bei mittlerem und 250 US-Dollar bei niedrigem Schweregrad.
Um sich für das VIP-Programm zu qualifizieren, müssen Forscher vorab mindestens eine kritische, zwei hochschwere, vier mittelschwere oder sieben geringfügige Lücken gemeldet haben. Zudem wird die Anzahl der noch nicht abgeschlossenen Fälle, die neue Forscher einreichen dürfen, auf vier begrenzt. Das soll verhindern, dass Neulinge das Programm mit KI-Meldungen fluten, ihnen aber zugleich genug Spielraum gewähren, um ihre Kompetenz unter Beweis stellen zu können.
Github will das Rauschen reduzieren
"Die wesentliche Veränderung liegt hier in der Art der Anreize: Man verdient nicht mehr, indem man mehr Meldungen einreicht. Man verdient mehr, indem man bessere Meldungen einreicht", erklärt Github. Das Unternehmen will mit seiner Änderung nach eigenen Angaben "das Rauschen reduzieren", um sich "auf das Signal konzentrieren" und Forschern ein Programm bieten zu können, "an dem sie gerne teilnehmen".
Die neuen Regeln greifen ab dem 27. Juli. Vor diesem Datum eingereichte Meldungen werden noch nach dem alten Regelwerk verarbeitet und vergütet. Nähere Details zu Githubs Bug-Bounty-Programm sind auf Hackerone zu finden.
Andere Softwareprojekte sind ebenfalls zunehmend von massenhaft eingereichten KI-Bug-Reports überfordert. Teilweise haben diese ihre Bug-Bounty-Programme in den letzten Monaten eingestellt oder pausiert, um die Anreize zu verringern und die Entwicklerteams zu entlasten.
FreshRSS 
