Censorship is a UX problem

A reader in Tehran opens your article. The page loads. They tap share. The share button reports the share back to a metadata broker baked into the third-party SDK someone added in 2019 because the marketing team wanted attribution. The article was never censored. The reader was.

This is what censorship looks like in 2026 in most of the places I actually work — not a takedown notice or a blocked domain, but a perfectly functional interface doing exactly what it was designed to do, while leaking the people who used it to whoever has leverage on the SDK provider, the DNS resolver, the CA, the cloud region, or the analytics vendor that someone added to ship a quarterly OKR in 2019.

The censorship apparatus has mostly stopped caring whether your content is up. It cares who read it.

The interface is the policy

When designers talk about censorship, the conversation usually lives in the editorial layer. What can be published. What gets removed. Whether the platform should host this or that piece of speech. The interesting censorship — the censorship that actually shapes what people in constrained environments can know, read, and do — happens nowhere near that conversation.

The work happens at the interface. The decision to require an account before reading. The decision to load a tracking pixel from a CDN that resolves through a censor's intermediary. The comments section that becomes, retroactively, a targeting list once someone with subpoena power gets curious. The “log in with Google” button that routes authentication through a network the reader can't use without flagging themselves to it.

None of this is what the designer thinks they are doing while shipping the feature. They are shipping a faster onboarding, a richer comment system, a cleaner login. The censorship is a side effect of an aesthetic choice — which is to say, it was a design decision, made without anyone in the room registering that they were making a design decision about censorship.

What the constrained reader actually does

I spent two years designing for an audience whose median reader was inside a country that surveils, throttles, and occasionally arrests over what they read online. The first thing you learn is that the reader you imagined does not exist. The reader you have is doing six things at once. They are on a borrowed phone. They are on a VPN that keeps disconnecting. They are reading in a language the OS does not fully support. They are screenshotting the article before it can be pulled. They have a separate browser profile for things they are not supposed to read.

The reader is doing all of this not because they are paranoid but because the system has trained them. Their cousin lost a job for a Telegram message. Their friend was detained for an Instagram story. Their professor's account was cloned and used to send the regime a list of students. The reader has already adapted to a threat model that most product teams have never modelled.

The design question, then, stops being how do we make this delightful and starts being what is the worst thing that can happen to this reader if our system works exactly as intended.

The decisions that change

When you take that question seriously, the design system narrows. Some of what we shipped on Raaznet — a Persian-language counter-surveillance publication serving readers inside Iran — was not invention. It was the consequence of asking the question out loud, then refusing to decorate around the answer.

No third-party JavaScript anywhere on the site. Not analytics, not fonts, not embeds, not the SDK someone offered us for free in exchange for a vendor logo. Every external script is a network call that can be inspected, redirected, or fingerprinted by whoever sits between the reader and our server, and the cost of the feature gets paid by the reader, in the worst case in jail time. So we didn't add the feature.

No comments. A comment system in this context is closer to a public transcript of a confession booth than to a community feature. We replaced the feeling of comments — the sense that other people are reading this with you — with editor's notes and reader letters that we published in batch, with explicit consent, with the readers' identifying details rewritten or removed.

No account required to read. An account is a list, a list is a target, and we did not want to be running a database of dissidents who happened to be subscribed to our publication.

Several mirror domains, on different registrars, in different jurisdictions, so that the home that breaks first is not the home most readers depend on. The one that gets seized is replaced; the seizure is documented; the reader gets used to the idea that the URL might change and the publication will still be there under a different one.

In product terms each of these is a regression — lower engagement metrics, worse attribution, no retargeting, a funnel that funnels into nothing. In design terms they are the only honest answer to the question of who the reader actually is.

The phrase the field keeps avoiding

The polite name for this kind of design work is privacy. It is not. Privacy is what you get when you opt out of tracking on a cookie banner. What I am describing is the safety floor under which a design system stops being a design system and starts being an extension of whoever has the keys to the infrastructure under it.

Most design education does not teach this, most design systems do not include it, and most product reviews do not have a section where it would live. The reviewer asks about accessibility, performance, brand consistency, visual polish, sometimes motion. The question that would have caught the leak — if our user is wrong about how safe this is, what happens to them — is not on the rubric, so the rubric scores high and the leak ships.

What this means for the rest of design

I am not arguing every product team needs a threat model. I am arguing that the people who think the question does not apply to them are usually wrong, and increasingly so.

The reader who needs you to take this seriously is not only in Tehran or Yangon or Riyadh. They are also the abused partner whose location is being shared by a fitness app's social feature. The undocumented worker whose immigration status leaks through a payroll integration. The trans teenager whose username on a kid's gaming site federates back to their school email. The journalist whose source list lives in their Slack contacts. The whistleblower whose PDF has a tracking pixel the legal team forgot to strip.

These users don't show up in analytics as a distinct segment. They show up as edge cases that get quietly removed from the persona deck because they make the deck too complicated for the all-hands. The product ships for the median user — comfortable, well-connected, unsurveilled — and the reader who was quietly cut from the deck is also, statistically, the reader who needed the product most.

Designing without political awareness isn't neutral. It is a vote, cast every time the feature ships, in favour of the user the system was already built to serve. The reader in Tehran isn't an edge case in this; they are the load test the rest of the system either passes or doesn't, and the result mostly tells you whether the rest of the product is honest with itself.