2016-fifield-censors
findings extracted from this paper
-
All bridges in a given Tor Browser release batch were blocked simultaneously within a 20-minute window, and every blocking event occurred during China Standard Time business hours (between 10:40 and 17:00 CST). The combination of unpredictable multi-day delay followed by abrupt simultaneous batch blocking suggests a semi-manual process: human analysts discover bridges after an irregular delay, then an automated system applies blocks.
-
China's firewall never blocked a bridge before its public Tor Browser release, despite bridges being discoverable earlier via bug-tracker tickets and source code commits. The four bridges distributed only in Orbot (not Tor Browser) remained unblocked throughout the experiment, indicating the GFW monitors end-user software releases rather than upstream repositories or alternative distribution channels.
-
The Great Firewall of China blocked newly published obfs4 Tor Browser default bridges after delays of 7, 2, 18, 11, and 36 days following the first public software release, and up to 57 days after bridges were first discoverable via bug-tracker ticket filing. Iran showed no blocking of the same default bridges across the entire five-month measurement period.
-
Some obfs4 bridges exhibited a roughly 24-hour periodic semi-blocking pattern from China, where bridges cycled between reachable and blocked states with a ~24-hour period. This diurnal pattern differed between the two China probe sites and between bridges, and one blocking failure coincided with a documented nationwide GFW outage that also briefly restored access to Google services.
-
GFW blocking was keyed on both IP address and port number, not IP address alone. Bridges with port 22 (SSH) open had that port remain reachable even as other ports on the same IP were blocked, confirming per-(IP, port) tuple granularity in the GFW blocklist.