Reducing & Increasing XML’s Attack Surface; Slash Pages

The Friday Drop ended up turning into this (CB). I’ve been wanting to really learn Alpine.js for a while, so I used one of the resources (Web Awesome) from a recent Drop to see if I could build a full mini-app with it. I started off with what I think I know pretty well — Vanilla JS — and built said app as a single HTML file. I then scrolled through the Alpine.js docs and did an initial stab at migrating from Vanilla JS to some freaky homunculus of Vanilla JS and Alpine.js idioms, to a (I think) proper 100% Alpine.js implementation. Hopefully it’s helpful to some other folks.

Now, on to today’s Bonus Drop!

---

TL;DR

(This is an LLM/GPT-generated summary of today’s Drop using MLX LLM in OpenAI API compatibility mode, SmollM3-3B-8bit, and a custom prompt.)

• libxml2 (maintained by a single volunteer) is embedded in billions of devices, including those in Apple, Google, and Microsoft OSes. Sara Gooding’s post highlights the maintainer’s frustration with unpaid vulnerability triaging and the potential for coordinated disclosure to exacerbate security risks, as major tech companies profit from his work. (https://socket.dev/blog/libxml2-maintainer-ends-embargoed-vulnerability-reports)
• The WHATWG’s GitHub issue proposes removing XSLT from browsers, citing its obsolescence and security vulnerabilities. While opponents argue it breaks RSS feed styling, supporters see it as necessary technical debt cleanup. The debate highlights the tension between backward compatibility and security improvements, with browser vendors cautiously considering the removal. (https://github.com/whatwg/html/issues/11523)
• Slash Pages (slashpages.net) catalog common website pages like /now, /about, and /uses, serving as hallmarks of the IndieWeb movement. The concept allows users to share personal details and interests, but the user expresses concern about AI bots potentially stealing this content. (https://slashpages.net)

---

Reducing & Increasing XML’s Attack Surface (Part 1)

I monitor scads of RSS feeds, and it is a rare occurrence to see a post about XML. So, I was a bit surprised to see two fairly important ones this past week. It is more surprising that they were both about XML security. We’ll cover the “increasing” in this section and the “reducing” in the next.

libxml2 (GL) ships with billions of devices worldwide, despite being maintained by a single volunteer. The maintainer (Nick Wellnhofer) himself explains that “It all started when Apple made libxml2 a core component of all their OSes. Then Google followed suit, and now even Microsoft is using libxml2 in their OS outside of Edge.” It appears as a standard dependency in countless Docker images and cloud deployments, and a look at just the Alpine Linux package repository shows that libxml2 is required by 460 packages just in that single Linux distribution.

That’s a YUGE attack surface, which makes Sara Gooding’s post noting “libxml2 Maintainer Ends Embargoed Vulnerability Reports, Citing Unsustainable Burden” more essential than you might realize.

Nick volunteers his time to maintain this critical piece of infrastructure used in those billions of devices and has stated that he’s tired of spending hours each week triaging security reports without compensation while big tech companies profit from his work. Under the new policy, security issues will be treated like regular bugs. That means they will be made public immediately and fixed when the maintainer has time, with no deadlines. Wellnhofer sees coordinated disclosure as mostly benefiting large corporations while leaving volunteers to do unpaid work. He’s particularly frustrated with organizations like the OpenSSF and Linux Foundation, which he views as exclusive clubs that require expensive memberships while preaching best practices to volunteers. Nick also argues the aforementioned tech giants have avoided their responsibility for technical debt, refusing to either develop better alternatives, create their own solutions, or properly support the library they depend on.

Without coordinated disclosure, security researchers and attackers will have simultaneous access to vulnerability details. This eliminates the traditional grace period where vendors could patch systems before exploits become public knowledge, so even a brief window could result in massive exploitation campaigns.

Since libxml2 is embedded so deeply in operating systems and foundational software, a serious vulnerability could trigger a domino effect. Downstream vendors who previously relied on advance notice to prepare patches will now be caught off-guard, potentially leaving critical infrastructure, enterprise systems, and consumer devices vulnerable for extended periods.

I find it ironic that this policy change, born from legitimate frustration with an unsustainable volunteer model, could end up making the very security problems it seeks to highlight significantly worse in practice. It will be interesting to see how this plays out, since it almost has to force at least one of the larger tech companies to start supporting the library (or move on to more modern, safer alternatives).

---

Reducing & Increasing XML’s Attack Surface (Part 2)

While there was some bad news in the first section, this GitHub issue in the Web Hypertext Application Technology Working Group’s (WHATWG) html repo — “Should we remove XSLT from the web platform? · Issue #11523 · whatwg/html” — has the potential to reduce the attack surface of almost every popular web browser.

The discussion proposes removing XSLT (Extensible Stylesheet Language Transformations) from web browsers entirely, arguing that XSLT has become obsolete and poses security risks.

If you did not know that your browser can use XSLT style sheets to process and render XML content, you are not alone. I haven’t seen (though I have not really looked) much use of it, and I really didn’t want to spend time trying to find a decent example site, so you can hit up this hastily-crafted demo to see how it works.

The main arguments for removal center on XSLT’s declining relevance and security vulnerabilities. Browsers only support XSLT 1.0 from 1999, while the technology has evolved to versions 2.0 and 3.0. Modern web development has largely moved to JavaScript-based solutions for DOM manipulation, and the underlying C/C++ libraries that process XSLT are aging codebases prone to memory safety issues and receive less security attention than core browser components, yet they handle untrusted web content and have been sources of recent security exploits.

The opposition argues strongly against removal, particularly around RSS feed display. (TIL) Many podcast hosting companies and news organizations like the BBC use XSLT to make their RSS feeds human-readable when viewed directly in browsers. Critics point out that XSLT works without JavaScript enabled, making it more accessible than JS-based alternatives. They suggest updating to safer, more modern XSLT implementations rather than removing the feature entirely.

The debate became quite heated, with supporters seeing it as necessary technical debt cleanup and opponents viewing it as breaking existing functionality for marginal security gains. Browser vendors like WebKit and Firefox showed cautious support but want to coordinate the removal carefully, potentially starting with console warnings. The discussion was eventually locked due to becoming “too heated,” highlighting how contentious the proposal is within the web development community.

The core tension is between reducing browser attack surface versus maintaining backward compatibility for legitimate use cases, particularly RSS feed styling. It’s an intriguing argument, and I’m all for removing legacy code. The WASM proposals sound like the best alternative to me, but I also don’t code browsers for a living. This is definitely one conversation to watch, though.

---

Slash Pages

Slash Pages is a directory of common website pages that folks can add to their personal sites using standard URL patterns like /now, /about, or /uses. These pages are hallmarks of the IndieWeb movement and help describe the individual behind a website. The concept was independently coined by Caleb Hearth and Shellsharks, with this particular directory created by Robb Knight.

The site catalogs dozens of different “slash page” types, from basic ones like /about (personal information) and /contact (how to reach you) to more creative ones like /chipotle (your standard order), /hills (opinions you’ll defend), and /pfp (profile picture timeline). Each page type serves a specific purpose in you share aspects of your personality, interests, work setup, or life philosophy.

While the concept is fun and useful, I’m not sure I want to give the “AI” bots even more content to steal, especially content that helps to build out a profile of me.

---

FIN

Remember, you can follow and interact with the full text of The Daily Drop’s free posts on:

• 🐘 Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev
• 🦋 Bluesky via https://bsky.app/profile/dailydrop.hrbrmstr.dev.web.brid.gy

☮️