alexi.sh
Alle ArtikelBrowser-SicherheitNetzwerk-PrivatsphäreDatenschutz-ToolsBedrohungsmodellierungKI-ProgrammierungDev-Tools

alexi.shForschung

browser-privacy

WebKit JIT-Benchmarks 2026: vier Jahre nach dem Lockdown-Modus

PrivSec Lab15 Min. Lesezeit
Makroaufnahme einer Leiterplatte mit leuchtenden Leiterbahnen — Darstellung der JIT-Kompilierungspipeline

Frische Speedometer 3.0, JetStream 2 und MotionMark Zahlen auf iPhone 15 und 16 — Normalmodus vs. Lockdown-Modus. Wie sich WebKits JIT von iOS 16 zu iOS 18 entwickelt hat und wo der Kompromiss heute steht.

Inhaltsverzeichnis


Einführung in die JIT-Kompilierung: wie JavaScriptCore funktioniert

Die Ausführung von JavaScript in WebKit folgt keinem einzigen Pfad. JavaScriptCore (JSC) — Apples JavaScript-Engine, die Safari und jeden Browser auf iOS antreibt — verwendet eine vierstufige Ausführungspipeline, wobei jede Stufe die Startkosten gegen den maximalen Durchsatz eintauscht.

LLInt (Low-Level Interpreter) führt Bytecode direkt aus. Er startet schnell, erfordert keine Maschinencode-Generierung und bietet keine JIT-spezifische Angriffsfläche. Jede Funktion beginnt hier.

Baseline JIT kompiliert Bytecode in nativen Maschinencode mit minimaler Optimierung, nachdem eine Funktion eine bestimmte Anzahl von Malen ausgeführt wurde (die "Aufwärmschwelle"). Es erzeugt unoptimierten Maschinencode schnell — typischerweise innerhalb von Mikrosekunden — und eliminiert den Interpreter-Overhead für häufig aufgerufene Funktionen.

DFG (Data Flow Graph) JIT greift ein, nachdem eine Funktion viele Male mehr ausgeführt wurde. Es erstellt einen Datenflussgraphen des Programms, leitet Typen ab und wendet klassische Compiler-Optimierungen an: Entfernung toten Codes, konstante Faltung, Inline-Caching und Registerzuweisung. Das Ergebnis ist wesentlich schnellerer nativer Code als der von Baseline JIT erzeugte.

FTL (Faster Than Light) JIT ist die oberste Stufe. Es verwendet die von LLVM abgeleitete B3 (Bare Bones Backend) Kompilierung für die heißesten Codepfade. FTL-Ausgaben nähern sich der Leistung von kompiliertem C bei rechenintensiven Arbeitslasten und sind der Hauptgrund, warum Safari einige Spitzen-Durchsatz-Benchmarks auf Apple Silicon dominiert.

Der Tier-Up-Prozess ist für den Entwickler transparent. JSC überwacht die Ausführungszählungen und befördert Funktionen die Leiter hinauf, wenn es gerechtfertigt ist. Der praktische Effekt: Lang laufende JS-Anwendungen (komplexe SPAs, Spiele, Datenvisualisierung) profitieren enorm von DFG und FTL, während kurze Skripte möglicherweise nie LLInt verlassen.

Der Lockdown-Modus schneidet all dies auf der Baseline-Stufe ab. Wenn der Lockdown-Modus aktiv ist, kehrt JSC zur reinen Interpreter-Ausführung zurück. Funktionen steigen nie auf. Die Leistungsgrenze sinkt stark.


Warum JIT ein Sicherheitskompromiss ist

Die JIT-Kompilierung ist das komplexeste Subsystem in jeder JavaScript-Engine und historisch das am meisten ausgenutzte. Das Kernproblem: JIT-Compiler erzeugen zur Laufzeit ausführbaren nativen Code aus von Angreifern kontrollierten Eingaben (dem JavaScript). Jeder Fehler in der JIT-Pipeline, der es einem Angreifer ermöglicht, den generierten Maschinencode zu beeinflussen, ist potenziell eine Schwachstelle für die Ausführung von Remote-Code.

CVE-Geschichte in WebKit JIT (2020–2026)

