In April, the Information Technology and Innovation Foundation published a paper called From Sovereignty to Control: A Clear-Eyed View of Canadian Cloud Policy. It's worth reading. The author, Lawrence Zhang, makes an argument that cuts against the direction I've been writing about, and he makes it well enough that it deserves a real response rather than dismissal.

The Argument

ITIF's core claim is that "sovereignty" as framed by Canadian and EU policymakers bundles together several distinct problems — data control, operational resilience, legal jurisdiction, industrial policy — under a single label, and then treats domestic ownership and server location as the solutions. Their counter: control is what matters. Who can access systems, under what conditions, and with what constraints. Server location doesn't determine that. Provider jurisdiction does. And domestic ownership doesn't either, if the provider still holds the encryption keys.

They break control into four layers: technical (encryption, key custody), operational (admin access, auditability), legal (who can compel disclosure), and structural (can you switch providers). Their diagnosis is that a sovereignty proposal that doesn't specify how it delivers control across all four layers is "just a protectionist location requirement."

They're right about that. A Canadian data center run by a company that holds your encryption keys and has a US corporate parent gives you location without control. The CLOUD Act reaches the provider, not the server rack. ITIF cites this correctly.

Where They're Right

The four-layer control framework is genuinely useful. If you're designing infrastructure for a community, you should be asking these questions:

  • Technical: Who holds the encryption keys? Can the provider access plaintext?
  • Operational: Who has admin access? Is access logged and auditable?
  • Legal: What jurisdiction is the provider subject to? Can they be compelled to disclose?
  • Structural: Can you migrate to a different provider without prohibitive cost?

These are the right questions. The sovereignty framing can obscure them — "it's in Canada" doesn't answer any of the four. ITIF is correct that policymakers often treat location as a proxy for control, and it's a bad proxy.

They're also right that the strictest controls should be reserved for the narrow set of workloads that actually need them. Not every community file share needs the same security posture as a government classified system. Treating everything as maximum-sensitivity wastes resources and makes deployment impractical — which is the opposite of what community infrastructure needs.

Where They're Wrong

ITIF's prescription is where the argument breaks down. Their six recommendations — procurement rules, customer-held keys, portability, redundancy, a blocking statute, and narrow scoping — are all addressed to government. Procurement rules. Blocking statutes. Reserved strict controls for defence and intelligence.

This is a policy paper written for policymakers about government cloud procurement. The implicit assumption is that cloud infrastructure is something you buy from a provider, and the question is which provider and under what terms.

That assumption misses the entire point of community-owned infrastructure.

When a fire hall runs a Proxmox cluster with Nextcloud, Matrix, and Keycloak, they're not procuring cloud services. They're operating infrastructure. The four-layer control framework doesn't just apply — it's fully satisfied by design:

  1. Technical control: The community holds the encryption keys. The community configures disk encryption, TLS, and application-level encryption. No provider has access to plaintext because there is no provider. The LUKS key is on a USB drive in the fire chief's office.

  2. Operational control: The community has root. Access is logged by the community's syslog server. The audit trail is on hardware the community controls. If someone abuses admin access, the community sees it and addresses it through their own governance — not a vendor's support ticket.

  3. Legal control: The infrastructure operator is the community. A lawful access demand goes to the community, not a corporate provider with a legal department trained to comply quietly. The community can see it, challenge it, and organize around it. This is the structural difference ITIF's framework acknowledges but their prescription doesn't leverage.

  4. Structural control: The data is on hardware the community owns. Migration means copying files, not negotiating data export APIs with a vendor who might decide to charge for it. The community can walk away from any software component — swap Nextcloud for ownCloud, Matrix for XMPP, Keycloak for Authentik — without losing their data.

ITIF's framework is correct. Their conclusion — that sovereign cloud is mostly protectionism — doesn't follow from it. The framework describes exactly why community-owned infrastructure delivers control that procured cloud cannot. The problem isn't the framework. It's the assumption that infrastructure is something you buy.

