Why Linus Refuses to Embed a National Anti-Fraud Center in the Linux Kernel

A Seemingly "Reasonable" Absurd Proposal

Someone on Zhihu asked: why doesn't Linus add the National Anti-Fraud Center to the Linux kernel? The reasoning: skip tedious authorization steps and directly protect user safety at the system level with highest privileges.

At first glance it might sound plausible, but anyone who has written two lines of code would gasp. It's like asking why not implant a chip in everyone's brain so police can directly know who's committing crimes. It sounds safe, but would you accept it?

The Kernel Is Not Your Trash Bin

What is the Linux kernel? It's the core of the operating system, the foundation of the entire system. It manages CPU scheduling, memory allocation, and hardware drivers.

What is the anti-fraud center? It's application-layer business logic, a specific functional implementation.

Stuffing the anti-fraud center into the kernel is like renovating a house and insisting on embedding a refrigerator into a load-bearing wall. Can it be done? Maybe. Is it necessary? Absolutely not.

Linus's standards for kernel code are near-obsessive. Every line undergoes rigorous review; every patch must prove its value. You think the kernel is an App Store where you can install whatever you want?

The kernel prioritizes generality, stability, and security. The anti-fraud center is a China-specific application scenario. Why should all Linux users worldwide pay for this feature? Should Americans using Linux install an FBI monitoring module? Should Russians install an FSB module? Once that door opens, the kernel is ruined.

Highest Privilege = Maximum Risk

The questioner says lightly: "guard user safety with highest privileges."

Anyone who has worked in a big tech company knows permission management is the first line of defense. Ever heard of the principle of least privilege? If ordinary privileges can solve the problem, never use root.

Giving an application-layer function kernel-level privileges isn't protecting security; it's creating vulnerabilities.

If kernel code has a bug, the whole system crashes. Can the anti-fraud center's code quality meet kernel standards? Its update frequency, iteration cycle, and business logic changes operate on a completely different rhythm from the kernel.

Today the anti-fraud center wants to update a recognition rule. Do you plan to recompile the kernel, or let the kernel dynamically load external logic? The former ruins user experience; the latter opens a security backdoor.

Moreover, an application with highest privileges can theoretically do anything: monitor call logs, read chat content, track location. You say it's only for anti-fraud? Who guarantees that? Is the code open source? Where is the audit mechanism?

The Cognitive Gulf Behind the Technical Issue

The truly scary part of this question isn't its technical absurdity, but that the asker doesn't realize there's a problem at all.

They think "skipping tedious authorization steps" is an advantage. But it's exactly those "tedious authorization steps" that protect your privacy and data security.

User authorization isn't a hassle; it's a right. It's your control over your own device. Once that right is stripped away, your phone, your computer, no longer belong to you.

This mindset is common in internet giants. Product managers wanting to boost conversion rates wish all permissions were enabled by default. Developers wanting to save effort wish all functions ran with highest privileges.

But truly excellent system design finds a balance between functionality and security. It gives users the choice, rather than making the choice for them.

The Underlying Logic of the Open Source World

Linux became what it is today not because of the will of any single country or organization, but through the consensus of global developers.

The core of that consensus is: the kernel remains neutral; the application layer blooms in diversity.

You want to install an anti-fraud center? No problem, install it at the application layer. You want antivirus, firewall, parental controls? All fine. But none of them should enter the kernel.

The kernel only provides mechanisms, not policies. It gives you capabilities but doesn't decide how you use them.

That's why Linux runs on servers, phones, routers, even Mars rovers. Because it's sufficiently general and sufficiently restrained.

Once the kernel starts mixing in specific business logic, it loses that generality. It becomes a special-purpose system for a particular scenario.

The Technical Clarity Workers Should Have

Ultimately, this question reflects the dilemma of many workers.

We're chased by endless demands, pressed by KPIs, gasping for air. Product says we need this feature, boss says we need that effect, so we bury our heads and write code.

Over time, we forget to ask: is this demand reasonable? Is this design correct?

A technologist's value isn't just implementing requirements, but guarding the technical bottom line. Some demands simply shouldn't be done. Some features simply shouldn't be added.

This isn't opposing business; it's for the system's long-term health. Today you break architecture for a small feature, tomorrow the whole system becomes a mountain of shit.

Linus is respected not because he has a good temper (in fact he's notoriously short-tempered), but because he guards the kernel's purity.

He'll bluntly reject unreasonable patches, even if the submitter is a senior engineer from a big company.

That persistence is true technical conviction.

Code example

来源丨
经授权
转自 良许Linux（ID：liangxulinux）
作者丨良许