'Resource Inaccessible' was the most frequently reported issue (61% of 119 submitted reports) during a month of naturalistic Tor Browser browsing, followed by CAPTCHAs (18%), Broken Content (17%), Other Issues (13%), and Timeouts (5%). These categories document the operational failure modes that degrade everyday Tor Browser usability beyond protocol-level censorship.

CAPTCHAs co-occurred with 'Resource Inaccessible' in 70% of CAPTCHA reports and appeared in 23% of all 'Resource Inaccessible' reports; overall 14% of the 119 reports involved one or both problems. Two CAPTCHA failure modes were identified: excessive repetitive CAPTCHAs and broken CAPTCHA servers that made the underlying website permanently inaccessible. The 'Unusual traffic detected from your computer' Google error appeared in 5% of all reports.

§6.1.2 evaluation

17% of ReporTor reports cited broken content; investigation found that several websites returned HTTP 403 errors through Tor Browser but loaded normally in Firefox, revealing deliberate differential treatment of Tor traffic masquerading as technical failure. Blocked resources included advertising platforms (e.g., t.co) and JavaScript files handling cookie-consent dialogs, and 8% of reports involved authentication failures where initial page load succeeded but subsequent auth steps were silently refused.

§6.1.3 evaluation

Two mechanistically distinct blocking categories account for Tor exit-node inaccessibility: explicit blocks (deliberate CDN/WAF configuration, e.g., Akamai Bot Manager renders AirBnB inaccessible over Tor) and dynamic blocks (abuse-detection systems that flag Tor exit-node IPs because pooled traffic from diverse users raises apparent abuse scores, triggering rate-limiting or blocking despite no explicit Tor policy). Cloudflare does not block Tor by default, but its aggressive IP scoring results in disproportionate blocking in practice.

§6.1.1 evaluation

The privacy properties of Tor Browser structurally preclude automated telemetry collection, creating a persistent blind spot for diagnosing user experience failures at scale. ReporTor demonstrates that anonymous voluntary in-situ reporting — transmitted over the Tor network and stored in a password-protected onion-service database — can substitute for telemetry: 119 reports over one month from five expert users sufficed to reproduce approximately half of reported issues exactly and identify root causes for most of the remainder.

§1, §7.1 evaluation

Cloud-hosted services represent an open measurement problem for ZMap because IPs are shared, ephemeral, and behind CDN layers, making traditional IP-to-service attribution unreliable. The paper identifies reconciling scan-based observation with cloud infrastructure as a key challenge for the next decade.

2024-durumeric-ten-years-zmap Abstract — open problems measurement-platformip-blocking

IPv6 measurement remains an open problem for ZMap because the address space is too large for exhaustive single-packet enumeration, unlike IPv4. This asymmetry means IPv6-addressed infrastructure is structurally harder to enumerate via blocklisting.

2024-durumeric-ten-years-zmap Abstract — open problems measurement-platformip-blocking

ZMap can scan the entire public IPv4 address space on a single port in under 45 minutes on a gigabit connection; with a 10 GigE connection and PF_RING, the same scan completes in 5 minutes. This makes Internet-wide enumeration of proxy infrastructure operationally trivial for any well-resourced actor.

2024-durumeric-ten-years-zmap Project overview measurement-platformip-blocking

The automated probe list generation system discovered 45.79 potentially blocked domains per 1,000 domains crawled, compared to 4.11 for FilteredWeb — over 10× higher efficacy. It uncovered 1,490 potentially blocked domains in crawls of just 71,960 URLs, versus 1,255 blocked domains found by Hounsel et al. in crawls of 1,000,000 URLs, with 1,473 of the 1,490 domains not overlapping with prior work.

2024-tang-automatic §5.5 measurement-platformdns-poisoningip-blocking

VPS-based vantage points in Singapore and India detected censorship patterns similar to 'free' locations, failing to observe blocking known to be enforced by local ISPs following government directives. This occurred because ISP-level censorship is implemented per-carrier rather than centrally, and the VPS provider's ISP did not enforce those blocks — confirmed by re-testing from a residential IP that did observe the expected blocks.

2024-tang-automatic §6.2 measurement-platformip-blocking

The authors' blockpage-based methodology cannot detect transit censorship implemented via TCP RST injection or packet drops, because distinguishing these from transient network errors requires identifying their location on the routing path. As a result, the 8-country, 6-AS finding is explicitly characterized as a lower bound on the true extent of Russian transit censorship.

2023-ortwein-towards §4.1 Gathering Blockpages / §6 Conclusion rst-injectionip-blockingmeasurement-platform