This is a fast path to open source irrelevancy, since the US copyright office has deemed LLM outputs to be uncopyrightable. This means that as more uncopyrightable LLM outputs are integrated into nominally open source codebases, value leaks out of the project, since the open source licences are not operative on public domain code.

That means that the public domain, AI generated code can be reused without attribution, and in the case of copyleft licences - can even be used in closed source projects.

I made a video if you want to watch instead.

• Copyleft History
  • License Choice
• LLM Code is Uncopyrightable
  • The Monkey Selfie Copyright Dispute
    • Copyright and LLMs
  • LLM Code and Open Source
• chardet
• Malus
• LLM Contributions

Last year, I wrote that big tech AI’s gobbling of data was particularly damaging to open source and free culture communities, since by taking advantage of those who share freely, they destroy the bargain that made free software spread like wildfire.

While back then I talked about the communities surrounding open source, the damage has now arrived to the open source projects themselves.

With tools like Anthropic’s Claude and other coding LLMs, contributors are hollowing out open source – and often, the maintainers are gleeful partners in their destruction.

Like in that last post, I’m focusing on projects that use copyleft or weak copyleft licenses like the GPL, LGPL, and MPL. That is because copyleft licenses require reciprocity – they require that derivative works are distributed under the same license terms.

As you know, derivative works are works that use parts of an original work in a new work.

Copyleft History

The concept of copyleft was described in Richard Stallman’s GNU Manifesto in 1985, where he wrote:

GNU is not in the public domain. Everyone will be permitted to modify and redistribute GNU, but no distributor will be allowed to restrict its further redistribution. That is to say, proprietary modifications will not be allowed. I want to make sure that all versions of GNU remain free.

Stallman worked within the framework of existing law to promote this idea, and formalized it in the Emacs General Public License, which later evolved to the GNU GPL - now one of the most popular free-software licenses.

Copyleft or weak copyleft licences are used for many of the best known open source projects - like Linux, Git, WordPress, VLC, MySQL and Firefox.

Copyleft licenses differ from permissive licenses like the BSD, MIT and Apache licenses. Under permissive licenses, there is no requirement for derivative works to be reciprocally licensed. This means that permissive licenses allow derivative works to be closed source.

There is real disagreement in the open source world around license choice. The schism between copyleft and permissive licences is a real one, and there have been years of discussion about which type of license is the right one for a particular project.

Copyleft licenses are sometimes derisively called “viral” - former Microsoft CEO Steve Ballmer famously called Linux a cancer, saying that:

Open source is not available to commercial companies. The way the license is written, if you use any open-source software, you have to make the rest of your software open source.

and

Linux is not in the public domain. Linux is a cancer that attaches itself in an intellectual property sense to everything it touches. That’s the way that the license works.

While Ballmer was wrong about Linux, many businesses prefer to avoid copyleft licenses, since they want to be able to not share alike – they want to be able to close their products.

License Choice

While I’m getting into the weeds around license choice, it is interesting to observe the progression of two major open source operating system families - the BSD derivatives and GNU/Linux distributions. BSD developers have prized quality and reliability, and have long felt that they stood apart from the Linux developer community as be being more “free” – since they are more permissively licensed.

As NetBSD explains in Why the NetBSD Project uses a Berkeley-style license:

One thing that some people don’t realize about Berkeley-style licenses is that they allow licensees (the users of the licensed work) to sell the code, in any form, with or without modification, and that they make no requirement that licensees give away the source code, even if they’re selling binaries. This provides a striking contrast to the license terms granted by the GNU General Public License, because the GPL requires that, if you’re distributing binaries, you must be willing to give away the sources to build those binaries.

Those of us working on the NetBSD Project are aware of this distinction, and some even value it. As stated above, we want anyone to be able to use the NetBSD operating system for whatever they want, just as long as they follow the few restrictions made by our license terms. Additionally, we don’t think it’s right to require people who add to our work and want to distribute the results (for profit or otherwise) to give away the source to their additions; they made the additions, and they should be free to do with them as they wish.

Since commercial vendors can close-source BSD code, it has been used in closed source products like Apple’s macOS and Sony’s Orbis OS (used in its PlayStation consoles since the PS3).

The open source BSD desktop has not progressed as quickly as the Linux desktop has, however. Linux advocates have long argued that the viral nature of the GPL promoted sharing beyond what the BSD license asks. While BSD licenses allow you to share, copyleft licenses enforce sharing. This ends up ensuring that more code is kept open in the Linux world.

As David Wheeler commented:

I think there is one primary reason Linux-based systems completely dominate the *BSDs’ market share - Linux uses the protective GPL license, and the *BSDs use the permissive (“BSD-style”) licenses. The BSD license has been a lot of trouble for all the *BSDs, even though they keep protesting that it’s good for them. But look what happens. Every few years, for many years, someone has said, “Let’s start a company based on this BSD code!” BSD/OS in particular comes to mind, but Sun (SunOS) and others have done the same. They pull the *BSD code in, and some of the best BSD developers, and write a proprietary derivative. But as a proprietary vendor, their fork becomes expensive to self-maintain, and eventually the company founders or loses interest in that codebase (BSD/OS is gone; Sun switched to Solaris). All that company work is then lost forever, and good developers were sucked away during that period. Repeat, repeat, repeat. That’s enough by itself to explain why the BSDs don’t maintain the pace of Linux kernel development.

…

BSD license advocates claim that the BSD is more “business friendly”, but if you look at actual practice, that argument doesn’t wash. The GPL has created a “safe” zone of cooperation among companies, without anyone having to sign complicated legal documents. A company can’t feel safe contributing code to the BSDs, because its competitors might simply copy the code without reciprocating. There’s much more corporate cooperation in the GPL’ed kernel code than with the BSD’d kernel code. Which means that in practice, it’s actually been the GPL that’s most “business-friendly”.

LLM Code is Uncopyrightable

Some people who use coding LLMs may not know that the output of LLMs are not copyrightable. While commenters will retort that this applies to the American notion of copyright, it is worth remembering that the open source licenses in common use are based on the American notion of copyright.

In the US context, the copyright office has rightly concluded that LLM outputs cannot be copyrighted as they are not the creative output of a human. They compare LLM outputs to being comparable to work for hire, where you may ask an employee to create some work for you.

As the Third Circuit explained, when a person hires someone to execute their expression, “that process must be rote or mechanical transcription that does not require intellectual modification or highly technical enhancement” for the delegating party to claim copyright authorship in the final work. Although entering prompts into a generative AI system can be seen as similar to providing instructions to an artist commissioned to create a work, there are key differences. In a human-to-human collaboration, the hiring party is able to oversee, direct, and understand the contributions of a commissioned human artist. Depending on the nature of each party’s contributions, the artist may be the sole author, or the outcome may be a joint work or work made for hire.

…

Prompts do not appear to adequately determine the expressive elements produced, or control how the system translates them into an output.

The copyright office says that when an employer directs an artist to create a work, the employer is able to “oversee, direct, and understand the contributions”. Based on the how they each contributed to the work, the artist may be the sole author, or it may end up becoming a joint work, or a work for hire.

The Office concludes that, given current generally available technology, prompts alone do not provide sufficient human control to make users of an AI system the authors of the output. Prompts essentially function as instructions that convey unprotectible ideas. While highly detailed prompts could contain the user’s desired expressive elements, at present they do not control how the AI system processes them in generating the output.

They conclude by saying that there isn’t enough expressive input in the prompts used by humans to instruct the LLMs to generate output that would make it copyrightable. The apparent “creativity” is attributable to the LLM, which is not a human.

Programmers may believe that they have a way out - they can simply test the code, or review it and commit it under their own name - that is certainly creative enough. Unfortunately, not according to the copyright office. The only portions of the work that can be copyrighted are the actual creative work the person has put into the work. If the person changes 10 lines in a 1,000 line changeset, that person holds copyright only to the 10 lines they modified. Everything else is uncopyrightable slop.

A lot of programmers are going to struggle with this, since clearly the code compiles, and it may even be of high quality. The problem is, copyright is not based on whether something works or is desirable, but rather if it is creative - and created by a human.

The Monkey Selfie Copyright Dispute

We can see this clearly in the case of the monkey selfie copyright dispute.

In the late 2000s, British wildlife photographer David J. Slater traveled to Indonesia, befriended a group of wild macaques, and set up his camera equipment in a way that a monkey selfie might happen. He then reviewed the photos the monkeys took and licensed them commercially. He believed that his action of arranging the scene in a way that that a selfie might be made had imbued the work with enough creative input from him to claim the copyright to the work.

It is a little confusing, so I’m going to say it directly. Mr. Slater didn’t take the photos. Monkeys did.

Unfortunately for Mr. Slater, in August of 2014, the US Copyright office published an opinion to clarify that “only works created by a human can be copyrighted under United States law,” - this “excludes photographs and artwork created by animals or by machines without human intervention”. They went on to say that the [copyright] office would “refuse to register a claim if it determines that a human being did not create the work. The Office will not register works produced by nature, animals, or plants.”

Copyright and LLMs

If we apply this logic to code produced by LLMs, the human orders the LLM to generate some output. They then examine the output, and consider it to be desirable. They show the code to other people, who also like it – this would be something like code review. If everyone is on the same page that the LLM output was desirable, they are free to use the code for whatever purposes they want.

The one thing they can’t do is copyright it. The only thing they can copyright are the creative inputs they made to the work. If during code review, a human changes a few lines of code, those lines would be copyright the human that wrote or modified the code. If on the other hand, another LLM is doing the code review and modifies some code, it’s all still slop.

Simply examining the code and deciding it is good is like examining the photo that a monkey took – it might be good code, or a good photo, but it wasn’t creative output from a human. Thus, it is uncopyrightable.

What does that mean for the code in question?

If the code is uncopyrightable, it is in the public domain. Since it is in the public domain, anyone is free to use it for any purpose they wish.

LLM Code and Open Source

Unfortunately, this presents a real challenge for open source.

Since the foundations of open source are the copyright regime, people can only release their code under an open source license if they hold the copyright. If the code in question was generated by an LLM with no further creative input (remember that testing isn’t creative input into the work), the code cannot be licensed as anything but public domain. People cannot bind others from using that output for whatever purposes they wish, and people can’t expect that they will abide by terms like reciprocity for derivative works.

This fundamentally destroys the bargain of copyleft licenses – without the requirement of reciprocity, the LLM code acts more like BSD licensed code – people can take it and use it for whatever purpose they wish.

Permissive license aficionados may see no problem here - they pride themselves as being more free then copyleft advocates, and while those licenses often require attribution - letting people know that the code is being used - ignoring that requirement may not bother them a whole lot.

Not so for the copyleft licenses. Those licences specifically bind derivative works to reciprocity – a requirement that cannot be enforced if the code is not copyrightable.

