kafsemo.org

“If the jury can count higher than two, the case will fail.”

Hullo!

Browser XSLT going away

Friday, 6 November 2026 (#)

Following a Google proposal in 2025, XSLT is being removed from the web platform. As Mozilla say:

While it's important to not break existing web content, it's also important to prevent security vulnerabilities. XSLT has been in maintenance mode in browsers and has been an ongoing source of security issues.

I’m a little nostalgic for the xml-stylesheet processing instruction. At the same time, the frozen 1.0 version of XSLT ignores all the improvements in 2.0 and 3.0, leaving it fairly literally stuck in the ’90s.

Outside a reference in my modest proposal for XML+Data, I used it to present some RDF for a blog post.

Existing behaviour

Currently, a file served as data.rdf starts with:

<?xml-stylesheet type='text/xsl' href='data-presentation.xsl'?>

That means:

  1. A browser requesting the RDF file applies the transformation and presents it as HTML.
  2. For other clients, the underlying data is RDF/XML.

Preserving behaviour

I’d like to preserve this behaviour, ideally under the existing URL, with Apache. I created a type map that points to underlying files with an additional suffix:

URI: data.rdf.rdf
Content-type: application/rdf+xml

URI: data.rdf.html
Content-type: text/html

Serve that map under the existing URL:

RewriteRule ^data.rdf$ data.rdf.var

and process the file server-side so there’s an HTML version:

xsltproc data-presentation.xsl data.rdf >data.rdf.html

Now:

  1. A browser requesting that URL will announce that it prefers HTML and get the HTML version.
  2. A client that prefers RDF/XML, or has no opinion, will get the RDF.

Ironically, the graphical representation of the data is more interesting.

(Music: The Hives, “Bogus Operandi”)

Feeds migrating to https

Friday, 12 September 2025 (#)

Way back in 2013, post-Snowden, moving general web traffic to TLS became an increasingly good idea, then a norm.

A common practice (but not a requirement) is to give insecure requests a 301 Moved Permanently from http over to https. This let user agents update their stored URL and make subsequent requests over a secure channel. If that initial request is compromised then all bets are still off, but TOFU is often a good trade-off.

The simple polling script I use for subscribed feeds uses exactly that logic: any chain of permanent redirections is persisted. Looking back, across all feeds, what did that migration from http to https look like?

An area chart showing http feeds being replaced by https

Initial adoption was slow. It was 2009 before I had an https subscription, when http://labs.mozilla.com/feed/ (now a 404) redirected to https://mozillalabs.com/feed/ (now an SSL_ERROR_BAD_CERT_DOMAIN). Mid-2016, https reached 5% of my subscriptions. That’s right after Let’s Encrypt officially launched.

In 2019 the ratio was 50-50, and it continued to increase to around 80% currently. Ironically, older feeds dropping off the web completely rather than switching still helped that ratio. Still, 20% plaintext is not great, so I took a look at the remaining holdouts.

A few were using a temporary redirection, with 302 Found:

the client ought to continue to use the target URI for future requests.

and indeed I did, fetching the original insecure resource each time.

Others were sending an Upgrade header:

Upgrade: h2
Connection: Upgrade

I could make a secure h2 connection; but the library I’m using needs changes for that.

Some other feeds were dead enough that it was time to unsubscribe.

With those migrated across manually, I’m at 96% https. Holdouts? Almost exclusively sites that aren’t actively being maintained. It’s always fun to see a feed spring back to life, even if it’s currently:

<updated>2022-03-17T05:00:46Z</updated>

or even:

<pubDate>Sun, 09 Mar 2014 00:00:00 PST</pubDate>

so I’ll poll until they 410.

(Music: Blonde Redhead, “Sit Down for Dinner (Part 2)”)

Trade-Markov Chains

Monday, 8 September 2025 (#)

Apple®’s branded house model shares much structure across its trademarks. Terms repeat, and patterns reoccur. It’s structured enough to be tokenised by splitting on transitions from lowercase to uppercase, or white space:

iPad Air® ⇒ ["i", "Pad", " ", "Air", "®"]

MacBook Air® ⇒ ["Mac", "Book", " ", "Air", "®"]

There are a few exceptions like ‘X’, which is its own token in e.g. Xserve® and Xcode®.

Breaking out the tokens lets us see that case is mostly consistent. Exceptions include ‘Mac’, ‘TV’, ‘Vision’ and ‘Watch’ (uppercase for hardware, and lowercase when followed by ‘OS’), and ‘Touch’ (uppercase except in ‘iPod touch®’). Also good to see ‘+’ rapidly overtaking ‘.’ and ‘-’ as the most common punctuation.

The natural thing to do is place these on a graph, where each distinct token is a node linked to all tokens that appear before or after:

A graph of all Apple trademarks showing all links between tokens

Notably, some tokens see broad use (‘Apple’ and ‘i’ in around fifty trademarks each, and ‘Mac’, ‘Pro’, ‘Air’ in around twenty), whereas some are used in small clusters (three ‘Engine’s and ‘Drop’s; three ‘Writer’s, all printers).

Weight the transitions according to current trademark usage to generate a Markov chain. Start on a token that’s used to start at least one trademark, and finish on one that ends. The resulting chains will, usefully, predict unused trademarks; including:

Following the existing structure means a few sound more “when” than “if.”

(Music: The Hives, “These Spectacles Reveal the Nostalgics”)
Joseph Walton <joe@kafsemo.org>