Das Muster ist über das sechsjährige Fenster hinweg konsistent:

  • 2020: WebKit JIT war für mehrere CVEs in iOS Zero-Days verantwortlich, die in freier Wildbahn gemeldet wurden. Die Zerodium-Preisliste für vollständige WebKit-Exploits erreichte 500.000 USD — ein Proxy-Indikator für den Wert der Angriffsfläche.
  • 2021: Project Zero veröffentlichte Forschungsergebnisse zu JSC-Typverwirrungsfehlern, die durch die DFG-Stufe ausgelöst wurden — insbesondere im NumberToString-Spekulationspfad. Zwei davon wurden in iOS-Exploit-Ketten eingesetzt.
  • 2022: iOS 16 wurde mit dem Lockdown-Modus ausgeliefert. Apples Sicherheitsnotizen für dieses Jahr listeten 14 WebKit-Schwachstellen auf, von denen mehrere mit JIT in Verbindung standen. Der Lockdown-Modus wurde ausdrücklich entwickelt, um die JIT-Angriffsfläche zu neutralisieren.
  • 2023: CVE-2023-23529 (in freier Wildbahn ausgenutzt, gemeldet von Clément Lecigne bei Google TAG). WebKit-Typverwirrung, JIT-adjacent. Gepatcht in Safari 16.3.1. iOS 16.3.1.
  • 2024: CVE-2024-23222 — JSC-Typverwirrung, in freier Wildbahn vor dem Patch ausgenutzt. Ein Muster, das sich im Kalenderjahr dreimal mehr über WebKit und JSC wiederholte.
  • 2025–2026: Exploit-Broker-Listings für vollständige WebKit-iOS-Exploits stabilisierten sich bei 2–3 Millionen USD auf großen Märkten (Zerodium, private Broker), was zeigt, dass trotz Härtung die Kosten gestiegen sind, JIT jedoch weiterhin wirtschaftlich attraktiv für staatliche Werkzeuge bleibt.

JIT-Spray-Mechanik

JIT-Spray ist eine Code-Injektionstechnik, die von Angreifern gewählte Byte-Sequenzen in JIT-kompilierten Code einbettet. Durch das Erstellen von JavaScript, das bestimmte Gleitkommakonstanten oder unmittelbare Werte verwendet, kann ein Angreifer dafür sorgen, dass der JIT-Compiler Byte-Sequenzen ausgibt, die, wenn sie an einem Offset interpretiert werden, gültigen Shellcode darstellen.

Moderne von WebKit angewandte Abschwächungen umfassen:

  • Gigacage: ein Schutzbereichssystem, das JIT-Speicher von Heapspeicher isoliert und die Annahmen des Angreifers über das Speicherlayout bricht.
  • Probabilistische JIT-Härtung: zufälliges Einfügen von Fallen zwischen Codeblöcken.
  • JIT-Berechtigungsgating: auf iOS ist die dynamic-codesigning-Berechtigung erforderlich, um beschreibbare+ausführbare Speicherseiten zu erstellen. Nur JIT-berechtigte Prozesse können dies tun — was den Explosionsradius begrenzt, wenn JIT in einem sandboxed Browser-Prozess ausgenutzt wird.
  • Nur ausführbar (XOM): auf A15+ Hardware werden JIT-Speicherseiten als nur ausführbar markiert, was den Angreifer daran hindert, JIT-Ausgaben zu lesen, um Shellcode zu lokalisieren.

Trotz dieser Abschwächungen bleibt JIT das Ziel mit dem höchsten Wert in der mobilen Browser-Ausnutzung. Es vollständig zu deaktivieren — wie es der Lockdown-Modus tut — entfernt die Angriffsfläche, anstatt zu versuchen, sie zu härten.


Lockdown-Modus 2022: die Basislinie

Als Apple den Lockdown-Modus in iOS 16 (September 2022) einführte, war der JIT-Kompromiss sofort und messbar. Tests auf einem iPhone 13 bei der Markteinführung ergaben die folgenden Ergebnisse bei periodengerechten Benchmarks:

BenchmarkNormalmodusLockdown-ModusDelta
Octane 2.0~56.000~2.800-95%
Speedometer 2.0~260~91-65%
MotionMark 1.2~750~595-20%
JetStream 2.0~150~18-88%

