Roastidio.us Tagged with web

Link Previews and You | Sable

Fri, 13 Nov 2026 23:32:40 +0000

If you’re an avid user of programs like Discord, you might be familiar with the venerable ‘link preview’. This is a little block that shows below a link, and hints at what might lie on the other end of that URL. These are a little messaging convenience that allows for many things, like conveniently sharing social media posts without logging into a platform and providing a description for a blog post. It encourages sharing: the open internet is built on a diversity of open websites, where people can freely view content without stepping into walled gardens and discourse chambers.

Discord, as a centralised platform, employs their servers to visit web pages for you, grab metadata from tags specified in markup headers, and caches that response. Clients then query that server to get a structured response on what a link preview should look like, and can easily render it without much hassle.

Signal has to go about this problem in a different way. Signal doesn’t know what websites you send people in messages, and they don’t want to. They also don’t want users to be able to send each other websites that would reveal information about them. For example, let’s say I own evil.example, and I’m listening closely for every connection to my servers. If I send you a link from that domain, your phone will try and find information about that webpage, and a poor implementation could leak things like your IP address, which is information that could be used to narrow the scope of a search into where you are currently located at.

So Signal doesn’t do that. Signal generates the preview on the sender’s device, which means the sender takes on the privacy burden for fetching data from a message, and my evil server can’t track your device unless I tell you to send me a link from my website, which is a much harder attack to perform.

An overview of strategies in Matrix, and why we’re deviating

At first, there was the /preview_url Client-Server API endpoint. In short, this is used to fetch a preview from your homeserver, and display it with a message. This essentially mirrors the “Discord” model, of deferring to a server. Privacy-minded people may be concerned about their homeserver (which they might not run) observing usage of this endpoint to find out which websites people are sending each other in encrypted rooms, so clients usually disable this behavior in encrypted rooms.

Supplementally, preview bots showed up: user accounts that listen for links and generate preview messages. Decoupling this behavior from the homeserver may be desirable if you happen to have opinions on how link previews should be displayed, or fetched. There’s a couple of issues with this, principally that this is quite inconvenient in Private Messages, and that to ensure privacy users would have to run their own bots. (Which we aren’t going to ask our users to do.)

To address these issues, MSC4095: Bundled URL Previews adds the ability for clients to attach previews directly to messages. This mirrors the Signal approach somewhat, as it makes the sender generate the preview.

Hold on– the sender has to generate it? We’re principally a web client. Most of our users would prefer to download our program, either on mobile, or on desktop, but we have web users we can’t just abandon. The issue is CORS: a limitation that stops websites from just sending network requests to random websites. Essentially, we can’t do this for all users unless we find a server.

This ended up with us having a server that generates link previews for web users, and a client that generates link previews, both with different behaviour. This is also complicated with homeserver previews, so we essentially had three different ways to get link previews.

Standardising how we generate link previews

We moved link preview generation into a separate library, which lets us do fun things. We can now make architectural decisions on where we do link previews without doing a ton of refactoring work.

One thing this allowed us to do is to think about how we handle social media previews better. We now have an OpenGraph extension specification for specifying a social media ‘note’, as Matrix link previews are OpenGraph based. We have scrapers for handling major social media websites, Atproto, and the Fediverse, and we can work on making these better separately from the rest of our codebase and infrastructure. We now format notes separately from default previews, which is shaped more like a social media note.

Another thing we are experimenting with now is a privacy-preserving proxy server, which Signal used to run for generating link previews, but has since rolled back this change. Our monolithic media-server-thing Soliditas is now free from CloudFlare and running on our own infrastructure, and runs a proxy for all clients to use which should hopefully be useful for everyone. Whether this is successful will depend on a lot of things: whether we can scale up infrastructure to meet demand, whether we can harden this service against abuse, whether sites decide to block our user agents, and more. You can donate to us to help balance the scales in this project’s favor.

The future of link previews, with us and otherwise

We’re excited to continue trying to make link previews good. We’re working on making our user interface clearer, so that the privacy implications of using this feature are more obvious to the user. We’re also interested in furthering support for note previews, so users can see better previews for more services.

We might look into eliminating use of the homeserver for generating link previews entirely, at least temporarily. If we can provide a meaningful benefit to how previews are generated, users might get frustrated with us at inconsistencies between previews coming from Sable versus their homeservers. In that case, we would like to create MSCs and work with the ecosystem. Our advantage is that as a new, fast-moving project we can figure out where things fail in practice, and then come to the wider community with a proposal that’s been informed by real users.

That’s our attitude in general: we’re trying out things. Matrix has been slow-moving for a long time (we’ve all heard complaints about it) and Sable hopes to be a client that sits far ahead of the specification, making experimental implementations and helping inform future movement for the protocol at large.

~ Daisy Forest, UX Engineer @ Sable

Would you reconsider your Tufte CSS sidenotes? | Kyou

Fri, 13 Nov 2026 02:25:37 +0000

Sidenotes are nice, and Tufte CSS beautifully demonstrates a way to incorporate sidenotes into the Web to be compatible with both wider views and narrower screens, with a little bit of CSS magic. ²

Like this! This is a sidenote.

Tufte CSS builds its sidenotes and margin notes upon inlined HTML elements plus a rather well-known CSS checkbox trick:

You write your sidenote inline, like this:

As it is one of the few styles that default to using serif fonts ( they use the ET Book font, a font designed by Dmitry Krasny, Bonnie Scranton, and Edward Tufte ), I love Tufte CSS nevertheless.
Then, you wrap your note up with a span element with a label as the sidenote reference:

As it is one of the few styles that default to using serif fonts <label>...</label><span class="sidenote"> ( they use the ET Book font, a font designed by Dmitry Krasny, Bonnie Scranton, and Edward Tufte )</span>, I love Tufte CSS nevertheless.
With tufte.css, the note should now be extracted from its context by browsers’ layout engines, and displayed on the side, just like any sidenote does:

As it is one of the few styles that default to using serif fonts ( they use the ET Book font, a font designed by Dmitry Krasny, Bonnie Scranton, and Edward Tufte ), I love Tufte CSS nevertheless.

Sidenotes are automatically numbered using CSS counters in Tufte CSS. (This page doesn’t do that, though.)
Since sidenotes take a significant portion of horizontal space, they don’t really fit on mobile screens or narrow browser windows:

You probably don’t want your text to get clamped to the left half of the already narrow screen:

As it is one of the few styles that default to using serif fonts ( sidenote ), I love Tufte CSS nevertheless.

Or, if you are reading on a rather narrow screen right now, you probably don’t want your text to look like this page. :p

Tufte CSS makes use of the checkbox CSS hack to make sidenotes collapsible on narrower screens:

As it is one of the few styles that default to using serif fonts ( they use the ET Book font, a font designed by Dmitry Krasny, Bonnie Scranton, and Edward Tufte ), I love Tufte CSS nevertheless.

(For the sake of demonstration, I didn’t style the checkbox. You may try toggling the checkbox to see how it controls the display of the “sidenote”.)

This sounds really good: mobile-friendly, JavaScript-less sidenotes! Also, arguably, sidenotes are actually better suited on the web than footnotes, as web pages are quite different from book pages, and the footnotes, if placed in the “footer” of a web page, can be a pain to navigate to.³ I’ve seen quite a few blog sites heavily using Tufte-CSS-like sidenotes and they all work pretty well… until they don’t.

Unless they provide links and backlinks to jump back and forth between footnotes and their references.

The anti-marketing aspect of the Gemini network

Thu, 12 Nov 2026 17:42:28 +0000

The anti-marketing aspect of the Gemini network

by Ploum on 2026-11-12

And why your niche should stay a niche

I like Gemini. Not the Google Chatbot but the network that existed before Google named its product. If you are enough of a geek, you may want to give it a try.

Creating a Blog in Gemini:// (brennan.day)

Eoin is counting the number of "capsules" on the Gemini network. A capsule is the equivalent of a "website" on the Web or a "hole" on Gopher. It’s a personal space, a bunch of pages. Blogs become "gemlogs".

Eoin’s first observation is that the number of active capsules is slowly growing. The network is healthy.

But his second observation is really interesting: there’s absolutely no correlation between the number of new capsules in a given month and articles about the Gemini protocol being promoted on the first page of Hacker News.

