
No Secret Software! - naish
http://www.tbray.org/ongoing/When/200x/2008/07/27/No-Secret-Software
======
demallien
Am I alone in having serious doubts of the ability to have an open source
implementation of a voting machine?

The problem is that to have any benefit from having an open source solution,
_all_ of the code in the system needs to be open source, including all of the
drivers etc. As drivers need to be adapted to the specific hardware that they
run on, it is normally only the manufacturer of the equipment that can write
them. Think video drivers in Linux, as an example. Hardware manufacturers
probably see little commercial advantage in providing their source code, and
even if they do, there is no guarantee that what they give out as source code
is really what they have loaded into the voting machine.

~~~
rcoder
It's not about them seeing the "commercial advantage" in free market terms;
it's about mandating a particular approach (in this case, open hardware and
software from top to bottom) because it's the only way to insure that the
basic infrastructure used in elections _works_. This is not a case where the
whims of the market should decide the approach taken.

If no one gets rich on the design and implementation of electronic voting
systems, that's _fine_. I'd rather see it run by well-intentioned, poorly-paid
academics within a strict peer-review model than by unknown private entities.

------
berryg
In The Netherlands a group has succesfully fought against the use of voting
machines with secret software. For now the use of voting machines is not
allowed anymore and the Dutch people have to vote using pen and paper. More
info: <http://www.wijvertrouwenstemcomputersniet.nl/English>.

"On May 16, 2008 the Dutch government decided that elections in the
Netherlands will be held using paper ballots and red pencil only. A proposal
to develop a new generation of voting computers was rejected."

~~~
nailer
I'm not averse to voting machines provied:

* The code is publicly available

* The code is publicly verifiable - eg, every voter is provided with a 'voting receipt' with a non-identifying UUID and their voting results. Users are allowed to look up this info online at any time they wish.

~~~
Create
think again. <http://cm.bell-labs.com/who/ken/trust.html>

~~~
nailer
This is a classic, but how does it relate to my post? Are you pointing out
that a trojan could still be hidden in public code?

If so, I agree. But I think making that code public reduces the risk of it
being malicious. Eg, for one you've already made it so that the malware must
be implemented as a trojan, rather than being obvious. The other is the code
would be under massive scrutiny (hopefully without the developers OKing
changes without actually looking at what they do, ala OpenSSL).

~~~
Create
Read again. You cannot trust code, and making it public is almost irrelevant
in this regard. You need the full resources of an "emerging" country, like
China, to fully develop your own (e.g. Longsoon).

"Moral

The moral is obvious. _You can't trust code that you did not totally create
yourself_. (Especially code from companies that employ people like me.) No
amount of source-level verification or scrutiny will protect you from using
untrusted code. In demonstrating the possibility of this kind of attack, I
picked on the C compiler. I could have picked on any program-handling program
such as an assembler, a loader, or even hardware microcode. As the level of
program gets lower, these bugs will be harder and harder to detect. _A well
installed microcode bug will be almost impossible to detect_."

I would be awfully surprised, if people who made millions (from Verisign) by
"looking" at ssl would have made that kind of a mistake (effectively freedom
frying the French National Guard).

~~~
swombat
Certainly, everything can be hacked, but if the code is running on a machine
using standard off-the-shelf hardware, and running OpenBSD or another
equivalently open *nix distro, and the code is interpreted code running on
that machine, using the standard interpreter from that (open) language, then
the chances that someone might manage to introduce a hack are heavily reduced,
due to the number of eyeballs which can verify that the code is safe.

I agree that you have to look at every element of the chain, but my point is
that you can construct such a trusted chain that goes all the way from the
hardware to the vote-tallying software. There is still some potential for
hackery in the hardware, but that could also be ruled out by designing and
implementing some open hardware - a project which, I'm sure, would gather
plenty of support from the open source community.

~~~
Create
you still look @it as a technological problem. It isn't. It is a social
(moral) problem, thus cannot be solved by any interpreter, BSD fork (which
deceivingly, towards the BIOS pretends to be Windows ;) etc.

~~~
swombat
The social problem exists whether or not you have e-voting. It has been solved
to a satisfactory level already by having election observers, etc.

One of the cool things about social problems is they don't need exact
solutions. If you can solve things for 99.9% or even 99% of the cases, that's
considered good enough when it comes to people

------
LogicHoleFlaw
What blows my mind is how fubar the voting machine industry has been when it
has a model example of regulation in the gambling machine industry. I realize
that some of the technical design goals are different but many of the
regulatory aspects are extremely similar.

Reliable and trustworthy voting is the linchpin of democracy. There is no
excuse for voting "irregularities" in this day and age.