Der Octane-Zusammenbruch war der dramatischste: Octane ist fast ausschließlich ein JIT-Durchsatztest, sodass die Rückkehr zur reinen Interpreter-Ausführung die Punktzahl zerstörte. Speedometer 2.0, das DOM-Interaktionen und Framework-Rendering zusätzlich zum JS-Durchsatz testet, zeigte einen moderateren, aber immer noch schweren Rückgang.

MotionMark — das CSS-Animationen, SVG-Rendering und Canvas testet — hielt sich relativ gut, da es weniger von der JS-Ausführungsgeschwindigkeit und mehr von GPU-Kompositionspfaden abhängt, die der Lockdown-Modus nicht deaktiviert.

Diese Basislinie von 2022 war wichtig: Sie setzte einen konkreten Leistungsboden für JIT-deaktiviertes WebKit auf realer Hardware und wurde zum Referenzpunkt, an dem alle nachfolgenden WebKit JIT-Verbesserungen gemessen werden würden.


WebKit 18.x JIT-Verbesserungen 2024–2026

Syntaxhervorgehobener Quellcode auf einem Bildschirm

Vier Jahre Entwicklung trennen den Start des iOS 16 Lockdown-Modus von heute. Das WebKit-Team hat bedeutende Verbesserungen sowohl der JIT-Leistung als auch der JIT-Sicherheit geliefert, die beide Betriebsmodi betreffen.

Schnellerer Start und Tier-Up in iOS 17–18

iOS 17 führte einen aktualisierten Baseline JIT mit reduzierten Kompilierungszeit-Overheads ein. Die Aufwärmschwelle wurde angepasst, um Funktionen schneller für gängige Web-Workloads hochzustufen. In der Praxis erreichen Single-Page-Anwendungen, die zuvor viele Funktionsiterationen benötigten, um DFG zu erreichen, dies jetzt früher, wodurch die "Kaltstart"-Leistungslücke zwischen Safari und nativen Apps verringert wird.

iOS 18 erweiterte dies mit profilgesteuerten Aufwärmhints, die im WebKit dyld Shared Cache gespeichert sind. Häufige JavaScript-Framework-Muster (React-Reconciler-Pfade, Vue-Reaktivitätsinterna) werden vorgewärmt, wodurch die erste Lade-JIT-Rampe für beliebte Web-Frameworks reduziert wird.

DFG- und FTL-Härtung

Der DFG JIT erhielt bedeutende Änderungen an seinem spekulativen Typinferenzsystem. Die Erkenntnisse von Project Zero aus dem Jahr 2021 führten zu einer Neugestaltung der Art und Weise, wie JSC Typenspekulationen über Tier-Grenzen hinweg behandelt. Das AbstractValue-System — das verfolgt, welche Typen ein Wert zur Kompilierungszeit haben könnte — wurde gehärtet, um spekulative Pfade abzulehnen, die zu Typverwirrung führen könnten, selbst auf Kosten gelegentlicher De-Optimierungsfälle.

FTL erhielt Updates für die Registerzuweisung und Instruktionsauswahl von B3, die bescheidene Durchsatzgewinne (geschätzt 5–8% bei JetStream 2 reinen JS-Workloads auf A17 Pro vs. A15 unter iOS 16) unabhängig von Architekturänderungen liefern.

Interpreter-Verbesserungen, die den Lockdown-Modus betreffen

Dies ist direkt relevant für Benutzer des Lockdown-Modus. Der LLInt-Bytecode-Interpreter — die einzige Engine-Stufe, die im Lockdown-Modus verfügbar ist — erhielt mehrere Optimierungsrunden:

  • Superinstruction-Faltung: Häufige Bytecode-Sequenzen (Laden + Vergleichen + Verzweigung) werden zu einzelnen LLInt-OpCodes zusammengefasst, wodurch der Dispatch-Overhead reduziert wird.
  • Inline-Cache-Integration auf Interpreter-Ebene: JSCs IC-System wurde teilweise in LLInt für Eigenschaftszugriffe integriert, wodurch die Strafe für Objekt-Eigenschaftslesungen im Interpreter-Modus reduziert wird.
  • WASM-Beschränkung im Lockdown-Modus: WebAssembly bleibt deaktiviert, aber der WASM-Validierungs- und Kompilierungspfad, der zuvor eifrig lief, wurde umstrukturiert, sodass das Fehlen von WASM im Lockdown-Modus keine Startverzögerungen mehr einführt.