This is a confirmation of what I’ve benn trying to explain for years: your metrics and web statistics are completely useless. The number of visitors, the number of clicks are worthless if you are not a marketer trying to extract money from a big brand. They don’t mean anything.

By the way: you should really avoid Hacker News these days. The front page is heavily manipulated to promote pro-AI stuff and bury everything that might question wether fascism-capitalism is good.

Why is Hacker News like that? (drewdevault.com)

A Mozilla employee is leaving after 15 years and comes to a similar conclusion. Mozilla is awesome because it has always been abnormal. It is mostly used by abnormal people. This means that hiring "normal managers" who try to make it "normal" and chase "normal" metrics is, of course, a recipe for failure.

jr conlin's ink stained banana (blog.unitedheroes.net)

I always failed to understand those marketing people who try to be "like others but a bit cheaper". While all the value is being different enough to nurture your own niche.

I completely removed statistics from my blog in 2013. At the time, I had a very strong realisation that the blog posts that mattered most, those I was proudest of, and those that prompted people to mail me even years later all had mediocre statistics.

How I Learned to Stop Worrying and Love the Web (ploum.net)

On the contrary, most of my hit, my "buzz", were quickly forgotten. But, being addicted to statistics, I was unconsciously adapting my writing style to improve those numbers. I was scrolling through social media posts that were highly popular while trying to create some myself.

Closing my social media accounts and, instead, procrastinating on Gemini had the opposite effect: making me read other ideas without caring about reactions, about popularity. Jsreed5 made the same observation while he was trying the Nostr protocol. While Nostr’s technicalities may be interesting by themselves, the content on it is similar to the one found of mainstream social networks. And our smolnet Gemini-formatted brains cannot take it anymore!

A Geminaut's View of Nostr (jsreed5.org)

We really need a simple Gemini hosting provider that would also provide a Web version, to welcome less technical-minded people who still may want to access a quieter, non-commercial, out-of-time virtual space.

Lot of people are trying Gemini and find that there’s no content on it, that they can’t have their news and dopamine hit on it. Well, that’s exactly the point.

There Is No Content on Gemini (ploum.net)

The fact that only a niche minority want to use it is also part of the point. Gemini might no be for you. That’s fine. The modern Web and even the real world (where every device is actively working against me and every human interaction seems to be about AI) is increasingly not for me. So let me have my strange niche space.

About the author

I’m Ploum, a writer and an engineer. I like to explore how technology impacts society. You can subscribe by email or by rss. I value privacy and never share your adress.

I write science-fiction novels in French. For Bikepunk, my new post-apocalyptic-cyclist book, my publisher is looking for contacts in other countries to distribute it in languages other than French. If you can help, contact me!

Bildrechte Unternehmenswebsite Italien: KMU-Leitfaden

Wed, 11 Nov 2026 21:51:25 +0000

Wenn Du Fotos auf einer Unternehmenswebsite in Italien veröffentlichst, musst Du Bildrechte fast immer auf drei Ebenen getrennt prüfen: Urheberrecht am Foto, Recht am eigenen Bild der erkennbaren Person und DSGVO, sobald Personen direkt oder indirekt identifizierbar sind. Genau an dieser Stelle entstehen bei kleinen Unternehmen in Südtirol die meisten Fehler, weil oft deutsche Muster übernommen werden, obwohl für Italien eigene Normen und eine eigene Praxis relevant sind.

Ich sehe das in der täglichen Arbeit mit KMU sehr oft: Ein Shooting wurde bezahlt, die Bilder sind schön, die neue Website ist fast fertig – und erst kurz vor dem Launch fragt jemand, ob Mitarbeiterfotos, Baustellenfotos oder ein Fahrzeug mit sichtbarem Kennzeichen überhaupt veröffentlicht werden dürfen. Dann wird hektisch nach Freigaben gesucht. Besser ist ein sauberer Prozess vor dem Upload.

Für eine Unternehmenswebsite in Italien gilt eine einfache Grundregel: Ein Foto darf nicht online, nur weil Du es besitzt, bezahlt hast oder technisch darauf zugreifen kannst. Entscheidend sind die geklärten Nutzungsrechte, die zulässige Veröffentlichung und eine nachvollziehbare Dokumentation.

Gerade in Südtirol ist die Verwechslung mit deutscher Rechtslage besonders häufig. Sprachlich orientieren sich viele Betriebe an Deutschland oder Österreich, rechtlich gilt für die Website aber die italienische und europäische Grundlage. Wenn Du Deine Unternehmenswebsite strategisch aufbaust, sollte die Rechteklärung deshalb genauso selbstverständlich sein wie Design, Texte und Technik.

Bildrechte auf der Unternehmenswebsite in Italien: Was Du wirklich prüfen musst

Für eine saubere Veröffentlichung trenne ich in Projekten immer drei Fragen:

Wer hat das Foto gemacht? Diese Frage betrifft das Urheberrecht und die Nutzungsrechte.
Wer ist auf dem Foto erkennbar? Diese Frage betrifft das Recht am eigenen Bild und die Veröffentlichung von Personenabbildungen.
Kann eine Person identifiziert werden? Diese Frage betrifft Datenschutz und DSGVO.

Diese Trennung bringt sofort Klarheit. Ein Beispiel: Ein externer Fotograf erstellt Mitarbeiterfotos für die Teamseite. Dann brauchst Du nicht nur eine vertragliche Regelung mit dem Fotografen, sondern meist auch eine klare Freigabe der abgebildeten Personen und eine saubere Dokumentation, wofür die Bilder verwendet werden dürfen.

Urheberrecht: Wem gehört das Foto wirklich?

Beim Urheberrecht starten viele Unternehmen mit der falschen Annahme. Das Urheberrecht am Foto liegt in Italien grundsätzlich beim Fotografen. Laut dem italienischen Urheberrechtsgesetz, dargestellt über WIPO Lex, hat der Fotograf nach Art. 88 des Gesetzes Nr. 633/1941 grundsätzlich das ausschließliche Recht zur Vervielfältigung, Verbreitung und Verwertung des Fotos. Das Gesetz kennt zwar Ausnahmen, etwa bei bestimmten bestellten Porträts oder Aufnahmen von Sachen des Auftraggebers, aber genau deshalb solltest Du nie pauschal annehmen, dass „bezahlt“ automatisch „frei nutzbar“ bedeutet.

Für die Praxis heißt das:

Ein bezahltes Shooting ersetzt keinen Nutzungsrechte-Vertrag.
Ein Download-Link ersetzt keine Rechteklärung.
Eine Rechnung ersetzt keine Freigabe für Website, Social Media, Recruiting und Print.

Ich empfehle bei jedem Shooting eine kurze schriftliche Regelung mit mindestens fünf Punkten: Wer ist Urheber, welche Nutzungsrechte werden übertragen, für welche Kanäle gilt die Nutzung, ist die Nutzung zeitlich begrenzt oder unbefristet, und darf der Fotograf die Bilder selbst für Eigenwerbung nutzen.

Wichtig ist auch der Blick auf Archivbilder. Ein altes Foto ist nicht automatisch frei. Nach Richtlinie 2006/116/EG auf EUR-Lex beträgt die Schutzdauer des Urheberrechts in der EU grundsätzlich 70 Jahre nach dem Tod des Urhebers. Für Unternehmensarchive heißt das: Auch historische Aufnahmen können noch geschützt sein.

Recht am eigenen Bild in Italien: Die Person auf dem Foto ist ein eigener Rechtsbereich

Selbst wenn die Nutzungsrechte am Foto geklärt sind, ist die Veröffentlichung noch nicht automatisch erlaubt. In Italien wird das Recht am eigenen Bild nach gefestigter Darstellung unter anderem durch Art. 10 Codice Civile sowie durch Art. 96 und 97 des Gesetzes Nr. 633/1941 geregelt. Eine gute Zusammenfassung dazu findest Du bei Bugnion.

Für kleine Unternehmen ist der praktische Kern einfach: Sobald eine Person erkennbar ist und das Bild auf der Unternehmenswebsite für Außendarstellung, Vertrauen, Recruiting oder Werbung eingesetzt wird, solltest Du die Veröffentlichung nicht auf bloße Gewohnheit stützen. Du brauchst eine klare Grundlage und eine saubere Freigabe.