This means that as LLM generated code is incorporated into codebases that call themselves copyleft, value leaks out of the project. Maintainers cannot prevent the LLM code from being incorporated into closed source projects without reciprocity - the license might read GPL, but the code is public domain.

Some open source maintainers either don’t believe this to be true, or don’t understand the law, and have taken it upon themselves to try to avoid the binding strictures of copyleft licenses, and come up with a brilliant solution. They’ll simply command an LLM to produce a nominally “clean room” permissively licensed version of copyleft code.

chardet

That is exactly what happened to chardet.

chardet is a library that lets programmers detect the character encoding of content.

The primary contributor and maintainer of chardet for the last 12 years, dan-blanchard used Claude Code with Opus 4.6 (and superpowers!) to rewrite chardet in less than a week.

As part of the update to version 7.0.0, Blanchard announced that he relicensed the project as MIT, changing from the LGPL license. The LGPL is a copyleft license, and the MIT license is a permissive license.

chardet’s original author (Mark Pilgrim) came out of the woodwork and informed the project maintainers that they had no right to relicense the project.

He says:

However, it has been brought to my attention that, in the release 7.0.0, the maintainers claim to have the right to “relicense” the project. They have no such right; doing so is an explicit violation of the LGPL. Licensed code, when modified, must be released under the same LGPL license. Their claim that it is a “complete rewrite” is irrelevant, since they had ample exposure to the originally licensed code (i.e. this is not a “clean room” implementation). Adding a fancy code generator into the mix does not somehow grant them any additional rights.

I respectfully insist that they revert the project to its original license.

The current maintainer responded to Pilgrim by asserting that they had the right to relicense, since this was not a derivative work of the original chardet - he claimed that the Claude generated code is a so-called “clean-room” implementation.

We’ll come back to that later.

Blanchard also explained why he tried to relicense the project under a more permissive license – he wanted to be able to include chardet in the Python standard library. The Python standard library needs to be permissively licensed, so chardet’s existing license didn’t qualify. Beyond that, after years of working virtually alone, he wanted some help.

About a decade ago, there was talk of trying to include chardet in the Python standard library, because it is a dependency of nearly every Python project. (I would dig up the Twitter thread but I deleted my account since then. I would be happy for anyone to point me to it if they have it.) Anyway, we couldn’t move forward with it because the standard library code has to be a more lenient license like MIT or BSD.

As the years of maintaining this project have gone on, the more and more I’ve added to it and made major changes to it, the more I’ve wanted it to become more than just a one-man shop. My main goal with relicensing is to encourage more contribution either through trying to submit it to the standard library, or just by having more people work on it who might avoid LGPL projects for whatever reason.

GitHub user Ratfink pointed out a teensy problem with that second motivation, saying:

Now that the project has eradicated all past contributions from human developers, why would I ever decide to start contributing? I can only assume my efforts would be similarly disrespected at some future date.

I said the same thing a while back about the the way Mozilla disrespected their volunteer localization community.

Blanchard explained his thoughts on why the newly licensed code was a “clean-room” implementation.

To catch you up, a clean-room design is where a team will copy a design by reverse engineering it and recreating it without infringing on the copyrights associated with the original design. This usually means that the people doing the reverse engineering can’t have ever seen the original, copyrighted design.

For example, the Wine project disallows “anyone who has seen Microsoft Windows source code (either stolen, under an NDA, disassembled, or otherwise)” to work on the project. They have a set of clean room guidelines to help contributors understand the types of techniques they can use to reverse engineer Windows features - all to ensure that they are in a legally defensible place.

Clean-room designs are a legally defensible way to copy a work, so it makes sense that Blanchard would argue that the new code was developed in a clean room.

While I’m not going to get into weeds about whether or not it makes sense to talk about a clean-room design when Claude is virtually guaranteed to have the original chardet corpus in its training data, others have figured out that they can provide a clean-room design as a service.

Malus

Enter Malus.

Malus offers a clean room as a service.

They claim that their “proprietary AI robots independently recreate any open source project from scratch”, resulting in new code with corporate-friendly licensing. As stated by their tagline, they “Liberate Open Source” from obligations like attribution or copyleft.

There’s a bunch of detail on the site about how the “liberation” works, complete with a bunch of testimonials from companies successfully generating clean-room, non-copyleft versions of open source projects.

Some of their FAQ entries are openly hostile to open source developers, like this one:

What about the original developers?

They made their choice when they released their code as “open source.” We’re simply exercising our right to independently implement the same functionality. If they wanted compensation, they should have worked for a corporation.

and in another one, where they claim to be able to free code from any license:

What licenses can you eliminate?

All of them. MIT, Apache, GPL, AGPL, LGPL, BSD, MPL—if it has terms, we can liberate you from them. Special rush pricing available for AGPL emergencies.

Back to reality.

Malus is a parody, but its homonym describes perfectly what LLM contributions or recreations of copyleft projects do to the original projects - pure malice. Hobbyists and practitioners released copyleft code with the expectation that their contributions would remain free forever, with the stipulation that modifications to their code would also remain free forever.

LLM Contributions

If copyleft codebases accept public domain AI generated code into their codebases, they are signing up to hollow out their projects from the inside out. The provisions of the copyleft license listed in the repository are no longer operative for the LLM generated code, so projects can no longer enforce attribution or reciprocity.

That leaves the license to be a lie, and every contributor who contributed under the original license is being robbed, as those contributions were released under the stipulation that derivative works based on their work would also remain free. With LLM contributions, that is no longer the case.

While everyone may not feel strongly that they are being wronged, many will – contributors could have chosen to contribute to permissively licensed codebases, but instead decided to contribute to copyleft codebases. For many, the license is an incentive, and they feel strongly that copyleft is enforced. With the acceptance of AI generated slop into copyleft codebases, maintainers are changing the terms of the project - sometimes decades after people originally contributed.

As Malus shows us, this is not good for open source. If the reciprocal provisions of copyleft licenses can no longer be enforced, it may mean that people will share less. People may not bother contributing to a project that says it is copylefted, but devalues its own contributors by being willing to violate the license to accept AI slop.

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.

While the feature is problematic, commenters pointed out that some previews are helpful – e.g. on Wikipedia, where a preview will appear when people hover over a wiki-linked page.

Other commenters pondered about some minimal way to replicate this elsewhere, and it seemed to be worth investigation. Read on as I propose an enhancement to the Fediverse (and maybe even web standards) to make Link Previews great: the Link Preview Manifest.

No video for this post, since I was boring myself as I recorded.

• Introduction
• Link Preview Manifest
  • Discovery Mechanism
    • HTTP Headers
    • Guessed Fallback
    • Link in HTML
  • Preview File
  • Examples
    • Article With Preview Image
    • Image Gallery
    • Video
    • Storage
  • Client Flow
    • Step 1: Header-based Discovery
    • Step 2: Fallback Discovery
    • Step 3: Fetch the Link Preview Manifest
    • Step 4: Verify Integrity
    • Step 5: Cache
    • Step 6: Parse and Render
• Conclusion

Introduction

Link previews are seemingly one of those web features that mostly work – until they they start to scale, and you need to figure out how the sausage is made.

The Firefox implementation shows why. There, generating a preview means retrieving a page’s HTML and parsing it, discarding most of what was downloaded. Firefox is just one client, though.

In federated systems, where a single link can fan out across thousands of timelines and clients, this behavior can accidentally lead to distributed denial-of-service (DDOS) attacks, as observed by publishers using Mastodon.

In a 2024 article, It’s FOSS asked people to not share their links on Mastodon, explaining that:

When you share a link on Mastodon, a link preview is generated for it, right?

With Mastodon being a federated platform (a part of the Fediverse), the request to generate a link preview is not generated by just one Mastodon instance. There are many instances connected to it who also initiate requests for the content almost immediately.

And, this “fediverse effect” increases the load on the website’s server in a big way.

Sure, some websites may not get overwhelmed with the requests, but Mastodon does generate numerous hits, increasing the load on the server. Especially, if the link reaches a profile with more followers (and a broader network of instances).

Things have not improved much since then.

Link Previews as generated by most user agents are expensive to create, since many of the pages being previewed are generated dynamically, increasing resource usage and page generation time.

There’s got to be a better way, and in this post, I am proposing one: Link Preview Manifest.

Please steal this idea if it is good!

Link Preview Manifest

A Link Preview Manifest is a small, cacheable resource that provides preview-specific metadata for a URL without requiring clients to fetch or parse the full HTML document.

Publishing software can generate this resource whenever the previewed document is created or updated once and it can be stored as a static file that does not need to be regenerated for each link preview request.

Discovery Mechanism

HTTP Headers

User agents can request a preview for a URI via a call to get the HEAD of a URI:

HEAD https://example.com/posts/hello-world/

User agents would receive some headers in response.

HTTP/1.1 200 OK
Link: <https://example.com/posts/hello-world/index.preview.json>; rel="link-preview"
Link-Preview: available
Cache-Control: max-age=86400

Upon receipt of the URI’s HTTP headers, user agents should inspect the headers for a Link relation advertising a preview resource. If a resource is advertised, the user agent can GET the preview resource, rather than the URI being previewed.

This separates discovery from retrieval and avoids the expense of page generation and transfer. This differs from the existing solutions, which require user agents to GET the entire page to parse link preview metadata.

The Link header is used since it already provides a standardized mechanism for advertising related resources.

Guessed Fallback

While the primary discovery mechanism for link previews is Link header metadata, user agents can also look for previews in the page URI + .preview.json

Link in HTML

If publishers can’t set headers, they can instead define link previews as external resources:

<link rel="link-preview" href="index.preview.json" type="application/link-preview+json">

This is a secondary fallback, in situations where the publisher is on shared hosting or cannot update web server behavior to support updating Link headers.

Preview File

The preview JSON file is a small, cacheable and verifiable representation of a web resource, intended for link previews in clients. Its purpose is to allow clients to render previews without needing to download the actual resource, and supports identity verification for safe caching and federation.

Examples

Article With Preview Image

{
  "version": 1,
  "type": "article",
  "title": "Why Link Previews Should Be Explicit",
  "description": "An argument for a lightweight web standard that avoids HTML scraping and supports federation.",
  "url": "https://example.com/blog/explicit-link-previews",
  "site": {
    "name": "Example Blog",
    "url": "https://example.com"
  },
  "published": "2026-02-09T12:00:00Z",
  "images": [
    {
      "url": "https://example.com/media/explicit-previews.jpg",
      "width": 1200,
      "height": 630,
      "integrity": "sha256-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa="
    }
  ],
  "cache": {
    "max_age": 86400
  },
  "integrity": "sha256-bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb="
}

Image Gallery

