Fazal Majid's low-intensity blog

WordPress has been getting a lot of bad press the last few days, as a worm is out in the wild exploiting a security vulnerability. This is leading to somewhat unfair comparisons with Windows, and thoughtful articles from John Gruber and Maciej Ceglowski.

To be sure, the ease of programming in PHP leads a great many people to contribute to projects, who may not have the experience or security awareness they should. This is not helped by poorly designed features in PHP that were enabled by default in previous versions, and cannot always be disabled outright due to legacy compatibility concerns, reminiscent of the persistent security woes due to the C standard library’s insecure old string processing facilities.

For many users, migrating away from WordPress may not be a practical option. My recommendations would be:

• Reduce your exposure by exporting a static HTML version of your site, as suggested by Maciej. This is really only simple if you use a non-default permalink structure that does not use question mark characters in URLs, like that used by the SEO plugins. Otherwise you would need quite a bit of mod_rewrite jiggery-pokery to get it to work. In any case, this will also disable quite a bit of functionality on your site, such as comments.
• If you are an Apache user, install modsecurity, a truly outstanding Apache module that acts as a firewall of sorts and will inspect requests for suspicious behavior like SQL injection attempts and malformed requests. Configuring modsecurity is not for the faint of heart, but there are some papers online like this one by Daniel Cuthbert (PDF) that walk you through this. This is probably the single most significant thing you can do to make your WordPress blog safer.
• Practice security in depth — keep regular backups of both your wordpress directory and database, so you can recover in case of attack, and if possible run WordPress in an isolated account with minimal privileges.

I upgraded my broadband connection yesterday from a puny 3-6Mbps/384-768K DSL connection to 20Mbps symmetrical Metro Ethernet service from an outfit called WebPass. My current ISP, Raw Bandwidth, has excellent service with no restrictions on hosting servers or traffic shaping shenanigans unlike the likes of Comcast, but they are still hobbled by the AT&T last-mile connection.

WebPass finesses around the incumbent monopoly by using newer buildings’ data-grade wiring plant to bring 100MBps Ethernet connections right into your home (all they had to do was change a wall plate and patch some cables in the closet) and use microwave links to backhaul traffic to their data center. They claim to use a mesh network for backhaul, but I think this just means a standard network of microwave links where some sites have to hop multiple microwave links to get to the transit connection, rather than a purely centralized hub and spoke model. In my case their offices are a mere two blocks away. This would allow me the pleasure of ditching the scumbags at AT&T altogether (were it not for the fact my building requires an entirely unnecessary landline for its security system).

AT&T is probably the worst telco in the US now, and is notorious for starving its infrastructure of investment to maximize short-term profits, unlike Verizon, who is investing heavily in its FiOS optical network. Unfortunately San Francisco is in AT&T territory and will not get true optical networks anytime soon. Municipalities can usually reassign the cable franchise every so many years, but there is no such provision for involuntary transfer of telcos that I know of.

The new service is $45 a month with no installation fee, vs. $70 a month for Raw Bandwidth, but it does not include a static IP address (they do offer it as part of their prohibitively expensive metered business service). Configuring my home router (a Cisco 877) to use both connections was incredibly painful, but I will run the two ISPs side by side for the next few months. If WebPass proves as reliable as Raw bandiwdth, I may just have to find a work-around for the static IP issue, or just rely on DHCP lease pinning.

If you live in San Francisco, or are moving there, definitely have a look at the buildings they have covered. The service is a glimpse of what people not in broadband backwater USA get.

I have an eight-core Nehalem Mac Pro. Most of these cores sit idle most of the time due to poorly written software that is not optimized for the post-Moore multicore world.

I am beginning to wonder if Intel’s transistor budget wouldn’t be better allocated to more SRAM cache instead of more cores. One SRAM bit uses up 4 transistors, the Xeon 5500 have 751 million transistors, of which 8Mx8x4 or 256 million are for the 8MB L3 cache. If the chip were brought down from quad-core to dual-core, that would allow doubling the cache. Many programs could run entirely from cache, including interpreters.

Amano, based in Salt Lake City, makes the best chocolate in the USA, their Ocumare bar, using only Venezuelan criollo cacao (the best in the world).

The founder, Art Pollard (photo taken 2 years ago at Fog City News in San Francisco) claims he gets superior results from roasting at high altitude in Salt Lake City, but I think superior conching technique is primarily to credit.
They recently introduced milk chocolate bars, the Jembrana and Ocumare. Despite its lovely green wrapper, the Jembrana leaves to be desired — it just doesn’t taste chocolatey enough. The Ocumare Milk comes through with wonderful texture, a rich, complex cocoa flavor while avoiding over-sweetness, the downfall of too many milk chocolates, specially in the USA.
It also avoids the harshness of some bars made by chocolatiers new to the world of milk chocolate — the abysmal Scharffen-Berger 68% cocoa “dark milk” bar comes to mind.

Mozilla Weave is a project of the Mozilla Labs to build synchronization of bookmarks, tabs, passwords and so on between multiple instances of the Firefox browser. It used to be a private beta, but with the release of version 0.4 recently, it has been opened up to the general public.

Where version 0.2 was pretty rough, 0.4 actually works quite well, even if it is not yet feature complete. Bookmarks and passwords are handled just fine. Furthermore, you can set up your own server, all that is needed is PHP. Previous versions required WebDAV support, and the WebDAV module in nginx is not functional enough for Weave (or anything else, for that matter).

The first synchronization is painfully slow, but once it is done, later synchronizations are essentially instant. When combined with the Awesome bar’s tagging components, it has completely supplanted Del.icio.us for my bookmarking needs (I never liked the rewritten user interface).

Amusingly, I came across these cufflinks at Thomas Pink in San Francisco last Friday — they are the mirror image of the Weave logo.

Below are the relevant sections of my nginx config.

php.ini

magic_quotes_gpc = Off
session.auto_start = 0
file_uploads = On
error_reporting = E_ALL & ~E_NOTICE
allow_url_include = Off
allow_url_fopen = Off
session.use_only_cookies = 1
session.cookie_httponly = 1
expose_php = Off
display_errors = Off
register_globals = Off
disable_functions = phpinfo
error_log = /home/majid/web/logs/php_error_log

nginx.conf

root /home/majid/web/html;
location ~ .php$ {
  auth_basic		"gondwana";
  auth_basic_user_file	/home/majid/web/conf/htpasswd;
  fastcgi_pass		127.0.0.1:8888;
  fastcgi_index		index.php;
  fastcgi_param		SCRIPT_FILENAME  /home/majid/web/html$fastcgi_script_name;
  include		/home/majid/web/conf/fastcgi.conf;
}
# Mozilla Weave
rewrite ^/weave/admin$	/weave/admin.php;
location /0.3/api {
  return		404;
}
location /0.3/user {
  fastcgi_pass		127.0.0.1:8888;
  fastcgi_index		index.php;
  include		/home/majid/web/conf/fastcgi.conf;
  fastcgi_param		SCRIPT_FILENAME	/home/majid/web/html/weave/index.php;
  fastcgi_param		SCRIPT_NAME	/home/majid/web/html/weave/index.php;
  if ( $request_uri ~ "/0.3/user/([^?]*)" ) {
    set $path_info	/$1;
  }
  fastcgi_param		PATH_INFO	$path_info;
}

fastcgi.conf

fastcgi_param  GATEWAY_INTERFACE  CGI/1.1;
fastcgi_param  SERVER_SOFTWARE    nginx;

fastcgi_param  QUERY_STRING       $query_string;
fastcgi_param  REQUEST_METHOD     $request_method;
fastcgi_param  CONTENT_TYPE       $content_type;
fastcgi_param  CONTENT_LENGTH     $content_length;

fastcgi_param  SCRIPT_NAME        $fastcgi_script_name;
fastcgi_param  REQUEST_URI        $request_uri;
fastcgi_param  DOCUMENT_URI       $document_uri;
fastcgi_param  DOCUMENT_ROOT      $document_root;
fastcgi_param  SERVER_PROTOCOL    $server_protocol;

fastcgi_param  REMOTE_ADDR        $remote_addr;
fastcgi_param  REMOTE_PORT        $remote_port;
fastcgi_param  SERVER_ADDR        $server_addr;
fastcgi_param  SERVER_PORT        $server_port;
fastcgi_param  SERVER_NAME        $server_name;