Das betrifft besonders:

Mitarbeiterfotos auf Teamseiten
Gruppenfotos aus dem Betrieb
Kunden oder Partner in Referenzfotos
Eventbilder von Eröffnungen, Messen oder Feiern
Baustellenfotos, wenn Personen im Vorder- oder Hintergrund erkennbar sind

In meiner Praxis ist genau das der häufigste Stolperstein: Das Team stimmt einem Shooting locker zu, aber niemand hält fest, ob die Bilder nur intern, nur für die Unternehmenswebsite oder auch für Social Media, Stellenanzeigen und Broschüren gedacht sind. Später gibt es Unsicherheit, und Unsicherheit ist bei Bildrechten fast immer ein Zeichen für fehlende Dokumentation.

DSGVO bei Fotos, Mitarbeiterfotos und Kennzeichen

Die DSGVO kommt zusätzlich ins Spiel, wenn auf Fotos personenbezogene Daten verarbeitet werden. Laut dem European Data Protection Board sind Fotos personenbezogene Daten, wenn eine Person direkt oder indirekt identifizierbar ist. Für die Unternehmenswebsite heißt das: Ein erkennbares Gesicht, eine typische Arbeitssituation, ein Namensschild oder eine Kombination mehrerer Merkmale kann bereits datenschutzrechtlich relevant sein.

Das gilt nicht nur für Gesichter. Auch Kennzeichen können personenbezogene Daten sein, wenn eine Zuordnung zu einer Person direkt oder indirekt möglich ist. Die CNIL nennt Fahrzeugkennzeichen ausdrücklich als Beispiel für indirekte Identifizierbarkeit. Für Fuhrparkfotos, Servicefahrzeuge und Baustellenbilder ist das wichtig.

Praktisch bedeutet das:

Ein Foto eines Firmenwagens mit Logo ist oft unkritischer als ein Foto, auf dem zusätzlich ein lesbares Kennzeichen, ein Fahrer und ein privater Wohnort erkennbar sind.
Ein Baustellenfoto wird schnell sensibel, wenn Monteure, Nachbarn, Hausnummern, Kennzeichen oder private Gegenstände erkennbar sind.
Ein Gruppenbild vom Team ist datenschutzrechtlich nicht „harmlos“, nur weil alle freundlich in die Kamera schauen.

Bei Mitarbeiterfotos ist eine schriftliche, konkrete und freiwillige Einwilligung in der Praxis meist die sauberste Lösung für die Außendarstellung. Die Freigabe sollte nicht allgemein formuliert sein, sondern den Verwendungszweck benennen: Website, Teamseite, Recruiting, Social Media, Print oder Presse.

Typische Fälle auf Unternehmenswebsites in Südtirol und Italien

Motivtyp	Rechtliches Risiko	Was zu klären ist	Einwilligung nötig?	Empfohlene Dokumentation
Mitarbeiterporträt	Mittel bis hoch	Urheberrecht des Fotografen, Veröffentlichung, Verwendungszwecke	In der Praxis meist ja, schriftlich und konkret	Foto-Freigabe, Kanalumfang, Datum, Ablageort
Teamfoto	Mittel bis hoch	Alle erkennbaren Personen, spätere Kanäle, Ausscheiden einzelner Mitarbeiter	Meist ja	Namensliste der Abgebildeten, Freigaben, Dateinummer
Baustellenfoto	Mittel bis hoch	Personen im Hintergrund, Kennzeichen, Hausnummern, Logos Dritter, Auftraggeberbezug	Nur wenn Personen erkennbar oder Nutzung sensibel ist; oft prüfen	Projektzuordnung, Prüfung sensibler Details, bearbeitete Version
Fahrzeugfoto mit Logo und Kennzeichen	Mittel	Nutzungsrechte am Foto, Sichtbarkeit von Kennzeichen, Bezug zu Personen	Nicht immer, aber Kennzeichen prüfen oder unkenntlich machen	Freigabe des Motivs, bearbeitete Datei ohne kritische Details
Kunde oder Testimonial	Hoch	Veröffentlichung, Werbenutzung, Kontext der Aussage	Ja, eindeutig und schriftlich	Einwilligung, Aussagefreigabe, Nutzungsdauer
Eventfoto	Mittel	Erkennbarkeit Einzelner, Fokusmotiv oder Beiwerk, Werbenutzung	Oft sinnvoll, besonders bei klar erkennbaren Personen	Eventhinweis, Bildauswahl, Einzelprüfung der Nahaufnahmen
Innenraum oder Gebäude	Niedrig bis mittel	Hausrecht, vertrauliche Informationen, Marken, Personen im Bild	Nur bei erkennbaren Personen	Freigabe des Ortes, Prüfung sichtbarer Details

Diese Übersicht ersetzt keine juristische Einzelfallprüfung, aber sie hilft im Alltag enorm. Genau so arbeiten wir auch bei Foto- und Video-Projekten: zuerst Motive und Nutzung definieren, dann shooten, dann sauber ablegen.

Die häufigsten Fehlannahmen bei Bildrechten

„Wir haben das Shooting bezahlt, also gehört uns alles.“ Nein. Ohne klare Regelung sind die Nutzungsrechte oft enger als gedacht.
„Alle waren beim Shooting dabei, also ist alles erlaubt.“ Nein. Die Teilnahme am Shooting ist nicht automatisch die Freigabe für jede Veröffentlichung.
„Das Bild ist nur auf unserer Website, nicht in Werbung.“ Eine Unternehmenswebsite ist trotzdem öffentliche Außendarstellung.
„Das ist nur ein Kennzeichen.“ Ein Kennzeichen kann personenbezogen sein und sollte bewusst geprüft werden.
„Der Mitarbeiter ist nicht mehr bei uns, aber das Bild war damals okay.“ Nach dem Austritt solltest Du die weitere Nutzung immer neu bewerten.

Pragmatische Freigabe-Checkliste für den Betriebsalltag

Wenn Du wenig Zeit hast, nimm diese Checkliste. Sie spart später Diskussionen, Nachfragen und teure Nacharbeit.

Vor dem Shooting

Motivliste anlegen: Mitarbeiterfotos, Teamfotos, Baustellenfotos, Fahrzeuge, Innenräume, Kunden.
Verwendungszwecke festlegen: Unternehmenswebsite, Social Media, Recruiting, Print, Presse.
Mit dem Fotografen Nutzungsrechte schriftlich klären.
Freigabeformular für erkennbare Personen vorbereiten.
Prüfen, ob sensible Details sichtbar sein könnten: Kennzeichen, Hausnummern, Displays, Dokumente, Kinder, Dritte.

Während des Shootings

Festhalten, wer auf welchem Motiv zu sehen ist.
Spontane Zusatzmotive nicht unbesehen später veröffentlichen.
Varianten ohne kritische Details fotografieren, etwa ohne Kennzeichen oder mit neutralem Hintergrund.

Nach dem Shooting

Dateien sinnvoll benennen, zum Beispiel: 2025-05-team-musterbetrieb-01-fotografname.
Zu jedem Bild intern dokumentieren: Wer ist abgebildet, wer hat fotografiert, wann wurde aufgenommen, welche Nutzungsrechte gelten, welche Einwilligung liegt vor, wo ist der Nachweis gespeichert.
Bearbeitete und freigegebene Webversion getrennt vom Rohmaterial ablegen.
Für jedes Bild einen klaren Status vergeben: freigegeben, eingeschränkt freigegeben, nicht veröffentlichen.

Wenn ein Unternehmen diese einfache Struktur einmal sauber aufsetzt, wird die Website-Pflege viel entspannter. Genau solche Prozesse gehören für mich zu guter strategischer Beratung: weniger Chaos, mehr Nachweisbarkeit und deutlich weniger Risiko.

So dokumentierst Du Bildrechte sauber

Ein brauchbares internes Muster braucht keine 20 Seiten. Für kleine Unternehmen reicht oft eine kompakte Bildakte pro Motiv oder Shooting mit diesen Feldern:

Dateiname / Bildnummer
Datum und Ort der Aufnahme
Fotograf / Urheber
Vertraglich eingeräumte Nutzungsrechte
Abgebildete Personen
Einwilligung vorhanden ja/nein
Zulässige Kanäle
Zulässige Dauer
Ablageort des Nachweises
Besondere Hinweise, etwa Kennzeichen retuschiert oder nur Website, nicht Social Media

Gerade wenn Du in DACH und Italien kommunizierst, lohnt sich zusätzlich eine sprachlich klare Freigabe. Ein ungenauer deutscher Standardsatz reicht in mehrsprachigen Betrieben oft nicht. Zum Thema länderübergreifende Kommunikation findest Du auch in meinem Beitrag zu Mehrsprachigkeit im Marketing für DACH und Italien ein paar wichtige Grundgedanken, die hier direkt mitspielen.

Wann Du besser juristisch prüfen lässt

Nicht jeder Fall braucht sofort eine spezialisierte Kanzlei. Aber eine juristische Prüfung ist sinnvoll, wenn Personen klar erkennbar sind, wenn Kunden oder Kinder im Bild vorkommen, wenn Referenzprojekte sensibel sind, wenn Baustellenfotos private Bereiche zeigen oder wenn unklar ist, ob alte Verträge die heutigen Nutzungen wirklich abdecken.

Mein praktischer Rat ist einfach: Kläre Rechte vor dem Website-Launch, nicht erst nach der Veröffentlichung. Bildrechte sind kein lästiger Anhang, sondern Teil einer professionellen digitalen Präsenz. Eine starke Marke wirkt nur dann souverän, wenn sie auch im Hintergrund sauber organisiert ist.

Fragen? Antworten!

Darf ein externer Fotograf die Bilder später selbst für Eigenwerbung nutzen?

Das hängt vom Vertrag ab. Wenn nichts sauber geregelt ist, bleiben dem Fotografen in Italien grundsätzlich eigene Rechte am Foto; zusätzlich muss aber auch geklärt sein, ob abgebildete Personen einer solchen Nutzung zugestimmt haben. Klare Verträge verhindern genau diesen Konflikt.

Reicht eine mündliche Zustimmung für Mitarbeiterfotos?

Für die Praxis ist eine mündliche Zustimmung zu schwach, weil sie später schwer nachweisbar ist. Besser ist eine schriftliche Einwilligung, die den genauen Zweck nennt und intern sauber abgelegt wird. Das spart Dir Diskussionen bei Website-Relaunch, Social Media oder Personalwechsel.

Was gilt bei ehemaligen Mitarbeitern auf der Unternehmenswebsite?

Nach dem Austritt solltest Du jedes Bild neu bewerten. Gerade bei Teamseiten, Recruiting-Seiten oder vertrauensbildenden Inhalten ist die weitere Nutzung oft nicht mehr sinnvoll oder rechtlich heikel. In der Praxis ist das Entfernen oder Ersetzen meistens der sauberste Weg.

Darf dasselbe Bild auch für Social Media, Recruiting und Print verwendet werden?

Nur wenn diese Nutzungen ausdrücklich von Nutzungsrechten und Einwilligung abgedeckt sind. Eine Freigabe für die Website ist nicht automatisch eine Freigabe für jeden anderen Kanal. Halte die Kanäle deshalb immer konkret fest.

Sind Baustellenfotos ohne Personen automatisch unproblematisch?

Nicht automatisch. Auch ohne Personen können auf Baustellenfotos Kennzeichen, Hausnummern, Unterlagen, Nachbargrundstücke oder geschützte Details sichtbar sein. Prüfe deshalb immer das gesamte Motiv und nicht nur die Frage, ob ein Gesicht zu sehen ist.

Was ist der sicherste Minimalprozess für kleine Unternehmen?

Kläre vor jedem Upload drei Punkte: Wer hat fotografiert, wer ist erkennbar, wofür ist die Nutzung freigegeben? Wenn Du diese drei Antworten schriftlich dokumentierst, reduzierst Du das Risiko auf der Unternehmenswebsite bereits deutlich. Für größere Shootings lohnt sich ein fester Freigabeprozess im Team.

Quellen

SEO : Google déploie une mise à jour majeure de ses algorithmes (November 2026 Core Update)

Wed, 11 Nov 2026 15:47:11 +0000

Google lance sa troisième Core Update de 2026, la première depuis l'arrivée d'AI Overviews et de l'AI Mode en France. Le déploiement peut durer jusqu'à deux semaines.

Reporting social media : le guide pour créer et automatiser son tableau de bord avec Data Studio

Wed, 11 Nov 2026 15:47:11 +0000

Comment créer un reporting social media vraiment utile, et l’automatiser sans perdre en fiabilité ? Bryan Coder partage sa méthode pour construire un tableau de bord sur mesure avec Data Studio.

Představení Openreviews.cz

Wed, 11 Nov 2026 14:53:58 +0000

Před dvěma týdny jsem psal o Mangrove Reviews a proč do této otevřené platformy pro recenze psát. Nakonec ale nezůstalo jen u toho a řekl jsem si, že by bylo dobré adopci této platformy v ČR trochu podpořit, a tak vzniklo Openreviews.cz.

Resonant Computing and Common Fabric

Wed, 11 Nov 2026 11:08:15 +0000

This event summary was created by Claude with editing by Tim O’Reilly, based on a transcript of the conversation.

Alex Komoroske is the CEO and a cofounder of Common Fabric, a public benefit corporation building the infrastructure for human-centric agentic computing. He spent more than a decade at Google as a product manager and director of product management on Chrome, Google Maps, and Google Earth, and he later ran corporate strategy at Stripe. At O’Reilly’s AI Codecon a year earlier, in a talk called “Why Centralized AI Is Not Our Inevitable Future,” he argued that we were sleepwalking into the wrong future for AI and didn’t have to accept it. Since then he has coauthored the Resonant Computing Manifesto, which Tim signed.

On Tuesday, October 20, 2026, Tim O’Reilly hosted Alex for an hour-long conversation, “Can We Build More-Human Technology?” Common Fabric’s consumer product hasn’t yet been released, but Alex showed Tim the product privately the day before, and Tim said his conversations with Alex had left him “more optimistic about the future of the web and the AI future than I’ve been in a long time.” They talked about the underlying theory behind Common Fabric.

The Resonant Computing Manifesto

The Resonant Computing Manifesto lays out five principles for resonant technology. It is private, meaning you’re the steward of your own data and it’s used in accordance with your wishes. It is dedicated, with no conflicts of interest. It is plural, with no central entity holding an unnecessary amount of power. It is adaptable, able to do things its creators didn’t specifically build in. And it is prosocial, helping people create meaning together rather than living as “individual islands.”

According to Alex, the manifesto rests on a distinction between two kinds of experience.

A hollow thing is something that you like when you’re using it, and then, after you’re done using it, you’re left feeling regret. And a resonant thing is something that you like when you’re using it, and then afterwards you’re left feeling nourished. They are superficially very similar, but they’re fundamentally, deeply, structurally different.

Alex argued that modern tech, business, and politics are very good at delivering hollow experiences efficiently and poor at delivering resonant ones. The manifesto came from a group of people who still believe in the hacker ethic of the 1990s and early 2000s, he said. They believe that technology is a large positive force for humanity, but also that the industry has spent the last decade optimizing for engagement and extraction, which has undermined that positive impact. They think that the AI transition is a unique opportunity to reset the norms and the architecture to make something that works better for people than for extractive business models.

Privacy, bits, and the physics of trust

Tim started out by asking Alex to go a bit deeper on privacy. Privacy and trust are related in ways the privacy movement often doesn’t consider, Tim said. We don’t put bars on all of our windows. We trust most people not to break in because we built a society where trust is the norm. It’s held in place not just by penalties but by social rewards for people who follow norms. “People will think you’re a creep if you go look into somebody’s window,” Tim noted. Like bars on the window, hard privacy seems to Tim a bit like an admission that we’re giving up on positive social norms and penalties for rulebreakers (where needed). He wanted to know whether Alex meant “private” in the way that HIPAA makes your healthcare records private, where your data is made hard for anyone to see, including you.

