Roastidio.us Tagged with web

95 reasons for having your own website in 2026 ~ Bell Kiosk

Tue, 21 Jul 2026 07:14:10 +0000

to write for oneself
to post quietly
to have a home on the open web
to keep a record of the days1
to learn how the web works
to make a friend2 across the world
to have a place to keep memories3
to learn HTML
to write lists
to keep a daily writing practice
to lean into feeling naive4
to understand more about your relationship to yourself, to others, or to the world
to write poetry
to use the web as a medium and material5
to ground oneself
to remember
to make a place for conviviality6
to create the community that you didn't have growing up
to make a photo album
as a place to rage
to recreate your old blogspot or tumblr
as a love letter
to keep <time>
to use social media7 a little less
to post for oneself
to be fragile
to ground8 yourself
to collect things and display them on a shelf together
to keep things unfinished and open ended
to contemplate your own mortality
as an activity to do with a friend, "lets make a website together"
out of boredom
to keep notes
as a medium to make a movie
an excuse to go to the park9
because vibe coding only gets you so far
for the love of the web
to pretend that it's 2010 again
to pretend that it's 2000 again
to become an island
to become an archipelago with your friends
as a form of prayer
to remember that a website is just files & folders
as a form of play
because you want to publish offline
to feel in control
to feel out of control
to stay unstructured
to think through a big life decision
to be your own localhost
to keep an index of colors
to go deep
to feel more alive when interacting with a computer
to publish without social pressure
to keep the like counter at 0
to troll yourself
to make infinite scrolling optional
to bring guest books back
to write for yourself
to show others what the web could be
to world the world
as a wish
to retain the aura10 of your work
to write your own wikipedia entry
to remove the cynicism11 from the reason
to stay grounded in the seasons12
to own what you publish
after reading an essay about what a website could be13
so that the nerds don't have the only voice on the www
as a form of care14
because it has very little to do with brutalism15
because it feels good to be alive16
as a way to find love
as a form of protest
as a radical statement
to have a clean room
to be in motion
to recharge
to draw
to try out POSSE17
as a way to go forward by looking back18
to bring web rings back
to create bridges to other activities19
to feel young and old at the same time
to archive everything20 you've ever done
to own your own instagram grid21
to learn how to juggle22
because no other medium is a container for images, audio, video, text, time, hyperlinks
it's still a largely unexplored artistic medium
to make a soup23
to create a scene report
to document a ufo sighting
to walk with
as a way to make a custom home screen for your phone
to publish your music outside the confines of the platforms

2026年前期 web-study 参加報告

Tue, 21 Jul 2026 01:35:32 +0000

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。

こんにちは、フロントエンドエンジニアのmehm8128です。

2026年の前期に、5回にわたりJxckさん主催のweb-studyにサイボウズ社員が参加しました。サイボウズからも何名か登壇しており、5回中2回は会場提供も行ったため、今回は5回のイベントを振り返っていきます。

#tpac_study

web-study.connpass.com

#tpac_studyでは、2025年11月に神戸で開催されたTPAC2025の参加報告として、現地参加した4名による発表が行われました。サイボウズのオフィスを提供し、弊社からはsakuさんとSajiさんの2名が登壇しました。

sakuさん「Drafting the Future of CSS」

sakuさんからは「標準化」自体や標準化におけるそれぞれのメンバーの役割についての解説や、CSS WGで行われたGrid-Lanes (Masonry) の議論についての発表がありました。

sakupi01.github.io

Sajiさん「Ambition and Improvement in i18n」

Sajiさんからはi18n WGで行われたDOM LocalizationやAmount要素についての議論や、それに関連してi18n WGで管理されているInternationalization Activity Blogというドキュメントについての紹介がありました。

speakerdeck.com

その他に外部の方2名から、それぞれ縦書きに関する発表「Revisiting Scope Between i18n and CSS」とAIエージェントとPaymentの関係に関する発表「Agents in Payment」が行われました。

TPACでは非常に多くのWGの議論が同時進行で行われていたため、自分の参加したWGとは違うWGに参加した方々の話を詳しく聞くことができたのが良かったです。

#temporal_study

web-study.connpass.com

#temporal_studyでは、新しい日時操作APIであるTemporalについて、弊社のSajiさんと、ふぁぼんさんの2名から発表があり、それらに関する質疑応答や議論が行われました。

Sajiさん「It's "Time" to use Temporal」

Sajiさんからは、「そもそも日時にはWallClockTimeとExactTimeの2種類がある」という話や、実際のアプリケーションで使うときにどのようなデータをTemporalのどの型で扱うべきかという点の解説がありました。また、dayjsやdate-fnsなど既存のライブラリが今後どのようにTemporalをサポートしていくのかという話は、発表後にも少し議論がありました。

speakerdeck.com

ふぁぼんさん「webにとってTemporalとは何か」

ふぁぼんさんからは、Temporalの基本や仕様に関する詳細な話がありました。ふぁぼんさん自身が作っているtemporal-polyfill-liteというpolyfillの話や、TemporalがStage 4に到達するまでになぜこんなに時間がかかったのか、仕様の分量やそれを支えるテストケースの話などが解説されました。

docswell.com

質疑応答では「Temporalが使えるようになったら、新しくJSを学ぶ人には最初からTemporalを教えるべきなのか？」など、技術だけでなく育成の観点からも今後を見据えた議論が行われました。また、参加者の中にもブラウザ実装に詳しい有識者の方がいらっしゃり、意見交換が活発に行われました。

#縦書き_study

web-study.connpass.com

#縦書き_studyでは会場としてサイボウズのオフィスを提供し、Webにおける縦書きについて外部の方2名による発表が行われました。

itoh_shimonさんからは「Mastodonにおける縦書きの諸課題」及び「中国語、韓国語、モンゴル語の縦書き」の2つの発表がありました。どちらも共通して、右縦書きである中国語・韓国語や左縦書きであるモンゴル語など、外国語に焦点を当てた発表でした。 berlysiaさんからは「縦書きWebの現在地概略」「縦書きWebを身近なものにするために」という2つの発表がありました。こちらはどちらかというと日本語のサービスや、「縦書きを使って遊ぶこと」についての発表でした。

発表後は質疑応答や関連したテーマについての雑談などが行われました。

#rich_text_editor_study

web-study.connpass.com

#rich_text_editor_studyでは、4名からリッチテキストエディタに関する発表が行われました。弊社からはコサキンが登壇しました。

コサキンによる発表

コサキンからは「RTEライブラリの仕組みとそれを支えるブラウザ機能」というタイトルで、RTEの基本的な仕組みやcontenteditableについての解説がありました。また、他3名の発表を挟み、「WYSIWYG ルビ入力の概要と Chromium のバグを修正した話」というタイトルで、ルビ入力やそれに関するChromiumのバグ修正に関する発表も行われました。バグ修正については、5月版のWeb標準動向でも紹介しています。

speakerdeck.com

他3名からは、それぞれ「フロントエンドだけで戦わない、既存 wiki サービスへの WYSIWYG エディタ導入記」「ページ構造の中で考えるリッチテキスト」「Tiptapで校正機能を作った時に考えたこと」という発表がありました。

#webfont_study

web-study.connpass.com

#webfont_studyでは、Webフォントに関する発表が行われました。新しく仕様が策定されているIncremental Font TransferというWebフォントの転送方法についての発表や、Noto Sans JPについての話、それらについての質疑応答や議論がありました。弊社からの登壇や会場提供はありませんでしたが、登壇者からの発表後には意見交換などが行われました。

弊社のプロダクトデザイナーこばりょーによる、参加記事も併せてご覧ください。

www.ryota5884.com

まとめ

個人的に、RTEやWebフォントなどは普段あまり積極的にキャッチアップしない分野なので、話を聞く良い機会になりました。

サイボウズは2025年4月のW3C加入や11月のTPAC参加を機に、Web標準に関するイベントに関わる機会をいただくことが多くなっています。今後も様々な形で積極的に関わりたいと考えているので、引き続きよろしくお願いします。

また、7/27（月）にも、弊社オフィスでweb-studyが開催される予定なのでこちらも楽しみです。

web-study.connpass.com

MarkuplintでHTMLの品質を守る

Tue, 21 Jul 2026 01:35:32 +0000

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。

こんにちは！サイボウズでフロントエンドエンジニアをしているたくぼうです！

はじめに

フロントエンドの開発では、JavaScript には ESLint、CSS には Stylelint と、Lint ツールを入れるのが当たり前になっています。

一方で HTML はどうかというと、意外とノーチェックのままになっていないでしょうか。

HTML は多少間違っていてもブラウザがよしなに表示してくれるので、問題に気づきにくい言語です。

ただ、崩れた入れ子、抜けた alt、ひも付いていない label といった小さな乱れは、アクセシビリティや SEO、コードの保守性にじわじわ効いてきます。

この記事では、そんな HTML のための Lint ツールMarkuplintを紹介します。あわせて記事の後半では、実際にモノレポ構成の kintone へ導入してみた事例も紹介します。

Markuplintとは

Markuplint は、その名のとおりマークアップのための Lint ツールです。

markuplint.dev

HTML の文法ミスやアクセシビリティ上の問題、非推奨の書き方を静的解析で検出してくれます。

素の HTML だけでなく、JSX（React）や Vue、Svelteといったテンプレートに書かれたマークアップも、後述する仕組みでチェックできます。

もう一つの特徴は、ルールを柔軟に設定できることです。

HTML 仕様への準拠を確認するだけでなく、チームやプロダクト独自のマークアップ規約を Lint として表現する使い方にも向いています。

何をチェックしてくれるのか

具体例を挙げてみます。レビューで指摘した覚えのあるものが混じっているのではないでしょうか。

要素の入れ子の妥当性（span の中に div は置けない → permitted-contents）
必須属性の欠落（img の alt → required-attr）
アクセシビリティまわり（label との関連付け、table の caption、WAI-ARIA の誤用、id の重複）
非推奨の要素・属性

たとえば次のように span の中に div を書いたとします。

<span><div>テキスト</div></span>

すると、次のようなエラーが出ます。

error: このコンテキストでは、要素spanに要素`div`を含めることはできません (permitted-contents)

エラーメッセージが日本語で出てくれるのも強みの1つです。

参考

ESLintのプラグインとの違い

required-attr や wai-aria のようなチェックは、React であれば eslint-plugin-jsx-a11y でも一部カバーできます。

「それなら ESLint だけでいいのでは？」と思うかもしれませんが、公式の FAQ でも触れられているとおり、Markuplint ならではの強みがあります。

要素の親子関係（構造）の適合性チェック（permitted-contents）ができる
強力なセレクタ機能で、ルールを細かく制御できる
HTML や JSX 以外の構文も幅広くサポートしている

一方でonClick を付けた要素にキーボード操作の考慮を求めるようなイベントハンドラ起点のチェックなど、eslintにしかできないこともあるので併用も可能です。すでに eslint-plugin-jsx-a11y を入れているプロジェクトでも、置き換えではなく足す形で導入できます。

参考

HTMLHintやeslint-plugin-jsx-a11yと何が違うの？ | Markuplint

導入と設定

まずは `--init` から

導入は簡単で、対話形式で設定ファイルを作ってくれる --init を実行するだけです。

npx markuplint --init

使っているテンプレートエンジン（React や Vue など）や、推奨設定を取り込むかどうかを聞かれるので、答えていくと設定ファイル.markuplintrcが生成されます。

markuplint.config.js のような形式でも書けます。

設定の土台になるのが、公式の推奨プリセット markuplint:recommended です。

extends に指定すると、入れ子の妥当性（permitted-contents）、必須属性（required-attr）、WAI-ARIA（wai-aria）といった主要なルールがまとめて有効になります。

まずはこれを土台にして、あとから必要に応じて足し引きしていくのがおすすめです。React の場合は、後述する React 版のプリセットもあります。

Parser と Spec の設定

Markuplint でコンポーネント内のマークアップをチェックするには、Parser と Spec という2つの設定が必要です。

それぞれの役割は次のとおりです。

parser: ファイル拡張子（正規表現）に対して、その構文を解釈する Parser を紐づける
specs: 同じく拡張子に対して、フレームワーク固有の属性を認識させる

この2つを設定に足すだけで、JSX やテンプレートの中のマークアップも正しくチェックできるようになります。

対応しているフレームワーク

Parser と Spec は特定のフレームワーク専用ではなく、主要なフレームワーク向けにパッケージが用意されています。

Vue: @markuplint/vue-parser + @markuplint/vue-spec
React: @markuplint/jsx-parser + @markuplint/react-spec
Svelte: @markuplint/svelte-parser
Astro: @markuplint/astro-parser

Vue・React・Svelte には推奨プリセットも用意されています。

Reactで使う

Reactでは、@markuplint/jsx-parser と @markuplint/react-spec を導入します。

npm install -D @markuplint/jsx-parser @markuplint/react-spec

設定ファイルでは、parser で .jsx / .tsx に JSX Parser を、specs に React Spec を紐づけます。

React 専用の推奨プリセット markuplint:recommended-react が用意されているので、extends にはこれを指定するのが手軽です。

{
  "extends": ["markuplint:recommended-react"],
  "parser": {
    "\\.[jt]sx?$": "@markuplint/jsx-parser"
  },
  "specs": {
    "\\.[jt]sx?$": "@markuplint/react-spec"
  }}

React Spec を入れないと、key のような React 固有の属性が「HTML 仕様に存在しない属性」として誤検知（invalid-attr）されてしまいます。

Spec を入れることで誤検知が消え、本当に直すべき問題だけが残ります。

なお、先ほどの --init でReactを選ぶと、このあたりの設定はほぼ自動で書き出されます。

まずは --init に任せて、生成された設定を見ながら理解していく進め方でも十分です。

コンポーネントをHTML要素として評価する（pretenders）

Parser と Spec を入れても、まだチェックしきれないケースがあります。カスタムコンポーネントです。

たとえば li をコンポーネント化した次のようなコードを考えます。

<ul><ListItem /><ListItem />
</ul>

Markuplint からは ul の直下に ListItem という未知の要素が置かれているように見えるため、本来チェックしたい ul > li の構造を検証できません。

これを解決するのが pretenders（プリテンダー機能）です。「このコンポーネントはレンダリングされるとこの要素になる」という対応を設定で教えると、各ルールがコンポーネントをその HTML 要素とみなして評価してくれます。

{
  "pretenders": [{ "selector": "ListItem", "as": "li" }]}

as はオブジェクト形式でも書けて、レンダリング後の要素が持つ属性（attrs）や、コンポーネントの属性を引き継ぐか（inheritAttrs）まで指定できます。

コンポーネントの数だけ設定が増えていくのが難点ですが、まずはエラーが出た箇所から少しずつ足していく運用で十分機能します。

参考

ルールのカスタマイズ

推奨プリセットのままでも十分使えますが、運用していくとプロジェクトに合わせて調整したくなる場面が出てきます。

いちばん簡単なのは、rules で個別ルールのオン・オフを切り替えることです。false で無効、それ以外の値で有効になります。

{
  "rules": {
    "required-attr": true,
    "indentation": false}}

特定の要素にだけルールを効かせたい場合は、nodeRules（対象要素そのもの）や childNodeRules（対象要素の子・子孫）にセレクタで指定します。

たとえば img に alt を必須にする場合は次のとおりです。

{
  "rules": {
    "required-attr": true},
  "nodeRules": [{
      "selector": "img",
      "rules": {
        "required-attr": "alt"
      }}]}

required-attr のように要素の種類ごとに設定したいルールは、こうして nodeRules に書くのが公式でも推奨されている使い方です。

カスタムルールの自作もできますが、組み込みルールのオン・オフと nodeRules での絞り込みだけでも、かなり実用的な運用ができると思います。

参考

ルールを適用する | Markuplint

既存プロジェクトへの組み込み

実際のプロジェクトで動かす方法は大きく二つあります。CI で機械的に回すか、エディタでリアルタイムに指摘してもらうかです。

CI に組み込むなら、package.json の scripts にコマンドを足しておくのが素直です。

{
  "scripts": {
    "lint:markup": "markuplint \"./src/**/*.tsx\""
  }}

これを CI で走らせれば、規約から外れたマークアップがそのままマージされるのを防げます。

あわせて VS Code 拡張（Markuplint）を入れておくと、書いているそばから警告が出るので、CI で弾かれる前に気づけます。

MarkuplintのVScode拡張でrequired-attrのエラーが出ている様子

参考

カスタムルールで独自の規約をチェックする

Markuplint はカスタムルールも書けます。

たとえば「.js-toggle クラスを付けた要素には aria-expanded を必須にする」というチェック。こうしたクラス名と属性のマッピングはチーム固有の知識なので、既存のルールでは表現できません。

カスタムルールは createRule で定義し、プラグイン（name + rules）として包んでエクスポートします。

// my-plugin.jsimport{ createRule }from'@markuplint/ml-core';const requireAriaExpanded =createRule({asyncverify({document, report }){awaitdocument.walkOn('Element',(el)=>{if(
        el.classList.contains('js-toggle')&&!el.hasAttribute('aria-expanded')){report({scope: el,message:'.js-toggle 要素には aria-expanded が必要です',});}});},});// プラグイン化: name + rules で包むexportdefault{name:'my-rules',rules:{'require-aria-expanded': requireAriaExpanded },};

あとは設定ファイルの plugins に登録して、プラグイン名/ルール名 で有効化します。

{
  "plugins": ["./my-plugin.js"],
  "rules": { "my-rules/require-aria-expanded": true}}

これで、チームの規約が組み込みルールと同じようにチェックされます。

規約をコードにしておけば、レビューの目視に頼らず機械的に担保できます。単なる HTML チェッカーを超えて、プロジェクトのマークアップ規約を支える基盤としても使える、というわけです。

参考

カスタムルールをつくる | Markuplint

kintoneでの活用

kintone でも、アクセシビリティの確保やコード品質の保証を目的として、Markuplint の導入を試みました。

kintone は複数のパッケージを抱えるモノレポ構成です。

開発フローに乗せるなら、CI で回すだけでなく、VS Code 拡張でエディタ上にリアルタイムに警告が出る状態が理想です。

モノレポでハマったところ

リポジトリのルートを VS Code で開くと、拡張が次のような警告を出してうまく動きませんでした。

Since markuplint could not be found in the node_modules of the workspace,
this use the version (v4.12.0) installed in VS Code Extension.

kintone のディレクトリ構造は、ざっくり次のようになっています。

kintone/              # リポジトリのルート
└─ frontend/
   ├─ pudding/        # チームのディレクトリ
   │  ├─ app/         # 領域やパッケージごとのディレクトリ
   │  └─ mobile-app/

Markuplint が各パッケージの下にインストールされている構成だと、ルートを開いただけでは拡張がそれを見つけられず、プロジェクト固有の設定やプラグインを反映しないままチェックが走ってしまいます。

当面の回避策は、ルートではなくパッケージのディレクトリを直接開くことです。

ただ、これは v5 系で解消できます。

v5.0.0-alpha.2 で VS Code 拡張に workingDirectories オプションが追加され、モノレポ内の複数のパッケージをワーキングディレクトリとして指定できるようになりました。これを設定しておけば、ルートを開いたままでも、各パッケージの設定と Markuplint が正しく解決されます。

たとえば app と mobile-app を対象にするなら、次のように指定します。

{
  "markuplint.workingDirectories": ["app", "mobile-app"]}

プレリリースの段階なので今後変わる可能性はありますが、モノレポでエディタ連携を諦めていた場合は、v5 系を試す価値があります。

参考

Release v5.0.0-rc.4 · markuplint/markuplint

まとめ

ESLint や Stylelint と比べると、Markuplint はまだ知名度が高くありません。

カスタムルールまで書けば、チーム固有の規約を組み込みルールと同じ土俵でチェックすることもできます。

HTML のチェックが手つかずになっているプロジェクトには、十分導入する価値があると思います。

ぜひ、まずは推奨プリセットから手軽に始めてみてください。

Workshop Basel day three

Mon, 20 Jul 2026 23:10:51 +0000

Why MOQ is going to replace HTTP live streaming

MOQ (Media over QUIC transport) is not HTTP, but it uses QUIC so it is at least tangentially interesting and it involves a lot of the same people so this status update still felt welcome and suitable. Compared to existing HTTP based solutions, MOQ is supposed to offer less complexity and lower latency. The moon landing was broadcasted with less latency than current live-streamed TV and maybe MOQ can make us come close to those numbers again. In MOQ clients subscribe to a track that then contains a lot of objects that are delivered. It’s not the request + response approach of HTTP. The fact that this is not HTTP of course brings a lot of questions and well, doubts, and we lingered on various aspects of this topic for quite a while.

