Die Open-Source-Webmailsoftware Roundcube Webmail ist verwundbar und Angreifer können an insgesamt acht Schwachstellen ansetzen. Im schlimmsten Fall kann Schadcode Systeme kompromittieren. Sicherheitsupdates stehen zum Download.

Verschiedene Gefahren

In einem Beitrag versichern die Entwickler, die Lücken in Roundcube Webmail 1.6.16 und 1.7.1 geschlossen zu haben. Vier der Schwachstellen sind mit dem Bedrohungsgrad „hoch“ eingestuft (CVE-2026-48842, CVE-2026-48843, CVE-2026-48848, CVE-2026-48844).

Installieren Admins die Sicherheitspatches nicht, können Angreifer unter anderem im Zuge von SQL-Injection- und Stored-XSS-Attacken Schadcode auf Computer schieben und ausführen. Bislang gibt es keine Hinweise, dass Angreifer die Lücken bereits ausnutzen.

Zuletzt haben die Entwickler im März dieses Jahres Sicherheitsupdate für die Webmailsoftware veröffentlicht.

(des)

Vor einigen Tagen sind zwei Beiträge erschienen, die mir immer noch im Kopf herumgehen. Der eine ist ein Interview, das ich mit Hannes Mühleisen geführt habe, dem Mitschöpfer von DuckDB. Der andere ist ein Artikel, den ich kurz darauf für unseren Firmenblog geschrieben habe und in dem ich argumentiere, dass ein Read-Model in einem Event-Sourcing-System oft gar keine Datenbank braucht, sondern problemlos im Arbeitsspeicher Platz findet. Beide Texte stehen nebeneinander, betreffen verschiedene Architekturebenen, und doch haben sie im Kern dasselbe Argument: Die Standardarchitektur, die wir reflexhaft wählen, ist viel öfter überdimensioniert, als wir glauben.

Was mich bei beiden Texten beschäftigt, ist allerdings weniger ihre jeweilige Aussage als die Reaktion, die solche Aussagen erfahrungsgemäß auslösen. Wenn ich vorschlage, ein Read-Model einfach im RAM zu halten, oder wenn jemand mit Hannes’ Datenpunkten argumentiert, dass eine einzelne Maschine für die allermeisten analytischen Lasten ausreicht, dann ist die häufigste Reaktion nicht Widerspruch, sondern Unglauben. Und dieser Unglauben ist, soweit ich das beurteilen kann, kein logisches Problem, sondern ein Wahrnehmungsproblem. Es hat damit zu tun, dass Entwicklerinnen und Entwickler heute kaum noch ein Gefühl für Datenmengen haben.

Zwei Beobachtungen, eine gemeinsame Pointe

Hannes Mühleisen vertritt seit Jahren die Position, dass verteilte Systeme für die meisten analytischen Workloads schlicht überdimensioniert sind. Seine Argumentation steht auf drei Säulen: Die Hardware ist gewaltig leistungsfähiger geworden, die Architekturen moderner Datenbanksysteme sind reifer geworden, und vor allem zeigt eine empirische Auswertung von Snowflake und Redshift durch Fivetran, dass selbst das 99,9-Perzentil der Abfragen auf diesen verteilten Systemen nur rund 300 GByte scannt. Das heißt: Mehr als 99 Prozent aller Abfragen, die auf einer ausgewachsenen verteilten Cloud-Datenbank laufen, würden problemlos auf einem einzelnen Knoten funktionieren. Das ist keine ideologische Position, sondern eine harte Zahl.

Mein eigenes Argument verläuft auf einer ganz anderen Ebene, kommt aber zum gleichen Schluss. In einem Event-Sourcing-System sind die Events die einzige verbindliche Wahrheit. Ein Read-Model ist eine abgeleitete Sicht auf diese Events, eine Projektion, die genau die Form annimmt, die eine bestimmte Abfrage benötigt. Aus dieser Eigenschaft folgt eine bemerkenswerte Konsequenz: Ein Read-Model ist verzichtbar. Es kann jederzeit weggeworfen und aus den Events neu aufgebaut werden. Damit fällt die Anforderung an Dauerhaftigkeit weg, denn die liegt bereits an anderer Stelle. Mit ihr verschwindet auch der wesentliche Grund, warum man überhaupt eine Datenbank für die Lese-Seite einsetzen würde.

