Wir sprechen mit Alexander Lichter [https://www.lichter.io/] (LinkedIn [https://www.linkedin.com/in/alexanderlichter/] / Mastodon [https://hachyderm.io/@manniL]) über die Übernahme von VoidZero durch Cloudflare. Nachdem wir in Revision 673 [https://workingdraft.de/673/] bereits über die Gründung von VoidZero und die Vision einer nachhaltigen Finanzierung moderner JavaScript-Infrastruktur gesprochen haben, ziehen wir nun Bilanz: Warum wurde VoidZero übernommen, was bedeutet das für Vite, Rolldown und Co., und wie verändert sich dadurch die Arbeit der Maintainer?

Außerdem sprechen wir über Open-Source-Finanzierung, die Rolle großer Unternehmen als Stewards wichtiger Infrastruktur, den Umgang mit AI-generierten Pull Requests, den neuen Vite Ecosystem Fund und darüber, warum Alex trotz Cloudflare-Anstellung weiterhin so viel Zeit in Framework-übergreifende Open-Source-Arbeit steckt.

Veranstaltungstipp



Die NodeConf.eu [https://nodeconf.eu/] ist eine ehrenamtlich organisierte Non-Profit-Konferenz von der Community für die Community. Dieses Jahr findet sie wieder im wunderschönen Bologna statt – eine Stadt, die sich perfekt für einen verlängerten Konferenztrip eignet.

Zum internationalen Vortragsprogramm gibt es reichlich Gelegenheit zum Netzwerken, denn im Ticketpreis ist auch ein mehrgängiges gemeinsames Abendessen enthalten. Wenn ihr JavaScript, Node.js und die Webplattform mögt, lohnt sich ein Blick auf die NodeConf.eu [https://nodeconf.eu/].

Shownotes

[00:00:56] Die VoidZero-Akquisition [https://voidzero.dev/posts/voidzero-cloudflare] Wir knüpfen zunächst an unsere frühere Episode zur Gründung des Unternehmens an. Alex erzählt, wie sich die ursprüngliche Idee einer nachhaltigen Finanzierung von Open-Source-Projekten entwickelte, warum sich Developer Tools nur schwer monetarisieren lassen und weshalb Cloudflare schließlich zum neuen Zuhause des gesamten Teams wurde. Dabei diskutieren wir, wie eine solche Akquisition abläuft, welchen Exit sie für Investoren darstellt und warum sie weit mehr als ein klassisches „Acqui-Hire“ ist.

Anschließend widmen wir uns den Auswirkungen auf das Vite-Ökosystem. Wir sprechen über den neuen Vite Ecosystem Fund, das Advisor-Modell, die weiterhin unabhängige Governance der Projekte und darüber, weshalb Cloudflare die technische Ausrichtung von Vite nicht einfach bestimmen kann. Alex erläutert außerdem, wie sich sein Arbeitsalltag verändert hat, warum das gesamte Team gemeinsam zu Cloudflare gewechselt ist und welche Möglichkeiten sich durch den direkten Zugriff auf große Produktionssysteme ergeben.

Darüber hinaus diskutieren wir die Rolle großer Unternehmen als Stewards von Open Source, den Umgang mit AI-generierten Pull Requests, die Bedeutung guter Bug Reports sowie Alex‘ Beiträge zu React, Chromium und Nuxt. Zum Abschluss werfen wir noch einen Blick auf Vite+, die zukünftige Entwicklung der Toolchain und darauf, woran sich überhaupt erkennen lässt, ob die Übernahme von VoidZero langfristig ein Erfolg war.

Links

Revision 673 – VoidZero [https://workingdraft.de/673/] Unsere erste Episode mit Alex über die Gründung von VoidZero und die Vision hinter dem Unternehmen. VoidZero joins Cloudflare [https://voidzero.dev/posts/voidzero-cloudflare] Der offizielle Blogpost von VoidZero zur Übernahme durch Cloudflare.

Revision 724: Die VoidZero-Akquisition, mit Alexander Lichter

Wir sprechen mit Thomas Steiner [https://blog.tomayac.com/] (Mastodon [https://toot.cafe/@tomayac], Bluesky [https://bsky.app/profile/tomayac.com], LinkedIn [https://www.linkedin.com/in/thomassteinerlinkedin/]) von Google über einen neuen Vorschlag für die Webplattform: die Cross-Origin-Storage API. Tom war bereits mehrfach bei uns zu Gast, zuletzt in Revision 677 [https://workingdraft.de/677/].

Gemeinsam schauen wir uns an, welches Problem die API lösen soll, warum Browser heute identische Ressourcen mehrfach herunterladen und speichern und wie sich das mit einem hashbasierten, sicheren und datenschutzfreundlichen Ansatz vermeiden ließe. Dabei geht es längst nicht nur um KI-Modelle, sondern ebenso um WebAssembly-Pakete, Web Fonts und JavaScript-Bibliotheken.

Shownotes

[00:01:10] Cross-Origin-Storage API [https://github.com/WICG/cross-origin-storage] Die Cross-Origin-Storage API soll es ermöglichen, identische Ressourcen originübergreifend wiederzuverwenden, ohne dabei die Sicherheits- und Privacy-Probleme früherer Shared-Caches wieder einzuführen. Ausgangspunkt sind zwar große KI-Modelle, die heute von jeder Webanwendung erneut heruntergeladen werden müssen, obwohl sie häufig bereits lokal vorhanden sind, das Konzept funktioniert aber genauso für JavaScript-Bibliotheken, WebAssembly-Module oder Web Fonts. Wir sprechen darüber, weshalb frühere Ansätze wie gemeinsame CDN-Caches für jQuery letztlich an Bundling, Cache-Partitionierung und Sicherheitsproblemen gescheitert sind. Tom erklärt das Grundprinzip der API: Ressourcen werden ausschließlich über ihren kryptografischen Hash identifiziert. Anwendungen können deklarativ über HTML und CSS oder imperativ über navigator.crossOriginStorage auf gemeinsam gespeicherte Dateien zugreifen. Dabei baut der Vorschlag bewusst auf bestehenden Konzepten wie Origin Private File System (OPFS) [https://web.dev/articles/origin-private-file-system], der File System Access API und Subresource Integrity auf. Dadurch lassen sich bestehende APIs weitgehend wiederverwenden und Browser ohne Unterstützung fallen automatisch auf das bisherige Verhalten zurück. Ein großer Teil der Diskussion dreht sich um Datenschutz und Sicherheit. Wir sprechen über Fingerprinting, Cache-Probing und Cross-Site-Leaks sowie über die vorgeschlagene Public Hash List [https://github.com/tomayac/public-hash-list], die nur weit verbreitete oder explizit freigegebene Ressourcen für den globalen Austausch zulässt. Ergänzend sollen Browser bewusst gelegentlich falsche Antworten liefern („Greasing“), um Tracking über den gemeinsamen Speicher zu erschweren. Außerdem diskutieren wir, warum Browser-Caches nicht einfach erweitert wurden, sondern eine eigenständige API entstanden ist. Anschließend geht es um praktische Einsatzszenarien. Neben AI-Modellen profitieren auch große WebAssembly-Projekte wie Flutter, Emscripten oder Multimedia-Bibliotheken sowie Frameworks wie Nuxt und Next.js. Tom berichtet von ersten Erfahrungen mit der Browser-Erweiterung, die den aktuellen API-Stand bereits emuliert, sowie von Integrationen wie dem Vite Plugin für Cross-Origin Storage [https://github.com/tomayac/vite-plugin-cross-origin-storage]. Zum Abschluss werfen wir einen Blick auf den weiteren Standardisierungsprozess, die geplanten Browser-Experimente und darauf, wie Interessierte schon heute Feedback geben und eigene Erfahrungen sammeln können.

Links

Awesome Cross-Origin Storage [https://github.com/tomayac/awesome-cross-origin-storage/blob/main/readme.md] Sammlung aller Spezifikationen, Demos, Browser-Erweiterungen und weiterer Ressourcen rund um Cross-Origin Storage. Cross-Origin Storage auf Hugging Face [https://huggingface.co/blog/cross-origin-storage] Vorstellung der A

Revision 723: Cross-Origin Storage API – Caching über Origins hinweg, mit Thomas
Steiner

Wir sind diesmal zu viert: Schepp, Vanessa und Peter diskutieren mit Jon Uhlmann über Utility-First CSS und insbesondere Tailwind CSS [https://tailwindcss.com/]. Jon war bereits mehrfach bei uns zu Gast und meldete sich nach unserer Diskussion in Revision 715 [https://workingdraft.de/715/], weil ihm unsere damalige Einordnung von Tailwind zu einseitig erschien.

Wir nehmen das zum Anlass, Tailwind noch einmal ausführlicher mit klassischem CSS, komponentenbasierten Ansätzen und BEM [https://getbem.com/] zu vergleichen. Dabei geht es weniger um ein einfaches Dafür oder Dagegen als um Wartbarkeit, lokale und globale Abhängigkeiten, Designsysteme, unterschiedliche CSS-Kenntnisse in Teams sowie die Frage, wie sich Utility-Klassen auf KI-generierten Code auswirken.

Unser Sponsor



Alle reden von Automation – aber wo betreibst du eigentlich deine Tools?

Egal ob n8n oder andere Container-Setups: Mit dem Container-Hosting von mittwald läuft deine Anwendung in wenigen Minuten. Die nervige Konfiguration? Geht easy von der Hand – inklusive Vorschlägen für Umgebungsvariablen und Entrypoints.

Also: Fang an zu automatisieren. Dein erster Schritt ist ein Hosting bei mittwald. 👉 mittwald.de/workingdraft [https://mittwald.de/workingdraft?ref=workingdraft.de]

Shownotes

[00:01:44] Tailwind CSS zwischen Utility-Klassen, BEM und Scoped CSS [https://tailwindcss.com/] In Revision 715 [https://workingdraft.de/715/] hatten wir eine Hörendenfrage zu Tailwind beantwortet und dabei unter anderem die These aufgestellt, dass das Framework vor allem Teams mit weniger ausgeprägten CSS-Kenntnissen helfe. Jon widerspricht weniger dem Nutzen dieser Funktion als der Beschränkung darauf: Tailwind könne nicht nur fehlende Kenntnisse ausgleichen, sondern auch erfahrenen CSS-Entwicklerinnen und -Entwicklern eine angenehmere Developer Experience bieten.

Wir vergleichen Tailwind zunächst mit BEM [https://getbem.com/]. Während BEM über semantische Klassennamen Komponenten und Varianten organisiert, setzt Tailwind auf präsentationsbezogene Utility-Klassen. Jon betrachtet beide Ansätze nicht als gegenseitigen Ersatz. Für komplexe Layouts oder Spezialfälle greift er weiterhin zu eigenem CSS, während sich wiederkehrende Abstände, Farben und einfache Layout-Eigenschaften gut mit Utilities abbilden lassen.

Tailwind nimmt Entwicklerinnen und Entwicklern das Verständnis von CSS nicht vollständig ab. Wer ein gutes Design umsetzen möchte, muss weiterhin wissen, wie Layout, Kaskade und CSS-Eigenschaften funktionieren. Das Framework liefert jedoch eine begrenzte Auswahl an Abständen, Farben und weiteren Design-Tokens. Dadurch kann es einen konsistenten visuellen Rhythmus fördern und gleichzeitig neue CSS-Funktionen sichtbar machen, die im Projekt bereits zuverlässig eingesetzt werden können.

Komponentenbibliotheken wie daisyUI [https://daisyui.com/] oder shadcn/ui [https://ui.shadcn.com/] gehen noch einen Schritt weiter und stellen fertige Komponenten beziehungsweise wiederverwendbare Vorlagen bereit. Wir unterscheiden deshalb zwischen dem eigentlichen Utility-Ansatz und dem zusätzlichen Designsystem, den Konventionen und den Serviervorschlägen, die Tailwind mitbringt.

Ein kurzer Ausflug führt zu Tachyons [https://tachyons.io/]. Das ebenfalls Utility-basierte Framework entstand unter anderem aus der

Revision 722: Tailwind versus BEM, mit Jon Uhlmann

Wir sprechen mit Jonas Ulrich [https://www.linkedin.com/in/jonas-ulrich-ksds/] von der Ruhmesmeile [https://www.ruhmesmeile.com/] in Bonn über Designsysteme, Headless-CMS-Workflows und darüber, warum kickstartDS [https://www.kickstartds.com/de/] nicht nur als Komponentenfundament, sondern auch als strukturierte Wissensbasis für KI-gestützte Redaktionsarbeit interessant ist.

Nachdem Jonas bereits in Revision 538 [https://workingdraft.de/538/] und Revision 607 [https://workingdraft.de/607/] bei uns zu Gast war, schauen wir diesmal darauf, wie sich Designsysteme, JSON Schema [https://json-schema.org/], Model Context Protocol [https://modelcontextprotocol.io/] und Headless-Systeme wie Storyblok zu einem Workflow verbinden lassen, der Frontend, CMS und Redaktion enger zusammenbringt.

Unser Sponsor



Im Webcafé, dem Podcast zu Webentwicklung, Webdesign und Unternehmenskultur, nehmen euch Felix und Kay mit auf eine spannende Reise durch die Welt moderner Softwareentwicklung. Gerade ihre unterschiedliche Perspektive macht dabei den Reiz aus: Felix schaut als Geschäftsführer der Geenen IT-Systeme GmbH auf Strategie, Führung und Unternehmensentwicklung, Kay bringt als Technical Lead den Blick auf Technik, Tools und Architektur ein. Genau daraus entstehen ehrliche, fundierte und persönliche Gespräche über Webtechnologien, Zusammenarbeit und die Herausforderungen digitaler Arbeit.

Jetzt reinhören: geenen-it-systeme.de [https://geenen-it-systeme.de/?src=workingdraft#podcast]

Shownotes

[00:00:00] Designsysteme, Headless CMS und KI-gestützte Content Operations Jonas stellt zunächst Ruhmesmeile und den Weg von der klassischen Webagentur hin zu einer Boutique-Entwicklungsagentur vor, die sich auf nachhaltige Frontend-Architekturen und Designsysteme konzentriert. Ein zentrales Thema ist, dass nicht jedes Projekt ein eigenes Designsystem braucht. Dort, wo Projekte groß genug sind oder über längere Zeit konsistent wachsen sollen, kann ein Designsystem aber helfen, Qualität, Barrierefreiheit, Performance und Wiederverwendbarkeit skalierbar zu machen.

Wir sprechen darüber, wie kickstartDS [https://www.kickstartds.com/de/] aus der eigenen Agenturpraxis heraus entstanden ist: als wiederverwendbares Fundament für Marketing-Websites, Landingpages und ähnliche Oberflächen, bei denen sich Informationsarchitektur und Komponentenbedarf oft stärker ähneln, als man zunächst denkt. Wichtig ist Jonas dabei, dass kickstartDS nicht das nächste Bootstrap sein will, sondern eine systematische Anschubhilfe, auf deren Basis Teams weiterhin eigene Komponenten und spezifische Lösungen bauen können.

Ein großer Teil des Gesprächs dreht sich um die Verbindung von Designsystemen mit Headless-CMS-Systemen. Jonas erklärt, wie Ruhmesmeile Komponenten, Templates und Seitenstrukturen über JSON Schema [https://json-schema.org/] beschreibt und daraus CMS-Konfigurationen ableitet. Die Schema-Beschreibungen dienen dabei als Contract zwischen Frontend, Redaktion und Backend. So kann ein Converter Strukturen wie Page-Templates, Blog-Templates, Sections und Komponenten ins CMS übertragen und später auch Änderungen kontrolliert nachziehen. Dadurch wird Drift zwischen Frontend-Code und CMS-Modell reduziert.

Daraus ergibt sich auch der KI-Teil des Gesprächs: Weil die Frontend-Struktur bereits maschinenlesbar beschrieben ist, lässt

Revision 721: Designsysteme, Headless CMS und KI-gestützte Content Operations.
Mit Jonas Ulrich

We caught up with Chris Adams (LinkedIn [https://www.linkedin.com/in/mrchrisadams/] / Bluesky [https://bsky.app/profile/mrchrisadams.net] / Mastodon [https://mastodon.social/@mrchrisadams]) at mittwald’s [https://www.mittwald.de/] Head in the Cloud [https://www.mittwald.de/lp/head-in-the-cloud] festival to talk about one of the less visible aspects of our industry: the energy that powers the internet. Chris is Director of Tech and Policy at the Green Web Foundation [https://www.thegreenwebfoundation.org/], where he works on making the web less dependent on fossil fuels and helping the industry understand the environmental impact of our digital infrastructure.

Shownotes

[00:00:27] What does a Fossil-Free Internet look like in Germany? Chris starts by explaining why Germany is such an interesting place to discuss a fossil-free internet. As Europe’s largest economy and one of its most important data centre markets, Germany has a lot of leverage when it comes to making digital infrastructure more sustainable. At the same time, the German electricity mix can vary significantly depending on how much wind and solar power is available at any given moment.

The conversation is not only about building more renewable energy. Chris also highlights the importance of battery storage and making smarter use of the energy that is already available. The goal is to take advantage of periods with abundant renewable power and reduce the need to rely on fossil fuel generation.

A central theme is the growing demand for compute, particularly because of the current boom in generative AI. While large parts of the tech industry had been moving towards decarbonisation, the Green Web Foundation [https://www.thegreenwebfoundation.org/] now sees signs of a reversal, with new data centres being built that increase dependence on fossil fuels instead of reducing it.

From the State of the Fossil-Free Internet 2026 [https://www.thegreenwebfoundation.org/publications/state-of-the-fossil-free-internet-2026/] report, Chris derives three main areas of action. First, we need to manage demand for compute more consciously. Efficient software, thoughtful architecture and a more deliberate use of resources matter more than ever.

Second, we need to actually green the energy supply. Instead of relying only on certificates or offsetting emissions on paper, companies should choose providers that organise their power supply through a meaningful mix of renewable energy sources and storage.

The third point concerns the structure of the market itself. Chris argues for a more diverse ecosystem of hosting and cloud providers and warns against increasing concentration among a small number of hyperscalers. Their priorities do not always align with wider societal or climate goals, while a more diverse provider landscape can create more accountability and better sustainability outcomes.

In the end, the takeaway is that the energy powering digital services is not an abstract background detail. As developers and operators of digital products, we should understand where that energy comes from and which choices we can make to help build a more fossil-free internet.

Links

The Green Web Foundation [https://www.thegreenwebfoundation.org/] The organisation working towards a fossil-free internet and publishing research and tools around sustainable web development. State of the Fossil-Free Internet 2025 [https://www.thegreenwebfoundation.org/news/state-of-the-fossil-free-internet-2025/] The latest report on the internet’s dependence on fossil fuels and the actions needed to decarbonise digital infrastructure. Electricity Maps [https://app.electricitymaps.com/] A service for exploring the c

On Tour @ #headinthecloud – What does a Fossil-Free Internet look like? With
Chris Adams

Wir spielen wieder ARIA-Glücksrad und sprechen mit Paweł Masarczyk [https://www.linkedin.com/in/pawe%C5%82-masarczyk-3a68b2117/] (Mastodon [https://dragonscave.space/@Piciok]), Peter Krautzberger [https://www.peterkrautzberger.org/] (LinkedIn [https://www.linkedin.com/in/peter-krautzberger/] / Mastodon [https://bonn.social/@pkra]) und Marco Bretschneider [https://www.linkedin.com/in/marco-bretschneider-norderstedt/] (Mastodon [https://norden.social/@meise2000]) über ARIA-Rollen und -Attribute, die uns unser Glücksrad [https://workingdraft.de/gluecksrad/] ausspuckt. Daniela Kubesch [https://dnikub.dev/] (LinkedIn [https://www.linkedin.com/in/danikubesch/] / Bluesky [https://bsky.app/profile/dnikub.dev] / Mastodon [https://front-end.social/@dnikub]) musste leider erneut aussetzen, und Paweł wurde später von seiner Internetverbindung aus der Runde gewürfelt.

Wir arbeiten uns durch abstrakte Landmark-Rollen, praktische Landmark-Navigation, die Rolle option, aria-required, ariaNotify() und schließlich role="form". Dabei geht es wie immer darum, was die Spezifikation meint, was Browser und assistive Technologien daraus machen und wo native HTML-Elemente fast immer die bessere Wahl sind.

Shownotes

[00:02:28] role=“landmark“ [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/landmark_role] Zum Auftakt würfeln wir die abstrakte Landmark-Rolle. Wir sprechen darüber, warum es in ARIA überhaupt abstrakte Rollen gibt, obwohl sie nicht direkt verwendet werden dürfen, und stellen fest, dass sie vermutlich eher Browsern und Accessibility-APIs als Autorinnen und Autoren dienen. Anschließend biegen wir zu den konkreten Landmark-Rollen wie banner, navigation, main, contentinfo und complementary ab, die heute fast alle native HTML-Entsprechungen besitzen.Wir diskutieren außerdem, warum Elemente wie section [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/section_role] oder Formulare nur dann als Landmark sinnvoll sind, wenn sie einen zugänglichen Namen besitzen, und weshalb zu viele oder falsch verschachtelte Landmarks eher schaden als helfen. Schließlich fragen wir uns, ob Landmark-Navigation nicht auch für reine Tastaturnutzende interessant wäre, und verweisen auf Browser-Erweiterungen wie Landmark Navigation via Keyboard or Pop-up [https://chromewebstore.google.com/detail/landmark-navigation-via-k/ddpokpbjopmeeiiolheejjpkonlkklgp]. Außerdem überlegen wir, ob sich mit dem WebAIM Million Report [https://webaim.org/projects/million/] oder HTTP Archive herausfinden lässt, wie häufig abstrakte Rollen fälschlich eingesetzt werden. [00:24:40] role=“option“ [https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Roles/option_role] Die Rolle option wirkt zunächst wenig spannend, weil sie im Wesentlichen dem nativen option-Element entspricht. Interessant wird sie erst dann, wenn man sich eine eigene Listbox oder Combobox bauen muss, beispielsweise für durchsuchbare Select-Komponenten.Wir sprechen darüber, wie aufwendig solche Eigenbauten sind, weil neben der Semantik auch die gesamte Tastaturbedienung nachimplementiert werden muss. Deshalb hoffen wir auf die weitere Verbreitung von Customizable Selects und Customizable Multi-Selects [https://utilitybend.com/blog/an-update-on-customizable-selects-the-multiple-select]. Dabei streifen wir auch den aktuellen Stand von Interop 2026 [https://web.dev/blog/interop-2026] sowie einen kürzlich wieder aufgetauchten Datalist-Bug unter [https://adactio.com/journal/22360]

Revision 720: ARIA-Glücksrad – von abstrakten Rollen und konkreten Problemen

Wir waren dieses Jahr erneut auf der Head in the Cloud [https://www.mittwald.de/lp/head-in-the-cloud] von mittwald [https://www.mittwald.de/] in Espelkamp unterwegs und haben dort mit Torben Mallwitz [https://linkedin.com/in/torben-mallwitz] über einen Vortrag gesprochen, den man so vermutlich nur selten auf einer Konferenz hört. Torben, CTO von guenstiger.de [https://www.guenstiger.de/], hat sehr offen darüber berichtet, wie das Unternehmen im April 2025 Opfer eines Ransomware-Angriffs wurde und welche technischen, organisatorischen und menschlichen Herausforderungen die folgenden Tage und Wochen geprägt haben.

Shownotes

[00:00:27] Ransomware, Realität und Wiederherstellung Am Morgen des 23. April 2025 begann für das Team von guenstiger.de ein Ausnahmezustand. Nahezu sämtliche internen Systeme waren verschlüsselt worden, Daten waren offenbar abgeflossen und in jedem Verzeichnis fanden sich die typischen Lösegeldforderungen samt Verweis auf eine Seite im Darknet. Glück im Unglück: Die eigentliche Preisvergleichsplattform blieb weiterhin online und konnte zumindest in einem eingeschränkten Modus weiterbetrieben werden.

Torben beschreibt sehr eindrücklich, wie professionell die hinter der Qilin-Ransomware stehende Organisation arbeitet. Ransomware wird mittlerweile als „Ransomware as a Service“ betrieben. Die Angreifer agieren wie ein Unternehmen mit klaren Strukturen, Support, Hierarchien und sogar Partnerprogrammen. Die Kommunikation läuft über ein Chatfenster im Darknet und fühlt sich, von der kriminellen Komponente abgesehen, erstaunlich ähnlich zu einer gewöhnlichen Geschäftsbeziehung an.

Für guenstiger.de war schnell klar, dass externe Hilfe benötigt wird. Noch am ersten Tag wurden Spezialisten für Incident Response und Forensik hinzugezogen, die bei der Analyse, der Verhandlung mit den Angreifern und der Wiederherstellung der Systeme unterstützten. Ein wichtiges Learning aus dem Vorfall: In einer solchen Situation sollte man nicht versuchen, alles selbst zu lösen. Die emotionale Belastung und die Vielzahl der gleichzeitig auftretenden Probleme machen einen kühlen Blick auf die Lage nahezu unmöglich.

Besonders spannend ist die wirtschaftliche Perspektive, die Torben auf das Thema einnimmt. Die Entscheidung, Lösegeld zu zahlen, wurde nicht aus Panik getroffen, sondern als nüchterne Business-Entscheidung. Der Zeitgewinn bei der Wiederherstellung der Systeme und die Bedeutung eines möglichst geringen Vertrauensverlusts gegenüber Kunden und Partnern überwogen letztlich die Alternative, alles ausschließlich aus Backups und manuellen Prozessen wieder aufzubauen.

Überraschend ist auch die Professionalität der Angreifer nach der Zahlung. Als die bereitgestellten Entschlüsselungswerkzeuge nicht überall funktionierten, gab es tatsächlich Support und Nachbesserungen. Das mag zunächst absurd wirken, folgt aber einer internen Logik: Das Geschäftsmodell der Erpresser basiert darauf, dass sich herumspricht, dass nach einer Zahlung auch tatsächlich geliefert wird.

Natürlich blieb es nicht bei der Wiederherstellung. Der Vorfall wurde genutzt, um die eigene Infrastruktur grundlegend zu modernisieren. Neue Sicherheitsmaßnahmen, Multi-Faktor-Authentifizierung, stärker zentral verwaltete Geräte und eine überarbeitete Systemarchitektur sollen zukünftige Angriffe erschweren. Daneben setzt das Team inzwischen verstärkt auf Notfallübungen und Planspiele, um im Ernstfall schneller und koordinierter reagieren zu können.

Ein zentrales Fazit des Gesprächs lautet dabei: Absolute Sicherheit gibt es nicht. Moderne IT-Systeme sind zu komplex und die Angriffsvektoren zu vielfältig. Ziel kann daher nur sein, die eigenen Systeme möglichst widerstandsfähig und als Angriffsziel möglichst unattraktiv zu machen.

Das Video zum Talk wird zeitnah auf dem YouTube Kanal von Mittwald [https://www.youtube.com/@mittwald] v

On Tour @ #headinthecloud – Der Randomware-Angriff auf guenstiger.de mit Torben
Mallwitz

Wir haben diese Revision mit Florian Sowade [https://de.linkedin.com/in/floriansowade] über den EU AI Act gesprochen. Florian hat sich in die Regulierung eingelesen und erklärt uns, was die EU damit eigentlich regulieren will, welche Risikokategorien es gibt und warum der Act nicht primär ein Verbot von KI ist.

Gemeinsam sortieren wir ein, welche Pflichten schon gelten, welche noch kommen, warum Hochrisiko-Anwendungen anders behandelt werden als alltägliche KI-Tools und weshalb gerade Transparenz, Schulungspflichten, Trainingsdaten, Deepfakes und Auditierbarkeit in der Praxis noch viele offene Fragen aufwerfen.

Shownotes

[00:01:03] EU AI Act [https://de.wikipedia.org/wiki/Verordnung_%C3%BCber_k%C3%BCnstliche_Intelligenz] Florian erklärt den EU AI Act als Versuch der EU, den Einsatz von KI zu regulieren, nicht zu verbieten. Im Zentrum steht eine Einteilung nach Risiko: inakzeptables Risiko, hohes Risiko, begrenztes Risiko und niedriges beziehungsweise nicht explizit reguliertes Risiko. Verboten sind etwa Social Scoring, bestimmte biometrische Identifikation im öffentlichen Raum und manipulative Systeme. Hochrisiko-Anwendungen betreffen Bereiche wie Kreditwürdigkeit, Recruiting, Medizin, Migration, Grenzkontrolle oder Rückfallprognosen. Dort braucht es unter anderem menschliche Kontrolle, Risikomanagement und teilweise Folgenabschätzungen.

Beim begrenzten Risiko geht es vor allem um Transparenz: Menschen sollen wissen, wenn sie mit einer KI interagieren oder wenn Bilder, Videos oder Texte KI-generiert sind. Peter und Florian diskutieren, wie gut solche Pflichten überhaupt durchsetzbar sind, ob sich daraus ähnliche Effekte wie bei Cookie-Bannern ergeben könnten und wo Missbrauch oder „malicious compliance“ naheliegen. Die niedrigste Kategorie umfasst Anwendungen wie Spamfilter, KI in Spielen, Übersetzungen, Zusammenfassungen oder alltägliche Textarbeit, die nicht weiter reguliert sind.

Ein größerer Teil des Gesprächs dreht sich um die Frage, was im Gesetz überhaupt als KI gilt. Da die Arbeit am Act bereits vor dem Durchbruch von Large Language Models begonnen hat, ist der Begriff nicht nur auf neuronale Netze oder Chatbots beschränkt. Entscheidend ist eher, ob ein System aus Daten lernt und daraus automatisiert Entscheidungen oder Empfehlungen ableitet. Das führt zu Grenzfällen, etwa bei Workflow-Tools, Coding-Assistenten oder automatisierten Entscheidungen in regulierten Branchen.

Florian ordnet außerdem ein, was der Act für Unternehmen bedeutet. Für seinen eigenen Arbeitskontext sieht er vor allem Schulungspflichten, interne Richtlinien und bewussten Umgang mit Daten als relevant an. Coding-Assistenten fallen nach seinem Verständnis nicht automatisch in Hochrisiko-Regeln, solange am Ende nachvollziehbarer Code entsteht. Kritisch wird es, wenn KI-Systeme selbst Entscheidungen treffen oder wenn generierter Code in Bereichen eingesetzt wird, in denen Grundrechte oder Lebensentscheidungen betroffen sind.

Zum Schluss sprechen wir über Bußgelder, offene Fristen, Kritik von Industrie und Netzpolitik, Transparenzpflichten für Modellanbieter, Trainingsdaten, Urheberrecht, Deepfakes, Watermarking und die Frage, wie sich KI langfristig in bestehende Software und Regulierung einfügt. Florian vermutet, dass der EU AI Act im Alltag vieler Entwicklerinnen und Entwickler eher im Hintergrund bleiben wird, aber bei Hochrisiko-Anwendungen sinnvolle zusätzliche Anforderungen schafft.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

Revision 719: Der EU AI Act, mit Florian Sowade

Wir waren dieses Jahr erneut auf der Head in the Cloud [https://www.mittwald.de/lp/head-in-the-cloud] von mittwald [https://www.mittwald.de/] in Espelkamp unterwegs und haben die Gelegenheit genutzt, mit André Richter [https://www.linkedin.com/in/schnittsteller/] über die Zukunft der Website zu sprechen. André ist seit den frühen Tagen des Webs im Agenturumfeld unterwegs und beschäftigt sich heute als Director Digital Experience mit der Frage, wie Unternehmen auch in einer von KI geprägten Welt digital relevant bleiben können.

Shownotes

[00:00:26] Die Website der Zukunft Sterben Websites aus? Für André Richter lautet die Antwort: nein, aber sie verändern sich grundlegend. Die klassische Vorstellung einer Website als Sammlung von Seiten, die Menschen direkt im Browser aufrufen, verliert an Bedeutung. Stattdessen werden Inhalte und Funktionen zunehmend über Chatbots, Large Language Models und andere Interfaces vermittelt. Die Website bleibt dabei die digitale Repräsentanz eines Unternehmens, muss ihre Rolle aber neu definieren.

Im Mittelpunkt steht für André die Idee, dass eine Website immer ein Versprechen ist: Sie soll Menschen bei einem konkreten Problem helfen. Diese Funktion bleibt bestehen, auch wenn die Kommunikation künftig häufiger über Maschinen stattfindet. Webseiten werden daher nicht nur für menschliche Besucher, sondern zunehmend auch für KI-Systeme gestaltet werden müssen.

Als Denkmodell führt André seine „fünf I“ ein: Interaktion, Individualisierung, Interfaces, Inhalte und Infrastruktur. Nutzer interagieren anders mit Webseiten als noch vor wenigen Jahren und erwarten Antworten statt Linklisten. Gleichzeitig ermöglicht KI eine bislang ungeahnte Personalisierung, bei der Inhalte situativ und individuell zusammengestellt werden können. Hinzu kommen neue Interfaces jenseits des klassischen Bildschirms sowie die Frage, wie Inhalte strukturiert und technische Infrastruktur möglichst souverän und unabhängig betrieben werden können.

Besonders ausführlich sprechen wir über Inhalte. Unternehmen müssten sich viel stärker damit auseinandersetzen, was sie tatsächlich einzigartig macht. Generische Ratgebertexte und austauschbare Marketingfloskeln verlieren an Wert. Stattdessen sollten Webseiten konkrete Fragen beantworten, Probleme lösen und den eigenen Mehrwert klar herausstellen.

Technisch sieht André viele Parallelen zu den bekannten Disziplinen aus SEO und Barrierefreiheit. Semantische Strukturierung, sauber aufbereitete Inhalte und maschinenlesbare Informationen bleiben entscheidend. Wer bereits gelernt hat, Inhalte so aufzubereiten, dass Suchmaschinen und assistive Technologien sie verstehen können, bringt gute Voraussetzungen für die Welt der KI-getriebenen Suche mit.

Schließlich diskutieren wir die Frage, wie Erfolg künftig gemessen werden kann. Wenn immer weniger Nutzer direkt auf Webseiten landen, verlieren klassische Metriken wie Besucherzahlen oder Rankings an Aussagekraft. Stattdessen werden qualitative Faktoren wichtiger: Werden Nutzerbedürfnisse erfüllt? Entsteht Vertrauen? Werden die richtigen Inhalte von KI-Systemen aufgegriffen? Und wie gut gelingt es Unternehmen, bestehende Kundenbeziehungen zu pflegen und auszubauen?

Das Video zum Talk wird zeitnah auf dem YouTube Kanal von Mittwald [https://www.youtube.com/@mittwald] verfügbar sein.

Diskutiert die Folge mit uns in unserem Community-Slack: https://draft.community/

On Tour @ #headinthecloud – Die Website der Zukunft mit André Richter

Wir sprechen mit Patrick Lauke [https://www.splintered.co.uk/] (LinkedIn [https://www.linkedin.com/in/redux/], Mastodon [https://mastodon.social/@patrick_h_lauke], Bluesky [https://bsky.app/profile/did:plc:bk7qw66tikjbjux7cywqrsij]) und Peter Krautzberger [https://www.peterkrautzberger.org/] (LinkedIn [https://www.linkedin.com/in/peter-krautzberger/], Mastodon [https://mastodon.social/@pkra@bonn.social]) über die WCAG [https://www.w3.org/WAI/WCAG22/Understanding/], ihre Success Criteria und die Frage, warum ein Standard, der auf den ersten Blick sehr eindeutig wirkt, in der Praxis oft viel Interpretationsspielraum lässt.

Wir sprechen darüber, warum WCAG 2.x trotz ihrer Schwächen weiterhin die Grundlage vieler Audits und gesetzlicher Anforderungen ist, wie sich neue Erfolgskriterien additiv an ältere anhängen, warum das nicht immer elegant ist und wie Patrick im WCAG-GitHub-Repository [https://github.com/w3c/wcag/] und der Backlog-Arbeit versucht, offene Fragen und Grauzonen besser zu klären.

Shownotes

[00:00:56] WCAG, Success Criteria und Interpretationsspielräume [https://patrickhlauke.github.io/wcag-interpretation/] Wir steigen mit Patricks und Peters Hintergrund ein: Patrick arbeitet bei Tetralogical im Accessibility Consulting, war früher bei Opera und ist unter anderem im W3C-Kontext aktiv. Peter arbeitet im akademischen Verlagswesen, ist in der ARIA Working Group und Co-Editor der ARIA-Spezifikation. Von dort aus landen wir bei der WCAG 2.2 [https://www.w3.org/WAI/WCAG22/Understanding/] und der Frage, wie belastbar ihre Erfolgskriterien eigentlich sind.

Patrick beschreibt die WCAG als Standard, der objektiv und binär wirkt, in der Praxis aber oft Interpretationsarbeit verlangt. Ein Kriterium kann formal nach Pass oder Fail aussehen, aber sobald man echte Interfaces, echte Nutzer:innen und echte Audit-Situationen betrachtet, entstehen Grauzonen. Besonders schwierig wird das, weil WCAG in Gesetze und Standards hineinreferenziert wird, etwa über den EAA, EN 301 549, BITV oder andere nationale Regelungen. Damit hängen an der Auslegung nicht nur Best Practices, sondern auch Compliance, Haftungsfragen und wirtschaftlicher Druck.

Ein erstes Beispiel ist 1.1.1 Non-text Content: Alle wissen, dass Bilder, Audiohinweise oder andere Nicht-Text-Inhalte Alternativen brauchen, aber was eine „gute“ Alternative ist, hängt stark vom Kontext ab. Ist ein Speaker-Foto dekorativ, wenn der Name danebensteht? Oder gehört eine Beschreibung des Aussehens dazu? Schon hier zeigt sich, dass selbst das erste Erfolgskriterium nicht rein mechanisch prüfbar ist.

Weiter geht es mit Target Size aus WCAG 2.1 und 2.2. Patrick erklärt, dass die Formulierung theoretisch sogar einen ein Pixel großen Link bestehen lassen kann, wenn rundherum genug Abstand vorhanden ist. Das wäre formal eventuell ein Pass, praktisch aber ein schlechtes Interface. Genau solche Fälle zeigen, dass man WCAG nicht als vollständige Usability-Spezifikation missverstehen sollte.

Ein weiterer großer Block dreht sich um das additive Modell von WCAG 2.x. Ältere Success Criteria werden in Minor-Versionen nicht grundlegend umgeschrieben, damit neuere Fassungen rückwärtskompatibel zu bestehenden gesetzlichen Referenzen bleiben. Stattdessen kommen neue Kriterien hinzu. Das erklärt Überschneidungen wie zwischen Pointer Gestures und Dragging Movement. Patrick beschreibt, wie er in den nicht-normativen Understanding-Dokumenten Beispiele und Erklärungen verschoben und präzisiert hat, ohne den normativen Kern der Spezifikation umzudeuten.

Wir sprechen außerdem über Reflow und die Frage, wie sinnvoll sehr konkrete Grenzwerte wie 320 CSS Pixel sind. Die Idee dahinter ist klar: Inhalte sollen bei starkem Zoom nicht in zwei Richtungen gescrollt werden müssen. In der Praxis entstehen aber neue Frage

Revision 718: WCAG: Pass, Fail oder kommt drauf an?

Der wöchentliche Podcast für Webdesigner:innen und -entwickler:innen. Supported
uns bei Patreon: https://patreon.com/workingdraft

Working Draft

Revision 724: Die VoidZero-Akquisition, mit Alexander Lichter

Revision 723: Cross-Origin Storage API – Caching über Origins hinweg, mit Thomas Steiner

Revision 722: Tailwind versus BEM, mit Jon Uhlmann

Revision 721: Designsysteme, Headless CMS und KI-gestützte Content Operations. Mit Jonas Ulrich

On Tour @ #headinthecloud – What does a Fossil-Free Internet look like? With Chris Adams

Revision 720: ARIA-Glücksrad – von abstrakten Rollen und konkreten Problemen

On Tour @ #headinthecloud – Der Randomware-Angriff auf guenstiger.de mit Torben Mallwitz

Revision 719: Der EU AI Act, mit Florian Sowade

On Tour @ #headinthecloud – Die Website der Zukunft mit André Richter

Revision 718: WCAG: Pass, Fail oder kommt drauf an?