1. Anger Is Understandable, But It Is Not a Strategy
Anti-consumer decisions deserve criticism. When platforms make their products worse for users through increasingly invasive ads, hostile browser changes, or burdensome developer rules, people are right to be annoyed.
But anger alone does not usually change the incentive structure. Companies often double down when the profitable path is also the anti-consumer path. I agree that capitalism should be a system of profit &codswallop loss, and that boycotting is an important part of consumer sovereignty. But boycotting should not be the only tool in our arsenal.
Digression: I love short sellers too (like Hindenburg Research & Michael Burry). At their best, short sellers are like market rogues with lanterns, crawling into the walls of corporate codswallop [nonsense] and finding the rot everyone else was paid not to notice.
Consumers should also think about whether we can have a more symbiotic relationship with the companies that annoy us. That does not mean excusing bad behavior or pretending corporations are our friends. It means asking whether some of their worst decisions come from warped incentives, high transaction costs, legal fears, revenue pressure, or clumsy attempts to solve real problems in user-hostile ways.
Part of this idea connects to Adam Smith’s view that human beings desire not only to be loved, but to be lovely: to be worthy of approval. People & institutions often fall short of that ideal when the easier path rewards uglier behavior. When circumstances are hard, when trust is expensive, or when every good option creates friction, the worse option can start to look inevitable.
That is where users & developers may have more power than we think. Instead of only punishing bad decisions after they happen, maybe we can build tools, standards, & alternatives that make better behavior easier [Here's my attempt to help the Blogger Platform]. We can reduce friction. We can lower transaction costs. We can create ways for companies to make money without treating users like cattle, developers like suspects, & privacy like a technical inconvenience.
The more useful question might be this: can users and developers build systems that make the consumer-friendly path cheaper, easier, & more attractive? [See: https://futo.tech/projects]
In other words, instead of merely demanding that companies stop being shitty, maybe we should also build things that make the virtuous path easier than the shitty one.
Another Random Digression: Big companies often try to block upstarts by using government power, especially after their own enshittification has created a gap in the market for someone better to enter. Instead of competing directly, they lobby for rules that raise the barrier to entry in their niche: licensing requirements, compliance burdens, identity checks, KYC laws, vague safety regimes, often in the name of protecting the kids or some other noble-sounding pretense, & other forms of competitor’s-veto whatnot [See: Bootleggers & Baptists].
In an ideal world, the government would not have the power to vitiate markets this way. But if the alternative is entering a political battle we are probably going to lose to big money, maybe there is another angle: make virtue easier for crappy corporations. Reduce the friction around doing the right thing. Build tools & standards that let companies make money without being so hostile, extractive, or paranoid.
There is a weirdly redemptive idea here. The Christian ethic says nobody is beyond repentance. Luke Skywalker saw the good in Darth Vader. Dostoevsky’s Crime and Punishment is built around the possibility of moral awakening after degradation. Maybe markets need a little of that too: not naive trust, not corporate absolution, but the belief that even bad institutions can sometimes be nudged toward better behavior when the better path is made easier.
2. Helping Platforms Cover Their Asses Without Doxxing Developers
This is where the abstract idea becomes practical.
Maybe one way to make the virtuous path easier is to build better trust infrastructure. For example, Google’s “Know Your Developer” rules for the Play Store seem like an attempt to reduce fraud, malware, and bad actors. But forcing developers to link their work more directly to their legal identity creates a new problem: privacy loss, surveillance creep, and another tempting honeypot for hackers.
That is where a Rust-based authentication or reputation system might be useful.
The basic idea would be to let developers prove trustworthiness without exposing more personal identity than necessary. A developer could build up reputation through signed releases, verified project history, code audits, package consistency, security practices, or community trust signals, without needing every app, extension, or project to be publicly chained to their legal name.
In theory, this could work like a practical version of what the blockchain humbug promised internet people: portable trust, pseudo-anonymous identity, cryptographic proof, and reputation without constant doxxing. But instead of speculative token nonsense, it would be boring, useful infrastructure built around real developer needs.
Rust feels like a good fit for this kind of system because it already has a culture of safety, tooling, package integrity, and serious infrastructure work. A Rust-based trust layer could help developers prove, “I am the same person or project that produced this previous trustworthy work,” without necessarily saying, “Here is my passport, home address, and legal identity.”
The goal would not be to help scammers hide. The goal would be to separate accountability from unnecessary exposure. Platforms like Google could still reduce abuse, but developers would not have to surrender as much personal information by default.
That is the better incentive thesis in miniature: build tools that help companies manage risk without turning every developer into a suspect and every identity database into a hacker honeypot.
3. Steam, RuneLite, & Community-Built Improvements
There are already examples of platforms becoming better because users and developers built useful things around them.
Steam is a good example. Valve built Proton with serious institutional support, but the broader Proton ecosystem benefits from community testing, compatibility reports, bug reports, guides, & tools like ProtonDB. That surrounding community infrastructure helps make Steam on Linux more usable than Valve’s work alone could make it.
RuneLite is an even clearer example. Old School RuneScape had an active community that wanted a better playing experience, and RuneLite provided that through plugins, interface improvements, quality-of-life features, and community-driven tooling. It improved the experience so much that it became part of the broader OSRS ecosystem rather than merely an outside annoyance.
That is the model I am interested in.
Instead of only yelling at platforms after they make anti-consumer decisions, maybe users and developers can build tools that demonstrate better possibilities. If a third-party tool solves a problem well enough, the platform may eventually copy it, tolerate it, integrate it, or at least respond to the demand it reveals.
This does not mean every company will behave like Valve, or that every community tool will be welcomed. Some platforms may treat outside improvements as threats. But the Steam & RuneLite examples show that community tooling can sometimes push an ecosystem in a better direction.
The broader lesson is simple: users are not only consumers. Developers are not only complainers. A healthy community can become a kind of experimental workshop, testing features, reducing friction, and showing platforms that better behavior is not only morally preferable, but practically useful.
P.S./Digression: I meet a pretty cool dude on Twitch who makes Civ 5 mods.
4. Could This Work for YouTube?
YouTube is probably one of the hardest cases, but also one of the most important.
The basic conflict is obvious: YouTube wants revenue, users want a site that is actually usable, creators want to be paid, & advertisers want results. In theory, these interests do not have to be enemies. In practice, the current system often turns them into enemies anyway.
That is how we get the arms race. YouTube adds more aggressive ads, users install stronger ad blockers, YouTube fights the ad blockers, users look for new workarounds, & the whole relationship becomes more hostile. The platform has become almost the inverse of Gabe Newell’s Steam, & it may be putting itself on a moribund path, not dying all at once, but slowly hollowing out the original appeal that made YouTube beloved in the first place. Users become more resentful. Advertisers get shoved into a system where their ads are treated like a digital infestation.
So maybe the goal should not only be to make YouTube nicer. Maybe the goal should be to make niceness cheaper.
That means looking at both sides of YouTube’s burden: the technical costs & the institutional risks. Video hosting is expensive. YouTube has to pay for storage, bandwidth, transcoding, fraud prevention, creator payouts, legal compliance, & whatever other eldritch infrastructure whatnot keeps the great video beast alive.
Moderation is its own nightmare too. Human moderation teams are expensive, inconsistent, & vulnerable to political bias, bureaucratic pressure, & government jawboning. COVID-19 is a famous example of the danger here: even when the U.S. government did not censor speech directly, officials could still pressure private platforms to suppress disfavored speech on its behalf.
Tools like Community Notes suggest one possible partial mitigation: distribute some fact-checking & context-giving power to users, instead of leaving every judgment to an internal, HR-flavored priesthood of platform hall monitors.
Another possible solution would be more transparency around moderation itself. Users should be able to choose whether to publicly share the internal reasoning behind YouTube moderation decisions, using an opt-in mechanism rather than an opt-out one, especially when a video, comment, or channel is restricted. That way, creators could explain to their audience why their video was removed, limited, demonetized, or otherwise punished.
That would not solve every problem, but it would make the process harder to hide, harder to abuse, & easier for outsiders to scrutinize. More importantly, it points back to the main idea: better systems can lower the cost of behaving decently.
That could mean experimenting with better opt-in revenue systems, privacy-preserving ads, creator-support pools, user-selected ad categories, or voluntary attention credits. But it could also mean looking beyond ads entirely. Developers could explore ways to lower YouTube’s infrastructure burden through opt-in caching, mirroring, decentralized storage, peer-assisted delivery, better compression workflows, or creator-owned archives.
Platforms like Odysee hint at one possible direction: a centralized service can still exist for convenience, discovery, moderation, & usability, while some storage or distribution work is supported by more decentralized mechanisms. YouTube would not need to become some pure blockchain fever dream. The point would be more modest: find ways to reduce the cost of serving video without making the user experience worse.
That is the key idea: help YouTube lower its expenses & risks so virtue becomes easier to pursue.
If the platform can make money, pay creators, moderate more transparently, & serve videos with less friction & less abuse, it has fewer excuses to make ads more invasive or treat users like enemies. The decent path becomes easier, cheaper, & more attractive than the crappy one.
5. Chrome, uBlock Origin, and the Browser Incentive Problem
Chrome shows the same incentive problem from another angle.
Google makes a lot of its money from advertising, while users often want more control over what runs in their browser. That creates an obvious conflict. From the user’s side, tools like uBlock Origin make the web faster, cleaner, safer, & less annoying. From Google’s side, widespread ad blocking threatens the revenue model that funds much of its empire.
Louis Rossmann’s consumer-rights wiki has documented Chrome automatically disabling uBlock Origin during the Manifest V3 transition, while The Verge notes that uBlock Origin Lite is a more limited replacement. That is the browser incentive problem in miniature: the user wants control, the platform wants revenue, & the browser starts acting less like your servant & more like an ad empire’s border guard.
That is how a browser can slowly become hostile to the very people using it. The browser is supposed to be the user’s agent: the tool that helps the person browsing the web. But when the company controlling the browser also depends on ad revenue, the browser can start acting less like the user’s servant & more like the platform’s border guard.
So again, the better question may not be only, “How do we stop Google from attacking user tools?” The better question might also be, “Can we build better revenue systems so Google has less incentive to attack user tools in the first place?”
Maybe that means better opt-in advertising systems, Patreon-like funding models for corporate pet projects or major services like YouTube, privacy-preserving ad matching, direct creator-support pools, voluntary attention credits, or other ways for users to fund the web without surrendering control of their browsers.he point is not to make everyone love ads. The point is to reduce the pressure that turns ads into an arms race between users & platforms.
If better revenue alternatives existed, platforms might have fewer excuses to treat user-control tools as enemies. Chrome could act more like a browser again, instead of a toll booth with a rendering engine attached.
That is the browser incentive problem in miniature: when the company making the browser depends on weakening user control, the browser stops being neutral. So users & developers should not only defend tools like uBlock Origin. They should also build systems that make respecting user control less financially painful for the platforms that currently resist it.
6. Trust Without Legal Identity Honeypots
The same incentive problem shows up in developer identity rules too.
Google’s “Know Your Developer” rules for the Play Store resemble the logic behind “Know Your Customer” regulations in finance. The stated goal sounds reasonable: reduce fraud, scams, malware, impersonation, & other bad behavior. But these policies often arrive under noble-sounding pretenses while quietly expanding identity collection, surveillance, & platform control. Platforms do need ways to judge developer trustworthiness, but legal identity collection should not be treated as the only path to trust.
But the solution can create a new problem. When every developer has to link more of their work to their legal identity, the platform becomes a bigger privacy & security risk. Legal names, addresses, documents, business records, & identity-verification data all become part of another centralized honeypot. That may help platforms cover their asses, but it also gives hackers, governments, & bureaucratic busybodies a more tempting target.
Brokerages already show the danger of this logic. “Know Your Customer” rules were supposed to reduce financial crime, but they also helped turn brokerages & financial platforms into giant identity warehouses. KYC & KYD-style systems may fight one kind of fraud while creating the conditions for another: identity fraud. The more legal identity data gets collected, copied, stored, & eventually breached, the more ordinary users & developers are exposed to fraud, surveillance, & bureaucratic misery.
And when that data leaks, the institution that demanded it usually moves on. The victim is the one stuck cleaning up the mess: disputing accounts, freezing credit, replacing documents, proving they are themselves, & in rare cases, even trying to get a new Social Security number. In other words, the “anti-fraud” system can end up exporting the real cost of failure onto the very people it claimed to protect.
The real solution to developer trust is probably not more legal identity collection. It is open source.
Open source lets users, researchers, platforms, & other developers inspect what software is actually doing. It does not magically make every project safe, but it shifts trust away from “this developer gave Google a passport” toward “this code can be examined, built, audited, forked, reproduced, & criticized.” That is a much healthier trust model.
Developers still need ways to prove continuity & reputation, but that should sit on top of openness, not replace it. Signed releases, verified project history, reproducible builds, code audits, package consistency, security practices, community reputation, & cryptographic proof can all help. A developer should be able to say, “I am the same trusted actor who shipped this previous work,” without also saying, “Here is my passport, home address, & entire legal identity.”
This is where a Rust-based authentication or reputation system might be useful. Not blockchain humbug. Not speculative token nonsense. Just boring, practical trust infrastructure: pseudo-anonymous identity, portable reputation, signed software history, reproducible builds, & accountability without unnecessary doxxing.
The goal would not be to help scammers hide. The goal would be to separate accountability from needless exposure. Platforms like Google could still fight fraud & malware, but developers would not have to surrender more personal information than necessary.
That is the larger theme again: make the decent path easier. Help corporations manage risk & satisfy their CYA policies without turning every developer into a suspect, every open-source project into a paperwork exercise, & every identity database into a hacker honeypot.
7. A Possible Rust-Based Trust System
This is where the idea becomes more concrete.
If platforms like Google want to reduce fraud, malware, impersonation, & bad developer behavior, they need some way to judge trust. But that does not mean every developer should be forced to tie all of their public work directly to a legal identity. There should be a middle path between “total anonymity with no accountability” & “upload your passport to yet another corporate honeypot.”
A Rust-based trust system could help fill that gap.
The basic idea would be pseudo-anonymous reputation. Developers could build a long-term trust profile around signed releases, verified project history, reproducible builds, security practices, open-source auditability, package consistency, & community reputation. Instead of proving, “My legal name is X,” a developer could prove, “I am the same actor who has maintained this software, signed these builds, fixed these issues, & behaved responsibly over time.”
In other words, maybe the answer is Rust + the useful parts of blockchain thinking + post-quantum security. Not token speculation. Not blockchain humbug. Not another ape JPEG casino. Just the original promise of portable trust, rebuilt as boring infrastructure for developers.
A system like that could borrow the non-stupid parts of blockchain: cryptographic identity, signed history, append-only public logs, decentralized verification, & pseudo-anonymous reputation. It could also be designed with post-quantum security in mind, so developer trust does not depend forever on systems that may become fragile as computing power changes.
That kind of system could include privacy-preserving identity proofs too. Maybe a developer could prove certain facts without revealing everything: that they control a domain, maintain a repository, have a clean signing history, passed an audit, or have been active under the same cryptographic identity for years. The platform gets useful trust signals without automatically collecting passports, home addresses, & legal paperwork from everyone.
Projects like Rauthy show that Rust is already being used for serious authentication infrastructure. Rauthy is not the full answer to the KYD problem, but it points in the right direction: secure, efficient identity tooling that could inspire better systems for developer trust without defaulting to legal-identity honeypots.
Open source should still be the foundation. A trust system is much stronger when the code can be inspected, built, audited, forked, reproduced, & criticized. Legal identity says very little about whether software is safe. Open code, signed builds, reproducible releases, & a consistent developer history say much more.
This would not be a magic solution. Bad actors would still exist. Platforms would still need enforcement. But it could help separate accountability from unnecessary exposure. Developers could prove trustworthiness without surrendering their entire identity by default, & platforms could reduce risk without turning every developer into a suspect.
That is the promise: trust without doxxing, accountability without identity hoarding, & developer reputation without another giant database waiting to be breached.
8. The Real Goal
The real goal is not to excuse bad corporate behavior.
It is not to make Google, YouTube, or any other platform the hero of the story. These companies still deserve criticism when they make hostile, anti-consumer decisions. Invasive ads, browser restrictions, legal-identity honeypots, opaque moderation, & user-hostile design should still be called what they are.
But criticism should not be the only move.
The more interesting goal is to build systems where the less hostile option becomes easier, cheaper, & more attractive. If platforms can make money without abusing users, they have fewer excuses to abuse users. If they can reduce fraud without doxxing developers, they have fewer excuses to demand legal identity from everyone. If they can moderate with more transparency, they have fewer excuses to hide behind vague institutional priesthoods. If they can lower infrastructure costs without making the user experience worse, they have fewer excuses to squeeze users through more ads, more tracking, & more control.
That is the builder’s version of consumer sovereignty.
Boycotts, criticism, & exit still matter. But users & developers can also create better tools, better standards, better funding models, better trust systems, & better alternatives. The point is not to trust corporations blindly. The point is to make the decent path harder for them to ignore.
In other words: do not merely yell at the dragon for hoarding gold. Build a better road around the mountain, a safer vault, a cheaper delivery network, & maybe a less cursed incentive structure so the beast has fewer reasons to keep eating villagers.
9. Closing Question
So maybe the closing question is not only:
Why are these companies being shitty?
That question still matters. Sometimes the answer really is greed, cowardice, bureaucracy, regulatory capture, or plain old institutional rot. But it should not be the only question.
The better question might be:
What could we build that makes being less shitty the easier path?
Can we build better opt-in revenue systems, better community tools, better moderation transparency, better developer trust infrastructure, better open-source verification, better storage models, & better ways for platforms to make money without treating users like cattle & developers like suspects?
That is the Tocquevillian angle: do not wait forever for government, corporations, or some benevolent central power to fix everything from above. Voluntary associations, builders, users, developers, communities, weird hobbyists, open-source people, & stubborn civic-minded oddballs can sometimes solve problems sideways by building alternative institutions. Think sideloading, independent app stores and app-discovery tools, like Aurora Store, F-Droid, Obtainium, SideQuest, & similar projects. Think open protocols, community tooling, and agorist-style workarounds that let people route around hostile gatekeepers instead of waiting for permission from above.
Ask not only what the government & corporations can do for us. Ask what we can build for each other, for the internet, & for humanity in general.
Maybe the best answer to hostile platforms is not only exit, complaint, or regulation. Maybe it is also construction.
Build tools that reduce friction. Build systems that preserve dignity. Build alternatives that reveal better possibilities. Build infrastructure that makes the decent path cheaper, easier, & more attractive than the crappy one.
In other words: make virtue easier to pursue.
Public Domain Notice
This blog post is released into the public domain. Copy it, remix it, quote it, archive it, print it, argue with it, or use it for whatever strange and useful purpose you like.
Attribution is not required, but crediting MoribundMurdoch would be chill and appreciated.
Also See:
: