You Cannot Verify What You Cannot See: The Logical Impossibility of Privacy-Respecting Closed Source Software

Last week, I demonstrated something uncomfortable: your antivirus software is architecturally indistinguishable from malware. It demands root access. It exfiltrates file contents, browsing history, and system telemetry to cloud servers in non-adequate jurisdictions. It does all of this while telling you it's protecting you. The Czech Data Protection Authority didn't buy the excuse — they fined Avast €13.9 million for selling the browsing data of 100 million users, and that fine is now final and enforceable¹.

The response from the industry was predictable. "That's just one bad actor." "Our product is different." "We take your privacy seriously."

This week, I'm going to prove why none of those claims matter — not because I doubt their sincerity, but because the claim itself is logically incoherent. This isn't a practical argument about implementation details. It's an Aristotelian one about the nature of the thing.

The Axiom: Privacy Requires Verifiability

Let's start from first principles. What does it mean for software to respect your privacy?

It cannot mean "the vendor pinky-swears." It cannot mean "their privacy policy uses reassuring language." It cannot mean "they have a good reputation." All of these are statements about marketing, not about software behavior.

Privacy is a property of what software actually does, not what it claims to do. And the only way to know what software actually does is to inspect its behavior. There are exactly two methods:

1. Static analysis — examine the source code to understand what data is collected, where it's sent, and under what conditions.
2. Dynamic analysis — observe runtime behavior through network monitoring, process inspection, and system call tracing.

Method 2 is what security researchers do when they discover that a "privacy-focused" app is phoning home with your location data. It's forensic, reactive, and fundamentally limited — you can only observe what happens during your testing window, under your test conditions. Conditional data exfiltration (triggered by specific files, keywords, or user profiles) will evade dynamic analysis indefinitely.

Method 1 — source code access — is the only path to affirmative verification. You cannot prove a negative through dynamic analysis. You cannot prove that software doesn't do something you haven't observed yet. You can only prove it doesn't do something by demonstrating that the code contains no mechanism for doing it.

This gives us our first premise:

P1: Privacy-respecting software requires verifiability. You must be able to determine what the software does with your data.

The Definition: Closed Source Means Non-Verifiability

Closed source software is software whose source code is not available for inspection. This is not a pejorative description — it's the definition of the category. The vendor distributes compiled binaries. You cannot read the logic. You cannot trace the data flows. You cannot audit the telemetry.

The vendor may publish a privacy policy. They may submit to third-party audits. They may obtain certifications. None of this constitutes verification by you or your agents — it constitutes trust in representations made by the vendor and parties selected by the vendor.

This gives us our second premise:

P2: Closed source software precludes independent verification of data handling.

The Contradiction: A Cannot Be Not-A

Now we apply Aristotle's law of non-contradiction: a thing cannot simultaneously be A and not-A in the same respect at the same time².

If privacy requires verifiability (P1), and closed source precludes verifiability (P2), then:

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

It is not a difficult engineering problem. It is not a matter of trust. It is not a question of the vendor's good intentions. It is a category error — like a square circle, or a married bachelor, or a dry ocean. The predicate "privacy-respecting" requires a property (verifiability) that the subject "closed source" structurally negates.

When Microsoft says "Windows 11 respects your privacy," they are making a claim that is not merely false — it is unverifiable by design. You cannot falsify it. You cannot confirm it. The claim floats in epistemic vacuum, immune to challenge and immune to proof, which is exactly where corporations want their privacy claims to live.

The Mafia Protection Racket: Trust Us, We're the Good Guys

I've written about this paradox before: the user of commercial software resembles a tourist delighted not to encounter pickpockets in a city run by the mafia³. The metaphor captures the structural relationship perfectly.

The tourist walks through the city, wallet intact, smiling at how safe the streets feel. What the tourist doesn't see is that the mafia runs the police, the shops, the hotels. Every "protection" service is controlled by the same entity that poses the real threat. The pickpockets are kept away not out of civic duty, but because they compete with the mafia's own, far more lucrative extraction operation.

This is the position of the user who trusts closed source software for privacy. The operating system that harvests your telemetry protects you from "malware." The browser that tracks your every click protects you from "trackers." The antivirus that uploads your files protects you from "ransomware." The predator protects you from smaller predators — for a price, and on terms you cannot examine.

Windows 11 ships with telemetry that cannot be fully disabled. Even on "Basic" diagnostic settings, Microsoft collects device specifications, installed applications, and crash data. On "Full" — which is the default and which Microsoft designs dark patterns to push you toward — they collect browsing history in Edge, voice data from Cortana, typed text for autocomplete, and application usage patterns. The telemetry client runs as a system service with kernel-level access. You cannot audit what's actually being sent, because the telemetry client is closed source. You can only observe the encrypted blobs leaving your machine and trust Microsoft's description of their contents⁴.

macOS is no better. The rapportd daemon — ostensibly for cross-device handoff features — maintains persistent connections to Apple servers. trustd validates certificates and sends hashes of every application you launch. nsurlsessiond handles background network activity for system services. transparencyd sends data to Apple for certificate transparency verification. Do these daemons send more than Apple claims? You cannot know. The source is closed. The traffic is encrypted. You have Apple's word⁵.

