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.