Censorship and Trade

A while back I wrote some thoughts about re-framing Internet censorship as a trade barrier. While I'm still uncertain about the consequences of doing so, I recently found this article (via freedom4internet) arguing:

Internet censorship is effectively preventing thousands of American and European e-commerce websites from reaching Chinese consumers, declare Internet marketing consultants Backbone IT Group in a recent study.

I cannot find a "study", but did find a press release by a search engine optimization company that provides services in China.

The main argument seems to be that sites hosted outside of China take 20 times as long to load as they do inside China. I don't doubt that foreign hosted websites take longer to load in fact that is why Google and others now have servers in China. But I'd like to know how these load times stack up to other countries. Is it because of China's filtering? Or is it something else.

I ran a few tests from websitepulse (see below) and China seemed to lead sites faster than Singapore and Australia. Rigorous tests would definitely be more appropriate, but I think these anecdotal tests indicate that a closer look at the methodology and data for this study would be prudent.

I am also wondering just how many ecommerce sites accept payment from China, from Chinese credit cards. In the past, Godaddy confirmed that they don't process transactions from China (this was a while ago, it could be different now). I'm not sure how widespread this practice is but I wouldnt be surprised if many ecommerce sites don't accept payment from China.

Some load times from websitepulse.com:

Tested From: Beijing, China
Tested At: 2008-09-25
08:43:47 (GMT -04:00)
URL Tested: https://www.godaddy.com/
Resolved As: 208.109.132.201
Status: OK
Response Time: 2.331 sec
DNS: 0.001 sec
Connect: 0.218 sec
Redirect: 0.000 sec
First Byte: 1.126 sec
Last Byte: 0.986 sec
Size: 147825 bytes

Tested From: Seattle, WA
Tested At: 2008-09-25
08:43:47 (GMT -04:00)
URL Tested: https://www.godaddy.com/
Resolved As: 208.109.132.201
Status: OK
Response Time: 0.473 sec
DNS: 0.001 sec
Connect: 0.040 sec
Redirect: 0.000 sec
First Byte: 0.231 sec
Last Byte: 0.201 sec
Size: 147825 bytes

Tested From: Beijing, China
Tested At: 2008-09-25
08:38:29 (GMT -04:00)
URL Tested: https://www.godaddy.com/
Resolved As: 208.109.132.201
Status: OK
Response Time: 5.958 sec
DNS: 0.571 sec
Connect: 3.218 sec
Redirect: 0.000 sec
First Byte: 1.133 sec
Last Byte: 1.035 sec
Size: 147824 bytes

Tested From: Singapore
Tested At: 2008-09-25
08:38:29 (GMT -04:00)
URL Tested: https://www.godaddy.com/
Resolved As: 208.109.132.201
Status: OK
Response Time: 7.000 sec
DNS: 1.605 sec
Connect: 3.232 sec
Redirect: 0.000 sec
First Byte: 1.199 sec
Last Byte: 0.964 sec
Size: 147824 bytes

Tested From: Beijing, China
Tested At: 2008-09-25
08:41:02 (GMT -04:00)
URL Tested: https://www.godaddy.com/
Resolved As: 208.109.132.201
Status: OK
Response Time: 3.296 sec
DNS: 0.001 sec
Connect: 0.218 sec
Redirect: 0.000 sec
First Byte: 2.182 sec
Last Byte: 0.894 sec
Size: 147825 bytes

Tested From: Brisbane, Australia
Tested At: 2008-09-25
08:41:02 (GMT -04:00)
URL Tested: https://www.godaddy.com/
Resolved As: 208.109.132.201
Status: OK
Response Time: 5.277 sec
DNS: 0.352 sec
Connect: 3.187 sec
Redirect: 0.000 sec
First Byte: 0.986 sec
Last Byte: 0.752 sec
Size: 148034 bytes

Tunisia: Law Suit over Fake 404

The ONI Blog reports that a journalist/blogger in Tunisia is suiing the government over the blocking of Facebook.

Tunisian journalist and blogger Zied El-Hen filed a suit this week in a Tunisian court against the Tunisian Internet Agency for blocking the social networking Web site Facebook, according to a report by Reuters (Arabic).

An interesting twist concerns the claim that he was mislead:

In an interesting technical argument he said that the the agency mislead him by serving the message 404 (Not Found) error message instead of the 403 message (Access Forbidden), which the agency serves to users who attempt to access banned sites.

Here is a screen shot I took during WSIS in Tunisia in 2005. You can see that the 404 page is taken from Internet Explorer, but I was using Firefox! You can see from the HTTP headers that the 404 is fake.

One important issue to remember in this case is that Tunisia is using SmartFilter, a filtering product developed by the U.S. company Secure Computing. This product is used in many countries including in Saudi Arabia, Oman, Sudan, United Arab Emirates, and previously in Iran. In these other countries they use SmarFilter to show users a blockpage that indicates to the user that the content is intentionally blocked. Instead, Tunisia uses this blockpage functionality to fake a 404 error page.

Tunisia uses SmartFilter to block access to categories of websites, such as pornography, but also adds their own targets, often political web sites, to the blocking lists. Sometimes content that was not intended to be blocked is blocked in all of Tunisia due to miscategorizations by SmartFilter.

Yahoo, MSN Censor More than Baidu

China unblocked many usually censored web sites following intense international pressure and scrutiny after having promised uncensored access during the Olympics. Five days later (August 6, 2008) I tested the search engines that Google, Yahoo! and Microsoft customize for the Chinese market as well as the leading domestic search engine Baidu. I found that all of the search engines were still censoring content that was unblocked by China. one interesting find was that Yahoo! was censoring less than all the others and Baidu (and Google) were censoring much less than Microsoft.

For purposes on comparison Google and Microsoft make a good match because both have to de-list web sites form search results while Yahoo! and Baidu index form within China and thus do not (usually) index sites already censored by China. (For more read my report on search engine comparison.)

Now over a month later things have changed. While these sites remain accessible in China some are still censored by the search engines. Google has dropped to only censoring two sites and is now censoring the least amount of content. Baidu is next with three censored sites. Microsoft remained steady, but Yahoo! has shifted from censoring the least amount of sites to the most!

The divergence between Yahoo! and Baidu is very interesting. If both crawl from within China and are subject to China's filtering why is Yahoo! censoring so much more than Baidu? It could be that the conclusion that Yahoo! and Baidu do not de-list content is not fully accurate. If the sites are accessible in China then Yahoo! is likely de-listing the sites. Because of the suboptimal method of censorship notification employed by Yahoo! (a standard disclaimer on every page regardless of whether any of the results are censored or not) I cannot fully distinguish between sites that are de-listed and sites that have not been indexed (e.g. because China blocks them).

I'm still struck by the fact that over a month later sites that are available and uncensored in China are still censored by these search engines.

DOMAINS	Google	Yahoo	Microsoft	Baidu
	ip = "203.208.39.99" host = "www.google.cn"	ip = "202.165.102.243" host = "one.cn.yahoo.com"	ip = "202.89.236.206" host = "cnweb.search.live.com"	ip = "202.108.22.43" host = "www.baidu.com"
chinese.wsj.com	OK	OK	OK	OK
cn.reuters.com	OK	OK	OK	OK
news.chinatimes.com	OK	CENSORED (0)	CENSORED (0)	OK
olympics.scmp.com	OK	OK	OK	OK
udn.com	OK	OK	OK	OK
www.amnesty.org	OK	CENSORED (0)	CENSORED (0)	CENSORED (0)
www.atchinese.com	OK	CENSORED (0)	CENSORED (0)	OK
www.ftchinese.com	OK	OK	OK	OK
www.hrw.org	OK)	CENSORED (0)	CENSORED (0)	CENSORED (0)
www.libertytimes.com.tw	CENSORED (0, message)	OK	OK	OK
www.mingpaomonthly.com	OK	OK	OK	OK
www.mingpaonews.com	OK	CENSORED (0)	CENSORED (0)	OK
www.rfa.org	CENSORED (0, message)	CENSORED (0)	CENSORED (0)	OK
www.rsf.org	OK	CENSORED (0)	CENSORED (0)	OK
www.scmp.com	OK	OK	OK	OK
www.voanews.com	OK	CENSORED (0)	CENSORED (0)	CENSORED (0)
www.yzzk.com	OK	CENSORED (0)	OK	OK
www1.appledaily.atnext.com	OK	CENSORED (0)	OK	OK
zh.wikipedia.org	OK	CENSORED (0)	CENSORED (0)	OK

