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

They almost made it, too

[Anonymous Coward]

They were just about to upgrade to Windows XP for the next election.

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.

Re:It's a software bug, hardware unrelated

[Hsien-Ko]

I guess their next 'logical' step is to upgrade to Windows XP


and then use the same software in the DOSBox emulator

and then complain on the DOSBox forum that it doesn't work, among the sea of other overentitled 'IT pros' that demand a gaming emulator to fit critical application usage
*facepalm*

Re:It's a software bug, hardware unrelated

[TheGratefulNet]

If the DOS machines are meeting the specifications required for Flanders elections, there's not much of a reason to upgrade them.

do I have to say it?

alright then:

"stupid flanders!"

Re:It's a software bug, hardware unrelated

[sillybilly]

Your sig says "It is now safe to switch off your computer."

With DOS, in the old days, you could just cut the power to the computer without any warning, and it would be fine, so shutdown time was 0 seconds, also boot time was super fast, like 1-10 seconds, unless you had a long autoexec.bat and config sys. And that was on 486 CPU's, pre-Pentium's.

DOS came with no bullshit, you can't really blame DOS for the programming error in the voting software, DOS is a reliable, secure(has no network layer unless you add one, and you can add non-tcp-ip stuff), real time, direct hardware access, and it is reliable and secure because it's so small, it fits on a floppy with plenty of room to spare unlike these 5 GB bloatloads of crap with daily patches they are releasing at microshaft these days. I don't remember a single service pack for DOS. Well, there were incremental versions, like 6.0, 6.2, 6.21, 6.22. By the way windows 95 comes with DOS 7,0, a very good version, and you can find most of the missing stuff in the oldmsdos folder on the win95 cdrom. Plus you get a neat version of windows for free,with a very small registry, and relatively low bs, but it doesn't run much modern stuff either, but it runs VB6 classic, and Office 97 just fine. They have yet to make an office version better than Office 97sp2 (service packs mostly fix vba crashes, but you can almost live with those crashes/hangs), Office 2000 is on par without needing bugfix service packs, while office 2002 is already too bloated(plus may require the activation bullshit), shit started going downhill by then, really accelerating by 2003, and pretty much turning into annoying piece of crap by office 2007, plus activation. Activation means you can't run it 50 years from now if Microsoft is out of business by then, or they simply refuse to activate it, and instead tell you to upgrade, which may happen even these days, to all versions starting with office xp=office 2002. Same goes for the OS, if you're packing up reserves for the future, and archiving stuff in case you have to go back to it, go for win95 full version that includes dos 7, and windows 2000, the very last windows without activation, also office 97 with sp1+sp2, and VB6 sp5 (don't use sp6, it introduces bugs on purpose, to usher along for upgrading.) Also Firebase database might come in handy, or ADO with SQL Server 7 or 2000, but SQL Server is expensive, and on a network it requires NT/2k server with client access licenses and such, so it's better to run off a common file on a network drive, or off of PostgreSQL 6-8 on Linux 2.4/2.6. The DOA database with office 97 access kinda sucks, but the access 2000 one is ADO, and the two are not compatible, ADO being much simpler than DOA, but it started to get bloated a bit, not enough to not make it better than DOA. Also from what I read delphi 5 and 7 are golden, but there is Lazarus now, I don't know how that would work on win95. Absolutely nobody is selling delphi 5 or 7, or it's like 300 bux. Delphi was a secret of coding houses cutting development time by like 5x compared to all the alternatives. I never programmed in it, but I've seen a lot of quality software by very smart people written in it, so it must be something really good if they chose it. VB6/VBA still kicks ass for basic stuff, but it's not very fast, and for heavy duty large projects, in development speed and code execution speed and codesize kept in balance, nothing beats delphi 5 or 7. The later dotnet versions of delphi are absolute pure raw crap, from what I read, just like anything touched by dotnet.

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.

Re:Paltry

[bruce_the_loon]

South Africa just did it that way and it works well. First you count the total ballots, still folded, then you count the votes and that way nobody can add other ballots in during the vote tally to make up numbers. No cellphones etc allowed in the hands of the counters, elections officials or party observers during the count.

Got one addition to the process that we don't do. No results should be released from a polling station until every single station has finished counting and certified within the station. Forget this running TV tally and all that crap, if the numbers in each station remain secret until all stations are ready to report, then you can reduce the risk of "finding" additional votes in the trunk of a car.

Obligatory

[ArcadeMan]

Stupid Flanders.

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

Incorrect story

[Anonymous Coward]

While it is true that most of Wallonia votes with paper, all the places using e-vote in Wallonia and in Brussel are "affected" by the bug as well.

"affected" with marks, as the actual problem happened with the software in charge of centralizing all the votes coming from these places. So the e-vote process had no actual problem, it's the counting afterwards that crashed.

source: I live in Belgium, it's been all over the news here. I'll also add that I heard exactly zero reports about the same problem occuring in Flanders, but I might have overlooked some reports.

disclaimer: I strongly oppose e-vote.

a number af factual errors in the original article

[joris.w]

for a more accurate account of the facts, you could read http://datanews.knack.be/ict/n... (in dutch)
the vote counting problem in Flanders was related to manual procedures in the Ghent area
the DOS based e-voting system is used in Brussels, not Flanders
as stated already in other comments: the DOS based systems did not fail, it was the central vote collecting system that failed
lesson learned: If you want accurate reports, go to the source and don't rely on second hand reports

Dos, Memory?

[Tablizer]

a paltry 1 megabyte of RAM...

640 votes ought to be enough for anyone. -B. Gates