Stattdessen kann das Read-Model schlicht im Arbeitsspeicher gehalten werden als geeignete Datenstruktur, in genau der Form, die für die Abfragen passt. Beim Neustart wird es aus den Events rekonstruiert. Mehrere Instanzen hinter einem Load-Balancer halten ihren eigenen Stand im RAM und müssen sich nicht untereinander abstimmen. Die Beobachtung an dieser Stelle ist dieselbe wie bei Hannes: Was die übliche Antwort ist, nämlich eine eigene, idealerweise spezialisierte Datenbank, ist für einen großen Teil der praktischen Fälle gar nicht nötig. Die Standardarchitektur ist also nicht falsch, sie ist lediglich zu groß für das tatsächliche Problem.

Was den Vorschlag eigentlich blockiert

Wenn ich in Gesprächen mit Kundinnen und Kunden vorschlage, ein Read-Model im RAM zu halten, ernte ich fast immer Skepsis. Das ist nachvollziehbar, denn ein ungewohnter Vorschlag muss sich rechtfertigen können. Auffällig ist allerdings, dass sich diese Skepsis selten an einem konkreten Gegenargument entzündet. Sie bleibt diffus. Sie äußert sich in Sätzen wie „aber das skaliert doch nicht“ oder „das passt doch nicht in den Speicher“ oder „und was, wenn das System neu startet?“. Diese Sätze sind keine Einwände, sie sind Reflexe.

Hinter diesen Reflexen stehen, soweit ich das beobachten kann, drei verschiedene Voraussetzungen, die in der Praxis oft fehlen. Die erste ist das Verständnis der Dualität von Arbeitsspeicher und persistentem Speicher. Daten können gleichzeitig im RAM und auf der SSD liegen, mit unterschiedlichen Aufgaben: Der RAM-Teil dient dem schnellen Lesen, der Disk-Teil der Persistenz. Beim Neustart wird der RAM-Teil aus dem Disk-Teil oder aus dem Event-Log neu aufgebaut. Das ist nicht exotisch, es ist nur ungewohnt.

Die zweite Voraussetzung ist die Vorstellung, dass im Arbeitsspeicher überhaupt geeignete Lesestrukturen aufgebaut werden können. Wer gewohnt ist, jede Abfrage gegen eine Datenbank zu richten, hat oft keinen Begriff davon, dass eine schlichte Hash-Map oder ein sortiertes Array für die meisten Abfragen vollständig ausreichen und um Größenordnungen schneller sind als jede Datenbankabfrage über ein Netzwerk.

Die dritte Voraussetzung ist diejenige, um die es mir hier eigentlich geht. Sie betrifft nicht Wissen, sondern Wahrnehmung. Sie ist das Gefühl dafür, wie viele Daten in einem heutigen Arbeitsspeicher tatsächlich Platz finden. Die ersten beiden Voraussetzungen lassen sich nachlesen, sie sind in jedem ordentlichen Lehrbuch über verteilte Systeme erklärt. Die dritte ist schwerer zu vermitteln, weil sie sich nicht aus einem Konzept ergibt, sondern aus einem Maßstab. Und genau dieser Maßstab fehlt.

Was eine Zeitschriftenseite wirklich kostet

Damit man ein Gefühl für Datenmengen entwickeln kann, helfen vertraute Größen. Eine Zeitschriftenseite reiner Text, etwa in einer Ausgabe der iX oder der c’t, enthält grob zwischen 4000 und 5000 Zeichen. Das sind ungefähr 4 bis 5 KByte. In einem MByte finden somit etwa 200 bis 250 Seiten reiner Text Platz. Eine 3,5-Zoll-Diskette der frühen 1990er-Jahre mit ihren 1,44 MByte hätte damit eine komplette Magazinausgabe ohne Abbildungen tragen können und wäre dabei nicht einmal zu drei Vierteln gefüllt gewesen.

