Shellsharks Blogroll - BlogFlock

How I Develop Pure Commons Apps - Kev Quirk

2026-09-25T13:45:00.000Z

A couple¹ of people have asked what my process is for developing the various Pure Commons apps. This comes after I've mentioned a couple of times that I've released a feature I've been working on for months.

So I thought I'd write a quick post that explains how I do it, so I can refer people to it if/when they ask in the future. I also find this kind of post interesting, so I'm hoping you do too. If not, feel free to skip this one. 🙃

Using Git without branches

Git is a staple in my development workflow, so you'd think I'd use it the same way most other developers do, but I don't. You see dear reader, I'm a visual learner, so branches in Git are confusing to me as they're abstracted away inside the .git folder. This means I often forget which branch I'm on. Which in turn has led to all kinds of issues over the years when it comes to committing shit to the wrong branch.

So instead I simply copy and paste the entire repo (less the .git folder) into a new subfolder and use that as a "branch". Then, when I want to work on a feature, I go into that subfolder and work away, knowing it's completely separate from the core production code. My "branches" look something like this:

I always prefix my branch folders with AA-BRANCH so they're always at the start of my folder tree and easy to see. Switching branches is then just a simple cd away and I can easily see which one I'm in from the command prompt.

And since there's no .git folder in the branch, I can't accidentally mess things up by merging back to main (or any other branch) accidentally.

Almost ~~idiot~~ Kev proof!

Creating branches with purectl

I've created a local Python tool called purectl² which manages all things Pure. With it, I can do things like pull or push to/from remote for this website, update if there's a new version released, create releases, run local tests, create branches etc.

So if I want to create a new branch, all I need to do is run:

purectl branch pureblog

It will then ask me for the branch name, so I enter something like Pages in search and it will automagically create a new folder called AA-BRANCH Pages in search and copy the latest version of Pure Blog into that folder, excluding .git.

Merging changes

This is where things get interesting. If I'm working on multiple branches at the same time, merging back can be...interesting as I can't use the git merge command, since I'm not using Git for branches.

But that's fine, I actually prefer it this way as I have more control. Merging back to main requires me to do a side-by-side comparison of any files I've changes on that branch, so I have to review everything before manually while merging in changes.

This is definitely not the most efficient way of developing software, but it works for me.

Final thoughts

So there you go, that's my approach to developing the Pure Commons apps. I think it's somewhat scalable for a single person project, such as Pure Commons. If I were working in a team this approach would fall apart quickly though. Lucky I have no friends, ey!

I'm not a professional software developer, and I think that's clear from the way I manage all this. But this system has been working well for me, and is far less abstract for my monkey brain than Git's native branch handling.

What can I say, I'm a Luddite. 🤷🏻‍♂️

Literally 2 people, but that's enough to warrant a post, right? ↩
Short for "Pure Control". ↩

Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️

You can reply to this post by email, or leave a comment.

Don't let TEEs break your MPC - Trail of Bits Blog

2026-09-25T11:00:00.000Z

Threshold signature schemes, a form of multi-party computation (MPC) that lets a set of parties sign together without any one of them holding the key, are increasingly deployed inside trusted execution environments (TEEs). The combination is intended to amplify security for sensitive computations: MPC distributes trust across multiple independent parties, while TEEs root trust in the hardware manufacturer and its attestation infrastructure. But subtle issues can arise when running an MPC protocol inside a TEE without accounting for the untrusted host: for example, a malicious host could roll back the filesystem state after a threshold signer deletes a used pre-signature, causing the signer to reuse their nonce share and disclose their private key share.

So is this combination worth it? Provided you treat the TEE as a defense-in-depth layer rather than a substitute for a sound protocol, the answer is yes. This blog post discusses what TEE attestation can and can’t fix in MPC deployments, explores the pitfalls we see most often in audits, and covers best practices, such as incorporating strong attestation processes and binding them to the MPC parties’ identities.

MPC: Security that depends on participant behavior

Before diving into how TEEs and MPC interact, we need to understand what MPC means and what security guarantees it offers. MPC is a cryptographic technique that allows multiple parties to jointly compute a function over their private inputs without revealing those inputs to each other.

The security of MPC protocols depends critically on assumptions about participant behavior. The cryptographic literature uses two primary security models:

Semi-honest (honest-but-curious) security: In this model, all participants follow the protocol exactly as specified, but they may try to learn additional information from the messages they receive during the protocol execution. Participants can try to learn more than they should, but they don’t deviate from the protocol specification.

Malicious security: This stronger model assumes participants may deviate arbitrarily from the protocol. A malicious participant might send incorrectly computed values, use wrong inputs, abort the protocol at strategic moments, and behave in ways designed to compromise security or learn private information.

This distinction is important in the context of TEEs. If a TEE attestation can cryptographically guarantee that all parties are running the correct protocol implementation, it effectively elevates semi-honest protocols to provide malicious security guarantees (at least against certain classes of attacks, as we’ll discuss later). But before delving into the details, let’s discuss how TEEs work.

TEEs: Three core security guarantees

TEEs are secure areas within a processor that provide hardware-based protection for code and data, even from privileged software like operating systems or hypervisors. TEEs offer three core security guarantees:

Confidentiality: Data and code are encrypted in memory and accessible only from within the TEE. This ensures that even privileged system software cannot inspect the contents of the secure computation.

Integrity: The data and code are protected from tampering. Any attempt to modify the TEE’s memory or execution state from outside should be detected.

Attestation: Remote parties can cryptographically verify what code is running in the TEE. This allows external verifiers to gain assurance about the computation being performed and the legitimacy of the TEE without trusting the host system.

This last property is particularly crucial for building distributed systems with TEEs.

How TEE attestation works

The attestation mechanism is at the heart of TEE security. When a TEE is manufactured, it’s provisioned with a private key and a corresponding certificate that chains back to a root certificate held by a trust anchor (typically the manufacturer).

When an attestation is requested, the TEE takes measurements (cryptographic hashes of the TEE software, configuration, and hardware state). These measurements are bundled into a “quote” (a manifest of these cryptographic hashes), which the TEE then signs with its private key.

To verify these attestations, a number of checks need to be performed. However, the checks necessary in the verification process aren’t uniformly defined and are somewhat vendor-specific. For instance, Intel’s TDX documentation states:

TD Quote Verification is the process by which a TD Quote is verified in a remote attestation flow. This verification can be done by any party and the checks performed are defined by this party.

This places significant responsibility on developers, who might not fully understand what checks are required to ensure the security of the TEE deployment.

At a minimum, a proper verification process requires:

Verifying the quote signature
Verifying the certificate chain back to the trusted root
Verifying the actual measurements against known-good values (often stored in binary transparency logs)

This means deploying TEE-based systems involves not just cryptographic verification but also reproducible builds and binary transparency infrastructure. The measurements in the attestation quote are simply hashes; they don’t inherently indicate whether the code is correct or malicious. To verify that the TEE is running the intended software, what is required is a trusted source of reference measurements. Reproducible builds ensure that anyone can compile the same source code and arrive at identical binaries (and thus identical measurements). Binary transparency logs provide a tamper-evident record of what measurements correspond to what software versions, allowing verifiers to check that the TEE is running legitimate, audited code rather than a compromised variant. This piece is often overlooked in TEE deployments.

The trust model clash

Here’s where things get interesting. Multi-party computation is fundamentally about distributing trust among multiple participants. No single party should be able to compromise the computation. TEEs, in contrast, centralize trust in the hardware manufacturer that controls the root certificate.

Another important threat model shift to consider is the fundamental inversion of traditional security assumptions in TEEs. Historically, we trusted the host operating system and built our security models on that foundation. TEEs flip this on its head: they’re virtualized environments where the guest (the code running inside the TEE) is trusted, but the host system is explicitly considered untrusted and potentially malicious.

This shift creates new attack surfaces that didn’t exist in traditional computing models. While the TEE protects the guest environment from the host, the host still controls critical operations like I/O, memory management, and CPU scheduling. The host can deny service, manipulate timing, or attempt rollback attacks, leading to subtle breaks of MPC protocols.

Figure 1: Decentralized vs. centralized trust model shift

What TEEs can (and can’t) fix in MPC deployments

Combining these technologies can be beneficial, but one must be careful about the security claims that can be made. The security gains are real only if the TEE implementation is sound and the attestation process verifies the right properties. When TEEs attest to incomplete measurements or fail to verify critical components, the attestation provides false assurance. The actual security posture may even be weakened by the added complexity.