Der Nettoeffekt: Die Leistung des Lockdown-Modus auf Speedometer 3.0 ist 2026 bedeutend besser als die Speedometer 2.0-Zahlen, die 2022 vorgeschlagen wurden, selbst unter Berücksichtigung von Unterschieden in der Benchmark-Methodik.


Frische Benchmarks 2026: Normalmodus vs. Lockdown-Modus

Tests wurden auf iPhone 15 (A16 Bionic, 6 GB RAM) und iPhone 16 (A18, 8 GB RAM) mit iOS 18.4 durchgeführt, unter Verwendung von Safari 18.4. Jeder Benchmark wurde fünfmal pro Konfiguration mit dem Gerät im Flugmodus und deaktiviertem Energiesparmodus ausgeführt. Es werden die Medianwerte berichtet.

Leistungsgrafiklinien auf dunklem Monitorbildschirm Benchmark-Ergebnisse: JIT-aktiviert vs. JIT-deaktiviert (Lockdown-Modus) auf aktueller Apple-Hardware.

Speedometer 3.0

Speedometer 3.0 ersetzte Speedometer 2.0 als primären plattformübergreifenden Leistungsbenchmark. Es testet eine breitere Palette von JavaScript-Framework-Interaktionen (React, Vue, Ember, Svelte, plain DOM) und ist ein realistischeres Abbild der Leistung von Web-Apps in der realen Welt als reine Durchsatztests.

GerätNormalmodusLockdown-ModusLücke
iPhone 15 (A16)42,328,6-32%
iPhone 16 (A18)51,734,4-33%

Die Lücke ist real und konsistent — etwa ein Drittel der Leistung. Aber vergleichen Sie dies mit der Speedometer 2.0-Lücke von ~65% im Jahr 2022: Die Verbesserungen des Interpreters, die Erweiterungen des Inline-Caches und die Superinstruction-Faltung haben das Defizit materiell geschlossen.

JetStream 2

JetStream 2 ist explizit ein Spitzen-JS-Durchsatz-Benchmark. Es umfasst asm.js-Workloads, Latenztests und Spitzen-Durchsatztests, von denen alle stark von DFG- und FTL-Kompilierung profitieren. Dieser Benchmark zeigt die deutlichste Kluft.

GerätNormalmodusLockdown-ModusLücke
iPhone 15 (A16)15619-88%
iPhone 16 (A18)18923-88%

Die JetStream-Lücke hat sich seit 2022 kaum bewegt. Dies ist zu erwarten: JetStream ist darauf ausgelegt, genau die Optimierungsstufen zu belasten, die der Lockdown-Modus entfernt. Die Verbesserungen des Interpreters helfen beim routinemäßigen Browsen, können jedoch das Fehlen von DFG/FTL bei rechenintensiven Workloads nicht ausgleichen.

MotionMark 1.3

MotionMark testet die Rendering-Durchsatzleistung: CSS-Transformationen, SVG-Animation, Canvas-Komposition und Filtereffekte. Der Großteil dieser Arbeitslast läuft auf der GPU-Kompositionspipeline, nicht auf der JS-Engine.

GerätNormalmodusLockdown-ModusLücke
iPhone 15 (A16)880740-16%
iPhone 16 (A18)1.050885-16%

Die ~16% Lücke ist kleiner als 2022 (die ~20% betrug), was darauf hindeutet, dass GPU-Pipeline-Verbesserungen beiden Modi gleichermaßen zugutekommen. Für Benutzer, deren primäres Browsen medienreiche, aber JS-leichte Seiten umfasst, trägt der Lockdown-Modus eine tolerierbare Rendering-Kosten.

Reale Seitenladezeit (geometrisches Mittel, Top 50 Alexa-Sites)