Reverse HTTP

My prize for the best slides of the HTTP workshop 2026 goes to [redacted] for the excellent use of potato images in their presentation.

PTTH is HTTP spelled backwards, commonly pronounced as PoTaToH. A client sets up the connection but the actual HTTP request is sent from the server to the client. One of the intended use cases for this, is to allow an origin server to connect to the CDN proxy and then be able to deliver traffic to the world, rather than to have the CDN connect to the origin the way they usually do. Apparently most CDNs already have custom and proprietary solutions for exactly this kind of feature, so maybe doing it in a standard way instead makes sense?

Resumable uploads

The draft explains the new proposed way to continue a previously interrupted upload over HTTP. The upload request gets a Location: header back for the resource being uploaded, and if it gets stopped prematurely, a client can then HEAD that resource, figure out the size and then do a second upload (using the PATCH method) request that tells the server that this transfer should start at offset X.

Exactly how this should be supported in browser’ upload forms seemed a little bit uncertain. For my own sake I can see a challenge to implement this nicely for curl in particular when the upload is using formpost upload (curl’s -F flag) which after all still is a very common way to do uploads on the current web. I’ll return to this topic at a later time when I written an implementation to test…

io_uring vs. multithreaded server runtimes vs HTTP mismatch

io_uring is a Linux asynchronous I/O framework that avoids the overhead of traditional system calls. It uses two shared ring buffers between user space and the kernel, allowing applications to batch I/O operations with zero-copy efficiency.

The feature is disabled by Google in ChromeOS, Android and in production Google servers which certainly holds back some use of it.

io_uring can be helpful to speed up things, but might be complicated to use in existing software architectures and the presentation went into some details on why this is so.

Modern UDP I/O for Firefox in Rust

A walk-through of some of the recent developments and improvements in Firefox’s UDP networking stack. Going from single datagrams to the modern ways to ship large chunks of data offloaded to the kernel to speed things up. Upload throughput in Firefox is up 60-90% over the last 11 releases. Lots of fun graphs and metrics were shown. This work is based on the quinn-udp stack.

Rollout of Happy Eyeballs v3 in Firefox

Happy Eyeballs v3 is coming and Firefox is implementing it. It now takes into account many more data sources than before, including alt-svc and HTTPS-RR and races connections against each other to use the one that connects first. There are some recommended timers in the specification and parts of the discussion was around how maybe the timers could instead be tightened a bit, and maybe the delay between the subsequent attempts could then use an exponential backoff instead sticking to a fixed interval?

(I know I’ll discuss some of these details with my curl hacker friends and see what we should adjust… curl already supports most of the Happy Eyeballs v3 specification.)

Shorter ones

As we approached the end of the day a few shorter topics were ventilated to give us a little more to consider before going home:

Why is there no UTF8 in URIs? “If we would do it again, we would have allowed UTF8 in there” was said by someone who was there in the mid 1990s…
Optimistic DNS is a draft. Use stale DNS cache data while getting the new. Connection remains alive for 120 seconds while DNS data is often not cached for even 30 seconds. No one in the room seemed to hate it. Let’s do this!
The journey to QUERY. One of the primary authors of the RFC took us through what it took to make it happen. It was sixteen years since the most previous registered HTTP method and maybe this was the last one ever?

The end for this time

With this, the seventh HTTP workshop had ended. Again a very fine event. This time graciously sponsored and arranged by Adobe. Thank you everyone!

The general idea is to continue with these events roughly every second year and I support this. The HTTP workshops are definitely one of my favorite events.

Credits

The top image on this post was used in the final presentation and the author told me he is aware of the AI errors in there, “of which there are at least two”.

Workshop Basel day two

Mon, 20 Jul 2026 23:10:51 +0000

If you missed it. I already described day one.

Caffeinated and ready, we all gathered in the same spacious room as yesterday, but seated in new places as “suggested” by our captain. Some of us even remembered to move over the name tags we wrote yesterday to our new seats.

No time was wasted on introductions today. We dove straight in at the deep end.

How AI is changing how HTTP is implemented.

Is the future of software that we check-in the AI prompts in the git repository and trust it to generate the correct code? Are specifications the new level o

f abstraction for source code? These questions triggered long discussions with a huge mix of opinions and experiences getting shared about how AI is used, should be used and could be used now and in the future.

Observations and Measurements of HTTP/2 During Large-Scale Web Crawls

The Common Crawl spidering upgraded to using HTTP/2 for their scan and as an end result, I believe 61% of the responses used HTTP/2 and the entire round ended a few percent faster than before, which when you traverse a few billion URLs really makes a difference. They apparently use a locally patched version of Apache Nutch for this.

HTTP/1.1 behavior divergence

The HTTP probe project runs a lot of tests on HTTP/1 servers and compares how they behave in a lot of different aspects and then generates these awesome tables. Looks like something for every server implementer team to have a look at and decide what of these red boxes that should rather be converted into green alternatives.

Request smuggling test suite

HTTP Zoll is a newtest suite for intermediaries that tests intermediaries (what we often call proxies) for a large amount of request and response smuggling issues. Some real world problems found were discussed and as this project aims at going Open Source words were expressed on what kind of precautions and checks that maybe should be done first. I hope we get to hear more about this project soon.

Server performance & measurement

The HTTP Arena is another project that does performance and measurements. They test HTTP server frameworks and present the results in various ways on their site.

Increase and evolve HTTP/3 & QUIC

In this presentation, we were presented with different HTTP/3 deployment numbers from different sources and the associated reasoning around why they differ but then more importantly. what can and should be done to increase HTTP/3 usage.

Anti-virus interceptions, enterprise blocks and server-side performance not yet on par with TCP were mentioned as reasons for holding back the numbers.

Reasons for using HTTP/3 include use cases that encourage QUIC adoption: WebTransport, Media over QUIC and MASQUE (HTTP/3 proxies and HTTP/3 proxies over older HTTP proxies).

Using HTTPS-RR for upgrade was promoted, as every alt-svc response that is returned with an ALPN using h3 should perhaps also offer h3 over DNS. Why doesn’t your server announce its h3 support over HTTPS-RR?

QUIC v2 is deployed on an amazing 0.003% of all QUIC v1 domains and there was a discussion why this is so and the common sentiment in the room seemed to be that very few saw a reason for deploying v2 and several expressed a concern that doing so might in fact introduce issues. Someone (you can probably guess who) in the room increased that number a lot by quietly mentioning that haxproxy.org certainly supports it.

QMUX

QUIC multiplexing over bi-directional streams is a proposal on how to do QUIC-style multiplexing over TLS (or anything else really). It has been adopted by the IETF QUIC working group and there was a somewhat extended discussion about what the HTTPbis group should or should not do with it. The biggest interest might be for data center use, but is that then something IETF should bother about? This is not the first time I blog about this, and even if there did not seem to be a strong demand or need for this, it also did not seem to be completely dead. I bet we will hear more about this later.

Multiplexed proxying: challenges in H2 and H3

Doing a TLS terminating MITM proxy has its challenges and we were given some insights and experiences on the challenges of doing HTTP/2 and HTTP/3 to the server.

The browsers refuse to do HTTP/3 when they detect custom CA certs installed, which apparently is mostly because of lots of past bad experiences with anti-virus software that in particular seems to break QUIC and for users it is not obvious where the blame should go. This then makes browsers not do HTTP/3 over any MITM proxy.

Some time was spent on how allowing different clients to the proxy uses a shared h2 connection to the target server is complicated and not used, even though in theory it should be possible. An argument was made that it could even lead to worse performance than when using HTTP/1 but I could not quite follow that reasoning. I’m sure I missed some subtle detail in that explanation.

Making the Web QUICer with Rapid Start

When the afternoon is running late and we have been promised beer and snacks after the final talk, what is better than a hard core technical presentation with lots of graphs and numbers showing how QUIC performance can be improved by tweaking the congestion control algorithm and send more data in the startup phase of a new QUIC connections? This new approach is called Rapid Start and it looks like a promising and yet simple improvement. According to experiments done on real world traffic, the time to last byte was reduced by 14.7% on average. Not bad at all.

Drinks and food

Our meeting sponsor Adobe graciously sponsored drinks and food so we got to linger around for a few extra hours and talk even more HTTP and networking until the personal firmly insistent they needed us to leave the room and we instead continued solving world problems elsewhere. Topics around the table included the famous HTTP/2 spec coin flip, the QUIC spin bit, the SCONE situation for QUIC, the timeline behind the QUERY method and many more great stories.

Thanks for the beer!

Now we can’t wait for day three.

Workshop Basel day one | daniel.haxx.se

Mon, 20 Jul 2026 23:10:51 +0000

On this hot summer’s day in Basel, Switzerland, the seventh HTTP workshop started. These events tend to work roughly the same way and the people in the room are also to large extent familiar and known since previous editions. Forty people in a meeting room, where we take turns in doing short talks on HTTP and networking topics, with the following question and discussion session. The rules for the meetings are explicitly Chatham rules, which means that everything I write about the meeting will be sufficiently fuzzy and without many company or personal names. This is not the kind of meeting that can be easily summed up in a short blog post anyway. You really should be here.

Present in the room were representatives from all the world’s most prominent and used HTTP deployments: clients, browsers, CDNs, proxies and servers. I’m happy to say that there were also several first-timers. We like fresh blood.

(If you think I’m being overly brief or vague about specifics in this post; that is partially on purpose but primarily because I’m a lousy note-taker and mostly write this up after a busy day that also may have involved beer.)

After a round of introductions, we started.

Extending REST for State synchronization

REST is a set of constraints, and in this presentation it was argued that it can or maybe even should be extended to do more. A number of recent applications like Mastodon/ActivityPub, Bluesky/AT, Matrix, Nostr, IndieWeb, all currently use HTTP to do state synchronization but they all do it differently in their own unique ways. Can REST and maybe HTTP be adjusted to help this for improved interoperability?

Last-Modified header use over time

Looking at the Common Crawl data and comparing data over time, it was observed that responses use the Last-Modified header field more now than they did in the past, and there were great follow-up speculations on why this is so. Data also shows that a large share of these headers present dates that are almost identical to the time the requests were issued.

How is HTTP used in the world?

With the cc-lint tool, data was gathered on how HTTP is actually used today, proving that there is work to be done: deprecated headers are used, some headers are done wrong, and many are overly big. This indicates that there are well used both servers and clients out there that would benefit from cleanup. It probably also shows that doing HTTP correctly and all the correct headers is far from an easy task.

AI-bots’ use of HTTP

Another presentation showed data, this time from a well-known CDN, on the impact the existing AI scraper bots have on the Internet from their point of view. It showed that roughly half of the requests and half of the bandwidth are spent by scraper bots. A long discussion followed where the numbers were questioned as maybe the numbers look like this because a sufficiently large number of the “bad AI scrapers” appear as regular users to the classifiers. Speculations of different kinds were made.

The Apple HTTP stack two years later

As a follow-up from a presentation from a previous HTTP workshop we got to learn how the journey on developing their new HTTP stack has progressed and several fun adventures and lessons from that were shared with the audience.

Why new HTTP APIs?

A look into new HTTP API development at Apple. Some discussions and lessons learned from creating new APIs for both servers and clients.

Android Networking

We got an excellent walk-through of some details and internals of the Android networking stack. Emphasis was perhaps especially put on ECH and QUIC connection migration, and the final “don’t tell us when your connection closed” led to a long new discussion on how we really should fix the problem: when connection has been left idle for a long time and it is closed by the server, the client (mobile phones) don’t want to be told. This, because getting that RST and more, just wakes up the radio and more on the phone only to tell it to go back to sleep. It was theorized that if we could get rid of this unnecessary battery waste, the accumulated gain across billions of devices would make a serious dent.

Day one world problem solving

Several additional HTTP related problems were of course also subsequently solved as we then wandered into the city for dinner and maybe a beer. Of course yours truly returned back to his hotel room in good time to be able to write up this blog post.

The best part of these workshops might be the (no pun intended) networking and discussions had completely outside of the agenda.

End of day one. Two more to come,

I like using scrollbars

Mon, 20 Jul 2026 11:51:22 +0000

I like to use scrollbars. I move my mouse cursor to the scrollbar handle and move it about – scrolling like this is so much faster than with the wheel if you want to scroll more than a few lines.

I didn’t notice how often I did this until sites started breaking this. It seems to be fashionable to put a margin around the entire document, resulting in the scrollbar no longer being aligned to the edge of the screen.

This is an absolute bollockache because now you can no longer just move the mouse to the edge of the screen: you need to place it exactly on the scrollbar, requiring far greater precision.

You can see an example at /scrollmargin.html. You need a device with a mouse cursor to see the problem of course.

Some real examples, all of which started doing it in the last year or so:

FastMail
Outlook365
Stack Overflow “Beta Redesign”, although that was aborted.
Spotify (example)
GitLab (example)
Couchsurfing now completely hides the scrollbar (example) (aside: I am not saying that Couchsurfing has been infiltrated by AirBnB agents to run this communist woke libtard competition in to the ground, but I am saying that nothing Couchsurfing has done over the last 10 years contradicts that hypothesis.)

There is of course also the perennial “inappropriate scrollbar styling” problem, and recently ultra low contrast have also gained popularity; for example:

Substack (example)
MariaDB documentation (example)

I’m not against any scrollbar styling; in some cases it’s appropriate. Some more playful websites, some very specific and rare webapp use cases, things like that. I’m not a “system behaviour in every single last scenario” purist. The MariaDB reference docs is very much not one of those cases.

I like using scrollbars. I can’t be the only person who does. You’re frustrating users for no reason other than following some fad that makes things look ever so marginally nicer. No one pays that much attention to your design and they won’t notice. In ten years time everyone will look back at this in the same way we look back that extremely low contrast text fad from a decade ago: “yeah, that was rather silly”.

The notification that gave up after a minute | jvalol

Mon, 20 Jul 2026 00:43:15 +0000

The notification that gave up after a minute

Projects

Popsicleboat, Web-Push

July 17, 2026

PopsicleBoat grew browser push notifications recently. The pitch is simple: hear when someone answers you, without handing anyone an email address. Your browser asks permission, a subscription goes to the server, and nothing personal leaves the device. I shipped it, watched the push service accept my first delivery with a tidy 201 Created, and felt good about the whole thing.

Then I replied to one of my own posts from my phone, looked at my laptop, and saw nothing.

No banner. No chime. The reply was on the site, the inbox badge lit up, the notification email arrived — every channel working except the one I’d just built. And here’s what made it a good puzzle: every layer of the push stack, inspected on its own, reported success.

The server sent the notification. The push service accepted it. The subscription was in the database. The service worker was registered. Four green lights, zero banners.

Web push is a relay race with four runners: your server signs a message and hands it to a push service (Google’s, for Chromium browsers), the push service holds it for the browser, the browser wakes a service worker, and the service worker asks the operating system to draw a banner. A dropped baton anywhere shows up the same way — silence at the finish line — and no runner files a report.

The first dropped baton was mine to find in the browser console. Notification.permission said "default". Not "granted", not "denied" — never asked. Somewhere between enabling notifications and testing them, the site’s permission had ended up back at square one — a site-data sweep, probably — while the subscription it had authorized lived on in my database, perfectly valid, pointing at a browser that would no longer show anything. In that state, a page calling new Notification() doesn’t error. It does nothing, silently, which is a bold choice for an API whose entire job is being noticed.

One re-grant later (“forever,” this time), banners worked. Victory lasted about an hour, until I noticed pushes still vanished whenever the browser wasn’t running.

That was the second baton, and it was hiding in a default I’d never questioned. Push services will happily hold a message for a browser that’s closed — that’s the whole point of the relay — but only as long as the message’s time-to-live allows. The library I use sets that TTL to sixty seconds unless told otherwise. Sixty seconds. Close your laptop, get a reply two minutes later, and the push service shrugs and discards it. The 201 it returned was entirely honest: message accepted. Nobody promised kept.

The fix is one option:

send_notification(payload, message, ttl: 86_400)

A day. That’s roughly how long “someone answered you” stays worth interrupting someone for; any older and it’s the inbox’s job, which never forgets.

Two lessons sailed home with this one. First: in a layered system where every layer answers “OK,” the bug lives in the gaps between the layers — the permission that reverted between grant and use, the message that expired between accepted and delivered. Debugging meant walking the relay in order and asking each runner not “did you succeed?” but “what did you hand the next runner, and did anyone catch it?”

Second: defaults are decisions someone else made about your product. A conservative browser permission model, a sixty-second TTL — both defensible choices, by people who’d never seen my notification settings page and its promise to hear when someone answers you. Keeping that promise meant finding every default standing between the reply and the banner, and overruling the ones that disagreed with it.

The banners arrive now. Even the morning after.

Guidelines for URL Storage and Comparison

Sun, 19 Jul 2026 15:51:08 +0000

This document contains some thoughts about the storage and comparison of URLs, common operations crucial to the correct function of security software like Microsoft SmartScreen.

Importantly, URLs are also displayed on security surfaces to enable the user to make a decision based on their contents. Eight years ago, I wrote the Guidelines for URL Display.

Background

The Web allows linking and retrieval of various resources via an address known as a URL. A URL (Uniform Resource Locator) is an identifier used to locate a resource on the Internet. (Note: “URI” stands for Uniform Resource Identifier, and in the real world, the two terms are used interchangeably).

It’s tempting to think of URLs as plain strings because almost all clients (like web browsers) and servers accept URL input as strings. However, despite the existence of various standards for the representation of URLs, there is considerable variation in the handling of URLs that creates inconsistency and variability in the interpretation of URL values. Additional complexity arises because URLs can include seldom-used components that must be understood to properly interpret the URL, and the URL syntax varies between different URL protocol schemes (e.g. HTTPS/HTTP/FTP/mailto/blob/data, etc).

The complexity of URLs is often exploited by attackers, either to socially-engineer users (as in phishing attacks) or to bypass security checks in code.

URL Encoding as Strings

