Preston L. Bannister { random memes }

Text about Rush Holt’s Voter Confidence and Increased Accessibility Act via CATO, which serves as a reminder that lawyers and politicians should not be allowed to design algorithms (or do math).

How to Reform E-Voting
It bans the use of computerized voting machines that lack a voter-verified paper trail. It mandates that the paper records be the authoritative source in any recounts, and requires prominent notices reminding voters to double-check the paper record before leaving the polling place. It mandates automatic audits of at least three percent of all votes cast to detect discrepancies between the paper and electronic records. It bans voting machines that contain wireless networking hardware and prohibits connecting voting machines to the Internet. Finally, it requires that the source code for e-voting machines be made publicly available.

This proposal shovels too many irrelevant requirements on the problem. Clearly the author cannot distinguish between essentials and what just sounds good.

Early in my career I ran into an observation from Butler Lampson (in a copy of Hints for Computer System Design) which can be paraphrased as:

Only end-to-end checks matter – everything else is (or should be) an optimization.

The same principle applies in this case. To be sure an election is counted accurately we need to be able to detect votes added, changed, or deleted. On one end we have the voters casting their votes. On the other end we have the recorded tally of all votes cast. Given a check that the two ends match, we don’t need anything extra in the middle.

No system is ever perfectly secure. With enough corrupt people in enough places, any election (as with any other security system) can be subverted. What we can do is make the expense and risk of detection very high. We can make elections more reliable and more secure than was possible in the past, with some clear design principles and relatively simple software and hardware.

To insure votes are not changed after they are cast by the voter:

• Give the voter a record of their vote. No personally identifying information, just an ID number (randomly generated and used only once) and a list of votes.
• Publish a public tally of all votes. Anyone can check that the numbers add up. Any voter can verify that their votes are present and accurate.

To insure voters are not falsely added or removed:

• Print a list of all votes recorded at a polling place at close of polls – one copy to post outside the polling place, and a reasonable number of copies for anyone interested.
• The published public tally of all votes must include the polling place. Anyone can check that these totals match.

To trust the local results both the hardware and software design must be published for public review and approval far in advance of the election. Interested parties must have an opportunity to spot-check the hardware and software both before and after the election. Very likely well-designed and well-reviewed software and hardware will see very wide use (in this country and others). Counting votes is not complex. Getting the hard parts of the design right need only be done once.

To trust the voter’s receipt is genuine, record a cryptographic “fingerprint” for each voter, and print the fingerprint on the voter’s receipt, the polling place tally, and the final public tally. Combined with open, reviewed, and verified hardware and software designs (this is essential) – this makes election results almost impossible to subvert without detection. This is a huge improvement over the present.

Today, once you cast your vote, you have no idea if it was counted. Today, when the votes leave my polling place, I have no way of verifying that they were recorded. What we lack is an end-to-end check.

By itself, a “paper trail” does not prove anything, and “paper records” used for recount are in not certain to be more reliable. Automatic recounts – without an end-to-end check – do not prove a thing. The end-to-end check is essential, and what we lack.

Banning wireless networks and connections to the Internet is silly. Both are sources of possible problems (I would be extra-wary if a design used either), but the problems are avoidable. Even though wireless networks and the Internet are both insecure, software folk figured quite a while ago how make secure connections across insecure networks (see Secure Shell for a widely used example). I can sit in my backyard using a laptop connected to my wireless network and from there to the public Internet – and connect securely to computers anywhere on the Internet, using freely available and publicly reviewed software (and have done this for years).

Open review is essential. Banning specific technologies is unnecessary.

We can make fairly simple use of existing technology to make voting more reliable and more secure than was ever possible with paper ballots – if the design is right.

There are problems with “voting machines” as used now, but the problems can be solved. This article from CATO paints entirely the wrong picture.

The Case Against E-Voting
Ars Technica has an article about problems created by e-voting machines in the French elections on Sunday. Apparently, technical problems caused long lines, causing some voters to be turned away from the polls.