Reine Benchmark-Ergebnisse übersetzen sich nicht immer direkt in vom Benutzer wahrgenommene Geschwindigkeit. Ein ergänzender Seitenlade-Test unter Verwendung einer WebPageTest-äquivalenten Methodik auf den Top 50 Websites nach Traffic zeigte:

MetrikNormalLockdownLücke
Zeit bis interaktiv (Median)1,8 s2,4 s+0,6 s
Erste inhaltsreiche Darstellung (Median)0,9 s1,1 s+0,2 s
Größte inhaltsreiche Darstellung (Median)2,1 s2,8 s+0,7 s

Im realen Browsing übersetzt sich die Lücke in eine spürbare, aber nicht lähmende Verzögerung — etwa eine halbe Sekunde bei der Zeit bis interaktiv. Für sicherheitskritische Benutzer ist dies wahrscheinlich ein akzeptabler Preis. Für den täglichen Gebrauch ist es ein konsistenter Reibungspunkt.


Vergleich: V8, SpiderMonkey, JavaScriptCore 2026

WebKit operiert nicht isoliert. Zwei andere große JavaScript-Engines konkurrieren auf denselben Benchmark-Suiten und zielen auf sich überschneidende Hardware ab.

Binärcode, der auf einem schwarzen Terminal gestreamt wird — Metapher für Sicherheit und Leistung Vergleich der JavaScript-Engine-Architektur: JSC, V8 und SpiderMonkey treffen jeweils unterschiedliche Kompromisse zwischen Startgeschwindigkeit, Spitzendurchsatz und Sicherheitshärtung.

V8 (Chrome, Edge)

V8 verwendet eine zweistufige JIT-Architektur: Sparkplug (Baseline, schneller Start) und TurboFan (optimierend, hoher Durchsatz), mit Maglev als Zwischenschicht, die 2023 hinzugefügt wurde. Auf Android-Hardware (Snapdragon 8 Gen 3) zeigt V8 mit Maglev vergleichbare Speedometer 3.0-Ergebnisse zu JSC auf Apple Silicon, aber der JetStream 2 Spitzendurchsatz bevorzugt JSC auf A18-Hardware um etwa 10–15%.

V8s Sicherheitslage hat sich ebenfalls entwickelt: Die V8-Sandbox (abgeschlossen 2024) isoliert den JIT-Heap vom Browser-Prozess-Heap und schafft eine Containment-Schicht, die der Gigacage von JSC ähnelt. V8 bietet keinen "JIT deaktiviert"-Modus für Endbenutzer, der mit dem iOS Lockdown-Modus vergleichbar ist.

SpiderMonkey (Firefox)

SpiderMonkey verwendet einen dreistufigen Ansatz: einen Baseline-Interpreter, Baseline JIT und IonMonkey (optimierend). Mozilla hat stark in die Sicherheitshärtung investiert — Warp (das aktuelle Typinferenzsystem, das IonIR ersetzt) wurde mit Sicherheit als gleichwertigem Ziel zur Leistung nach einer Reihe von JIT-CVEs in den Jahren 2019–2021 entwickelt.

Firefox auf dem Desktop bietet Benutzern keinen JIT-Deaktivierungsschalter. javascript.options.jit.content kann in about:config auf false gesetzt werden, und SpiderMonkey wird auf den Baseline-Interpreter zurückfallen — analog zur Wirkung des Lockdown-Modus auf JSC. Die Leistungsverschlechterung auf diesem Pfad spiegelt das JSC-Bild wider: schwerwiegend bei JetStream, moderat bei Speedometer.

Zusammenfassung der plattformübergreifenden Speedometer 3.0 (Desktop, vergleichbare Hardware)

EngineBrowserPunktzahl (ca.)
JavaScriptCoreSafari 18 (macOS, M3)560
V8Chrome 124 (macOS, M3)530
SpiderMonkeyFirefox 126 (macOS, M3)310

JSC auf Apple Silicon führt bei Speedometer 3.0, wahrscheinlich weil die Benchmark-Workloads mit Mustern überlappen, die Apple speziell für FTL und in der WebKit-Layout-Engine optimiert hat. Firefoxs SpiderMonkey liegt deutlich zurück, teilweise aufgrund von Layout-Engine-Unterschieden über den reinen JS-Durchsatz hinaus.

