Adversarial interoperability is a team sport

Top Sources: None

-->

Enshittification is particularly galling because (in theory, at least), digital technology should be really hard to enshittify.

That's because the only digital computer we know how to build is the "Turing-complete, universal von Neumann machine," which is to say, a calculating engine capable of computing every valid program. In some deep, important, foundational sense, every computer is the same as every other computer. Sure, they vary in terms of speed, storage and RAM, but given enough time and electricity, every computer can run every program.

This has profound implications for enshittification. Say a tech boss takes away a feature you value (as when Sonos pushed an update that removed nearly all the functionality from its "smart" speakers), or adds a feature you hate (like when Chamberlain blocked third-party apps from controlling its garage doors so it could force its customers to view seven ads before they could open or close their garages). At that point, a programmer can write an "interoperable" program that restores the good feature or blocks the bad one.

This program can be costlessly and instantaneously distributed to every affected technology user, and those users will likely pay something for it. After all, enshittification is a way to shift value away from technology users to tech companies, which makes the case for you paying for disenshittification technology that wrestles that value back.

All of that means that, in a state of nature, companies that are contemplating enshittification need to worry that their greed will tempt new companies to enter the market and poach their customers and suppliers. This alone might be enough to frighten companies off from enshittificatory gambits, and if companies press ahead regardless, then they open market opportunities for better companies that can costlessly, instantaneously usurp the original manufacturer's relationship with their entire affected customer base.

That's how it should work. But in 1998, Bill Clinton signed the Digital Millennium Copyright Act, and Section 1201 of the DMCA establishes a felony (punishable by a five-year prison sentence and a $500,000 fine) for reverse-engineering and modifying technology without the manufacturer's permission. Then, the US Trade Rep spent the next 25 years making sure that every US trading partner had an identical (or even worse!) "anticircumvention" law:

https://pluralistic.net/2025/05/26/babyish-radical-extremists/#cancon

The result is a grotesquely asymmetrical digital world, in which companies are free to use the flexibility of digital computers to downgrade or brick your digital devices, but where you commit a crime if you avail yourself of a countermeasure to get more out of something you own. This is the core technological factor at play in enshittification.

Enter AI. Thanks to vibe-coding, everyday people are rolling their own software for their devices and building the tools to shatter the digital locks that manufacturers use to block disenshittification. An excellent article by 404 Media's Jason Koebler runs down some of these hacks, including drop-in replacements for smart TV software that blocks the endless ads and surveillance that have made TVs all but unusable:

https://www.404media.co/reverse-engineer-anything-is-the-new-wild-west-of-ai/

These AI tools mix several techniques to disenshittify users' devices. One major component is automating the installation of existing alternative firmware for these devices that have been (possibly illegally) created by hobbyists and uploaded to various code repositories. Installing these alternative OSes is typically a gnarly task, requiring the user to do a lot of complex, fiddly, highly technical work to bypass their devices' digital locks.

In a world without anticircumvention law, a company that sold alternative OSes could hire a ton of programmers and UX developers to smooth over this process, but this is beyond the reach of a typical hobbyist or even a community of hobbyists, especially if they must operate in the shadows, under the threat of civil and criminal liability.

There's a useful analogy here to the trajectory of desktop versions of GNU/Linux. The first time I tried to install Linux (on an original iMac, in the late 1990s), the installation process included a multi-week post-installation wrangle that saw me (often unsuccessfully) compiling key modules from source code and then painstakingly configuring them to get the computer's graphics and I/O working reliably.