Alex doesn’t mean that at all. He means privacy that makes your data more useful by putting it under your control. He gave a three-part answer about how that happens. The first leg of the stool is what Helen Nissenbaum, a professor of information science at Cornell Tech, calls contextual integrity. What she means by that is that your data is used in line with your intentions and expectations, with no use that harms you, and no nasty surprises. Alex said it’s the best formulation of privacy he knows. Tim agreed.

The second part of Alex’s answer was that there are differences between atoms and bits. Arguing from game theory, Alex suggested that trust emerges when you expect to deal with the same person or entity again. In the physical world, you might be seen peering into someone’s window and shamed as a result. But “in the world of bits,” because the peeping is invisible, there are fewer immediate consequences, and “you can have a whole bunch of creepy companies peering through your window.” And because your data becomes more useful when combined with other data, there are much larger financial incentives to misbehave. (Tim would still argue that we also need to establish the right set of social norms and laws for regulating this bad behavior.)

The third point Alex made is that data is viral. It can be copied at full fidelity, instantly, for almost nothing, so once it’s out of your sight, it’s out of your control. The industry has relied on three inadequate mechanisms to address this: 1) terms of service nobody reads; 2) permission dialogs, which Alex called “responsibility-laundering dialogs” (He argued they ask an ill-posed question, whether you trust another entity, open-ended and forever, with your data. “I trusted 23andMe with my genetic data 10 years ago, and I sure as hell don’t trust them now,” he noted.); and 3) silos, where each app sees one slice of you. Spotify knows what you listen to and Strava knows when you work out, but neither knows which songs you like during a workout.

Alex said he respects Google, where he worked for many years, but he argued that it has little incentive to build much on your data beyond keeping you from leaving. His point was that “our data is kind of sitting there, not really working for us, and also not really on our turf,” and that this is the result of technical decisions the industry made rather than a law of nature.

Data that carries its own rules

Tim asked what makes Common Fabric different. A lot of people have espoused ideals like those of the Resonant Computing Manifesto, though perhaps in different words, but not much has changed. Alex replied that resonance is hard to build today because users spend their time on the software creator’s turf, doing what the software creator wants. Unless that structure changes, engagement-maxxing keeps emerging. Common Fabric goes down to lower layers and does something very different with the very structure of data. Alex said Steven Levy, writing about the manifesto for WIRED, had described what Common Fabric is working on as “resonant AF.”

Conceptually, in Common Fabric, every piece of data carries a metadata sidecar wherever it goes. In that sidecar, there are two things. One is cryptographic provenance: who did the last computation, the fingerprint of the software that did it, and what its inputs were, traceable all the way back. Alex said the math is similar to blockchains, but without a globally consistent, financialized ledger. The other is policy, the conditions under which the data may be declassified, now or in the future.

An open source runtime, which Alex called “the core reaction chamber” of Common Fabric, enforces those policies. It receives a proposed graph of computation, made of untrusted code running on specific data with specific policies. If the computation is legal, the runtime runs it, updates the provenance chain, and tells everybody. If not, it stops with a descriptive error, for example because a network request could leak something derived from confidential data. You can run the runtime on your own machine, but most people won’t, so Common Fabric will run it in the cloud in trusted execution environments. These are hardware-isolated environments where the host can’t see inside and can prove cryptographically that it’s running the runtime unmodified.

Tim raised a worry from the history of security software. Early systems such as Kerberos were so complicated to set up and maintain that few people used them. Would this be a master console of access controls so complicated that nobody ever touches it? Alex said most users will never know how it works. To them it will simply be “the best way of using AI in their lives,” a digital home where their data, their collaborators, and their agents come together.

The software in that home is made of what Common Fabric calls patterns, small chunks of untrusted code. Alex stressed that he means “untrusted” in the security sense, which is good, because rather than meaning “not trustworthy,” it means “you don’t have to trust them.” Patterns are written in TypeScript and look much like React. (When the team asked LLMs what framework felt most natural to them, the models said React.) A pattern can do six things:

It can do arbitrary computation.
It can produce derived data, which persists and is available to other patterns.
It can produce UI for different contexts, such as dark mode or a preview chip, computed only when used.
It can make network requests if policy allows. (LLM calls are technically network requests.)
It can instantiate subpatterns fetched from anywhere on the internet, or written by an LLM on the fly.
It can wish for more data.

Alex walked through a wish. A meal-planning pattern wishes it knew the user’s favorite foods. In one pattern, the system might express this wish by asking an LLM to generate a simple text box for the user to fill in. Another pattern might look for notes tagged “favorite foods” or for the ingredients in recipes the user made in the last six months. Another might read through the user’s Gmail with an LLM and distill what they like to eat. Because the emails are confidential, the result is confidential too.

That pattern could have been written by a stranger and could still run proactively on your data, Alex said, because Common Fabric is designed so that the pattern’s author never sees your data and the pattern can’t use it against your expectations. Anyone can write new patterns (kind of like skills) and Common Fabric will surface the most popular ones for various tasks.

Type checking for your data’s rules

Tim asked Alex to slow down on this point, that you can give untrusted software access to your data because the data, not the software, decides what may be done with it. Alex replied that users will rarely think about policies. Users would choose default policies that are vouched for by people and organizations whose judgment they trust. For instance, he said “I trust Simon Willison. And Simon Willison will say, ‘I trust that repo right there.’”

Alex gave as an example a pattern that pulls your Gmail into Common Fabric. It uses an OAuth flow to get a token from Google. Anyone who has that token can read and send your email indefinitely. So the token is tagged with a policy “secret to google.com,” which specifies that the token should never be logged or shown on screen or sent anywhere that isn’t attested to be running the runtime, not even the user’s own browser. It may cross the network only over a secure connection to the origin that minted it, and only in the authorization header. Any pattern that looks at the token, or at anything derived from it, absorbs those policies permanently. “You can look at the OAuth token, but then you can never talk to anybody else ever again, basically.”

Tim said this sounds like the virality of GPL licenses. Alex agreed, and said that Mitchell Baker, the Mozilla cofounder, had made the same point to him a few weeks earlier.

The term of art in information-flow control is “taint,” (a term Alex joked he dislikes because people look at him funny when he uses it). Data is tainted when it has touched something confidential and so inherits that thing’s restrictions. The aim is to keep as little data tainted as possible so that network requests can still happen safely later. Common Fabric’s compiler untangles a pattern’s data flows so that code which only passes a token along gets a handle to it rather than the token itself, and stays untainted. Alex compared this to Rust’s borrow checker, which refuses to compile code that could theoretically have a data race. Human programmers find it a nag, and a slog.

But you know who doesn’t get impatient about that? LLMs. They don’t care. They’ll say, “Okay, cool. I’ll just make this tweak.”

There’s something different at work in the world.

This is the heart of Alex’s answer to Tim’s question about the risk that complexity will make the system unusable. Common Fabric’s taint checker nags in the same way as Rust’s borrow checker, and LLMs grind through it. “If this software compiles, it’s safe structurally,” Alex said. “You don’t know it’s useful, but you do know it’s safe.” Because it’s safe, the system can run patterns for people proactively and speculatively, without their installing anything, and then share more widely the ones people engage with. Alex said that kind of distribution isn’t possible under the trust model normal software uses.

Crappy patterns and dangerous patterns

Tim noted that the word “pattern” comes from Christopher Alexander’s A Pattern Language, the book about why some buildings and places work and others don’t. Alex added that the manifesto quotes Alexander directly, and that he considers resonance to be Alexander’s “quality without a name.” Tim recommended the book to anyone who hasn’t read it. He recalled patterns such as Alexander’s observation that balconies and porches less than six feet deep are rarely used, and his question of why people sit on stoops in some neighborhoods and not in others. Then he asked, “Won’t people just start making shitty patterns?”

Alex said they will. Most videos on TikTok are bad, and social sifting still brings the good ones to the top. He gave a stylized example of a ranking function. To decide whether to show images at the top of search results for a query, you can check how many people in the last 90 days searched for “images of” that term compared with the term alone, and show images above a threshold. The authentic behavior of a small group of savvy users tells you about quality for everyone else.