In their canonical form, HTTPS/HTTP URLs are meant to contain only a subset of US-ASCII characters, where characters outside of that subset (e.g. emojis; international character sets like Cyrillic, Hiragana, Katakana, Kanji, etc; and ASCII characters like :@/\?# that are reserved for use to delimit URL components) are meant to be escaped. Escaping is a system whereby a character’s UTF-8 octet (byte) representation is serialized to ASCII by preceding each octet’s value with a % character. For example, the URL:

https://webdbg.com/자연생?자연생=ΉЄլլՓ#활의집

…after escaping, is represented as: https://webdbg.com/%EC%9E%90%EC%97%B0%EC%83%9D?%EC%9E%90%EC%97%B0%EC%83%9D=%CE%89%D0%84%D5%AC%D5%AC%D5%93#%ED%99%9C%EC%9D%98%EC%A7%91

Within a browser, you can see both forms:

In this example, the 자 (Hangul Syllable Ja) character has the UTF-8 encoding 0xEC 0x9E 0x90, which is escaped in the URL to the sequence %EC%9E%90, while the Փ (Armenian Capital Letter Piwr) character with the UTF-8 encoding 0xD5 0x93 is escaped to %D5%93.

The hostname of the URL does not use %-escaping, instead relying on a much more complicated escaping mechanism (Punycode), wherein each DNS label component containing non-ASCII characters is prefixed by xn-- followed by ASCII text that encodes any non-ASCII characters. For instance, a URL containing hostname characters from Thai and Latin character sets:

https://தேடல்.example.baydengrátis.com/자

…is encoded as:

http://xn--mlcj7bwe6a.example.xn--baydengrtis-r7a.com/%EC%9E%90

Security Landmine: Inconsistent Client Support

However, not all clients properly support standards-based encoding behaviors– some clients aim to maintain legacy compatibility with behaviors that existed before the current standards were written.

In particular, Microsoft’s MSHTML (and the WinINET network stack beneath it) used by Internet Explorer, Web Browser Controls (WebOCs) and other common Windows platform features, only implements the standards-based behavior when certain flags are set. Otherwise, MSHTML can put raw UTF-8 octets in the hostname component, and put ANSI codepaged (ACP) octets in the path, query, and fragment components.

The snowman emoji is properly UTF-8 escaped in the path component, and it is thunked down to a question mark ? in the query component (as the target character doesn’t exist in the system codepage). However, if we instead pick a character in the system codepage, we see the path component is UTF-8 escaped, but the query string’s raw ACP octet is put out on the wire:

Furthermore, this path-escaping is sensitive to the checkbox in the Internet Control panel, such that even the path may be sent without escaping if the “Send URL path as UTF-8” checkbox is unticked:

From https://stackoverflow.com/a/18220123, variables involved (in the encoding determination) include:

Where the URL was typed (e.g. address bar vs. Start > Run, etc)
What the system’s ANSI codepage is (e.g. what locale the OS uses as default)
The charset of the currently loaded page in the browser

WinINET exposes the following option flags to control what octets are “put on the wire”:

INTERNET_OPTION_CODEPAGE
INTERNET_OPTION_CODEPAGE_PATH
INTERNET_OPTION_CODEPAGE_EXTRA

The Default URLMon codepath sets those options inside based on conditional logic, while the EdgeHTML fork of URLMon more simply sets them. Computation of the options is complex: for instance, Edge Legacy checks not only the Zone but also allows a Microsoft-delivered CompatView list to weigh in on the proper encoding.

Beyond the WinINET behavior, it is believed that many other HTTP stacks do not properly handle corner-cases (e.g. being passed URLs that do not follow standards-based escaping rules, contain octet sequences that cannot be validly represented in Unicode, utilize overlong encodings, etc.

URL Components

A URL is made up of a sequence of components. For example, an absolute URL containing all available components for the HTTPS protocol scheme might look like this:

In contrast, a relative URL, as seen within a web page, might be as simple as /file.html.

Making URLs Absolute: Combine

Relative URLs are rarely usable on their own; typically, the first thing that code must do before operating on a relative URL is convert it to an absolute URL by performing a combine operation on the relative URL with the absolute URL of its context (e.g. the web page in which it appears) to generate a new absolute URL. For example, combining https://user:pass@sub.example.com:8080/path?query#fragment with /file.html results in an absolute URL of https://user:pass@sub.example.com:8080/file.html. In this combination operation, the context URL’s path is overwritten, and its query and fragment components are dropped.

Deep Dive: Components

Let’s look at each of the URL components and explore how attackers might attempt to confuse code or humans with each component.

Component: Scheme

The scheme component of the URL designates what underlying protocol should be used to retrieve the information, as well as dictating the rules for interpreting the rest of the URL, including whether it uses the standard hierarchical syntax (e.g. HTTP/HTTPS/FTP/FILE) or the opaquegeneric syntax (e.g. mailto/data/blob).

Clients only support a limited set of URL schemes. Adding new schemes to browsers to retrieve resources or to open external applications generally requires installing native code; a web-platform mechanism allows adding schemes from JavaScript, but when invoked the custom-scheme URL is simply translated into a HTTPS URL for further use.

Security Considerations: Supported Scope

Each security-sensitive client must consider how it handles less common URL schemes; many clients will block all URLs except those using popular schemes (HTTP/HTTPS/mailto), but some clients (e.g. browsers) must support invocation of arbitrary URLs.

Because uncommon schemes are a common vector of security compromise, the decision of how to handle such schemes is an important one. If a security mechanism deems certain schemes out-of-scope, then the user could be exploited by those schemes. For example, mailto: links can be used in phishing:

Security Considerations: Parsing changes by Scheme

Each feature that attempts to analyze a URL for security purposes must understand the scheme of the URL and the rules by which it is parsed. For example, a mailto URL uses the format mailto:user@host.com?subject=messagecontent whereby the Internet address appears in the middle of the URL alongside other optional field content.

Security Considerations: Not All Schemes are Routable

Some URL schemes do not refer to a server on the internet; the most broadly supported and commonly used of these are the data and blob schemes.

A data: schemed URL contains the entire resource to which it refers. For example, if a client fetches the URL data:text/html;base64,PGgxPkhlbGxvIHdvcmxkPC9oMT4=, the result is the string <h1>Hello world</h1>, the base-64 decoding of the substring beginning PGg and ending with4=.

A blob schemed URL refers to a resource which exists only in the memory of the JavaScript context that generated the URL via the createObjectURL() JavaScript method. JavaScript running inside a web page at https://webdbg.com/test/data.htm might generate a blob URL that looks like this:

blob:https://webdbg.com/1c179345-3c59-47bd-908d-2b2b5d198590

When fetched from JavaScript inside the originating webpage, that blob URL will return an object (anything from an image to a file download to a HTML document). However, attempting to fetch that same blob URL from any other device (or even another browser window on the same device) will not return any content, because the blob scheme is not globally routable.

Security Considerations: The FILE Scheme is Weird

The file scheme allows routing a request to a file on either the local file system or the filesystem of a remote server. A URL like file:///C:/test.html refers to a file on C: drive of the system where the fetch retrieval occurs, while file://serverhostname/docs/test.html refers to a file on the share named docs on the server named serverhostname.

Fortunately, use of the file scheme in modern browsers is somewhat restricted because retrieving file URLs can result in assorted security and privacy badness, including fingerprinting the apps on the user’s computer or leaking the user’s Windows password hash to a remote servers.

Component: Authority

The Authority component of the URL consists of three subcomponents: userinfo, the fully-qualified hostname, and the port.

Component: UserInfo

The userinfo subcomponent of a URL specifies a username and password that the client should use when authenticating to a server. This subcomponent is only defined for certain URL schemes (e.g. FTP), while it is officially invalid for others (e.g. HTTP and HTTPS) but nevertheless supported (e.g. Firefox and Chromium allow userinfo for HTTP and HTTPS URLs).

Security Considerations: UserInfo UI Spoofing

Way back in Internet Explorer 6, IE started forbidding HTTP/HTTPS URLs containing userinfo because this obscure subcomponent’s primary real-world use was to confuse the user as a part of phishing attacks. Because the UserInfo is typically not present in URLs, a user looking at the URL https://victim.com:80@random.text.evil.com/ will often assume that they are looking at content from victim.com rather than from random.text.evil.com.

This threat vector is not terribly common today: Chromium hides the UserInfo component in its address bar, while Firefox explicitly warns the user about this threat:

I wrote more about the UserInfo spoofing vector back in 2023.

Component: Fully-qualified hostname

The most security-relevant part of a URL is the fully-qualified hostname of the URL. The hostname is registered by an individual or business (e.g. PayPal, Inc. owns Paypal.com) with the relevant DNS registrar of the top-Level domain (e.g. Verisign controls the .com top-level domain).

Security Considerations: Transport Security

If the URL’s scheme is secure (e.g. HTTPS), content delivered from a given hostname is deemed to be under the control of the entity that registered the hostname (modulo compromised infrastructure, etc). However, if the scheme refers to a non-secure protocol like HTTP, and especially if the protocol traverses an untrusted network, the registrable domain information may not accurately describe the true source of the content because the content may have been modified by a man-in-the-middle on the network. The port number only needs to be specified if it is not the default for the scheme (e.g., 80 for HTTP, 443 for HTTPS).

Security Considerations: Parsing of IPv6 Literals

When the URL’s hostname is an IPv6 literal, the address is wrapped in square brackets, e.g. http://[::1]:8080/file.html is a reference to a file hosted on port 8080 of the current device’s IPv6 loopback interface. The fact that a colon character can appear before the colon delimiter representing the start of the Authority’s Port subcomponent can confuse a parser unfamiliar with IPv6 addresses.

While there’s no standard for including an IPv6 scope id within a URL, WinINET allows specification of the scope by %-encoding the % delimiter character, e.g. https://[::1%253]/

Security Considerations: Interpretation of IPv4 Literals non-canonical syntax

Most technically savvy users are familiar with IPv4 literal addresses in dotted decimal format, like http://127.0.0.2/. However, dotted decimal is not the only format; you can also express the same address by dropping the 0. components, like http://127.2, with extra 0s like http://127.000000002/, or in decimal notation http://2130706434/, octal notation http://0177.0.0.2/, or hexadecimal notation http://0x7f000002/.

The various serializations of addresses could be used to evade matching logic. Historically, we’ve also seen some code that assumes that any hostname lacking a dot must not be globally routable and belongs to the (more trustworthy) Intranet zone (leading to an MSRC case for Windows/IE in the early 2000s).

Security Considerations: IDN and PunyCode

Support for non-Unicode characters in URLs can lead to spoofing attacks.

https://chromium.googlesource.com/chromium/src/+/main/docs/idn.md

Security Considerations: eTLD+1

Usually, the security context that the user cares about is the registrable domain of the top-level page’s URL’s origin, even when a given page is made up of components from many different origins. The registrable domain typically consists of a subdomain of an entry on the Public Suffix list. For instance, bbc.co.uk is a registrable domain under the co.uk public suffix. The fully-qualified hostname consists of a registrable domain, and optionally one or more subdomain labels.

See https://publicsuffix.org/ for more discussion.

Component: Port

The port component of the URL indicates which TCP/IP port should be contacted to send the request.

Security Considerations: Shared Servers and “Well-Known” Ports

In general, a server operator is deemed to be in control of all ports on the server, although notably some systems (e.g. Unix) allow low-permissioned users to perform TCP/IP listen operations only on certain ports (>1024) while requiring administrative permissions to listen to “low ports” (<1024) which are the default ports used by popular services (HTTP/HTTPS/FTP).

Security Considerations: Canonicalization Drops Default Port

When canonicalizing a URL, if the specified target port is the default port for the scheme, it should be removed from the URL entirely. For example,

Input URL	Canonical URL
http://example.com:80/	http://example.com/
https://example.com:443/	https://example.com/
ftp://example.com:21/	ftp://example.com/
https://example.com:4567/	https://example.com:4567/

Meta-Concept: Origin

The Web Platform security model uses a term called “Origin” which is comprised of the triplet scheme+fullyQualifiedHostname+port.

Challenges and Threats

Malicious websites are motivated to misrepresent their provenance in order to trick visitors into performing an unsafe action (e.g., phishing, malware install) or to otherwise grant unwarranted trust in the information provided by the site (e.g., “fake news”).

Other components of the URL (subdomain, userinfo, path, query, and fragment) are completely under the control of the website and may be crafted in an attempt to spoof the user by misrepresenting the registrable domain.

URL Comparison

A critical thing security software needs is a consistent function that turns “a pile of octets that some client is treating as a URL” into “a string that the security software considers to be the canonical / common form that we will use in all subsequent matching logic, even if that string would not be accepted by a real server.”

That function will need to handle things like bare-ACP octets appearing anywhere in the string, invalid UTF-16 sequences, raw (non-encoded) UTF-16 codepoints, and anything else we devise.

Canonicalization and Normalization

We’ll also need comparison functions that work correctly both with and without the most common forms of canonicalization/normalization performed by servers (e.g. https://example.com/blah/..///thisisafile.htm matches https://example.com/thisisafile.htm. Similarly, there are many ways to represent equivalent IPv6 literals, and so on.

Matching and “Rollups”

Beyond that, the software needs to decide how closely two URLs must match to be considered equivalent.

For example, http://example.com/PaTH and http://example.com/path are technically different URLs, but in actual practice, they will return the same content on from most servers.

While the port component in the URL is technically a part of the web origin, in actual practice, it is very uncommon for an arbitrary port to be controlled by a different entity than the default port, and there’s no evidence to suggest that any human being will make a different security decision based on the target port number. As such, security software will often ignore the port when comparing URLs. In Microsoft SmartScreen, for example, a rule set to block https://x.com (implicitly port 443 due to the HTTPS scheme) will also block requests to http://x.com:12345.

Any URL matching function needs to decide how closely two URLs must match; in SmartScreen, we call this roll-up, meaning “Will a block for X.com block X.com/something? What about sub.x.com/anything?” We call these “path rollup” and “domain rollup”, respectively.

Challenge: Supporting URL “Scrubbing”

URLs often contain sensitive information, ranging from PII to document titles, to security nonces that are intended to be available only for a single client computer. In an attempt to limit the privacy impact of URL transmission/telemetry, software may attempt to “scrub” the URL, replacing private data with a replacement character (e.g. https://phone.com/425-830-6600/call is masked as https://phone.com/XXX-XXX-XXXX/call).

Because scrubbing logic is, at best, based on imprecise heuristics, it is subject to false negatives (sensitive values not masked) and false positives (PII-looking values that are e.g. actually just meaningless numbers formatted as if they were telephone numbers).

Any attempt at scrubbing creates a mechanism by which an attacker can easily interfere with URL matching logic. The attacker can “cloak” their endpoint such that it responds only with innocuous content when a “PII-looking” value is omitted from the request URL (e.g. by a server-side detonator that is using a scrubbed URL).

Any attempt at using scrubbed values in threat intel feeds creates problems if the components creating and consuming the feed do not recognize how sensitive data is masked within that data, potentially leading to URL matching ambiguities.

Challenge: Inconsistent Length Limitations

URLs do not have a consistent length limit. Chromium limits URLs to 2MB for navigation (and 32kb for display, in some contexts), while various components of Windows use 2083 characters, and some servers and security software have URL length limits that are longer and shorter.

Some security software imposes a lower limit on URL length, returning error pages if the URL length exceeds their limit (e.g. 4096 characters):

The fediverse was right · Ata Kuyumcu's Blog

Sun, 19 Jul 2026 14:16:11 +0000

I use Mastodon on and off but I would not trade it for any alternative atm. Not because it’s better than Twitter was, the discoverability is worse, the reply threading is too complex at times, and it does have sync issues across instances. What it does have is something no corporate platform will ever offer: you can leave and take your social graph with you. Your followers, your follows, your block lists. Pack them up, point your domain at a different server, done.

That’s not a selling-point, it’s the absence of a lock-in mechanism. And it only works because ActivityPub is a real protocol that people actually implement.

We’re about to see a lot more of this.

Protocols that ship

ActivityPub shipped. That’s the part people gloss over. The fediverse has millions of users across thousands of instances. It’s not a whitepaper. It’s not a “we’re exploring decentralized architectures” blog post from a company that’ll pivot to AI next quarter. People use it every day, and they use it to talk to people on completely different servers running completely different software. Mastodon talking to Pleroma talking to Pixelfed talking to PeerTube. Same protocol, different UIs, different moderation policies, different vibes.

The protocol layer is the part that matters. Implementations come and go. Mastodon might fade. Something better will replace it. But ActivityPub will still be there, and the network effects built on top of it won’t evaporate the way they do when a single company burns out.

Email works the same way. Nobody owns email. You can run your own mail server (people do, I’ve done it, it’s a pain but it works) and you can send mail to anyone on any provider. The protocol is the platform. Everything else is just a client.

What’s missing

Git forges. That’s the obvious one.

GitHub has been the default for so long that we forget it doesn’t have to be. Git itself is decentralized. Every clone is a full copy of the repository. But issues, pull requests, code review, CI configuration, releases, wiki pages. None of that is in the repo. It’s in GitHub’s database. When GitHub goes down, your code is fine but your workflow is gone. When GitHub makes a decision you hate, you can move your repos but you can’t move your issues. The community is stuck to the platform.

ForgeFed is an attempt to fix this. It’s an ActivityPub extension that defines vocabulary for repositories, commits, patches, issues, merge requests. The idea is that your forge, wherever it’s hosted, can interact with any other forge that speaks ForgeFed. You open an issue against a repo on someone else’s server without creating an account there. You submit a patch from your self-hosted Gitea instance to a project on a friend’s Forgejo instance. Same protocol, different UIs, same as the fediverse already does for social media.

It’s early. Vervis is the reference implementation, mostly a testbed for the protocol. Forgejo is working on federation support, but the discussion about enabling it on Codeberg gives you a sense of where things actually stand: the features are real enough that Codeberg’s team is planning the rollout, but they’re also worried about scaling surprises, DDoS amplification, and moderation gaps. The largest Forgejo instance in the world can’t just flip a switch and see what happens. Pagure had a plugin that’s unmaintained now. Nobody would call this production-ready. But the direction is right, and the pieces exist.

Why now

AI makes protocols cheap again.

Here’s what I mean. Writing a protocol is not the expensive part. An RFC is a text file. The expensive part is iterating on it. You write a spec, someone implements it, they find ambiguities, you revise the spec, someone else implements the revision, they interpret it differently, you add clarifications, and on and on. Each cycle costs developer time. The longer the cycles, the slower the protocol converges. And the slower it converges, the less likely anyone is to bet on it.

AI changes the economics of this. If an LLM can draft a reference implementation in an afternoon, you can test a protocol revision against real code the same day you write the spec change. You can have multiple implementations in different languages from the same spec, each revealing different assumptions. You can generate compliance tests, edge case tests, interop tests. The feedback loop shrinks from months to hours.

This doesn’t replace the human work of protocol design. Trade-offs still need judgment. But it removes the biggest bottleneck: the gap between “here’s the spec” and “here’s code that proves it works.”

Beyond protocols: UX contracts

There’s a further step I keep thinking about. Protocols define data formats and message flows. They don’t define what the user sees. Two ActivityPub implementations can have wildly different UIs, and they do, and that’s fine for power users who know what they’re signing up for. But for federation to reach people who don’t want to think about protocols, you need something more.

Call it a UX contract. Not a wireframe spec, not a design system. Something lighter. A set of guarantees about what the user can expect. If you open a merge request on a federated forge, the interface for reviewing it should be recognizable. The terminology should be consistent. The notification flow should feel familiar. Not identical. Just not alien.

This is harder than a protocol spec. UX is squishy. But AI makes squishy things cheaper too. You can generate UI scaffolding from a UX contract the same way you generate network code from a protocol spec. You can test whether different implementations feel coherent to a user. You can iterate on the contract without waiting for a design team to hand off mockups to an engineering team.

I don’t think we’re there yet. But the path is visible. Protocols define what the machines say to each other. UX contracts define what the humans expect to see. Both need to be cheap to iterate on, and both are getting cheaper.

The bet

Centralized platforms win on convenience. Self-hosting wins on control. Federation splits the difference: you get control over your own data and your own instance, but you’re not isolated. You’re still in the network.

The fediverse proved this works for social media. It’s not perfect. Moderation at scale is unsolved, instance discovery is clumsy, the UX is uneven. But it works, and it’s growing, and nobody can shut it down.

Git forges are next. ForgeFed might not be the thing. Something else might emerge. But the pattern is set. Protocols over platforms. Federation over centralization. And with AI making the iteration loop tighter, we’re going to see protocols ship faster than they ever have before.

I want my code, my issues, my review history, and my community to outlast whatever forge I’m using. Same way my email outlasts whatever client I’m using. Same way my social graph outlasts whatever Mastodon instance I’m on. The protocol is the platform. Everything else is just a client.

wp2shell: Pre Authentication RCE in WordPress Core

Sun, 19 Jul 2026 04:21:14 +0000

wp2shell

Pre Authentication RCE in WordPress Core

Searchlight Cyber's security research team has discovered a pre-authentication RCE in WordPress Core. The attack has no preconditions and can be exploited by an anonymous user in a stock install of WordPress with no plugins.

It is estimated that over 500 million websites use WordPress. Given the severity of the bug and to give defenders time to patch, we are not releasing technical details at this time. We are, however, releasing a checker so you can determine whether your instance is vulnerable. Check your site directly below.

Versions Affected

`< 6.9.0`	not affected
`6.9.0 - 6.9.4`	affected, fixed in 6.9.5
`7.0.0 - 7.0.1`	affected, fixed in 7.0.2

Mitigation

The best way to protect yourself is to update WordPress immediately. WordPress 7.0.2 contains the fix (or 6.9.5 if you are on the 6.9 branch). Until you can update, there are multiple mitigation options:

Install the plugin Disable WP REST API to disable unauthenticated users from using the WordPress API. This is the easiest option but does have a possible low risk of breaking existing functionality.
Use a WAF to block the path /wp-json/batch/v1 and the query parameter rest_route=/batch/v1 (both of these patterns must be blocked to secure your instance).

Drop the following custom plugin into wp-content/plugins/disable-batch-api-for-unauth.php on the filesystem for your WordPress instance via SSH or FTP and enable it from Plugins in the admin panel:

<?php
/**
 * Plugin Name: Disable Unauthenticated REST Batch API
 * Description: Requires an authenticated WordPress user for REST batch requests.
 * Version: 1.0.0
 * Requires at least: 5.6
 * License: GPL-2.0-or-later
 */

defined( 'ABSPATH' ) || exit;

/**
 * Reject anonymous requests to the core REST batch endpoint.
 *
 * @param mixed           $result  Pre-calculated dispatch result.
 * @param WP_REST_Server  $server  REST server instance.
 * @param WP_REST_Request $request Current REST request.
 * @return mixed|WP_Error
 */
function wporg_require_authentication_for_rest_batch( $result, $server, $request ) {
    if ( '/batch/v1' !== strtolower( untrailingslashit( $request->get_route() ) ) || is_user_logged_in() ) {
        return $result;
    }

    return new WP_Error(
        'rest_batch_authentication_required',
        'Authentication is required to use the batch API.',
        array( 'status' => 401 )
    );
}

add_filter( 'rest_pre_dispatch', 'wporg_require_authentication_for_rest_batch', -1000, 3 );

Note that these solutions may have impact on legitimate use of the site and should only be considered emergency temporary measures until you can update.

Credits

Discovered and authored by Adam Kues of Searchlight Cyber.

Hardcore IndieWeb: Run your own website 100% independently for only $0.01/day

Sun, 19 Jul 2026 04:21:14 +0000

Hardcore IndieWeb: Run your own website 100% independently for only $0.01/day

Adam Newbold
July 18, 2026

If you’re not familiar with the IndieWeb movement, it’s a practical approach to maintaining your presence on the web that emphasizes fully owning your identity and your content. This is especially relevant now, at a time when a growing number of corporations want to own and control those things for you. The IndieWeb ethos seeks to eliminate external influence and control over both you and your stuff.

And as with any movement, there are a bunch of different services out there aiming to help you plug into this modern independent web. I even run one myself! But I always place my values over profit, so I don’t have any problem sharing the simple truth that you don’t need a fancy subscription blogging service to join the IndieWeb. In fact, when you use one of those services, you’re actually taking a step back from real independence, because your content often winds up living in someone else’s database on someone else’s server. They’ll tell you that’s OK because you can always export it whenever you’d like, in open formats, and of course that’s nice. But you still don’t fully fully own and control your content when you’re dependent on someone else’s service.

There’s nothing wrong with using those services, to be clear. And if you’re already using them and happy with them, that’s great! This guide isn’t for you. But if the idea of having complete independence and control over your content on the web is appealing to you, read on. Because that’s what Hardcore IndieWeb is all about.

Defining Hardcore IndieWeb

Hardcore IndieWeb fully embraces existing IndieWeb principles; there’s really nothing new or different there. The key aspects of Hardcore IndieWeb are control over your content and portability of your website:

If your content doesn’t primarily exist on your own hard drive, you don’t fully control your content.
If you don’t have a copy of your published HTML and web assets on your own hard drive, it’s not truly portable.

Why does this matter? Consider what happens if the IndieWeb blogging service you’re using goes belly-up one day. Your ability to move to a new service depends entirely on your ability to export your data. What if you can’t export it? The service provider may have told you that you own your content, but what good does that do if you can’t access it?

From a portability standpoint, consider what happens if you discover that the owner of your IndieWeb blogging service has been outed as engaging in abhorrent behavior or just comes down with a major case of the ick (this has happened before!). Sure, you can export your data in an open format and move house. But now you have to find another service that can work with that format, or convert everything and adopt an entirely new set of tools or processes. And you have to move house, which is a major pain.

If you follow Hardcore IndieWeb, neither of these situations can affect you. Your content remains completely under your own control at all times, and your website exists in a fully published format at all times. The independence is tangible, and you can benefit from it whenever necessary.

The methodology

In many ways—no, actually, in every way—Hardcore IndieWeb mirrors the very same web publishing practices that were used in the 90s when the web was brand new. These were things that I did back then myself, every day, and they worked great! And they still work today, of course, but few people would recognize the approach because we’re now multiple levels deep in hybrid SaaS CMS/SSG solutions tethered to half a dozen markup languages and twice as many template systems. We’re living in a messy and complex web right now, but it doesn’t have to be that way. The complexity is one choice, and the simplicity of Hardcore IndieWeb is a different choice.

The process looks like this:

Author your web content on your hard drive.
Preview it in your web browser.
When you’re happy with what you have, upload it to your web host. Repeat as often as you’d like.

That’s it. It really is that simple. Besides a domain name, here’s what you’ll need:

A text editor
A file transfer tool
A web host

Again, that’s all. You don’t need any other special software. No programming environments or IDEs, no frameworks or shells or CLI tools. And definitely no monthly subscriptions. In the next section, I’ll cover choosing these items, and I’ll suggest a very nice web host that literally only costs $0.01/day, which you can pay-as-you-go (so no subscription).

(You do also need to know some HTML, but everyone can learn HTML. And in reality, you can get away with only knowing a few tags and largely copying and pasting, so don’t sweat it!)

Getting Started

First, you’ll need to find a text editor that you like. Hopefully you already have one, but if not, you can try different editors until you find one that works for you. (I use Nova by Panic, myself.) You can use virtually any editor, because it only needs to support saving files to your disk (and they all do that).

Then, you’ll need a way to transfer files. Part of the reason I use Nova as my editor is that it handles file transfers, too. But there are plenty of options out there. FileZilla is a nice cross-platform app. You can use anything that can transfer files over SSH (or the SFTP protocol).

Finally, you’ll need a place to host your web content. There are a zillion web hosts out there, all with various features and benefits. But for Hardcore IndieWeb, you only need the basics, and you don’t need to spend a lot of money at all. For just $0.01/day, you can run a static website at NearlyFreeSpeech.net, and that’s what I recommend. I’ve had an active account with them since 2008 and they’re awesome!

You can use any web host you’d like, though. If you want to use NearlyFreeSpeech, go ahead and sign up, fund your account (you can kick things off with as little as $0.25), add a site (static, non-production), and you’re good to go. You’ll find your site’s login information (for file transfers) on the Sites tab after clicking on your site name. You’ll get a free subdomain to work with, but you can add your own personal domain on the Domains tab if you’d like (and you should totally do that).

The Process

Once you have your editor, a way to transfer files, and an active account with a web host, you’re ready to get going. At this point, the world is your oyster. You can run any kind of website you’d like, but for this guide, we’ll assume you want to run a blog.

Most of the time, a blog consists of these things:

A landing page
Posts/articles
An archive page
A feed

If you’ve always assumed that you need a special blogging service or software to maintain these items, that’s totally understandable. But you don’t! You can actually manage these yourself, and it’s really super easy. At this point you might (understandably) be wondering “what kind of person manages their own RSS feed in a text editor?” And the answer is you. You are the kind of person who is totally capable of managing your own RSS feed in your own editor.

We’ll cover that shortly. First, let’s cover the HTML pages.

A Quick Note About Web Pages

If you already have your existing web site or blog in HTML format, you’re in a great position to get started with Hardcore IndieWeb. If you don’t, that’s OK. Depending on where your blog lives today, there are likely ways to export it in HTML or to convert it into HTML. If your blog is huge, you’ll probably want to use a tool to make this easier. If it’s small, maybe you’d enjoy diving into creating your new HTML files yourself (which is always a fun way to revisit your posts and such).

If you don’t know much HTML, you can totally learn it. Heck, I’ll even teach you if you’d like. It’s super fun to learn, and using HTML brings you so much closer to your web content in ways that modern tools just don’t capture. Markdown may be many people’s preferred way to author content, but HTML is the language of the web, and I can personally attest to the fact that there are plenty of occasions where doing something in plain HTML turned out to be far easier than fighting a Markdown parser.

Anyway. If you want to jump in with some ready-made web material to use as a basis for your site, there are a bajillion free web designs and templates out there. Here’s one I just found. You can download something you like, open it in your text editor, and make it your very own.

Landing Page

Your landing page is your home on the web, and you can do whatever you’d like with it. It can show your latest blog post, or several of them, or none of them at all. It can show entire posts or just the first couple of sentences. You’re in complete control here, and you can put whatever you want on that page. If you want to display your latest blog post, just copy and paste it there and add a link to its standalone page. If you want to show your five most recent posts, paste the new one at the top and delete the oldest one at the bottom. You’re now working directly with your content on your own landing page, and you can do whatever you’d like, however you’d like.

This might sound like madness, if you’re fully accustomed to today’s modern template-driven systems for managing blogs and web content. And that’s a totally fair way to feel about it. But consider that this approach offers some unique possibilities that are actually harder to do with template-driven solutions. With this approach, you’re in a position to deviate from the norm. You can take things in different directions. You can apply your creativity in fun and interesting ways, and you’ll never find yourself fighting your CMS/SSG/templating engine/etc. because you’re not using one. It is utterly freeing.

Your landing page should be called index.html and should sit in the root level of your web root (which is /home/public if you’re using NearlyFreeSpeech).

Blog Posts

Blog posts are just web pages. These are super easy to maintain and publish. You can run with any process you’d like, but the simplest approach is to just make a copy of the web page for your last blog post, give it a unique file name, and then edit it with your new blog post content.

This is a good time to think about your site structure and how you want to organize your files. The URLs to your posts will reflect the file structure on the disk. Do you want all of your blog posts to be in a /blog/ section? Then make a blog folder in your web root and store your blog files there. You can name your posts with the desired slug, e.g. the-best-lunch-i-ever-had.html, or you could make folders for them and store the blog posts inside each folder as an index.html file to hide the .html file extension (but contrary to popular belief, it’s a beautiful and honest file extension).

This is also a good time to consider another benefit of Hardcore IndieWeb. When your posts are individual HTML files (not Markdown files or database entries), they can finally be seen as the individual web pages that they truly are. And that means that you can really lean into making all of your posts unique! They don’t all have to be cookie-cutter paper-doll clones of one another; that’s just a bi-product of modern web publishing tools and the cultural influence that they have on our concept of a “blog”. You can now go ahead and make every blog post as special and individual as you’d like. Each post can have its own personality, baked right into its HTML. Individual style, individual appearance, even individual layout. Literally everything is possible with this approach.

Archive Page

Managing your archive page is simple. Make a folder called archive (or whatever you’d like to call it), add an index.html page there, and list your blog posts on the page. You can organize them in any way you wish. You can highlight your favorite posts at the top of the page. You can do anything—it’s your archive page to manage as you please.

Feed

An RSS feed isn’t some magical esoteric web code thing; it’s just a file on disk. And it’s a file that is in a fairly simple format to parse and work with, and you can totally do that in your text editor. It’s really not difficult.

You can get started with a simple Atom feed (100% RSS-compatible and universally supported) by visiting the Atom feed page on Wikipedia, copying the example feed shown halfway down the page, and pasting that into a feed.xml file (or whatever you want to call it). Then just change all of the example.com references and <title>, <subtitle>, etc. values to reflect your own domain and information. Finally, just include an <entry> section for each post that you want to include in your feed. Set the relevant data within each (dates/times, title, summary, etc.). For the <id>, just grab a fresh UUID. And when you’re finished, copy and paste your feed into the W3C Feed Validation Service to make sure that it can be parsed. If there are any issues, the validator will tell you what needs to be corrected.

Uploading

This is the easiest part! When you’re ready to publish your website, just use your file transfer program to connect to the server and drag your files into the remote server. The first time you publish to your web host, you’ll want to copy everything over. But on subsequent uploads, you can just transfer anything that’s new or changed (e.g. your landing page, new blog post, feed, and archive page).

Next Steps

At this point, you have a fully functioning website that lives primarily on your own computer and is completely portable. This is the Hardcore IndieWeb way. You’re ready for anything: if your host vanished, you can just use another host and upload your website there. You don’t have to worry about critical security vulnerabilities in blogging software or SSG dependencies or anything like that. You are in complete control over every aspect of your web content, and you’re reliant upon no one else.

Where do you go from here? That’s up to you. You don’t have to go anywhere at all. You can follow this exact process forever and you’ll always have a wonderful website that is entirely your own and completely independent.

You could also choose to explore additional tools and processes to support your own workflow. Keep in mind that everything you add creates a dependency on something else, but as long as your content continues to live primarily on your own device and you have a full copy of your ready-to-publish website, you’re A-OK as far as Hardcore IndieWeb goes.

Conclusion

“Did I just read 2,500 words that tell me to write my own HTML and upload it to a web server?” Yeah. You did.

If this seems like ridiculous advice in 2026, I think that’s largely the result of how we’ve strayed so far from the original simplicity we had when working with the web. The layers of technical complexity introduced over the past 30 years, the new additive processes, and the expectations that come with it all combine into a modern approach that turns over more of our control and independence to other people than at any other point in the web’s history. Even under the “IndieWeb” umbrella, so many people have their only copy of their entire web presence entrusted to some guy on the internet who’s promised to take care of it. That’s not real independence, and we should stop pretending that it is.

Hardcore IndieWeb may not be for everyone. But if you care about your words, who holds them, and where and how they appear online, then you might just find that it’s for you. And if while embracing this particular approach you happen to reconnect with the web in a way that so many of us enjoyed early on, experiencing the magic and delight of working directly with HTML and copying files to your own space on a web host, then that’s a heck of an added bonus. Hardcore IndieWeb may sound intense, but the reality is that it’s empowering, fun, and rewarding. And you deserve that.

Need help with any of this? Or just want to join a super nice community of web enthusiasts?

Consider joining omg.lol! You’ll feel right at home with our active community of folks who would love to chat about (or even help with) any aspect of Hardcore IndieWeb.

Using AI To Build A Website: Security & HIPAA Risks

Sat, 18 Jul 2026 08:23:39 +0000

Using AI to Build a Website Can Create More Than Design Problems

AI website builders are popular because they remove friction. You can describe what you want in plain language, choose a design direction, adjust a few sections, connect a custom domain, and launch a complete website without coding experience.

For a simple personal site, that may be enough. For your healthcare or behavioral health organization, the stakes are higher. Your website needs to support trust, protect user data, guide people to the right next step, perform well in search engines, and connect cleanly with your intake and marketing systems.

That is where AI-generated sites often fall short. Many AI powered website builders focus on speed and convenience. What they do not always provide is production-ready code, secure form architecture, HIPAA-aware workflows, clean WordPress compatibility, or long-term technical ownership.

The Hidden Costs of Using AI to Build a Website

The hidden costs of an AI generated website usually appear after launch. At first, your site may look modern, mobile friendly, and easy to use. Then your team starts editing pages, adding plugins, improving SEO, installing tracking, or changing forms.

That is when the problems surface.

Common long-term risks include:

Technical debt that slows the site down
Platform conflicts that make updates difficult
Security risks tied to forms and user input
Maintenance costs that erase the upfront savings
Limited scalability as your organization grows

A free AI website builder or basic plan may seem cost-effective in the beginning. But if your site later needs a rebuild, security cleanup, SEO repair, or custom development, the real cost can become much higher than expected.

Code Quality and AI-Generated Technical Debt

AI tools can generate functional snippets quickly, but functional does not always mean clean, efficient, or maintainable.

A skilled developer considers your design system, page templates, integrations, performance goals, tracking needs, and future updates. An AI builder reacts to prompts. It may create something that works in the moment without understanding how that code will affect your entire website later.

Bloated Code Can Slow Performance and Hurt Core Web Vitals

AI generated code often uses more code than necessary. It may load full libraries for small effects, duplicate functions, add excessive wrappers, or create messy CSS that becomes harder to manage over time.

That can lead to slower load times, poor Core Web Vitals, higher hosting resource usage, weaker SEO performance, and more difficult technical audits.

For your treatment center website, speed is not just a technical concern. A slow website can reduce trust and increase the chance that a high-intent visitor leaves before calling, submitting a form, or reading about your services. Google Search Central’s Core Web Vitals guidance explains that these metrics measure real-world user experience for loading performance, interactivity, and visual stability.

AI-Generated Snippets Often Lack Architectural Planning

AI can create a section, form, animation, or landing page. What it often lacks is a clear architectural strategy.

That can create inconsistent naming, repeated code, mixed design patterns, poor separation between content and functionality, and pages that are difficult to scale or hand off.

This becomes especially risky when your site needs location pages, program pages, service hubs, blog templates, campaign landing pages, or intake-related workflows.

Cookie-Cutter Layouts Can Weaken Trust

Many website builders and AI website generators rely on similar template structures. Even when the colors, images, and copy are different, the final site can still feel generic.

That matters in behavioral health. Your visitors may be comparing treatment options during an emotional, high-stakes moment. If your site looks like every other AI built website, it may not communicate the trust, clinical seriousness, or brand differentiation your organization needs.

Professional Website Essentials for New Businesses

Sat, 18 Jul 2026 02:03:05 +0000

Finance

Mobile App Design: What Makes an App Easy to Use and Worth Keeping

A new mobile app usually gets one honest shot....

Why Serious Web3 Development Starts With Saying “No”

Most enterprise blockchain pilots end up going nowhere. Teams...

Top Crypto Market Making Services for Exchanges and Token Projects

Liquidity is one of the most important factors in...

Why Growing Businesses Eventually Need a Digital Marketing Agency

Most small businesses start out handling marketing themselves, and...

BeeReaders Review: Features, Pros, Cons, and Alternatives

If you are researching a BeeReaders review, you are...

Marketing

Mobile App Design: What Makes an App Easy to Use and Worth Keeping

A new mobile app usually gets one honest shot....

Why Serious Web3 Development Starts With Saying “No”

Most enterprise blockchain pilots end up going nowhere. Teams...

Top Crypto Market Making Services for Exchanges and Token Projects

Liquidity is one of the most important factors in...

Why Growing Businesses Eventually Need a Digital Marketing Agency

Most small businesses start out handling marketing themselves, and...

BeeReaders Review: Features, Pros, Cons, and Alternatives

If you are researching a BeeReaders review, you are...

Politics

Mobile App Design: What Makes an App Easy to Use and Worth Keeping

A new mobile app usually gets one honest shot....

Why Serious Web3 Development Starts With Saying “No”

Most enterprise blockchain pilots end up going nowhere. Teams...

Top Crypto Market Making Services for Exchanges and Token Projects

Liquidity is one of the most important factors in...

Why Growing Businesses Eventually Need a Digital Marketing Agency

Most small businesses start out handling marketing themselves, and...

BeeReaders Review: Features, Pros, Cons, and Alternatives

If you are researching a BeeReaders review, you are...

Strategy

Mobile App Design: What Makes an App Easy to Use and Worth Keeping

A new mobile app usually gets one honest shot....

Why Serious Web3 Development Starts With Saying “No”

Most enterprise blockchain pilots end up going nowhere. Teams...

Top Crypto Market Making Services for Exchanges and Token Projects

Liquidity is one of the most important factors in...

Why Growing Businesses Eventually Need a Digital Marketing Agency

Most small businesses start out handling marketing themselves, and...

BeeReaders Review: Features, Pros, Cons, and Alternatives

If you are researching a BeeReaders review, you are...

15 Features Of The Best Plumbing Websites With Examples

Thu, 16 Jul 2026 06:29:59 +0000

What Defines The Best Plumbing Websites?

Your plumbing company website represents your business to residential and commercial clients alike. The most effective web design can set your plumbing apart from others.

Ask yourself these questions:

How can my website help me stand out from other plumbers near me?
How can I get my website to show up when people search for plumbers?
Is my website built to actually bring in more leads and customers for my plumbing business?

In this article, Valve+Meter Performance Marketing explores 15 key features every plumbing company’s website needs. Our plumbing website design and development team explains why each feature can make an impact in answering each of these questions. Packed with examples from some of the best plumbing websites from across the country, you can find inspiration and a plan to make your plumbing website stand out and maximize performance.

15 Key Features of the Best Plumbing Websites:

A successful plumbing website combines aesthetics with functionality, offering a seamless user experience while effectively showcasing the company’s services and expertise. It’s a platform that not only attracts potential customers but also converts them into loyal clients.

Professional Design
Mobile-Friendly
Fast Loading Speed
Clear Contact Information
Online Booking or Quote Requests
Services Offered
About Us Page
Social Proof
FAQ Section
Blog or Resources Section
Clear Call-to-Action (CTA)
SEO Optimization
Social Media Integration
Localized Content
Easy Navigation

Professional Plumbing Website Design: Reflecting Brand Identity

The significance of a clean, modern design in a plumbing website cannot be overstated. It’s the first thing visitors notice, and it sets the tone for their entire experience.

How does your website compare to all the plumbing companies in your service area?

A professional design reflects the brand’s identity, showcasing your values and brand personality. Your plumbing website content has the ability to make a connection with your target audience that is instantly memorable.

90%of the information transmitted to our brains is visual.

Website design is not just about looking good; it’s about creating an environment where visitors feel comfortable and confident in the plumbing services offered.

A well-designed site conveys reliability and expertise, essential qualities for any plumbing business. It tells potential customers that the company pays attention to detail and is committed to providing a positive experience, both online and offline.

In a competitive market, a standout design can be the deciding factor that turns a website visitor into a loyal customer.

Professional Website Design Example: Ravinia Plumbing

Ravinia Plumbing, Sewer, Heating, & Electrical Services has a clean and modern design that showcases their brand logo clearly. Plumbing businesses often offer a range of services including residential plumbing and commercial plumbing services.

An expert plumbing website designer understands how to keep visitors’ attention on next steps with prominent calls to action.

Other key design features to build brand identity include:

Consistent use of brand colors, logo, and typography.
Detailed “About Us” page highlighting company story, values, and mission.
High-quality, professional imagery and videos.
Clear, concise messaging that communicates unique selling points.
Customer testimonials and reviews to build trust and credibility.
Easy-to-navigate menu that reflects brand’s priorities.
Blog or resource section showcasing expertise and industry knowledge.
Contact information and social media links for easy communication.

Mobile-Friendly: Catering to All Devices

When a plumbing emergency happens day or night, prospective customers grab the first thing at hand. It is literally a smartphone for residential and commercial customers.

The importance of a responsive plumbing website design cannot be overstated.

The best plumbing website design creates an optimal user experience for smartphones, tablets, and desktop devices.

A mobile-friendly website ensures you stay competitive against other plumbing companies. When visitors can find all your plumbing services, they’re more likely to engage with your website and convert into plumbing leads.

Furthermore, mobile-friendly plumbing websites impact SEO significantly. Websites optimized for mobile devices rank higher in search engine results, making them more visible to potential customers.

Plumber websites must offer a smooth mobile experience that keeps users engaged, reducing bounce rates and increasing the likelihood of converting visitors into customers.

###

Mobile-Friendly Plumbing Website: Bay Water Plumbing

Bay Water Plumbing incorporates a seamless experience across all devices. This plumbing website responds to the user’s device with a prominent phone number at the top of the page for website visitors ready to call now.

Additional features of responsive plumber websites include:

Fast loading times to reduce bounce rates.
Easy-to-use navigation for touchscreens.
Click-to-call buttons for immediate contact.
Simplified forms for easy submission on mobile devices.
Readable font sizes and clear text spacing.
Compressed images for quicker loading on mobile networks.
Accessible menus and dropdowns for seamless navigation.
Focused on content for quick access to essential information.

Fast Loading Speed: Keeping Visitors Engaged

When people need emergency services, they won’t wait for a slow response.

Slow websites are likely the hold music of the digital age.

Slow-loading websites test the patience of users, who’re likely to leave if a page takes too long to load. This not only affects user satisfaction but also harms the website’s search engine ranking, as speed is a key factor in SEO algorithms.

Web developers who understand performance first build the best plumbing websites. Your plumbing company can look great online without sacrificing website speed.

Compressing images, leveraging browser caching, and minimizing the use of heavy scripts and plugins can help your plumbing company website delight users and earn more plumbing leads.

Fast Loading Speed Example: Superior Plumbing

Superior Plumbing earns an incredible 96/100 according to the Lighthouse Metrics. This plumber website eliminates features that slow the website without sacrificing quality design. The phone number is prominent, text matches branding, and the plumbing slogan is on clear display: “Plumbing Repairs + Honest Answers.”

Additional ways to improve the speed and performance of a plumbing website:

Compress and optimize images to reduce file sizes.
Minimize heavy graphics and animation use.
Enable browser caching to reduce load times for repeat visitors.
Minimize the use of plugins and external scripts.
Optimize CSS and JavaScript files by minifying and combining them.
Choose a reliable and fast web hosting service.
Set up lazy loading for images and videos.
Reduce the number of HTTP requests by consolidating resources.
Regularly monitor and test website speed.
Keep your website’s software and plugins up to date for optimal performance.

Clear Contact Information: Ensuring Accessibility

So your plumber website looks great and performs exceptionally across all devices. When a potential customer arrives, the best plumber websites are intuitive.

Modern plumbing websites can be packed with many service pages, videos, blogs, and even podcasts.

Don’t let marketing stand in the way of converting happy customers.

Performance-focused plumbing website design puts a clear call to action ahead of all other features. Your website’s job is to convert visitors to connect with your sales and support staff.

Visitors should be able to find phone numbers, email addresses, and physical locations without having to search extensively. This accessibility is crucial for customer convenience and can significantly impact the decision to choose your services over a competitor’s.

Best practices for displaying contact information include placing it prominently on the homepage, in the website’s header, and in a dedicated ‘Contact Us’ section.

Example Of A Great Website CTA: Penguin Air, Plumbing, Electrical

Penguin Air, Plumbing, Electrical offers one of the best plumber websites in terms of easy contact details. On the homepage of the business website, the phone and contact form leap off the page in branded colors.

Across every webpage the phone number and service schedule options are just a click away.

Contact details improve user experience and can help with search engine visibility. Here are the contact details that should be prominently displayed on a plumber website:

Phone number
Emergency service hotline (if offered)
Contact form on homepage and link in header
Business name, address, phone (NAP) in footer
Social media profiles (Facebook, Instagram, LinkedIn, etc.)
Business hours
Map or directions to the physical location (if applicable)
Links to review sites (e.g., Yelp, Google Reviews)

Online Booking or Quote Requests: Simplifying Customer Interaction

Incorporating online booking or quote requests into a plumbing website offers numerous benefits. It provides a convenient way for potential customers to schedule appointments or request pricing information without the need for phone calls or emails.

This streamlined process can lead to increased conversions and customer satisfaction and all the best plumbing websites use forms or plugins to provide plumbing leads a quick solution for plumbing services.

Example Of Online Booking: Hoffman Brothers

With an expansive range of services and locations in St. Louis and Nashville, Hoffman Brothers‘ website could become crowded and difficult to use.

Instead, they wisely offer potential customers a simple option to book online or request an estimate across the primary service pages.

The best plumbing websites feature:

Buttons for “Schedule an Appointment” or “Request a Quote” on the homepage and service pages.
User-friendly booking forms with simplified fields.
Real-time availability calendars to allow customers to select their preferred appointment slots.
Automated email or SMS confirmations and reminders to keep customers informed.
Integration with payment gateways for secure online payments or deposits, if applicable.
Option for customers to describe their plumbing issue in detail for a more accurate quote.
Estimated response time displayed on the booking page to set clear expectations for customers.
Mobile optimization to ensure the booking process is seamless on smartphones and tablets.

Services Offered: Informing Potential Customers

A detailed services page is vital for informing potential customers about what your plumbing business offers.

It should clearly outline the range of services provided, from routine maintenance to emergency repairs, and everything in between. This transparency helps visitors understand whether your company can meet their specific needs.

The best plumbing websites also design service pages for improved site navigation and SEO.

Services Page Example: O’Neill Plumbing Company

O’Neill Plumbing Company incorporates a services page that’s well-organized and easy to read. Visitors can choose between general plumbing services or navigate to underground utilities and construction services sub-pages.

Services pages can simplify websites with many services when thoughtfully designed, including:

Clear headings and descriptions for easy information access.
High-quality images and videos enhance service presentation.
Testimonials and case studies build trust and credibility.
Internal linking increases specific service pages’ visibility.
Professional design and SEO guide user and search navigation.
Organized services page improves site navigation efficiency.
Calls to action on the services page encourage engagement.
service information retains user attention, boosts rankings.

About Us Page: Building Trust and Connection

The About Us page plays a crucial role in establishing credibility for a plumbing business. It’s where you share your company’s story, values, and the team behind the services. This personal touch helps build trust and connect with potential customers on a deeper level.

Elements of a compelling About Us section include a brief history of the company, the qualifications and experience of the team, and the company’s mission and values. Including team photos and any awards or recognitions can further enhance credibility and relatability.

Example Of Great Plumbing Website About Us: Applewood FixIt

Applewood Plumbing, Heating & Electric checks all the boxes with their About Us page. With a clear value proposition at the top of the page, this may be one of the best plumbing industry websites.

There’s a clear story to be told on your about us page and Applewood FixIt nails everyone including:

Value proposition that states the ‘Why’ of your business.
Customer-focused content across the page.
Brand showcase including images of your team, vehicles, and showroom.
Industry awards and community recognition.
Code of ethics and company values.
Membership programs, warranties, referral offers, and other branded offers.

Social Proof: Enhancing Credibility

Positive feedback from past customers can significantly enhance the trustworthiness of your plumbing business.

Testimonials and reviews serve as social proof, showing potential customers that others have had satisfactory experiences with your services.

Best practices for showcasing testimonials and reviews include placing them prominently on the website, ensuring they’re genuine and up-to-date, and including the reviewer’s name and location for added authenticity.

You can also link to third-party review sites like Yelp or Google My Business for more feedback.

Social Proof Example: Pink Plumber

Pink Plumber is an example of innovative design and a great example of simplified social proof. From their homepage, potential customers can find why this Atlanta area plumbing company can be trusted.

It’s worth noting that creating a dedicated page within links to testimonials, directories, and reviews is highly recommended to improve user experience and gain even more reviews from your happy customers.

FAQ Section: Addressing Common Concerns

A well-structured FAQ section can provide immense benefits to both your plumbing business and website visitors.

It addresses common questions and concerns, saving time for both parties and providing valuable information upfront.

Tips for creating informative and helpful FAQs include grouping questions into relevant categories, using clear and concise language, and regularly updating the section based on new queries and feedback.

Providing answers that are informative and to the point can significantly enhance the user experience and establish your business as a helpful and knowledgeable authority in the plumbing industry.

Example Of Plumber FAQ: Summers and Zim’s

Summers and Zim’s is one of the best plumbing websites they show expertise and customer-focused attention.

An FAQ doesn’t need to be complex and can build over time. It’s also a great way to begin building a strong blog and resources sections as we’ll explore next.

Blog or Resources Section: Establishing Authority

Content marketing, through a blog or resources section, plays a pivotal role in both SEO and authority building for a plumbing website.

By providing valuable and informative content, you can attract more visitors to your site and position your business as an expert in the field.

Ideas for valuable blog topics don’t only live on your website. You can use blog posts to inspire social media posts, email marketing campaigns, and even script videos for your plumbing company.

Plumbing Blog Example: Dave Jones

Dave Jones uses a clean, modern plumbing design across their website. This extends to their blog that uses original images and a carousel to keep readers engaged with featured blogs.

Tips for a successful plumbing blog include:

Identify relevant and trending topics in the plumbing industry.
Write informative and engaging content that provides value to your readers.
Use keywords strategically to improve SEO and visibility.
Include high-quality images and videos to enhance your posts.
Update your blog regularly to keep content fresh and attract repeat visitors.
Promote your blog posts on social media and other channels to increase reach.
Engage your readers by responding to comments and encouraging discussion.
Collaborate with other industry professionals or guest bloggers to expand your audience.

Clear Call-to-Action (CTA): Guiding Visitor Actions

As we discussed early on, online booking, phone numbers, chatbots, and contact forms are key to the best plumbing websites converting leads.

Clear CTAs are crucial for guiding visitor actions on a plumbing website. This means they should stand out visually and convey a clear message on every page of your website.

CTA Example For Plumbing Website: Lee Company

Lee Company offers a vast range of services including home services and plumbing. For enterprise websites, a clear call to action can help website visitors cut through the confusion of complex navigation and connect with your sales team.

The blue Schedule Online button stands out and lets visitors request plumbing services quickly.

Here are some best practices for call-to-action (CTA) on a plumbing website:

Use clear and concise language that communicates the action you want users to take (e.g., “Schedule an Appointment,” “Get a Free Quote”).
Make CTAs visually stand out with contrasting colors or buttons.
Place CTAs strategically throughout the website, especially above the fold and near relevant content.
Personalize CTAs based on the user’s journey or the page content.
Keep forms simple and easy to fill to encourage conversions.
Test different CTA placements, wording, and designs to optimize performance.
Use action-oriented verbs to create a sense of urgency (e.g., “Call Now,” “Book Today”).
Provide multiple contact options (phone, email, contact form) to cater to different user preferences.

SEO Optimization: Improving Visibility

SEO optimization is essential for improving the visibility of a plumbing website in search engine results. This includes extensive content management, competitor analysis, and keyword research.

Beyond the visible sections of a website, the reason one plumbing company always seems to appear at the top of search results include technical SEO and off-page SEO strategies.

Incorporating SEO into a website is part of a digital marketing strategy for plumbers to succeed in the modern era. SEO helps search engines understand what your website is about and improves the chances of your site appearing higher in search results.

Example Of Plumbing SEO: Thomas & Galbraith

When someone searches for plumbing services in Cincinnati and surrounding communities, Thomas & Galbraith consistently rank in the top of organic search results.

Practices that the best plumbing websites use to improve search visibility include:

Optimized title tags and meta descriptions with relevant keywords.
High-quality, keyword-rich content that addresses user queries.
Mobile-friendly design for better ranking on mobile searches.
Fast loading speed to improve user experience and SEO.
Local SEO optimization with NAP (Name, Address, Phone) details.
Structured data markup for rich snippets in search results.
Secure website with HTTPS protocol for better ranking and security.
User-friendly navigation and URL structure for better indexing.
High-quality backlinks from reputable sources to build authority.
Regularly updated blog or resources section for fresh content.

Social Media Integration: Expanding Reach

Linking to social media profiles from a plumbing website offers numerous benefits.

It provides an additional platform for engaging with potential customers, showcasing your work, and sharing valuable content. Social media integration can also increase your brand’s visibility and drive more traffic to your website.

If your plumbing business is active on social media, your website design can connect happy customers to your accounts.

Social Media Integration: Fast Plumbing

Fast Plumbing in Austin, Texas features social media links prominently in the upper left of their homepage. This business website offers customers a range of social media including Facebook, Twitter, and LinkedIn.

They also link to YouTube and Google Business Profile to showcase videos and images of recent projects.

Consider how these social channels can improve your overall plumbing marketing strategy:

Increases brand visibility and online presence.
Builds trust by showcasing active engagement with customers.
Drives traffic from social platforms to your website.
Enhances SEO through social signals and backlinks.
Provides an additional channel for customer support and interaction.
Showcases your work and expertise through shared content.
Encourages word-of-mouth marketing as users share your content.
Allows targeted advertising and promotions on social platforms.

Localized Content: Connecting with Your Community

Localized content establishes you offer services and connect with your community.

Google and other search engines display local results when someone searches “plumber near me” or “plumbing services in Warsaw.”

By tailoring your content to specific geographic locations, you can make your website more relevant and appealing to potential customers in your service area.

The best plumbing websites make a connection with your target audience and also raise your prominence with search crawlers about your service area.

Local Plumber Services Example: Flow-Tech Plumbing and Heating

Flow-Tech Plumbing and Heating features 5 locations on their homepage. With plumbing services offered across a broad region, their plumbing website design includes a service areas section.

This helps both residential plumbing and commercial businesses searching for service discover Flow-Tech. Although their plumbing website content strengthens local SEO, the design stays focused on the website visitors.

Localized website design considerations include:

Dedicated pages for each service area or city you serve.
Local testimonials or case studies showcasing your work in specific neighborhoods or towns.
Tips for dealing with common plumbing issues specific to your area (e.g., hard water, seasonal changes).
Blog posts or articles about local community events or initiatives you’re involved in.
Local landmarks or references in your website’s imagery or descriptions.
A map showing your service areas or locations.
Local awards, certifications, or recognition your business has received.
Emergency plumbing services available in specific areas.
Seasonal plumbing maintenance tips relevant to your region.
Collaboration or partnerships with other local businesses or organizations.
Mention of local schools, parks, or landmarks near your business location.

Easy Navigation: Enhancing User Experience

Intuitive layout and organization play a crucial role in user satisfaction on a plumbing website. Visitors should be able to find the information they need quickly and easily, without getting frustrated or lost.

Best practices for website navigation include having a clear and concise menu, using descriptive labels for menu items, and organizing content logically.

Easy Navigation Example: Ingram Plumbing

Ingram Plumbing makes it easy for users to find the specific information and plumbing services with a clear navigation menu.

Clear and concise menu labels.
Sticky navigation menu for easy access.
Search bar for quick content finding.
Breadcrumb navigation for site hierarchy.
Dropdown menus for subcategories.
Footer links to important pages.
Logical and intuitive page layout.
Visible contact information.

How To Build The Best Plumbing Website

Creating a winning plumbing website involves more than just listing your services. It’s about crafting an online presence that reflects your brand identity, caters to your audience’s needs, and stands out in a competitive market.

At Valve+Meter, our team collaborates with businesses to design plumbing websites that represent your unique services.

By incorporating features such as a professional design, mobile-friendly layout, fast loading speed, clear contact information, and online booking options, you can enhance user experience and build trust with potential customers.

Additionally, showcasing your services, sharing customer testimonials, providing valuable resources, and optimizing for SEO will help establish your authority in the industry and improve your website’s visibility.

Great plumbing website designs start with your customers and the services you provide to your community.

From there, you need a team of experienced professionals in design, web development, content marketing, and search engine optimization to ensure your plumbing website is one of the best in the world.

Your website is an extension of your plumbing business. Just like your vehicles, support staff, and plumbers, it should represent the best your business has to offer.

Connect With Plumbing Design Experts

Interested in a new plumbing website or a redesign? Valve+Meter provides consultations and a free marketing assessment to understand how our team can make collaborate with your plumbing business.

Request Marketing Analysis

Frequently Asked Questions

What are the key features of the best plumbing websites?

Top plumbing websites share several key features. When assessing your current plumbing company website or consulting with professional designers, consider the following:

Professional design that stands out from other plumbing companies
Mobile-friendly layout that showcases all of your plumbing services
Fast loading speeds across all devices
Clear contact information
Online booking or quote request options
List of services offered in the navigation menu and footer
About Us page
Testimonials and reviews
FAQ section
Blog or resources section with localized content
Local SEO optimization, including city pages and local service area content
Social media integration
Security features
Easy navigation

How can I make my plumbing website more mobile-friendly?

To make your plumbing website more mobile-friendly, ensure it has a responsive design that adjusts to different screen sizes, optimize images and content for faster loading times on mobile devices, and ensure buttons and links are easy to tap on a touchscreen.

Professional plumbing website design firms can assist in choosing the best plumber website builder and themes for mobile. WordPress is a prominent CMS platform that can be customized to your plumbing company’s needs.

What are the benefits of having an online booking system on my plumbing website?

An online booking system can streamline the appointment scheduling process, making it more convenient for customers to book services at any time.

A variety of options, including phone numbers, chatbots, email forms, and online booking plugins, can reduce administrative workload, improve efficiency, and potentially increase the number of bookings by offering a user-friendly experience.

Plumbing websites are lead generation tools. Offering multiple forms of contact meets user preferences.

How can I improve the SEO of my plumbing website?

Search engine optimization (SEO) is a core element of effective plumber website design. While beautifully designed plumber websites are a great starting point, web crawlers need to understand what your website is about to rank it effectively.

Improving SEO focuses on increasing the relevance, credibility, and authority of your website. For a plumbing company, this means conducting local keyword research to identify relevant plumbing terms and optimizing your website’s content and meta tags with these keywords.

Advanced SEO involves creating high-quality and informative localized content, building backlinks from reputable sources, and regularly updating your content to keep it fresh and aligned with search engine updates.

The post 15 Features Of The Best Plumbing Websites With Examples appeared first on Valve + Meter.

Link + Popover Navigation

Wed, 15 Jul 2026 19:53:18 +0000

This is a redress of my 2019 post Link + Disclosure Widget Navigation, except (as the title implies), I’ve modified it to use native HTML popovers instead of ARIA or HTML disclosure widgets.

Popover has the benefit of using appropriate HTML structure and semantics while removing the need for scripting and ARIA. I use some ARIA here regardless.

`popover` vs. Disclosure Widgets

ARIA-based disclosure widgets (<button aria-expanded>) require script to work. HTML-based disclosure widgets (<details> / <summary>) expand when there is a hit for in-page searches (in two engines), have inconsistent exposure to accessibility APIs (across browsers and over time), and in my experience confuddle teams with styling overrides. I have a 2020 post going into some detail on each.

The popover feature requires CSS for positioning. Cross-browser anchor positioning support only came about recently. Because popovers appear on the top layer, you have to be careful with anything that uses z-index. Only use this pattern if all the dialogs on your site are already using the native HTML <dialog> element, otherwise overlapping issues happen.

The Pattern

Embedded below or visit it directly at Codepen. There’s also a debug version.

See the Pen Link + Popover Nav by Adrian Roselli (@aardrian) on CodePen.

The Container

The navigation lives in a <nav> as a list with nested lists.

<header>
  <nav id="Nav">
    <ul>
    […]
    </ul>
  </nav>
</header>

The Links

The links are links. They work with a keyboard, assistive technology knows what to do with them, and links are generally well understood by users.

I identify that the current parent page is the About page and the current page is Job Postings by using aria-current="page". I also use that as my CSS selector and you should too.

<li>
  <a href="[…]" id="Item02" aria-current="page">About</a>
  […]
  <ul id="SubItem02" popover>
    […]
    <li><a href="[…]" aria-current="page">Job Postings</a></li>
  </ul>
</li>

The Button Trigger

As my older pattern, the <button> element is the trigger. Unlike my older pattern, it doesn’t use aria-expanded (nor aria-controls, which was unnecessary then anyway).

Instead it uses popovertarget, which brings the programmatic state aria-expanded for free. The value of popovertarget must be the id of the content whose appearance you want to control (the popover content). The popover content needs the popover attribute for this to work.

No CSS or JavaScript is needed to make this content appear or disappear.

<button type="button" id="btnItem02" aria-labelledby="Item02" popovertarget="SubItem02">
  <svg […]>[…]</svg>
</button>
<ul id="SubItem02"popover>
 […]
</ul>

Naming the Button

This is the second place I still use ARIA. To avoid text duplication and auto-translation issues, I use aria-labelledby to reference the text of the preceding link. Screen reader users hear / feel a different control type and that it’s expandable, which has proven to be sufficient context. For voice users, saying the visible text presents them with the option to choose the link or the button.

<a href="[…]" id="Item02" aria-current="page">About</a>
<button type="button" id="btnItem02" aria-labelledby="Item02" popovertarget="SubItem02">
  <svg […]>[…]</svg>
</button>

Focus Order Support

You must place the popover content immediately after the popover trigger, otherwise you risk reading order and focus order problems for users. The popover feature does not automatically do any focus management.

`Esc` Support

It comes for free with popover.

Click-to-Close Support

It comes for free with popover.

Focusout-to-Close Support

You’ll have to write your own.

Styles

Not all of these styles will work for you, but these may matter:

I use logical properties throughout. The demo has buttons to let you cycle between four writing directions. They are not a perfect test since neither the rest of the page nor the text change.
There are no classes. IDs only exist as hooks for popover and naming references.
the links are block links (using CSS generated content) to fill the container. The buttons have a z-index to sit in front of them.
The layout uses flexbox with no width media queries. If you don’t like the wrap or the layout, write your own.
Supports forced-colors / Windows High Contrast Mode out of the box with no custom CSS. That’s partly because the focus styles use outlines.
Uses color-scheme: light dark just so I could more easily see styling gaps, but I don’t recommend that for real-life use.
The buttons use an arrow SVG that rotates via :popover-open when the popover appears / disappears. It honors user motion preferences.
The button and arrow position shift based on typeface, as with any layout mixing icons and type.
The popover triggers conform to 2.5.8 Target Size (Minimum), but you can always make them bigger. Make sure yours at least conform.

There is a button on the demo to remove all styles from the page, making it easier to see how this will perform as raw HTML, for easy testing, or for CSS Naked Day.

Popover Positioning

I haven’t played with popovers much. Positioning it to work across Firefox, Chromium, and Safari while also not overflowing the window or falling apart with text direction changes proved to be a challenge. I welcome suggestions on improvements.

My goal was to have the popover appear to the right edge of the parent list item and just below the button — for left-to-right languages — and in a corresponding location for other language text directions.

[popover] {
  inset: auto;
  position-anchor: auto;
  inset-block-start: anchor(self-end);
  inset-inline-end: calc(anchor(self-end) - 1em);
}

I flailed about trying different values from the spec and struggled to understand logical properties with anchor positioning. As it is, the popover positioning falls apart with the vertical writing modes, but I can’t be sure if that’s my code or browser bugs (¿Por qué no los dos?).

Pattern History

There are reasons I built this pattern.

Early in 2017 I filed an issue against ARIA Authoring Practices (APG) requesting a change to the menu navigation pattern. Despite a great deal of feedback in agreement, it continues to languish. In late 2017 I wrote Don’t Use ARIA Menu Roles for Site Nav and started actively campaigning against the APG pattern. In 2019, Sarah Higley proposed a disclosure-only APG pattern and then a disclosure and link pattern proposal in 2020.

An under-baked batch of mini popovers I made for my solo Easter during the first year of the pandemic. I still ate them all.

HTML (via Open-UI) has since stepped in to fill some gaps, so here we are.

Wrap Up

Standard disclaimers apply: may not work for your audience, likely has bugs, support can change, new features may moot this, my design sense is poor, yes you have to write script to get whatever custom interactions you think are nifty but which probably annoy users, who even writes code anymore, using [insert random element here] in a way that’s not mentioned in this post is your problem not mine, etc.

And if you have more experience with multilingual popover anchor positioning, please share!

Update: Same Day

Ana Tudor, possibly offended by my middling layout skills and crap SVG knowledge, forked my demo to replace the block link with good old-fashioned grid, make a better SVG, adjust the popovers to stay in the viewport for vertical RtL layouts, and address the rotation differently (you’ll need to add language code selectors for your use cases).

I plan to test and integrate them into mine, but until then I’ve embedded Ana’s fork or you can visit the debug view of Ana’s fork directly.

See the Pen Link + Popover Nav by Ana Tudor (@thebabydino) on CodePen.

Curtis Wilcox made a fork with the anchor positioning polyfill. I intentionally ignored the polyfill because I didn’t want to field tech support questions for a thing I haven’t used, but Curtis is a better than man than I. I’m still not tech support for the polyfill (James Stuckey Weber might be, but probably don’t pester him).

Nathan Knowler reminded me that :not(:open)::details-content can be used to prevent a <details> from expanding on a hit from in-page search but since I was too lazy to test it for this post, go check out his demo.

Update: 10 July 2026

Technically still the same day, but I was already away from screens and am only adding it today. Kirk Loretz did not fork my pen, but he made a new one to test popover positioning with different writing modes. Then he went to the CSS Working Group repo and filed #14159 [css-anchor-position-1] Popover text direction/writing-mode bugs. If you have expertise in this area, it might be worth checking the issue.

Focusgroup Tests — Adrian Roselli

Wed, 15 Jul 2026 19:53:18 +0000

Focusgroup Tests

Chrome 150 has landed support for focusgroup, a feature proposed by Open-UI and not yet in WHATWG HTML as anything more than a feature request. Open-UI has outsized representation from Google and Microsoft folks, so it’s no surprise Chrome would implement it first.

“FOCUS!” by Metro Centric, CC BY 2.0; cropped, skewed, and desaturated.

Open-UI has a handy focusgroup explainer, which is the only place (inside or outside of a spec) to understand how to use it and what it’s meant to do. Which means this is your best opportunity to play with it before it gets into a spec.

To hopefully make that easier, I’ve created a series of very basic demos using the properties outlined in the explainer.

Demos

There is no scripting in any of these demos. The only styles are to honor dark / light mode, make focus styles more obvious, and add some text defaults. None of the controls do anything. The labels are nonsense. I left a set of boring default HTML buttons at the end of each demo as a comparison.

Observe how the axis of movement is based on the default widget visual display. For example, listbox wants up and down arrows because they are generally vertically stacked (block). My demo, however, makes no effort to set a layout. This is not a focusgroup bug, but if you use listbox for something like “pills,” which are generally horizontal (inline), then you would need to address that.

With all the available properties, there are more permutations than I have coded. I also haven’t done complex nor nested demos. I just don’t have the time. But you, dear reader, probably enjoy pointing out things I missed. Please do so. Make your own examples. Play around. Try your own use cases and expectations. Leave comments letting me know what I, or the proposal, got wrong.

If you work in digital accessibility, you have an opportunity to find gaps that others might miss (especially in how roles are exposed). Let’s get those documented before the spec or browsers ossify code that cannot be readily changed in the future. Let’s help ensure developers won’t create more inaccessible experiences simply by using this new property.

You’ll need Chrome 150 to test these today, but as more browsers add support these will still be useful.

`listbox`

View the listbox demo pen directly or open the listbox demo in debug mode.

See the Pen focusgroup="toolbar" by Adrian Roselli (@aardrian) on CodePen.

`menu`

View the menu demo pen directly or open the menu demo in debug mode.

See the Pen focusgroup="menu" by Adrian Roselli (@aardrian) on CodePen.

`menubar`

View the menubar demo pen directly or open the menubar demo in debug mode.

See the Pen focusgroup="menubar" by Adrian Roselli (@aardrian) on CodePen.

`radiogroup`

View the radiogroup demo pen directly or open the radiogroup demo in debug mode.

See the Pen focusgroup="radiogroup" by Adrian Roselli (@aardrian) on CodePen.

`tablist`

View the tablist demo pen directly or open the tablist demo in debug mode.

See the Pen focusgroup="tablist" by Adrian Roselli (@aardrian) on CodePen.

`toolbar`

View the toolbar demo pen directly or open the toolbar demo in debug mode.

See the Pen Untitled by Adrian Roselli (@aardrian) on CodePen.

Notes

In very quick tests, a few things jumped out at me:

In the focusgroup="none" test across all patterns, I found the button with focusgroup="none" as well as those flanking it accepted focus from Tab↹. It presents as the first three buttons accepting focus (the second one has focusgroup="none"). I understand why, but that feels like a bug.
The interactive child with focusgroup="none" (to remove it from the focusgroup) keeps its role from the element, instead of assigning it the required accessibility child role. That might feel like a bug if you expect focusgroup="none" to work like a weird disabled state (it’s not).
Adding role="presentation" to a node with focusgroup has no effect. The role from the focusgroup is still exposed in the accessibility tree and AAPIs. This is also true for role="none" (none is a synonym for presentation). This means you cannot apply focusgroup and then un-role it to keep the interaction but avoid the other requirements of the role. This feels like a bug?
James Scholes has corrected my misunderstanding. When using NVDA or JAWS, the virtual cursor will not let me go letter-by-letter within a button (handy for getting the spelling) unless I leave forms mode (by pressing Esc in JAWS, for example). This is different from how I can typically interact with buttons. That feels buggy but I am not a daily screen reader user.

A table tracking what property behaviors are exposed from my tests.

Opinions

I’m frustrated the explainer leans on APG patterns as if they are a, or the, standard while pointing only to MDN instead of the actual ARIA standard. I understand why, but you may know how I feel about APG.

I’m frustrated the menu example refers to web site navigation, when there is years-old evidence showing that as an anti-pattern. I’m working on a web site navigation post to address this. 14 July: Luke Warlow replaced the site navigation example with a far more appropriate toolbar example. Issue 1474, PR 1475.

I’m frustrated yet pleased navigation across a two-axis construct, such as an ARIA grid, is deferred. Though I understand that gets more complex.

While I’m thrilled this isn’t going into CSS, I’m worried that it isn’t completely off the table. I’ve so far been unimpressed with the CSS Working Group’s ability to address accessibility concerns.

I’m excited to see these ARIA concepts finally make it to HTML (if only as a proposal so far). This fits the original model of ARIA as a temporary, bridging technology until HTML caught up. Which hey, maybe that will start to happen.

While I like that using focusgroup brings ARIA roles for free (in the accessibility tree and exposed to AAPIs), I’m worried how readily developers will unintentionally role-up standard HTML just to get free arrow key interactions. One Open-UI explainer menu example fails to remove roles from lists, demonstrating how easy it is to forget unless your testing is robust ( 14 July: issue 1476 should address this).

In April, Steve Frenzel shared his own in My thoughts on the “focusgroup” attribute proposal for an older proposal.

Added to Link + Disclosure Nav

6 July 2026. Open-UI’s focusgroup Quickstart (incorrectly) uses the APG menu navigation pattern. In mid-2019 I responded to the APG pattern with a link & disclosure navigation prototype. Today I forked it (debug view) and added focusgroup="menubar", something I half expect authors to try.

See the Pen 2017 Link + Disclosure Nav with `focusgroup` by Adrian Roselli (@aardrian) on CodePen.

I got some interesting results:

Using Chrome 150.

I don’t know if this is a bug, but it certainly feels like someplace a dev can get confused when determining where to apply ARIA roles for accessibility children of the navigation.

Update: 10 July 2026

The Microsoft Edge team is working on an explainer, Focus Landmark: declarative landmark focus navigation for web apps. It looks like it might using the momentum from focusgroup to pitch focuslandmark, possibly with similar ARIA-role-setting tokens. Discussion is already happening at Open-Ui issue #1472 [focuslandmark] No declarative way to move keyboard focus between major page regions. Sarah Higley linked to Carolyn MacLeod’s years-old Web We Want request.

Update: 13 July 2026

The Microsoft Edge team also has its own tests, linked from the undated Focusgroup: Interactive Demos. They were definitely published before Chrome’s release, given it tells readers how to enable experimental flags.

2 Comments

Reply

Thanks for putting these together! That’s super useful!

Question, why do you have a demo with role=”presentation”?
One should never have a focus group of buttons without a group level element without a role (one of listbox, menu, menubar, toolbar, radio group, or something I am forgetting).
Without one, a screen reader will not go into forms/application/focus mode so the arrow keys won’t work, and there is no hint to the screen reader user that these controls are grouped.

On orientation, is there an attribute that goes with focusgroup to indicate orientation?
If not, that might be something to propose, because it impacts both how the group is presented to a screen reader user and the keyboard operability of it (with and without a screen reader).
Another approach would be to support all arrow keys, with arrows up/left navigate up/previous and arrows down/right navigate down/next.
That way the orientation becomes less important, at least from a functional perspective. You could use aria-orientation as a descriptive attribute to tell the screen reader user what it looks like, but it wouldn’t have to tie into the keyboard operation.

There are still some things to figure out with all this, but it’s super exciting that finally we are getting the capability to support keyboard operation for common components, pretty much without JavaScript.

Birkir; 7 July 2026 at 12:24 pm. Permalink

In response to Birkir. Reply

Question, why do you have a demo with role=”presentation”?

Because I am confident I will run into teams in the wild trying to get free arrow key navigation in a thing without it getting roled-up into something they don’t want. I was being pre-emptive (and judgmental).

On orientation, is there an attribute that goes with focusgroup to indicate orientation?

The inline and block tokens are as close as it gets. Though they are less about orientation and more about reading axis. My tests show throwing in both tokens supports both sets (all) of arrow keys working. Throwing aria-orientation had no functional impact.

Adrian Roselli; 7 July 2026 at 1:10 pm. Permalink

A modern HTTP request – Nelson's log

Wed, 15 Jul 2026 09:46:07 +0000

I got curious about what HTTP headers Chrome is requesting so I stood up a trivial HTTP server and this is what is on the wire.

$ while true; do echo -e "HTTP/1.1 200 OK\nContent-Length: 3\n\nOK\n" | nc -l -p 8081; done

GET / HTTP/1.1
Host: localhost:8081
Connection: keep-alive
sec-ch-ua: "Not;A=Brand";v="8", "Chromium";v="150", "Google Chrome";v="150"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
DNT: 1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
sec-gpc: 1
permissions-policy: browsing-topics=()

Goodness that’s a lot of stuff! I still remember when even the Host header was optional (in HTTP/0.91). And my knowledge taps out around HTTP/1.1, the Connection: keep-alive and the Accept headers.. Anyway, what else is there?

The sec-ch-ua stuff is a modern replacement for User-Agent

DNT, sec-gpc, and permissions-policy are various requests to preserve my privacy. I just installed OptMeOwt, it is adding some of these. I think permissions-policy is a Google thing.

The Sec-Fetch stuff is about the intent of the request and is apparently used to make decisions related to CSRF, CORS, etc.

Upgrade-Insecure-Requests is telling the webserver to redirect me to https if it can.

In general sec- is a “forbidden request header“: only the browser is allowed to set these headers, not Javascript on the page. (Extensions can set them though.)

One other trivia I learned about: HTTP Trailers. This lets you set more headers at the end of an HTTP request instead of the start. Say data you only know about after a long POST or something. These date all the way back to 1997 and HTTP/1.1 apparently but I’ve never encountered them. They don’t work with the simplest request format since there’s no way to identify the end of the HTTP body. Chunked encoding allows for them and I imagine later encodings have something similar.

Like Loading…

You should probably check on your smart appliances - Xe Iaso

Wed, 15 Jul 2026 00:39:33 +0000

You should probably check on your smart appliances

Published on 2026-07-14, 1008 words, 4 minutes to read

TL;DR: is your refrigerator running malware? If so, you better catch it!

The scraping problem is worse than anyone can imagine and thanks to my friends at Sourceware we have some real data to prove it.

I've been working more on Anubis' reputation database and I've run into a really weird discovery: 80-90% of the hits created by the honeypot feature are from IP addresses that do not belong to any existing threat monitoring lists.

Here's a breakdown of the honeypot hits Sourceware has gotten in the last few months:

Assessment of ./data/manually-submitted/sourceware/202607141625.txt against ./var/reputationdb.mmdb

In case this interests you, I have put the full tables in Appendix A: Full tables for the reputation database input.

Field	Value
lines read	2678193
skipped (non-IP):	0
skipped (dupe):	0
unique IPs:	2678193
flagged (in db):	286161 (10.7%)
clean (not in):	2392032 (89.3%)

Flags (of flagged addresses)

Flag	Unique IPs	Share
is_vpn	1264	0.4%
is_datacenter	7918	2.8%
is_crawler	46	0.0%
is_proxy	2562	0.9%

Categories (6 distinct, of flagged addresses)

Providers (126 distinct, of flagged addresses)

Mara

Methodology note: "provider" here means one of two things:

The company or organization associated with the IP address.
The place the list was gotten from.

For example, scaleway is based off of Scaleway's publicly posted IP address ranges, firehol-level1 is based on a daily snapshot of FireHOL's Level 1 IP list, and fdo is based on data contributed by the administrators of freedesktop.org.

Provider	Unique IPs	Share
netshield	237945	83.2%
bitwire	96539	33.7%
magicteamc	26475	9.3%
ipinsights	17378	6.1%
threathive	8422	2.9%
netmountains	6673	2.3%
multacom	2676	0.9%
fyvri	2433	0.9%
cbuijs	1916	0.7%
x4bnet	1263	0.4%
solispirit	1259	0.4%
dailyproxy	1182	0.4%
blackwall	1073	0.4%
hproxy	1067	0.4%
scaleway	922	0.3%
fdo	755	0.3%
datacamp	702	0.2%
ebrasha	686	0.2%
hideip	628	0.2%
datacentres	480	0.2%
komutan	463	0.2%
aws	431	0.2%
m247	360	0.1%
firehol-level1	354	0.1%
vpslab	331	0.1%
alibaba-cloud	319	0.1%
proxyscrape	272	0.1%
ovhcloud	268	0.1%

(remainder snipped for brevity)

Countries (229 distinct, of all addresses)

Country	Unique IPs	Flagged	Rate
Brazil (BR)	270937	18282	6.7%
India (IN)	185091	12478	6.7%
Saudi Arabia (SA)	120372	3574	3.0%
Mexico (MX)	95449	7053	7.4%
Türkiye (TR)	87258	5559	6.4%
Argentina (AR)	86463	9522	11.0%
Pakistan (PK)	85241	17083	20.0%
Vietnam (VN)	78967	8848	11.2%
Morocco (MA)	69201	1805	2.6%
Philippines (PH)	66128	7899	11.9%
Venezuela (VE)	64670	13780	21.3%
Iraq (IQ)	62047	13613	21.9%
Chile (CL)	60878	4522	7.4%
Colombia (CO)	59579	7048	11.8%
Bangladesh (BD)	59245	17735	29.9%
France (FR)	49782	1339	2.7%
Tunisia (TN)	48535	5799	11.9%
Uruguay (UY)	45888	430	0.9%
South Africa (ZA)	43919	7431	16.9%
United States (US)	40828	3347	8.2%
Indonesia (ID)	38119	6122	16.1%
Canada (CA)	37342	2334	6.3%
Spain (ES)	36008	2944	8.2%
Algeria (DZ)	35112	537	1.5%
Ukraine (UA)	32261	8920	27.6%

This doesn't list data from 204 additional countries. Given that the ISO 3166-1 standard comprises 249 countries (193 of which are UN members), it's safe to say this is a global problem.

ASNs (21116 distinct, of all addresses)

ASN	Unique IPs	Flagged	Rate
AS55836 Reliance Jio Infocomm Limited	57029	1749	3.1%
AS45899 VNPT Corp	56910	6831	12.0%
AS6057 Administracion Nacional de Telecomunicaciones	43694	339	0.8%
AS25019 Saudi Telecom Company JSC	40800	679	1.7%
AS24560 Bharti Airtel Ltd., Telemedia Services	35957	1620	4.5%
AS36903 Office National des Postes et Telecommunications ONPT (Maroc Telecom) / IAM	35562	668	1.9%
AS36947 Telecom Algeria	33172	386	1.2%
AS9121 Turk Telekom	32742	1465	4.5%
AS8151 UNINET	32012	856	2.7%
AS14593 Space Exploration Technologies Corporation	31569	4597	14.6%
AS9299 Philippine Long Distance Telephone Company	27573	1626	5.9%
AS39891 Saudi Telecom Company JSC	25904	794	3.1%
AS35819 Etihad Etisalat, a joint stock company	24493	978	4.0%
AS28573 Claro NXT Telecomunicacoes Ltda	23903	841	3.5%
AS8193 Uzbektelekom Joint Stock Company	22611	3191	14.1%
AS8452 IDDQD-AS	22369	364	1.6%
AS43766 Mobile Telecommunication Company Saudi Arabia Joint-Stock company	22038	968	4.4%
AS9541 Cyber Internet Services (Pvt) Ltd.	21386	3696	17.3%
AS37705 TOPNET	20024	222	1.1%
AS11664 Techtel LMDS Comunicaciones Interactivas S.A.	18021	883	4.9%
AS17072 TOTAL PLAY TELECOMUNICACIONES, S.A.P.I. DE C.V.	18021	1181	6.6%
AS22927 Telefonica de Argentina	17672	291	1.6%
AS13999 Mega Cable, S.A. de C.V.	17410	692	4.0%
AS36925 MEDITELECOM	17259	383	2.2%
AS47331 Turk Telekom	17211	26	0.2%

There are 18069 more ASNs not listed.

How Anubis' honeypot works

In order to collect data on how widespread the scraper problem is, I added a honeypot feature to Anubis. On every challenge page it adds semantically invalid HTML akin to the following:

Visiting that page gets you cheap to generate vacuous anti-content that has two links to other pages. This is intended to get badly written scrapers caught in the honeypot so they scrape that instead of the protected website. I made it on a whim but thought it would be great for collecting data on how widespread this problem actually is.

This is a global problem

Based on the data I've seen, this is a global problem. If I had to guess where most of this traffic is coming from, it's from compromised smart appliances contributing traffic to proxy networks. I don't think there's any way to make a real impact on this problem without concerted simultaneous global action.

TL;DR: the scraping problem is actually widespread enough that web application firewalls like Anubis make sense.

Facts and circumstances may have changed since publication. Please contact me before jumping to conclusions if something seems wrong or unclear.

Tags:

Too many words about DIDs

Tue, 14 Jul 2026 18:39:07 +0000

Too many words about DIDs

Jul 14, 2026

ATProto & Bluesky

Your “Bluesky account” is not just a Bluesky account: it is an account that can be used with a variety of other applications. This post is going to be an exploration of part of what that means from a technical perspective, so if you’re not a software developer, this post isn’t for you. But what I’m going to explain is the technical mechanism for how your account works separate from Bluesky, and in fact, separate from any particular app.

Let’s talk about identity: who are you, anyway? Users of a system need some sort of way to describe who they are to use it. If you want to log in, you need to present who you are. If you want to make a post, well, we need to know who the author of that post is. For atproto, the protocol that underlies Bluesky and other apps in the ATmosphere, they use the “Decentralized Identity” standard, also known as DID. The W3C standardized DIDs in 2022. As you might guess from the name, DIDs are, an identifier that you can use as the basis of identity for building applications. And the idea is that these identifiers are decentralized. However, a lot of people have a lot of feelings about that specific word, and often accuse atproto of not being properly decentralized. We’re going to go over the details so you can understand how this works, and you can decide for yourself if this approach suits you or not.

DIDs and DID Documents

Here is my DID, we’ll use this as an example: did:plc:3danwc67lo7obz2fmdg6jxcr

There are three parts, separated by colons: The scheme (did), the method (plc), and the DID method-specific identifier (3danwc67lo7obz2fmdg6jxcr).

To use a DID, such as did:plc:3danwc67lo7obz2fmdg6jxcr, you resolve it into a DID Document

A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID.

That document contains various properties that describe the identity. Here’s my DID Document, at the time of writing:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1",
    "https://w3id.org/security/suites/secp256k1-2019/v1"
  ],
  "id": "did:plc:3danwc67lo7obz2fmdg6jxcr",
  "alsoKnownAs": ["at://steveklabnik.com"],
  "verificationMethod": [
    {
      "id": "did:plc:3danwc67lo7obz2fmdg6jxcr#atproto",
      "type": "Multikey",
      "controller": "did:plc:3danwc67lo7obz2fmdg6jxcr",
      "publicKeyMultibase": "zQ3shfNec2kPEb8cL77gSRMbCwbWE27p9nxKkcc4E82xtW8RJ"
    }
  ],
  "service": [
    {
      "id": "#atproto_pds",
      "type": "AtprotoPersonalDataServer",
      "serviceEndpoint": "https://morel.us-east.host.bsky.network"
    }
  ]
}

This document gives you everything you need to know to determine who I am, that is, given an arbitrary post that claims it’s written by me, this document describes how you’d verify that claim.

We’ll get into how to do that that in a moment, but first, how do you resolve that DID into that DID document? Well, it’s pretty easy: each method is a standard that describes how you do that. So when you see did:plc, that means we use the PLC standard, which we’ll be going over in a moment. Another method supported by Bluesky is did:web. In that case, you wouldn’t use the PLC standard, you’d use the Web one.

This is the sense in which DIDs are decentralized: when you present your identity, you get to decide what method validates that that is a real identity. There’s no centralized authority that determines which DID types are valid. Now, of course, that doesn’t mean that every application supports every DID method, because while this specification is very generic, you’re still going to have to write some code to implement that particular method. I could say “Hey I’m did:foo:1243” and unless your app supports the foo method, it’s not gonna inherently just know what to do. So that is one important caveat.

`did:web`

Let’s explain this resolution process for the web method. While supported by Bluesky, a very small number of users actually use did:web, but it’s a simpler method and so I think it’s illustrative to go over first. I’ll be using Liz Fong-Jones did:web account as an example here. Her identity for that account is did:web:lizthegrey.com.

So how do we resolve this DID into a DID Document? We take the method-specific identifier, which in this case is lizthegrey.com, and put it into this URL template:

https://<id>/.well-known/did.json

You can then go fetch this URL to resolve it into the DID Document, which at the time of writing, looks like this:

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/multikey/v1",
    "https://w3id.org/security/suites/secp256k1-2019/v1"
  ],
  "id": "did:web:lizthegrey.com",
  "alsoKnownAs": [
    "at://web.lizthegrey.com",
    "did:plc:i4tfenpfog244rxry5uz4vtk"
  ],
  "verificationMethod": [
    {
      "id": "did:web:lizthegrey.com#atproto",
      "type": "Multikey",
      "controller": "did:web:lizthegrey.com",
      "publicKeyMultibase": "zQ3shnEqBNR5cuTePW8FyvnrRQaFf6Y7sCi5NBmDpteVXFjb6"
    }
  ],
  "service": [
    {
      "id": "#atproto_pds",
      "type": "AtprotoPersonalDataServer",
      "serviceEndpoint": "https://pds.lizthegrey.com"
    }
  ]
}