{
  "version": 1,
  "type": "photo",
  "title": "Weekend in Kyoto",
  "description": "A short photo set from a weekend trip to Kyoto.",
  "url": "https://example.com/photos/kyoto-weekend",
  "site": {
    "name": "Example Photos",
    "url": "https://example.com"
  },
  "images": [
    {
      "url": "https://example.com/media/kyoto-1.jpg",
      "width": 1080,
      "height": 1080,
      "integrity": "sha256-ccccccccccccccccccccccccccccccccccccccccccc="
    },
    {
      "url": "https://example.com/media/kyoto-2.jpg",
      "width": 1080,
      "height": 1080,
      "integrity": "sha256-ddddddddddddddddddddddddddddddddddddddddddd="
    },
    {
      "url": "https://example.com/media/kyoto-3.jpg",
      "width": 1080,
      "height": 1080,
      "integrity": "sha256-eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee="
    }
  ],
  "cache": {
    "max_age": 43200
  },
  "integrity": "sha256-fffffffffffffffffffffffffffffffffffffffffff="
}

Video

{
  "version": 1,
  "type": "video",
  "title": "Federation Without Scraping",
  "description": "A short talk on making link previews cheaper and safer for the fediverse.",
  "url": "https://example.com/videos/federation-without-scraping",
  "site": {
    "name": "Example Videos",
    "url": "https://example.com"
  },
  "images": [
    {
      "url": "https://example.com/media/video-poster.jpg",
      "width": 1280,
      "height": 720,
      "integrity": "sha256-1111111111111111111111111111111111111111111="
    }
  ],
  "video": {
    "url": "https://example.com/media/federation-talk.mp4",
    "width": 1280,
    "height": 720,
    "duration": 315,
    "integrity": "sha256-2222222222222222222222222222222222222222222="
  },
  "cache": {
    "max_age": 86400
  },
  "integrity": "sha256-3333333333333333333333333333333333333333333="
}

Storage

Preview files can be generated statically as separate .preview.json files per page. These files can be generated at build time, alongside HTML.

On disk, this would look like:

/article/index.html
/article/index.preview.json

Client Flow

Step 1: Header-based Discovery

When a client wants to get link preview metadata:

• Perform a HEAD request to the URL.
• Look for a Link header with rel=”link-preview”.

Example:

Link: <https://example.com/article/index.preview.json>;
      rel="link-preview";
      type="application/link-preview+json"

If found, proceed to step 3.

Step 2: Fallback Discovery

If a link header is not present in HEAD, user agents can try (in order):

• Predictable adjacent file
  • Example: https://example.com/article/index.preview.json
• HTML <link> element
  • Example: <link rel="link-preview" href="index.preview.json">

Clients should stop once they successfully discover the manifest file.

Step 3: Fetch the Link Preview Manifest

Now that we know where the manifest is located, we can download it.

• Do a GET on the discovered link preview manifest
• Output:
  • Content-Type: application/link-preview+json
  • a small JSON file

Step 4: Verify Integrity

If present, clients can verify the Subresource Integrity hash. If fetching media resources, individual hashes can be verified.

If verification fails, clients may fall back to parsing the page.

Step 5: Cache

Clients should respect HTTP caching headers to minimize load on publishers.

Step 6: Parse and Render

At this point, the client has the Link Preview Manifest containing the information that would previously have been manually parsed from page HTML. As we now have a manifest that encapsulates this data in a verifiable way, we can avoid parsing of page data.

Conclusion

The way that web developers currently do link previews are inefficient and wasteful, and advantages big tech players like Facebook and X, since they are centralized and can easily absorb the costs associated with scraping pages.

The web deserves a better way: preview data that is explicit, lightweight, cacheable, and verifiable. By separating preview metadata from page content, clients can get and share metadata without forcing web servers into expensive page generation.

This proposal extends the web incrementally - advanced hosts can advertise Link Preview Manifests via page headers, while simpler setups can rely on predictible locations and fallbacks linked from HTML. Clients can adopt the standard incrementally without needing to throw away their existing functionality. The standard itself can be versioned to meet forthcoming needs.

It doesn’t make sense for publishers to not want their content posted on Mastodon because it causes their web servers to buckle under the strain. As more and more clients generate link previews, we can help scale the federated web by making link metadata cheap to advertise, transfer and consume.

Importantly, this approach does not require new infrastructure. It works with static site generators, shared hosting, CDNs, and existing HTTP semantics. Advanced hosts can benefit from cheap discovery via headers, while simpler setups can rely on predictable file locations and HTML fallbacks. Clients can adopt it incrementally and fall back to legacy scraping when necessary.

Subresource Integrity makes it possible to federate previews without centralized trust or authentication, allowing instances to cache and redistribute previews confidently. Combined with aggressive caching and small payloads, this shifts link previews from a repeated scraping problem into a solved distribution problem.

If link previews are going to remain a foundational part of the federated web, they should be treated as first-class resources. Making them explicit is a small change, but one that moves us toward a more resilient and scalable web.

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.

If we dig deeper, you can start to see that the kill switch isn’t the whole story. This feature acts like an accountability sink. By giving you an off-switch, Mozilla’s leadership shifts the ethical burden of AI onto the user - turning their design choices into your responsibility.

I made a video if you want to watch instead.

• The AI Kill Switch
  • Why
• AI Powered Translations
• A Distraction - By Design
• Reframing the Debate on AI
• Mozilla’s Betrayal of Open Source
• Opportunity Costs
• Mozilla’s AI Future

The AI Kill Switch

Mozilla’s AI controls launch in Firefox 148. It consists of a “Block AI enhancements” toggle that promises to disable current and future AI features in the browser. The options can also be toggled individually, to allow people to enable some but not all AI features. I tested the kill switch as soon as it appeared in Nightly, and it works pretty much like you might expect.

That is supposed to be the end of the conversation – it does what it was designed to do.

Mozilla frames the feature as giving users control over their browsing experience. In doing so, Mozilla is trying to reframe the debate around AI in Firefox as a question of optionality - are the features opt-in? Are they opt-out? Do users have choice?

Why

Mozilla introduced the kill switch to sidestep the concerns the Firefox community has voiced over AI and large language models.

Just two days after new Mozilla CEO Anthony Enzor-DeMeo’s introductory post announcing that Firefox would evolve into a modern AI browser (as they focus on becoming “the trusted software company”), Mozilla quickly tried to change the topic, with the Firefox for Web Developers Mastodon account promising that “Firefox will have an option to completely disable all AI features”.

By shifting the conversation away from whether Firefox should become an AI browser at all to questions about user choice, Mozilla staff now spends a lot of time pontificating about whether features are truly opt-in or not, and whether certain types of LLMs count as AI.

It is obvious what is happening here - Mozilla is shifting the burden of responsibility of choice to its users, and is excusing itself of it entirely.

What Mozilla is telling us is that AI is good actually, and while isn’t great that a large portion of their userbase doesn’t like it, it is up to them to avoid it.

AI Powered Translations

As part of the community outreach around the kill switch, Mozilla staff surveyed the Mastodon community, asking whether translation features in Firefox ought to be affected by the kill switch.

Mozilla staff said that the on-device translation models shipped in Firefox were trained on open data, and 49% of voters responded that Firefox should allow users to re-enable translations, even if other AI features were disabled.

It’s easy to understand the rationale here. If you know about how the AI models are made, you know that they are built on large-scale piracy. Big Tech companies have gone out and scraped as much content as they can get their hands on - legally or illegally (and it is mostly illegally). By saying that the translation models are trained on open data, Mozilla is in effect saying that this is “good AI” – not the AI that is built on piracy.

In just one recent example, Claude owner Anthropic recently agreed to pay $1.5 billion to settle a lawsuit over their piracy of books. Incidentally, Anthropic is also one of the vendors featured in Firefox’s AI chatbot sidebar feature.

So the concerns are real and known, so Mozilla is taking people’s concerns seriously when they engage both in the kill switch and in conversations about the ethics of LLM piracy.

Right?

That would be accurate, if it were true that Mozilla’s translation models were trained on open data. Given how Mozilla has been talking up open source AI, it would make sense if Mozilla was practicing what it preached.

After all, Mozilla is the same company that garnered community contributions for Common Voice. Common Voice is an open source data set of speech data of over 130 languages, all contributed by members of the community, including myself. That data is available to download on Mozilla’s Data Collective.

Given that history, I first looked at Mozilla’s Data Collective to find the open data that Mozilla staff was referring to.

I wasn’t able to find it, so I looked closer at the public docs for translations. Mozilla states that they use OPUS as their main resource for translation datasets.

A quick look at the Opus Corpora reveals that most of the datasets are not permissively licensed. Instead, they are scraped from copyrighted web sources, exactly like the big tech AI companies.

Why is Mozilla claiming that their models are open when they know that they aren’t? It isn’t as if Mozilla doesn’t know that open data exists – they actually host a repository of it.

A Distraction - By Design

It isn’t just that Mozilla is lying to us about the provenance of the data used in the translation engine - they are using the lie to sideline community members concerned about Mozilla co-signing the theft of the commons.

Mozilla says that there is uncertainty about whether the translation engine is AI - as if people are having a discussion about semantics.

Mozilla seems to imagine that people don’t like AI because what it is called, not because of how it works.

In their post, Mozilla specifically says that the translation engine is trained on open data. This is untrue. They then use this lie to convince people that Mozilla is somehow doing “good AI” like they are promoting elsewhere – this isn’t the bad pirated AI, this is good, homegrown AI.

Mozilla is saying “Hey, if you hate AI so much that even pure and good (and optional) AI isn’t good enough for you, we’ll let you disable it. We don’t really understand why you would want to, since it is clearly so good, but we’ll let you opt-out anyway.”

The implication is that the AI kill switch exists to protect the sensibilities of whiny Luddites, rather than to distract from Mozilla’s own failings.

When people later pointed out that the Mozilla’s translation models don’t qualify as open data, Mozilla apologized but says that they “don’t think it impacts the results”.

Right.

Reframing the Debate on AI

With the AI kill switch, Mozilla is attempting to reframe the debate on AI as a question of user choice, rather than a positive vision of Mozilla’s space in the industry.

While Mozilla has long claimed to help people break free from big tech, their latest moves have the company joining with big tech to work against their community.

While features like AI powered tab grouping and link previews might have limited utility, their uselessness help to limit the damage they do to the browser and the broader web ecosystem.

AI powered assistive image descriptions and translations are features that are useful to at least some segment of the userbase, but their usefulness are borne from the fact that they are reliant on pirated data sets.

The model for Firefox’s AI powered image description generator was partially trained by OpenAI’s GPT4-o, which itself is trained on pirated datasets.

Mozilla Translations is also trained on non-public domain data sets.

The fact that LLMs based on pirated data sets are useful is not an accident, or surprising. It would have been commendable if Mozilla had managed to train new translation models without needing to steal from the commons, like big tech has.

By obfuscating the source of the training data in shipping Mozilla products, Mozilla is trying to convince ordinary people to support the theft of the commons. After all, it is useful, and are people really against accessibility improvements?