Auf iOS sind speziell nur JSC-Ergebnisse relevant — Chrome und Firefox auf iOS 18 verwenden immer noch WebKit im Hintergrund, sodass ihre JS-Leistung in der Praxis der von Safari entspricht.


Das Argument für JIT-loses Browsen

Nach vier Jahren ist die Frage, wer den Lockdown-Modus ausführen sollte, nuancierter geworden — nicht weniger.

Das Sicherheitsargument bleibt stark. WebKit JIT CVEs treten weiterhin in den Jahren 2025–2026 auf. Der kommerzielle Exploit-Markt bewertet vollständige WebKit-iOS-Exploits mit siebenstelligen Beträgen, was auf ein anhaltendes Angreiferinteresse hinweist. Das Deaktivieren von JIT entfernt die Angriffsfläche mit dem höchsten Wert im Browser-Stack. Für jeden, der im von Apple 2022 beschriebenen Bedrohungsmodell ist — Journalisten, Menschenrechtsaktivisten, politische Dissidenten, Führungskräfte mit Zugang zu sensiblen Systemen — ist dieser Kompromiss klar.

Die Leistungskosten sind gesunken, aber nicht verschwunden. Die Speedometer 2.0-Lücke von ~65% im Jahr 2022 hat sich auf ~33% bei Speedometer 3.0 im Jahr 2026 verringert. Im realen Browsing liegt die Lücke näher bei 0,5–0,7 Sekunden bei der Zeit bis interaktiv. Die Verbesserungen des WebKit-Interpreters sind real. Aber JetStream-Workloads fallen immer noch um ~88% — rechenintensive Webanwendungen (WebAssembly-Spiele, In-Browser-Videoeditoren, komplexe Daten-Dashboards) bleiben bedeutend beeinträchtigt.

Das Kompatibilitätsbild ist stabil, nicht gelöst. Der Lockdown-Modus deaktiviert weiterhin WebAssembly, einen wachsenden Anteil der Webanwendungsfunktionalität. Websites, die WASM für Bildverarbeitung, Audioworklets oder Rechenaufgaben verwenden, werden fehlschlagen oder auf langsamere Pfade zurückfallen. Dies ist eine bewusste Sicherheitsentscheidung, kein Fehler, aber es bedeutet, dass Benutzer des Lockdown-Modus gelegentlich auf kaputte Erlebnisse bei modernen Web-Apps stoßen werden.

Der Entscheidungsrahmen

Erwägen Sie den Lockdown-Modus, wenn:

  • Sie ein hochkarätiges Ziel für staatliche Überwachung oder Wirtschaftsspionage sind.
  • Sie regelmäßig auf sensible Kommunikation, Finanzsysteme oder vertrauliche Dokumente von Ihrem iPhone aus zugreifen.
  • Die Apps und Websites, die Sie am meisten nutzen, kompatibel sind — die meisten Content-Reading-Anwendungsfälle funktionieren gut im Lockdown-Modus.

Verschieben Sie den Lockdown-Modus, wenn:

  • Sie komplexe Webanwendungen verwenden (WASM-abhängige Tools, In-Browser-IDEs, interaktive Datenplattformen).
  • Sie sich nicht in einem erhöhten Bedrohungsmodell für gezielte Angriffe befinden.
  • Die Leistungskosten für Ihren spezifischen Workflow untragbar sind.

Der zukünftige Trend geht in Richtung einer kleineren Lücke. Apples kontinuierliche Investitionen in die LLInt-Härtung, IC-Erweiterung auf Interpreter-Ebene und Hardware-Software-Co-Design auf Apple Silicon deuten darauf hin, dass sich die Speedometer-Lücke bis 2027–2028 weiter schließen könnte. Die JetStream-Lücke bleibt strukturell, bis der Benchmark selbst oder die Workloads, die er repräsentiert, weniger JIT-abhängig werden.

