Diebold is trying to use the copyright laws to stifle discussion of whether its proprietary (read: secret and unaccountable) vote-counting software, which due to the lack of paper ballots provides no audit trail whatever, can be used — perhaps even has been used — to steal elections. The Electronic Frontier Foundation is resisting.
Update More from Tom Runnacles, who says that he wouldn’t use one of the key software elements in the Diebold system to manage a piggy bank.
Guess which side I’m on?
Of course, by trying to prevent the posting of the memos, Diebold in effect concedes that they are genuine.
The threat here is impossible to overstate. If the party currently in power can give the contract to count the votes to its friends, and if the count can be set up in a way such that cheating is easy and recounting impossible, then the party in power can stay in power forever.
Update Tom Runnacles at Crooked Timber, who (unlike me) seems to know a RDBMS from a hole in the ground, says he wouldn’t trust Access, a seemingly a key piece of the Diebold system, to run a piggy bank.
And here’s the Scoop item with some of the incriminating memos. Diebold’s technical folks tell one another (1) The existing system can be cracked, and its audit log modified, without a password; (2) That could be fixed by using a password; (3) Such a step should be taken if the customers want it; but (4) It won’t matter because there are better and easier ways to crack the system.
Right now you can open GEMS’ .mdb file with MS-Access, and alter its contents. That includes the audit log. This isn’t anything new. In VTS, you can open the database with progress and do the same. The same would go for anyone else’s system using whatever database they are using. Hard drives are read-write entities. You can change their contents.
Now, where the perception comes in is that its right now very *easy* to change the contents. Double click the .mdb file. Even technical wizards at Metamor (or Ciber, or whatever) can figure that one out.
It is possible to put a secret password on the .mdb file to prevent Metamor from opening it with Access. I’ve threatened to put a password on the .mdb before when dealers/customers/support have done stupid things with the GEMS database structure using Access. Being able to end-run the database has admittedly got people out of a bind though. Jane (I think it was Jane) did some fancy footwork on the .mdb file in Gaston recently. I know our dealers do it. King County is famous for it. That’s why we’ve never put a password on the file before.
Note however that even if we put a password on the file, it doesn’t really prove much. Someone has to know the password, else how would GEMS open it. So this technically brings us back to square one: the audit log is modifiable by that person at least (read, me). Back to perception though, if you don’t bring this up you might skate through Metamor.
There might be some clever crypto techniques to make it even harder to change the log (for me, they guy with the password that is). We’re talking big changes here though, and at the moment largely theoretical ones. I’d doubt that any of our competitors are that clever.
By the way, all of this is why Texas gets its sh*t in a knot over the log printer. Log printers are not read-write, so you don’t have the problem. Of course if I were Texas I would be more worried about modifications to our electronic ballots than to our electron logs, but that is another story I guess.
Bottom line on Metamor is to find out what it is going to take to make them happy. You can try the old standard of the NT password gains access to the operating system, and that after that point all bets are off. You have to trust the person with the NT password at least. This is all about Florida, and we have had VTS certified in Florida under the status quo for nearly ten years.