The problem is, Mozilla isn’t being upfront about what is going on.

Mozilla is speaking out of both sides of its mouth – it’s talking about how important it is to own your stack in the world of proprietary AI – even as they themselves partake in the same piracy being practiced by the proprietary vendors.

Yes, Mozilla started their Data Collective, and I have personally contributed to Common Voice, but when it comes to Firefox (their flagship product), they are willing to ship closed AI.

That is the debate that Mozilla is trying to avoid.

In their post detailing their strategy on open source AI, Mozilla hearkens back to 25 years ago in describing “what we did for the web”:

Twenty-five years ago, Microsoft Internet Explorer controlled 95% of the browser market, which meant Microsoft controlled how most people experienced the internet and who could build what on what terms. Mozilla was born to change this, and Firefox succeeded beyond what most people thought possible — dropping Internet Explorer’s market share to 55% in just a few years and ushering in the Web 2.0 era.

Back then, Mozilla was formed from the ashes of Netscape, and what Mozilla did for the web was to fund and build a free, open source web browser that served as real competition to the big tech companies of the era.

In trying to reclaim the mantle of “leading a rebel alliance” to take on proprietary AI, Mozilla is hoping that we ignore that Firefox itself is becoming infected with big tech AI, even as they pour money into projects destined for failure.

It would mean something if Mozilla was actually building what they were claiming to build - in the past, Mozilla built Firefox as a competitor to Microsoft’s Internet Explorer. Today, Mozilla ships with chatbot integrations with multiple proprietary big tech AI providers, including the Microsoft-partnered OpenAI.

Mozilla’s $1.4bn investment in open AI is not in Firefox - Mozilla is instead investing in other companies to do what Mozilla itself doesn’t seem equipped to do. Mozilla itself will instead be partnering directly with big tech and partaking in piracy when it builds its own AI products.

Mozilla seems to believe that by simply reminding the industry that it once did great things, that we will be convinced that everything Mozilla is doing around AI is part of the same tradition.

Unfortunately, it isn’t.

Mozilla’s Betrayal of Open Source

We should have seen this coming, even before the announcement from Mozilla’s new CEO. A few months ago, Mozilla began to overwrite volunteer contributions on Support Mozilla with slop from Google’s Gemini.

That caused the Japanese translation group to disband, including the locale leader, who went by marsf and had contributed edits to over 1000 articles over 20 years.

In case you thought Gemini was open source, it isn’t. Upon the introduction of Gemini, the UK based Society of Authors wrote an open letter to Google saying:

The Society of Authors was greatly concerned to hear that, at the launch of Gemini pro, ‘Google repeatedly refused to answer questions from reporters about how it collected Gemini’s training data, where the training data came from and whether any of it was licensed from a third party’. Given the reportedly extensive infringement of copyright protected works that took place to build existing Large Language Models (LLMs), this continued lack of transparency is alarming and leads us to assume that Google has used creators’ works unlawfully and unfairly, without consent or any kind of remuneration.

Mozilla’s moves represent a double betrayal: first, they reject the community’s contributions to SUMO’s knowledgebase, then to add insult to injury, they reject the very idea of open source by implementing a closed source model based on stolen data.

The message Mozilla is sending when choosing to overwrite human contributions with stolen ones is that while Mozilla will gladly take your contributions, it is also willing to steal them.

Opportunity Costs

Some of you may be reading and saying “So what? If you don’t like it, just use the kill switch!”

That is clearly the response Mozilla wants us to have, and why the kill switch exists. Don’t get me wrong, I appreciate that the option exists for Firefox users that don’t want to be nagged to try AI features - like the nags associated with the Link Previews feature.

That doesn’t change the fact that by partnering with pirating AI vendors, and indulging in piracy itself, Mozilla helps to foreclose the introduction of the open source AI they claim to care about.

Imagine if back in 2009, when Google introduced Chrome Frame, Mozilla rushed to integrate it. If you don’t remember Chrome Frame, it was a plugin for Internet Explorer that allowed you to run Chrome’s engine in a tab.

Mozilla could have told Firefox users that the introduction of Chrome Frame in Firefox proved how far Microsoft’s Intenet Explorer had fallen, and Mozilla could take advantage of the high quality and open source web engine that Google was building.

Why bother investing in Gecko when Mozilla developers could instead work on user facing features, leaving engine work to Google? That is the path that Opera and Microsoft have gone in recent years - both have given up on developing their own web engines in order to instead develop browsers that rely on the work Google invests into Chromium. That relationship gives Google a whole lot of influence over the web platform, since their web platform is being shipped by multiple vendors - including other massive big tech companies.

Why then did it make sense for Mozilla to continue to invest in Gecko?

The obvious reason is that Gecko still exists, and since the majority of Gecko development is paid, it is Mozilla’s continued investment that has granted web users with an option to browse the web that isn’t fully owned by big tech.

That isn’t what is happening this time around.

Perhaps Mozilla doesn’t believe that they can build an open alternative to big tech AI, as they aren’t trying. Instead, they are doing what Opera, Microsoft, Vivaldi, and others are doing when they develop products on top of Chromium – they are putting a different face on the same big tech platform.

Instead of building the open AI that they exhort others to join and invest in - and shipping it, like they had with Gecko and Firefox 25 years ago, they are instead becoming just another distribution platform for the closed AI companies they claim to be against.

That isn’t an exaggeration - one of the AI features that are disabled by the kill switch is the chatbot integration in Firefox’s sidebar. The products featured here are Anthropic Claude, OpenAI ChatGPT, Google Gemini, Le Chat Mistral, and Microsoft Copilot. None of these are open source - not a single one.

You are likely familar with the concept of opportunity costs - the idea that by choosing one option, you lose out on the benefits of choosing an alternative option. That is the “cost” you pay for not taking the alternative opportunity.

We can think about this in the context of Chrome Frame. If Mozilla had integrated Chrome Frame, web developers may have more quickly decided to stop supporting both Internet Explorer and Firefox, since they could simply target Chrome, and their sites would work on every browser that had Chrome Frame.

Mozilla could have spent their resources on features to differentiate themselves from the competition - like what Microsoft and Vivaldi do today.

There would be little point in integrating Chrome Frame if Mozilla continued to be interested in developing Gecko, so the cost the web would pay would likely be the eventual disappearance of Gecko. We might still have Firefox, but investing in Chrome Frame would likely mean disinvestment in Gecko.

Mozilla investing $1.4 billion in non-Firefox AI projects while also integrating closed source, big tech AI is sending the signal that Mozilla isn’t interested in developing an open source AI, and instead is looking to get paid by big tech.

Mozilla’s pronouncements around AI are incredibly confusing if you take what they say at face value. Mozilla is telling us to not trust big tech AI and to not rent our models, all while they do exactly that. Mozilla doesn’t have an instance of Gemini running on Mozilla servers, overwriting human contributions - they are paying Google to rent their model.

Mozilla says that Mozilla Translations are open source, but they are built exactly the same way that Google’s models are built - scraping of copyrighted content without payment or permission.

Mozilla says that they are building a rebel alliance to take on industry heavyweights, all while integrating them directly in the browser, complete with nags to send them user data.

In an interview with the Guardian, CEO Enzor-DeMeo declined to be transparent about how much the partnerships with AI companies are worth to Mozilla.

I’m not a betting man, but if I were, I’d guess that Mozilla is expecting to get back more than the $1.4 billion they are pouring into AI.

Given that context, Mozilla’s investment in the so-called rebel alliance seems more like the biblical concept of indulgences – a way to reduce the punishment from committed sins. Mozilla can partner with as many big tech companies that do as much damage to the world as they want, as long as they take some of that dirty cash and put it towards some meaningless “good” projects.

It doesn’t matter that the investment is unlikely to be fruitful - the point of the investment is to forgive Mozilla for doing bad things.

Mozilla wouldn’t need to pour good money after bad around open source AI if they were actually implementing open AI solutions in-house. What seems to be happening instead is that they are partnering with the closed source big tech AI pirates, and spending some of the proceeds to wash themselves clean of the stain of copyright theft.

Mozilla’s AI Future

While Mozilla pitches the AI kill switch as an exercise in user choice, it reveals itself to be a Hobson’s choice – take it or leave it.

If we accept that Firefox becoming an AI browser will necessarily mean that Mozilla will focus less on web platform or even browser features that don’t rely on copyright theft, users have no choice but to leave it. The kill switch doesn’t change that Mozilla is partnering with copyright pirates, thereby endorsing their behavior (and getting paid for it). It doesn’t change that Mozilla is shipping AI models built on piracy in Firefox proper - no matter if it is optional or not.

The kill switch also doesn’t change the betrayal of loyal community members whose contributions are being removed in favor of big tech AI slop.

In all of these cases, Mozilla had choices.

They could have chosen to allow community members to opt into translation suggestions, like exists for Firefox in Mozilla Pontoon, instead of forcing community members to play catch up as slop overwrites human contributions.

They could have partnered with their community to help develop an open corpus like they had for Common Voice, in order to power their translation engine. The existing localizations on Support Mozilla could have been used to kickstart model creation, and volunteers could have worked with developers to tune models to ease localization work for contributors. Rather than needing to correct the same errors over and over (since paid Gemini queries don’t train the model), contributors could have been actively assisting in training an open model. Instead, Mozilla ignored their community and partnered with slop generating pirates.

Mozilla didn’t need to choose to get paid by AI vendors and to try to distract us by investing in AI projects that – let’s face it – will go nowhere. They could have instead taken that money and spent it on anything else – even home grown AI.

If AI is as amazing as advertised, Mozilla should be able to take that $1.4 billlion they are planning on pouring down the drain and instead turn it into hundreds of billions. Just think – in just 5 short years, Anthopic went from not existing to being worth over $300 billion dollars.

Is Mozilla taking home nearly that much money to secure its future, or is AI simply another way to sell the Firefox audience to big tech?

The kill switch exists as a way to distract us from the larger questions surrounding AI in Firefox. By building it, Mozilla makes AI your responsibility - you choose to use it. Mozilla’s agency never enters the picture.

We aren’t going to ask how much the AI companies are paying Mozilla for the privilege of advertising to Firefox users and gathering their data. We won’t deign to question whether Mozilla shipping pirated models in Firefox is something we ought to be concerned about – Firefox users can disable it, so Mozilla is off the hook.

AI products seem to generally serve as an accountability sink - a way to absorb or obscure the consequences of a decision such that no one can be held directly accountable for it.

The kill switch is a fantastic example of such, since by providing users with the option, the users are now the ones accountable. Mozilla can point to the switch and wash themselves of accountability and responsibility.

Mozilla isn’t responsible for your use of its AI. And that is the point.

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.

I made a video if you want to watch instead.

• Interview
  • History
  • Sustainability and Governance
  • Waterfox Features
  • AI
  • Gecko Ecosystem

