LoginSign UpSite Members:1,049

Measuring censorship in India: bounded data and conclusions

Measurements of filtering always depend on vantage point, time and method. Studies of India in 2015 showed how limited data produce limited conclusions; do not generalize one connection’s result to a whole country today either.

Cream gateways and charcoal paths with a removable red barrier and an unmarked observation disc

It is easier to notice that a site is blocked in a country than to measure that blocking precisely. Networks are large, providers differ, and what you see from one connection in one city may not repeat on another operator or in another city. Studies of censorship in India published in 2015 made that limit clear: the data came from a few vantage points and could not speak for an entire vast country.

This page is not a fresh report on filtering in India in 2026. The lasting lesson of that research, and of similar work, is that a measurement always depends on vantage point, time and method. Do not turn one test from a café or a home line into a claim about a whole country.

The layers of restriction — an outage, a disruption, a filter, an account limit — are separated in how internet access is restricted. Choosing a path when one route is closed is covered in choosing circumvention routes. This text is access education: it helps you see what an observation can and cannot say. It is not a circumvention recipe for a particular network.

What measurement can and cannot say

Common methods answer a few specific questions, not an eternal political verdict:

  1. Whether a domain name resolves, and to which address.
  2. Whether a connection to that address succeeds or is cut along the way.
  3. Whether the reply is diverted to another page, the certificate is swapped, or the attempt times out.
  4. Whether the same behaviour differs for encrypted and unencrypted requests.

Projects such as OONI collect those tests from volunteers in many countries and describe the test types on the network test page. The result is usually “from this network, at this time, this domain behaved like this” — not an eternal verdict for a whole country.

The same logic holds today wherever you are, including on the networks you use yourself. A tool that opens a path on one operator today may fail tomorrow on another. Do not confuse an outage, a shutdown or an account restriction with filtering.

Why the 2015 India research still teaches a method

India is a country with many operators, diverse states, and a mix of fixed and mobile lines. When data is gathered from only a few cities or networks, even a careful test method does not produce a map of the whole country. A domain may be cut in one state on one operator and remain open in a neighbouring state, or it may appear only on mobile data and not on a fixed line.

The studies that year showed that variety and, at the same time, put the sample’s limits on the table. Reading them today is more useful as a methodological warning than as a list of blocked sites in 2015. That list has aged; the sample limit has not.

  1. Look in the report for the number of vantage points and the name or type of network.
  2. Separate the collection date from the publication date of the article.
  3. See which protocol the test used: name resolution only, or a full web connection.
  4. Quote the result in a bounded sentence, not with a sweeping national headline.

Write down the vantage point, the time and the path

Even a correct observation becomes misleading if it is written without context. “The site did not open,” without city, operator, connection type and time, is almost impossible to compare.

  1. If you record an observation, write the time, the type of network — mobile, home, work — and the operator’s name if you know it.
  2. Once, and only if it is safe for you, try the same domain from another network and keep the results separate; two different results do not cancel each other, they are two vantage points.
  3. Do not mix browser errors together: a timeout, a rejected certificate, a custom operator page and a “not found” message mean different things.
  4. Do not confuse a service’s geographic limit or an error on the site itself with a network filter.

If the path opened the second time from another network, you still do not have a national verdict. You only know that two paths behaved differently.

Do not turn one observation into a country’s policy

The temptation of a large headline is strong: “Country X blocked site Y.” Sometimes there really is a nationwide order and many measurements show the same thing. Sometimes it is only one operator, one state, one temporary event, or even a technical fault.

  1. Before you repeat a claim, see how many networks and how many days it covered.
  2. Prefer a source that publishes its method, its sample limits and raw or near-raw data.
  3. Do not use an old report to choose an access tool today.
  4. State your own observation as “from my connection, today,” not as “in this country.”

Keep outages, filters, accounts and apps separate

If an app will not open, the network may be blocking that domain, the service may not operate in that region, your account may be limited, or the store may not show the version. The access-restriction guide explains those layers; here the reminder is only to keep them apart so you do not name a sign-in error “national censorship.”

  1. If the same site on the same network opens in another browser or after you clear stored data, the problem may be the cache or an extension rather than a filter.
  2. If only one account is closed and others still work, the issue is the account, not a filtering map.
  3. If all connectivity is down, measuring a single domain means very little.

Anonymity of a connection is also not the same as a site being reachable; those limits are in the limits of anonymity in communication. Safer browsing is covered in safer web browsing.

How to read a measurement report

A good report usually does not hide its method. You do not need to be a network specialist to ask a few plain questions.

  1. What exactly did the test send, and what reply did it count as “blocked”?
  2. How many probes, over what period, from which networks, sent data?
  3. Were negative results — meaning the site was open — published as well, or were only blocked cases highlighted?
  4. Is an independent repeat possible, or is there only a chart with no data left behind?

OONI is one example of a project that writes its method down. Using it, or any similar tool, should follow your own sense of risk: installing a network probe on a device that should not attract extra attention is itself a decision, not a requirement of this page.

Do not tie the choice of an access path to an old report

If work or family contact needs a path that is closed from your network today, choose a tool from the experience of this network and this week. A five-year-old report from another city is at most a historical hint.

  1. Get a tool from that project’s official path, not from an unknown file advertised “for getting around a filter.”
  2. Do not label one tool as something that “always works” or “never works”; behaviour changes by operator and by time.
  3. If a tool suddenly stops, that does not necessarily mean a change in national policy; that particular path may have been closed.
  4. Do not write configuration details in a public group with the network name and the exact hour if that would mark you or other people.

What this page does not measure

This text does not say which domains are open or closed in India today, and it does not offer an up-to-date block list. It is also not a hidden configuration guide for a particular network. Its aim is that when you see news, a chart or your own experience, you keep the concluding sentence as small and as defensible as the data allows.

  1. If you saw only a chart with no method, do not make a work decision on that basis.
  2. If you run a test yourself, do not expect the result to repeat exactly for a friend on another operator.
  3. If a news item refers only to “Indian users” and names neither network nor city, read it as incomplete and do not reshare it until more context appears.

Common mistakes

  • Generalising one café test to an entire country.
  • Treating a network outage, an account limit and a domain filter as the same thing.
  • Repeating a headline with no date, no network name and no method.
  • Choosing an access tool only from an article written years ago.
  • Forgetting that two operators in the same city can behave entirely differently.

What to do today

  1. When a site fails to open, do not turn a single person’s test into a general verdict.
  2. If you need comparable data, look at measurements that publish their method and their limits.
  3. Choose an access tool from the experience of this network and this moment, not from an old report somewhere else.
  4. Note your own observation with the time and the type of network if you want it to be comparable later.
  5. Before you reshare a claim about “the whole country,” check the number of vantage points and the date of the data.
  6. If you see two results from two networks, keep both with their own context rather than calling one “right” and the other “wrong”; a difference between vantage points is itself part of the data.

Careful measurement is useful work, as long as the concluding sentence stays as bounded as the data allows. The 2015 India research showed that for a large country, and the same methodological warning still holds for any other network, including your own, in whatever country you are in.