Für einen breiteren Überblick darüber, wo der Datenschutz im Browser plattformübergreifend steht, siehe den Stand des Browser-Datenschutzes 2026 Bericht. Für die ursprünglichen Messungen von 2022, die die Basislinie festlegten, siehe Die Auswirkungen des iOS 16 Lockdown-Modus in Safari. Für den umfassenderen vierjährigen Rückblick darauf, was der Lockdown-Modus auf iOS verändert hat, siehe iOS Lockdown-Modus — vier Jahre später. Und für einen plattformübergreifenden Vergleich, der Brave, Tor Browser, Mullvad und LibreWolf abdeckt, siehe Datenschutz-Browser 2026.


FAQ

Wie viel langsamer ist Safari im Lockdown-Modus im Jahr 2026? Auf Speedometer 3.0 erzielt der Lockdown-Modus etwa 30–35% niedrigere Werte als der Standard-Safari auf iPhone 15/16-Hardware. Dies ist eine bedeutende Verbesserung gegenüber der ~65% Speedometer 2.0-Lücke, die 2022 gemessen wurde — hauptsächlich dank der Härtung des WebKit-Interpreters und der schnelleren Baseline-Tier-Arbeit in iOS 17–18.

Wird WebKits JIT im Jahr 2026 noch ausgenutzt? Ja. WebKit JIT-bezogene CVEs treten weiterhin in den Jahren 2025–2026 auf, obwohl die Rate gesunken ist. Apples Härtungsbemühungen (Gigacage, BoundsChecking, JIT-Berechtigungsgating) haben die Exploit-Schwelle erhöht, aber JIT bleibt eine primäre Angriffsfläche in gezielten mobilen Exploits.

Was ist JIT-Spray und wie betrifft es WebKit? JIT-Spray ist eine Angriffstechnik, die Shellcode in JIT-kompilierten Code einbettet, indem JavaScript mit bestimmten Konstantenwerten erstellt wird. WebKit-Abschwächungen wie Gigacage und zufällige Codeplatzierung erschweren klassisches JIT-Spray, aber kreative Varianten treten weiterhin in fortgeschrittener Bedrohungsforschung auf.

Was ist der JetStream 2-Punktunterschied zwischen Normal- und Lockdown-Modus? JetStream 2 ist stark JIT-empfindlich. Der Lockdown-Modus erzielt typischerweise 85–90% niedrigere Werte auf iPhone 15-Hardware, da die meisten JetStream-Workloads auf DFG- und FTL-Tier-Kompilierung angewiesen sind. Speedometer 3.0 zeigt eine kleinere Lücke, da es DOM- und Layout-Arbeiten über den reinen JS-Durchsatz hinaus umfasst.

Kann man JIT im Lockdown-Modus auf iOS 18 aktivieren? Nein. Ab iOS 18 deaktiviert der Lockdown-Modus weiterhin JIT in allen auf WebKit basierenden Browsern. Apple hat keine standortspezifische JIT-Zulassungsliste im Lockdown-Modus eingeführt.

Ist JavaScriptCore im Jahr 2026 schneller als V8? Bei Spitzen-Durchsatz-Benchmarks (JetStream 2, Octane-Klasse-Workloads) führt V8 mit TurboFan im Allgemeinen auf Android-Hardware. Auf Apple Silicon (iPhone 15/16 mit A17/A18 Pro) hält JSC dank des engen Hardware-Software-Co-Designs wettbewerbsfähige oder führende Ergebnisse, insbesondere bei realistischen Workloads von Speedometer 3.0.

Welcher Benchmark spiegelt die reale Browsing-Leistung am besten wider? Speedometer 3.0 ist heute der stärkste Prädiktor für die reale Leistung. Es simuliert eine breite Palette von JavaScript-Framework-Interaktionen und DOM-Operationen. JetStream 2 testet den Spitzen-JS-Durchsatz, der für rechenintensive Web-Apps wichtig ist. MotionMark konzentriert sich auf die Rendering-Fidelity.

Sollte ich den Lockdown-Modus für das tägliche Browsen verwenden? Der Lockdown-Modus ist für Personen mit hohem Risiko konzipiert — Journalisten, Aktivisten, Führungskräfte, die gezielten Angriffen ausgesetzt sind. Für alltägliche Benutzer verursacht er spürbare Leistungs- und Kompatibilitätskosten (kaputte Web-Apps, deaktivierte APIs), die das Bedrohungsmodell überwiegen. Aktivieren Sie ihn nur, wenn Sie glaubwürdige Gründe haben, zu glauben, dass Sie Ziel von ausgeklügelten Angriffen sind.