Diese Rechnung sieht beim ersten Lesen aus wie eine nostalgische Anekdote. Sie ist es aber nicht: Sie hat nämlich eine direkte Konsequenz für gegenwärtige Architekturentscheidungen. Wenn ich für unseren eigenen Firmenblog nachrechne, wie viel Speicher die interne Aufgabenverwaltung von the native web nach 18 Monaten kontinuierlicher Nutzung tatsächlich belegt, dann komme ich auf 5 MByte. Das sind 8610 Events, mehrere Teammitglieder, reale Daten. 5 MByte. Vier Disketten. Das ist die gefürchtete Größenexplosion bei Event-Sourcing-Systemen.

Auf der anderen Seite des Maßstabs steht die Maschine, auf der dieser Text gerade entsteht. Es ist ein MacBook Pro aus dem Jahr 2022, also inzwischen vier Jahre alt. Es hat einen M2-Prozessor, 24 GByte RAM und eine SSD mit 1 TByte. Das ist kein Server, das ist kein Spezialgerät, das ist ein normales Notebook von vor vier Jahren. Und nun überlegen Sie kurz, wie viele 5-MByte-Datenbestände in die 24 GByte Arbeitsspeicher dieses Geräts passen würden und wie oft sich dieser Arbeitsspeicher als Ganzes auf die 1 TByte der SSD ablegen ließe. Die Antwort sieht in beiden Fällen nicht nach Mangel aus, sondern nach erheblichem Spielraum.

Die andere Hälfte der Asymmetrie

Bis hierher habe ich nur von einer Seite des Wahrnehmungsproblems gesprochen, nämlich der Überschätzung. Wir glauben, dass die Daten, die unsere Anwendung produziert, gewaltig sein werden, und in den allermeisten Fällen sind sie es nicht. Die Wahrnehmung kippt allerdings, sobald wir die Seite wechseln und nicht mehr produzieren, sondern konsumieren. Dann fallen plötzlich Sätze wie „ach, die paar GByte“, und niemand wundert sich mehr.

Wer einmal versucht hat, in einem JavaScript-Projekt die Größe des node_modules-Verzeichnisses nachzurechnen, kennt das Muster. Ein mittelgroßes Projekt zieht ohne Weiteres mehrere hundert MByte an Abhängigkeiten nach, gelegentlich über ein GByte. Docker-Images, die im Grunde nur eine einzelne Anwendung enthalten, kommen mit überraschender Regelmäßigkeit auf 1 bis 2 GByte, weil sie ein halbes Ubuntu mitschleppen. Bei jedem Build, bei jedem Deployment, in jeder Continuous-Integration-Pipeline wird das im Netz hin- und hergeschoben.

Diese Wahrnehmungsfehler sind nicht zufällig entgegengesetzt. Sie speisen sich aus derselben Quelle. Wir denken Datenmengen nicht in Zahlen, sondern in Bewertungen. Was wir selbst produzieren, fühlt sich nach „viel“ an, weil es uns wichtig ist. Was wir nebenher konsumieren, fühlt sich nach „wenig“ an, weil es im Hintergrund passiert. Mit den tatsächlichen Größen hat beides wenig zu tun.

Daten als Adjektiv, nicht als Zahl

Damit ist die eigentliche Diagnose erreicht. Das Problem ist nicht, dass wir bei der Schätzung von Datenmengen zu hoch oder zu niedrig liegen. Das Problem ist, dass wir Datenmengen überhaupt nicht in Zahlen denken, sondern in Adjektiven. „Viel“, „wenig“, „riesig“, „eine Menge“, „kaum nennenswert“: Das sind keine Größen, das sind Stimmungen. Sie sagen etwas darüber aus, wie sich die Daten für die sprechende Person anfühlen, und nichts darüber, wie groß sie tatsächlich sind.

Adjektive sind eine schlechte Grundlage für technische Entscheidungen. Wer eine Architektur darauf aufbaut, dass „viele Daten“ entstehen werden, kann nicht beurteilen, ob die gewählte Datenbank überdimensioniert ist, ob das geplante Sharding berechtigt ist oder ob ein verteiltes System wirklich notwendig sein wird. Es fehlt der Maßstab, gegen den die Entscheidung gemessen werden könnte. Es bleiben Gewohnheit, Reflex und das diffuse Gefühl, lieber zu groß als zu klein zu planen.