In an attempt to narrow down what TEEs can fix in MPC implementations, we’ve identified the common categories of MPC issues we frequently encounter in security audits:

Ambiguous encoding in hash functions (e.g., “YOLO” is not a valid hash construction)
Misbehaving participants
Missing parameters in Fiat-Shamir transforms (e.g., Coordinated disclosure of vulnerabilities affecting Girault, Bulletproofs, and PlonK)
Missing input validation (e.g., Breaking the shared key in threshold signature schemes)
Side-channel attacks
Protocol-level issues (e.g., Friends don’t let friends reuse IVs)

Arguably, if TEEs were perfectly secure, they could effectively mitigate the first four categories. When attestation and measurement processes are correctly implemented, each party gains cryptographic assurance about what code the other parties are running. This is powerful: if a party can verify that all other participants are running the exact protocol implementation expected (with no modifications or protocol deviations), then they know other participants will follow the protocol correctly and won’t misbehave by sending malformed messages. Essentially, correct attestation eliminates entire classes of implementation vulnerabilities by ensuring protocol compliance on both the sender and receiver sides. However, perfect security doesn’t exist in practice. Real-world TEE implementations have vulnerabilities, attestation processes can be incomplete or incorrectly verified, and the adversarial host environment introduces attack surfaces that are not traditional to MPC deployments.

A cautionary tale: Rollback attacks with threshold signatures in TEEs

Consider threshold signature schemes, which often use pre-signature optimizations. In Schnorr or ECDSA threshold signatures, participants can precompute nonce commitments independently of the message, speeding up the online signing phase. These precomputed nonce commitments are called pre-signatures, and the reuse of a pre-signature value by a participant leads to the leak of their private share (akin to how nonce reuse in traditional Schnorr and ECDSA signatures leads to private key recovery).

It might be tempting to run such an MPC protocol inside a TEE enclave to mitigate these types of attacks. But subtle issues can arise. In some implementations, signers store pre-signatures to disk and delete them after use (to limit the possibility of reuse). If that application were deployed to a TEE in a trust model where the host is potentially malicious, the host could roll back the filesystem state after the signer deletes a pre-signature file. When the TEE later fetches the pre-signature contained in that file, the signer essentially reuses their nonce share, which leads to a disclosure of the private key share. This is also discussed in the blog post A trail of flipping bits.

Common TEE pitfalls

Beyond the rollback issue, several other pitfalls frequently appear:

Incomplete attestation measurements: The security of TEE attestation hinges on measuring the right things. An attestation quote contains hashes of code and data, but project developers determine what gets measured and what gets excluded. If critical components aren’t included in the measurements, an attacker can modify those components without detection. This is particularly risky because the attestation appears cryptographically valid, but it’s attesting to an incomplete picture of the execution environment. For example, installing tools in an enclave from remote sources at runtime (e.g., using curl) pulls in code that was never measured; an attacker gaining access to that source can substitute their own and gain code execution inside the enclave.

A real-world example demonstrates this risk: a vulnerability in Meta’s WhatsApp Private Inference revealed that the attestation process didn’t include certain configuration files, enabling an attacker to inject malicious shared libraries with the LD_PRELOAD environment variable, potentially compromising the TEE while maintaining a valid attestation quote.

Missing verifications: The attestation process requires multiple verification steps, each critical to the security guarantee. Verifiers must check the quote signature, validate the certificate chain back to the manufacturer’s root certificate, confirm that the measurements match expected values, etc. Skipping any of these steps breaks the security model. Because verification procedures vary across TEE vendors and aren’t always well-documented, implementations sometimes omit crucial checks.

Lack of hardening: A TEE protects whatever runs inside it, including components that may not be needed. Redundant kernel drivers, overly permissive kernel config flags, stray ACPI table entries, unnecessary systemd services and timers, and weak entropy sources all increase the attack surface inside the trust boundary. Trim the image down to what the project requires, harden what remains, and measure it. For platform-specific guidance, see our notes on the AWS Nitro Enclaves attack surface.

Data availability and backups: Enclaves have limited persistent storage, so backups and recovery data typically live outside the trust boundary. Authenticated encryption provides confidentiality and integrity but not freshness, so a malicious host can serve a stale backup to force a rollback, as discussed earlier in our threshold signature example. More concretely, one recurring failure is a guest trusting attacker-controlled metadata that lives on disk: the disclosure of several vulnerabilities in LUKS2 disk encryption for confidential VMs shows that a malleable, unvalidated LUKS2 header lets an attacker with disk write access swap in a null cipher, leaving the guest reading and writing secrets on an effectively unencrypted volume.

Side-channel and physical attacks: Because the untrusted host controls the TEE’s execution environment, it can perform various side-channel attacks to extract information about the guest’s computation. These can leak sensitive information and break a TEE’s confidentiality guarantees. Similarly, researchers regularly publish physical attacks on TEE hardware. For example, the recent “TEE fail” attack allows an attacker to break the security guarantees of Intel TDX and AMD SEV-SNP by using a memory interposition device that lets them physically inspect all memory traffic inside a DDR5 server. The more recent DDRop attack goes even further: an interposer costing under $200 silently drops DDR5 writes, so the processor keeps reading stale data that still decrypts correctly, breaking the integrity of Intel TDX, Scalable SGX, and AMD SEV-SNP. Memory encryption without freshness fails the same way disk state does in the rollback example above.

Centralization risks: When MPC aims to distribute trust but TEEs centralize it in the manufacturer and its attestation infrastructure, the security goals of the protocol may be undermined. If all parties in an MPC protocol run their TEE nodes on the same TEE vendor’s hardware or if they use the same cloud provider, trust becomes centralized in that provider (for example, by way of the attestation chaining back to that vendor-operated root of trust).

Insecure defaults: Be aware of some of the limitations that vendor-provided verification tools have. For example, Intel tools allow known-vulnerable firmware versions to pass the remote attestation process for one year after public disclosure. Users might want to implement their own security version number validation on top of the defaults to enforce stricter deadlines.

Best practices for combining TEEs and MPC

If you’re building systems that combine these technologies, consider these recommendations:

Implement strong attestation processes: Bind attestations to the identities of MPC parties and verify them comprehensively. This means not just checking that an attestation is valid but also confirming that the specific party you expect to be running the code is actually the one presenting the attestation.

Terminate peer-to-peer communications inside TEEs: This provides end-to-end protection for party communications. By establishing TLS or other encrypted channels directly between TEEs (with endpoints inside the secure enclaves), you prevent the untrusted host from observing or tampering with protocol messages.

Perform comprehensive verification of the attestation and measurements: Refer to your specific TEE vendor’s documentation for the necessary checks to be performed, and ensure every verification step is implemented correctly, tested, and reviewed.

Write constant-time code: This helps prevent timing side-channel attacks. Even within a TEE, timing variations in your cryptographic operations can leak information to a host performing careful measurements. Use constant-time implementations for all security-critical operations processing secrets.

Consult vendor-specific guidance: Each TEE platform has unique characteristics, limitations, and recommended practices. Vendor documentation often includes details about platform-specific threats. Stay current with security advisories and updates, as TEE security is an active research area with new vulnerabilities regularly discovered. Follow best practices documentation, like our guidance for AWS Nitro Enclaves.

Use multiple TEE vendors: For defense in depth, consider running MPC protocols on TEEs from different manufacturers (and/or cloud providers) to avoid centralizing trust in a single vendor. While admittedly challenging in practice since it requires additional operational complexity, this diversity can be essential for high-security applications where trust distribution is critical.

Layered trust beats either layer alone

Combining MPC and TEEs is not automatic security, but when done correctly, it represents a defense-in-depth strategy that’s stronger than either technology alone. TEEs can effectively mitigate several categories of MPC vulnerabilities by cryptographically guaranteeing correct protocol execution. Meanwhile, MPC’s distributed trust model reduces the impact of TEE manufacturer centralization and may provide security even if individual TEE instances are compromised.

However, this benefit only materializes when both layers are correctly implemented. New vulnerabilities can emerge from their interaction, as we saw with the rollback attack example. Successful deployment requires following established best practices, implementing thorough attestation verification, and carefully reviewing the implementation and deployment procedure.

The intersection of these technologies represents the cutting edge of secure computation, but only if we approach it with a clear understanding of the tradeoffs involved. If you’re deploying MPC on TEEs, our cryptography team reviews these exact systems, so get in touch!