With Mozilla announcing plans to turn Firefox into an “AI browser,” people are taking stock of browser options. People new to the Firefox community may be looking back towards Chromium-based options. Others are wary about helping Google extend its hegemony over the web platform and are looking to Firefox offshoots like LibreWolf and Floorp, or further afield with projects like Servo and Ladybird.

As people look for alternatives, they are rediscovering options that didn’t appear overnight. Waterfox has been around for more than a decade, built on Mozilla’s work in Firefox but bringing it to people without data collection and some user focused niceties.

As Mozilla goes off to explore the world of AI, I thought it would be interesting to catch up with Alex Kontos, the founder of Waterfox. I wanted to discuss with him what it means to build and sustain an independent browser over the long term, how Waterfox’s philosophy diverges from Mozilla’s current direction, and why there’s still value in software that doesn’t treat you like a lab rat.

I’m also taking the time to test-drive Waterfox on my own, and I’ll be following up with a review in the coming weeks.

Interview

History

QUIPPD You started Waterfox when you were 16 years old. Most people at that age are just trying to keep up with homework, and you were out there trying to outcompete Mozilla at 64bit. Looking back to that 16 year version of yourself, did you think you’d still be working on Waterfox 15 years later?

ALEX Hah, I think it’s generous calling what I started out doing as competing with Mozilla! I remember struggling at the time to find a 64-bit version of Firefox - I was enamoured with it, it was (and still is) a great bit of software. Some people were pushing out sporadic builds, but that wasn’t good enough - and here we are! I definitely thought I’d be involved with computers and software in some capacity, but maybe not still with Waterfox!

QUIPPD You sold Waterfox to System1 in 2020 and then bought it back to become independent again in 2023. Can you tell us more about what happened there?

ALEX As it happens, the System1 I joined and the System1 I left were different companies. There wasn’t much scope of a browser vision anymore, and I still felt there was untapped potential, so we went our separate ways.

Sustainability and Governance

QUIPPD Now that you are independent, how are you building a sustainable business model? How secure is Waterfox’s funding?

ALEX Up until the last year, things were great. But unfortunately with Microsoft terminating all Bing partnerships and API calls (to stop AI companies scraping the web with their services), it’s been much more difficult. Without a big player like Microsoft on the scene, other search engines are much more aggressive with their partnership agreements.

So we get okay revenue, not much, and I’ve launched Waterfox Private Search, a subscription based meta search as a way to try and be completely independently funded. I’d like to launch an Oblivious proxy too - but the whole “VPN” market (proxies is how people really use them) seems insanely saturated and I don’t want to spread myself too thin.

QUIPPD Tell me about your structure. You reference it on your recent blog post, but readers will want to know more.

ALEX Yes I’m conscious I bring that up frequently and I’m currently building out some pages to add on the website. It will be something as follows:

A “Governance” page that:

• Links to Companies House registration
• Names directors and their roles (only me)
• Explains revenue model transparently
• States our privacy commitments in plain language
• Provides contact for governance questions
• Provide information and link to our ICO Registration certificate (to show we’re beholden to things such as the UK GDPR)

There’s much more I want to flesh out and have easily accessible as well, such as security disclosure policies, partnerships guidelines etc.

QUIPPD How large is the team?

ALEX It’s just me at the moment! With the odd contributors here and there.

QUIPPD Do you have any plans for expansion?

ALEX I have dreams, but without a large revenue stream nothing that is currently feasible.

Waterfox Features

QUIPPD How do you choose what to develop? What is the core vision for Waterfox as a product?

ALEX A difficult one to answer, but at its core I’d like Waterfox to be as privacy friendly as possible while not breaking the web. A hard line to balance! I want people to feel as if they are in control of their experience and getting real use out of their browser as a productivity tool.

AI

QUIPPD You’ve been vocal about Waterfox staying ‘AI-free’ while Mozilla is becoming an AI browser. I recently learned that Mozilla’s translation engine (that you referenced in your blog post) is not trained on open data, but from crawled copyright content. Does that change your perspective on inclusion within Waterfox?

ALEX I think ‘AI-free’ isn’t my exact stance - “AI” is too broad a term to make blanket statements about. I’m cautious about LLMs specifically, and definitely against including them by default in the context of a web browser. If users want to use external AI services via extensions, their own setup (or re-enabling via toggles in Waterfox), they’re free to do so - user choice is core to Waterfox’s ethos.

My biggest concern is the unknown Mozilla has thrown out there, where it sounds like a complete pivot to AI control within the browser. Browsers like Comet and Dia seem like a recipe for disaster. I’m not downplaying the convenience, but these things aren’t perfect and putting one in the drivers seat seems wrong. On the flip side, AI has also been revolutionary for those with disabilities, so judgment shouldn’t be made in just black and white.

I was actually unaware of ParaCrawl’s data sources. Arguably it doesn’t respect the spirit of creator consent, but it seems that it’s legal in many jurisdictions and follows standard practices for research corpora. I’d need to do more research myself to form a better opinion as I believe this warrants a much more nuanced response.

QUIPPD Can you explain more about how you think about inclusion of AI features in Waterfox?

ALEX Outside of LLMs, things such as ML have been a part of Waterfox (and most software!) for a while. Translations (Bergamot), TTS/STT (DeepSpeech), URL bar ranking for local history when entering keywords and more recently, alt text generation for PDF images. These all provide real utility to end users, are implemented transparently and have been a part of the browser for years. The biggest issue I find is how LLMs are used, rather than the all encompassing “AI” term which includes many useful features over the years. It’s why in the blog post I specify that I won’t include LLMs in their current form in Waterfox

QUIPPD Do you have a perspective on you or Waterfox contributors using AI to develop Waterfox? Have you tried out AI coding at all?

ALEX I agree with Dmitry Kudryavtsev’s note on his ‘Dead Internet Theory’ post.

QUIPPD The note on Dmitry’s post reads:

NOTE I don’t mind people using AI to write code, even though I tried to resist it myself, until eventually succumbing to it. But I think it’s fair to disclose the use of AI, especially in open-source software. People on the internet are, mostly, anonymous, and it’s not always possible to verify the claims or expertise of particular individuals.

But as the amount of code is growing, considering that everyone is using AI to generate whatever-app they want, it’s impossible to verify every piece of code we are going to use. So it’s fair to know, I think, if some project is AI generated and to what extent. In the end, LLMs are just probabilistic next-token generators. And while they are getting extremely good at most simple tasks, they have the potential to wreak havoc with harder problems or edge-cases (especially if there are no experienced engineers, with domain knowledge, to review the generated code).

ALEX When it comes to contributions, I think it’s fair to ask contributors to disclose if they’ve used AI to generate code, especially for substantial changes. As Dmitry mentioned, LLMs are probabilistic - they’re great at common patterns but can introduce subtle bugs in edge cases. With Waterfox being essentially just me, I can’t review every line with the depth a larger team could. Knowing something was AI generated helps me understand where to focus review effort and what kinds of issues to look for. I also hope users aren’t just blindly tasking LLMs with creating patches for Waterfox, I’d be surprised if it wouldn’t run out of context before even being able to generate anything and it’d be such a waste of resources.

I do also use it - I find it useful as a smarter, glorified IntelliSense, as it saves typing and repetitive actions. I’ve found it useless for doing anything novel with - and of course it can’t “think” like a human does, so complex problem solving isn’t much good with it either (at least how I’ve tried? I see a lot of hubbub about it solving math problems recently). If it does get used, its usage is strict and limited. It’s great as a code search tool as well, saves me a bunch of time loading up searchfox.org or grepping through the repo.

Gecko Ecosystem

QUIPPD Does Waterfox contribute to upstream Gecko or Firefox? Is that something people can expect in the future?

ALEX It has done so in the past, mainly small inconsequential things, but I’d be more than happy to provide upstream code, if I thought it would actually be any use to Mozilla.

QUIPPD Is Gecko important to Waterfox, or would you be willing to rebase to WebKit or Chromium?

ALEX It is! But, it’s always an uphill battle as it’s not designed to be taken apart from Firefox, which makes using Gecko in isolation difficult (and makes ongoing maintenance a burden). I would be willing to work with WebKit - it’s much improved over the last few years for platforms outside of macOS and I think there’s a lot of untapped potential there.

QUIPPD What’s your strongest elevator pitch for someone trying out or switching to Waterfox?

ALEX A private web browser that stays out of your way.

Are there any questions that I missed? Leave a comment and I’ll try to get Alex to do a follow-up interview!

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.

I made a video if you want to watch instead.

• Link Previews in Beta
• Link Previews in Firefox 142
  • Link Previews
    • Criticism
• Deceptive Patterns
  • Obstruction
  • Nagging
  • Preselection
• Opt-Ins and the “Kill Switch”
• An Alternative Opt-In

Mozilla’s new CEO has a new mission to make an AI browser. The community’s reaction has been decidedly negative, with posters on social media saying that they have little to no interest in Mozilla’s AI ambitions.

Mozilla’s response to the community’s backlash towards AI was to (re)announce that they would be developing an “AI Kill Switch” to disable any existing and forthcoming AI features in Firefox.

Mozilla employees followed up on their traditional media response with a social media response, and multiple team members fielded questions from the general public.

As Firefox users asked how the “kill switch” would work, Mozilla began to sound more shifty, saying that while there are some gray areas of what “opt-in” means to different people, their kill switch would absolutely remove that stuff.

To help clear things up, Mozilla explained that the AI features in “Link Previews” has “always been opt-in”.

Link Previews in Beta

Link Previews is a feature that was first introduced in Firefox 138, as an experimental, opt-in Labs feature.

The feature was introduced as a way for users to get relevant information faster, by providing them with an image, the webpage title, and AI-generated key points.

Mozilla introduced the experiment by saying that Link Previews is “entirely optional” and that “it only appears in Firefox if you enable the feature and consent to local AI processing”.

After enabling the feature in Firefox Labs, users would have to press Shift and Alt (or Option on macOS) to see the preview.

The feature changed in a few ways once it was released to general availability in Firefox 142.

Link Previews in Firefox 142

Link Previews was promoted to release on Firefox 142.

Firefox 142’s release notes describes how the feature was changed upon release. Mozilla says: “Long press a link (or right-click and choose Preview Link). Previews can optionally include AI-generated key points, which are processed on your device to protect your privacy.”

Firefox now shows the Link Preview popups when long clicking a link. While this gesture is common on mobile, it is not on desktops - and many people are seeing the popups and not understanding why they appear. Some are even convinced that they are coming from the sites themselves, like from YouTube.

While Mozilla introduced Link Previews as “entirely optional”, people are now seeing link previews without ever enabling the feature.

You probably noticed that Mozilla said that the previews can optionally include AI-generated key points. That’s because Mozilla enabled link previews by default, but made the summaries optional.

Since the feature has been split up, let’s see how it works.

Link Previews

