How to track the evolution of a censorship order over several months

A censorship order can look stable on paper while its practical effects change. A DNS resolver may switch from returning an address to returning an error; a website may begin redirecting requests; or an enforcement change may affect only one network or protocol. Reliable tracking therefore means repeating the same checks, preserving raw evidence, and separating a legal requirement from the filtering behaviour observed on a particular connection.

In Australia, that distinction has particular value. The residential broadband market is heavily concentrated around Telstra, Optus, TPG and Vodafone, while mobile broadband and regional fixed-wireless services can behave differently. Test times must also account for AEST and AEDT, and a public Wi-Fi login page in a Melbourne café can resemble a blocked destination. A multi-month record works best when every observation identifies its resolver, connection type and timestamp.

Establish a precise baseline

Convert the legal instrument into a testable scope. Record the issuing body, date, wording, affected services or addresses, required actions, exemptions and any scheduled review. Keep the original text beside the monitoring notes. A broad description of a restriction can expand into an inaccurate claim about which sites are affected, particularly when the wording covers a service rather than a particular hostname.

Record the starting position before testing the suspected restriction. For a domain, save the exact URL, hostname, response status and error message. For an IP address, document the address, any associated hostname, connection protocol and observation time. A failed connection to a shared hosting address may reflect server trouble, while a consistent DNS error can indicate filtering. These are different observations and need different evidence.

Net Neutrality Monitor’s how it works page describes its beta monitoring service, which is powered by AirVPN and supported by volunteers. Users can submit URLs and IP addresses for monitoring and compare country-specific results. Its blacklists, probe results, DNS observations and statistical reports can help establish a baseline, but they are indicative research data rather than findings about an ISP’s legal compliance.

Separate legal scope from technical effects

Read the operative wording before choosing test URLs. A directive may name a service, address, domain or category, and it may impose duties on different network actors. Its implementation can be narrower than the headline description suggests. The monitoring record should cite the relevant clause instead of paraphrasing it in a way that adds requirements the original text does not contain.

Ownership and subject matter are unreliable proxies for coverage. A page about drone operator training could disappear because its hosting changed, a server rejected requests or access was restricted; its aviation subject does not establish that an order applies. The same caution applies to sites hosting several kinds of material, where one unreachable path does not prove that every page on the domain is blocked.

Build a scope record for every candidate. It should contain the exact hostname or address, the clause relied upon, the expected technical behaviour if known, and the date of the test. If the legal material is unclear, mark the scope as unresolved rather than filling the gap with assumptions. That prevents a later improvement in availability from being mistaken for proof that the original restriction was enforced.

Measure DNS and connection behaviour

Filtering can occur at several layers. A recursive resolver may suppress a name, a network route may block traffic to an address, and an origin server may refuse an application request. Testing only a browser may conflate these mechanisms. Record the resolver response separately from the HTTP outcome so that a DNS block is not incorrectly described as a connection timeout.

Document whether the test uses the ISP’s default resolver, a public resolver or DNS over HTTPS. Changing resolvers can change both the returned address and the route taken to it. Test IPv4 and IPv6 only when both are available, and avoid attributing an IP-level block when a shared CDN address is involved. A virtual private network may also replace the normal network path, making the result useful for comparison but less representative of an ordinary household connection.

Translate technical failures precisely. NXDOMAIN suggests that the resolver could not find the name; SERVFAIL indicates a resolver failure that requires further investigation; a timeout can result from routing, congestion or deliberate interference; and an HTTP 403 may come directly from the origin server. Australians may describe a stalled connection as a “drop-out”, but the log should preserve the underlying status, headers and resolver response rather than rely on casual terminology.

Keep observations independent and repeatable

Standardise the test conditions. Use the same device or connection profile, the same URL path and the same resolver wherever possible. Check at regular intervals, but avoid scheduling every observation during the same busy hour. Store timestamps in UTC alongside the Australian local time so daylight-saving changes do not distort comparisons across months.

Independent vantage points help reveal network-specific effects. Neumon’s volunteer probe network can provide observations from distributed locations, allowing a result seen at home to be compared with results from elsewhere. This is particularly important when one route appears normal but another consistently fails. A distributed result should still include its location and network conditions, since a probe without context is weak evidence.

Keep the testing modest and the record precise. Automated requests should not place unnecessary load on the affected service, and logs should exclude unrelated personal information. Retain raw responses, relevant headers and screenshots rather than only a summary saying “blocked”. Record the monitoring tool and its version, because changes in the tool can otherwise be mistaken for changes in censorship.

Compare months without changing the method

Create weekly observations and a monthly snapshot from the same checklist. The snapshot should capture the target’s status, DNS behaviour, response type, tested paths and any differences from the previous month. Keep the underlying weekly material so that a short-lived change is not lost. The legal order may also have been amended, so its text and review dates belong alongside the network results.

Compare like with like. A test through a residential broadband connection should not be compared directly with one through a commercial VPN, and desktop results should not be presented as evidence about a mobile network. Retain a control host with a stable, unrelated service to identify general connectivity problems. If an observation disappears, record it as a missing data point rather than treating an interrupted test as a successful unblock.

Annotate plausible causes without letting them replace evidence. Server maintenance, CDN configuration, an expired certificate and an ISP outage can resemble interference. A captive portal may redirect every HTTP request, while a regional route fault may create timeouts. Where several explanations remain possible, preserve the ambiguity in the monthly notes. The aim is to track a trend, not to force every result into a binary label.

Read results in their local context

Australian conditions can make identical requests produce different outcomes. Perth and Brisbane sit in different network regions, fixed-line and mobile paths can use separate infrastructure, and a household may replace its ISP-provided resolver with Cloudflare or Google DNS. These differences do not prove censorship, but they define which comparisons are meaningful. Identify the access network and resolver in every record rather than describing a result simply as “Australian”.

The project’s explanation of why volunteer probes matter makes the case for observations closer to ordinary users’ networks than commercial VPN exit locations. That distinction matters when assessing a restriction’s reach, because a server response from an overseas data centre may behave differently from the same request made over an Australian broadband service.

Common observations fit several very different causes:

Observation	Possible cause	Check before attributing it to an order
NXDOMAIN from the selected resolver	DNS filtering, a retired hostname or a typo	Compare an independent resolver and check the domain’s authoritative records
Connection timeout	Slow server, route loss, regional outage or packet filtering	Repeat through another access type and at another time
TLS handshake reset	Middlebox interference, server policy or a routing problem	Compare another resolver, protocol and network
HTTP 403 or 451	Application denial or an origin-enforced restriction	Read the response headers and distinguish origin errors from network blocks
Redirect to a login or warning page	Captive portal, CDN challenge or provider notice	Record the destination and test outside that portal

A recurring result becomes stronger when it persists over several months under unchanged conditions. A single failure, however consistent, does not establish a trend.

Lock the baseline and schedule the next review

A durable monitoring archive should be compact enough to review and complete enough to challenge. Each monthly review should note continuing restrictions, newly affected destinations, changes in error type and plausible confounders. Keep the original evidence and the legal source distinct from the interpretation. When a destination becomes reachable again, record the date and conditions rather than assuming the underlying restriction has ended.

The immediate next step is a dated baseline record containing the affected address, resolver identity, Australian observation time and raw result.