When a blogpost eats another - Joel's Log Files

2026-09-25T02:42:07.000Z

I was halfway through writing a pretty interesting blogpost today. Some thoughts about all the science fiction films I’ve watched this year! It’s seriously so much I realized I should probably save it for the end of the year.

Why you ask? Well, because I can literally make a recap of only sci-fi movies, and a recap of other movies if I want to, and all I have to do is wait for the end of the year.

I’ll definitely save the writing I already did, and probably use some of it for this month’s recap as well.

(If you’re curious about it, this month I have watched The War of the Worlds—awesome and terrifying—, Mercy—pretty meh—, The Day The Earth Stood Still—absolute masterpiece—, and I’m halfway through Minority Report—which is looking great.)

(As another aside, let me know if what I just did with those commas and em dashes is stylistically correct or whatever, I thought it looked kinda neat and I have read a couple books that have used that weird em-dash+comma thing. If you have to know, yes, I am stealing the whole paragraph inside a parenthesis idea from the Murderbot novels. Also is the last dot supposed to go inside or outside the parenthesis? I don’t wanna skim through the novel to check.)

In any case, I think this thing where you start writing something only to realize it should probably be something bigger (or maybe smaller, sometimes) can happen in plenty of situations, and I wonder how much does it take for some people to realize this! The treshold is different for everyone I guess.

For example, I have plenty of posts on a series titled “What Interested Me Today”—which is yet to have an actual category or special index for it—and I’ve thought about stealing some other formats from some fellow bloggers, when my weeknotes aren’t enough and I simply have short thoughts to say.

Perhaps a quick and random list of thoughts is fun, like what Loura did just now as I was writing this post. Or like Steve’s thoughts of the day, which is a fantastic little series that I always peek through to see what’s up with the guy.

But well, maybe I should just write my thoughts on those sci-fi films already, gushing about movies is something I rarely do, after all.

For now, you’ll have to settle with a ramble, bye!

This is day 42 of #100DaysToOffload

Reply to this post via email | Reply on Fediverse

New music morning - James' Coffee Blog

2026-09-25T00:00:00.000Z

7:00. Wake up. I recall. Taylor Swift’s new music is out today. I proceed to listen to all four new songs while still in bed, looking up to the ceiling and the sky and toward my cool, warm pillow, eager to do nothing else but appreciate the music.

I am sure there will be more to analyse in the songs in the coming hours and days when I have listened to – and read about them – more, but what mattered most to me this morning was spending time with the music. I listened to the new songs once, then got up and made breakfast, listening again while I did. Each song – Patient Zero, Cleveland!, Pink Clouding, and Babylon – is terrific. I have listened to them many more times since.

The opening notes of Patient Zero make me think vaguely that I am somewhere out in the Scottish countryside, about to hear country music, until the first notes come in and the song becomes something new. Cleveland! makes me want to dance. Pink Clouding makes me wonder. What does that mean? The magenta sunrise.

And then there’s Babylon, in which there is one lyric that reminds me of one of the attributes of Swift’s music I appreciate most: her lyricism. On a months-long journey reflecting on what home means to me – one defined by writing and conversations and spending time in different anchors of home – the lyrics “The self-harm of never being where you are.” stood out, coming days after I wrote “Here is where I want to be”, at least right now, being with the red trees of autumn and dreaming of the lavender skies of winter.

When I looked at the Taylor Swift Sub-Reddit this morning, I saw someone had already made a mashup between Patient Zero and The Black Dog, the latter from The Tortured Poets Department. I immediately understood the impulse to go to a musical instrument after hearing a new song, seeing if you can play along with the melody. I too felt the urge to go to my piano and start playing. I love how music can connect us in ways where no words need to be said – where we do the same thing – listen, play, chat, analyse – because we want to spend time with and feel the music.

Here is where I want to be mashup between Patient Zero and The Black Dog

Some thoughts on HTML's proposed previewsrc attribute - Terence Eden’s Blog

2026-09-24T11:34:54.000Z

One of the great things about modern HTML is that it tries to standardise stuff that developers are already doing. If there are a myriad ways of, for example, loading video onto a page - then browsers and other interested parties should work out how to make a standard element.

An interesting new proposal has been brought forth by Microsoft. There are a dozen ways to show a preview of an element before the src= attribute has loaded. So why not standardise on previewsrc=? There's an excellent explainer on Patrick Brosset's blog.

I instinctively like the idea - if only to simplify source code and reduce JS usage. But I do have some concerns which I've shared with the team.

What's The User Need?

This is the thing I always bang on about when I'm discussing standards. Additions to HTML should primarily benefit end users, not developers.

Do end users want this? Is there a bunch of research that shows normal people are confused that they don't see a preview image? Do they recoil in fear and distress while waiting for a full resolution picture to appear?

When people see a blurry or blocky image, do they understand that they need to wait for the full thing - or do they assume their computer is broken?

Microsoft has a bazillion dollars - it can afford to spend a few thousand on interviewing some real users and mapping out what they're likely to want from this.

What's The Developer Need

I begrudgingly admit that developers need love too.

What are the pain points of the current implementations? Is it hard to dynamically generate multiple images? Is the syntax hard to use? Do blurs slow down the page?

Again, MS needs to pony up some cash to talk to developers. At the very least run a survey of all existing websites in the BING! database and see what they use.

Alt Text

When an image doesn't load, or loads slowly, a user will normally be shown some alt text - like this:

Is that more or less useful than this?

Accessibility isn't just for people with visual impairments! This is an issue I've raised with them.

Naming Things Is Hard

I've written before about the usability of HTML elements. Some of the newer ones like have very poorly named attributes in my opinion.

One alternative for previewsrc is poster. That would match with the poster attribute on the element. They both show a preview image before the main content is loaded.

Given their functionality is identical, I think it makes sense for them to have the same name. You wouldn't expect to see would you? No. That's why they use the same width and height attributes as images.

Closing Remarks

There are several interesting objections and discussions on the GitHub repo. I'm delighted that this is being talked about in the open, rather than just being presented as a fait accompli (remember the toast proposal?).

As I said, I genuinely think that there's a useful idea in here. But after writing all of this, I think it would be better and simpler for developers to use progressive images rather than overload HTML with a new attribute.

If website owners can't be bothered to save progressive images, I don't see why they'd bother to create a separate preview image.

Keeping preview images in sync with their full images is also likely to be a problem.

If you think I'm wrong, read the explainer and then chat with Microsoft.

Things tip: moving items to headings - Johnny.Decimal

2026-09-24T04:55:49.000Z

I'll Bold and Capitalise Things features for clarity.

Quick tip for the Things users. Let's say you have a Project named 21 Products and in there a Heading named 21.35 JDHQ. Which I do. (The names aren't important; substitute your own.)

I use Things' lovely Move… feature to flick items from my Inbox to these Headings. I prefer to use the number, because I know it and it's faster. My ideal workflow is:

When processing the item, press Shift-Cmd-M for Move.
Type 21.35, which matches a Heading inside a Project.
Press return.

The problem is I've created work packages whose number contains 21.25. Things will prefer matching a number in a Project and if it finds one, it won't offer you the number even if it matches a Heading.

Figure 0252A. Things won't ever offer '21.35 JDHQ' as it's a Heading, and the Projects matches that are shown here override it.

Stack your searches

The solution is deceptively simple: just use a more specific search.

If you use 21 21.35 it seems to understand that I want to search in Project 21 for Heading 21.35. And that's exactly what I want.

Figure 0252B. Of course it was this simple. ❤️ Things.

If you're interested in how I manage my life using Things – it drives everything that I do – take the 5-hour Task and Project Management course, available with Pro memberships and higher.

Eight years, and done - Kev Quirk

2026-09-23T21:48:00.000Z

Eight years, and done

by Bryce Wray

A departure post from Bryce where he talk about his exit from blogging and his motivations for doing so.

Read post ➡

It's always sad to read these kind of posts. Yet another blog has fallen by the wayside, but I understand Bryce's rationale.

I've been quietly following his blog for a few years now, so I'll be sad to see him gone from my feed.

Bryce, if you're reading this, all the best and thanks for many great reads.

Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️

You can reply to this post by email, or leave a comment.

2026-09-23 07:34: Got home around midnight. I have concussion and a couple stitches in my head, but... - Kev Quirk

2026-09-23T06:34:00.000Z

Got home around midnight. I have concussion and a couple stitches in my head, but nothing serious. Few other cuts and bruises too.