Link Previews - without the AI summary - is a feature Mozilla could have added to Firefox decades ago. That’s because the snippet it shows is the same one that search engines have been using since 1996 to get a basic idea of what pages are about: the page’s meta description.

If you click your mouse button over a link for a second, your browser will visit the page and process it to grab the page description and to estimate the amount of time it takes to read.

The request to the page happens from your computer and is not proxied in any way. That means that your IP address will be leaked to the server hosting the link that you are previewing. Mozilla says that key points are processed locally to protect your privacy in the release notes, but says nothing about leaking your privacy in showing the link preview (and enabling it by default).

Criticism

Note: This section updated on January 8.

I got some responses that my criticism for Link Previews leaking your privacy doesn’t make sense, since visiting the page would also share the same data with the originating server.

That is true, but it also doesn’t defend Link Previews in any way. The reason that Mozilla tells us that the AI generated summaries are generated locally to protect your privacy is because the alternative would be to send it off to a cloud-based LLM. Mozilla doesn’t apply the same thinking to the Link Previews itself, since privacy (like security) is layered.

To demonstrate, we can do a search for the same page I previewed in the mockups I generated.

I use Startpage, and they offer a “Visit in Anonymous View” that actually works like a privacy preserving preview.

This feature actually works to preserve my privacy. The originating host never sees my request, and I can visit the page on my own if I want to.

Startpage shows us how a feature like this could help to protect your privacy – even as it opens up the potential for abuse. For example, people might say that Mozilla is intruding on your privacy if they saw what pages you were previewing. If you wouldn’t want Mozilla knowing what pages you are previewing, why would you want the originating host to?

You may believe that Link Previews don’t leak your privacy. Mozilla can improve Link Previews further. Firefox can visit links on pages you visit, so that long-clicking (or hovering) could show you a preview without delay. Would that intrude on users’ privacy?

There is no doubt that Firefox is causing people to visit more pages than they normally would, and those pages aren’t even being viewed by people, as they are processed by Link Previews. That Mozilla imposed this privacy leaking change on Firefox users in an automated update is indisputable.

While Mozilla says that the AI features in Link Previews have always been opt-in, it is obvious that this is sleight of hand. Mozilla thinks that by wrapping the AI feature inside a non-AI feature, and enabling the non-AI feature by default, the browser can interrupt you over and over again to finally opt into the AI features.

If you don’t know what is happening, this might be easy to miss. Thankfully, the team over at Deceptive Patterns have researched “the growing issue of manipulative, deceptive and coercive design patterns in the digital world”.

Deceptive Patterns

Looking closer, we can see that Mozilla has designed the Link Previews experience to architect consent for AI by using three main tactics. They are: obstruction, nagging, and preselection.

Obstruction

The first tactic I want to highlight is obstruction, which Deceptive Patterns defines as something that “deliberately creates obstacles or roadblocks in the user’s path, making it more difficult for them to complete a desired task or take a certain action”.

The obstruction in Firefox is obvious - the browser is obstructing the user from clicking or manipulating the link in another way. You might want to drag the link to a document to copy it, for example. The user might also have mobility impairments that makes a fast click harder, resulting in a longer hold time.

Deceptive Patterns notes that obstruction “is used to exhaust users and make them give up, when their goals are contrary to the business’s revenue or growth objectives.” That sounds exactly right – Firefox is now an AI browser, so Mozilla’s goal is to grow usage of AI rather than browsing web pages.

Nagging

The obstruction in Link Previews doesn’t just happen once, though. After Firefox updates, the popup appears continually as people browse the web normally. This is nagging, defined by the team over at Deceptive Patterns as: “a tax that the provider imposes on users who do not want to comply with the provider’s wishes.”

Eventually, the cost becomes non-trivial and at that point, “the user may decide it’s more cost effective to just give in and agree to whatever the provider is asking for, even if it is against their best interests”.

Preselection

The deceptive design pattern that makes it all possible is the last one I want to highlight: preselection.

Deceptive Patterns notes that this pattern takes advantage of the default effect cognitive bias: “a psychological phenomenon where people tend to go with the option that is already chosen for them, even if there are other choices available.”

Preselection is what allows Mozilla to continually nag and obstruct users - all while putting the onus on disabling the interruptions on the person using Firefox.

Contrary to their messaging on social media, Mozilla preselected the option to enable Link Previews in an automatic update.

Opt-Ins and the “Kill Switch”

The design of Link Previews shows us the lengths to which Mozilla is willing to go to get users to “opt into” AI features.

After designing the feature, Mozilla allowed users to use it by opting into it, first by enabling it in settings, then by performing a keyboard shortcut to activate the popup each time.

Making the feature available in settings wasn’t going to juice the metrics though, so Mozilla decided that they needed to put it in front of people who weren’t checking out the settings UI.

Likely predicting backlash for enabling an AI feature by default, Mozilla decided to split the original feature into two, so they could enable the non-AI portion by default.

It really is that simple. Mozilla never designed Link Previews by itself, as the feature is annoying, not very useful and also leaks your privacy.

It’s not even like we can point to people asking for this feature – I looked for extensions that are similar to Link Previews, and all of them combined total up to around 300 users.

What’s really happening is that Mozilla wanted people using AI features, but they want people to opt into them – likely so they could say that Firefox AI features are always opt-in. How can you make that happen without actually enabling AI across the board?

Mozilla figured it out - enable the feature without AI and use the stub feature to advertise for the complete version. It is basically a demo advertising the full version.

If this is how opt-ins look to Mozilla, it means that users can expect to be nagged over and over to try AI features even though they hit the “kill switch”. Clearly, Mozilla isn’t actually enabling AI, it is enabling an unrelated feature that just suggests AI to you.

After having to opt out of being interrupted, Mozilla is insisting that this counts as an opt-in.

Mozilla’s latest communications say that the kill switch will remove “entry points to AI features”, so even features newly invented to push AI should be disabled when using the kill switch.

Hopefully that is the case, but it is worth observing what Firefox is becoming. A minefield of pre-selected anti-features is Firefox’s present. With the transformation to an AI browser, I’m sure we can expect to see more.

An Alternative Opt-In

While I’m not a designer, I took a stab at imagining what an opt-in feature would look like.

If summaries are really useful, people will opt into them.

That is the idea behind making summarization a new page action button in the address bar.

Once you load a page, Firefox can advertise that it can summarize the page to you.

Once you click the button, Firefox will show you the summary, in a reader-view like format.

Unlike Link Previews, this version doesn’t ever get in your way.

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.

I made a video if you want to watch instead.

• Open Source History
  • Open Source Licensing
• Big Tech AI
  • Damage to Open Source and Free Culture
  • Vocational Awe and Sharing Communities
• The Aftermath of LLM Piracy

Last week, I argued that Mozilla’s replacement of volunteer contributions on Support Mozilla with AI translations was a betrayal of Mozilla’s open source principles.

If you disagree, you might not realize that the AI companies have been pirating from the commons, directly hurting open source. This is an important topic, so I’m devoting the rest of this post to it.

Open Source History

This comment helped me realize that some of us are forgetting the role of copyright in open source.

It’s funny seeing the sudden surge of “copyright is awesome!” On the Internet now that it’s become a useful talking point to bludgeon the hated Abominable Intelligence with.

We can think about copyleft as a kind of hack of the copyright system.

What is copyleft?

The FSF defines it as a method to make a work free “and requiring all modified versions to be free as well”.

The default way that copyright works is when you create an original work, you own the copyright on that work, which gives you some exclusive rights over the intellectual property. Since those rights are exclusive, you need to assign them to others if you want to give them permission to exercise those rights.

Open source subverts the default notion of copyright. By releasing your work under open licenses, the copyright owner grants others the same rights that the copyright owner has over the work. Since that means that the copyright owner is effectively giving the work away (with addtional restrictions, depending on the license), it gives that work new life.

Like royalty free music on YouTube, people will spread the work, and the community of people who find it useful can fix issues and add new features – helping it spread even further.

The results are evident – open source lets hobbyists connected by the internet to compete with software built by professionals working at big software companies. According to a Harvard study, open source has an economic value of $8.8 trillion.

It is so powerful that it allowed KDE to develop a browser engine called KHTML that was eventually forked by Apple to WebKit, then forked again by Google to form Blink.

The two dominant browser engines on the market today are Blink and WebKit. These engines power big tech web browsers like Chrome, Safari and Edge.

Open source is what propelled competition between Linux and its entirely open source stack with huge big tech companies like Microsoft and Apple. Google’s adoption of open source in Linux and Android helped eventually force Microsoft out of the mobile operating system market.

The Linux desktop has even gotten to the point that Valve is promoting it as a gaming OS to run Windows games. You don’t even need to run a Microsoft OS to run Windows games anymore. Open source really is powerful stuff.

Open Source Licensing

I’m talking about copyleft licenses, as they differ from “permissive” licenses by preserving the openness of the original work by placing changes to the work under the same open license. These licenses are also sometimes called “viral” because by using the “virally licensed” work in another work, you transmit the license (virus) to the new work.

The virality ensures that the work - freely given - continues to be given freely.

Copyleft doesn’t just apply to software - user contributions on Wikipedia are licensed under a Creative Commons Attribution-ShareAlike license, for example. This means that any edits people make to the encyclopedia are also given freely.

The “share alike” in Wikipedia’s license is a covenant that Wikipedia has made with its contributors, and that copyleft developers have made with open source contributors.

Big Tech AI

Since arriving on the scene, AI companies have relied on massive data sets to train their LLMs. The data sets include virtually anything posted online by anyone - blog posts, books, music, illustrations, even things like reddit comments.

While the AI companies have stolen from us all, I contend that open source and free culture communities have been disproportionately damaged, and will continue to be.

Damage to Open Source and Free Culture

The key covenant that differentiates copyleft licenses from permissive ones is that they are shared alike. That is the bargain that the big tech content pirates blow a hole through.

By incorporating copyleft data into their models, the LLMs do share the work - but not alike. Instead, the AI strips the work of its provenance and transforms it to be copyright free.

That is because the US copyright office has rightly advised that AI generated works are not copyrighted.

This means that the LLMs are copyright removal devices - copy open source (or proprietary!) data into it, and you get copyright free data on the other side that you are free to plagiarize into newly copyrighted works.

While this process robs all copyright owners, it is particularly damaging to people involved in sharing communities, since many are particpating not for money but for the love of the game - what librarian Fobazi Ettarh calls “vocational awe”.

Vocational Awe and Sharing Communities

Vocational awe explains why so many are willing to share freely with others - even when being involved can be degrading and thankless. Ms. Ettarh invented the term to describe how people who believe that they are serving the greater good can be more easily taken advantage of.

It explains why people share even when they aren’t getting paid.

When was the last time you heard of a plumber who repaired leaks for free? It doesn’t happen, so when AI comes for the plumbers, they will need to be coerced for their training, or will need to be paid for it. Plumbers aren’t going to work for free, and if they do, they know exactly how much they are donating.

