We created a digital vote-counting monster and it ate us

\

ould I support a recount? No. One wrong count is enough for any election. A recount is totally useless if we don’t understand how the original count was

done in the first place.

We have created a monster in digitizing our vote counting and that monster ate us. We plunged into a computerized system of voting before we have obtained enough expertise in the technology.

Worse, not only do we generally not understand about computers—except on the level of touchscreen-clicking casual users—we don’t even listen to the people who DO.

For months, computer techies have been shouting themselves hoarse, “Check the source code! Check the source code!” but their voices fell on deaf ears.

What’s a “source code” anyway?

It is the list of instructions given to a computer to execute. It is written in human-readable language, meaning WORDS and NUMERICAL VALUES assigned to constants and variables, and FLOW PATTERNS controlling the sequence in which these instructions are carried out, repeated and terminated.

Together, these human-like commands comprise that computer’s operating software—before those instructions are crunched into machine language code written in 1’s and 0’s (the terms is “compiled”) and translated into micropulses of voltage which is all a machine understands.

In layman’s terms, the source code is the “script” that the computer follows in carrying out its tasks, such as counting and adding up votes.

Little can go wrong in the actual counting itself, because all that involves is accumulating impulses recorded by sensors, which can be mechanical or optical. Once the count value is stored in a “variable”--which is like a digital container in the program that holds a given number only as long as until the NEXT number comes in to replace it—this is where monkey business can happen.

Loading this “next number” is where the machine can be programmed to “lie.” What is the definition of “NEXT VALUE ”? Normally, the computer must be told that “NEXT VALUE” is “PREVIOUS VALUE PLUS ONE.” But the computer can also be told to divert to a carefully-designed “sub-routine” first.

This subroutine can be any set of decision branches that the program can go through. For instance, I can tell the computer to compare THREE values stored in THREE VARIABLES. The first variable (let’s call it “A”) holds the vote count for “CANDIDATE A”; The second variable (call it “B”) holds the vote count for “CANDIDATE B”; The third variable (call it “C”) can either be a fixed arbitrary value or a formula.

Then I can tell the computer to compare A and B. Let’s say I want to increment A to always remain in greater value than B. Then my instruction would be “If A is greater than B, go back to main routine.”

It means A is leading, no need to panic.

But “if B is greater than A, then replace A with B plus C.” This means if B draws level with A, or even overtakes A, then I would tell the computer NOT to touch the value of B (hence be sustained by a recount of B’s votes later) but to replace A with the value of B (which is higher) and add to that the value of C (which is the fixed “difference” I want to maintain between A and B).

Such a “subroutine” would ensure that at any point in the counting, both values of A and B will increase at different rates, but A will always be more than B by a factor of C.

You will never catch it in a rerun of the program, no matter how often you do it. The result will always be the same.

You can study the program code, observing how it behaves LINE BY LINE by running a “TRON” command—which stands for “TRACER ON.” (Also, it became the title of a sci-fi movie about a rogue computer code that acquired humanoid attributes and started wreaking havoc in the world’s computers. Google it.) The process is called "debugging." If you're lucky or eagle-eyed, or both, you will see abnormal behavior in the program in realtime enough to isolate the malicious code and cut it out.

However, in the time it takes a human to raise his eyebrow about one calculation, the doggone computer would have performed a billion calculations already.

So better yet, you can READ THE SOURCE CODE—the commands written in human language, grammar and syntax—and, as a mental exercise, follow the flow of the commands while tracking the simulated values of the program’s variables by writing them down on a piece of paper.

In layman’s terms, you would take a program that requires a computer mere nanoseconds to execute, and HUMANLY PERFORM its instructions at a glacial pace. This nothing you can do on election day, of course.

The source code can be read by many programmers who understand decision flow and execution logic. If malicious code has been written into it, you can ONLY see it in the source code. You cannot see it by looking at a computer chip under an electron microscope. Programs do not manifest in hardware (except as graphic reports on an output device, like your computer screen or ‘hardcopy’ printout.)

This is why computer pundits were demanding, vainly it turns out, to see the source code. But what did COMELEC do? They bragged that the source code has been secured in an impregnable vault at the Bangko Sentral ng Pilipinas, where it is safe from anybody’s access.

That is the OPPOSITE of how to secure a source code for a software documentation as imbued with public interest as a vote-counting program. You want that source program to be SAFE and SECURE?

EXPOSE IT TO THE ENTIRE COMPUTER COMMUNITY.

Let all programmers see it—not just the so-called “independent” or “third party” programmers—but EVERYBODY. Every person who has any knowledge of programming, which means every I.T. graduate or every post-modern Steve Jobs and Bil Gates, both dropouts from computer institutes who eventually created all of cyberspace as we know it, who are out there.

Next you want the source code (once you’ve determined it is “clean”) to be literally keyed into a computer in plain sight. Then make the computer “compile” the program into an “executable module” which is then “burned in” onto the Vote Counting Machine (VCM) standard density (SD) cards, or memory sticks. Those memory cards, numbering as many as the VCM’s that would use them, are the ones you must keep in the vault.

Why? To prevent them from getting lost, but NOT to discourage “tampering.” No, because once the source code has been compiled into a machine language executable module, IT CAN NO LONGER BE EDITED. In fact, it can no longer be read by any humans, even.

On the other hand, if the source code contains malicious code, it makes no difference even if you keep it in Fort Knox. A bad program will cause a good computer to produce bad output once you load and run that program--even if it spend the last six months sitting in a "high-security vault."

But if locking this "source code" in a vault is your main criteria of confidence, then you don't really understand how computers and computer programs work. Therefore, you lack the competence to run the program, in the first place, let alone to RE-RUN it in a recount later.

We always say in the programming community "garbage in, garbage out." If you do a recount using computers running a program with malicious code in it, you will just end up consolidating its erroneous output.

So what good would a recount do at this point? It's too late in the day to start your digital “due diligence” now. You will just end up shooting yourself in the foot.

It would be a totally different story if you ask me if I would support a REVOTING, using an entirely new set of vote-counting machines and only if we get to inspect the SOURCE CODE, witness its actual encoding into a master processor, have it compiled into an executable module ENCRYPTED and MASS-COPIED onto brand-new and newly-reformatted memory cards, BEFORE these machines and cards are sequestered in a vault in the runup to the actual balloting. Those are the terms--if it's not asking too much. Would COMELEC agree to something like that?

Yeah, right.*