Closed-Source Privacy Is a Logical Contradiction

You know when Microsoft tells you Windows 11 "respects your privacy"? Or when Norton swears your data is safe?

There's a problem. It's not that they're lying — it's that the statement itself doesn't make sense. It's like saying "square circle" or "married bachelor." A logical contradiction, not a trust issue.

The argument, in three steps

One: privacy isn't a promise. It's a property of what software actually does, not what it claims to do. And the only way to know what software does is to inspect it. You can analyze runtime behavior (limited, reactive, gameable) or you can read the source code. Only the second path gives you affirmative verification — you can prove the mechanism to steal your data doesn't exist, because it isn't there.

Two: closed-source software, by definition, doesn't let you read the code. You get compiled binaries. You get a privacy policy written by lawyers whose job is maximizing legal latitude, not informing you. You get the vendor's word. That's it.

Three: if privacy requires verifiability, and closed source precludes verifiability, then...

"Privacy-respecting closed-source software" is a logical contradiction.

Not an implementation problem. A category error. Aristotle would approve.

The mafia's protection

I've used this metaphor before: the user of commercial software is like a tourist delighted not to encounter pickpockets in a mafia-run city.

The tourist smiles, wallet intact, streets safe. What they don't see is that the mafia runs the police, the shops, the hotels. The pickpockets are kept away not out of civic duty, but because they compete with the mafia's own extraction operation — far more lucrative and systematic.

Windows 11 protects you from malware while system telemetry vacuums up your data. Chrome protects you from trackers while Google logs every click. Your antivirus protects you from ransomware while uploading your files to servers in opaque jurisdictions. The predator protects you from smaller predators — for a price, and on terms you can't examine.

The audit theater

"But we undergo independent third-party audits!"

Sure. The vendor picks the auditor. The vendor pays the auditor. The vendor defines the audit scope. The vendor gets the report before publication. The vendor decides what to fix and what to disclose.

This isn't independence. This is audit theater — a ritual that creates the appearance of accountability without the substance. Arthur Andersen signed off on Enron's books. Rating agencies stamped AAA on mortgage-backed securities. The paid-audit structure is structurally corrupt, and everyone in the industry knows it.

Even setting aside the structural corruption: an audit only verifies what the auditor was told to look for, on the version of the software provided, at the moment of testing. It can't verify what the software will do tomorrow after an automatic update. It can't verify conditional logic lying dormant waiting for a server-side flag. It can't verify the binary matches the audited source — because without open source, you can't perform a reproducible build.

GDPR: the vise tightens

The GDPR doesn't explicitly mention open source. But read Articles 5, 24, 25, 28, and 32 together, and the implication becomes inescapable.

Article 5(2) puts the burden of proof squarely on the controller — you must demonstrate compliance, not believe in it. Can you demonstrate transparent data processing when the processing logic is opaque? Can you ensure confidentiality when you can't verify what leaves the system? Can you fulfill the accountability principle when you can't account for what the software does?

The Czech DPA has already ruled that Avast's "anonymized" telemetry data was in fact personal data, and that the vendor's claims were false. A €13.9 million fine, final and enforceable as of April 2024. More decisions are coming.

If you're a DPO running a Windows fleet with cloud-connected endpoint protection, you're personally liable for data processing you can't verify, conducted by software you can't audit, on servers you can't locate, under jurisdictions you can't determine.

What to do instead

The alternative isn't theoretical:

• Debian publishes every line of code. If a package phoned home with your data, someone would find it and it'd be forked or removed within hours.
• Signal publishes its client source. You can verify end-to-end encryption happens before messages leave your device.
• Qubes OS isolates every component with open-source Xen. You can verify your banking VM can't touch your browsing VM's data — not because a vendor promised, but because the isolation mechanism is transparent and auditable.

The common thread isn't that these projects are perfect. It's that they're verifiable. The epistemic foundation shifts from trust to knowledge.

The one question to ask

Next time a vendor tells you their closed-source product "respects your privacy," ask them one thing:

How would I know?

They won't have an answer. Not because they're hiding something — though they might be — but because the question itself exposes the contradiction at the heart of their business model. They're selling you a square circle and charging a premium for the corners.

This is the second in a series of articles building the philosophical infrastructure behind dropQbsd — compartmentalization without virtualization on BSD. The full version, with detailed data flow analysis, regulatory references, and case law, is on blog.nicolabaudo.fr.

Was this forwarded to you? Subscribe here. No tracking, no algorithm — just philosophical analysis of digital tools, every Sunday