Serious Computer Business

MIE Soft Mode

2026-01-30T10:27:53+11:00

I wrote previously that I was having difficulty making Apple's Memory Integrity Enforcement feature do what it says on the tin. After getting some help from Eskimo on the developer forums I'm pleased to report that it does work. Somewhat. In its current form it's not as impressive as I hoped, and I feel like there are still some bugs lurking.

The thing that tripped me up most is that we're not allowed to use "hard mode" yet. This means it's impossible to reproduce exactly what was demoed in Apple's video. It turns out this was called out in the Xcode 26.1.1 release notes, which I guess I should be reading if I want to play with brand new features:

When enabling Hardware Memory Tagging under Enhanced Security (Capabilities editor -> Enhanced Security -> Memory Safety -> Enable Hardware Memory Tagging), all applications will currently run under Soft Mode irrespective of the Soft Mode for Memory Tagging option.

What this means in normal English is that, for now, MIE will not actually protect anything in your app unless you're running under the Xcode debugger with a special setting enabled. It will observe the memory corruption, allow it to proceed, and log a fake crash report with the backtrace. This is not completely terrible—as a developer you will at least be able to find out when corruption is occurring so you can put out a fix. Sadly, we're not yet at the promise of "your phone would sooner terminate the app than allow memory corruption to occur", which is what you actually want for protection from malicious parties. Watch this space, I guess.

Even this new information doesn't fully explain what I saw a couple of weeks ago, however. When I was launching the app outside the debugger I had tonnes of crash reports accumulating on my phone but I didn't see any MTE ones. This was partly my oversight: once I had followed Eskimo's instructions to produce a valid simulated crash and knew exactly what it looked like, I trawled through carefully one at a time and found that I had previously triggered soft mode in two cases, in amongst a deluge of regular memory corruption crashes where it seemed MTE wasn't active at all. I'm not surprised I was confused. When I went back to my original app yesterday, and soft mode worked, I hadn't changed a single thing. My macOS, iOS and Xcode are still on the same versions.

So, who knows? Maybe there's an intermittent bug registering the entitlements properly. In any case I think I'm done playing with MIE for now. It's a neat feature. I hope everyone finds lots of bugs with it, and we get true hard mode soon.

Standard Search: a search engine for standard.site posts

2026-01-31T15:03:39+11:00

The other day I put a search engine online which attempts to index all articles in the Atmosphere conforming to the standard.site lexicon: Standard Search

In practice this mostly covers people blogging on sites like pckt.blog or leaflet.pub but also independent websites like mine that have gone out of their way to integrate with ATProto. This is rapidly growing in popularity—when I first launched the search engine a few days ago there were around 3900 indexed documents and today there are 4122.

This was a relatively easy job as far as search engines go. Between the ATProto firehose and the relay's ability to list all repos with a particular collection, there is no great technical hurdle to find all the standard.site records that exist on the network and the process is entirely automated by tap. This means that no crawling is required for discovery.

Tap is a standalone service that's designed to be consumed over an HTTP API, which means you can use it from basically any programming environment. Since I'm a fan of Rust I previously built the library tapped. This hides the fiddly details of running tap, making requests and parsing the JSON events.

The search and indexing part wasn't particularly tough either because I could use tantivy. This is basically a pure Rust equivalent of Lucene and it works incredibly well. It even handles generating the snippets of text highlighting where the keywords appear in the text. For documents that don't include any content in the AT record I scraped the HTML and ran it through dom_smoothie to get the text. The existing AT blogging platforms all seem to have plaintext fields in their content data so I extract and index those.

The main part that doesn't come off-the-shelf is verification. Standard.site has a two-part verification check. The AT record points to the page's URL, and the HTML at that URL needs to have a <link> tag pointing back to that same AT record to prove ownership. There's also a publication record which is verified against a .well-known URL. Therefore to prevent any forged records there is a bit of scraping required for each discovered post. Of course, at this early stage nobody (to my knowledge) is actually trying to forge anything. Verification failures mostly occur because someone didn't realise that they needed to add <link> tags. (If you want to check your own implementation I built an online validator).

Then there is the matter of validating the standard.site records themselves. Technically I don't need to do this: if I'm able to parse out the fields I need and the scraping checks succeed, then that would be enough to index the documents. However, in the spirit of encouraging correctness the search engine is actually pretty pedantic. It uses jacquard-lexicon to validate the record which confirms that the lexicon matches both structurally (having the right fields) and in terms of constraints. In practice these constraints are sometimes not observed, particularly the maximum number of graphemes in a post's description field (300). Documents that don't conform exactly are skipped from indexing.

One unknown at this stage is when there will be problems with spam or otherwise problematic content showing up in the index. I speculate that strict verification might keep a lid on this for a while. It's a little bit fiddly to get it right on your own and if a spammer is using a hosted platform they're likely to get kicked off anyway. I'll decide what to do if and when that happens.