The Aftermath of LLM Piracy

LLM piracy of open source works damages the value exchange that contributors made to the community. When LLMs strip provenance from contributions, the contract is broken - their contributions are no longer shared alike. Instead, the contributions are stolen.

As Sean O’Brien, founder of the Yale Privacy Lab at Yale Law School points out:

“Now those same corporations are using that wealth and compute to train opaque models on the very codebases that made their existence possible, and threatening the legal structures, such as reciprocal or copyleft licenses like GNU GPL, by labeling all the outputs of genAI chatbots public domain.”

While many contributors will continue to give, others will rightly realize that the bargain has shifted, and will stop contributing.

You can see that shift happen on Stack Overflow, a popular question and answer site for programmers.

The data speaks for itself: 50% fewer posts and comments than before ChatGPT became generally available.

Perhaps the people who might have contributed are instead helping to train a chatbot like Copilot or Gemini. They aren’t helping the community anymore, though.

Contributors need to ask themselves: Does it makes sense to continue to contribute directly to the big tech LLMs for free?

It isn’t as if they are also getting a (second?) big tech salary in the mail.

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.

I made a video if you want to watch instead.

• Google Gemini
• Open Source
  • Common Voice
  • Mozilla is Biting the Hand(s) that Feed It
  • Contributions to Support Mozilla
• Barreling Ahead to Proprietary AI

In the world of open source, community contributions are the norm. That’s why Mozilla’s recent decision to overwrite community contributions with an AI-powered bot feels like such a betrayal.

Given Mozilla’s open source history, you might assume that the AI is powered by an open model with datasets available on Mozilla Data Collective.

Mozilla’s leadership has recently been talking up open source AI, saying that it is important to own what you build.

I took a look at the Data Collective to see whether the Support Mozilla data set was there. No such luck.

I should have looked at the Kitsune documentation instead. Kitsune is the software that runs SUMO, and the Kitsune developers have helpfully documented the translation bot. Kitsune is the Japanese word for fox, and in Japanese folklore, they are ascribed with intelligence and magical powers. Kitsune’s bot is built on top of Gemini 2.5 Pro, according to the docs.

Google Gemini

Unlike the vision that Mozilla is pitching elsewhere, Gemini 2.5 is not an open source model, with data coming from “publicly available sources”. We know what that means – Google pirated a whole lot of copyrighted material from the web.

The UK based Society of Authors wrote an open letter to Google upon the introduction of Gemini, saying:

The Society of Authors was greatly concerned to hear that, at the launch of Gemini pro, ‘Google repeatedly refused to answer questions from reporters about how it collected Gemini’s training data, where the training data came from and whether any of it was licensed from a third party’. Given the reportedly extensive infringement of copyright protected works that took place to build existing Large Language Models (LLMs), this continued lack of transparency is alarming and leads us to assume that Google has used creators’ works unlawfully and unfairly, without consent or any kind of remuneration.

While we don’t yet know what the legal remedies for the copyright infringement used to create models like Gemini is going to end up looking like, there is no doubt that Gemini is both closed source and contains pirated material.

Open Source

Common Voice

If you are involved in the wider Mozilla community, you may know about Common Voice. Common Voice is an open source data set of speech data of over 130 languages, all contributed by members of the community, including myself. This data is available to download on Mozilla’s new Data Collective.

The existence of the Common Voice data set demonstrates that people are willing to contribute to open data sets - companies don’t need to infringe on people’s copyrights in order to get access to training data.

Mozilla is Biting the Hand(s) that Feed It

In choosing closed source, infringing models, Mozilla is biting the hands of the community that feeds it.

Mozilla has experience in garnering community contributions to build open data sets. Instead of asking for their community’s help in developing an open source localization model, they deployed a closed source model and destroyed open contributions.

That makes Mozilla’s committment to open source AI seem insincere.

Mozilla’s moves represent a double betrayal: first, they reject the community’s contributions to SUMO’s knowledgebase, then to add insult to injury, they reject the very idea of open source by implementing a closed source model based on stolen data.

Mozilla’s Data Collective includes this blurb on the homepage:

Mozilla Data Collective is rebuilding the AI data ecosystem with communities at the centre. Access over 300 high-quality global datasets, built by and for the community in a transparent and ethical way.

While Mozilla says that they are rebuilding AI data ecosystems with communiites at the center, that isn’t what is happening on Support Mozilla. There, Mozilla is destroying a high quality data set built by the community in a transparent and ethical way.

What motivation do communities have to contribute to Mozilla projects or data sets if Mozilla itself does not privilege open source? The message Mozilla is sending when choosing to overwrite human contributions with stolen ones is that while Mozilla will gladly take your contributions, it is also willing to steal them.

Contributions to Support Mozilla

The Gemini terms of service says that Google does not use submitted prompts to improve paid Gemini queries.

That means that overwrite over overwrite, any fixes that localizers make to the Mozilla knowledgebase can be overwritten at any moment by a bot that doesn’t learn.

The only way Kitsune developers can modify Gemini’s output is to modify the prompt that Mozilla sends to Google to provide a translation.

That changes the command that Mozilla sends Google, but it has no effect on the underlying model that contains the error being corrected.

Why should Mozillians bother to make corrections to a corpus that is prone to be overwritten by the whim of anyone making a modification to the American English version of an article when they know that that correction won’t stick – can’t stick, because Mozilla is throwing away the open data that they are contributing, release after release?

Barreling Ahead to Proprietary AI

Since the November SUMO call, Mozilla continues to barrel ahead towards the brave new world of proprietary AI.

Following up from the call, Mozilla introduced a “Feedback and Training Period”, where they invited the community to study the machine translation bot and to provide feedback.

Their feedback process is not open – instead of asking for feedback on the forum where they made the announcement, they are telling the community to submit feedback in secret, to a Google form monitored by Mozilla.

That seems like a way to quash negative feedback, and to allow only approved feedback to emerge. Why is Mozilla, an open company - operating in secrecy?

As Mozilla elicits feedback, the translation bot continues to run on Support Mozilla, overwriting community contributions. A recently opened Kitsune feature request reveals the challenging environment that contributors are operating in – contributors want a listing of articles that have been overwritten by the bot. They want it to look like an existing listing of unreviewed articles.

A full month after marsf resigned from SUMO as Japanese locale leader, contributors are asking for an easier way to find the AI’s modifications.

Why is Mozilla barreling forward towards closed source AI? I have some ideas about that, but this post is already pretty long. Follow if you want to read my thoughts on that.

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.

I made a video if you want to watch instead.

• Support Mozilla (SUMO)
  • Contributions
• Japanese Locale Leader Resigns
  • Locale Leaders
  • Resignation
  • Thank You, marsf
• Localization
  • Mozilla’s Position(s)
• Mozilla Kills Localization

My post about the deeper implications of what Mozilla is doing to the Support Mozilla community is coming, but I figured over the Thanksgiving holiday that I could focus on giving thanks.

While the title of this post is a bit tongue in cheek, I realized that some people didn’t know what was going on. Support Mozilla isn’t Firefox or Thunderbird, and if you aren’t aware of developments in AI or communities you might not be clear how it all affects you, a Mozilla user.

Support Mozilla (SUMO)

Support Mozilla is Mozilla’s helpdesk and knowledgebase.

This is where you can get help for Mozilla products like Firefox and Thunderbird. The products themselves also link to the knowledgebase, in place of in-product documentation.

Contributions

The helpdesk and knowledgebase are all volunteer driven, and people spend hours of their time helping other people use and troubleshoot Mozilla products.

Mozilla isn’t shy about asking for people’s help on the Support Mozilla website - their website says “save the world from the comfort of your couch”.

Contributors can answer support questions, write help articles, and they can also localize support content.

Mozilla is pretty complimentary towards their localizers, calling them “heroic”.

Japanese Locale Leader Resigns

On November 4, the locale leader of the Japanese Support community on SUMO very publicly resigned.

You should read what marsf said themselves, but here’s my summary:

marsf has been contributing to Mozilla for over 20 years, even before Support Mozilla existed.

They were a locale leader, someone who coordinates localization efforts for a locale.

Mozilla enabled machine translation on the Japanese locale on October 22. marsf quit on November 4. It took less than two weeks to scare away someone who had spent 20 years contributing to the Mozilla mission.

Locale Leaders

Prior to the introduction of machine translation, locale leaders were a core part of the localization process.

On Mozilla’s knowledgebase article for localization contributions, the documented process is to send a locale leader a private message to get started.

Let’s take a look at the kinds of things you do as a locale leader:

• Greet new members of the SUMO community who want to localize into your language
• Work together with other Locale Leaders and Reviewers on guiding all Editors in their work:
  • through 1:1 mentoring on language and quality
  • through documentation (for example, a Style Guide for your locale)
• Provide fair reviews of contributions provided by all Editors in your locale – and provide constructive feedback on their quality, which includes:
  • Approving good revisions and encouraging Editors to continue their great work
  • Rejecting revisions that can be improved, and letting their authors know what and why could be better

You can see that locale leaders do a lot of work to build community around localization.

This is all work that Mozilla is throwing away in its move to machine translation.

Resignation

It is easy to see why marsf is angry and in pain. As a locale leader, marsf maintained the Japanese style guide. As a contributor for over 20 years, marsf likely had a hand in nearly every article on the locale.

Those were the articles that were overwritten by Mozilla and its machine translation bot, sumobot. The overwritten articles represented years of effort - a real labor of love, given that volunteers are unpaid.

Without discussion, without communication, without testing, untold years of human effort were overwritten by a machine with no love in its heart.

It is obvious that locale leaders are unable to foster a culture to train new contributors in process and style if AI is providing machine translations.

Thank You, marsf

Thank you for the over 20 years as a Mozillian. Thank you for helping Mozilla build culture. Thank you for helping millions of Japanese Mozilla fans. Thank you for caring.

Check out marsf’s profile on SUMO - they’ve got a lot of badges!

Localization

Some commenters say that none of this really matters. Machine translations are good now, it’s not like we’re really missing anything.

I got a great comment from pandakekok9 that dispels that notion. They say that Mozilla shouldn’t be calling what sumobot is doing “localization” if what it is doing is translation:

If that was the intent Mozilla, maybe don’t call what you’re doing “localization” then and just call it literal translation? A crucial difference between localization and translation is that former DOES add and change stuff that would not be found or recognizable in the original. As much as localization gets flak recently from Western fans of anime there are instances where localization works better than simply translating. Watch an episode of Keroro Gunsou / Sgt. Frog in English dub first, then the original Japanese dub with English subtitles. Each version has their own jokes and references that their intended audience get!

lokalise.com says the difference between translation and localization is:

Translation is the process of converting text from one language to another. Localization goes beyond translation to ensure content is culturally appropriate and well-received in the target market.

