Voidly
All findingsPublished research

Why there's no 'newly-censored this week' feed (yet) — an honesty note

The most-requested thing journalists want from a censorship observatory is a global 'what got newly blocked this week' feed. We built one, tested it, and took it down before it ever shipped — because the only version the current data supports would publish false accusations against democracies. The…

Read the full published summary

The most-requested thing journalists want from a censorship observatory is a global 'what got newly blocked this week' feed. We built one, tested it, and took it down before it ever shipped — because the only version the current data supports would publish false accusations against democracies. The naive build (every country/domain pair whose first blocking measurement lands in the last 7 days) produced a top that read: 'Australia blocked sputnikglobe.com', 'United States blocked isiswomen.org' (a women's-rights NGO), 'Japan blocked isiswomen.org', 'UK blocked freespeechdebate.com'. None are real national blocks — they're single-probe anomalies (transient timeout, CDN redirect, one flaky vantage point), the noise any raw per-measurement signal carries. A feed telling the world the US just censored a women's NGO is worse than no feed. We couldn't just filter it: the confirmed national-block layer (>=3 independent networks) correctly excludes every one of those false positives, but it's regenerated as a periodic snapshot — every row carries the regeneration date, NOT the date the block began, so 'newly' has nothing to stand on; and the per-measurement evidence that does have timing mostly lacks an ASN, so we can't retro-fit a multi-network gate onto the timed rows. The timed layer is noisy, the clean layer is timeless, neither alone can answer 'what was newly, genuinely blocked this week.' What we ship instead: /data/incidents — curated, deduplicated, vetted events with evidence permalinks, plus its ?since= delta and RSS/Atom feeds. The real fix is a state-transition log: persisting a genuine first-seen timestamp on each confirmed national block so accessible->blocked transitions are recorded the day they're first confirmed across networks. That's on the roadmap. Until it exists, the global newly-censored endpoint stays unbuilt — on purpose. An observatory that names governments has to be right.

The single most-requested thing journalists ask an internet-censorship observatory for is a “what got newly blocked this week” feed — a global, rolling digest of fresh censorship. We built one, tested it, and took it back down before it ever shipped publicly, because the only version the current data can support would publish false accusations against democracies. This note explains exactly why, in the interest of the transparency the whole project is built on.

What broke

The naive build is easy: find every (country, domain) pair whose first blocking measurement lands inside the last seven days. When we ran it, the top of the feed read like this:

  • “Australia newly blocked sputnikglobe.com”
  • “United States newly blocked isiswomen.org” (a women's-rights NGO)
  • “Japan newly blocked isiswomen.org”
  • “United Kingdom newly blocked freespeechdebate.com”

None of those are real national blocks. They are single-probe anomalies — a transient timeout, a CDN redirect, one flaky vantage point — the kind of noise that any raw per-measurement signal carries. A feed that tells the world the United States just censored a women's-rights NGO is worse than no feed at all.

Why we couldn't just filter it

We have a layer that already strips exactly this noise: the confirmed national-block set, which only counts a domain as nationally blocked when it is seen blocked across at least three independent networks. We checked — every one of those false positives is correctly absent from it. So why not build the feed on the confirmed layer instead? Two hard data limits:

  • No first-seen timestamps. The confirmed national-block set is regenerated as a periodic snapshot; every row carries the regeneration date, not the date the block actually began. Without a real per-pair first-seen, the word “newly” has nothing to stand on — you cannot tell a block that started yesterday from one that started last year.
  • Sparse network attribution. The per-measurement evidence that does have timing mostly lacks an ASN, so we cannot retro-fit a “confirmed across N networks” gate onto the timed rows to filter the single-probe noise out ourselves.

So the timed layer is noisy and the clean layer is timeless. Neither alone can answer “what was newly, genuinely blocked this week,” and the honest move is to not pretend otherwise.

What we ship instead, and what would fix it

For recent censorship today, use /data/incidents — curated, deduplicated, human-readable events with evidence permalinks — and its delta (?since=) and RSS/Atom feeds. Those are event-level and vetted, not a raw per-measurement firehose.

The real fix is a state-transition log: persisting a genuine first-seen (and last-seen) timestamp on each confirmed national block, so an accessible→blocked transition is recorded the day it is first confirmed across networks. That is on the roadmap. Until it exists, a global “newly-censored this week” endpoint stays unbuilt — on purpose. An observatory that names governments has to be right.

The source record.

Original source links and labels. Linked responses may have changed since publication.