France’s problems are not an isolated incident. In November’s U.S. election, one county in Florida (ironically, the one Katherine Harris was vacating) seems to have lost about 10,000 votes, which happens to be smaller than the margin of victory between the candidates. And there were numerous smaller examples of e-voting problems all over the United States in the 2006 elections.

Those incidents by themselves would be a good argument for scrapping computerized voting. But the most important argument is more fundamental: e-voting is not, and never can be, transparent. The most important goal of any election system is that the voting process be reliable and resistant to manipulation. Transparency is a critical part of that. Transparency makes it more likely that any tampering with the election process will be detected before it can do any damage.

First, a few places having trouble does not prove anything. For the past several years I have volunteered to run the local polling place. The transition from paper ballots to using “e-voting” was anti-climatic. In fact, voters get through the voting process just a bit quicker (no long lines), and with less than half the number of errors (both voters and poll workers are human). Having worked several elections both before and after the conversion – in the same neighborhood – I can be fairly sure that things at the polling place are indeed better.

Are there problems with “e-voting” as currently practiced? Absolutely. Are the problems insoluble? Absolutely not.

Yes, the hardware and software design of voting machines should be open to public review. There is nothing sufficiently special about the hardware or software to merit a proprietary design. Yes, there is presently a risk of mass-stealing votes, if the folks upstream in the voting process cannot be trusted – though this problem existed with paper ballots.

There is a simple way to make “e-voting” more secure than anything we have used in the past. What we need is a simple end-to-end check. At one end we have the voter casting his votes. At the other end we have a sum of all votes cast. What if you could verify that your vote was counted? What if I (as a poll worker) could verify that the sum of votes from my polling place was in the final count? Between the two, we (the voters) would know that our votes were counted accurately, and that no voters were under or over counted.

The end to end check is simple. The voter gets a printed slip with a unique code, and a list of his or her votes. The code identifies the vote, but not the voter. At the end of the election, a list of all votes gets published on a government website. The voter can check the website, and verify that his/her votes are present and correct.

At end of the day, the polling place produces a sum of all votes collected at that location – the copies to poll workers, poll watchers (and potentially any interested voter). That same sum should also appear on the government website. Any voter can potentially verify that the number of votes collected at the local site on election day matches the published counts for the entire election.

There is a bit more to this. The software and hardware used must be open to public review. The voter’s slip and polling place printout must include a list of encrypted signatures (so fake voter slips can be caught).

The end result is in fact dramatically more open and reliable than anything we could do in the past. Done right, “e-voting” can make subverting elections vastly more difficult than any time in the past.

This is a bad joke, in more than one sense.

The folk that founded this country were pretty smart, but by no means all-knowing. I have tremendous respect for the thought that went into the founding of this country. Seems somehow between founding and the present day, something fairly fundamental has gone wrong. Perhaps in a thousand years the study of society and politics might be reduced to a science, and if someone from that future dropped through a time-warp, they might be able to point out in detail what mistakes we have made. Lacking any convenient time-warps, we are stuck with having to figure out things for ourselves.

I spend my work-time working on software, and in software one of the problems we have to deal with is scale. We may have a solution that works very well at first, but runs into trouble when the scope of the problem suddenly grows. In the physical world you are not likely see the scope of your problem suddenly change by a factor of a thousand or a million. In the software world, such changes are not unusual. What worked well for one user may not work well for a hundred, and fail utterly when users number in the millions. A database may grow from a hundred items to a hundred million in a few years. Scale is very much a concern for many software projects. Not everyone who works on software learns this lesson, and fewer still learn this lesson well.

After paying a bit of ongoing attention to politics, I am starting to wonder if where things go wrong has a lot to do with scale.

The population of Orange County, California is currently somewhere in excess 3 million. (The official count was slightly lower, but illegal immigrants tend to go uncounted, and are not exactly rare here.) Contrast this with the population of about 2.5 million for the entire United States in 1776.

