Yesterday, at CCW 2011, the IEEE Annual Computer Communications Workshop, I surveyed Chinese censorship of text chat in instant messaging (IM) programs. We found that every IM program that we analyzed written by a China-based company performed some kind of keyword censorship of text chat. One question we wanted to answer was whether the keyword lists used to trigger censorship were based on some kind of "master" list provided by the Chinese government or whether each company was deriving their list independently.

Of the Chinese IM programs analyzed, we found that only TOM-Skype and Sina UC perform censorship "client-side." What we mean by this is that only these two IM services perform the censorship in the program itself, not on a remote server, not over the network. When a program performs keyword censorship client-side, this makes it possible to acquire an exhaustive list of keywords censored by reverse engineering the IM program.

Upon reverse engineering both IM programs, we found that TOM-Skype downloads 515 unique keywords and Sina UC downloads 997 unique keywords. Overall, 1446 keywords are seen in only TOM-Skype xor Sina UC and only 33 keywords are common to both. This leads us to conjecture that any master keyword list required by the Chinese government must be either very short or nonexistent. We conjecture that, although the Chinese government exerts pressure on IM companies to perform censorship, it leaves the implementation to each IM company itself. For more details, here are my slides, and here are the TOM-Skype and Sina UC data supplements.

Yesterday, at FOCI 2011, the USENIX workshop on Free and Open Communications on the Internet, I talked about our work on analyzing TOM-Skype censorship and surveillance. We were able to discover the exhaustive list of keywords that trigger censorship and surveillance across different versions of TOM-Skype via reverse-engineering the lists' encryption. Moreover, we were able to decrypt the surveillance messages sent to TOM's servers. Here are our paper, slides, and supplementary data. We had questions related to whether we were tracking changes in the lists and, if so, what kind of changes we were seeing.

We are tracking changes, and we talk about some of the early changes we saw in the paper. As we showed in the paper, TOM-Skype 5.1, the most recent version, introduced a second keyword list used to trigger surveillance only, whereas before, keywords triggered both censorship + surveillance. In the paper, we also observed some keywords beginning to move from the censorship + surveillance list to only the surveillance-only list. Since the paper, we've seen this trend continue to the extent that all but one word remains censored, most of the keywords now used to only trigger surveillance only. It seems as though China or TOM is becoming increasingly interested in taking a surveillance-only approach to Internet censorship. You can find daily decrypted downloads of the lists here.

If you've flashed to the latest BIOS and don't have an option to enable VT-x on your Inspiron 1545 laptop, it could be because your CPU doesn't support it. I would have thought that all recent Intel CPU's would have VT-x, but I suspect that Intel intentionally cripples some CPU's to create market stratification. I had a CPU without VT-x, and googling around, I found a lot of comments by people in my shoes with no VT-x option in their BIOS, but I didn't find any affirmations that upgrading to a CPU with VT-x would enable the option. I recently took a plunge and replaced my CPU with a Core 2 Duo P8400. Sure enough, after the upgrade, the VT-x option appeared in my BIOS. So the takeaway message is that if you own an Inspiron 1545 and want VT-x support badly enough, try flashing your BIOS to the latest version and then upgrading to a P8400. Disclaimer: your mileage may vary. Also, I learned that market stratification is an effective way for corporations to make money off of me.

You can edit /etc/hosts to have DNS queries resolve to IP addresses of your choosing. But what if we want to reroute IP addresses to other IP addresses? This is possible by manually creating static IP routes and by creating a TUN/TAP interface on the server to which we want to reroute the IP address. We will assume that this server is running a Debian variant of Linux but make no assumptions about the operating system of the machine on which we want to reroute the IP address.

If you already have existing MD devices, then there is nothing too tricky about mounting MD devices from an Ubuntu Live CD, but I'd like to have the instructions available for quick reference, so I'm posting my steps here.

Update: As of Ubuntu 11.04, Alsa + PulseAudio is working fine on my hardware, so I won't be maintaining this guide, but you can find support for 11.04 in the comments below.

PulseAudio is a controversial addition to Ubuntu. PulseAudio is a userspace sound daemon that brings many benefits to users, but it is also problematic for others as well. For instance, many experience audio latency issues and stuttering with it. I've opted to disable it in Ubuntu. The longer I've been around, the more I've discovered that there really is no truly elegant way of disabling PulseAudio in Ubuntu, but I hope that this guide is one of the more elegant.

By the time you've finished this guide, you'll have disabled the PulseAudio server and made gstreamer unaware of PulseAudio in Ubuntu 10.04 or 10.10. This is sufficient for almost all applications—certainly everything that I've ever used—but some may have other ways of detecting PulseAudio that might require additional steps to disable that are not in this guide.

Many Linux users experience woes when attempting to get widescreen or otherwise untraditional screen resolutions to work. The problem is that many video BIOS's do not include these untraditional resolutions in their VBE mode tables. There have been a number of ways to mitigate this, with varying pros and cons. For example, when given a resolution, a tool called 915resolution can patch the mode tables in the video BIOS's shadow in RAM to include that resolution. But this must be done on every boot, and other programs using VBE cannot use the desired resolutions until after 915resolution is run. X drivers have begun including 915resolution functionality automatically, but this still requires X to be run. So this would not be helpful for enabling, for example, a widescreen virtual console resolution at bootup.

I decided to solve this issue more permanently. Surely if we can patch the shadow of the BIOS in RAM, we can patch the BIOS in ROM!