One mildly embarassing thing: when I announced this I didn't realise that there already was a search engine for standard.site posts: pub-search.waow.tech by @zzstoatzz.io. That's no reason not to have a go making my own but it might have been nice of me to acknowledge that it wasn't a new concept.

Now that it's there, there are more things I could play with when I have time: language detection and filtering, vector search, things like that. We'll see what happens.

Promoting use of fine-grained PATs

2026-04-11T06:08:51Z

Software development is becoming an increasingly risky business. Supply chain attacks are more frequent than ever, and those of us using agentic LLMs run the risk that it will add a dependency automatically that contains malware. We're perfectly capable of doing that without LLMs of course (see typosquatting) but it's riskier when an LLM can add the dependency, download it, and run it, all before you get a chance to realise what it's doing.

As a result many of us are making an effort to isolate our development environments. This means both isolation between projects and isolation from our "main computer" that we're using to do the work, which probably contains most of our personal data.

If you run your development in a container or remote SSH server there are two things to worry about if malware takes over: the code itself if your repo is private or proprietary, and the SSH key or token that you're using to communicate with the git remote. The most popular choice is an SSH key, which can be stored with varying levels of security. In practice, in many situations malware will be able to make use of that key, either by exfiltrating an unencrypted key or by using the SSH agent.

The trouble with a service like GitHub is that your SSH keys are user-scoped. If someone gets your key then they have access to all of your repos, along with all of those shared with you by other users and organisations. If you're trying to isolate your environment it's kind of upsetting if the GitHub authentication in that environment grants a wider scope of permissions than it needs to.

GitHub does have three features for narrower permissions, but they all have their own issues.

Codespaces are convenient for some projects but they're costly and the organisation that owns the repo has to pay for them. SSH Deploy Keys are a repo-level mechanism not designed for regular development workflows. Some people use it for this purpose but it's going against the grain.

Fine-grained PATs are great because you can set exactly which repos and capabilities are permitted for that token, but there is a wrinkle. If you're working on another organisation's repo then by default you can't create a PAT on your own—you have to submit a request that an org admin needs to review and approve. The good news is that there's an option to turn that off, which means that developers are free to create tokens with the narrowest required permissions for each situation.

If you're a developer, consider asking for the ability to use PATs freely. If you're an organisation, consider changing the setting from the default so that contributors are able to use PATs proactively and independently.

I think it would be neat if GitHub allowed you to restrict specific SSH keys to particular organisations or repos. For personal use, honestly my favourite thing is to use Codespaces. It feels a little bit silly not using the computational power of my laptop but it automatically creates repo-scoped tokens so it's a pretty excellent level of isolation with very little effort.

Yes, yes, I'm one of those AI users now

2026-05-08T01:40:06Z

It's been a weird year. Last May I was working full-time for a client when they announced that they wanted to try Claude Code. Suddenly, I was furnished with an account and encouragement to try it out. I typed some clumsy prompts into Sonnet 3.5 and it had a clumsy go at writing Rust. It wasn't that great for my typical development work but I found a few use cases where it could solve annoying or tedious problems.

Fast forward to now. New models are extremely capable and my job is infused with AI every day. Whether I'm writing code, debugging, understanding a new codebase, or scripting an unfamiliar toolchain, the robot helps. I've been doing this kind of work for a while. I can state confidently that I'm at least three times faster for similar or better technical output. The benefits flow directly to my clients—higher quality for fewer billable hours.

I'm sharing this because I owe this blog an update. The last time I discussed AI directly was early last year and it would be fair to describe me as a hater. I predicted some of the controversies around open source contributions and preserving human communities online and I was pretty bummed about the inevitability of it all. I assumed I would be part of the tribe writing code the old way. Not for any particular reason—just to stick it to the people who messed up those things that I like. Clearly, that's not how things played out.

Thing is, I like being paid to write software. No sane business is going to pay me to spend two days typing out a Rust module that a frontier LLM can whip up in five minutes, even if it takes me half an hour to review. There's a great deal of work and judgment around that coding, which is why I still have a job, but it's crystal clear that if I rejected LLMs entirely I'd be less employable. I'm a consultant, which puts me at the pointy end of these discussions. If I want to get paid I need to meet the market. For now this remains more attractive than becoming a plumber.

Unfortunately, it appears that AI is going to be pretty disruptive to society. Copyright concerns are being waved away and our leaders are clearly more interested in having AI than not. I live in a democracy, flawed as it is, and the outcome is what it is. Regulations around misinformation and economic support for affected people will matter a great deal. Immiserating myself in protest will not, although it might get upvotes on some corners of the internet.

Note that I'm only talking about employment or contracting here. If you're writing and selling software by yourself then you can take as much time as you want, given sufficient cash flow. If you're writing hobby open source software then anything goes—write it however you like, and police contributions however you like. No arguments from me.

Of course, the LLMs won't stop here. Right now an experienced developer provides the big picture thinking and a great deal of supervision. Even among those who've taken up AI there's a widespread view that "it's just another tool" or "there'll always need to be someone who really understands the computers". It's both comforting, and the most appropriate way to use this tech today with its current capabilities. I also suspect it's wrong in the long term.