Chrome sync uploads your bookmarks, passwords, browsing history, open tabs, and payment information to Google servers. Google claims this data is encrypted. You cannot verify this claim. The encryption implementation is closed source. You are trusting the world's largest advertising company — whose entire business model depends on monetizing user data — to protect data it has every economic incentive to exploit⁶.

LinkedIn was caught placing browser extensions capable of detecting a myriad of parameters and accessing all kinds of personal information, including religious beliefs, political views, and health data³. The irony? Many Data Protection Officers are active LinkedIn users and likely had no idea their own data was being harvested by the platform they use for professional networking.

This is the mafia's protection: we'll guard your wallet, just leave it with us. The tourist smiles at the safe streets while the real extraction happens invisibly, systematically, at a scale no pickpocket could ever match.

The Audit Theater

The industry response to this argument is predictable: "But we submit to independent third-party audits."

Let's examine what this actually means. The vendor hires the auditor. The vendor pays the auditor. The vendor defines the scope of the audit. The vendor receives the report before publication. The vendor decides what to fix and what to disclose.

This is not independence. This is audit theater — a ritual of verification 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 structure of paid auditing is structurally corrupt, and everyone in the industry knows it.

Even setting aside the structural corruption, an audit can only verify what the auditor is told to look for, on the version of the software provided, at the moment of testing. It cannot verify what the software will do tomorrow after an automatic update. It cannot verify what conditional logic lies dormant waiting for a server-side flag to activate. It cannot verify that the compiled binary matches the audited source — because with closed source, you cannot perform a reproducible build.

The audit says: at some point in the past, someone paid by the vendor looked at some parts of some version of the software and didn't find anything that violated some criteria. This is not verification. This is a press release.

The GDPR Time Bomb

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

Article 5(1)(a) requires that personal data be processed "lawfully, fairly and in a transparent manner." Article 5(2) places the burden of demonstrating compliance squarely on the controller — the accountability principle. Article 24 requires "appropriate technical and organisational measures" to ensure and demonstrate compliance. Article 25 requires data protection by design and by default. Article 28 requires controllers to use only processors that provide "sufficient guarantees" of compliance. Article 32 requires the ability to "ensure the ongoing confidentiality, integrity, availability and resilience of processing systems."

Now ask yourself: can you demonstrate compliance with these articles when your processing infrastructure runs on code you cannot inspect?

You cannot demonstrate that data is processed transparently when the processing logic is opaque. You cannot ensure confidentiality when you cannot verify what data leaves the system. You cannot guarantee resilience when you cannot audit the attack surface. You cannot fulfill the accountability principle when you cannot account for what the software does.

The Czech DPA has already ruled that "anonymized" telemetry data was in fact personal data and that the vendor's claims were false¹. More decisions are coming. The legal framework is increasingly incompatible with the technical reality of closed source infrastructure, and the gap will widen as regulators grow more sophisticated.

If you're a DPO running a Windows fleet with cloud-connected endpoint protection, you are personally liable for data processing you cannot verify, conducted by software you cannot audit, on servers you cannot locate, under jurisdictions you cannot determine. Good luck with that Subject Access Request.

What Verification Actually Looks Like

The alternative is not theoretical. It exists. It works.

Debian publishes every line of source code for every package in its main repository. You can inspect telepathy-logger and verify it only does what it claims. You can audit tracker-miners and confirm it indexes only the directories you configure. If a Debian package phoned home with user data, someone would find the code, publish it, and the package would be forked or removed within hours. This has happened repeatedly — the verification mechanism is real and operational.

Signal publishes its client source code. You can verify that messages are end-to-end encrypted before they leave your device. You can confirm that metadata collection is minimal. You can build from source and compare against the distributed binary. You don't have to trust Signal — you can check.

Qubes OS implements security through compartmentalization using open source Xen hypervisor technology. Every domain is isolated. The code is inspectable. The architecture is documented. You can verify that your banking VM cannot access your browsing VM's data — not because a vendor promised, but because the isolation mechanism is transparent and auditable.

The common thread is not that these projects are perfect. It's that they are verifiable. When a vulnerability is discovered, it's discovered by independent researchers reading the source, not by attackers exploiting a black box. When a privacy claim is made, it can be confirmed or refuted by anyone with the technical skill to read the code. The epistemic foundation shifts from trust to knowledge.

The Bottom Line

The claim "this closed source software respects your privacy" is not a statement of fact. It is not a technical specification. It is not a verifiable assertion. It is a marketing incantation — words arranged to produce a feeling of safety without any corresponding reality.

You cannot verify what you cannot see. You cannot trust what you cannot verify. And privacy without verification is not privacy — it's hope dressed in a EULA.

The AV article showed you that one category of software lies. This article shows you why all closed source software can lie, and you have no way to know. The specific becomes the universal. The case study becomes the proof.

Next time a vendor tells you their closed source product "respects your privacy," ask them one question: 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.

The mafia keeps the pickpockets away. But who protects you from the mafia?

---