IRBlock

Longitudinal measurement of Internet censorship in Iran, observed from outside

Questions and answers

How does measuring from outside Iran work?

We use the censor's own bidirectional blocking mechanism as a side channel. Much of the GFI's filtering acts on traffic regardless of the direction it travels, so a crafted packet sent inward from our probes provokes filtering that a user inside would also encounter, and the injected response is the measurement. No volunteers or devices inside Iran are involved.

Note the direction of that claim. What we trigger, a user inside would meet as well; the reverse does not follow, because filtering that responds only to traffic originating inside never answers our probes. Our results are a floor on what someone in Iran experiences, not a reproduction of it.

So what exactly are you measuring?

The bidirectionally-triggerable portion of Iran's filtering apparatus. This distinction matters, and it is not a hypothetical one: our earlier study of China's Great Firewall found that bidirectional blocking is not symmetric, and that some filtering only responds when probed from inside the country. Filtering of that kind is invisible to us by construction, however thoroughly we scan.

So this dashboard should be read as a continuous, near-complete census of the filtering we can provoke from outside, not as a complete census of censorship in Iran.

Why measure this way if it has blind spots?

Because the alternative costs more than it gains. Continuous large-scale measurement from inside Iran would mean recruiting volunteers to run probes against a strict surveillance apparatus, and we are not willing to create that risk for the sake of coverage. Renting in-country vantage points is not a workaround either: sanctions and Iranian regulation make servers there impractical to obtain, and the handful one might get would not represent a country-sized network. Probing public servers inside the country at the volume this work requires raises its own ethical problems.

Measuring from outside is therefore a deliberate trade. We give up the filtering that can only be triggered from inside, and in exchange we get continuous coverage of essentially the whole address space, sustained over years, at no risk to anyone in Iran. Volunteer-based platforms such as OONI make the opposite trade, and the two together see more than either does alone.

If something does not appear here, is it uncensored?

No. This is the single most important thing to understand about these figures. A domain, address or mechanism showing nothing may be uncensored, may be censored in a way we cannot observe from outside, or may simply not have been reached in that scan. Where we can tell those cases apart we say which; where we cannot, we say that too. Every figure here is a lower bound on censorship, never a complete picture.

Why are Iran's mobile networks barely represented?

Because we cannot see them, not because they are uncensored. We detect censorship on under 2% of the address space belonging to Iran's mobile carriers, against 89 to 100% for fixed-line networks. In-country measurements published by OONI confirm blocking in those same networks at rates equal to or higher than elsewhere. Roughly a third of Iran's IPv4 space sits in networks where our numbers are effectively a floor.

We have not established the cause, and there are at least three candidates. Cellular networks generally deploy carrier-grade NAT that discards unsolicited inbound traffic; we separately observe carrier-side captive-portal responses that may answer our probes before they reach any filtering; and the filtering on those paths may simply not be bidirectionally triggerable. All three would look identical in our data, so we report the gap rather than explain it.

Why do your numbers differ from OONI's?

The two projects measure different things and are complementary rather than competing. OONI relies on volunteers running tests from inside the country, which reaches networks we cannot, including mobile carriers, but depends on where volunteers happen to be. We probe the entire address space continuously from outside, which gives near-complete coverage of fixed-line networks but misses paths our packets never traverse. In the networks both methods reach, both find censorship to be pervasive. Neither approach describes Iran on its own.

What do the four mechanisms mean?

A domain can be caught by one mechanism and not another. That is a real property of how the system is configured, not an inconsistency in the data.

What do the gaps in the charts mean?

They are periods when we measured nothing, caused by factors outside our control such as network and power outages or storage and system maintenance, as well as Iran's own Internet shutdowns. The line breaks across them rather than joining over them, and long gaps are shaded, because drawing a line through unmeasured time would invent a trend we never observed. This is different from the line genuinely falling to near zero, as it does during the 2026 shutdown, where we were measuring and the censorship itself had collapsed along with the country's connectivity.

How often do you scan?

Scanning is continuous, but the cadence has varied across the record and each point on a chart is one scanning batch rather than a fixed interval. We publish coverage as a percentage of our tests and dates at month granularity rather than exact scan times, because publishing the precise rhythm of our probes would make them easier to identify and block.

Why are so few events marked on the coverage chart?

Because most candidates did not survive scrutiny. We only mark a change when it is large relative to the series' own variation, is not explained by a disturbance in our own measurement pipeline, and is corroborated by an independent public source. Several striking-looking shifts were examined and left off: some coincided with changes to our own infrastructure, one turned out to affect our pipeline generally rather than Iran, and others we simply cannot explain. The data contains more movement than the annotations claim, and we would rather show an unexplained bump than attach a story to it.

What does "triggered in N% of scanning batches" mean on the domain lookup?

It is the share of our scans of that mechanism in which the blocking rule fired. A low share is not a weaker measurement: it is a rule that genuinely fired on only some batches, which may mean the block was lifted and reimposed, or applied to part of the network rather than all of it. A rule appears at all only if at least two independent scans inferred it, which keeps one-off noise out. The same test applies to all three mechanisms, so presence is comparable between them.

The months either side of the share bound the batches the snapshot draws on, not the life of the block. A rule may have been in force long before the earliest month shown, and one whose period ends before the present may have been withdrawn or may simply not have been re-observed. Neither month should be read as the date blocking started or stopped.

How is a rule's shape inferred, and why does it sometimes change?

Whether a rule exists and what shape it takes are judged separately, and shape is the noisier of the two. For HTTP in particular a domain can read as an exact match in one scan and a suffix match in the next. When that happens we show the most common shape and label it, rather than discarding the domain over the disagreement.

The same instability can move where a rule appears to be anchored. A block on a domain is sometimes inferred against the domain itself and sometimes against its parent, so one block can surface under two anchors across a run of scans. Where that happens the lookup reports the best-supported anchor and says so, which makes the share a floor: the true coverage is the share of scans in which any matching rule fired, and that is at least the figure shown.

Why might a domain be missing from the lookup?

Several reasons, and "it is not blocked" is only one of them. The domain may never have been in a scan's test list; inference may not have converged on a rule; or the block may take a form we do not capture. The index also covers only rules anchored on the domain you type or on one of its parents, so rules anchored on unrelated substrings, which do exist in the full rule lists, are not searched. Finally, the rule snapshot spans a shorter period than the coverage charts, so a block that predates the snapshot will not appear even where the charts show censorship at the time.

Can I use this data?

Yes. Everything on this dashboard is free to use for academic research, with citation.

Beyond what is shown here, we provide two curated bulk datasets on request: aggregated censored IP addresses by network and mechanism, and tested and censored FQDNs with the mechanism and inferred rule for each. We share these directly rather than posting them openly, because a public dump of exactly what we can see is the fastest way for the operator to make it invisible, and because we want to know what a dataset is being used for. Researchers, circumvention developers and journalists are all welcome to ask. See Research for the citation and how to get in touch.