Iran Block logo
IRAN BLOCK

Methodology

Where these numbers come from, how they are produced, and what they cannot tell you.

Where the numbers come from

01

Where the data comes from

Nothing here is measured by us alone. 42 collectors are polled on fixed schedules and stored verbatim; the interval beside each is how often it runs.

IODA0 * * * * UTC
IODA provinces23 * * * * UTC
Cloudflare Radar5 * * * * UTC
Cloudflare BGP events15 * * * * UTC
Connectivity probes20 * * * * UTC
Cloudflare anomalies35 * * * * UTC
ArvanCloud Radar4,14,24,34,44,54 * * * * UTC
Routing snapshots25 */2 * * * UTC
RIPEstat update volume30 */2 * * * UTC
RIPEstat routing40 */2 * * * UTC
RIPEstat prefix history45 */2 * * * UTC
RIPEstat routing events50 */2 * * * UTC
bgp.tools10 */6 * * * UTC
OONI tests55 */6 * * * UTC
RIPE Atlas results58 */6 * * * UTC
Tor Metrics52 */3 * * * UTC
Event evidence archive47 * * * * UTC
Telegram channel posts12,27,42,57 * * * * UTC
In-country matrix0 */3 * * * UTC
Fixed comparison references32 5 * * * UTC
OONI network outcomes32 3 * * * UTC
IHR hegemony7 1 * * * UTC
APNIC estimates17 2 * * * UTC
OONI domains22 3 * * * UTC
Access Now reports12 6 * * * UTC
Retention sweep45 4 * * * UTC
Dataset export40 6 * * * UTC
Citizen Lab test list18 4 * * 1 UTC
ISOC resilience24 5 * * 3 UTC
Evidence detection7,22,37,52 * * * * UTC
Encrypted DNS sample28 9 * * * UTC
Evidence transitions18 5 * * * UTC
Geoblocking pilot38 5 * * * UTC
Attributed probe imports9 * * * * UTC
02

Where each measurement is taken from

Vantage decides what a number can mean. OONI anomaly rates come from volunteer probes inside Iran and are the only in-country measurement here. Our direct reachability probes run from outside Iran, so for Iranian services they measure inbound international access, and for international apps they measure nothing about Iran at all — which is why the dashboard scores the gateway over Iranian-hosted services only. IODA, Cloudflare Radar, RIPE and Tor Metrics each observe from their own infrastructure.

03

Published blocklists

Beside its own measurements, IranBlock holds three fixed, published snapshots of names recorded as blocked. They are shown with their dates and sources and never as today's state.

Not imported yet.

04

What IranBlock derives from them

Suffix rules: a name counts as a whole-platform or public-suffix rule when it is listed itself and at least 50 of its direct subdomains are listed under the same mechanism. Inferred from the list, never measured; top-level domains cannot be inferred this way.

Address blocks: the IRBlock study's blocked-address files are aggregated to /24 blocks and attributed to networks with the bgp.tools routing table on the import date. Single addresses are not stored.

DNS injector: OONI web measurements already sampled by IranBlock are classified by their DNS answer. 10.10.34.34–36 is Iran's block-page address; a set of fixed real addresses documented by the Paderborn study, such as 216.239.38.120 (Google enforced SafeSearch), is a substitution.

Offline index: a Bloom filter over every listed name, split into 256 shards, which /check uses only when its lookup cannot be reached and only after a reader saves it. About 1 in 100 answers is a false match.

05

Live check from inside Iran

The live check on /check measures a domain the moment a reader asks, from a residential exit inside Iran provided by a commercial proxy network (one subscriber's connection on the chosen operator) and from a datacenter abroad as the control. It records, in order: the DNS answer the exit receives for the name (an answer in 10.10.34.0/24 is Iran's injector), whether a TCP connection to the site's real address opens, whether a plain TLS handshake completes or is reset once the name is sent, whether an Encrypted Client Hello, a fragmented ClientHello or HTTP/3 gets through instead, and what the page itself returns (the filter's block page, the site's own refusal, or its content). The verdict is rule-based: injected DNS, a reset after the ClientHello, a block page and a valid certificate followed by a 403 each have one reading. The real address is always resolved on our server; an injected answer is observed, never connected to.

One exit is one subscriber at one moment, so a single run is a reading, not a ruling. The proxy network does not relay UDP, so HTTP/3 and UDP DNS cannot be measured from inside and are shown as unmeasurable, never as blocked. Each run spends part of a daily byte budget; when it is spent, the card says so. Nothing about the reader is sent with the measurement. The in-country browser on /browse uses the same exits to show a page from a short, operator-maintained list of Iranian official and public-service sites as a subscriber receives it: the page is rewritten to run no scripts and to load only the files it referenced, each signed for that session, and the panel lists every file and its outcome. There is no free address entry.