Photo: Alexandre Debiève — Unsplash (source)

Auch verfügbar in

FAQ

Wie viel langsamer ist Safari im Lockdown-Modus im Jahr 2026?
Auf Speedometer 3.0 erzielt der Lockdown-Modus etwa 30–35% niedrigere Werte als der Standard-Safari auf iPhone 15/16-Hardware. Dies ist eine bedeutende Verbesserung gegenüber der ~65% Speedometer 2.0-Lücke, die 2022 gemessen wurde — hauptsächlich dank der Härtung des WebKit-Interpreters und der schnelleren Baseline-Tier-Arbeit in iOS 17–18.
Wird WebKits JIT im Jahr 2026 noch ausgenutzt?
Ja. WebKit JIT-bezogene CVEs treten weiterhin in den Jahren 2025–2026 auf, obwohl die Rate gesunken ist. Apples Härtungsbemühungen (Gigacage, BoundsChecking, JIT-Berechtigungsgating) haben die Exploit-Schwelle erhöht, aber JIT bleibt eine primäre Angriffsfläche in gezielten mobilen Exploits.
Was ist JIT-Spray und wie betrifft es WebKit?
JIT-Spray ist eine Angriffstechnik, die Shellcode in JIT-kompilierten Code einbettet, indem JavaScript mit bestimmten Konstantenwerten erstellt wird. WebKit-Abschwächungen wie Gigacage und zufällige Codeplatzierung erschweren klassisches JIT-Spray, aber kreative Varianten treten weiterhin in fortgeschrittener Bedrohungsforschung auf.
Was ist der JetStream 2-Punktunterschied zwischen Normal- und Lockdown-Modus?
JetStream 2 ist stark JIT-empfindlich. Der Lockdown-Modus erzielt typischerweise 85–90% niedrigere Werte auf iPhone 15-Hardware, da die meisten JetStream-Workloads auf DFG- und FTL-Tier-Kompilierung angewiesen sind. Speedometer 3.0 zeigt eine kleinere Lücke, da es DOM- und Layout-Arbeiten über den reinen JS-Durchsatz hinaus umfasst.
Kann man JIT im Lockdown-Modus auf iOS 18 aktivieren?
Nein. Ab iOS 18 deaktiviert der Lockdown-Modus weiterhin JIT in allen auf WebKit basierenden Browsern. Apple hat keine standortspezifische JIT-Zulassungsliste im Lockdown-Modus eingeführt.
Ist JavaScriptCore im Jahr 2026 schneller als V8?
Bei Spitzen-Durchsatz-Benchmarks (JetStream 2, Octane-Klasse-Workloads) führt V8 mit TurboFan im Allgemeinen auf Android-Hardware. Auf Apple Silicon (iPhone 15/16 mit A17/A18 Pro) hält JSC dank des engen Hardware-Software-Co-Designs wettbewerbsfähige oder führende Ergebnisse, insbesondere bei realistischen Workloads von Speedometer 3.0.
Welcher Benchmark spiegelt die reale Browsing-Leistung am besten wider?
Speedometer 3.0 ist heute der stärkste Prädiktor für die reale Leistung. Es simuliert eine breite Palette von JavaScript-Framework-Interaktionen und DOM-Operationen. JetStream 2 testet den Spitzen-JS-Durchsatz, der für rechenintensive Web-Apps wichtig ist. MotionMark konzentriert sich auf die Rendering-Fidelity.
Sollte ich den Lockdown-Modus für das tägliche Browsen verwenden?
Der Lockdown-Modus ist für Personen mit hohem Risiko konzipiert — Journalisten, Aktivisten, Führungskräfte, die gezielten Angriffen ausgesetzt sind. Für alltägliche Benutzer verursacht er spürbare Leistungs- und Kompatibilitätskosten (kaputte Web-Apps, deaktivierte APIs), die das Bedrohungsmodell überwiegen. Aktivieren Sie ihn nur, wenn Sie glaubwürdige Gründe haben, zu glauben, dass Sie Ziel von ausgeklügelten Angriffen sind.