The Key Custody Question

ITIF's strongest point is about encryption keys. They argue, correctly, that domestic hosting with provider-held keys is theater. If the provider can decrypt your data, location is irrelevant — the CLOUD Act reaches the provider, not the data center.

This is where the sovereign cloud procurement debate and the community infrastructure movement diverge sharply. The Canadian government's sovereign cloud RFI restricts applicants to Canadian-owned providers. That's a procurement decision about which companies get government contracts. If those providers hold the keys — and most cloud providers do, by default — the sovereignty is a legal layer, not a technical one. Better than a US provider subject to the CLOUD Act, but not the same as control.

Community-owned infrastructure takes a different path. When you run Nextcloud on your own Proxmox node, you configure encryption. You hold the keys. You decide the threat model. The gap between "Canadian provider holds your keys" and "you hold your keys on your hardware" is the gap ITIF identifies but doesn't follow to its conclusion.

The conclusion isn't "procure better." It's "don't procure at all. Operate."

The Honest Counter-Argument

ITIF would push back here, and they'd have a point: not every community can operate infrastructure. The fire hall treasurer who struggles with Excel isn't going to administer a Proxmox cluster. The procurement path — buy from a provider under terms that enforce control — is the practical path for most organizations.

That's true, and it's why the work we do is structured the way it is. The deployment is the easy part. The training, documentation, and sustainability planning — making sure the community can operate what we build — is the hard part, and it's the part that makes the difference between "sovereign infrastructure" and "a consulting bill."

But ITIF's argument, taken seriously, actually makes the case for this work stronger, not weaker. Their four-layer control framework is the audit checklist for a community infrastructure deployment. When we deploy for a community, we can walk through each layer:

  • Keys held locally, not by a provider
  • Admin access controlled and logged by the community
  • Legal exposure scoped to the community's jurisdiction, not a vendor's corporate parent
  • Data on community-owned hardware, portable by design

This isn't a sovereignty argument. It's a control argument. And it's one community-owned infrastructure wins decisively, because the provider and the operator are the same entity.

What ITIF Got Half Right

The paper's most useful contribution is the warning that "sovereignty" as a policy label can become protectionism dressed up as security. That's a real risk. The Canadian sovereign cloud procurement process — restricting to Canadian-owned providers — is a procurement decision, not a sovereignty decision. If those providers hold the keys, the control framework ITIF describes is not satisfied.

But the paper frames this as an argument against sovereignty. It's actually an argument for going further than procurement. If control is what matters, and control requires key custody, operational access, legal jurisdiction, and structural portability, then the only infrastructure that fully delivers it is infrastructure you operate yourself.

ITIF's framework is the argument for community-owned infrastructure. They just didn't take it there.

The Practical Takeaway

For communities evaluating their infrastructure options, ITIF's four-layer framework is a useful tool. Use it. When a vendor pitches you "sovereign cloud," ask:

  1. Who holds the encryption keys? If the answer is "us, the provider," that's not control. That's a promise.
  2. Who has admin access to the systems holding our data? If the answer includes anyone outside your organization, your audit trail depends on their logs, not yours.
  3. What legal jurisdiction is the provider subject to? If they have a corporate parent in another country, that country's laws apply regardless of where the servers sit.
  4. Can we migrate our data to a different platform without the provider's cooperation? If the answer is "we'd need to negotiate an export," your structural control is conditional.

If the answers to those questions are "the provider," "the provider," "another jurisdiction," and "not easily" — you don't have control. You have a contract. Contracts are useful. They're not control.

Community-owned infrastructure answers those questions differently: "we do," "we do," "our jurisdiction," and "yes, the data is on our hardware." That's control across all four layers. Not because of where the server sits. Because of who operates it.

ITIF asked the right question. They just stopped short of the answer that matters for the communities we work with.