Bug In DOS-Based Voting Machines Disrupts Belgian Election

jfruh (300774) writes "In 20 cantons in Belgium's Flanders region, voting machines are x86 PCs from the DOS era, with two serial ports, a parallel port, a paltry 1 megabyte of RAM and a 3.5-inch disk drive used to load the voting software from a bootable DOS disk. A software bug in those machines is slowing the release of the results from yesterday's election, in which voters chose members of the regional, national, and European parliaments. The remaining voting machines, which are Linux-based, are unaffected, as were voters in the French-speaking Wallonia region of the country, most of whom use paper ballots."

Comments

It's a software bug, hardware unrelated

[mechtech256]

A graphing calculator would probable have adequate power to handle taking votes. If the DOS machines are meeting the specifications required for Flanders elections, there's not much of a reason to upgrade them.

I guess I'm just not seeing the story here. Linux wouldn't stop a software bug either. I guess the only hassle here is that they might have to dig out the parallel cables to patch the machines.

Paltry

[wiredlogic]

The problem wasn't on the voting machines with the "paltry" amount of memory:

After the elections are over the results are loaded on a 3.5-inch floppy disk and shipped to the canton headquarters where the disks are fed into another computer that adds up the votes before sending the results to the ministry. It was there that the problem occurred, the spokesman said, adding that the votes that ended up on the disks were correct.

There is nothing wrong with a simple dedicated system that is based on proven hardware. Most of the computers in use today have even less than 1MiB at their disposal. It is a fallacy of thought that you have to have an extensive operating system with virtual memory and other elaborate support systems to accomplish a simple task.

Re:Paltry

[fgouget]

Do I have to provide links to all the election workers that find paper ballots in their trunk right after they know just how many votes they need? Cite LBJ?

Sure, one can make a paper based voting system that can be hacked. The easiest way is to require that all ballots be moved around to a central location before they are counted. That provides plenty enough of opportunities for fraud during transport. To maximize fraud-opportunities, cost and slowness you can even claim you cannot start counting the ballots until the next day so all the ballot boxes have time to arrive and so you don't have to pay the people you hired extra for night work.

Or you can pick volunteers among the voters to count the ballots as soon as the election closes, right in the polling station. With tables of four volunteers working together and checking each other's work (in addition to the usual party representatives), you get the results within 2 hours and have a really fraud-proof system. It also scales nicely with both the number of polling stations and the population, and needs only 1% to volunteer.

Re:Paltry

[fgouget]

This is the kind of project you could do in a weekend on a Raspberry Pi. Off-the-shelf , disposable hardware; demonstrably provable software.

A voter will never be allowed to verify that the software actually running on the voting computer is your 'demonstrably provable software' software. If he were allowed to do so, not only would it cause a huge backup in the line, but it would also require completely compromising the security of the system. Then that voter would also have to check that the hardware is really an unmodified Raspberry Pi board rather than one that was 'upgraded' by the NSA (or someone else).

Open-source (or provable software) and open-hardware change strictly nothing to the electronic voting opacity.

Paper trail

[ArcadeMan]

In Canada, we use paper voting and we usually know the results of national elections within 24 hours.

Why mess with electronic voting?

Re:Paper trail

[sribe]

Why mess with electronic voting?

SHINY! OOH OOH SHINY! That's why ;-)

Re:Paper trail

[cpghost]

24 hours is quite a long time actually. In Germany, we use paper voting too, and the (final) results are usually available within 2-3 hours, 4 hours at most.

Re:Paper trail

[Rumagent]

No good reason. Except perhaps that a perfectly implemented system (if such a thing is possible, so far none has been devised) would be faster.

Apart from that, the paper version is:

Cheap,
Reliable,
Repeatable
Extremely hard to rig on a large scale,
Well tested
Durable,

And most important of all: Easy to understand and audit by a layperson.

Many slashdot readers are well versed in CS and we do not trust these systems. How then can we expect the public to have any faith in these systems?

If the many CS guys out there really want to help, they should think out algorithms for sorting that are efficient, precise and can be done by humans - preferably with some error correction built in. It will not make anyone rich, but it may just keep a bit of faith in elections