The original number of elected Representatives to Congress was meant “not exceed one for every thirty Thousand”. In 2007 the actual number of Representatives is about one for every 690 thousand. When your representation becomes 23 times more remote, perhaps things start to go wrong.

Given the county has a greater population than the entire United States at it’s founding, how does the government compare? The County of Orange has a five elected Supervisors. The first Congress had 65 Representatives, and 26 Senators. Clearly representation is much more remote than at this country’s founding.

Now to descend from fine ideals to local politics…

Our current elected county Sheriff’s prior experience was basically that of a security guard for the county courts. Not an especially impressive base for leading law enforcement for the entire county. He had substantial political and monetary backing, and got elected. He did come and speak at a local venue, before the first election. He spoke very well, but at the end I realized somehow that I simply did not trust the man. He subsequent record seems to reinforce that initial impression. If representation was less remote, if other voters were more likely to hear and meet there potential representatives, would better folk get elected?

Forward to the present, and this announcement…

OC Blog: Anderson Elevated to Assistant Sheriff
OC GOP Central Committee member and Sergeant at Arms Jack Anderson was appointed yesterday by Sheriff Carona to be one of four Assistant Sheriff’s. Until recently Jack was the captain overseeing South Operations.

Also, Sheriff Carona elevated Assistant Sheriff Jo Ann Galisky to be Under Sheriff (a newly created position).

Congratulations to Jack and Jo Ann!

So the new Assistant Sheriff’s qualifications are his political connections, and as “Sergeant at Arms”? Impressive, but not in a good way.

As to the female appointed to the newly created position of, er, “Under Sheriff” … I do not know what to say. I hope she serves well in that position.

Another obvious observation…

I’m in the middle of exercise the aim of which is expression of an OLAP hypercube into a web page, using HTML/CSS/Javascript (no applets, or Flash, or …). The presentation is very much like a spreadsheet, but the data and UI manipulation models are very different. Add to this the fact that end result is a definition (a “model”) of how to build hypercube and then generate a report from the cube. The model will be used many times by a back-end “publisher” to generate reports (often in very large volumes).

So in the end I have a sheet that must evaluate identically in the web browser and in a back-end process.

Spreadsheets typically have a small expression language used to calculate fields from other fields. The expression language is usually something invented – not used anywhere else – and need their own little specialized interpreter. In my case I have need for a similar interpreter. I could have one implementation on the server, and do a round-trip to the server every time a cell needed update. I could do an implementation to run in the browser, and another implementation for the back-end process, with the risk that the two implementations might differ (and additional development and testing time). Neither alternative is ideal.

What if the expression language used in the spreadsheet were Javascript?

With Javascript we get a much more expressive language, eliminate the need to implement an interpreter, and get multiple well-tested implementations (Rhino, Spidermonkey, JScript). The syntax may be a bit more of a bother than the usual spreadsheet expression language, but perhaps not enough to matter. There is the potential for security risks that needs to be addressed (and should be quite solvable).

Have to chew on this one a bit more…

There is a W3C group working on the next standard for HTML. In tracking the current discussion, things started to make more sense when the roles and points of view of some participants became clear (or at least clearer). Seems only fair (and perhaps necessary) to make my own motivations clear.

I am a software developer. After looking at the mass of incompatible behaviors during the browser wars, I intentionally stayed away from making use of “dynamic” HTML until Netscape 4 and IE 5 were almost gone from use. A few years ago I started on a somewhat ambitious (and risky) project to replace a Windows desktop GUI application with a web application. My goal was to produce an application that was better than the Windows GUI it was displacing (not an easy thing to do). This was a one-man project that pulled in a bits of everything.

