Web

My new company’s website uses SSL. I ordered an “extended validation” certificate from GoDaddy, instead of my usual CA, RapidSSL/GeoTrust, because GoDaddy’s EV certificates were cheap. EV certificates are security theater more than anything else, I probably should not have bothered.

Immediately after switching from my earlier “snake oil” self-signed test certificate to the production certificate, I saw SSL errors on Google Chrome for Mac and Safari for Mac, i.e. the two browsers that use OS X’s built-in crypto and certificate store. I suppose I should have tested the certificate on another server before going live, but I trusted GoDaddy (they are my DNS registrars, and competent, if garish).

Big mistake.

I called their tech support hotline, which is incredibly grating because of the verbose phone tree that keeps trying to push add-ons (I guess it is consistent with the monstrosity that is their home page).

After a while, I got a first-level tech. He asked whether I saw the certificate error on Google Chrome for Windows. At that point, I was irate enough to use a four-letter word. Our customers are Android mobile app developers. A significant chunk of them use Macs, and almost none (less than 5%) use IE, so know-nothing “All the world is IE” demographics are not exactly applicable.

After about half an hour of getting the run-around and escalating to level 2, with my business partner Michael getting progressively more anxious in the background, the level 1 CSR tells me the level 2 one can’t reproduce the problem (I reproduced it on three different Macs in two different locations). I gave them an ultimatum: fix it within 10 minutes or I would switch. At this point, the L1 CSR told me he had exhausted all his options, but I could call their “RA” department, and offered to switch me. Inevitably, the call transfer failed.

I dialed their SSL number, and in parallel started the certificate application process on RapidSSL. They offered a free competitive upgrade, I tried it, and within 3 minutes I had my fresh new, and functional certificate, valid for 3 years, all for free and in less time than it takes to listen to GoDaddy’s obnoxious phone tree (all about “we pride ourselves in customer service” and other Orwellian corporate babble).

I then called GoDaddy’s billing department to get a refund. Surprisingly, the process was very fast and smooth. I guess it is well-trod.

The moral of the story: GoDaddy—bad. RapidSSL—good.

Update (2012-08-26)

I switched my DNS business from GoDaddy to Gandi.net in December 2011 after Bob Parsons’ despicable elephant-hunting stunt.

In my misspent youth I spent about a year as a visiting scholar researching wavelets under Raphy Coifman’s supervision at Yale’s small but excellent Mathematics Department. Professor Coifman was head of a department that also featured Benoît Mandelbrot (of fractals fame), the late Walter Feit (as in the Feit-Thompson theorem), and Fields medalist Gregory Margulis. He was kind enough to credit me on a published paper, even though he did all the work, reverse delegation in action. That paper had modest success and was cited, so I can claim (not with a straight face) to be a published mathematician.

While perusing my blog’s web analytics referrer report, I was surprised to find out my article on the Nikon D70’s not-so-raw RAW format is actually cited in a serious scientific paper on human vision. We keep hearing about students getting flunking grades for citing Wikipedia, are blogs really considered more authoritative?

The citation uses the old URL for the blog entry, </mylos/weblog/2004/05/02-1.html>. When I migrated to WordPress at the end of 2009, I took great pains to provide redirects whenever possible and avoid broken links. Many bloggers don’t have the time or expertise to do this, and simply leave dangling permalinks around. If quoting blogs is to become standard practice, authors should probably provide some sort of fallback mechanism like linking to Archive.org, but dead-tree journals do not have this capability. Absent that, linkrot may spread to an entire new category of documents, scientific papers.

Update (2011-07-18):

Here’s another paper (PDF) referencing the same article. What’s next, CiteSeer?

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.

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;

I updated my wife’s home page to use embedded fonts (in this case the Fonthead GoodDog typeface for headings) with the @font-face CSS primitive. With the introduction of Firefox 3.5, all the major browsers now support embedded typography.

As usual, Microsoft had to do its proprietary thing in Internet Exploder and devised a crackpot font format called EOT (Embedded OpenType), ostensibly at font foundries’ request, with weak DRM-like metadata that allows the font supplier to restrict which sites the font can be used on. Microsoft has an incredibly convoluted tool called WEFT (Web Embedded Font Tool) to do this, but I used the open-source and incredibly easy to use ttf2eot tool instead. The only hitch in this case was that this tool takes a TrueType TTF font as input, and GoodDog is a (PostScript-ish) OpenType OTF instead. Fortunately, TypeTool can do the conversion.

We finally have semi-decent typography on the web without having to embed images (bad for page load times or accessibility) or the even worse sIFR hacks using the noxious Adobe Flash. The only question remains whether type foundries will follow. Fonthead has enlightened licensing policies for GoodDog (free for up to 5 sites, no insistence on DRM). Typeface design is a painstaking craft and designers certainly deserve what they charge for their fonts, but I hope the typographic industry does not follow the RIAA in its self-destructive crusade against its own customers.

Update (2011-03-03):

One option for hassle-free embedded font licensing is TypeKit. It does require JavaScript in the browser to work, unlike a pure CSS solution like the one I used, but the convenience can’t be beat. We use it on Apsalar’s public website.