This is very simple! So why might we not want to use did:web? Why bother with any other system? Well, this relies on the DNS system. One could make the argument that ultimately, this is still centralized in some form. If Liz’s domain registrar were to take away her domain, she would also lose control of this DID. In a more generic sense, if Liz decides she wants to not use that domain anymore, she will lose control of that identity to whoever does. That could be through non-malicious means, like letting it expire and someone else purchases it, or through malicious ones, like a hack which would compromise her registrar account and take the domain over.

Also, you need to have a web server running on that domain with infinite uptime; if the server goes down, so does your ability to get the document.

When this DID document changes, there’s no mechanism for clients to know that it’s changed, which means applications may use one that’s out of date, or that there is lag between updating the document and updating the application built on it, which may cause temporary problems until the latest document is fetched.

`did:plc`

All of these drawbacks led Bluesky to develop their own DID method, which attempts to fix these problems and others. This method is called did:plc. To resolve a did:plc, you take the entire DID, and put it in this template:

https://plc.directory/<did>

You can then fetch that URL and get the DID document.

So… what’s the difference? Well, in this case, both nothing and something. In a very literal sense, both are resolved in the same way: you fetch a URL. However, the details matter. There is already two ways in which this is different than DID:Web:

Your DID is no longer tied to a specific domain name. I can let steveklabnik.com expire and move to steve.klabnik.com and my did:plc stays the same.
While a web server still needs to be running, that’s the job of plc.directory, not my own job. This is operationally much simpler.

