Die In-Memory-Datenbank Redis ist in Version 8.6 erschienen. Das Update steigert den Durchsatz bei Caching-Workloads auf ARM-Prozessoren um mehr als das Fünffache gegenüber Redis 7.2. Auf einem 16-Kern-System in der AWS-Cloud mit einem Graviton4-Prozessor erreichte Redis 8.6 in Benchmarks bis zu 3,5 Millionen Operationen pro Sekunde.

Die Entwickler optimierten zahlreiche Komponenten: Sorted Sets verzeichnen eine Latenzreduktion von bis zu 35 Prozent, GET-Operationen bei kurzen Strings führt Redis 15 Prozent schneller durch. Beim Speicherverbrauch sinkt der RAM-Bedarf für Hashes um 16,7 Prozent, für Sorted Sets sogar um 30,5 Prozent. Diese Verbesserungen betreffen nicht nur ARM-Systeme – auf Intel- und AMD-Plattformen zeigen sich ähnliche Verbesserungen.

Für KI- und Machine-Learning-Anwendungen bringt Redis 8.6 beschleunigte Vektor-Operationen: Die Geschwindigkeit beim Einfügen von Vektoren steigt um 43 Prozent, Abfragen werden 58 Prozent schneller durchgeführt. Dies gilt besonders bei binärer und 8-Bit-Quantisierung auf x86-64-Systemen.

Idempotente Produktion verhindert Duplikate in Streams

Eine weitere zentrale Neuerung betrifft Redis Streams. Der XADD-Befehl unterstützt jetzt idempotente Produktion durch die Parameter IDMP und IDMPAUTO. Damit lassen sich Duplikate vermeiden, wenn Produzenten nach Netzwerkfehlern oder Abstürzen Nachrichten erneut senden. Jeder Produzent erhält eine eindeutige Producer-ID, jede Nachricht eine Idempotency-ID – entweder manuell vergeben oder automatisch aus dem Nachrichteninhalt generiert.

Administratoren können die Haltedauer dieser IDs über XCFGSET STREAM IDMP-DURATION steuern und die maximale Anzahl pro Producer mit IDMP-MAXSIZE begrenzen. Die idempotente Produktion ist besonders wichtig bei Systemen mit mehreren Consumer-Groups: Stürzt etwa der Producer bei einer Essensbestellung nach dem Senden ab, verhindert die Idempotenz, dass Küche, Lager und Lieferdienst die Bestellung doppelt verarbeiten. Eine Einschränkung gibt es jedoch: Die Kombination aus idempotenter Produktion und AOF-Persistierung ohne RDB-Preamble führt derzeit zu Problemen – ein Patch soll folgen.

Neue Eviction-Strategien für Write-Heavy-Workloads

Mit den LRM-Policies (Least Recently Modified) erweitert Redis 8.6 die Eviction-Strategien. Anders als die etablierten LRU-Policies (Least Recently Used) berücksichtigt LRM nicht den letzten Lesezugriff, sondern ausschließlich Schreiboperationen. Das ist vorteilhaft bei write-intensiven Anwendungen oder KI-Workloads, wo Lesezugriffe die Relevanz eines Eintrags nicht beeinflussen sollen. Verfügbar sind volatile-lrm für Keys mit TTL und allkeys-lrm für alle Schlüssel.

Cluster-Betreiber profitieren vom neuen HOTKEYS-Befehl. Er identifiziert CPU- oder Netzwerk-intensive Schlüssel pro Slot und ermöglicht gezielte Optimierungen. In Kombination mit der in Redis 8.4 eingeführten atomaren Slot-Migration lassen sich Hotspots im Cluster gezielt beseitigen. Die Analyse startet mit HOTKEYS START, wobei Metriken, Stichprobenrate und Dauer konfigurierbar sind.

TLS-Zertifikate zur Authentifizierung

Für mTLS-Umgebungen vereinfacht Redis 8.6 die Authentifizierung: Clients können sich automatisch über ihr TLS-Zertifikat anmelden, wenn der Common Name des Zertifikats einem ACL-Benutzer entspricht. Die Konfiguration erfolgt mit tls-auth-clients-user CN und ACL SETUSER on nopass. Damit entfällt die separate Passwort-Authentifizierung – das Zertifikat dient als einzige Credential.

Time-Series-Datenbanken unterstützt Redis 8.6 mit NaN-Werten (Not a Number) in TS.ADD und TS.MADD. Neue Aggregatoren wie COUNTNAN und COUNTALL behandeln fehlende Messwerte korrekt, während bestehende Aggregatoren NaN-Werte ignorieren.

Alle Informationen zum neuen Release finden sich im Blog des Projekts. Redis 8.6 ist als Open-Source-Software unter der AGPLv3-Lizenz verfügbar. Die Unified Distribution enthält alle Funktionen einschließlich RedisTimeSeries, RedisBloom und RedisJSON in einem Paket. Binaries stehen für Docker, Snap, Homebrew sowie als RPM- und Debian-Pakete bereit. Die Version haben die Entwickler auf Ubuntu 22.04/24.04, Rocky Linux, AlmaLinux, Debian und macOS getestet.

(fo)

Google hat Chrome 145 für Windows, macOS und Linux veröffentlicht. Die Version umfasst einige kleinere neue Features und schließt elf Sicherheitslücken, darunter drei mit hoher Priorität. Vor allem aber bringt die neue Version des Browsers den Support des Bildformats JPEG XL zurück, dem sich Google offiziell lange verweigert hatte.

JPEG XL: Von der Entfernung zur Rückkehr