Genau dieser Reflex ist es, der die Vorschläge aus den beiden eingangs erwähnten Beiträgen unverdaulich erscheinen lässt. Wer Datenmengen nur als Stimmung wahrnimmt, kann mit dem Vorschlag, ein Read-Model im RAM zu halten oder Analytics auf einer einzelnen Maschine zu fahren, schlicht nichts anfangen. Es klingt zu klein, zu unscheinbar, zu sehr nach Bastelei. Das Gefühl sagt: Das wird nicht reichen. Die Rechnung würde sagen: Es reicht mit erheblichem Spielraum. Aber die Rechnung wird nicht gemacht.

Architektur mit Phantommaß

Die Folgen sind in vielen Systemen sichtbar, die ich in den letzten Jahren kennengelernt habe oder über die ich mit anderen gesprochen habe. Sharding wird eingeführt, bevor die Datenmenge auch nur annähernd eine Größenordnung erreicht hat, bei der das gerechtfertigt wäre. Verteilte Datenbanken werden ausgewählt, weil sie nach „groß“ klingen, obwohl PostgreSQL auf einer einzelnen Maschine die zu erwartende Last über Jahre tragen würde. Es werden eigene Cluster für Read-Models aufgesetzt, deren Datenbestand auf eine 3,5-Zoll-Diskette gepasst hätte.

Ein wiederkehrendes Beispiel aus meinem eigenen Tätigkeitsfeld ist die fast schon rituelle Frage zu Event-Sourcing-Systemen: „Wird die Datenbank denn nicht zu groß, wenn man nie etwas löscht?“. Die Frage ist verständlich, und sie folgt derselben Logik. Sie geht davon aus, dass viele Events zwangsläufig viele Daten bedeuten. Tatsächlich ist die Antwort fast immer ernüchternd: Ein typisches Geschäftsereignis ist 200 bis 500 Byte groß, ein durchschnittlicher Geschäftsprozess generiert wenige Events pro Vorgang und auf einer Festplatte von 1 TByte finden zwei Milliarden Events Platz. Wer keine Mengenintuition mitbringt, hört diese Zahlen wie aus einer anderen Welt. Wer sie ernst nimmt, kommt zu anderen Architekturen.

Es geht nicht darum, jede Datenbank zu vermeiden oder pauschal alles in den Arbeitsspeicher zu zwingen. Es geht um die Reihenfolge der Entscheidungen. Wer die Frage „brauche ich überhaupt eine Datenbank?“ nie stellt, hat sie auch nie verneinen können. Es gibt Fälle, in denen die Standardantwort die richtige ist. Aber es gibt eben auch sehr viele Fälle, in denen sie es nicht ist, und die werden flächendeckend verfehlt, weil die Frage nicht gestellt wird.

Augenmaß als Ingenieurstugend

Mengenintuition ist keine Nostalgie. Sie ist keine Hommage an die Diskette, kein Plädoyer für asketische Software, kein Wettstreit darum, mit möglichst wenig Ressourcen auszukommen. Sie ist eine Voraussetzung dafür, technische Entscheidungen überhaupt treffen zu können, statt sie reflexhaft zu fällen. Wer vor dem Bauen rechnet, kommt zu anderen Antworten als der, der dem ersten Gefühl folgt. Das ist keine erschöpfende Methode, es ist nur eine Mindestbedingung.

Was die beiden eingangs erwähnten Beiträge eint, ist nicht ein gemeinsames Thema, sondern ein gemeinsames Vorgehen. Hannes Mühleisen verweist auf eine konkrete Auswertung von Abfragelasten. Ich verweise in meinem eigenen Text auf konkrete Zahlen zu Read-Model-Größen, ergänzt um eine Mengenschätzung an einer realen Produktionsanwendung. In beiden Fällen wird der Reflex durch eine Rechnung ersetzt. Genau das macht die Vorschläge tragfähig.