I’ve presented the above as pros, but there are also cons. Before, I had to trust the DNS system and domain registrars, now I have to trust plc.directory. All of the same caveats apply in that sense, I have to trust that they don’t take my ID away from me, or that it doesn’t get stolen, etc. However, there are also some important details that mitigate this, which we’ll get to. But for some people, neither trusting DNS nor trusting plc.directory is acceptable, and there are other DID methods that use, for example, a blockchain to resolve the name. Bluesky does not support using any of those DID methods, so for this application, it’s not really relevant, but it’s important to know that they exist.

Why do it this way? Well, the simplest way to put it is this: setting up a did:web involves a lot of “nerd stuff.” You have to register a domain, and that’s also an ongoing monetary cost. You have to know how to set up a web server, and author some JSON to put on that server. You have to keep it running. You have to know how to store your private keys, and keep them safe. It’s a non-starter compared to “sign up for this web app.” And Bluesky’s goals involves making this platform accessible to non-nerds. By having plc.directory manage all of this, we eliminate all of those steps.

While drafting this post, I have also been made aware of did:webvh, which expands on did:web and attempts to rectify some of its shortcomings. I have not read the spec yet, but it has reached 1.0, so it is probably worth checking out. I wanted to get this post shipped last week, and didn’t want to delay it further by adding another section, but if I were writing this post in the future, I’d probably want to talk about it as well, so just a little heads-up there.

