Learn which bridges can't reach baidu
I hear from our friends at GIFC that when their bridges get blocked, they get blocked duplex. That is, people in China can't reach the bridge, but also the bridge can't reach China. So one trick they have for checking if bridge addresses need to be rotated is pinging a well-known site inside China.
Now, this reachability testing won't solve all our problems. In practice, we know from #1728 (moved) that sometimes the gfw blocks our bridges much more precisely by ip:port rather than by blackholing the IP address.
On the other hand, we know that at least in the Sept 2009 blocking event, they blocked some bridges by ip:port and others by blackholing them: http://archives.seul.org/tor/relays/Sep-2009/msg00003.html
So it would be worthwhile to teach bridges how to check if they've been blackholed, in case it turns out to be useful trick in the arsenal.
Step one is to come up with a proposal for how we're going to check. Should we just fetch the baidu frontpage at irregular times, and if we've failed too many tests lately but we otherwise seem to have a working network connection, add a line to our extra-info descriptor? What are the blocking-resistance implications of having all our bridges voluntarily touch baidu periodically?
Step 1.5 is to implement the proposal.
Step two is to run a few bridges ourselves, get them blackholed (perhaps by giving out their addresses in every single answer on bridgedb ;), and test to make sure the reporting behavior is working as expected.
Step three is to look for patterns in the extra-info descriptors that the bridge directories aggregate. Do the bridges that seem to have no traffic from China report that they can't reach Baidu? Corroborate by doing direct scans from inside China.
Step n, as a bonus, is to evaluate whether we want to get any more methodical about which domains we test. Maybe have a list of domains somewhere that bridges learn that we can update on the fly? We should save this question until we've at least finished step two.