06

Where IranBlock’s own measurements come from

Besides OONI’s volunteers and our probe abroad, IranBlock measures a fixed list of sites itself from inside Iran: on a schedule, from consumer connections on a handful of Iranian networks, one exit per check. Each check asks for the site’s address, connects, completes the TLS handshake with its name and reads the first part of the reply, and gives the same verdict words as the live check; when a site is blocked, or a block changes, the full set of ways around it is tried once more. Three Iranian sites that should always open are measured beside the others, so a failing connection shows as a failing control, not as blocking.

It can say whether a site opened from a given network at a given hour, how it was blocked there, and whether networks differ. A row on /check leads with it only when at least three networks were measured in the last six hours.

It cannot say what every subscriber on a network sees: one exit is one connection at one moment, the networks are a handful of Iran’s many, and mobile and fixed lines on the same network can differ. It does not say who blocked a site or why.

07

Google traffic

Every 30 minutes the worker reads Google’s Transparency Report for Iran: for each Google product, Iran’s share of the world’s requests, normalised by Google with added noise and published about 75 minutes late. The last three days are re-read on every run, so late or revised points replace stored ones; a response in an unexpected shape stops the run instead of storing nothing. History since 2009 was loaded once, as Tehran days.

In the verdict, five everyday services (Search, Images, Gmail, Maps, Translate) are each judged against the same hour of day over the previous 30 days; a reading departs when it is at least 50 % below the median and three robust deviations out. The Google source departs when two of the five do. Tested on Google’s own history since 2023 plus November 2019, the rule flagged all four independently recorded shutdowns within hours and raised no false alarm in about 26,000 quiet hours (scripts/google-backtest.js). YouTube and Blogger, which are blocked in Iran, and the near-empty series never vote.

The Google page compares each product with the same hour over the previous year instead, and classes the pattern: a blackout (four or five services down) or a whitelist (Search or Images back while Gmail, Maps or Translate stay under 30 %). Google traffic

How a verdict is formed

08

Evidence and coverage rules

2026-09-evidence-v4

“No new disruption” does not mean unrestricted access. An unchanged verdict requires at least two recent evidence families. IODA and RIPE routing conservatively count as one family. Legacy confidence scores are rules, not statistical probabilities.

Freshness limits: direct probes 2 hours; IODA and Cloudflare 3 hours; RIPE 5 hours; OONI 72 hours; Tor 96 hours. Observation, collection and computation times remain separate. Daily data belongs to its reported day. Missing reports cannot confirm recovery. Event metrics hold their pre-departure comparison until two known readings return; a prolonged outage cannot recover merely because the rolling median adapted.

The rolling median uses the previous 30 days. A fixed reference preserves the first captured complete calendar month with at least seven observed days; it does not automatically move. That reference need not be an unrestricted period. Event dossiers are retained with content hashes after the archive job runs.

Network cells require five eligible tests and a recent observation. Accessible, anomalous, confirmed and failed outcomes remain separate. Failure stages use a small daily OONI sample, not a representative estimate. Speed comes from Cloudflare speed tests (the last 90 days per network, percentiles of individual tests); self-selected, to Cloudflare’s nearest server, and Cloudflare WARP users are shown apart from Iranian networks.

09

Baselines: normal versus new

Each headline reading is compared with the median of its own previous thirty days, with the median absolute deviation (MAD) as the yardstick: a reading counts as a departure when it sits at least three of those deviations from the median and also clears an absolute margin set per metric — ten points for an OONI anomaly rate, for instance — so a flat series cannot flag noise. Cloudflare traffic is compared with the same hour of day, since it has a daily cycle. Nothing is smoothed and nothing is stored; the baseline is recomputed from the raw rows every fifteen minutes.

10

How an incident is raised

A detection pass runs every 15m, separately from collection. Each reading is judged against the same service's own baseline, not a fixed level: an OONI test against its 28-day median anomaly rate (an incident when it rises 20 points), a network's route visibility against its 30-day normal (below half), HTTP requests to Cloudflare against the median for the same hour (below half), Tor users against the previous week, and IODA's BGP and ping signals against their 7-day peak. A service that is always blocked is therefore not re-reported as news; the censorship pages show that state. An incident closes when a later reading is back inside a recovery margin, and that reading's time is recorded as the recovery. Probes from abroad do not raise incidents: an Iranian service unreachable from outside is not an event inside Iran, and /connectivity shows them.

