Meta Just Proved Why Encryption Shouldn't Be Optional

On May 8, Meta removed end-to-end encryption from Instagram direct messages. Their stated reason: too few users had opted in.

Take that explanation at face value for a moment. They built the feature. They offered it. They watched the data. Then they shut it off because not enough people were using it.

You could read this as a story about adoption metrics. It’s actually a story about how privacy gets built.

The decision that came before the decision

“Should we offer encryption?” sounds like a privacy question. It isn’t, really. It’s a product question. The harder one is the one most companies never make visible: “Can we, as a company, see this data?”

When end-to-end encryption is a feature, the answer is “sometimes, depending on your settings.” The company keeps the ability to access your data. They’ve just promised not to, for the users who toggled it on. That promise can be revisited.

When end-to-end encryption is part of the architecture, the answer is simply “no.” The company can’t see your data even if they want to. There’s no toggle on their side either. Removing the protection would mean rebuilding the service.

These look similar from the outside. They are fundamentally different commitments.

Why “low opt-in” is the company’s problem, not yours

Meta’s justification deserves a closer look. If a setting protecting something important sits unused, that’s a design failure, not a user failure.

Encrypted Instagram DMs required users to find an option, understand what it did, and turn it on for individual conversations. Most people sign up for a messaging app to message people, not to audit security settings. Very few opting in says something about the interface, not about how much people care about privacy. We’ve written before about why defaults matter more than features; this is the same argument from the other direction.

When companies build privacy as an obscure option and then point to “low adoption” as a reason to remove it, the math is convenient. The conclusion was available the moment the design choice was made.

What this means for any service you trust with your data

Cloud storage is the same problem with higher stakes. Your photos, your documents, your family’s history. (We’ve explained the technical side of this in our post on who actually holds the keys.)

Before you ask “is this service encrypted right now?”, ask “can the company decrypt my data if they choose to?” The first is about today. The second is about every day after that, including the day a board meeting decides priorities have shifted.

A service that designs itself so it cannot decrypt your files is making a structural commitment. A service that holds the keys is making a policy promise. Policies change. Architectures don’t, not without rebuilding the product.

The harder version of the question

It’s comfortable to think privacy is a setting you can configure. It’s less comfortable to ask whether the company you trust has the ability to change the answer later.

When you choose a service for something important, look at what the company can do, not what they currently are doing. The first is structural. The second is a checkbox.

We mention this not to claim virtue. Building a service that can’t decrypt user data is a constraint, not a feature. It rules out a long list of conveniences. We took that constraint on because the alternative, asking users to trust that today’s promises will hold up across decades of business pressure, isn’t a fair deal.

Meta didn’t betray a guarantee. They removed an option, the way the option was always going to be removable. That distinction is the entire point.