Attack on Voting Machines

DNS and the GFW

While the ability to the GFW to send RST packets in an attempt to terminate a connection between a source IP and a destination IP based on keywords appearing in packets (keyword in GET requests and possibly the HTML responses) has been documented in http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf and http://www.cs.unm.edu/~crandall/concept_doppler_ccs07.pdf China also employs a similar system to interfere with DNS. If a DNS request to resolve a hostname is sent in to an IP in China, an intermediary will respond with a DNS response containing an incorrect IP. This is not totally new, it has been documented from inside China already.

I start with a "UDP Traceroute" (DNS packets with no qname with incrementing TTL's) in order to find the first hop inside China. The IP address of contained in the ICMP response is checked in Team Cymru's IP lookup service to find the AS, Country and Network Name.

1|192.168.2.1|time-exceeded  NA
2|64.230.*.*|time-exceeded CA NA
3|64.230.*.*|time-exceeded CA NA
4|64.230.*.*|time-exceeded CA NA
5|64.230.*.*|time-exceeded CA NA
6|64.230.147.14|time-exceeded CA NA
7|206.108.103.138|time-exceeded CA NA
8|160.81.109.193|time-exceeded US SPRINTLINK - Sprint
9|144.232.10.19|time-exceeded US SPRINTLINK - Sprint
10|144.232.8.169|time-exceeded US SPRINTLINK - Sprint
11|144.232.9.224|time-exceeded US SPRINTLINK - Sprint
12|144.232.9.32|time-exceeded US SPRINTLINK - Sprint
13|144.232.2.171|time-exceeded US SPRINTLINK - Sprint
14|144.223.148.2|time-exceeded US SPRINTLINK - Sprint
15|219.158.4.193|time-exceeded CN CHINA169-BACKBONE CNCGROUP China169 Backbone

For me the first CN hop to the IP address 202.165.102.247 (www.yahoo.cn) is 15. So I send a DNS request for "www.citizenlab.org" to 202.165.102.247 (which is not a DNS server) with a TTL of 15, its IP is 219.158.4.193 (CHINA169-BACKBONE CNCGROUP China169 Backbone).

###[ IP ]###
  version   = 4
  ihl       = 0
  tos       = 0x0
  len       = 0
  id        = 1
  flags     = 
  frag      = 0
  ttl       = 15
  proto     = udp
  chksum    = 0x0
  src       = 192.168.2.11
  dst       = 202.165.102.247
  options   = ''
###[ UDP ]###
     sport     = domain
     dport     = domain
     len       = 0
     chksum    = 0x0
###[ DNS ]###
        id        = 0
        qr        = 0
        opcode    = QUERY
        aa        = 0
        tc        = 0
        rd        = 1
        ra        = 0
        z         = 0
        rcode     = ok
        qdcount   = 0
        ancount   = 0
        nscount   = 0
        arcount   = 0
        \qd        \
         |###[ DNS Question Record ]###
         |  qname     = 'www.citizenlab.org'
         |  qtype     = A
         |  qclass    = IN
        an        = 0
        ns        = 0
        ar        = 0

The ICMP response comes back from hop 15:

###[ IP ]###
  version   = 4L
  ihl       = 5L
  tos       = 0x0
  len       = 56
  id        = 5984
  flags     = 
  frag      = 0L
  ttl       = 241
  proto     = icmp
  chksum    = 0xf52
  src       = 219.158.4.193
  dst       = 192.168.2.11
  options   = ''
###[ ICMP ]###
     type      = time-exceeded
     code      = 0
     chksum    = 0xc2d7
     id        = 0xeacf
     seq       = 0x3af8
###[ IP in ICMP ]###
        version   = 4L
        ihl       = 5L
        tos       = 0x0
        len       = 64
        id        = 1
        flags     = 
        frag      = 0L
        ttl       = 1
        proto     = udp
        chksum    = 0xc55c
        src       = 192.168.2.11
        dst       = 202.165.102.247
        options   = ''
###[ UDP in ICMP ]###
           sport     = domain
           dport     = domain
           len       = 44
           chksum    = 0xbca

While this is occurring I also sniff the wire to see if other packets are being sent my way, and they are. Four bad DNS responses were sent my way claiming to be from 202.165.102.247.

###[ IP ]###
     version   = 4L
     ihl       = 5L
     tos       = 0x10
     len       = 98
     id        = 45372
     flags     = 
     frag      = 0L
     ttl       = 45
     proto     = udp
     chksum    = 0xe7ee
     src       = 202.165.102.247
     dst       = 192.168.2.11
     options   = ''
###[ UDP ]###
        sport     = domain
        dport     = domain
        len       = 78
        chksum    = 0xe286
###[ DNS ]###
           id        = 0
           qr        = 1L
           opcode    = QUERY
           aa        = 1L
           tc        = 0L
           rd        = 1L
           ra        = 1L
           z         = 0L
           rcode     = ok
           qdcount   = 1
           ancount   = 1
           nscount   = 0
           arcount   = 0
           \qd        \
            |###[ DNS Question Record ]###
            |  qname     = 'www.citizenlab.org.'
            |  qtype     = A
            |  qclass    = IN
           \an        \
            |###[ DNS Resource Record ]###
            |  rrname    = 'www.citizenlab.org.'
            |  type      = A
            |  rclass    = IN
            |  ttl       = 86400
            |  rdlen     = 0
            |  rdata     = '216.234.179.13'
           ns        = 0
           ar        = 0

Summary:

192.168.2.11 > 202.165.102.247 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 0
219.158.4.193 > 192.168.2.11   time-exceeded
202.165.102.247 > 192.168.2.11 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 
    <DNSRR  rrname='www.citizenlab.org.' type=A rclass=IN ttl=300 rdata='64.33.88.161' |>
202.165.102.247 > 192.168.2.11 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 
    <DNSRR  rrname='www.citizenlab.org.' type=A rclass=IN ttl=86400 rdata='216.234.179.13' |>
202.165.102.247 > 192.168.2.11 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 
    <DNSRR  rrname='www.citizenlab.org.' type=A rclass=IN ttl=86400 rdata='216.234.179.13' |>
202.165.102.247 > 192.168.2.11 <DNSQR  qname='www.citizenlab.org.' qtype=A qclass=IN |> 
    <DNSRR  rrname='www.citizenlab.org.' type=A rclass=IN ttl=86400 rdata='216.234.179.13' |>

64.33.88.161 and 216.234.179.13 are not IP addresses that "www.citizenlab.org" should resolve to.

I used 38 IP addresses on 38 different AS's in China as targets. A DNS packet was sent to the first CN hop from a udp traceroute to each of these IPs. The IP's returned from the ICMP packet received from each hop are distributed across 11 AS's in China.

In total, I received 8 unique bad IP addresses.

211.94.66.147 24403 CN CNNIC-CNCITYNET-AP Beijing Kuanjie Net communication technology Ltd
209.145.54.50 6428 US CDM - CDM
203.161.230.171 9925 HK HKTHOST-AP Powerbase DataCenter Services (HK) Ltd.
64.33.88.161 19916 US ASTRUM-0001 - OLM LLC
202.181.7.85 7489 AU FIRSTLINK-AS-AP First Link Internet Services
4.36.66.178 3356 US LEVEL3 Level 3 Communications
216.234.179.13 13911 CA TERA-BYTE - Tera-byte Online Services
202.106.1.2 4808 CN CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network

Two of the IP's are in Mainland China and one is in Hong Kong; three are in the US and one in Australia. Only one of the CN IP's, 211.94.66.147, has a web server running when I checked which means that this server could log IP addresses that connect to it and host name in the requests. Why these IPs?

I don't know. It is pretty strange.

64.33.88.161 was the IP for falundafa.ca, the IP was blocked so an domains that resolved to it were also blocked. Seems to be legacy blocking.

If you $host bbs.hygung.com you'll get back most of these IP's, along with a bunch of others. Many of these IP's also appear on some kind of IP blocking list (another one), RobotDog anyone? Seems to be a list for a Router OS by http://www.mikrotik.com.cn/. Another site has a post about dns cache poisoning/phishing and one of these IP's, this time affecting an ISP in Taiwan.

Anyone?