This is a post I wrote long ago on another site. In this case, it’s from Rusty Foster’s Kuro5hin.Org which has long since disappeared from the Internet.

I ran in the first ICANN board of directors election on a platform that ICANN should immediately dissolve itself. If I remember correctly, I came third.

An old post of mine from Kuro5hin.Org, dated “Sun Oct 1st, 2000 at 11:05:43 PM EST”.

ICANN has sent out their announcement that the actual voting system for the Board of Directors election is now available. Their elections, it seems, will be run by election.com, a startup .com aiming to build themselves into a position of control over “e-voting” worldwide. Let’s look at some of the implications of this, shall we?

Firstly, I find it troubling that ICANN, who claimed that the registration and nomination phases of this election were as broken as they were because they had insufficient funding (through there are definitely questions about the validity of this claim), has obviously forked over the cash for an outside company. Not only that, but election.com does not (as far as I can tell) publish even an estimate of election cost on their site.

Next, the election.com Privacy Policy is, while fairly progressive for the .com market, still fairly disturbing. It’s not even linked off their front page, for one thing; the only page from which I could find it referenced was their “Order an Election” link in the nav-bar. Nothing like going out of their way to make sure you see it, eh?

The privacy policy has a lot of flexibility for how they can use information they gather, and does not prohibit them from collected any information they choose (except in the case of people under 17 years). To give credit, however, though they do allow themselves to change the policy without notice, they do specifically require themselves to use any data collected under the terms of whatever version of the policy was posted when the data was collected. This is sort of silly, of course, since some court cases have drifted towards saying that this is an obvious implication of a posted policy, but it does make it seem that they’re at least aware of the issue.

Next, there’s no evidence or mention of a neutral election monitor’s involvement, as ICANN has promised repeatedly that there would be. I personally consider it likely that ICANN intends to claim election.com as their monitor, though I’m sure we call all see how absurd a claim that would be. As the contractor in the election, they obviously cannot be considered to be a neutral party.

Most importantly, however, is the question of election security.  Pointing NetCraft at the ICANN election server reveals that the ICANN election is running on a Microsoft IIS server. I’m not going to belabor the Microsoft-bashing here, but IIS is clearly the least secure SSL web server available. To give an example, a simple search on Rootshell for IIS exploits gives 61 results (totalling locally hosted and remote results).  The same search for Apache gives 34 total and for WebStar returns 0.

Obviously, these numbers are a mere gloss over the potential security issues, but they do point in the right direction. IIS is well known to be the least secure server available and Apache to be the most secure common server. Even the U.S. Army has recognized that Macintosh servers are the most secure available, as most security experts are well aware.

So, ICANN has at least these four serious issues in their construction of the election, and I’m sure that many more will come to light in the following two weeks, just as they have done in the previous phases of their process. With that background, I’d like to ask you to consider the following questions about this:

  • How important are these issues and are there others I’ve missed which would overshadow them? I, obviously, think these are the most important to show up so far, but I’m certainly open to new suggestions.
  • Without a monitor, can ICANN’s results stand up to a legal challenge? They’re bound by their Bylaws and procedures to hold these elections; demonstrable fraud would likely force a rerun, but without a monitor, there’s no way to demonstrate it. The likelihood of fraud is much more difficult to demonstrate.
  • How legitimate can the election be is their server gets cracked? My personal opinion, though there are no ICANN procedures for it, is that any irregularity on the election servers would require a recasting of all ballots. ICANN, naturally, doesn’t even have a provision for recount demands, much less for questioning the entire polling process.
  • What data about you will election.com be collecting and how will they be able to use it? How would a cracker be able to use it? Consider that they have your number, password and PIN; a cracker could easily extract this information (once the server is compromised). With that information compromised, it would be necessary to rerun the entire registration process before holding the final election over, since the cracker could vote as every “member” whose authentication info they’ve intercepted.

As a closing note, for those of you who are following the elections, there will be two events involving candidates in North America taking place this week. Harvard and MIT will be hosting debates among the candidates on Monday and Wednesday and the Electronic Frontier Foundation will be hosting a panel discussion between the three non-Board nominated candidates on Thursday.

arkady

Leave a Reply