Photonamus Industries Forums
The Usurpers: How Software Companies Seized Control of Your Hardware - Printable Version

+- Photonamus Industries Forums (https://forum.photonamus.com)
+-- Forum: Main Topics & Discussions (https://forum.photonamus.com/forumdisplay.php?fid=1)
+--- Forum: Article Discussion (https://forum.photonamus.com/forumdisplay.php?fid=3)
+--- Thread: The Usurpers: How Software Companies Seized Control of Your Hardware (/showthread.php?tid=39)

The Usurpers: How Software Companies Seized Control of Your Hardware - Photonamus - 08-22-2026

The Usurpers

How Software Companies Seized Control of Your Hardware

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

─── ◆ ───

The Short Version

You own your computer. You paid for it. It sits in your house, draws your electricity, and runs on parts you chose. But the software companies who write the programs that run on your machine have quietly decided that they get to make the rules about how you use it. They embed themselves in your hardware. They phone home without asking. They block you from repairing the things you bought. They force you to upgrade when your machine works perfectly fine. And they've done all of this slowly enough that most people never noticed it happening.

I noticed. This article is about how I got here, what I found, and why I think it's time we do something about it.

─── ◆ ───

Who I Am and Why I'm Writing This

I've been building, repairing, and modifying computers for thirty-five years. I'm not a software engineer at a big company. I'm the guy who fixes things, builds things, and takes things apart to understand how they work. I started tearing apart Tiger Electronics handhelds when I was eight years old — not because someone taught me, but because I wanted to know what was inside. I modded one of those handhelds before I ever owned a real game console.

I went on to build PCs from parts, run game servers for over a decade, do hardware repair and machining, build custom guitars with embedded electronics, and teach myself how every layer of a computer system works — from the silicon up. I ran Ultima Online private servers for twelve-plus years. I was the server owner. I managed the hardware, the software, the community, and every technical decision that kept those systems alive. That experience matters to this story, and I'll come back to it.

For most of those thirty-five years, I ran Windows. I knew it inside and out. Registry hacks, driver conflicts, boot sequences, system internals — I was a Windows specialist in the truest sense. It was my platform, and I was good at it.

Then I left.

I wiped my Windows partition, cold-switched to Linux, and never looked back. Not because Linux is perfect. Not because I wanted to be different. Because I looked at where Windows was heading and asked myself a simple question: why would I invest more years of expertise into a platform I can see is going wrong, when I could invest that same energy into something that might go right?

That decision led me to build the platform you're reading this on. Every piece of it — the web server, the forum, the IRC chat, the radio station, the analytics, the domain, the SSL certificates — runs on hardware I own, in my house, on software I chose and configured myself. Nobody can take it away. Nobody can change the terms. Nobody can flip a switch and shut it off. That is the point, and the fact that the point needs to be made at all is the problem.

─── ◆ ───

What Your Computer Actually Is (And What They Want It to Be)

Let's start with something basic that a lot of people have never thought about.

Your computer is a stack of layers. Think of it like a building.

The hardware is the foundation and the structure. The processor, the memory, the motherboard, the storage drive. This is the physical stuff. You bought it. It's yours. It sits on your desk and you can touch it.

The operating system is like the building's electrical and plumbing systems. It manages all the hardware and lets programs use it. Windows, Linux, and macOS are operating systems. They sit on top of the hardware and make it usable.

The kernel is the deepest, most powerful part of the operating system. If the operating system is the building's infrastructure, the kernel is the control room. It has direct access to everything: every piece of hardware, every byte of memory, every process running on the machine. When something runs "at the kernel level," it runs with maximum authority. It can see everything, touch everything, and change everything. If the kernel crashes, the whole system goes down. Period.

Your applications — your web browser, your email, your games, your word processor — run on top of all of that, in a restricted area. They can only do what the operating system allows them to do. They can't directly touch the hardware. They can't read other programs' memory. They're in a controlled space, and that's by design. It keeps things stable and safe.

Here's the critical thing to understand: the further down that stack something operates, the more power it has, and the more damage it can do if something goes wrong — or if something is being done on purpose that shouldn't be.

When a software company puts their code into your kernel, they have the same level of control over your machine as the operating system itself. They're not a guest in your house anymore. They've moved into the walls.

─── ◆ ───

The Windows Key: A Story of Tightening Grip

Let me walk you through how Microsoft's control over your computer has escalated, step by step, using something everyone has dealt with: activating Windows.

The Sticker Era

In the early days, when you bought a computer, it came with a sticker on the side of the case. That sticker had a product key — a string of letters and numbers that proved you owned a license to run Windows. You'd type it in during installation, and you were done.

It was simple. It was yours. You could read it, write it down, and use it if you ever needed to reinstall. It was also hilariously insecure. Any tech who came to your house could snap a photo of that sticker with their phone, walk home, and activate a copy of Windows with your key. It was a bad system, but the important thing was this: the proof of ownership was physical, visible, and in your hands.

The Digital License

Starting with Windows 10, Microsoft changed the game. They introduced something called a "digital license" (originally "digital entitlement"). Instead of a key on a sticker, your activation was tied to a fingerprint of your hardware — a unique identifier generated from your specific combination of components — and linked to your Microsoft account on their servers.

This sounds convenient. You can reinstall Windows without hunting for a key. It just recognizes your machine and activates automatically. But think about what actually changed: the proof of ownership moved from a sticker on your desk to a record in Microsoft's cloud. You can't see it. You can't hold it. You can't transfer it by writing numbers on a piece of paper. Microsoft is now the authority on whether your computer is allowed to run their software, and that authority lives on their servers, not yours.

The TPM Lockout

Then came Windows 11, and this is where things got aggressive.

Microsoft declared that Windows 11 requires a TPM 2.0 chip — a Trusted Platform Module, a small piece of security hardware built into your motherboard or processor. Without it, you cannot install Windows 11. Period. Microsoft called this requirement "non-negotiable."

Now, the TPM is not a bad piece of technology. It can store encryption keys, help verify that your system hasn't been tampered with at boot, and protect sensitive data. Those are good things that serve you, the hardware owner.

But Microsoft didn't just use the TPM for your security. They started using it for their licensing enforcement. The latest move: starting with the next Windows Server release, Microsoft is making TPM-based attestation mandatory for their Key Management Service. That means the TPM — your hardware, on your motherboard, that you paid for — is being used to verify that your software licenses are legitimate according to Microsoft's rules.

Your security chip is doing double duty as Microsoft's cop.

And here's the kicker that proves the whole thing was never really about security: when Windows 11 adoption numbers stalled because too many perfectly good computers didn't have TPM 2.0, Microsoft quietly loosened the requirement. They even published their own instructions for bypassing it. Then, when people used third-party tools to do the same thing, Microsoft flagged those tools as "potentially unwanted applications" through their own antivirus software — Windows Defender.

Read that again. Microsoft published a bypass. Then they used their security software to flag other people's bypasses. The message is clear: you can work around our rules, but only the way we say, and only when it serves our adoption numbers.

240 Million Machines in the Landfill

This is not just about control. It has real-world consequences.

Industry analysts at Canalys estimated that 240 million PCs worldwide do not meet Windows 11's hardware requirements. These are not ancient, broken machines. Many of them are just a few years old, running perfectly well on Windows 10. They have capable processors, plenty of memory, and years of useful life left in them.

But when Windows 10 reached end of support in October 2025, those machines were cut off from security updates. Microsoft's official recommendation? Buy a new computer.

Two hundred and forty million functional computers, consigned to obsolescence — not because the hardware failed, but because a software company decided their arbitrary requirements mattered more than the physical reality of what those machines could do. If you stacked those laptops, the pile would reach higher than the moon.

Microsoft makes public commitments to sustainability and carbon reduction. Then they engineer a situation where a quarter of a billion perfectly good computers get junked. These two things cannot both be sincere.

─── ◆ ───

The Anti-Cheat Problem: When Games Move Into Your Walls

If the Windows story is about slow escalation, the anti-cheat story is about a straight-up home invasion.

Modern competitive games like Valorant, League of Legends, and others use something called "kernel-level anti-cheat." Remember the building analogy? These programs don't run in the application layer like normal software. They install a driver that operates at the kernel level — the control room of your entire system. Same level as the operating system itself. Maximum privilege. Maximum access. Maximum risk.

The reason game companies do this is simple: cheaters use sophisticated tools that also operate at deep system levels, so the anti-cheat needs to be at least as deep to catch them. It's an arms race, and to fight it, they demand the keys to your entire building.

Here's what that means in practical terms:

If the anti-cheat software has a bug, your whole system can crash. Not just the game. Everything. Blue screen. Hard reboot. Data loss.

If the anti-cheat software has a security vulnerability, your whole system is exposed. Not just your game account — your banking information, your passwords, your personal files. Everything the kernel can see, an attacker exploiting that vulnerability can see too.

The anti-cheat runs even when you're not playing the game. Riot Games' Vanguard, for example, starts at boot and runs continuously. It's monitoring your system at the deepest level twenty-four hours a day, seven days a week, whether or not you've launched the game.

This is not theoretical risk. In July 2024, a company called CrowdStrike — an actual cybersecurity firm whose entire job is security — pushed a faulty update to their kernel-level software. That one bad update crashed approximately 8.5 million Windows computers worldwide. Airlines grounded flights. Hospitals lost access to records. Businesses went dark. A single mistake in kernel-level code, from a company that specializes in getting kernel-level code right, caused what may have been the largest IT outage in history.

Now think about that same level of access being held by a video game company. Not a security firm. A game studio. Their expertise is making games, not hardening operating systems. And they're running code at the same privilege level that brought down 8.5 million machines when a security company got it wrong.

It gets worse. In late 2025, Riot Games' own security researchers found a UEFI firmware vulnerability across motherboards from four of the biggest manufacturers — Asus, Gigabyte, MSI, and ASRock. The flaw was serious enough to earn four separate CVE identifiers. Riot then pushed a firmware update — not a game update, a firmware update — directly to players' machines. That means a game company reached below the operating system, below the kernel, into the actual boot firmware of your motherboard. That is the deepest possible level of a computer system.

And by 2026, anti-cheat systems had escalated further. They now enumerate your PCIe devices, check IOMMU state, and mandate Secure Boot configurations. They're inspecting your hardware and demanding specific firmware settings to let you play a video game.

The cost of all this isn't paid by cheaters. Cheaters with six-thousand-dollar direct-memory-access cheat hardware just adapt and move on. The cost is paid by normal players whose machines get locked out, whose systems get destabilized, and whose hardware gets inspected at the deepest level by code written by people who make entertainment products.

I will not open a hole to the heart of my system for a game. Not today, not ever.

─── ◆ ───

The Server Owner Analogy

I ran Ultima Online private servers for over twelve years. Custom builds, custom core modifications, the works. I was the server owner. I owned the hardware. I wrote and maintained the software. I managed the community. I made the rules, because it was my infrastructure and my responsibility.

Now imagine this: a group of players joins my server. They play for a while. Then they start telling me how to run it. They want access to the backend. They want to dictate what gets patched. They want to verify that their accounts are safe by inspecting my server files. They want to invent their own set of rights — rights I never granted, rights that have no basis in how the system works — and then enforce those invented rights on me, the person who actually built and maintains the whole thing.

That's insane, right? Those players are guests. They're using a service I provide, on hardware I own, under rules I set. They have every right to leave if they don't like it. They have zero right to move into my server room and start making demands.

Now flip it.

You are the server owner. Your computer is your server. You own the hardware. You maintain it. You pay for the electricity. Microsoft, Riot Games, and every other software company that runs code on your machine are the players. They are guests on your hardware. Their software exists because your hardware exists — without your processor, your memory, your motherboard, their code is just text in a file. The dependency runs in one direction: they need you.

But somehow, they've convinced the world that the authority runs the other way. They've decided that because they wrote a piece of software that can run on your hardware, they get to dictate terms about how that hardware operates. They embed code in your kernel. They use your security chips to enforce their licensing. They inspect your firmware. They phone home to their servers to verify that you're compliant with their rules. They flag tools you use to maintain your own system as threats.

They're players who walked into your server and started running it. That is a usurpation of authority, plain and simple. They invented rights they don't have, and they're enforcing those invented rights on the people who actually own the infrastructure.

─── ◆ ───

How I Took It Back

I'm not telling this story from the sidelines. I'm telling it from the other side.

When I saw where this was heading — the TPM lockouts, the telemetry, the kernel-level software from companies I don't trust, the slow erosion of ownership — I made a decision. I was going to build my own infrastructure, run my own services, and take back control of my own hardware. Not as a political statement at first, but as a practical one. I wanted to own what I use, understand what runs on it, and be able to verify everything from the silicon up.

So I switched to Linux. Cold switch. Wiped the Windows partition. Thirty-five years of Windows expertise, and I walked away from it. Not because I hated Windows — I knew it better than most people alive. Because I looked at the trajectory and realized that investing more years into a platform that was actively working against my interests as a hardware owner was a bad bet. I'd rather spend that energy learning something new that aligns with what I actually believe: that the person who owns the hardware should control the hardware.

Then I built my stack.

I've got a dedicated web server — a real machine, in my house, running on hardware I selected and assembled. On top of that I deployed a full suite of self-hosted services: an IRC server for real-time chat, a Matrix server for persistent messaging, a forum for long-form discussion, a web-based radio station streaming music I produced, analytics I control, a code repository, an RSS reader, an uptime monitor, a dashboard, and a reverse proxy handling SSL certificates through Let's Encrypt. Every piece of it is open source. Every piece of it runs on my hardware. Every piece of it is configured by me.

I have a Raspberry Pi running Pi-hole for network-wide ad blocking, Unbound for my own recursive DNS resolution, Home Assistant for home automation, and Vaultwarden for password management. My DNS queries don't leave my network until they hit the root servers. My passwords are stored on hardware I hold in my hand.

And then I poked a hole through to the open internet — on my terms. I registered a domain. I set up Cloudflare DNS. I configured Nginx Proxy Manager to route traffic. I secured everything with SSL. And the site you're reading this on went live, served from a machine I can walk over and touch.

Nobody else controls this. No platform can delete my content. No terms of service can change overnight and take away what I've built. No algorithm decides who sees what I write. If I want to publish something, I publish it. If I want to change something, I change it. If I want to shut it down, I shut it down. The authority over this infrastructure lives where it belongs: with the person who built it and owns the hardware it runs on.

This is what hardware sovereignty actually looks like. And it's why this platform exists — not to be a blog, not to be a portfolio, but to be a proof of concept. A demonstration that you don't need to rent your digital life from companies who see your hardware as their deployment target. You can own it. You can run it. You can control it.

That's not a hobby. That's integrity.

─── ◆ ───

The Problem, Plainly Stated

Here's the situation we're in, stated as simply as I can state it:

Software companies have gradually assumed authority over hardware they do not own. They've done this through a combination of licensing terms nobody reads, hardware requirements that serve their business model rather than your needs, kernel-level access that gives them the deepest possible foothold in your system, and market dominance that leaves most people feeling like they have no alternative.

The Trusted Platform Module — a security chip you paid for, soldered to a motherboard you paid for — is being used to enforce Microsoft's licensing schemes.

Anti-cheat software from game studios is running at the same system level that crashed 8.5 million computers when a security company made a mistake, and it's doing this to protect game integrity, not your security.

240 million perfectly functional computers were pushed toward the landfill because a software company's arbitrary requirements didn't match the hardware — not because the hardware couldn't do the job.

Your operating system phones home constantly, reporting data about your hardware, your usage, and your configuration to servers you don't control.

Bypass tools that let you make your own decisions about your own hardware get flagged as threats by the same company that published its own bypass when the adoption numbers weren't looking good enough.

This is not security. This is control. And it's being exerted by companies whose software depends on your hardware to exist, not the other way around.

─── ◆ ───

What We Need: Regulation That Actually Works

I'm not anti-business. I'm not anti-software. I'm not even anti-Microsoft. I'm anti-usurpation. I'm against any entity — corporate, governmental, or otherwise — inventing authority it doesn't have and enforcing it on people who actually own the thing in question.

We've started fighting this in other areas. The right-to-repair movement has made real progress. Twenty-three states have enacted or advanced right-to-repair legislation since 2020. The 2026 legislative template for right-to-repair laws now explicitly states that manufacturers may not use software-based restrictions to limit access to parts or tools, and it expands the definition of "tools" to include software, data files, activation mechanisms, and security credentials needed to complete a repair. Colorado's law took effect January 1, 2026. Washington's followed. Oregon's enforcement begins in 2027.

But here's the gap: right-to-repair addresses what happens when your hardware breaks. What we need are protections for what happens while your hardware is working — protections against software companies embedding themselves in your system, using your hardware for their enforcement, and making unilateral decisions about what your machine is allowed to do.

Here's what I think that regulation should look like:

Informed consent at every level. If software is going to operate at the kernel level of your system, you should be told — in plain language, not legalese — exactly what it does, exactly what it can access, and exactly what risks it introduces. Not buried in a terms-of-service document that nobody reads. Front and center, in language a normal person can understand, every single time.

No silent embedding in hardware security modules. If a software company wants to use your TPM, your Secure Boot configuration, or any other hardware security feature for their purposes (not yours), that should require explicit, informed, revocable consent. Your security hardware should serve your security first. Using it as a licensing enforcement mechanism without clear disclosure and opt-out should be illegal.

Mandatory disclosure of kernel-level access. Any software that installs a kernel-level driver should be required to disclose this prominently before installation, explain in accessible language what kernel access means and what risks it carries, and provide a clear, functional opt-out that doesn't cripple the software's basic functionality. If a game can't function without kernel-level anti-cheat, the user should know that before they buy it, not after.

Hardware longevity protections. Software companies should not be allowed to impose hardware requirements that render functional equipment obsolete unless those requirements are technically necessary for the software to function — not for the company's business strategy, not for their preferred security architecture, not for their future product roadmap. If a computer can run the software, it should be allowed to run the software.

User-controlled telemetry. Every piece of data your computer sends to an external server should be disclosed, visible, and individually toggleable. Telemetry should be opt-in, not opt-out. The default state of your computer should be silence — it talks to the outside world when you tell it to, not when the software vendor decides it should.

Accountability for kernel-level failures. If a company's kernel-level code causes system failure, data loss, or security compromise, the liability framework should reflect the level of access they demanded. You wanted root-level access to millions of machines? Then you accept root-level responsibility when it goes wrong.

None of this is radical. This is basic property law applied to digital systems. If you own something, you control it. If someone else wants to use it, they need your informed permission. If they break it, they're responsible. We've had these principles in every other domain of property ownership for centuries. It's time to apply them to computers.

─── ◆ ───

This Is Why I Built This

This platform — photonamus.com — exists because I believe the best way to argue for independence is to demonstrate it. Every article I publish here is served from hardware I own. Every service that runs on this site is software I chose, deployed, and maintain. Nobody approved this. Nobody gave me permission. Nobody can take it away.

I'm not saying everyone needs to build their own server. I'm saying everyone deserves to understand what's happening inside their computers, and everyone deserves a say in who gets to operate at the deepest levels of the machines they own. Right now, most people don't even know the question exists. They don't know that their game's anti-cheat is running at the same level as their operating system. They don't know that their security chip is being used to verify someone else's license. They don't know that their perfectly good computer was declared obsolete to serve a software company's upgrade cycle.

Now you know. And knowing is the first step toward demanding that the people who write the software that runs on your hardware start treating you like what you are: the owner.

Not the user. Not the customer. Not the endpoint.

The owner.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

This article was researched and composed in August 2026. All statistics, legislation, and incident details are drawn from publicly reported sources current as of the date of publication. This is one person's perspective, grounded in thirty-five years of hands-on experience with the systems being discussed. If you're reading this on photonamus.com, you're reading it on hardware that practices what this article preaches.