| gov.uscourts.dcd.223205.1436.0_1.pdf |
https://storage.courtlistener.com/recap/gov.uscourts.dcd.223205/gov.uscourts.dcd.223205.1436.0_1.pdf |
Here's the 230 page PDF ruling on the 2023 [United States v. Google LLC federal antitrust case](https://en.wikipedia.org/wiki/United_States_v._Google_LLC_(2023)) - the case that could have resulted in Google selling off Chrome and cutting most of Mozilla's funding.
I made it through the first dozen pages - it's actually quite readable.
It opens with a clear summary of the case so far, bold highlights mine:
> Last year, this court ruled that Defendant Google LLC had violated Section 2 of the Sherman Act: “Google is a monopolist, and it has acted as one to maintain its monopoly.” **The court found that, for more than a decade, Google had entered into distribution agreements with browser developers, original equipment manufacturers, and wireless carriers to be the out-of-the box, default general search engine (“GSE”) at key search access points**. These access points were the most efficient channels for distributing a GSE, and Google paid billions to lock them up. The agreements harmed competition. **They prevented rivals from accumulating the queries and associated data, or scale, to effectively compete and discouraged investment and entry into the market**. And they enabled Google to earn monopoly profits from its search text ads, to amass an unparalleled volume of scale to improve its search product, and to remain the default GSE without fear of being displaced. Taken together, these agreements effectively “froze” the search ecosystem, resulting in markets in which Google has “no true competitor.”
There's an interesting generative AI twist: when the case was first argued in 2023 generative AI wasn't an influential issue, but more recently Google seem to be arguing that it is an existential threat that they need to be able to take on without additional hindrance:
> The emergence of GenAl changed the course of this case. No witness at the liability trial testified that GenAl products posed a near-term threat to GSEs. **The very first witness at the remedies hearing, by contrast, placed GenAl front and center as a nascent competitive threat**. These remedies proceedings thus have been as much about promoting competition among GSEs as ensuring that Google’s dominance in search does not carry over into the GenAlI space. Many of Plaintiffs’ proposed remedies are crafted with that latter objective in mind.
I liked this note about the court's challenges in issuing effective remedies:
> Notwithstanding this power, courts must approach the task of crafting remedies with a healthy dose of humility. This court has done so. It has no expertise in the business of GSEs, the buying and selling of search text ads, or the engineering of GenAl technologies. **And, unlike the typical case where the court’s job is to resolve a dispute based on historic facts, here the court is asked to gaze into a crystal ball and look to the future. Not exactly a judge’s forte**.
On to the remedies. These ones looked particularly important to me:
> - Google will be barred from entering or maintaining any exclusive contract
relating to the distribution of Google Search, Chrome, Google Assistant,
and the Gemini app. [...]
> - Google will not be required to divest Chrome; nor will the court include a
contingent divestiture of the Android operating system in the final
judgment. Plaintiffs overreached in seeking forced divesture of these key
assets, which Google did not use to effect any illegal restraints. [...]
I guess Perplexity [won't be buying Chrome](https://www.bbc.co.uk/news/articles/c3dpr0kkyz4o) then!
> - Google will not be barred from making payments or offering other
consideration to distribution partners for preloading or placement of Google
Search, Chrome, or its GenAl products. **Cutting off payments from Google
almost certainly will impose substantial —in some cases, crippling—
downstream harms to distribution partners**, related markets, and consumers,
which counsels against a broad payment ban.
That looks like a huge sigh of relief for Mozilla, who were at risk of losing a sizable portion of their income if Google's search distribution revenue were to be cut off. |
2025-09-03 08:56:30+00:00 |
| Making XML human-readable without XSLT |
https://jakearchibald.com/2025/making-xml-human-readable-without-xslt/ |
In response to the [recent discourse](https://simonwillison.net/2025/Aug/19/xslt/) about XSLT support in browsers, Jake Archibald shares a new-to-me alternative trick for making an XML document readable in a browser: adding the following element near the top of the XML:
<script
xmlns="http://www.w3.org/1999/xhtml"
src="script.js" defer="" />
That `script.js` will then be executed by the browser, and can swap out the XML with HTML by creating new elements using the correct namespace:
const htmlEl = document.createElementNS(
'http://www.w3.org/1999/xhtml',
'html',
);
document.documentElement.replaceWith(htmlEl);
// Now populate the new DOM |
2025-09-02 19:32:57+00:00 |
| Rich Pixels |
https://github.com/darrenburns/rich-pixels |
Neat Python library by Darren Burns adding pixel image support to the Rich terminal library, using tricks to render an image using full or half-height colored blocks.
Here's [the key trick](https://github.com/darrenburns/rich-pixels/blob/a0745ebcc26b966d9dbac5875720364ee5c6a1d3/rich_pixels/_renderer.py#L123C25-L123C26) - it renders Unicode ▄ (U+2584, "lower half block") characters after setting a foreground and background color for the two pixels it needs to display.
I got GPT-5 to [vibe code up](https://chatgpt.com/share/68b6c443-2408-8006-8f4a-6862755cd1e4) a `show_image.py` terminal command which resizes the provided image to fit the width and height of the current terminal and displays it using Rich Pixels. That [script is here](https://github.com/simonw/tools/blob/main/python/show_image.py), you can run it with `uv` like this:
uv run https://tools.simonwillison.net/python/show_image.py \
image.jpg
Here's what I got when I ran it against my V&A East Storehouse photo from [this post](https://simonwillison.net/2025/Aug/27/london-culture/):
 |
2025-09-02 11:05:23+00:00 |
| Introducing gpt-realtime |
https://openai.com/index/introducing-gpt-realtime/ |
Released a few days ago (August 28th), `gpt-realtime` is OpenAI's new "most advanced speech-to-speech model". It looks like this is a replacement for the older `gpt-4o-realtime-preview` model that was released [last October](https://openai.com/index/introducing-the-realtime-api/).
This is a slightly confusing release. The previous realtime model was clearly described as a variant of GPT-4o, sharing the same October 2023 training cut-off date as that model.
I had expected that `gpt-realtime` might be a GPT-5 relative, but its training date is still October 2023 whereas GPT-5 is September 2024.
`gpt-realtime` also shares the relatively low 32,000 context token and 4,096 maximum output token limits of `gpt-4o-realtime-preview`.
The only reference I found to GPT-5 in the documentation for the new model was a note saying "Ambiguity and conflicting instructions degrade performance, similar to GPT-5."
The [usage tips](https://platform.openai.com/docs/guides/realtime-models-prompting#general-usage-tips) for `gpt-realtime` have a few surprises:
> **Iterate relentlessly**. Small wording changes can make or break behavior.
>
> Example: Swapping “inaudible” → “unintelligible” improved noisy input handling. [...]
>
> **Convert non-text rules to text**: The model responds better to clearly written text.
>
> Example: Instead of writing, "IF x > 3 THEN ESCALATE", write, "IF MORE THAN THREE FAILURES THEN ESCALATE."
There are a whole lot more prompting tips in the new [Realtime Prompting Guide](https://cookbook.openai.com/examples/realtime_prompting_guide).
OpenAI list several key improvements to `gpt-realtime` including the ability to configure it with a list of MCP servers, "better instruction following" and the ability to send it images.
My biggest confusion came from [the pricing page](https://openai.com/api/pricing/), which lists separate pricing for using the Realtime API with `gpt-realtime` and GPT-4o mini. This suggests to me that the old [gpt-4o-mini-realtime-preview](https://platform.openai.com/docs/models/gpt-4o-mini-realtime-preview) model is still available, despite it no longer being listed on the [OpenAI models page](https://platform.openai.com/docs/models).
`gpt-4o-mini-realtime-preview` is a **lot** cheaper:
<table>
<thead>
<tr>
<th>Model</th>
<th>Token Type</th>
<th>Input</th>
<th>Cached Input</th>
<th>Output</th>
</tr>
</thead>
<tbody>
<tr>
<td rowspan="3">gpt-realtime</td>
<td>Text</td>
<td>$4.00</td>
<td>$0.40</td>
<td>$16.00</td>
</tr>
<tr>
<td>Audio</td>
<td>$32.00</td>
<td>$0.40</td>
<td>$64.00</td>
</tr>
<tr>
<td>Image</td>
<td>$5.00</td>
<td>$0.50</td>
<td>-</td>
</tr>
<tr>
<td rowspan="2">gpt-4o-mini-realtime-preview</td>
<td>Text</td>
<td>$0.60</td>
<td>$0.30</td>
<td>$2.40</td>
</tr>
<tr>
<td>Audio</td>
<td>$10.00</td>
<td>$0.30</td>
<td>$20.00</td>
</tr>
</tbody>
</table>
The mini model also has a much longer 128,000 token context window.
**Update**: Turns out that was [a mistake in the documentation](https://twitter.com/_agamble/status/1962839472837361807), that mini model has a 16,000 token context size.
**Update 2**: OpenAI's [Peter Bakkum clarifies](https://twitter.com/pbbakkum/status/1962901822135525695):
> There are different voice models in API and ChatGPT, but they share some recent improvements. The voices are also different.
>
> gpt-realtime has a mix of data specific enough to itself that its not really 4o or 5 |
2025-09-01 17:34:55+00:00 |
| Cloudflare Radar: AI Insights |
https://radar.cloudflare.com/ai-insights |
Cloudflare launched this dashboard [back in February](https://blog.cloudflare.com/expanded-ai-insights-on-cloudflare-radar/), incorporating traffic analysis from Cloudflare's network along with insights from their popular 1.1.1.1 DNS service.
I found this chart particularly interesting, showing which documented AI crawlers are most active collecting training data - lead by GPTBot, ClaudeBot and Meta-ExternalAgent:
Cloudflare's DNS data also hints at the popularity of different services. ChatGPT holds the first place, which is unsurprising - but second place is a hotly contested race between Claude and Perplexity and #4/#5/#6 is contested by GitHub Copilot, Perplexity, and Codeium/Windsurf.
Google Gemini comes in 7th, though since this is DNS based I imagine this is undercounting instances of Gemini on `google.com` as opposed to `gemini.google.com`.
 |
2025-09-01 17:06:56+00:00 |
| Claude Opus 4.1 and Opus 4 degraded quality |
https://status.anthropic.com/incidents/h26lykctfnsz |
Notable because often when people complain of degraded model quality it turns out to be unfounded - Anthropic in the past have emphasized that they don't change the model weights after releasing them without changing the version number.
In this case a botched upgrade of their inference stack cause a genuine model degradation for 56.5 hours:
> From 17:30 UTC on Aug 25th to 02:00 UTC on Aug 28th, Claude Opus 4.1 experienced a degradation in quality for some requests. Users may have seen lower intelligence, malformed responses or issues with tool calling in Claude Code.
>
> This was caused by a rollout of our inference stack, which we have since rolled back for Claude Opus 4.1. [...]
>
> We’ve also discovered that Claude Opus 4.0 has been affected by the same issue and we are in the process of rolling it back. |
2025-08-30 21:04:13+00:00 |
| Talk Python: Celebrating Django's 20th Birthday With Its Creators |
https://talkpython.fm/episodes/show/518/celebrating-djangos-20th-birthday-with-its-creators |
I recorded this podcast episode recently to celebrate Django's 20th birthday with Adrian Holovaty, Will Vincent, Jeff Triplet, and Thibaud Colas.
> We didn’t know that it was a web framework. We thought it was a tool for building local newspaper websites. [...]
>
> Django’s original tagline was ‘Web development on journalism deadlines’. That’s always been my favorite description of the project. |
2025-08-29 20:02:50+00:00 |
| The perils of vibe coding |
https://www.ft.com/content/5b3d410a-6e02-41ad-9e0a-c2e4d672ca00 |
I was interviewed by Elaine Moore for this opinion piece in the Financial Times, which ended up in the print edition of the paper too! I picked up a copy yesterday:
<a href="https://static.simonwillison.net/static/2025/ft.jpeg" style="text-decoration: none; border-bottom: none"><img src="https://static.simonwillison.net/static/2025/ft.jpeg" alt="The perils of vibe coding - A new OpenAI model arrived this month with a glossy livestream, group watch parties and a lingering sense of disappointment. The YouTube comment section was underwhelmed. “I think they are all starting to realize this isn’t going to become the world like they thought it would,” wrote one viewer. “I can see it on their faces.” But if the casual user was unimpressed, the AI model’s saving grace may be vibe. Coding is generative AI’s newest battleground. With big bills to pay, high valuations to live up to and a market wobble to erase, the sector needs to prove its corporate productivity chops. Coding is hardly promoted as a business use case that already works. For one thing, AI-generated code holds the promise of replacing programmers — a profession of very well paid people. For another, the work can be quantified. In April, Microsoft chief executive Satya Nadella said that up to 50 per cent of the company’s code was now being written by AI. Google chief executive Sundar Pichai has said the same thing. Salesforce has paused engineering hires and Mark Zuckerberg told podcaster Joe Rogan that Meta would use AI as a “mid-level engineer” that writes code. Meanwhile, start-ups such as Replit and Cursor’s Anysphere are trying to persuade people that with AI, anyone can code. In theory, every employee can become a software engineer. So why aren’t we? One possibility is that it’s all still too unfamiliar. But when I ask people who write code for a living they offer an alternative suggestion: unpredictability. As programmer Simon Willison put it: “A lot of people are missing how weird and funny this space is. I’ve been a computer programmer for 30 years and [AI models] don’t behave like normal computers.” Willison is well known in the software engineering community for his AI experiments. He’s an enthusiastic vibe coder — using LLMs to generate code using natural language prompts. OpenAI’s latest model GPT-3.1s, he is now favourite. Still, he predicts that a vibe coding crash is due if it is used to produce glitchy software. It makes sense that programmers — people who are interested in finding new ways to solve problems — would be early adopters of LLMs. Code is a language, albeit an abstract one. And generative AI is trained in nearly all of them, including older ones like Cobol. That doesn’t mean they accept all of its suggestions. Willison thinks the best way to see what a new model can do is to ask for something unusual. He likes to request an svg (an image made out of lines described with code) of a pelican on a bike and asks it to remember the chickens in his garden by name. Results can be bizarre. One model ignored key prompts in favour of composing a poem. Still, his adventures in vibe coding sound like an advert for the sector’s future. Anthropic’s Claude Code, the favoured model for developers, to make an OCR (optical character recognition) software loves screenshots) tool that will copy and paste text from a screenshot. He wrote software that summarises blog comments and has planned to cut a custom tool that will alert him when a whale is visible from his Pacific coast home. All this by typing prompts in English. It’s sounds like the sort of thing Bill Gates might have had in mind when he wrote that natural language AI agents would bring about “the biggest revolution in computing since we went from typing commands to tapping on icons”. But watching code appear and know how it works are two different things. My efforts to make my own comment summary tool produced something unworkable that gave overly long answers and then congratulated itself as a success. Willison says he wouldn’t use AI-generated code for projects he planned to ship out unless he had reviewed each line. Not only is there the risk of hallucination but the chatbot’s desire to be agreeable means it may an unusable idea works. That is a particular issue for those of us who don’t know how to fix the code. We risk creating software with hidden problems. It may not save time either. A study published in July by the non-profit Model Evaluation and Threat Research assessed work done by 16 developers — some with AI tools, some without. Those using AI assistance it had made them faster. In fact it took them nearly a fifth longer. Several developers I spoke to said AI was best used as a way to talk through coding problems. It’s a version of something they call rubber ducking (after their habit of talking to the toys on their desk) — only this rubber duck can talk back. As one put it, code shouldn’t be judged by volume or speed. Progress in AI coding is tangible. But measuring productivity gains is not as neat as a simple percentage calculation."></a>
From the article, with links added by me to relevant projects:
> Willison thinks the best way to see what a new model can do is to ask for something unusual. He likes to request an SVG (an image made out of lines described with code) of [a pelican on a bike](https://simonwillison.net/tags/pelican-riding-a-bicycle/) and asks it to remember the chickens in his garden by name. Results can be bizarre. One model ignored his prompts in favour of [composing a poem](https://simonwillison.net/2025/Aug/14/gemma-3-270m/).
>
> Still, his adventures in vibe coding sound like an advert for the sector. He used Anthropic's Claude Code, the favoured model for developers, to [make an OCR](https://simonwillison.net/2024/Mar/30/ocr-pdfs-images/) (optical character recognition - software loves acronyms) tool that will copy and paste text from a screenshot.
>
> He wrote software that [summarises blog comments](https://til.simonwillison.net/llms/claude-hacker-news-themes) and has plans to build a custom tool that will alert him when a whale is visible from his Pacific coast home. All this by typing prompts in English.
I've been talking about that whale spotting project for far too long. Now that it's been in the FT I really need to build it.
(On the subject of OCR... I tried extracting the text from the above image using GPT-5 and got a [surprisingly bad result](https://chatgpt.com/share/68b1e707-add0-8006-8344-4c2fca902b2e) full of hallucinated details. Claude Opus 4.1 [did a lot better](https://claude.ai/share/e98d2fe1-0c81-4f51-8739-483f843e4c0e) but still made some mistakes.) |
2025-08-29 17:51:10+00:00 |
| Python: The Documentary |
https://youtu.be/GfH4QL4VqJ0 |
New documentary about the origins of the Python programming language - 84 minutes long, built around extensive interviews with Guido van Rossum and others who were there at the start and during the subsequent journey. |
2025-08-28 19:49:51+00:00 |
| Piloting Claude for Chrome |
https://www.anthropic.com/news/claude-for-chrome |
Two days ago [I said](https://simonwillison.net/2025/Aug/25/agentic-browser-security/):
> I strongly expect that the *entire concept* of an agentic browser extension is fatally flawed and cannot be built safely.
Today Anthropic announced their own take on this pattern, implemented as an invite-only preview Chrome extension.
To their credit, the majority of the [blog post](https://www.anthropic.com/news/claude-for-chrome) and accompanying [support article](https://support.anthropic.com/en/articles/12012173-getting-started-with-claude-for-chrome) is information about the security risks. From their post:
> Just as people encounter phishing attempts in their inboxes, browser-using AIs face prompt injection attacks—where malicious actors hide instructions in websites, emails, or documents to trick AIs into harmful actions without users' knowledge (like hidden text saying "disregard previous instructions and do [malicious action] instead").
>
> Prompt injection attacks can cause AIs to delete files, steal data, or make financial transactions. This isn't speculation: we’ve run “red-teaming” experiments to test Claude for Chrome and, without mitigations, we’ve found some concerning results.
Their 123 adversarial prompt injection test cases saw a 23.6% attack success rate when operating in "autonomous mode". They added mitigations:
> When we added safety mitigations to autonomous mode, we reduced the attack success rate of 23.6% to 11.2%
I would argue that 11.2% is still a catastrophic failure rate. In the absence of 100% reliable protection I have trouble imagining a world in which it's a good idea to unleash this pattern.
Anthropic don't recommend autonomous mode - where the extension can act without human intervention. Their default configuration instead requires users to be much more hands-on:
> * **Site-level permissions**: Users can grant or revoke Claude's access to specific websites at any time in the Settings.
> * **Action confirmations**: Claude asks users before taking high-risk actions like publishing, purchasing, or sharing personal data.
I really hate being stop energy on this topic. The demand for browser automation driven by LLMs is significant, and I can see why. Anthropic's approach here is the most open-eyed I've seen yet but it still feels doomed to failure to me.
I don't think it's reasonable to expect end users to make good decisions about the security risks of this pattern. |
2025-08-26 22:43:25+00:00 |