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.