Models are already quite smart. Given the right prompt and context they can do wild things. As long as my work is primarily looking at a screen and typing things on a keyboard the LLMs are still coming for me.

Make hay while the sun shines, I guess?

Mythos and Legends

2026-05-12T11:23:29Z

A recent pastime for me has been reading the reports coming out from Project Glasswing. As you're probably aware by now, that's the scheme where Anthropic is permitting various companies and open source projects to scan their code for security vulnerabilities using the fancy new model called Mythos.

This all kicked off with a detailed post from Anthropic's own security researchers. They suggested that by evolving and improving its general capabilities, Mythos became dramatically better than previous models at locating and stringing together bugs to create working exploits. One of their proudest scalps was a 17-year-old RCE bug in FreeBSD's NFS implementation, and Mythos was apparently also adept at browser exploitation. Despite the overall sombre tone, they still found an opportunity to link to James Mickens' The Night Watch, a piece that deserves to be linked more often.

Recently I've been reading more LinkedIn (I know, I know) and it's been pretty funny watching this play out. First there was the marvelling and FUD concerning the new capabilities, then others came out to trumpet that it was pure marketing. This second group was reaching peak intensity when Mozilla published.

271 vulnerabilities identified by Mythos and fixed. They later posted more details about their process and also updated their count to 423 security bugs in April (achieved via various means). Remember that Tor Browser is based on Firefox? Probably a good thing if that one's secure. Thanks, Anthropic.

AISLE came out with a provocative post that they were able to find some of the same vulnerabilities using less capable models. This was interesting, but much of the trick was isolating the relevant buggy part so that the model wouldn't be distracted by everything else. I'll come back to this in a minute.

wolfSSL also made an announcement—8 new CVEs.

So, is Mythos as good as the hype? On our codebase, yes.

Now curl has had the chance to get checked out by Mythos. Apparently it has found one low-severity vulnerability (not memory safety) and around 20 non-security bugs.

Daniel Stenberg's comments about AI are pretty interesting in general. He's been through a lot in recent months—AI slop on curl's bug bounty program eventually causing him to shut it down, then later reporting that the security reports are getting quite good actually (due to AI), and now the Mythos thing.

He said this about the latest work:

My personal conclusion can however not end up with anything else than that the big hype around this model so far was primarily marketing. I see no evidence that this setup finds issues to any particular higher or more advanced degree than the other tools have done before Mythos. Maybe this model is a little bit better, but even if it is, it is not better to a degree that seems to make a significant dent in code analyzing.

I feel he's being modest about the absence of bugs[1], or at least avoiding hubris. Curl is a heavily scrutinised codebase that's already had significant attention from researchers assisted by AI. To me, the more likely explanation is that there's not much left to find. Amusingly, Daniel has a recent blog post stating exactly the opposite, that there are probably still plenty of bugs to come. You can all come and laugh at me in a few months if there's a raft of CVEs that Mythos didn't identify. It would only be fair. I'm still going to make this prediction, however, for two reasons.

The first is Mozilla's experience. They said that they found 22 security bugs with Opus 4.6 and then 271 with Mythos. If the model was only incrementally better at finding vulnerabilities, that's not the kind of result you would expect.

The other is AISLE's finding. If Opus 4.6 (or 4.7) is okay at finding vulnerabilities when targeted at particular vulnerable code, then it's likely that this has already been happening. If there are hundreds of researchers using publicly-available models and pointing them at different parts of curl's code in varying levels of detail, it's logical that they've found much of what Mythos could, except with more effort involved.

As you would expect, all the reports I've seen so far have come from open source projects. They don't mind talking about it. Sure, it's mildly embarrassing when memory safety bugs keep showing up in memory-unsafe languages but we're used to that. Best to just fix them and keep on keeping on.

For the commercial entities who are also part of Glasswing the calculus is a little different. I expect that few companies want to crow about the number of security bugs they had lurking in their code until Anthropic swept in to help. Still, I hope they find lots and lots of things and fix them all. The big tech companies are responsible for the security and privacy of most people on this planet and it's what their users deserve. Once the vulnerabilities are fixed, I hold out hope that Microsoft will spend some Mythos tokens taking care of the other bugs. A man can dream. And maybe some of them will find the courage to post something publicly.

What's most interesting to me is this: if we have all this neato AI tech that can find vulnerabilities, what's the path to getting this capability running against all my PRs? Will it be expensive? My hope is that this task can be optimised without having to reach for a huge general model like Mythos. Focusing analysis on diff contents will save tokens but sometimes it's the interactions with other parts of the codebase that bite you. Whoever gets this right at an economical price point is probably going to make a lot of money.

I said as much in a comment on HN. Part of my comment was relayed anonymously to Mastodon. Daniel's response was possibly either roasting me, or riffing on it. I'm just going to assume riffing. ↩︎