After an incident closes, the same service cannot open another for a short window, so a reading that hovers at the threshold does not flap:

ioda · 90mcloudflare · 90mbgp · 150mooni · 400mtor · 720m
11

How corroboration is counted

After every detection pass, each new incident records two things about the three hours around it: how many of the six detectors were firing, and which ones collected their inputs successfully and raised nothing. The second is counter-evidence — a source that ran and stayed quiet argues against a country-wide disruption. A source that simply had not run in that window is excluded from both counts, because silence is not disagreement.

12

What the confidence score means

Confidence is not computed from the evidence. It is a fixed number attached to whichever collector detected the condition, capped at 95:

ooni · 82ioda · 78cloudflare · 74bgp · 72tor · 68any other source · 60

The incident type then adjusts it: +10 when a service is fully unreachable, +3 for an irregular reading, nothing otherwise.

So a high score means a historically reliable detector fired — not that several sources agreed. Corroboration is recorded separately, in the signal count and conflicting-sources fields on each incident. Read the evidence on an incident page and judge it yourself.

13

The verdict: a count, not a judgement

Seven independent sources — OONI, the gateway probe, IODA, Cloudflare Radar, Google traffic, Tor demand and ISP routing — are each reduced to one state: within their 30-day baseline, departing from it, or no data. OONI, with many tests, counts as departing when two tests do or one of the four that carry most traffic does; Google traffic counts as departing when two of its five everyday services (Search, Images, Gmail, Maps, Translate) do. The level is the number of departing evidence families (IODA and ISP routing count as one): none is “no new disruption”, one is “watch”, two is “disruption”, and three with IODA, Cloudflare or Google among them is “major”. The matrix on the dashboard shows the same cells for each of the last 24 hours, so the count can be checked by eye. The collector’s machine-written summary is still shown, labelled, but no longer decides anything. An event is a stretch of hours in which two or more families departed together, and it is given two lengths: the hours of that agreement, and the span until every affected family was back within its baseline, which one source still departing alone can stretch to days. An event already under way when the measured window opens is not listed on its own, because its start cannot be seen.

14

The three headline scores

Each is a direct calculation over the newest reading of every input — no smoothing, no weighting, no history.

Censorship score

100 − min(mean OONI anomaly % across the latest run of each test, 100)

International gateway score

Iranian-hosted services reachable by the probe ÷ those monitored × 100 (lib/data/vantage.js decides the group)

Network score

ISPs whose routes RIPE peers can see ÷ ISPs with a visibility reading × 100 — a missing reading is excluded, not counted as down

What it cannot tell you

15

What this cannot tell you

  • Our own reachability probes run from outside Iran on a schedule — not from your connection, and not from inside the country. They send ordinary browser requests, so a site treats them as it treats a visitor; when our server gets no answer, the target is asked once more from a second network outside Iran, and the verdict says whether that one was answered. OONI is the only in-country source here, and its volunteer probes are spread unevenly across networks. A service can be reachable on one network and blocked on another at the same moment.
  • Collection intervals range from ten minutes to a week. A short disruption between two runs leaves no trace here at all.
  • Corroboration is measured across sources, not within one service. The detectors watch different things — per-service reachability, national outage signals, per-ISP routing — and mostly share no service key, so the signal count says how many independent detectors were firing during the incident's window, not how many confirmed that specific service.
  • Only services on the monitoring list are probed, and only ISPs visible in public routing data are tracked. Absence from this site is not evidence that something is working.
  • Nothing here establishes intent. An unreachable service may be blocked, misconfigured, overloaded or failing for reasons that have nothing to do with censorship.
16

How long data is kept

Raw measurements are pruned on a fixed schedule, and incidents are pruned by type: routine probe noise is kept a month, the notable events this project exists to record are kept well over a year, and anything still open is never removed. Anything older than these windows is gone, so charts cannot reach further back than the shortest series they draw on.

connectivity_probes · 90dioda_asn_signals · 90darvancloud_monitoring (per minute) · 7darvancloud_hourly · 730drouting / BGP history · 90dcloudflare_traffic · 180dihr_hegemony · 180dooni_measurements · 730dincidents — critical / disruption · 400dincidents — inactive / irregular · 30dincidents — open · never prunedpublished blocklist snapshots · never pruned
17

Corrections

Detection is automated and unreviewed, so mistakes reach the site unedited. If a reading here is wrong, the raw measurements behind it are public through the API — check them, and tell us what you find.

Read the data yourself →