Translation prioritizes language accuracy, while localization pays specific attention to cultural, social, and linguistic nuances.

Before Mozilla introduced machine translations to SUMO, locale contributors referenced style guides to localize articles (e.g: the Japanese guide).

You might think that machine translations are good – we even have them in Firefox as a feature! While they can be good, do we really think they are better than a dedicated volunteer?

What Mozilla is telling us is that yes actually, the bots are better than a human.

Mozilla’s Position(s)

Mozilla gave linuxiac a statement that doesn’t tell the truth.

These changes were designed to deliver additional translation support to our community and provide even more articles in local languages. Machine translation helps fill in the gaps, while contributors continue to review, edit, and approve translations to ensure quality and cultural accuracy. We introduced the change by sharing the update publicly, holding a call with the contributor community, and notifying each locale in advance of activation.

Mozilla says that the point of machine translations is to fill in the gaps, and that humans continue to review and approve translations.

But marsf is telling us otherwise: the bot isn’t filling in the gaps, it is overwriting articles written by humans. Humans don’t need to approve the bot, the bot approves itself.

Mozilla knew when introducing machine translations that the bot doesn’t respect the style guides across various locales. Months later, marsf pointed out the same fact in their quit note.

A Dutch contributor on the call pointed out that although there may be multiple possible translations for a button’s label, Firefox will use a specific word. In those cases, the localization community on SUMO would always use the language used in Firefox - not an alternate translation. Just one example of localization not handled by Mozilla’s machine translation.

In the community call introducing machine translations, Mozilla said that they realize that AI makes mistakes and that they don’t want to force this onto the community.

Months later, when marsf pointed out that human contributions were being overwritten, Mozilla staff instead explained that it is logical for machines to overwrite human contributions.

Mozilla clearly understands on multiple levels that the AI doesn’t actually localize articles, it simply translates them. If Mozilla cared about that, Mozilla would revert the changes sumobot made, and locale leaders could work with developers to ensure that sumobot adhered to the locale’s style guide.

Why hasn’t that happened?

Mozilla Kills Localization

Everyone is on the same page: the AI doesn’t do localization.

Since Mozilla is going forward with overwriting localized articles with machine translated slop, Mozilla is telling their userbase that machine translations are good enough.

If Mozilla thought localization mattered, they would let their “heroic” localizers’ words stand, instead of automatically believing that the bots are doing a better job.

According to the Machine Translations documentation, Mozilla says:

If your revision is based on the MT version, your changes will not require additional approval before publishing.

Mozilla is saying that they trust machine translation more than human contributions, even when those contributions have been previously approved.

This leaves locale leaders in a very strange place. They are clearly being ignored in the move to AI, and Mozilla has said nothing about their role going forward.

More miscommunication, I guess.

On this Thanksgiving day, let us give thanks to marsf and to all the other contributors on SUMO whose contributions are being unceremoniously overwritten by a bot that has no connection to the locale it is slopping about.

Long live Mozilla!

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.

During the call, Mozilla also doubled down on AI, confirming that volunteers would be unable to disable AI translations across the entire Mozilla knowledge-base, with the American English version of articles serving as the blessed, canonical version. Locale specific contributions will be overwritten (by design) by AI.

This means that without human intervention, Mozilla intends to roll out automated AI slop across the entire knowledge-base, especially for archival content.

I made a video if you want to watch instead.

• Takeaways
  • The Reason Japanese Volunteers on Support Mozilla Quit is Because of “Miscommunication”
  • AI Cannot be Disabled on a per Locale Basis
  • Bonus Takeaway

Mozilla had their community call yesterday, and it was pretty eventful.

While I am still thinking through the deeper implications of the latest updates from Mozilla, there are a couple of quick takeaways that I think are important to note.

Takeaways

The Reason Japanese Volunteers on Support Mozilla Quit is Because of “Miscommunication”

You might have seen that Mozilla’s Volunteer Japanese Support community left very publicly via a note on the Support forums.

This was due to the introduction of automated AI translations to Mozilla local communities.

The entire post by the locale leader, marsf is worth reading, and they raised a number of issues in it.

Mozilla’s official response to the team rage quitting is that it is all a big miscommunication and that they continue to be in communication. It is ironic to me that since introducing AI translations, Mozilla is unable to communicate with volunteers that have been trusted to be Mozilla’s international voice for over 20 years.

From my perspective, it doesn’t look like miscommunication at all.

On the call, Mozilla doubled down on many of the issues raised by the Japanese community.

Mozilla explicitly doesn’t care about custom localized content or community content guidelines - they don’t understand why localizers would want that, and they recommend that if volunteers don’t want content to be removed, that they should instead request that it be added to the US English version. They explain that this version serves as the canonical source of truth for the automated translation engine.

In one concession to international communities, Mozilla increased the time before the AI overwrites human contributions from 72 hours to 7 days. This is to work within volunteers’ real life schedules – and especially to give people the weekend to catch up on the edits generated by AI.

marsf noted that 300 slop articles have been posted by Mozilla already. During the call, there was no mention that any of these articles would be reverted. Presumably, volunteers can go ahead and clean up after the AIs, if they so wish.

AI Cannot be Disabled on a per Locale Basis

One of the first comments in the SUMO chat following the call from people who hadn’t watched it was whether it would be possible for specific locales to disable AI translation.

Mozilla talked about this a few times on the call, and yeah… there is not going to be any way to disable AI translation anywhere on the SUMO knowledgebase.

Mozilla weirdly says the reason for this is that it serves as a “safety net”.

Personally, I don’t quite understand the safety net that doesn’t provide safety. This sounds a bit like jumping out of a plane without checking your parachute first. Sure, it might be fine, but are you going to risk your data to that? I guess non-American Firefox users are about to find out.

Bonus Takeaway

Even though everyone outside of Mozilla is calling this AI, Mozilla insists on calling it “MT” (Machine Translation) – until they slip into calling it AI. It seems to me that they think they can avoid controversy by using a word that doesn’t remind people of AI.

I have a lot of other thoughts about the situation that I’ll be posting about soon, so if you are interested in that, please subscribe.

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.

Towards the end of his appearance, Skyler claimed that 55% of NYC was planning on leaving within 5 years. He said this to bolster his argument that NYC residents are leaving due to high taxes (among other reasons).

The survey he references says the opposite of what he claimed, however, with 19% of people planning to leave NYC within the next 5 years.

I made a video if you want to watch instead.

As a New Yorker, I have been watching coverage of the election since the primary election.

Last night, I watched an interview on CNBC’s Squawk Box with a former deputy mayor under the Bloomberg administration.

Most of the interview went just as you might expect, but towards the end, the deputy mayor - Edward Skyler - who now works for Citibank as head of enterprise services and public affairs - drops some misinformation.

Check out the clip: Former NYC Deputy Mayor: You saw a huge enthusiasm gap between Mamdani and Cuomo supporters.

Mr. Skyler says that 55% of New Yorkers won’t be in New York in 5 years.

Usually, I don’t get too bothered about people getting things wrong, but this didn’t pass the smell test for me. A majority of New Yorkers were saying that they might leave the city within 5 years?

That didn’t sound right, so I decided to look into it.

No huge surprise – he’s totally wrong.

At first, I did a quick search on Google to help me find the exact statistic he’s referencing.

Google’s AI was really helpful in regurgitating the wrong information. The AI repeated some lies from the New York Post and NDTV, and even misrepresented what the makers of the survey - the Citizen’s Budget Commission - said.

The Google AI response, verbatim

The claim that “Fifty percent of New Yorkers say they plan to leave New York City over the next five years, according to a poll released Tuesday by the Citizens Budget Commission” appears to be based on the Citizens Budget Commission’s (CBC) “Straight from New Yorkers” survey

Where it says this:

• CBC Website: The CBC’s website and newsroom articles refer to the survey and state that 50.1% of New Yorkers planned to stay in the city over the next five years, down from 58.2% in 2017.
• News Articles: Several news outlets, including the New York Post and NDTV, reported on the survey findings and the 50% figure.

The survey question:

The wording of the specific survey question is not explicitly stated in the provided search results. However, based on the information provided, it’s highly probable the question was along the lines of asking residents about their intention to stay in New York City over the next five years. For example, the CBC states they asked residents if they “plan to stay in New York City in the next five years”.

Important Notes:

• The 50% figure specifically refers to the percentage of New Yorkers who stated they plan to stay in the city, which is a decline from 2017. This does imply a large number of residents are considering leaving, but the original statement phrasing might be slightly misleading.
• The survey data suggests dissatisfaction with various aspects of life in NYC as primary reasons for considering leaving, including affordability, safety, and living space.
• New Yorkers’ desire for action on safety, housing, infrastructure, and cleanliness are also highlighted as key findings from the survey.

Since Google referenced those organizations specifically, let’s take a look at the supporting data before we move onto the actual study.

The New York Post says: “When asked if they planned to stay in the Big Apple until 2028, only 50% of those surveyed said yes, down from 58% in 2017, according to the CBC.”

NDTV references the 50% figure in the headline, but never actually supports it in the article.

Okay, let’s take a look at the survey.

The survey is called “Straight from New Yorkers 2025” and is a survey of residents from across the 5 boroughs of 1,700 responses.

Let’s skip on down to the section we’re interested in.

Majority of New Yorkers say they will stay in NYC the next 5 years, but still lower than 2017

Remember that the former deputy mayor said that 55% of New Yorkers won’t be here in 5 years.

The survey says that 55% of New Yorkers will be staying over the next 5 years. If you look at the table, they also say that 19% of respondents say that they plan to leave within 5 years. This is an improvement from 2023, where respondents said that a quarter of them would be leaving within 5 years.

Clearly, they got it completely wrong. The deputy mayor was parroting misinformation from who knows where.

The anchor then asks a very reasonable question about who it was that was planning on leaving the city and why.

The only problem is, since the data wasn’t real to begin with, lacking the information, Mr. Skyler decided to guess in order to support his erroneous claim.

What’s the real reason?

The CBC has a handy graph for that too.

As you can see, the top three reasons are affordability, crime and safety and living space.

The survey itself says:

“These results reinforce the importance of New York City’s value proposition and ensuring the benefits of living here—cultural and social amenities, and economic opportunity—exceed the challenges of high costs, small apartments, and quality of life.”

Zohran Mamdani’s signature appeal in the primary election was a focus on affordability.

His campaign website says: “Zohran Mamdani is running for Mayor to lower the cost of living for working class New Yorkers.”

Unfortunately, over the next couple of months we’re going to see an uptick in the amount of misinformation being spread about this election - because we know that it works.

I hope that New Yorkers question the information they are receiving, because not everyone is interested in checking the information they are passing along. Sometimes, people are pushing a message that is based on half remembered statistics that say the opposite of what they thought.

Is CNBC going to issue a correction? I wouldn’t count on it.

If you liked this material, please consider supporting me. You can message me or follow this blog on Mastodon.