Wenn ich mir für die nächste Architekturdiskussion etwas wünschen dürfte, dann nicht, dass alle ihre Daten ins RAM legen oder ihre Cluster zurückbauen. Sondern dass, bevor jemand „viel“ oder „wenig“ sagt, eine kurze Rechnung dazwischensteht. Eine Schätzung in Byte pro Ereignis, eine Schätzung in Ereignissen pro Tag, eine Multiplikation auf den geplanten Betriebszeitraum. Das ist keine große Mathematik, das sind drei Zahlen. Aber es macht den Unterschied zwischen einer Architekturentscheidung und einem Reflex. Und in diesem Unterschied liegt das, was eine Ingenieursleistung von Bastelei unterscheidet: das Augenmaß.

(mro)

Spanien hat die Prognosemarkt-Plattformen Polymarket und Kalshi für spanische Nutzer gesperrt und Sanktionsverfahren gegen beide Anbieter eingeleitet. Das zuständige Ministerium für Verbraucherangelegenheiten ordnete den Block als Sicherungsmaßnahme an, bis die Verfahren abgeschlossen sind, teilte die Generaldirektion für Glücksspielaufsicht (DGOJ) mit.

Das Sanktionsverfahren wurde am Dienstag im spanischen Staatsanzeiger (BOE) veröffentlicht – direkte Zustellungsversuche an die im Ausland ansässigen Betreiber seien zuvor gescheitert. Polymarket und Kalshi sollen laut DGOJ ohne die in Spanien vorgeschriebene Betriebsgenehmigung aktiv gewesen sein, wie aus der Pressemitteilung des Ministeriums hervorgeht. Die Behörde schätzt, dass das Verfahren 3 bis 4 Monate bis zur Entscheidung dauern könnte. Bis dahin bleibt der Zugang zu beiden Plattformen in Spanien blockiert.

Wetten ohne Aufsicht

Spanien stuft Prognosemärkte als Glücksspiel ein, sobald auf unsichere Ereignisse in der Zukunft gesetzt wird. Wer solche Wetten in Spanien anbieten will, braucht eine Lizenz der DGOJ. Ohne sie fehlen laut Behörde wesentliche Schutzmaßnahmen: Altersverifikation, Zugangssperren sowie die regulatorische Aufsicht über die Abwicklung der Wetten.

Kalshi und Polymarket sind Plattformen, bei denen Nutzer auf den Ausgang zukünftiger Ereignisse wetten können. Dazu zählen unter anderem Sportveranstaltungen, aber auch Wahlen, Wetterphänomene, Kriegsgeschehnisse und viele weitere Themen. Anders als bei klassischen Buchmachern setzen Nutzer dabei nicht gegen das Haus, sondern handeln Anteile untereinander. Die Plattform vermittelt und kassiert eine Provision.

In der Europäischen Union sind Polymarket und Kalshi bisher nicht einheitlich reguliert. In Deutschland benötigen Online-Glücksspielanbieter eine Lizenz, die weder Polymarket noch Kalshi besitzen. Daher blockiert Polymarket den Handel aus Deutschland, lässt aber die Ansicht der Märkte zu. Österreich und die Schweiz stehen nicht auf der offiziellen Sperrliste von Polymarket. Kalshi schließt den Handel aus deutschsprachigen Ländern nicht offiziell aus, verweist aber auf länderspezifische Beschränkungen.

Wachsender Regulierungsdruck

Spanien ist nicht das erste Land, das gegen die Plattformen vorgeht. Polymarket ist unter anderem in Frankreich und Belgien blockiert, berichtet der Guardian. Zuletzt hat Minnesota als erster US-Bundesstaat beide Plattformen per Gesetz verboten. Die CFTC (Commodity Futures Trading Commission) klagt gegen das Gesetz, das ab dem 1. August in Kraft treten soll.

In den USA streiten unterdessen Bundesbehörde und Einzelstaaten um die Frage, wer die Branche regulieren darf. Mindestens 14 weitere US-Bundesstaaten planen ähnliche Verbote.

(dahe)