Why Linus Won’t Put a National Anti‑Fraud Center Into the Linux Kernel

A Seemingly "Reasonable" Absurd Proposal

Hello, I am Liang Xu.

Someone on Zhihu asked why Linus doesn’t add a national anti‑fraud center to the Linux kernel, arguing that it would save cumbersome authorization steps and protect user safety at the system level.

At first glance it sounds plausible, but any developer who has written a few lines of code will gasp.

It’s like asking to implant a chip in everyone’s brain so police can instantly know who is committing crimes—sounds secure, but would you accept it?

The Kernel Is Not Your Trash Can

The Linux kernel is the core of the operating system, managing CPU scheduling, memory allocation, and hardware drivers.

The anti‑fraud center is an application‑level business logic, a specific feature implementation.

Putting the anti‑fraud center into the kernel is like embedding a refrigerator into a load‑bearing wall during house renovation—possible but unnecessary.

Linus demands extremely strict code quality; every line is rigorously reviewed and each patch must prove its value. The kernel is not an app store where anything can be added.

The kernel prioritizes generality, stability, and security. A China‑specific anti‑fraud service should not be forced on all Linux users worldwide. Would American users want an FBI monitoring module? Would Russian users want an FSB module?

Adding such a feature would compromise the kernel.

Highest Privilege = Maximum Risk

The questioner claims “using highest privilege to protect user safety.”

Anyone who has worked at a large tech company knows that permission management is the first line of security. Have you heard of the principle of least privilege? Anything that can be done with normal permissions should never be done as root.

Granting an application‑level feature kernel‑level privileges creates a vulnerability rather than a safeguard.

If kernel code bugs, the whole system crashes. Can the anti‑fraud code meet kernel‑level quality standards? Its update frequency, iteration cycle, and business‑logic changes are out of sync with kernel development.

When the anti‑fraud center needs a new detection rule, should you recompile the kernel or load external logic dynamically? The former offers terrible user experience; the latter opens a security backdoor.

Moreover, an application with highest privileges can theoretically do anything—monitor calls, read chats, track location. Who guarantees it will only be used for fraud prevention? Is the code open‑source? Where is the audit mechanism?

The Cognitive Gap Behind the Technical Issue

The real problem isn’t the technical absurdity but the asker’s failure to recognize any issue.

They see “saving cumbersome authorization steps” as a benefit, yet those steps protect privacy and data security.

User authorization is not a hassle; it is a right, a control over one’s own device. If that right is stripped, your phone and computer no longer belong to you.

This mindset is common in large internet companies: product managers push for higher conversion by enabling all permissions by default, developers take shortcuts by running everything with elevated privileges.

Good system design balances functionality and security, giving users choice rather than making decisions for them.

Underlying Logic of the Open‑Source World

Linux’s success stems from global developer consensus, not any single nation or organization’s will.

The core consensus: the kernel stays neutral while the application layer flourishes.

You can install an anti‑fraud service at the application level, just as you can install antivirus, firewalls, or parental controls. None of these belong in the kernel.

The kernel provides mechanisms, not policies. It gives you capabilities but does not decide how to use them.

This neutrality allows Linux to run on servers, phones, routers, and even Mars rovers—because it is generic and restrained.

Once the kernel starts mixing in specific business logic, it loses that generality and becomes a specialized system for a particular scenario.

Technical Clarity for the Working Engineer

Ultimately, this issue reflects the plight of many engineers.

We are constantly chased by demands and KPIs. Product says we need this feature, the boss wants that effect, and we just code.

Over time we forget to ask: Is this requirement reasonable? Is this design sound?

An engineer’s value is not only delivering features but also protecting the technical foundations. Some demands should not be implemented; some features should not be added.

This isn’t opposing business; it’s safeguarding long‑term system health. Sacrificing architecture for a small feature today can turn the system into a “shit mountain” tomorrow.

Linus is respected not because he’s nice—he’s actually quite harsh—but because he preserves the kernel’s purity. He will bluntly reject unreasonable patches, even from senior engineers at big companies.

This steadfastness is true technical belief.