Board vote code

The board vote code in MediaWiki uses public key crypto to enable an audit trail. No other wiki code has this feature yet. An exchange between the Lowest Troll of Consumerium and the chief developer vigilante of Wikipedia included the following:

User:Juxo is "very critical of submitting everything to computers because that gives technocrats too much (secret) power, but in this case there is no prob since the private key could be on a disk in a safe

Tim Starling responds "yes, I wanted to make it so that it was hard for a developer to rig since a developer was one of the candidates and he came very close to winning, too"

This is probably a reference to Erik Moeller who, along with Starling, does most of the developer vigilantiism and distributing vandalbot code to those willing to do denial of service attack against other GFDL corpus access providers. By making it "very hard for a developer to rig" it becomes possible only for these two individuals, Moeller and Starling, to rig the votes. See Disinfopedia entries on Diebold corporation for more on the various issues with vote-rigging and why electronic voting is usually bad.

According to Tim Starling, "it's also made so that's it's fairly difficult for a developer to work out who is voting for whom; they'd have to constantly run a monitoring program on the server, which is detectable; instead of just get in, grab the results and cover their tracks". Use of terms like fairly difficult and detectable and cover their tracks implies of course that Starling himself can actually do these things, and ensure they are covered up. In the future this might be of benefit to his friend and ally Erik Moeller who is a strong opponent of English Wikipedia User Anthere, who won the so-called "election" this time - probably just to make everything look honest?

Individual records in plain text have three lines: two for the two different positions, and one for "salt" (though the GPG algorithm adds its own salt). "The plain text records don't contain the usernames, it's not trivial for even the private key holder to determine who voted for who assuming the private key holder doesn't have access to the full DB," which of course some do. Apparently the SQL DB hides the order in which votes were cast, which is why to track votes one would need to monitor every transaction as it occurred.

The web interface gives two different data displays :

the "list", where names and timestamps are displayed and where an election administrator may use this list to strike out invalid votes, e.g. of trolls who oppose the sysop power structure
the "dump", which lists the encrypted records in chronological order

Starling admits that "there's a few ways an election administrator could match up dump entries with list entries" such as to match records in "dump" with timestamps", and muses about shuffling them so that only the most expert of the vote riggers could do this trace very reliably to identify political enemies for future harassment by the echo chambers.

"An election administrator with the private key could find out which entry belongs to which person by striking it out temporarily, and seeing which dump entry disappears" according to Starling, "so the way to get around that vulnerability is to make the private key holder a non-administrator" but given the power of the sysop power structure that person can be made to comply with more or less any demand to assert or impose the Cabal point of view.

Like all e-voting mechanisms, this one is certainly open to rigging and spying at least by its own developers. There is probably no way around that.

LOL!!! That's the funniest thing I've read in ages. You think I'm a friend and ally of Erik, and I wanted to help him win the election against Anthere??? I've made no secret of my dislike for Erik. He's arrogant and overbearing. He's done a few things to piss me off in the past and I'm still bearing a grudge. I voted for everyone except him on the contributing ballot. By contrast I have a great deal of respect for Anthere.

I had two personal reasons for making the voting system hard for developers to rig: firstly out of distrust for Erik, and secondly because I was entertaining visions of being a candidate myself. It takes a lot of care to design a voting system such that nobody could reasonably claim that even its designer could rig it.

This is made possible by displaying the encrypted election records. When someone votes, their election record both in plain text and in encrypted form is displayed to them. They may then check to make sure it appears on the dump. If it spontaenously disappears, then they can raise the alarm bells. A developer could rig it so that a different dump is displayed to the general public than to the private key holder, but the private key holder could check for this by requesting copies of the dump downloaded by other people.

Any paranoid member of the general community can check for disappearing vote records by regularly downloading the entire dump and comparing new dumps and old dumps side by side. Voting records will indeed disappear from the dump due to the election administrator striking out invalid votes, or when someone votes twice. But if such removals are challenged, they can be checked for legitimacy by a third party examining the log.

Secrecy, that is preventing anyone from discovering who voted for who, is also very important. My original idea was to preserve secrecy except from the private key holder. I later realised that simply leaving the username off the encrypted records would discourage casual snooping by the private key holder. It also makes it harder for a developer to breach secrecy by reading the temporary files input to GPG. I made no effort to prevent a determined private key holder from working out who voted for who, although this may be possible in principle.

A developer may breach secrecy in several ways, such as installing a packet sniffer, or modifying the voting code such that unencrypted votes are logged. However these methods are detectable, and difficult enough so that casual snooping is impossible. Dectability adds an element of risk for a developer wanting to breach secrecy. Note that for breaches of secrecy to be detected, there must be a vigilant non-corrupt person with root access to the servers. Wikipedia has a diverse group of developers with root access. Others wishing to use a similar voting system may not be so lucky. In such cases, it may be better to use an external company to provide the web hosting, and to allow only a trusted neutral person access to that machine, or to allow a diverse group of people access, for oversight.

-- Tim Starling 10:44, 27 Jun 2004 (EEST)