Fast forward 30+ years and installing Linux is trivial, thanks to highly capitalized companies like Canonical (makers of Ubuntu, the flavor of Linux I've used for nearly 20 years now). Installing Ubuntu today merely requires that you download the OS to a thumbdrive, reboot your computer using the drive as a startup disk, and click "install." Canonical's installer automatically hunts down the correct software for your hardware and configures it. Canonical writes and contributes to a lot of parts of the Linux OS, but the most important work it does is the fiddly, painstaking, labor- and capital-intensive work of perfecting that installer so it Just Works.

Much of what a vibe-coded jailbreaking tool does is stand in for Canonical, but for hobbyist OSes for smart TVs and speakers and many other devices. These LLMs patiently research every weird error and peccadillo and parse through message boards and logfiles detailing other hobbyists' struggles to get the code working and methodically apply and adapt those solutions until your device Just Works.

Some of these vibe-coded interop tools go farther than that. According to Koebler's coverage, some device owners had their coding assistants scratch-build entirely new, heavily customized OSes for their devices, complete with bypasses that allow this new code to be installed despite the manufacturer's countermeasures which are designed to prevent this. Delightfully, many of these users have created software that revives their bricked, discontinued devices. This poses the possibility of a world in which manufacturers no longer have the last word in your use of your own property: the mere fact that the manufacturer lost interest in a device and killswitched it does not mean that you must consign that valuable device to a landfill to become immortal, toxic e-waste.

All of this is good news. Some of the most sophisticated jailbreaking tools (such as those on the super viral "Reverse Engineer Anything" Github page) run locally, on your own computer, without invoking the "frontier models" that the big, awful AI companies have created:

This is good even if you're just modifying your own devices to get them to more closely conform to your own use-case. LLMs are genuinely good at coming up with the abstruse and obscure configuration lines and other incantations to get your technology working. Recently, I used a local model to fine-tune the power-management on my new laptop in ways that go beyond the options that are exposed through user-friendly graphic interfaces. The LLM spat out a grub "GRUB_CMDLINE_LINUX_DEFAULT" line that (again) Just Worked.

The last time I had to do this, I spent days painstakingly trouble-shooting options by trial-and-error. Using a chatbot to fill in the gaps left by decisions about which configuration options to place within reach of regular users and which to reserve for power-users has made my computer much more useful to me for the things I want to do, like writing and making collages.

The reality is that it's just not practical for technology developers to turn every conceivable function of your computer into a simple-to-use, accessible tool. A large part of technology design is about leaving things out (or, as my favorite Eno Oblique Strategy goes, "Be the first person to not do something that no one else has ever thought of not doing before"). No matter how thoughtful and diligent a technology designer is, they will never fully anticipate the needs and exigencies of their users. That's why the motto of the disability rights movement is "Nothing about us without us."

The users of technology know more about their use-cases than can ever be captured through a requirements gathering exercise and user testing. One of the best and proudest legacies of technology is the lineage of "user-friendly" programming tools that let nontechnical people design their own applications that exactly met their needs, from Hypercard to Visual Basic to Scratch, a lineage that vibe-coding tools are arguably part of:

https://pluralistic.net/2026/09/25/other-people/#right-there

But these tools are not perfect (nothing is). For all that Hypercard lets you do many things that would otherwise require a skilled programmer, it was also always limited relative to, say, writing MacOS code in Objective C. Your Hypercard program might do exactly what you needed it to, but slowly, and sometimes unreliably, and with serious limitations, such as a relatively low ceiling for the number of records you could add to a database.

Vibe-coded personal apps aren't necessarily subject to these limitations, but they come with some significant risks. Vibe-code can have serious security vulnerabilities that expose the user to things like identity theft or sextortion. It's conceivable that a vibe-coded garage-door opener app might make it possible for attackers to open your garage door when you're not home (or worse, when you are!). Depending on your risk-tolerance and expertise, these might be acceptable prices, or they might be too high.

But it's important to clearly identify the problem here: if the alternative OS you install on your smart TV exposes you to privacy-invading hack attacks, the problem is the defect in that software. The problem isn't that you had the temerity to rip out the manufacturer's own software and replace it with code of your choosing. You bought that TV, it's yours, and you don't owe the manufacturer an obligation to expose yourself to its own, built-in, intentional surveillance and invasive ads.

Here's a parallel: you have the right to put any shoelaces in your running shoes. Sure, Nike might prefer you to lace up your Jordans with its expensive OEM laces, but that's Nike's problem, not yours. Now, Nike might argue that by using no-name laces, you run the risk of having a lace break while you're running, which could also break your ankle. That's certainly a possibility: shoelaces do break, and Nike might be justifiably proud of the quality of its laces. But if your generic laces snap (and so does your ankle), the problem is that the shoelaces you chose were defective. The problem is not that you chose someone else's laces.

Your stuff is yours. You can put anyone's milk on your cereal, not just the milk that Kellogg's endorses. If the milk you choose is sour and you have to pour your cereal down the toilet, that's too bad, but it doesn't mean that Kellogg's should have the right to shame you for having the temerity to choose the milk you preferred, and it certainly doesn't militate for DMCA-style enforcement to coerce you into using Kellogg's official milk in the name of protecting you from food wastage.

I raise this because there's a live debate over this subject, which is well represented in the latest 404 Media podcast:

https://www.youtube.com/watch?v=UbG1qwxMtU0

In the podcast, Koebler and his 404 co-founder Joseph Cox express misgivings about various possible uses of "slop interop." Koebler discusses the fact that John Deere sells the same physical tractor at many different price-points, depending on which software a farmer chooses, and raises the possibility that a farmer might vibe-code software that replicates the high-end functionality without paying for it. Koebler discusses two possible downsides to this: first, that the vibe-coded software might be defective and expose the farmer to risk; and second, a question about whether it's fair or just for a