“I’m not worried about crappy patterns,” Alex said. “I’m worried about dangerous patterns.” He’s thinking about patterns that would misuse your data. And that’s what Common Fabric is designed to prevent. His example was the draft box in a chat app. Everyone assumes what you type is visible only to you until you hit send, and then only to the people in the chat. Nothing in today’s software structurally guarantees that, and on some marketing sites, the support agent can see what you type before you send it. In Common Fabric, a default policy could make the draft structurally confidential until the Send button is pressed and then declassify it to only the chat’s members. No chat app assembled from this pattern could behave otherwise.

Tim noted there will be a long period of discovering corner cases once the system is out in the wild. Alex said two surfaces must coevolve, the open-ended set of patterns and the policies, which is why trust delegation matters. As people find patterns that slip past common default policies, the policy sets need to evolve to meet the threat. He said he isn’t promising perfect security, which he called an asymptotic ideal. His claim was that for the same security budget, users can reach further.

Today, in the physics of trust we use, a more secure system requires putting yourself in a smaller and smaller and smaller box. What if, instead, a more secure system puts you on a taller and taller platform, allowing you to reach much further?

People won’t come for the security model, he said. They’ll come because they can do much more with AI and with collaborators than other software allows, and the security model is the reason that isn’t creepy or dangerous.

Where’s all the new software?

Tim brought up a question he has written about previously. When a new technology arrives, at first people can see only the old one. When the web came along, Marc Andreessen talked about Netscape becoming the next Windows, and even open source developers talked about a Linux desktop and an open source Photoshop, while the real action was people making entirely new things with the web. With AI, Tim said, we hear about a world of infinite software, but he hasn’t seen many accounts of wonderful new things people have built. Mostly he hears about dark factories that help people get more productive at what they already did. People talk about the tooling but not what they built with it. Patterns, he said, gave him a taste of what infinite software might really be.

Alex said software today orbits corporations, when it should orbit people. He described a “nightmare” in which building software took excruciating, hypermeticulous detail and bickering with dozens of people, and then pointed out that this was how software was built nine months ago. Old software now inspires in him the kind of awe people feel at the pyramids, built without heavy machinery. “And yet where is all the new software?”

His answer was that infinite software built on the old physics of trust can’t produce the things that matter. On one vibe-coding platform, he found a dream-tracker app by an anonymous author that lets you log in with Google, store dreams, and mark some of them public. He started to enter a dream and stopped, because he had no idea whether the author had left everything public by mistake or was reselling it. The old trust model worked tolerably, he argued, because expensive software usually came from people who knew what they were doing, and big companies had lawyers telling them not to sell your data. When anyone can bring software into existence, even that level of trust goes away. Without new physics for distribution and trust, infinite software gives you either “cozy bits of software” from people you would trust alone in your house for an afternoon, or isolated islands that can’t touch sensitive data and “top out at microgames and art apps.”

Software is alchemy. It is our ability to extend our agency beyond ourselves and automate it. And so the idea that software is going to top out at these very low things is just ludicrous to me.

Reclaiming your data

Tim connected Alex’s point about trusting big companies to his own analysis of rising tide rents and robber baron rents, which he developed around the same time Cory Doctorow was writing about enshittification. Companies have strong incentives to treat users well while they’re acquiring them. Once growth flattens, the incentive shifts toward taking advantage of users, staying just good enough that they don’t leave. Part of what keeps people attached even as applications enshittify, Tim said, is that the apps hold so much of their data.

Alex agreed that reclaiming data is the right frame. The business model of the last decade, as he described it, was to build expensive software aimed at an average market, let user data accumulate, and then rent access back, sell derived insights, or hold the data hostage. In a world of infinite software, users can build what they want on their own turf, and he expects silos to become “greedy goblins” guarding the data. He drew a line between what silos add and what users put in. Insights a company derives are its own, but the bits a user contributed should come back out. Infinite software, he said, also tilts the cat-and-mouse game back toward users.

Tim asked how he would get 15 or 20 years of email out of Google. Alex gave Google credit for some of the best APIs, especially in Europe. Alex pointed to msgvault, an open source project that keeps a local archive of a Gmail history, so agent queries go to a local copy instead of rate-limited APIs. When services hand over data in deliberately annoying forms, such as a thousand-page PDF, an LLM can patiently restructure it. “They don’t get bored of a task the way you do.”

Who pays for the compute

Tim pushed on the economics. Services like Gmail are expensive to run, and users get them for very little. If he stores terabytes of email himself, he’s paying someone else, possibly more than Google charges, since Google had ways of subsidizing it. How does this work over the long haul if Common Fabric becomes a new paradigm?

Alex began by acknowledging the value these services have delivered. Free turn-by-turn navigation is now taken for granted, though about 15 years ago, he said, the main licensors of that data charged something like five dollars per user per month. Then he made a point he expected some people to find provocative.

If you aren’t paying for your own computation, then it’s not working for you; it’s working for somebody else.

Users would pay for their own compute by running the runtime on their own machines, or through hosts Alex called AI service providers. These would run the runtime in trusted execution environments, prove they can’t see inside, and charge for tokens, compute, and storage. If users could switch providers, margins would stay small. Alex acknowledged that consumers have long resisted paying for software, but argued that the nontrivial marginal cost of LLM tokens creates an opening, much as people pay a monthly cell phone bill because the service has become indispensable.

Tim suggested companies like Google could migrate many of their services into this world. Alex said there will be many opportunities, but incumbents are used to another business model. He recalled telling a friend with a startup that building on the Common Fabric was wildly premature and that his investors might not like it, because the point is that patterns use data without owning it.

Tim noted that today’s model doesn’t have to stay the model, and Alex said he expects new business models to emerge. Asked how he will get developers to write patterns, Alex said he doesn’t need to. Agents write them on users’ behalf, and once someone’s agent has ground through building a word search, anyone else can use that pattern.

Is surveillance capitalism inevitable?

An audience member, David, wrote that he loves Shoshana Zuboff’s The Age of Surveillance Capitalism and wondered how we came to accept as inevitable that companies take our behavioral data. He said he wasn’t sure technology could fix something technology didn’t cause.

Alex said he thinks technology did decide this but allowed that people may disagree. The same-origin policy, the browser rule that lets a script use only data from the site it came from, was introduced by Netscape in 1995 as a quick fix for a security problem that was discovered early on with JavaScript. As more APIs were added, the walls grew higher, and when native apps arrived on iOS and Android, the same model meant every app owned its own data. Alex said that decision could have been made differently. Surveillance capitalism may keep emerging, he said, but it isn’t inevitable, and technology applied at the right leverage point can lead to a different result.

Tim told David he thought Zuboff’s book had a fundamentally bleak view of the world. For a long time, he said, we had a fairly virtuous set of relationships with many of these companies, and then we created economic incentives that led them to treat us badly. He argued that economic redesign is needed alongside technical redesign. That redesign starts with eliminating the market’s requirement that companies always keep growing even when they no longer deliver additional value.

Alex brought up Eric Ries’s book Incorruptible, which he said he keeps a stack of near his desk. He described himself as a believer in markets and capitalism as an emergent force for good. He distilled the book’s thesis down to the idea that organizations that think long term naturally attend more to their externalities. Common Fabric is set up as a public benefit corporation, and Alex said Eric consulted on structuring it to keep a long-term perspective in perpetuity, advice that Eric is now sharing with the wider world through Incorruptible.

Tim’s argument: AI as a reset

AI is a reset the industry still hasn’t yet taken full advantage of, Tim noted. We’re still thinking in the surveillance-capitalism frame, he said, in the same way that Netscape assumed people would buy software and that whoever controlled the software would control the future. We assume a world of advertising, and a world where companies hold more data about us than we do about ourselves. But new AI native companies will find new business models. Tim called Common Fabric the most thoughtful take on this reset he had seen. He compared it to his first encounter with the web, when there were about 200 websites and O’Reilly put it in The Whole Internet User’s Guide & Catalog because, as he put it, “this is the future.”

Tim said he couldn’t promise that Common Fabric would be the winner, but it is the most promising new thing he’s seen in a long time. He recalled the early days of the internet, when it wasn’t clear whether Gopher, the World Wide Web, or AOL would prevail. The web won, in his reading, because it built an architecture of participation. It was easy to draw from and easy to add to, and its mechanisms kept evolving, so that the web of 2000 or 2005 looked very different from the web of 1991. Common Fabric comes with that same sense of open-ended possibility.

Open source underneath, a product on top