Google hatte die Unterstützung für das Format Anfang 2023 in Chrome 110 entfernt – mit der Begründung, es gebe zu wenig Interesse im Ökosystem und unzureichende Vorteile gegenüber bestehenden Formaten. Die Entscheidung stieß auf massive Kritik: Über 1000 Upvotes im Chromium-Bug-Tracker protestierten gegen die Entfernung, die Free Software Foundation kritisierte die Entscheidung als Einengung von Nutzer-Wahlmöglichkeiten. Jon Sneyers, Mitentwickler von JPEG XL, vermutete einen internen Konflikt bei Google zwischen JPEG-XL-Befürwortern und Vertretern der konkurrierenden Google-Formate AVIF und WebP.

JPEG XL wurde als moderner Standard für Bildkompression entwickelt und basiert auf Googles PIK und Cloudinarys FUIF. Der Standard wurde im Dezember 2020 finalisiert und im Oktober 2021 als internationaler Standard verabschiedet. Das Format bietet höhere Kompressionsraten als JPEG, unterstützt verlustfreie Kompression und ist offen sowie lizenzgebührenfrei. Experimentell war JPEG XL bereits ab Chrome 91 mit einem Feature Flag verfügbar.

Die Neubewertung begann im November 2025, als das Chromium-Team die Wiederaufnahme ankündigte. Ausschlaggebend waren mehrere Faktoren: Apple hatte den JPEG-XL-Support in Safari implementiert, Mozilla seine neutrale Haltung aufgegeben und die PDF-Association das Format im Oktober 2025 als empfohlen in PDF-Spezifikationen aufgenommen. Technisch plant Chromium die Integration von „jxl-rs“, einem Rust-basierten JPEG-XL-Decoder. Google nutzt das Format bereits praktisch: Die Google Cloud Platform DICOM API verwendet JPEG XL für eine Reduktion der Dateigröße um 20 Prozent.

Neue Features in Chrome 145

Chrome 145 bringt außerdem diverse neue Funktionen. Column wrapping für Multicol ermöglicht vertikales Spaltenlayout und 2D-Spaltenlayout. Device Bound Session Credentials schützen Nutzer-Sessions besser. Die neue Origin API vereinfacht die Arbeit mit Origins. Bei CSS unterstützt der Browser nun das text-justify-Property für bessere Kontrolle über Textausrichtung bei Blocksatz sowie prozentuale Werte für letter-spacing und word-spacing für responsive Typografie.

Weitere Neuerungen umfassen eine optimierte Schattenberechnung bei hohen border-radius-Werten, neue Event-Handler wie onanimationcancel für CSS Animations und die focusVisible-Option zur Kontrolle über Fokusring-Anzeige. Das Customizable-select-Element verbessert das Listbox-Rendering, während Monochrome-Emoji im Forced-Colors-Modus die Darstellung verbessern.

Behobene Sicherheitslücken

Besonders kritisch sind drei als „High Severity“ eingestufte Schwachstellen. CVE-2026-2313 betrifft einen Use-after-free-Fehler in CSS, CVE-2026-2314 beschreibt einen Heap-Buffer-Overflow in den Codecs und CVE-2026-2315 eine fehlerhafte Implementierung in WebGPU. Alle drei Lücken lassen sich durch manipulierte HTML-Seiten ausnutzen und erreichen einen CVSS-Score von 8.8. Für die Meldung von CVE-2026-2313 zahlte Google 8000 US-Dollar an die Forscher Han Zheng, Wenhao Fang und Qinying Wang.

Die mittelschweren Sicherheitslücken umfassen unter anderem CVE-2026-2316, die UI-Spoofing in Frames ermöglicht, sowie CVE-2026-2317, die ein Cross-Origin-Datenleck in der Animation-Implementierung erlaubt. Eine Race-Condition in den DevTools (CVE-2026-2319) könnte Object-Corruption via bösartiger Erweiterungen ermöglichen. Insgesamt zahlte Google für die gemeldeten Schwachstellen Prämien zwischen 500 und 8000 US-Dollar.

Alle Informationen zur neuen Version 145 finden sich in den Release-Notes. Anwender sollten Chrome zeitnah aktualisieren, da die Sicherheitslücken remote über manipulierte Webseiten ausnutzbar sind. Chrome aktualisiert sich in der Regel automatisch, Nutzer können die Aktualisierung aber über „Einstellungen/Über Google Chrome“ manuell anstoßen.

(fo)

Der Chatdienst WhatsApp wirft der russischen Regierung den Versuch einer Komplett-Blockade vor. Über 100 Millionen Nutzer von sicherer und privater Kommunikation auszuschließen, werde zu weniger Sicherheit für die Menschen in Russland führen, kritisierte eine Sprecherin der zum Facebook-Konzern Meta gehörenden App. Man werde alles Mögliche unternehmen, damit die Nutzer weiterhin verbunden blieben.

Die russische Regierung schränkt bereits seit einiger Zeit nach und nach die Funktionen internationaler Messenger-Apps ein. Bei WhatsApp etwa waren Anrufe bereits nur noch über VPN-Verbindungen (Virtual Private Network) möglich. Eingeschränkt wurden auch Telegram und der Apple-Dienst iMessage.

WhatsApp hat eine Ende-zu-Ende-Verschlüsselung, was bedeutet, dass nur die beteiligten Nutzer Beiträge im Klartext sehen können – aber nicht WhatsApp als Betreiber.

„Staatliche Überwachungs-App“

Die russischen Behörden hatten seit Beginn des Angriffskrieges in der Ukraine die Kontrolle und Zensur im Internet noch einmal drastisch verschärft. Während ausländische Dienste eingeschränkt werden, wurde in Russland der einheimische Messenger Max auf den Markt gebracht. WhatsApp sprach in der Stellungnahme von einer „staatlichen Überwachungs-App“, in die die russische Regierung die Nutzer drängen wolle.

(olb)