A many years ago, the IF Archive existed, and it was an FTP site. It lived at ftp.gmd.de. That was a long time ago. (1992, but who's counting.)

Slightly less long ago, the World Wide Web existed, and I said "I bet there could be a web mirror of the FTP site." So I (along with my co-conspirator Paul) built that as a holiday break project. It was just a static mirror of the files, with HTML index pages. I announced it on the rec.arts.int-fiction newsgroup.

A few days later, someone posted "How Do You Find Anything?"

Fair question. The favored answer was "Download the Master-Index text file and search through that." Nobody even mentioned the idea of a web search engine.

It wasn't a very complicated archive at that point, though. If you were looking for a game, you went to games/zcode or games/tads or whatever and all the games were listed. Hierarchical folders; you probably knew where you were going.

More files and more folders were added over the years, but people still mostly knew their way around. Then Google turned up and that helped a lot. And then in 2007, Mike Roberts launched IFDB, which was an extremely searchable database of IF games -- with links to the IF Archive. So that solved the problem completely!

Mostly. Ish.

IFDB is very comprehensive for games, but it doesn't try to cover interpreters, zines, articles, or the rest of the eclectic material which the Archive has collected over the decades. Google is still okay for this purpose (with the "search web" option and site:ifarchive.org). But the idea of a locally hosted search tool kept coming up.

Last weekend I finally said, "Eh, how hard could this be?" Answer: not hard at all! I had a first draft working in about two days. Don't I feel silly now?

Behold: the IF Archive search page.

This is still a feature in progress. Should there be a mini-search bar on each page of the site? Should I be sorting results by date? More than ten results per result page? Suggestions welcome.

Here's the code for that search tool. I wound up using a Python search library called Whoosh. Whoosh is pretty old; it hasn't been much updated since 2016. But it works just fine. (There's a more recent fork called Whoosh-Reloaded but I have not dug into that.)

The nice thing about Whoosh is that it's not a web search engine per se. It's a library for full-text search of whatever data you've got. You feed in "documents", which are really just key-value collections. Whoosh builds an on-disk database of that data, and then it can search it very efficiently. I set up a script to feed in that Master-Index file I mentioned earlier, and Gretchen's your aunt.

(In fact we keep an XML version of Master-Index. So the problem of parsing that into key-value data is already handled.) (Click on Master-Index.xml if you like, but it's 15 MB of XML and browsers aren't great at that.)

I had to build a web-service wrapper for Whoosh. Well, hey, I built tinyapp for a different IFTF service; I'll just use that. It's a Flask-alike. (Yeah, I could have used Flask, but tinyapp is a habit now.)

Someone suggested Pagefind as an alternative. This is a client-side search script: a JS widget that loads its index data from the web server. Then there's a static server-side component that generates this index data. Unlike Whoosh, it works by scraping your static HTML.

This is an interesting tradeoff. You save the CPU cost of server-side search, but you pay the bandwidth cost of handing out the search index to each user. (Don't worry, it's segmented, not served in a giant lump.)

However, this model doesn't fit the Archive case very well. The Archive generates HTML files from Master-Index, so scraping the HTML back in to regenerate the index metadata is just clunky. (And requires a lot of tuning of the HTML.) Also, I want search items to refer to parts of an index page -- there are lots of items per index page. Whoosh doesn't see anything weird about that; the item's URL can have a #fragment, Whoosh doesn't care. But Pagefind is pretty solidly set on the idea that one page is one index item.

Anyhow, server load doesn't seem to be a problem yet. (Maybe this post will change that!) IFDB search is undoubtedly more useful for most people.

So, for many reasons, Whoosh it was.

(However, I'm considering Pagefind as a search tool for this blog! The DuckDuckGo search you see in the sidebar works okay -- but DDG is ad-supported, and ad-supported services gonna getcha sooner or later.)

While I'm on about the Archive, let me mention the development model.

It's a mess. A deep, historic mess. I originally wrote the Archive's index generator in 1999... in C, bless that child's heart. I converted that nightmare to Python in 2017, looks like, while I was moving the site over to IFTF hosting. But it was just a Python script that ran on some files. I tested it locally by running it on some test files.

Over time, more projects got folded into the Archive setup. There's the upload script, the admin tool, the Unbox service. Now search. Each one has its own git repository. And oh yeah, while I'm in there, shouldn't the front page and stylesheet be under version control too?

It's all pretty well organized on the server. (Except Unbox, which is well-organized on a second server.) However, to get everything installed, I just... shove the files into place. When I update a script or something, I shove it in where it goes. There's no automation at all. Every repo has a private NOTES or TODO file where I scribbled down what I did last time.

This is not good devops zen.

A couple of years ago, Dan Fabulich suggested Docker. I am fairly Docker-resistant, but he set up the admin tool repo with a Docker config to test that component (just that one) in a test container. It seemed workable.

I am now slowly constructing a testframe repository which will assemble all the Archive components in a test container. It includes the other repos as submodules. (I know, sigh, submodules.) You'll be able to browse a set of test files, search the files, upload files, etc -- all in a pocket universe, so to speak.

This isn't even slightly ready for road testing yet. The original index generator is the only part that works. I'm still feeling my way through the right way to construct it in Docker. (I've barely even scratched Docker-Compose.) I'm having to tweak many parts of the system to work in a test environment.

To be clear, I'm not working on Dockerizing the actual IF Archive. I am very conservative about making changes in production! The testframe is meant for testing and development, and also as documentation-by-model for how the Archive is configured. Once it's stable... I'll probably put it on the shelf and let the Archive keep running. I love things that just keep running on their own. Big life goal there.

But someday, there will be automation to build the production Archive setup too. As my partner said: this is how archivists deal with mortality.

The Australian Radio Network has three main brands: KIIS, GOLD and CADA. Across nine stations, there’s one non-white presenter — and she’s a bot.

Thy has been CADA Sydney’s weekday host for six months now. It turns out Thy is an AI voice clone created by ARN and ElevenLabs. [MediaWeek]

Here’s a sample of Thy on CADA. Whoever dropped in the voiceover didn’t really care if you could even hear the voice in the mix. [James Cridland; James Cridland, MP3]

Thy was apparently modeled on the voice of an ARN finance department employee. ARN won’t disclose if the employee was paid for the use of her voice, nor who’s writing the scripts for Thy.

The Carpet posted about Thy as a rumour on 13 April. Stephanie from The Carpet was surprised there was no announcement or biography of CADA’s new 11am–3pm DJ and no social media. [Carpet]

The AFR confirmed Thy was an AI fake shortly after. [AFR, archive]

ARN told shareholders it was “active in creating an inclusive workplace, as recognised in the Diversity Council of Australia’s Inclusive Employer Index.” That index probably doesn’t count faking the diversity with a bot. [ARN, PDF]

ElevenLabs scrambled to post that ARN is “not replacing people” — though it literally is. [ElevenLabs]

It’s not even clear Thy is saving ARN money. [The Carpet]

Last October, Radio Kraków in Poland tried some AI-powered fake-diversity on their OFF radio station just after firing all of OFF’s presenters. That went down about as well as this.

• Video version

Cursor is an AI-enhanced code editor. You click and an LLM auto-completes your code! It’s the platform of choice for “vibe coding,” where you get the AI to write your whole app for you. This has obvious and hilarious failure modes.

On Monday, Cursor started forcibly logging out users if they were logged in from multiple machines. Users contacted support, who said this was now expected behaviour: [Reddit, archive]

Cursor is designed to work with one device per subscription as a core security feature. To use Cursor on both your work and home machines, you’ll need a separate subscription for each device.

The users were outraged at being sandbagged like this. A Reddit thread was quickly removed by the moderators — who are employees of Cursor. [Reddit, archive, archive]

Cursor co-founder Michael Truell explained how this was all a mistake and Cursor had no such policy: [Reddit]

Unfortunately, this is an incorrect response from a front-line AI support bot.

Cursor support was an LLM! The bot answered with something shaped like a support response! It hallucinated a policy that didn’t exist!

Cursor’s outraged customers will forget all this by next week. It’s an app for people who somehow got a developer job but have no idea what they’re doing. They pay $8 million each month so a bot will code for them. [Bloomberg, archive]

Cursor exists to bag venture funding while the bagging is good — $175 million so far, with more on the way. None of this ever had to work. [Bloomberg, archive]

• Video version

A critical resource that cybersecurity professionals worldwide rely on to identify, mitigate and fix security vulnerabilities in software and hardware is in danger of breaking down. The federally funded, non-profit research and development organization MITRE warned today that its contract to maintain the Common Vulnerabilities and Exposures (CVE) program — which is traditionally funded each year by the Department of Homeland Security — expires on April 16.

A letter from MITRE vice president Yosry Barsoum, warning that the funding for the CVE program will expire on April 16, 2025.

Tens of thousands of security flaws in software are found and reported every year, and these vulnerabilities are eventually assigned their own unique CVE tracking number (e.g. CVE-2024-43573, which is a Microsoft Windows bug that Redmond patched last year).

There are hundreds of organizations — known as CVE Numbering Authorities (CNAs) — that are authorized by MITRE to bestow these CVE numbers on newly reported flaws. Many of these CNAs are country and government-specific, or tied to individual software vendors or vulnerability disclosure platforms (a.k.a. bug bounty programs).

Put simply, MITRE is a critical, widely-used resource for centralizing and standardizing information on software vulnerabilities. That means the pipeline of information it supplies is plugged into an array of cybersecurity tools and services that help organizations identify and patch security holes — ideally before malware or malcontents can wriggle through them.

“What the CVE lists really provide is a standardized way to describe the severity of that defect, and a centralized repository listing which versions of which products are defective and need to be updated,” said Matt Tait, chief operating officer of Corellium, a cybersecurity firm that sells phone-virtualization software for finding security flaws.

In a letter sent today to the CVE board, MITRE Vice President Yosry Barsoum warned that on April 16, 2025, “the current contracting pathway for MITRE to develop, operate and modernize CVE and several other related programs will expire.”

“If a break in service were to occur, we anticipate multiple impacts to CVE, including deterioration of national vulnerability databases and advisories, tool vendors, incident response operations, and all manner of critical infrastructure,” Barsoum wrote.

MITRE told KrebsOnSecurity the CVE website listing vulnerabilities will remain up after the funding expires, but that new CVEs won’t be added after April 16.

A representation of how a vulnerability becomes a CVE, and how that information is consumed. Image: James Berthoty, Latio Tech, via LinkedIn.

DHS officials did not immediately respond to a request for comment. The program is funded through DHS’s Cybersecurity & Infrastructure Security Agency (CISA), which is currently facing deep budget and staffing cuts by the Trump administration.

Former CISA Director Jen Easterly said the CVE program is a bit like the Dewey Decimal System, but for cybersecurity.

“It’s the global catalog that helps everyone—security teams, software vendors, researchers, governments—organize and talk about vulnerabilities using the same reference system,” Easterly said in a post on LinkedIn. “Without it, everyone is using a different catalog or no catalog at all, no one knows if they’re talking about the same problem, defenders waste precious time figuring out what’s wrong, and worst of all, threat actors take advantage of the confusion.”

John Hammond, principal security researcher at the managed security firm Huntress, told Reuters he swore out loud when he heard the news that CVE’s funding was in jeopardy, and that losing the CVE program would be like losing “the language and lingo we used to address problems in cybersecurity.”

“I really can’t help but think this is just going to hurt,” said Hammond, who posted a Youtube video to vent about the situation and alert others.

Several people close to the matter told KrebsOnSecurity this is not the first time the CVE program’s budget has been left in funding limbo until the last minute. Barsoum’s letter, which was apparently leaked, sounded a hopeful note, saying the government is making “considerable efforts to continue MITRE’s role in support of the program.”

Tait said that without the CVE program, risk managers inside companies would need to continuously monitor many other places for information about new vulnerabilities that may jeopardize the security of their IT networks. Meaning, it may become more common that software updates get mis-prioritized, with companies having hackable software deployed for longer than they otherwise would, he said.

“Hopefully they will resolve this, but otherwise the list will rapidly fall out of date and stop being useful,” he said.