Alex said the underlying runtime and pattern system are open source, but on their own they feel like a tech demo, which is why Common Fabric is building a consumer product on top. That product is still in development and not yet public. But he expects strong network effects as more people join the open ecosystem. Tim said that when Alex showed him the product the day before, this idea made sense. He described his takeaway as agents building throwaway software that embodies a shared set of patterns, with data that carries from the beginning the scope of what can be shared with whom.

Alex said none of this would have been possible before AI could write software. He told the story of his cofounder, Berni Seefeld, who had been thinking about these ideas for decades. Over a dinner a decade ago, Alex asked how they would ever get people to write enough patterns to reach critical mass. Berni said that in the future, AI would write software. Alex replied, “Come on.” Berni gave the structural argument for why software engineering would be the strongest, fastest, and most invested-in vertical, and a few years ago told Alex the curve was happening and it was time to start. Not needing humans to write patterns, Alex said, lets us think much bigger and differently from how the industry has assumed software must work for the last 30 years.

Tim closed on that point. Because agents building software in Common Fabric do it according to principles that put people at the center, he said, the nature of the game changes.

(iterate think thoughts): Rendering in batches with glimmer and Datastar

Wed, 11 Nov 2026 02:04:09 +0000

Anders Murphy recently wrote about [faster streaming HTML with batches and aggregates](https://andersmurphy.com/2026/09/29/faster-streaming-html-with-batches-and-aggregates.html). The idea is simple. When the server streams HTML to a page, it should collect the changes and render once for the whole batch. Similarly, it makes sense to avoid rendering the same thing twice for two different pages to avoid resending the data that the client already has.

I've been building glimmer and glimmer-datastar to do reactive server side rendering for jolt, and ran into similar problems. This post covers how both libraries have been reworked to facilitate batch processing, and how these changes are used in the newsroom app.

The setup

Glimmer is a Reagent-style library where state lives in ratoms which UI components subscribe to. The original target was native GUIs such as glimmer-gtk and glimmer-tui, but the reactive core is toolkit agnostic. So, naturally I got curious if I could use the same model on the server with Datastar on the frontend.

The way this works is that each open page keeps a Server-Sent Events stream to the server. When the page is rendered, any ratom the page reads is recorded, and the stream subscribes to it. Then whenever one of those ratoms changes, that causes the stream to render the page again. So, when a swap! happens on a ratom, that sends a datastar-patch-elements event with the new HTML to every page that renders it.

(def state (ratom/atom {:greetings []}))

(def handler
  (-> (fn [_] {:status 200 :body (render-page @state)})
      (datastar/wrap-datastar {:tick-ms 15})))

The first version did the obvious thing which is to wake up every stream that reads the ratom on a write to do a render. The naive approach works fine with a few pages that do occasional writes, but it doesn't scale with load because the cost ends up being writes * pages.

Render once per tick, not once per write

The fix here is to decouple writes from render requests. A write only needs to mark the streams that read the ratom as dirty, then a separate render loop can run on a fixed timer specified by :tick-ms. And every dirty stream ends up being rendered exactly once each time it wakes up with all the changes that have been batched up since the last time:

(defn mark-dirty! [sched conn]
  (swap! (:dirty sched) conj conn)
  (wake! sched))

(defn- tick! [{:keys [txs dirty batch-fn] :as sched}]
  (run-batch! batch-fn (drain txs))
  ;; snapshot after the writes, so the connections they dirtied render now
  (let [[conns _] (swap-vals! dirty (constantly #{}))]
    (render-all! sched (vec conns))))

The loop sleeps out whatever is left of the tick before rendering, allowing every change that arrives to land in the same batch. Meanwhile, an idle loop simply parks on a channel without incurring any additional cost.

The effect on a burst with ten open streams and a hundred swap!s in a row is fairly dramatic as one would expect:

|—|—|—|

Before, the server had to do a thousand renders, most of which were thrown away. With ticks in place, the render count depends on the number of pages and how long the burst lasts rather than how many writes it contains. Incidentally, glimmer's GUI side already worked this way since a component's watcher holds a pending flag to ensure that a burst of changes queues a single deferred render on the UI thread.

Slow clients drop frames instead of queueing them

A tick produces at most one frame per stream, and each stream sends its frames through a channel with a sliding buffer of one. If a client hasn't taken the last frame by the time the next one is ready, the old frame is discarded so that the client always gets the latest update. This way a bad connection can't back up the render loop or build up an unbounded queue of stale HTML.

Batched writes with `tx!`

Since ticks batch renders, it makes sense for writes to be batched as well, as an opt-in. This is done using tx! to queue a thunk that runs on the loop thread at the start of the next tick, and before a render happens:

(fn [request]
  (datastar/tx! request #(swap! state update :greetings conj "hello"))
  {:status 204})

Writes and renders have to take turns, so that a render can't observe a partial update. If you pass a :batch-fn, it receives all of a tick's thunks together, so you can run them in a transaction, and calling tx! returns a promise of the thunk's result.

Using component cache to avoid rendering the same thing twice

While ticks cut renders per page, there is also waste across different pages to consider. If a hundred people are looking at the same 300-row board, rendering it a hundred times per tick produces a hundred identical strings.

To address that, glimmer-datastar provides its own hiccup renderer in jolt.datastar.html. The head of the vector is a component of [row item], and its HTML is cached under the vector itself, so the key is the function plus its arguments. The whole board can now render once per change with every page showing it sharing the result.

As always, the tricky part is knowing when a cached entry is stale, since components read ratoms as well as their arguments, glimmer now has capture for this case:

(let [a (atom 1) b (atom 2)]
  (r/capture #(+ @a @b)))   ; => [3 [a b]]

It runs a function and returns its result along with every reactive cell the function read. The cache stores each entry with those cells and the values it saw in them, and once any of those values changes, that indicates a need for a cache refresh. And on a hit, the cache simply reads the cells again.

The cache also admits an entry only when it's asked for more than once, so components that render once and never again don't push out ones that render every frame. It evicts by generation, which is roughly LRU without needing per-entry bookkeeping on the hit path.

On a 4-core machine, with 100 streams showing the 300-row board and one row changing per tick, a tick takes:

|—|—|—|—|—|

The cache is the big win here while render threads level off, so two is the default.

And capture also fixes another problem unrelated to speed. Since a stream now knows exactly which cells its last render read, it only needs to watch those. A cell it stopped reading can be unwatched right away, rather than leaving a subscription behind that triggers extra renders later.

Not sending what the client already has: patches

With rendering no longer being the bottleneck, the wire becomes the main cost since a single row change to that 300-row board still sends a 40 KB page. One obvious solution here is to enable streaming compression which gets you part of the way. Using ring-chez-adapter's wrap-gzip compresses an SSE stream with a single deflate window across frames, so a frame that's almost identical to the previous one compresses to almost nothing. But that holds only while a frame fits in deflate's 32 KB window. Past that the saving mostly disappears, and even a one-row change costs 4316 gzipped bytes.

So, we need to use patches to address the underlying problem. A component whose root element has an id, like [:tr {:id ...}], is a part of the page. Since each stream compares its new page with the last one, part by part, it only needs to send parts that changed. Then, on the frontend, Datastar swaps each one in by id. When the page changes around its parts, such as a row being added, text outside every part being edited, or the client missing a frame, the whole page still gets sent.

|—|—|—|

Since the size of a patch depends on the change rather than the page, the comparison is cheap too. A cached component brings its parts as the same shared vector on every page, so the diff can skip it with an identity check. On my machine, this roughly halved the time for each tick going from 21.7 ms with whole frames to just 7.0 ms with patches. Using the delta is key for incremental view maintenance because only parts of the page that change have to be sent as updates.

Aggregates: derived state that follows the change

We're not done yet though, because another trick that can be applied is to use aggregates. Take a reaction like (reaction (count (filter open? @todos))). It recomputes from scratch on every write, so whether a single row or a thousand change, the reaction still costs a thousand.

Glimmer's new glimmer.table borrows from DBSP. A table is a keyed collection cell, and a view over it maps or filters only the rows that changed. An aggregate whose operation has an inverse, like a count or a sum, simply takes the old row out and puts the new one in:

(def todos (t/table {1 {:title "a" :done false}}))
(def open (t/view todos (fn [_ v] (when-not (:done v) v))))
(def open-count (t/aggregate open t/count-of))

(t/put! todos 2 {:title "b" :done true})   ; costs one row, not the table

These are ordinary reactive cells, so pages subscribe to them with @ like anything else. With ticks, the cache and patches, a write costs one row to derive, there is now one component to render, and one part to send.

Letting go of closed pages

Of course, batching only helps if you're not doing work for pages nobody is looking at. So, when a client goes away, the server closes the stream's channel. A transducer on that channel runs on close and unwatches every cell the stream was tracking, making it possible to garbage collect the connection right away. And a render that the handler answers with a redirect or an error, such as a 401 after sign-out, cleans up the stream the same way.

What does this look like in practice

I've always been interested in understanding how world news and events all connect to each other. There are many different things happening on any given day, and things that often seem like isolated events can often have shared underlying causes.

Decision makers get fancy daily briefings prepared for them by analysts who review the events to produce a perfectly prepared report. So, I figured why can’t I have something like that too?

And so, I built Newsroom which is a self-hosted news desk app to gather sources and write a daily briefing tailored to what I'm interested in. The app goes through hundreds of sources using a combination of RSS and web scraping. It then groups the news into categories and gets an LLM to build a graph of events and their connections to provide a basis for the report.

It was a perfect project to exercise the library since it has a live sidebar showing the progress as each source is aggregated, and the model's progress as it streams.

That kind of workload is the worst case for one-render-per-write. A run fetches its sources concurrently from several threads, and each source reports a result and a log line. Meanwhile, the model's progress updates many times a second while it streams. Every one of these events used to be a swap! on the run's status ratom, and every swap!, in turn, translated into a render of every page watching that reader's run.

Now, the server asks for {:tick-ms 200} which prevents event flooding. However fast the status changes, an open page still renders at most five times a second, and a burst of sources finishing together all get packaged into a single frame. The whole change was just one line, since newsroom already asked for the same 200 ms through the old :rate-limit-ms option. What changed underneath though is that a tick now coalesces the writes instead of only spacing them out.

Ticks can also split two related writes across frames to ensure correct order. A source used to set its state and then append its log line in a second swap!, so a page could show "ok, 12 items" in the source list before the log mentioned it. Now both go in one write:

(update-status! (:run-id ctx)
                (fn [st]
                  (-> st
                      (update-in [:sources name] merge {:state :ok :count (count items)})
                      (add-event {:text (str name ": " (count items) " items") :level :ok}))))

That's the same idea tx! enforces, done by hand where one function owns both writes. It also depends on glimmer's swap! being atomic, because sources call this from several threads at once.

Each newsroom page has two live regions, the sidebar and the article, both running on separate streams. The sidebar reads the run status, which changes constantly during a run. The article reads only a counter bumped when a day is stored. Since a stream only watches what its last render read, the article doesn't need to repaint while a run is in progress.

All readers have their own lanes in the form of a status ratom and a stored counter, so each reader's run only dirties their own pages. When a tab closes, or a reader signs out and the stream gets its 401, the stream drops its subscriptions.

Incidentally, the same kind of batching also works for the database. Making the status of a run durable makes it possible to pick up where it was interrupted. But the same problem we talked about earlier came back from the other direction. Writing the status to SQLite on every swap! results in a database write per progress tick. So, Newsroom marks the run as unsaved instead, and a background thread writes the changed runs once a second:

(defn- update-status! [run-id f & args]
  (swap! (status-of run-id) (fn [st] (if (identical? run-id (:run st)) (apply f st args) st)))
  (when (and (instance? Run run-id) (.-job ^Run run-id))
    (swap! unsaved conj run-id)
    @saver))

This is the same tick pattern of marking the state dirty, and doing a flush on a timer. A restart loses at most a second of the log without the worry of having IO pressure. And the final state can be written synchronously when the run ends.

Summary

Each layer that I've discussed in this post removes a different kind of repeated work:

ticks ensure that one render happens per page per tick rather than per write
the component cache: further gives one render per change on each page
sliding buffers give one frame in flight per client
tx! makes it so that a render can't see a partial update
patches send the change only for the page components that changed
tables derive state from the change instead of the collection itself
release on close cleans up pages nobody is looking at

The reactive model is key for all of this, because the dependency tracking used to decide what to re-render can also be used to infer what can be skipped.

Handling Arbitrarily Nested Structures with Burp Suite

Tue, 10 Nov 2026 19:06:37 +0000

This is a blog post by Erik Szinai, who worked with us as an intern during the last couple of months. We hope our readers will find his contribution to the Burp Suite ecosystem useful!

Our new scanner for Text4Shell

Tue, 10 Nov 2026 19:06:37 +0000

Some say, CVE-2022-42889 is the new Log4Shell, for which we developed our own tool to enumerate affected hosts back in 2021. Others like Rapid7 argue that it may not be as easy to exploit like Log4Shell. Regardless of the severity and exploitability of this vulnerability, we quickly morphed a clone of our Log4Shell plugin into an open source tool that can detect this vulnerability reasonably well.

Our new tool for enumerating hidden Log4Shell-affected hosts

Tue, 10 Nov 2026 19:06:37 +0000

Log4Shell, formally known as CVE-2021-44228 seems to be the next big vulnerability that affects a huge number of systems, and the affected component, Log4j gets involved in logging untrusted data by design. This results in lots of vulnerable hosts that are hidden in the sense that naive testing won’t find them, as it’s not trivial to know which part of a complex parsing path (potentially involving multiple systems) is vulnerable. We built and released our new open source tool to find these in order to help everyone identify these before the bad guys do.

Uninitialized Memory Disclosures in Web Applications

Tue, 10 Nov 2026 19:06:37 +0000

While we at Silent Signal are strong believers in human creativity when it comes to finding new, or unusual vulnerabilities, we’re also constantly looking for ways to transform our experience into automated tools that can reliably and efficiently detect already known bug classes. The discovery of CVE-2019-6976 – an uninitialized memory disclosure bug in a widely used imaging library – was a particularly interesting finding to me, as it represented a lesser known class of issues in the intersection of web application and memory safety bugs, so it seemed to be a nice topic for my next GWAPT Gold Paper.

Unix-style approach to web application testing

Tue, 10 Nov 2026 19:06:37 +0000

SANS Institute accepted my GWAPT Gold Paper about Unix-style approach to web application testing, the paper is now published in the Reading Room.

The curious case of encrypted URL parameters

Tue, 10 Nov 2026 19:06:37 +0000

As intra-app URLs used in web applications are generated and parsed by the same code base, there’s no external force pushing developers towards using a human-readable form of serialization. Sure, it’s easier to do debugging and development, but that’s why I used the word “external”. Many frameworks use custom encodings, but one of the most extreme things a developer can do in this regard is completely encrypting request parameters. We encountered such a setup during a recent web app security assessment, let’s see how it worked out.

Snow cannon vs. unique snowflakes — testing registration forms

Tue, 10 Nov 2026 19:06:37 +0000

Many of the web application tests we conducted had a registration form in the scope. In such cases, there’s usually a field that needs to be unique for each invocation, sometimes called username, in other cases, the e-mail address is used as such. However, launching the Scanner or Intruder of Burp Suite or a similar tool will send the same username over and over again, resulting in possible false negatives. We faced this problem long enough that we came up with a solution for it, and now you can use it too!

Beyond detection: exploiting blind SQL injections with Burp Collaborator

Tue, 10 Nov 2026 19:06:37 +0000

It’s been a steady trend that most of our pentest projects revolve around web applications and/or involve database backends. The former part is usually made much easier by Burp Suite, which has a built-in scanner capable of identifying (among others) injections regarding latter. However, detection is only half of the work needed to be done; a good pentester will use a SQL injection or similar database-related security hole to widen the coverage of the test (obviously within the project scope). Burp continually improves its scanning engine but provides no means to this further exploitation of these vulnerabilities, so in addition to manual testing, most pentesters use standalone tools. With the new features available since Burp Suite 1.7.09, we’ve found a way to combine the unique talents of Burp with our database exploitation framework, resulting in pretty interesting functionality.

Detecting ImageTragick with Burp Suite Pro