Does Bluesky own your identity?

But it does also mean that, in some sense, Bluesky still owns your identity. They’ve generated a keypair for you, and the have access to the secret key. That’s unacceptable for some people. So how do you fix that?

Well, did:plc has some additional features that did:web does not. For example, did:plc will allow you to register additional keypairs with your ID and use them to rotate your signing keys. This allows you to remove the Bluesky generated keys and insert your own.

While that is true, it’s also the case that your PDS needs to use your keys to sign your posts. As such, most people are likely to store their keys in their PDS, and so if you are using a Bluesky managed PDS, well, you’ve uploaded your keys to their infrastructure, and that’s probably not acceptable if you’re trying to keep your identity away from Bluesky. Of course, the solution there is to run your own PDS and then rotate your keys. At that point, your key is living on infrastructure you own, and Bluesky has no say over it any more.

I think that this possibility is an important design property, and allows motivated users to meaningfully own their identity. A criticism of this boils down to “well, most users won’t do that,” and while that’s true, I also think that’s okay for most people, and that having the choice is more important than forcing every user to deal with their own key management.

In summary

This is kind of an abrupt end to this post, but I just wanted to get some things down ‘on paper’ as it were. I hope you’ve learned a bit about identity and how it works with atproto.

Here’s my post about this post on BlueSky:

Just Let Me Write Digits | Blog | Guillaume Endignoux

Mon, 13 Jul 2026 19:17:18 +0000

Digital identities and what they mean for the web have become a hot topic of discussion in the last few years. They have also brought many controversies: age verification laws and what they mean for online anonymity, Wikipedia potentially having to verify the identify of its users in the UK, the reliance on official iOS and Android operating systems as mandatory form factors for digital identity wallets, not to mention what these inter-dependencies mean when your US digital accounts are cancelled for being a judge at the International Criminal Court.

My story is about the Swiss governmental login system AGOV. Deployed since 2024, it now counts 1.6 million accounts and it is increasingly becoming the login mechanism to benefit from unemployment insurance, file taxes (a mandatory activity!), and many other interactions. In the canton of Zurich, this is the only entry point to apply for citizenship.

So I eventually had to create an AGOV account. Unfortunately, registering an account proved to be a real challenge, until I got the bottom of a weird accessibility bug. Inspired by Just Let Me Select Text, it’s my turn to present you Just Let Me Write Digits.

AGOV registration
Contacting support?
Asking around
Investigating the web page
Conclusion
Post-mortem

AGOV registration

The first step of the AGOV registration process is to provide your email address and enter a verification code to validate the address. My problem was that I couldn’t even enter this code!

To set the context, the form to enter the verification code is split into 6 boxes (one per digit). The first weird thing was that every time I typed a digit, the focus wouldn’t automatically jump to the next box. Instead, the current box would accumulate more digits and highlight them in red, indicating an error.

At first, I thought that this was just a minor UI bug, and that I could manually jump to the next box after each digit. However, this didn’t work and the page would always display a “field required” error at the end, even when I carefully filled one digit per box. Strange.

I tried looking at the DOM in the developer tools to see if there was a form value I could manually adjust, but nothing obvious stood out. No error message was logged either in the web console. Using a different email address, or even a fake one¹ like test@example.com didn’t make any difference.

Given that I was browsing the web with Firefox on Linux, I thought that maybe this combination was unsupported or failing a CAPTCHA. This would be unlikely – I barely encounter any website broken specifically on Firefox or Linux these days – but not impossible. Indeed, the registration page connects to eu-api.friendlycaptcha.eu just before the verification code form appears. And the official AGOV documentation only mentions Windows and macOS as supported operating systems, even though a different page about security keys states that Linux and Firefox are supported.

To rule this out, I ended up trying 6 combinations of browsers and operating systems: Firefox, Chromium and Chrome on Linux; Firefox, Safari and Chrome on macOS. All of them showed the same error!

Contacting support?

At this point I thought it’d make sense to contact the official support. The AGOV website has many help sections, but unfortunately, this didn’t lead me very far because the only way to contact support is via a web form… that starts by sending a verification code to your email! The exact same form I couldn’t pass.

And yes, the FAQ explicitly mentions that this form is the only way to contact support (emphasis mine).

Support for participating authorities is provided by second-level support during office hours exclusively through the creation of tickets online.

The impressum also lists the physical postal address of the Swiss Federal Chancellery, who are likely not the ones directly developing the website anyway. There are no other contact details: no email, no phone number. Alternatively, one can in principle write a comment to “share feedback on AGOV: praise, criticism, requests”, but that again requires an AGOV or equivalent account to log in. A true chicken and egg problem!

I also looked at the online reviews of the AGOV Access Android app, which is currently rated 1.4 stars – by far the worst of any app I’m using. Unfortunately, nobody mentioned an issue similar to mine on these Google Play store comments. Interestingly, there were many comments about support for GrapheneOS (a private and secure mobile OS derived from Android) and the official FAQ now even has an entry about it (emphasis mine)!

The AGOV access App does not work on GrapheneOS because the hardening framework, which protects the AGOV access App against unauthorized manipulation, is not compatible with GrapheneOS. The Federal Chancellery has tasked the supplier with ensuring compatibility.

It sounds promising, but for now you can only register/login with a second-factor device that’s either a smartphone with vanilla iOS or Android, or a security key (good that it’s an option!). Of course, after you pass email verification.

Asking around

I wasn’t in a rush to create my AGOV account yet, so I casually mentioned this issue to some friends, but nobody seemed to have encountered this problem.

I also thought to ask some colleagues and tried the registration page on my work laptop to make a screenshot to show them evidence. Surprisingly, the form worked this time! The autofill automatically jumped to the next box, and it actually detected that I entered an incorrect code rather than no code at all!

This time the error was “Code entered is incorrect”.

But I obviously don’t want to rely on an employer-issued computer for long-term interactions with the government. Even if I managed to register via my work laptop, there was always a risk that I wouldn’t be able to login with my personal laptop.

Unfortunately, none of my colleagues had encountered my error… I also tried on a friend’s computer, with the same three browsers on macOS, and all of them accepted a verification code!

Was I really that unlucky to own the only two computers in the world for which this website breaks??

Investigating the web page

At this point I was out of simple ideas, so I thought to inspect the web page. It surprisingly loads only a few resources, but the main JavaScript file was 2.4MB, expanding to more than 100K lines of semi-obfuscated/minified code. This looked quite daunting as some parts looked very obfuscated at first glance.

So I decided to wait a bit more in case someone would have an idea.

According to the FAQ, the source code of the AGOV system will be published at the end of 2026 to satisfy legal requirements.

Article 9 EMBAG stipulates in paragraph 1:

“The federal authorities subject to this law shall disclose the source code of software that they develop or have developed for the fulfilment of their tasks, unless third party rights or security related reasons prevent or limit such disclosure.”

In December 2026, the source code of AGOV will be published in accordance with this requirement. This is the AGOV version that represents the achievement of the AGOV project goal, namely AGOV including AGOV e-ID Verifier. Later versions will be described in the release notes www.agov.ch/rn, prepared for publication after release and published.

Having the source code upfront and a place to report bugs directly to developers would have helped my investigation, but unfortunately for me, AGOV is already the mandatory login system for some services before its source code has been published!

I eventually came back to it, and fortunately searching for “field required” gave some hints into the logic.

Continuing the search with “required”, I found this email verification function that sets the status code to “REQUIRED”.

onEmailVerification() {
  var _ = this;
  return (0, ve.A)(function* () {
    ((_.showResendSuccessfulBanner = !1),
      _.verificationCode
        ? _.verificationCode.length === _.verificationCodeLength
          ? (_.statusCode.set(""),
            (_.isLoading = !0),
            yield (0, Qt.s)(
              _.registrationService.emailVerification(_.verificationCode, _.userEmail),
            )
              .then((S) => {
                "VALID" === S.status
                  ? _.onEmailVerificationSuccess()
                  : ((_.showCodeValidation = !0), _.statusCode.set(S.status ?? "WRONG"));
              })
              .catch(() => {
                (_.statusCode.set("WRONG"), (_.showCodeValidation = !0));
              }),
            (_.isLoading = !1))
          : (_.statusCode.set("WRONG"), (_.showCodeValidation = !0))
        : (_.statusCode.set("REQUIRED"), (_.showCodeValidation = !0)),
      _.changeDetectorRef.detectChanges());
  })();
}

Eventually, I found the following function, which calls the email verification callback.

At this point the bug became clear to me! Have you found it?

verificationCodeEntered(_, S) {
    if ("Shift" === this.lastKeyPressed) return;
    switch (S.key) {
      case "Control":
      case "Meta":
      case "Shift":
      case "v":
      case "r":
        return;
      case "Enter":
        return (S.preventDefault(), void this.emailVerificationCallback());
      case "Backspace":
        return (this.setCode(_, "", "backward"), void S.preventDefault());
      case "ArrowLeft":
      case "ArrowDown":
        return void this.goBackward(_);
      case "ArrowUp":
      case "ArrowRight":
      case "Tab":
        return void (_ !== this.codeLength - 1 && (this.goForward(_), S.preventDefault()));
    }
    S.preventDefault();
    const O = Number(S.key);
    isNaN(O) ? (this.getInput(_).value = "") : this.setCode(_, String(O));
  }

It appears that this function intercepts key presses and collects the verification code into a local JavaScript variable. So there was no chance to modify the input form in the DOM after the fact, one would have to find the JavaScript variable and inject it there!

The critical part is that modifier keys are rejected.

And my problem is… that I’m using an AZERTY standard French keyboard layout, where digits are only accessible behind the Shift key. In other words: blocking the Shift key means blocking digits.

Source: https://en.wikipedia.org/wiki/File:KB_France.svg, license: CC BY-SA 3.0.

It turns out that AZERTY is one of the few keyboard layouts in the world to have digits behind the Shift key. At work I’m using an English (QWERTY) keyboard layout, and none of the people I asked were French, so obviously among the tested computers only my two “broken” laptops were affected.

Source: https://en.wikipedia.org/wiki/File:KB_United_States.svg, license: CC BY-SA 3.0.

Switching the keyboard layout at the software level in my operating system indeed fixed the problem on my “broken” laptops, and conversely switching to a French keyboard layout on the “working” devices triggered the bug.

At this point you may wonder how come a Swiss app doesn’t work on a French keyboard: isn’t French one of the official languages in Switzerland? The answer is that the standard Swiss-French keyboard layout is of the QWERTZ family (common in Central Europe), to allow efficient typing in both French and German. Of course, digits don’t require pressing the Shift key with this layout.

Source: https://en.wikipedia.org/wiki/File:KB_Swiss.svg, license GFDL 1.2.

Still, there are about 171’000 residents of French nationality in Switzerland according to the Swiss Federal Statistical Office, not to mention cross-border workers that may have to interact with the Swiss government. So statistically speaking I’m surprised that this bug hasn’t been noticed and fixed yet!

Conclusion

After switching my keyboard layout, I could finally validate my email address, and register with a security key.