• A Java applet, small as I could make it, but essential to the UI.
• MAYSCRIPT enabled Java to Javascript, and Javascript to Java interaction.
• Heavy use of scripted behaviors.
• Heavy use of CSS for carefully controlled layout.
• Pure HTML 4.01 Strict pages – with quite a few runs through a validator.
• No use of browser specific code – except for the bit of script that generates the tag to invoke the applet.
• No document.write() – anywhere.
• Testing iterations first under Firefox, and later under IE.
• Server-side Java generating HTML pages, HTML fragments, and both sending and receiving JSON data.
• Server-side C++ called from Java to perform the heavy processing.

The end result is both somewhat complex, near squeaky-clean in standards compliance, and works well in both Firefox and IE. At the end of the development cycle I did try firing up the product in Opera … and it almost worked. Was this a result of Opera not-quite meeting the standards? Was the fault in my code for misusing the standards in ways that just happen to work in Firefox and IE? Was the fault in standards that allowed more than one reasonable interpretation? Frankly, I expect it is a bit of all three. Unfortunately, I cannot invest the time needed to figure this out, as our customers simply do not care about Opera.

The fact that standards-compliant browsers might differ in their interpretation of standards-compliant code does not surprise me. This expectation comes out of experience.

In my first job out of college, the guy in the next office was working on what was to be the second validated Ada compiler. At the time, Ada was meant to be the most carefully designed and throughly specified programming language ever – and compilers written for the language had to pass strict validation tests. The guy next door would call me over when he hit a particularly tricky section. Ada was a fairly complex language, with a fair number of “dusty corners” not explicitly covered by the specification. As it turned out there were quite a number of cases where we had to puzzle out what behavior made the most sense – and there was not always a single clear choice.

The lesson I pulled from this experience is that the more complex a specification, the more likely there are “dusty corners” where thoughtful folk could come to reasonable but differing implementations. Simpler is often better.

Also relevant to the W3C activity is my point of view in relation to maintaining version compatibility. For most of the software projects I have been involved with in the last twenty-odd years, maintaining compatibility was an explicit concern. I will not claim we always got things right, but I do try very hard not to screw the customer, and will claim to have got better at this over time.

Since I find that my experience leads me to back views offered by Chris Wilson (from Microsoft), just to be clear – I do not work for Microsoft, never have worked for Microsoft (directly or indirectly), and probably never will. My only remotely “special” relationship would be the fact that I ate lunch with Bill Gates at the Windows developer’s conference in 1984 (yes, pre-Windows 1.0), and that’s it. (Spent the next seven years writing pure Unix code, BTW.)

My point of view is that of an application developer reasonably proficient at use of HTML/CSS/Javascript (another other things), and interested in improving the programming model offered to web application developers.

ongoing · On Selling Music
Finally, I remain astonished that the subscription model hasn’t caught on; it seems like awfully low-hanging fruit. There are any number of artists I’d subscribe to for ten or twenty bucks a year in exchange for an irregular flow of new material; live cuts, studio work, collaborations, whatsoever, along with discounts and front-of-the-line access to their regular output. Which is ten or twenty bucks a year more than they’re getting out of me now. The technology wouldn’t be hard to set up, either.

I agree – a subscription model makes a lot of sense to me, for the artists I like that are still producing work. The money for the artist might be a smaller than regular sales, but also might serve as an indication of future sales, and provide encouragement for the artist. May not make a difference to mass-market music, but for the smaller folk … ?

Picked up the JSON string to/from object implementation from json.org a year or so back (which I see has since changed). Did not care for the pollution of the stock classes with toJSONString() methods (don’t care much for the method name either), so implemented the same function as methods scoped within a global JSON namespace:

JSON.toJSON(object) returns string
JSON.isJSON(string) returns truth
JSON.parseJSON(string) returns object

Perhaps a matter of taste, but I do prefer three functions in an isolated namespace over the approach in the json.org code. The string encoder looked (and is) a shade inefficient. Checked by putting together a test page. Chose the string encoder in json.js from timings in Firefox and IE6 (your results may differ). Barring any editing errors, this should work in IE6/IE7, and Firefox/Mozilla. The GET/POST implementations may be a bit cleaner too.