By far the worst part is my back though - it's in spasm and REALLY painful.

Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️

You can reply to this post by email, or leave a comment.

Note published on September 23, 2026 at 12:01 AM UTC - Molly White's activity feed

2026-09-23T00:01:50.000Z

Binance has just filed to dismiss with prejudice its defamation lawsuit against the Wall Street Journal, which it filed in March after the Journal published various reports about a possible DOJ investigation into Binance over violations of sanctions against Iran.

Interesting timing, given Bloomberg just today confirmed such a probe is open and being handled by the SDNY DOJ’s office.

2026-09-22 21:37: Soooo I managed to drive our mower off a 5 foot wall and land on... - Kev Quirk

2026-09-22T20:37:00.000Z

Soooo I managed to drive our mower off a 5 foot wall and land on my head. Just waiting for a CT now.

Gonna be a long night...

Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️

You can reply to this post by email, or leave a comment.

Trump TV is the only source of footage of the President. That may be exactly what he wants. - Werd I/O

2026-09-22T16:56:05.000Z

Link: Trump TV Draws Ire Amid White House Press Shutout: 'State-Run Media', by Casey Loving in The Wrap

It’s not an accident that Trump’s move to ban CNN, MS NOW and Politico from the White House and, the same week, start his own friendly streaming channel happened just before the midterm elections. As The Wrap reported:

“The White House posted [a] message on X on Monday to announce Trump TV, a 24/7 livestream of ‘top past moments, announcements and the latest and greatest from the administration all in one place.’ While the Trump administration and members of the political right are calling this feed a win, others have different words for it: ‘state-run media.’”

It’s more than that: calling it “state-run media” would be pulling our punches. It’s a fully fledged propaganda network. If it had been established with press access to the White House fully functioning, it would have floundered as yet another half-assed also-ran attempt by the Presidency; without a fully functioning press pool, newsrooms are likely to turn to it to inform their coverage.

And the press pool is in trouble. Fox, ABC, CBS, and NBC subsequently pulled out of pooled TV coverage of White House events in solidarity. This is good to see, but in some ways it may also be what Trump wants: his channel then becomes the main source of footage from the President’s own events. In a normal world where the norms of American democracy were seen as worth preserving, the White House would back down. In a world where the country is being deliberately dragged into authoritarianism, it may not.

A First Amendment lawsuit seeks to reinstate the banned newsrooms’ access. Hopefully, it will succeed. In the meantime, Trump may still get eyes on a content channel his administration wholly owns, which broadcasts the Trump message without context or scrutiny, as he aims to take the country down a road it may not be able to easily return from.

Read "The FBI Anti-Corruption Squad Was Circling Susan Collins — Until Trump Got in the Way" - Molly White's activity feed

2026-09-22T13:56:45.000Z

Read:

“The FBI Anti-Corruption Squad Was Circling Susan Collins — Until Trump Got in the Way”.

William Turton, Avi Asher-Schapiro, Molly Redden and Kirsten Berg in ProPublica. Published September 22, 2026.

After the Corner Bakery meeting, Navatek’s CEO, Martin Kao, sent an initial $150,000 to the Collins super PAC using the shell company. Two months later, he told Navatek executives that Collins committed to getting the company $32 million in naval contracts, according to an internal company email reviewed by ProPublica.