The weirdest part is that my actual identity was never verified in the process! I simply entered my name, phone number and date of birth in the form but these were never verified. The only things that the AGOV system validated is that (1) the email address exists and (2) the second factor is a security key from a model they allow or the AGOV Access app running on an Android or iOS device they allow.

This makes me question the threat model and overall usefulness of the AGOV system. AGOV is resilient against account take-over by remote phishing – which is certainly important for privacy reasons! However, nothing prevents someone else to create an account and put my name and other identity details there.

Upon further investigation, it seems that identity validation is required to access services deemed sensitive. So I just didn’t access a sensitive service yet.

I’ve reported the bug on the help form, but haven’t received any reply yet. Stay tuned!

Post-mortem

I think this incident deserves a little post-mortem, to hopefully avoid similar ones in the future.

What went poorly?

Making a fancy UI with 6 input fields and a complex JavaScript logic isn’t a resilient way to build a UI. Just use one native browser form field, and decorate it with CSS.
Completely decoupling the form logic from the DOM, rather than reading values from the DOM upon form submission. An advanced user (or a browser extension) cannot even edit the DOM after the fact because the JavaScript logic has already intercepted the key presses.
Having only one support channel. A second channel (email, phone, etc.) is best practice for resilience.
Using the same login logic for the main product and the support channel. By coupling both, you miss bug reports from users who can’t even login. There’s a reason why many providers of Internet services host their status page on a separate domain.
Gating support behind email verification. Maybe you get less spam, but you also get fewer reports from genuine users.
Not publishing the source code before the code is deployed and mandated by some systems. The legal requirement to provide the source code isn’t just a compliance checkbox, it’s actually useful for users to troubleshoot issues and socialize bug reports and work-arounds.

What went well?

The relevant JavaScript logic wasn’t obfuscated. In the end a few string searches were enough to identify the bug. No advanced decompiler, no expensive LLM required. It would have cost me waaay more time to figure it out if the logic was obfuscated or compiled in WebAssembly.
The relevant code was distributed on the open web, making it easy to download it (even though in minified form) and inspect it for troubleshooting. We may take this as a given, but it would have been more difficult to even access the code if it was distributed only for a few approved walled garden operating systems.

Where did I get lucky?

Having multiple laptops at hand with various keyboard layouts ruled out many hypotheses early on. A browser-specific or networking problem was unlikely. That said, it took me a while to gather evidence in the initial phase, as I methodically took screenshots of each browser combination to make sure it wasn’t a mistake of my part.

The example.com domain is reserved according to RFC 6761. ↩

Comments

To react to this blog post please check the Mastodon thread, the Lobste.rs thread and the Reddit thread.

RSS | Mastodon | GitHub

Query any HTML table with PRQL

Mon, 13 Jul 2026 19:17:18 +0000

Query any HTML table with PRQL

2026-07-08

Once again I find myself searching through a giant table on Wikipedia. And again I think: it would be so much better if I could just query it with SQL or something. Wish someone made a browser extension for that!..

Aaand now I did. Here is the source code: https://codeberg.org/aka_dude/tableq. And here you can get it for your Firefox. Except this uses PRQL because it is much better that SQL. Here is an example:

*Source (Wikipedia)*
File system	Block journaling	Metadata-only journaling	Case-sensitive	Case-preserving	File Change Log	XIP
APFS	?	?	Optional	Yes	?	?
NTFS	No	Yes (2000)	Yes	Yes	Yes	?
ext4	Yes	Yes	Yes, optional	Yes	No	Yes

The Q? button over upper-left corner activates the extension. Upon activation, column names are renamed to snake_case and a PRQL prompt appears. Try writing the following there and see what happens!

from t0
filter (file_change_log == 'Yes')

Note that the table still contains original HTML, e.g. the links are still there.

Some caveats:

The extension doesn’t do anything with column duplicates, so underlying DB (sqlite) will have a problem with that.
Since content is stored as HTML in the DB, operations over text will work with it, not rendered representation. This may lead to weird results when sorting or searching through rich text.

All caveats should (and maybe will) be taken care of, but current functionality is enough for me.

Today I Rescued 7,234 Old GIFs – Dan Q

Sun, 12 Jul 2026 08:32:27 +0000

This week, GlitchyZorua brought to my attention the Ibiblio Icon Browser, a collection of many thousands of GIF icons curated in the 1990s by Gioacchino La Vecchia. Glitchy’s goal was to archive a copy of all of the icons, which was turning out to be… challenging.

A more-90s website you’re unlikely to see today.

It looks pretty simple: (a) an index page, leading to (b) 24 sub-index pages, leading to (c) 57 icon directory pages, representing (d) 114 icon collections, containing anywhere up to (e) 7,296 icons, mostly but not always 32×32 pixels. Right?

But the challenge comes when you try to go from a directory page to an icon file. It looks like you’re clicking a link, but really you’re clicking… an imagemap.

I’ve talked about imagemaps before, but the essence of them is that you define areas of an image that, when clicked, hyperlink to different places. The most-common way of doing these was always client-side imagemaps, where the HTML code itself contained all of the coordinates and, crucially, the resulting destinations. But that’s not what kind of imagemap this is.

A server-side imagemap asks your browser to send the pixel coordinates that were clicked-on, as the query string. In the case of this server, that gets decoded server-side and you’re redirected based on where you clicked.

This one’s a server-side imagemap. The HTML code looks like this… and there are no URLs for the resulting library of GIF files anywhere to be seen:

Directory indexing is disabled, so we can’t just knock the image filename off the end of the URL and inspect. So how are we to get these images, short of manually, painstakingly, clicking on each one of them? That’s what GlitchyZorua was wondering when I turned up with some bright ideas…

(We’re clearly not the only people who struggled: archive.org hadn’t managed to collect a full set of the icons either.)

Fortunately, we can work out a little something about the gallery images. Exploration of the site shows that they’re always laid out in a grid of up to 8×8, with each (including its size information) occupying a space of 72×89 pixels:

A little experimentation shows that clicking anywhere within the intersection area results in a redirect to the same image.

The webserver seems to be running Apache, so it’s probably using something like mod_imagemaps to manage its server-side imagemaps. We can imagine that somewhere on the server there’s probably a file that looks a bit like this, mapping rectangular coordinate pairs to redirect URLs:

# icon3 images:
base destic3/
#    filename  |  top left  |  bottom right
# -------------+------------+----------------
rect 49ers.gif         0,0            72,89
rect 49ers1.gif       73,0           145,89
rect 4dos.2.gif      146,0           217,89
rect 4dos.gif        218,0           289,89
# ... and so on for all 64 images in this collection!

I sincerely hope that La Vecchia had some automated process that he used to produce the thousands of lines of configuration that he needed, and he didn’t write his files by hand!

We don’t have access to those configuration files, but we can infer what hit areas they might have. If each hit area is 72×89 pixels, we can hit the centre of the top-left one at 36×44 and then just keep adding on 72 and 89 pixels to permute the centrepoints of all the hit areas.

In pseudocode, what we’d need to do is:

For each library from 1 to 113,
- For each X coordinate from the set {36, 108, 180, 252, 324, 396, 468, 540}
  - For each Y coordinate from the set {44, 133, 222, 311, 400, 489, 578, 667}
    1. Generate a URL of the form:
      https://www.ibiblio.org/iconbin/imagemap/icon{library}?{x},{y}
    2. Make a HTTP HEAD request to that URL
    3. If you get a HTTP 302 (redirect) response code, record the resulting Location:

That gets us the URL of every one of the thousands of GIFs on the service. Next, we can use wget to download each of them. Sorted!

But we can do one better: once we’ve got all the icons, we can present them in a new website. One without server-side image maps, and with a working search. So that’s what I did. I hacked together a very basic static site generator using Ruby and ERB templates, that produces a gallery with pagination (mirroring the page numbers from the original), plus client-side search. And of course the whole repository can be cloned if you just want a copy of the icons for yourself:

I think my modernised version of this icon library is, while basic, a huge improvement upon the original… (thanks in large part to the advancement of Web technologies in the intervening years!).

Anyway: if you’d like to browse the library in its new form, it’s at ibiblio-icon-archive.danq.dev. It… looks its age, but at least now it’s accessible to the world and able to be archived for posterity.

The Proportional Web

Sun, 12 Jul 2026 08:32:27 +0000

The Proportional Web

Inspired by the The Elements of Typographic Style

Authored by Oskar Wickström. v0.1.0, licensed under MIT.

Foreword

Two summers ago, just before I started working at TigerBeetle, I picked up a new side project during downtime. I’ve always had a soft spot for CSS but I don’t know why; frankly, it’s weird, confusing, and infamously error-prone. It could be nostalgia from my early days of programming web applications. Whatever the cause, The Monospace Web was born out of that love, and it took off way harder than I ever thought it would, with many personal blogs and even application interfaces having adopted it.

So, here I am again, spending weekend spare hours in a form of meditative state writing CSS. This time, inspiration struck after reading Robert Bringhurst’s classic The Elements of Typographic Style. A challenge indeed, trying to implement the layout and typography of the book itself in the browser. Reckless, some might say! Surely the same rules don’t apply across print and web, where the latter cannot lean on a fixed page size, but has all the capabilities of a programmable platform. Perhaps, perhaps not. I’ve decided to publish regardless, and bid you to take from it what you will; if you find it pleasant or useful, that’s a wonder, and if not, that’s fine.

Consider this the spiritual and variable-width sequel of The Monospace Web, and equally open for reuse. I’m a sucker for Pandoc, and that’s what I’ve used to produce this HTML, but the stylesheet should work in many other settings with minor tweaks.

1 Foundations

Typography is the craft of endowing human language with a durable visual form.
Robert Bringhurst, The Elements of Typographic Style, 2nd edition, 2002

1.1 Typography

1.1.1 A single versatile font as the basis of the design

In this document and its design, I’m using two variants of the Alegreya font. The regular variant is used for body text and third-level headings. Its small-caps variant, Alegreya SC, is used for titling-caps top-level headings, small-caps second-level headings, and for inline abbreviations such as HTML. Finally, Courier Prime is used for monospace code snippets.

Bringhurst argues in his book for choosing a single versatile typeface rather than a hodgepodge of different ones. I think Alegreya is such a choice, and an excellent one at that.

1.1.2 A sizing system built on relative measurements

Every size is based on the root font size, which is 16px. Sizes are thus given in rem units, relative to the root font size. The following table shows how fractional, rem, and pixel measurements correlate.

Sizing everything based on the root font size makes it easy to scale the design, for instance on smaller viewports:

The line height is 1.2rem, and is used as the basis for vertical alignment of all elements. Much like in The Monospace Web — but not to the same extremes — I’ve tried to get everything globally aligned to multiples of the line height.

1.1.3 Justified text in modern browsers

As in Bringhurst’s book, body text is justified, not ragged right. To some, this is grave heresy on the web. Thou shalt not justify. That’s what we’ve all been taught. But browsers have improved over time and today it’s not unthinkable to justify text. This stylesheet uses word-break, text-wrap, and hyphens to control how words are broken and hyphenated at line breaks. The hyphenate-limit-chars property is useful to control the bounds of hyphenation.

The risk is of course getting horrible word spacing and rivers of whitespace in your paragraphs. If justified text doesn’t work for your uses, consider text-align: left instead. In this document I find that it works acceptably with the line lengths, font size, and the content itself. I’ve also inserted a few soft hyphens to further guide the word breaks for some tricky words.

1.1.4 Indented paragraphs for legibility

In keeping with tradition, each successive paragraph is indented 3ch, which is the width of three 0 (0x30) characters. As an example, the paragraph following this one leads with an indent.

This lets your eyes more easily scan the structure of the text and find the starts and ends of paragraphs. We’ve done this in print text for at least half a millennium, and while the web has largely settled on no indent and vertical space between paragraphs, it is still a valid approach.

1.2 Colors

You may have noticed that this design is devoid of color. It’s all black on white. Not only am I personally inclined towards this minimalism in prose-heavy documents, at least as a strong default that I depart from only with careful consideration, but it’s also what Bringhurst argues in his book, although with print media in mind. I find it aesthetically pleasing and easier on the eyes, and it reserves the arsenal of color, and thus the attention of the reader, for the most critical things, such as diagrams conveying complex data.

2 Elements

This document uses a few extra classes here and there, but mostly it’s just semantic HTML5 markup. This, for instance, is a regular paragraph. The examples below are indented for clarity; in normal use they’d span the full width of the text.

2.1 Headings

The design provides styles for three level of headings: top-level chapter headings (h1), section headings (h2), and sub-section headings (h3).

1 On the theory of war

1.2 Art or science of war

1.2.1 Usage still unsettled

2.2 Emphasis

There’s no surprise here; text in <em> tags is italicized, just as you’d expect:

Do you think I can stay to become nothing to you?

2.3 Horizontal line breaks

There’s no clear guidance on horizontal line breaks in Bringhurst’s book, but it seems to me like a good place for ornamentation. Here’s one:

The symbol used is U+2767 Rotated Floral Heart Bullet from the Unicode Dingbats block.

2.4 Details

We can hide stuff in the <details> element. Click the label below:

License

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

2.5 Asides

Bringhurst’s book uses plenty of side notes. In HTML we define those using <aside> elements. Along with this paragraph there’s a side note. With a large enough viewport, you’ll see it in the right margin, aligned with the top of the previous paragraph; with a smaller viewport, it’ll be collapsed into an inline paragraph with ornamentation.

2.6 Names

Proper nouns and canonical names, distinguished using the .canonical-name class, are rendered as small-caps much like in the example from Bringhurst’s book:

… on the islands of Lombok, Bali, Flores, Timor and Sulawesi, the same textiles …

2.7 Blockquotes

Bringhurst talks about various ways of typesetting quotations, and the one I landed on is using an indented block, quotation marks around the text, and a footer with author, work, and year.

Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte.
Blaise Pascal, Lettres Provinciales, letter XVI, 1657

2.8 Figures

Images with captions are put in <figure> and <figcaption> elements, respectively. Similar to blockquotes, author and work are styled specifically using small-caps and italic text, and they share the indentation.

Leonardo Da Vinci, Vitruvian Man, c. 1490, pen and watercolor over metalpoint on paper, 34.4 × 24.5 cm (photograph via Wikimedia Commons)

2.9 Lists

This is a plain old bulleted list:

Banana
Paper boat
Cucumber
Rocket

Ordered lists look pretty much as you’d expect:

Goals
Motivations
1. Intrinsic
2. Extrinsic
Second-order effects

2.10 Tables

Tabular data is presented with a strong table head, using small-caps labels and a border. Otherwise it’s very simple, relying only on spacing.

Name	Dimensions	Position
Boboli Obelisk	1.41m × 1.41m × 4.87m	43°45′50.78″N 11°15′3.34″E
Pyramid of Khafre	215.25m × 215.25m × 136.4m	29°58′34″N 31°07′51″E

2.11 Code Blocks

This design is geared towards prose, not code-heavy technical writing, but code blocks and inline code should read well nonetheless. The font choice of Courier Prime might feel a bit typewriter-nostalgic, but I find it goes very well with Alegreya and the overall feel I’m aiming for. Here’s some code from the stylesheet:

3 Usage

Immature poets imitate; mature poets steal.
T.S. Eliot, The Sacred Wood, 1920

3.1 Purpose

This design is meant for web documents comprised mainly of prose: books, journals, blogs, manuals, and the like. You might use this as a basis for your personal website, a specific project, or maybe a larger wiki. You probably don’t want it in a dynamic web application.

Copy or fork what you want, modify it to your heart’s content, but don’t forget proper attribution. The sources have license information in their headers, so it’s as easy as keeping those around.

3.2 Getting started

To get started quickly, download the sources from GitHub, put the directory in your project as the-proportional-web, and add these to the head element of your HTML:

If you’re using Pandoc, invoke it with some thing like the following set of arguments:

If you do need syntax highlighting, consider using a custom template like the one used for this HTML output, stripping away the default CSS included by Pandoc.

4 Related works

4.1 The Elements of Typographic Style Applied to the Web

The most closely related work that I know of is The Elements of Typographic Style Applied to the Web by Richard Rutter. It’s a website largely mirroring the structure of Bringhurst’s book, but adapting its advice to web design. It is much larger in scope and is seemingly focused on the information itself, while this document is a showcase of the ideas and of the stylesheet that is The Proportional Web. Furthermore, I had a hard time reading Rutter’s website on my phone, with font sizes varying drastically. From what I’ve gathered, it dates back at least 20 years, and seems to have had no updates in about 8 years. I have put a lot of effort into making this design responsive yet consistent across viewport sizes. In any case, I think it’s fair to say that they serve different purposes and can happily coexist.

4.2 Practical Typography

Matthew Butterick’s Practical Typography is a real workhorse, and goes into sufficient detail on just about everything a layman or typography-adjacent engineer, like myself, will ever need. I have come back to it many times over the years.

4.3 Tufte CSS

Tufte CSS deserves an honorable mention. From what I’ve seen, it’s had a big impact and recognition. There are small details around typesetting that I don’t like in it, but it’s overall a solid piece of work.

Afterword

There we have it, The Proportional Web. The methodology of Bringhurst’s book is rich and I highly recommend you read it. I’ve only scratched the surface in this exposition, and applied and adapted a small subset of his ideas.

This document was produced using Pandoc, html-minifier, esbuild, and GNU Make. The design borrows heavily, both in ideas and actual layout, from The Elements of Typographic Style by Robert Bringhurst. A big thanks to U.S. Graphics and Mikael Brockman for reviewing my drafts.

Headless Web

Sat, 11 Jul 2026 15:38:48 +0000

Headless Web bedeutet, dass Datenbasis, Content-Backend, visuelles Frontend und externe Schnittstellen entkoppelt geplant werden. Der Inhalt liegt nicht fest in einer einzelnen Website-Oberfläche, sondern kann über APIs in Website, App, Shop, mehrsprachige Landingpages, KI-lesbare Datenquellen oder einen Agentic Workflow ausgespielt werden. Für KMU ist Headless Web keine reine Technologiefrage, sondern eine Architekturentscheidung. In meiner Arbeit […]

Roastidio.us Tagged with web

95 reasons for having your own website in 2026 ~ Bell Kiosk

2026年前期 web-study 参加報告

#tpac_study

sakuさん「Drafting the Future of CSS」

Sajiさん「Ambition and Improvement in i18n」

#temporal_study

Sajiさん「It's "Time" to use Temporal」

ふぁぼんさん「webにとってTemporalとは何か」

#縦書き_study

#rich_text_editor_study

コサキンによる発表

#webfont_study

まとめ

MarkuplintでHTMLの品質を守る

はじめに

Markuplintとは

何をチェックしてくれるのか

ESLintのプラグインとの違い

導入と設定

まずは --init から

Parser と Spec の設定

対応しているフレームワーク

Reactで使う

コンポーネントをHTML要素として評価する（pretenders）

ルールのカスタマイズ

既存プロジェクトへの組み込み

カスタムルールで独自の規約をチェックする

kintoneでの活用

モノレポでハマったところ

まとめ

Workshop Basel day three

Why MOQ is going to replace HTTP live streaming

Reverse HTTP

Resumable uploads

io_uring vs. multithreaded server runtimes vs HTTP mismatch

Modern UDP I/O for Firefox in Rust

Rollout of Happy Eyeballs v3 in Firefox

Shorter ones

The end for this time

Credits

Workshop Basel day two

How AI is changing how HTTP is implemented.

Observations and Measurements of HTTP/2 During Large-Scale Web Crawls

HTTP/1.1 behavior divergence

Request smuggling test suite

Server performance & measurement

Increase and evolve HTTP/3 & QUIC

QMUX

Multiplexed proxying: challenges in H2 and H3

Making the Web QUICer with Rapid Start

Drinks and food

Workshop Basel day one | daniel.haxx.se

Extending REST for State synchronization

Last-Modified header use over time

How is HTTP used in the world?

AI-bots’ use of HTTP

The Apple HTTP stack two years later

Why new HTTP APIs?

Android Networking

Day one world problem solving

I like using scrollbars

The notification that gave up after a minute | jvalol

Guidelines for URL Storage and Comparison

Background

URL Encoding as Strings

Security Landmine: Inconsistent Client Support

URL Components

Making URLs Absolute: Combine

Deep Dive: Components

Component: Scheme

Security Considerations: Supported Scope

Security Considerations: Parsing changes by Scheme

Security Considerations: Not All Schemes are Routable

Security Considerations: The FILE Scheme is Weird

Component: Authority

Component: UserInfo

Security Considerations: UserInfo UI Spoofing

Component: Fully-qualified hostname

Security Considerations: Transport Security

まずは `--init` から