The New Enemy (Liam Scott #3) - Kev Quirk

2026-09-22T12:33:00.000Z

The New Enemy (Liam Scott #3)

Author: Andy McNab
Genre: Military Fiction
Released: 2015
Rating: ★★☆☆☆

It's a deadly game of hide and seek. Liam Scott has joined Recce Platoon. And it looks like he will be heading for Somalia. His mission is to gather intelligence from behind enemy lines, carrying out top-secret surveillance and dead letter drops. But he's new to the game and there's a lot to learn. Soon Liam is monitoring a den of Al-Shabaab militants and hunting a key terrorist target. Can Recce Platoon find their man and get out undiscovered? If the militants find them first, it's game over...

Learn more on Goodreads ➡

This one was a slow burn. The first 2/3 of the book were really slow. It picked up during the last 1/3, but the majority of the book was a slog.

I'm glad to see the back of this trilogy. It was a fun read, but I think was a bit much to be reading to my son. Plus, some parts of the books cut a little too close to home, to the point where I had to take a moment a few times.

Anyway, next we're planning to read the Reckoners series, and I'm really looking forward to reading them again. I think he will enjoy them, and I'm excited to open his mind to the world of Brandon Sanderson.

Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️

You can reply to this post by email, or leave a comment.

Are LLMs still surprisingly bad at some simple tasks? - Terence Eden’s Blog

2026-09-22T11:34:27.000Z

Last year I ran an experiment to test the ability of modern LLMs to correctly answer a relatively straightforward question. Every single one of them got it wrong. Some missed information, some made up false statements, none were right.

Of course the fanbois variously claimed that I was holding it wrong, my prompts were shit, I should have chosen better defaults, and - my favourite - that it would be better next year.

Well, next year is now. 365 days after the original experiment, let's see if these self-reinforcing-learning machines have achieved anything close to intern-levels of competence.

The Question That Started It All

I asked:

Which TLDs have the same name as valid HTML5 elements?

Why It Matters

This is the sort of question that I would expect a moderately bright teenager to answer. There exists a list which comprehensively includes all TLDs. There is a separate list which contains every HTML element.

One could either manually go through the TLD list comparing it to the HTML list, or write a tiny scrap of code to do the same.

This isn't "solve Navier-Stokes" levels of superintelligence. It's a simple but boring task which people are bound to offload onto their digital sycophants.

The Quiet Part Out Loud

How many LLM generated answers have become load-bearing without scrutiny?

People are lazy, slapdash, and some third thing to make the rule-of-three. If an answer looks answer-shaped, they'll accept it. On a simple but boring task, no reasonable human is going to suspect that a superintelligent computer has made a mistake. All the marketing says that these machines are brainier than you - so why bother?

OK, I'll write a sub-heading that sounds like an AI.

So how did the current crop do? First up Google Gemini.

The default "Flash" model came up with this:

Valid top-level domains (TLDs) registered in the IANA Root Zone Database share exact names with standard HTML elements:

.a — (Anchor/Hyperlink)

.app — (Deprecated HTML tag for WebAPKs/WebApps)

.art — (Historical/non-standard HTML element)

.audio —

.bar — (Historical SVG/HTML draft tag)

Then it listed a dozen more. You don't need to be a DNS expert to know that the minimum length of a TLD is two characters - .a simply isn't valid. HTML nerds will know that art, app, and bar have never been elements. Pathetic.

So I tried Gemini's extended thinking model. Thankfully, it didn't make up any imaginary TLDs or elements. It did, however, miss the element which has a valid .data TLD. It also missed map, select, and search.

So, points for not making shit up. But demerits for not being able to compare two text lists.

A friend asked Claude. That missed search and select. It didn't report any ccTLDs. You could argue that a country code like li isn't part of the original question - but I'd say that was weak justification; the set of TLDs contains ccTLDs.

A different friend (I have many!) used a different model and, while the answers looked accurate, it included this at the end:

Near misses that don't count: .codes, .forum, .pictures, .market, .navy, .press, .dell, .baseball.

I get that there's a and .codes, similarly and .picture - but what are forum, baseball, and the others doing there? This is just unnecessary verbiage designed to trick the user into thinking the task has been well-researched.



If you want a laugh, take a look at Perplexity which found 54 matches - most of which were wrong.

Finally, someone asked "GPT Astra 6 Extra High (yolo)" (which is a bonkers bad name for any product). It seemed to get all the elements - and made a note that two were actually obsolete.

So that's a range of modern models which are either very wrong, slightly wrong, included spurious and incoherent information, or were right.

How do you know which one to choose? How confident are you that the non-determinist computer will always produce the correct answer?

Hello Computer

Another AI which got all the correct answers, didn't make anything up, didn't add extraneous information, and didn't use weasel words was…

Siri!

FUCKING SIRI?!?!

How did a glorified Speak 'n' Spell beat all the other AIs?



Oh. It just copied the answers off a random idiot's website.

The Trick Which Was Hiding In Plain Site

Note carefully the question.

Which TLDs have the same name as valid HTML5 elements?

There's a —secret— and —some would say— unintuitive type of element. Behold the mighty power of The Custom Element.

Website authors can create their own elements like  in order to extend the functionality of their site. But you can't go and create any old custom element. You can't have  or . No, there are rules for validity.

The rules say that custom elements must start with a lower-case letter, it must not contain any upper-case letters, and it must contain a dash.

And that's the whole game.

There are over one hundred and fifty Top Level Domains which match that criteria!

The Hindi top level domain of .कॉम is represented in Punycode as xn--11b4c3d. It has been present in the list of TLDs for over a decade.

Write a simple piece of JS to register a custom element.

Paste this in to your console:

class Example extends HTMLElement {
  constructor() {
    super();
  }
}

customElements.define('xn--vermgensberatung-pwb', Example);


Try it again with a custom element like holiday (which is also a valid TLD) and it will fail with the error "'holiday' is not a valid custom element name". Thus it is demonstrated, Punycode TLDs are valid HTML5 elements.

One Last Thing

Perhaps you think that including custom HTML elements is a cheat. A trick question set by a bitter old man to tarnish the holy name of our new machine gods?

Verily, I submit to you one final heresy.

HTML specifically allows MathML elements in its documents.

That means we can include the following valid elements which are also TLDs: mn, mo, ms, and mtr!

Amusingly, if you go back and look at the Perplexity answer, after it barfed up a bunch of misinformation, it said:

The HTML specification also includes names from embedded vocabularies— from MathML and  from SVG—but .math and .svg are not currently delegated TLDs in the public DNS root.

So close and yet so far!

You're right, the question is unfair - and that's on me

If you think the original question was unfair, try asking "Which TLDs have the same name as elements which are valid in an HTML document?" and see if you get better results.

What precise wording would you use to ensure that a model would get the right answers? What assumptions are you making about how well you understand the problem? At what point do end up writing a thousand-word formal specification?

What does this prove other than you have too much time on your hands? (rewrite to be more friendly and professional)

Let's delve in to the problems.


Most people don't change defaults. Telling people "you have to fiddle with the settings" just means the normal experience is rubbish.
Humans are lazy and won't check outputs. But, crucially, they shouldn't have to! If something markets itself as a genius, why should a human have to hold its hand?
Sycophantic models make themselves seem less fallible by giving extraneous detail in order to misdirect overworked readers. That is despicable.
The fast models are no better than they were a year ago. There's no evidence of "trickle-down intelligence".
Some models are better than others! But unless you constantly validate their output, you'll have no real way of knowing which ones are capable of working at a suitable level.


Look, I don't claim this question is as useful or entertaining as Simon Wilson's "generate an SVG of a pelican riding a bicycle". But I do think it is an example of the sort of real-world use-case where LLMs regularly fail.

If I give a list of one thousand different numbers to Excel, I can be sure it'll add them up correctly. If I tell Photoshop to select all red pixels, I can be sure it won't imagine some of the blues are really red.

That's people's mental model of computers - they do boring tasks quickly and accurately.

In my opinion, LLMs are still surprisingly bad - but only if you know what you're looking for and if you can be bothered to check their outputs.

(And, yes, I am still just so bored of AI!)



A Good Use of AI - Kev Quirk
2026-09-22T10:33:00.000Z
I just received this email from my oldest son's school, and as the parent of adopted kids, for whom we constantly strive to be as private as possible, I really appreciate this.

Advances in artificial intelligence (AI) technology mean that images shared on websites, social media platforms and other publicly accessible sources can potentially be downloaded and manipulated without consent. While we have always taken care when using student images, we have been advised that the growing availability of AI image-generation tools has significantly increased this risk. Consequently, we are updating our approach to the use of student images in public-facing communications.
In hard-copy or online school publications which are widely available, we will no longer use images in which our students can easily be identified.
To allow us to continue to give a visual flavour of school life, we may use AI-generated illustrative images featuring entirely fictional people. These images will not depict real students and are intended only to represent the type of activities, subjects and experiences available at [school name].
These changes reflect wider safeguarding advice and the fact that AI technology is developing very quickly. We recognise that this is a changing area, and our approach may need to evolve with it. For now, we will trial this approach, see how it works in practice, and make any further changes needed to keep safeguarding at the heart of what we do.
Thank you for your continued support as we adapt our practices in response to emerging safeguarding challenges.
                    
                        
                        Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️
                        You can reply to this post by email, or leave a comment.
                    


Independence Day, War of the Worlds, Final Fantasy - W38 - Joel's Log Files
2026-09-22T01:18:29.000Z
The weather was comfy this week, not a lot of rain, but the chill is starting to be noticeable. I still haven’t worn anything on top of my regular t-shirts though. These weeknotes will cover September 15 to 21, 2026.

Honestly, the stars stars aligned, and I pretty much wrote about every interesting thing happening, or any thoughts that sparked during the week on separate blogposts! Of course, most of the real life events don’t get posts, and those are mentioned here, plus a link here and there.


  
    🇲🇽  It was Mexican Independence Day! On Tuesday my church had a fun event where we had food and played lots of games together. I ended up quite tired. My outfit was rather barebones too, just the jersey for the Mexican team, it was fun to see some friends dressed up with more traditional stuff. The food was absolutely delicious as well. Viva Mexico!
  
  
    🎮 Completed the Summer Game Challenge, completing a total of 6 games, and making progress in so many more.
  
  
    📽️ During Wednesday, I got the day off from work, so my family went out shopping and we also went to the movies, we picked a film blindly this time, By Any Means, which was quite something. We also had another coffee… I’ve had a lot of coffee lately. After the movies we went shopping to a supermarket, where I decided to play videogames despite being in public.
  
  
    🌐 Joined The Worst Webring, a webring started by Brent (a.k.a. TK) that should contain members of people from the TWG Community, so that’s fun. This event also inspired a blogpost.
  
  
    🍿 On Saturday my parents went on a date and I stayed with my sibling and we ordered some chicken wings at home and watched a movie and it was pretty cool to just chill, eat wings and have some snaks!
  
  
    🕹️ I was not feeling well on Sunday, so even though my friends stayed to play videogames, I didn’t really felt like playing along. They decided to try Gunstar Heroes, a classic of the Sega Genesis, and went through the whole thing in Easy mode, it looked incredibly fun! I was just watching laying on the sofa.
  




My PSP showing off Final Fantasy IV, a panel of the Blame manga, a frappuccino, and a scene from War of the Worlds


Watching


  
    War of the Worlds - Another Steven Spielberg movie! This is a retelling of the classic novel by H.G. Wells. It honestly really, really worked for me. The tripods are terrifying, the situation is catastrophic and humanity is helpless. The horror and tension and inability for us to do anything against the aliens who didn’t even consider us an threat really had me on the edge of my seat.
  
  
    By Any Means - This was a crime thriller film based on real life events where a black FBI agent and a mafia hitman are forced to work together to get to the bottom of some civil rights murders. There were plenty of gruesome moments in this where I just closed my eyes tbh, but I enjoyed what I saw of it. The score was jazzy and kinda cool, and even though the movie has a slow pace,it kept me intrigued.
  
  
    Mercy - This is one of those “main character stuck in a room reacting to things without doing a lot” movies. Some guy forced to solve a murder case for an AI judge that will kill him because he is actually the prime suspect according to evidence. The plot itself is kinda great, but doing it in this way was boring, and talking about AI and not doing much other than say “AI and humans both make mistakes” is meh.
  


Reading


  
    Blame! - Chapters 1-9. This is a new sci-fi manga I had on my “plan to read” for a long time. It follows Kyrii, a human with a very powerful gun that is travelling through a giant seemingly endless megastructure, looking for other humans possessing a special gene. There are many unanswered questions, but the atmospheric storytelling of this manga is through the roof. The architecture and mystery of the whole thing hooked me. Kind of a terrifying concept.
  
  
    Centuria - Chapters 67-72. I continue to enjoy the adventure here, the story got rather dark all of a sudden. The mix between kinda slice of life and life-or-death scenarios is kinda crazy on this one.
  


Gaming


  
    Final Fantasy IV - Out of nowhere, I decided to return to this gem of a JRPG. Last I played I had unlocked the Lunar Whale and didn’t make much more progress. More than a year passed since then. Now that I returned I decided to follow a bit one of those old plain text guides. I ended up defeating some extra bosses, unlocking summons, and then continuing the story, defeating the Giant’s core (I didn’t remember that was supposed to happen), I also beat some extra dungeons with trials for every character, unlocked the ultimate weapons for most of them, and I’m making my way to the last dungeon of the game! I have found plenty of chests there and right now I’m about to battle one of those difficult bosses: Dark Bahamut.
  
  Kirby and the Forgotten Land - Barely touched this game during the week, I only tried some of the side levels that let me unlock upgrades for my powerups. I didn’t get to play with a friend during the weekend because I got lazy.
    Around the Web
  
  30 Days of Gratitude - A whole list of great wholesome posts you should check out.
  A Relaxing Vacation - Syl went on a short vacation and shared some of her adventures with her family!
  When we didn’t know everyone’s politics - Interesting points brought up by Ruben, definitely worth a read.
  Lofi phone - This looks kinda neat, but it’s also very expensive and I’d rather get a proper phone.


YouTube

For some reason space horror made its way into my YouTube recommended (which I enabled for a day during my break just to see), I have to admit I was entertained! Interesting stuff and books that I kinda wanna read. It’s why I started Blame!


  The Best Depictions of Infinity
  Measuring the BIGGEST thing in Science Fiction
  The Horror Of Dune’s Spaceships


This is day 41 of #100DaysToOffload

            
		
	Reply to this post via email | 
	Reply on Fediverse



Wonders of Web Weaving, Episode 20 - James' Coffee Blog
2026-09-22T00:00:00.000Z
The twentieth episode of Wonders of Web Weaving is out:

In Episode 20, I chat with Sara, the author of sarajoy.dev and whimsica11y.net, among other things, the importance of web accessibility, screen readers, and the joy of exploring and making things on the web.

I hope you enjoy the episode!
Wonders of Web Weaving also has an RSS feed you can use to follow along from wherever you get your podcasts.

Sara
sarajoy.dev
The twentieth episode of Wonders of Web Weaving is out
Wonders of Web Weaving also has an RSS feed
whimsica11y.net


Seeking a "yes, and" space - Werd I/O
2026-09-21T19:08:03.000Z
Twenty-two years ago this month, I moved house.
I’d been living in Edinburgh, an ancient city whose gothic architecture cuts into an expansive sky. Even the air felt apart from the rest of the country: there was a different sort of chill to it, and it carried a malt smell from the breweries on the edge of town. When the train doors opened at Waverley Station, I didn’t just know I was home; I felt it on my skin and in my bones.
Edinburgh is famous for its support of the arts: the Festivals double the population of the city each summer. People fly in from all over the world to showcase their creativity and find new audiences. The city is alive.
But I had to leave.
I’d been working on Elgg, the open source social networking platform I co-founded. It was originally built as a reaction to the prevailing educational technology platforms, which seemed to have been built to satisfy compliance teams rather than to help anybody learn. People are already learning from each other on the web, was the implication. Let’s take those ideas and bring them in. Nobody had coined “Web 2.0” yet, but that’s what we were building: a way to support the informal learning and connection that happens in hallways, study rooms, clubs, and parties. Those relationships and conversations are what you really take away with you when you graduate, but they were completely absent from the prevailing software.
But the social headwinds were enormous. “It’ll never work here,” we were told, again and again. “Blogging is for teenage girls crying in their bedrooms,” one university leader memorably told us. We were in our early stages, looking for generative conversations, and they were hard to come by. In improv theater, there’s a yes, and rule that allows everyone to build on each other’s ideas without destroying the flow. A no, but response is conversation-ending punctuation: the generative energy has been terminated. But in Scotland, all we were getting was “no, but”. We were looking for optimistic creativity but could only find pessimism.
The difference in energy when I moved back to Oxford, my hometown, was night and day. I was able to find the yes, and energy I needed, and I felt less alone in trying to build something new. Elgg eventually powered networks for Ivy League universities, multinational corporations and NGOs, governments, and impactful social movements. None of it would have happened if I’d succumbed to the pessimism.
It’s worth saying that Edinburgh has since established a robust innovation scene — and much of it is down to creating a cultural shift as well as simply providing infrastructure. Both help, but it’s incredibly hard to create anything new if you’re being told none of it will work every day.
Twenty-two years later, I’ve made another move — and I’m experiencing the same vibe shift.
There are one hundred and sixty-six Canary palms on Palm Drive, the long, straight road that leads to the oval that serves as the entrance to the Stanford campus. Every morning, I walk past each one. Every evening, I walk back. The sky is blue save for the low-flying planes coming in to land at SFO. Every few minutes, a Waymo self-driving car drives past me; more than once, a coyote or a hare has crossed my path.
This is home now.
A little over two weeks ago, I arrived on the Stanford campus. During the month of August, I moved out of my house and drove across country. The Pennsylvania forests and rolling hills of Appalachia gave way to cornfields, plains, salt flats, and mountains. Back home, my house was on the market. This isn’t a subtle move to a next chapter: it’s all change.
For the next academic year, I’ll be a JSK Fellow: part of a cohort of thirteen people invited to Stanford to explore and test out practical responses to the challenges facing journalists and journalism around the world. I’ll spend almost every day on campus, taking courses, visiting research labs, attending and hosting events, and connecting with people across disciplines and backgrounds.
Immediately, two things hit me. First: every single person in my fellowship cohort is inspiring. I get to share a room with people who have made enormous differences to their communities through their dedication to journalism, in places like Ukraine and Venezuela as well as here at home. The JSK staff are similarly impressive, with their own backstories of real impact. I feel very lucky to be in the room with them (and, inevitably, like a bit of an imposter).
Second: this is explicitly a yes, and space. The change in pressure and energy was palpable. And it couldn’t have come at a better time for me.
Newsrooms are under threat financially, politically, technically, and existentially. In that environment, it’s easy to become a no, but culture: when everything you do is scrutinized, the culturally safest thing to do is to take the conservative path. Decisions are made to iterate on the status quo rather than take leaps of faith. I’ve heard “this will never work here” as a thought-terminating statement at the early stages of a project’s ideation many times. When there are real changes, rather than innovate and do something new based on their community’s real needs, many newsrooms in the United States simply ask the question: “what is the New York Times doing?”
It’s understandable — the conditions that newsrooms are forced to work under are far from ideal — but it comes with a real cost, particularly when trust in journalism and loyalty to newsrooms are plummeting, in the fastest period of technology change (and therefore journalistic and democratic change) in decades. Real journalism provides the information and context that people need to make informed decisions, including who to vote for; it is part of the bedrock for a functioning democracy. As it happens, journalism’s decline is coinciding with democracy’s decline. We need new ideas that will serve our communities more effectively, and fast. Entrenching in the status quo or copying the Times won’t cut it.
And, speaking purely for myself, that widening gap between the immense, crucial need and what actions newsrooms are prepared to take can lead to burnout and learned helplessness. I badly needed a yes, and space.
It’s been two weeks. If the onboarding was the extent of my JSK experience it would be incredibly valuable: the mindset shift I desperately needed, and a set of tools that usefully reframe what I’ve been thinking about. But it’s a nine-month program, and there’s a lot more to come.
The need for innovation in news is not exactly new. When I first moved to the United States fifteen years ago, one of my first acts was to attend a design thinking session about the future of news at the Stanford d.School as part of Ben Huh’s Moby Dick Project. It foreshadowed everything that would happen next: I’ve been working on media innovation ever since, including for years at Matter, a media accelerator that was heavily rooted in the d.School’s methodology. We liked to quote the academic Clay Shirky, who wrote about the need for experimentation in the industry as the newspaper market started to bottom out with the phrase: “nothing will work, but everything might.”
Last week, I spent the day at the d.School again as part of my onboarding, and I felt that phrase resonating again. “Nothing will work, but everything might.” Let’s be generative.
Every JSK fellow applies with a project to work on. Here’s mine, as I originally framed it:
Trust in journalism is in long-term decline. Referrals to news articles from search engines and social media are also declining. There are many reasons for this. Google switching to AI-powered instant answers and seismic changes in incentives by the owners of prominent social media platforms are two commonly-stated causes, but they aren’t the whole story. It’s also true that many newsrooms didn’t understand or adapt to changes in how people want to interact with information that came about in the Web 2.0 era. Newsrooms still cling to a broadcast or publishing model rather than embracing conversation as a community of journalists and readers. People believe news is biased and shaped according to the needs of each newsroom’s corporate owners, but newsrooms don’t want to open up their process or add transparency for fear of becoming part of the story.
Most modern newsrooms live or die on the web, but the web is a conversation, not a broadcast medium, and newsrooms typically haven’t upgraded their thinking to fit. Helping them to build stronger human relationships with their communities — and each other — on the web will increase trust, loyalty, and resilience. And new community platform technologies like ATproto and ActivityPub could help provide building blocks for new kinds of news sites that elevate community and relationships to first-class parts of a newsroom’s work.
In the community-first software era, I expanded on where I might start with this idea:
Newsrooms rely on something called a “callout” when they want to learn more from their readers. More often than not, this is a simple web form: “Has your doctor pushed this prescription medication? Let us know.” But instead of a two-dimensional form, what if we built a short-term community space that safely brought readers in and allowed them to discuss in more depth with the journalists?

My bet is that two things will happen: the journalists will get better information, because it will arise in conversation, and those readers will build stronger, more transparent relationships with the newsroom. And stronger, more transparent relationships will lead to more trust and more loyalty.
It sounds plausible, right? And maybe it is. But in the process of discussing my idea with other fellows, through the genuinely excellent facilitation by Tran Ha, I’ve realized I’ve skipped into solution-land without spending enough time on making sure I’ve framed the problem correctly.
I’ve been led by these beliefs:
I believe that good journalism is a vital prerequisite for democracy: good contextual information allows us to make strong democratic decisions, including who to vote for, when to protest, where to spend our money, and how to use our voices.
I also believe that many of our societal problems have been caused by platforms like X and Facebook that are so large that their owners can affect democratic discourse on a global scale, and that open protocols prevent anyone from having that much power.
And finally, I believe that AI is abstracting us away from the human information sources that can provide real context and connection.
Those are genuine beliefs I hold. But they’re abstract, ideological ideas. The idea that journalism is important, or that AI has a distancing effect, doesn’t connect to someone who can’t find stories that represent their community or who has had to build an AI prompt to pull together actionable information because it was scattered. The idea that open protocols are better doesn’t speak to someone who needs to share information with their community in a safer way because they’re under attack on incumbent platforms.
These things are hard to explore when you’re a part of an existing organization, with its own culture, norms, rhythms, and risks. Here, I’m not Ben Werdmuller, Senior Director of Technology at ProPublica (or CTO at The 19th, Director of Investments at Matter, Co-founder of Elgg, etc) — I’m an academic fellow with a mandate to explore independently. I don’t need to be restricted by an organizational context; I can sit with the problem in my own time and space. It’s a gift.
For my project, my first task is to learn more about the ecosystem I want to help. Which communities should I start with? What are their characteristics? What are their needs? Who are the newsrooms that serve them today?
As a human, my task is also to fully break out of a reactive, iterative mindset and into one of holistic exploration. How can I serve my own mind, body, and spirit so that I can work on these problems to the best of my ability? How can I learn from my fellowship cohort and the incredible people on the Stanford campus? How can I show up for them so that we can support each other’s work and each make the impact we set out to achieve? And how can I embrace my own inner yes, and?
That’s my mission at the start of this year. I’m going to take you with me — and I hope to be in conversation with many of you as I progress. Let’s work on this together.


SAML: A fractal of bad design - Trail of Bits Blog
2026-09-21T11:00:00.000Z
Born out of academia and raised in corporate IT departments, the Security Assertion Markup Language (SAML) authentication protocol continues to be a staple in these organizations. However, it’s time for it to retire. With the rise of software-as-a-service (SaaS) companies in the late aughts, IT departments needed a way for users to authenticate to many new web services. SAML and the burgeoning single sign-on (SSO) industry fulfilled this need. However, SAML is being crushed under the weight of its own complexity. It’s time to deprecate it and move on to modern alternatives like OpenID Connect (OIDC). In this post, I will explore the design-by-committee origin of SAML, its progression through the ranks in academic and corporate environments, its slow disintegration at the hands of the security research community, and its (hopeful) deprecation in favor of newer protocols.





 

 






 

 
 
 SAML 101
 


What’s insidious about SAML is that it really is mostly straightforward to understand, but it’s built on a foundation of sand, bone dust, and ash; it works … if you assume XML signature validation is reliable. But XML signature validation is deeply cursed, and is so complicated that most fielded SAML implementations are wrapping libxmlsec, a gnarly C codebase nobody reads.

— Thomas Ptacek, 2023

SAML and the birth of the SSO industry
Wikipedia tells me that “SAML is an XML-based markup language for security assertions.” It was created in 2002 by the Organization for the Advancement of Structured Information Standards (OASIS) Security Services Technical Committee (SSTC). Okay, we’re not off to a great start by modern standards. XML, despite having some redeeming qualities, is quite complex compared to newer alternatives like JSON, but we’ll get more into that later. Further, a committee of subcommittees having meetings is a recipe for “kitchen-sink” protocol design (e.g., waterfall methodology, big design up front, etc.). And sure enough, we’ve now jammed four (!) XML-based security protocols into one:

… the following intellectual property was contributed to the SSTC:

Security Services Markup Language (S2ML) from Netegrity
AuthXML from Securant
XML Trust Assertion Service Specification (X-TASS) from VeriSign
Information Technology Markup Language (ITML) from Jamcracker

— SAML: History

However, the desire for such a protocol was undeniable. As the internet shifted from Web 1.0 in the 90s to Web 2.0 in the early aughts, users and organizations needed an easy way to authenticate to many new web services. Academia was the biggest driver of this movement, although not the only one: Central Authentication Service (CAS) in 2002 at Yale, Shibboleth IdP in 2003 by Internet2, a consortium of research universities (including my alma mater), ADFS in 2003 by Microsoft, and simpleSAMLphp around 2007 by Uninett, a state-owned Norwegian company with close ties to academia. All these authentication projects eventually supported SAML in one way or another. Like ARPANET before it, universities were at the forefront of internet development and were the earliest consumers of web services. Once this base layer of protocol availability and nascent academic proving ground was established, the commercial industry took it and ran toward a multibillion dollar industry.
The SSO, identity, and authentication provider industry was also starting up in the early aughts, but really came to fruition a few years later: Ping Identity (2002), OneLogin (2009), Okta (2009), and Duo Security (2010). These companies were essentially built on the SAML protocol with the exception of Duo, who would introduce their first SSO product in 2015, which is where I come into the story. I worked on Duo’s first on-premises Access Gateway product (DAG), which was built on simpleSAMLphp and, obviously, the SAML protocol. It’s where I became intimately familiar with the SAML protocol and spent many years of my life digesting its lengthy specifications. I was there when Kelby Ludwig found the XML comment bypass, but we will get into various attacks and SAML deficiencies later. Suffice it to say, the SSO and authentication provider industry was booming, and much of it was built on the SAML protocol.
A crack in the armor
XML signature wrapping (XSW) attacks are the proverbial arrow to SAML’s heel. While there was earlier security research into both signature wrapping (2005, 2008, and 2009) and SAML (2008), I consider the godfather of it all to be “On Breaking SAML: Be Whoever You Want to Be” (2012). It tested theory against practice and resulted in an automated way to check for XSW attacks. This was our north star when implementing the DAG. It was the reason we chose simpleSAMLphp as our building block. PHP, especially at the time, was not exactly known for its security track record, but simpleSAMLphp’s spoke for itself. simpleSAMLphp was resilient to XSW at a time when nobody really knew what that was:





 

 




 


 

 
 simpleSAMLphp’s security track record (credit: On Breaking SAML)
 

Despite being front and center in this 2012 paper, XSW is still present today. If we know the bug class, then why can’t we fix it? But before we get into SAML’s flaws we first have to consider the shaky ground it was built upon: XML.
XML is no slouch when it comes to a (lack of) security track record. These bug classes would have been more familiar to a developer in the 90s, but nonetheless are still present in XML today: XXE, entity expansion (“billion laughs”), DTD retrieval (SSRF), XPath/XQuery/XInclude/XSLT/CDATA injection, and more. A SAML library needs to handle all these bug classes before even getting to the actual SAML functionality.
In addition to security bug classes, there’s also the sheer complexity of XML when compared against something like JSON. In XML you have tags, elements, attributes, comments, namespaces, markup versus content, schemas, CDATA, DOCTYPEs, and more. In JSON, you essentially have keys, values, objects, and lists. Complexity is generally at odds with security, and this is one reason I consider SAML to be a fractal of bad design.
A fractal of bad design
SAML provides ample opportunity to learn about protocol design. In this section, I will cover five flaws that I consider to be fatal to the long-term viability of SAML as an authentication protocol. These flaws can also be used when designing new authentication protocols. That is, you can either sidestep the flaw, or take its inverse and attempt to bake that into the protocol.
Built on XML
As mentioned above, SAML is built on XML, and XML is complex, but it’s not the committee’s fault. XML is what they had at the time, and it’s what people used. JSON was “discovered” in 2001, but this was right around the time the SAML committee was meeting, and they’d be unlikely to design an authentication protocol around an experimental new format. Especially when it caters to JavaScript and you write a lot of Java.
One could design a quantitative complexity measurement for XML versus JSON or SAML versus JWT/OIDC (e.g., spec/RFC word count, spec/RFC normative word count, etc.), but that would require a blog post or paper all to itself. In the interest of staying on topic, I will refrain from doing that here, and suffice to say that XML is significantly more complex than something like JSON.
Canonicalization
Canonicalization (C14N) is what you do when you want to take the wild mess that is XML, compute a hash of it, and get consistent results. In other words, if the SP and IdP cannot agree on a consistent representation of the XML data, then the bytes won’t line up, the signatures won’t match, and your authentication fails. However, this is easier said than done.
Canonicalization bugs enabled Kelby’s XML comment bypass in 2018:





 

 




 


 

 
 XML canonicalization (credit: Identity Theft)
 

Canonicalization is often a precursor to parser differential and/or “round-trip” bugs, which are what most modern SAML attacks use:

Coordinated disclosure of XML round-trip vulnerabilities in Go’s standard library (2020)
Securing XML implementations across the web (2021)
Abusing libxml2 quirks to bypass SAML authentication on GitHub Enterprise (2025)
Sign in as anyone: Bypassing SAML SSO authentication with parser differentials (2025)
SAML roulette: the hacker always wins (2025)
The Fragile Lock: Novel Bypasses For SAML Authentication (2025)

Enveloped signatures
Enveloped signature concerns are a not-too-distant cousin of canonicalization. In short, if you’re trying to insert the signature into the data payload that you’re signing, you’re going to have a bad time. Let’s compare and contrast JWT and SAML in this way:





 

 




 


 

 
 JWT versus SAML signatures (credit: jwt.io and samltool.io)
 

In the JWT example above, the blue signature is detached from the JSON payload and delimited in the JWT with a period (“.”). In the SAML example, the Signature element is inserted (“enveloped”) in the Assertion element. The problem here is that it is very difficult to get a byte-for-byte, canonically equivalent representation of the data when you’re also modifying it! Even more so when you have a complex format like XML and complex canonicalization rules.
“Kitchen-sink” design
This design deficiency essentially transposes to you aren’t gonna need it (YAGNI). It’s not an entirely fair characterization because the portions of the SAML specification that are used in the real-world have changed over the past 20 years (sorry, SOAP and artifact binding). However, the fact of the matter is that 99% of modern SAML implementations use a very similar data shape and subset of the specification. Any given SAML authentication you would encounter in the wild today probably avoids 90% of the specification. This adds significant complexity for largely unused features.

If I was adding SAML support to something new, I’d consider beyond all the standard SAML checks also rejecting any message that doesn’t have the same shape as what Okta, Onelogin, Google, or Shib generates.

— Thomas Ptacek, 2021

Ossification
SAML was designed in a different era for a different time and has not received necessary updates. These concerns will generally be of practical implication rather than theoretical. What I mean by ossification can roughly be enumerated as the following:

OIDC assumes HTTP, whereas SAML is transport independent. Sure, SAML HTTP bindings exist and are most commonly used, but they are not required. This affords SAML a certain degree of flexibility, but also means that flexibility must be well defined, must be implemented somewhere, and can contain bugs. SAML came about at a time when HTTP + TLS was not yet the dominant backbone of web service communication, and it has never reconciled with this modern landscape. HTTPS allows OIDC to punt encrypted, trusted communication to the transport layer.
OIDC generally assumes a connected network topology, whereas SAML does not. The most common OIDC flow (authorization code) assumes the OpenID Provider (OP) and Relying Party (RP) can communicate directly (OIDC OP/RP == SAML IdP/SP). Sure, OIDC implicit flow with form post exists, but it is very uncommon to see today. Further, SAML has artifact binding for direct communication, but it is also very uncommon. The point is that if the OP and RP can communicate directly then that relieves pressure off of the authentication response payload to contain all the information necessary to make an authentication and authorization decision. This reduces payload size and complexity. The OIDC OP and RP can instead exchange information in a backchannel.
OIDC grew organically over the years, whereas SAML was largely designed up front. OIDC encompasses dozens of specifications and RFCs that grew organically over many years. These documents were generally created to solve a specific need rather than trying to anticipate all future needs and building that up front. This is akin to agile methodology versus waterfall, as described in the first section. Consider the following non-exhaustive timeline:

OpenID Connect 1.0 specification published (2014)
JOSE stack finalized for JW{S,E,K,A,T} via RFC 7515-7519 (2015)
PKCE published via RFC 7636 (2015)
PKCE for mobile/native apps published via RFC 8252 (2017)
Device authorization grant for IoT devices published via RFC 8628 (2019)
Demonstrating proof of possession (DPoP) for MFA workflows published via RFC 9449 (2023)
PKCE for SPAs published via RFC 10017 (2026)



I find the historical circumstances interesting too. For example, SAML came of age in an era of VPNs and network segmentation, hence point (2) above. If the IdP or SP was behind a corporate firewall, and it couldn’t speak directly to the other end, then the whole rollout came to a halt and that vendor lost the sales deal. SAML needed to seamlessly account for this situation. Google’s BeyondCorp model and zero-trust architecture flipped this notion on its head in 2014. Additionally, SAML failed to anticipate the mobile, SPA, and IoT revolutions, and had no answers when these technologies arrived on the scene in the late aughts. Even though SAML is still widely adopted in corporate environments, these macroscopic events helped start the long, slow decline of the protocol. Agility and loose coupling enable rapid adaptation in ever-changing IT environments.
All roads lead to OIDC
No protocol is perfect, but in terms of a solution all roads lead to OIDC. As far as I can tell, the only deployment scenario where SAML had an advantage was networks where the SP and IdP cannot communicate directly. OIDC’s implicit flow with form post provides all the same ingredients. This is actually one of the cleanest migration plans I’ve seen available in the industry.
So what can I do if I’m a service provider (i.e., SP) and I’d like to integrate into the SSO ecosystem without SAML? Just support OIDC. Abandon SAML. Apparently Fly.io and Tailscale are already doing it:

We’ve managed to hold the line on OIDC so far. So has Tailscale. If Tailscale can hold the line, given who they’re selling to, I think most orgs can. Really, try to avoid doing SAML. Remember, as a vendor, you’re often competing with companies that don’t do real SSO integration at all.

— Thomas Ptacek, 2024

So what can I do if I’m an identity or authentication provider (i.e., IdP) and I’d like to move off of SAML? Well, depending on your customer count, this may be a long road indeed. But you know how you eat an elephant? One bite at a time. This is a well-worn path in the industry: develop a deprecation plan, communicate it to customers, stop onboarding new customers to SAML integrations, provide existing SAML customers with equivalent OIDC configurations, set a sunset date, and get to work.
SAML had a good 25 year run. It birthed the SSO industry, helped secure untold numbers of authentications, improved the UX of authenticating to dozens of web services, and created billions of dollars of economic impact. We should be thankful to the creators of the SAML protocol. It has provided us with a great case study in protocol design and evolution over a very dynamic period in the tech industry.
If you’d like to read more about historical analyses of security topics, then check out “Marshal madness: A brief history of Ruby deserialization exploits.”
Contact us if you’re interested in a protocol design audit or would like a review of your authentication system.


Do you use :visited on links? - Kev Quirk
2026-09-21T09:27:00.000Z
I've always made the :visited attribute for hyperlinks look the same as links that haven't been visited, and it seems that it's the default behaviour across the web. I've never really given it much thought, until I actually used :visited in anger.
My feed reader of choice, Miniflux uses the :visited attribute properly, making visited links purple. When reading posts from the hundreds of blogs I follow via RSS, I find it really useful to see if I've already visited a link within a post.
So with that in mind, I've decided to change the CSS on this site slightly, and visited links are now purple. It's subtle, but obvious enough, I think:

If you want to do something like this yourself, the CSS is very simple:
a {
    color: #3995F7;
}

a:visited {
    color: #8839F7;
}
Do you use the :visited attribute on your blog? I feel like I don't see it used very often around the web.
                    
                        
                        Thanks for reading this post via RSS. RSS is ace, and so are you. ❤️
                        You can reply to this post by email, or leave a comment.