Viewing entries tagged
proprietary

Comment

Vote Adding Machine Problems in FL -- We Have to Fix That!

Despite today's blog docket being for RockTheVote, I just can't resist pointing out a recurring type of technology-triggered election dysfunction that is happening again, and is 100% preventable using election technology that we have already developed. Here's the scoop: in St. Lucie County, Florida, the LEOs are having trouble coming up with a county wide grand total of votes, because their adding machine (for totting up the the subtotals from dozens of voting machines) has a great feature for human error. The full details are bit complex in terms of handling of data sticks and error messages, but I've been told that in early voting in 94 precincts, 40 precincts weren't counted at all, and 54 were counted twice. Thank goodness someone noticed afterwards! (Well, 108 precincts totaled out of 94 might have been a tip off.) Sure, human error was involved, but it is not a great situation where software allows this human error to get through.

We're only talking about software that adds up columns of numbers here! A much better solution would be one where the software refuses to add in any sub-total more than once, and refuses to identify as a finished total anything where there is a sub-total missing. Of course! And I am sure that the vendor of St. Lucie's GEMS system has a fix for this problem in some later version of the software or some successor product. But that's just not relevant if an election official doesn't have the time, budget, support contract, or procurement authority to test the better upgrade, and buy it if it works satisfactorily!

What's sad is that it is completely preventable by using an alternative adding machine like the one we developed last year (OK, shameless plug) -- which of course does all these cross-checks. The LEOs would need to translate that vendor-proprietary subtotal data into a standard format -- and I know some volunteer programmers who I bet would do that for them. They'd need to use an ordinary PC to run the open source tabulation software -- and I know people who would set it up for them as a public service.  And they'd have to spend less than half an hour using the system to get their totals, and comparing them to the totals that their GEMS system provided.

And maybe, in order for it to be kosher, it would have to be a "pilot effort" with oversight by the EAC; we've already discussed that with them and understand that the resource requirements are modest.  I bet we could find a FL philanthropist who would underwrite the costs without a 2nd thought other than how small the cost was compared to the public benefit of the result - that is, avoiding one more day of delay in a series that's causing a State to not be done with the election, more than a week after election day.

It's just one example of the many possible election integrity benefits that can be demonstrated using technology that, so far at any rate, only non-commercial technologists have been willing to develop for governments to use to do their job correctly -- in this case, producing timely and accurate election results.

-- EJS

Comment

Comment

Sequoia Announces Published Source Code

Sequoia Voting Systems announced today that they will be moving towards a disclosed-source model in which they will soon begin publishing their source code. I must say that the tone and language of the press release is gratifying, especially that they thought to say that the product is also open-data, which is critical for the goal of transparency of operation of a voting system. But perhaps the most satisfying is the about-face on security by obscurity. Sequoia's VP of R&D, Eric D. Coomer, PhD, was quoted:

Security through obfuscation and secrecy is not security. Fully disclosed source code is the path to true transparency and confidence in the voting process for all involved.

I couldn't agree more! Even though the product is still proprietary (disclosed-source not open-source), it's nice to see a vendor come around to the idea that open is not weak, and indeed to have taken the leap to do R&D to make a product that they say was intended from the beginning to be disclosed.

-- EJS

Comment

Comment

Wired: Nation's "First" Open Source Election Software

Wired's Kim Zetter reported on our Hollywood Hill event, in an article titled "Nation's First Open Source Election Software Released."  I got a few questions about that "First" part, and I thought I'd share a few personal thoughts about it. First of all, there is certainly plenty of open source software that does election-related stuff, as a few searches on github and sourceforge will show you. And there are other organizations that have had open source election software as part of their activities. FairVote's work on IRV software (some done by TTV's own Aleks Totic) is a notable example. Another is Ben Adida's notable work (on crypto-enabled ballot count verification among other things) represented in his Helios system, recently used in a real university election. And Helios is only one of several such systems.

Now, what is "first" about OSDV's release of a part of the election tech suite that we're developing in the TTV project? In my own view, one first is that the software is targeted at U.S. elections specifically, and on providing  automation of election operations in ways that match the existing practices and needs of U.S. elections officials. The many well-meaning efforts on open-source Web apps for Internet voting, for example, are laudable work, but not what most election officials actually need right now or can legally deploy and use for U.S. government elections.

So I think that it is a first indeed, when you combine that factor with all the other attributes of open-source, non-proprietary, open-data, operations-transparent, and so forth. It's not exactly a great invention to do what we're doing: pick a target for deployment; talk to the people who work there; find out what they want, and how to deliver it without asking them to also change the way that they do their work. Applied to election tech development, that approach is fundamental to what we do, and whether our work  is "first."

-- EJS

Comment

2 Comments

Tales From Real Life: Testing

Another in our series of real life stories ... how it actually works for real election officials to test a new voting system that they might be adopting for use in the state. The backplot is that New York State has been unwilling to give up its admittedly no-longer-legal*  lever machines, until the the state Board of Elections is confident that they have a replacement that not only meets Federal standards, but also is reliable and meeting similar requirements met by the old lever machines. There have been several setbacks in the adoption process, but the latest phase is some detailed testing of the candidate systems. (For the real voting tech geeks, what's being tested is a hybrid of the Dominion ImageCast scanner/Ballot Marking Device and the ES&S DS200 scanner with the Automark BMD.)

Bo Lipari is is on the Advisory Committee for this process, and has reported in detail on the testing process. You don't have to be a complete election geek to scan Bo's tales, and be impressed with the level and breadth of of diligence, and the kinds of kinks and hiccups that can occur. And of course the reportage is very helpful to us, as a concrete example of what kind of real life testing is needed for any new voting system, open or closed, to be accepted for use in U.S. elections.

-- EJS

* No-longer-legal means that NY state law was changed to require replacement of lever machines. In the initial release of this note I erroneously said that the replacement requirement was driven by HAVA. Thanks again to alert readers (see comments below) for the catch, and for providing many resources on the vexed question of "HAVA compliant" generally and lever machines specifically.

2 Comments

Comment

Voting Machine Monopoly?

It looks like the largest U.S. voting system company will acquire the second-largest, creating a potential monopolist controlling about three quarters of the market nationally, and 100% in some regions. I could explain why that might seem like a bad idea to many people, but the New York Times' The Business of Voting Machines already said it better than I. Likewise, one of our election integrity colleagues, Rob Ritchie of FairVote has already explained some of the details and implications in the HuffPost's Diebold's End: Consolidation of Largest Voting Companies Shows Need to Reform Elections. What I'd like to point out instead is how the pricing of the deal shows that there is in fact no real market for voting systems in the U.S. -- not in the typical entrepreneurial sense of "healthy market" in which players with superior value can effectively compete. This deal basically shows that Dieboild's Premier Election Systems, Inc. (PESI) is essentially worthless. The nominal price tag on the deal is $3 million, but ES&S is paying that small sum only on the condition that Diebold retain some PESI's liabilities.

So here is a story that should convince you -- if you were seriously thinking of becoming a new vendor of voting systems in the U.S. -- not to bother. Diebold/PESI was new vendor, that now after 6 years of hard work, and obtaining about a quarter market share, finds that the company's value is essentially nil, and further bedeviled by ongoing legal wrangles with its customers. And that new vendor started with the great opportunity of states awash in Federal funds from HAVA to buy new voting systems! Today, customer budgets are tighter, certification costs are higher, there are only handful of deals on the table for new revenue on new products, and ongoing customer contracts require continuing service and support for older products.

That story tells me the U.S. market for voting systems is essentially broken. It's still true that in that dysfunctional market, there is a basic conflict between making money and serving the public interest in elections. But now we can see that in selling voting system products in the U.S., it isn't even possible to make money! The largest remaining vendor may retain a healthy U.S. business, but I suspect it will be based on the strengthened ability to structure some profitable service and support contracts as the largest player -- and in some cases the only player.

Lastly, why do I keep saying "U.S. market"? Because Diebold is staying in the elections business in Brazil, and ES&S has plenty of business overseas as well -- mostly in countries that unlike the U.S., have elections run by the national government. Back here in the 50 states and thousands of elections boards, there is still plenty of work to do, to figure out how to effectively deliver the needed election and voting technology to the many government organizations that need it. What we do know now is that "the market" has not done so and likely will not in the future.

-- EJS

Comment

Comment

Open and Secret?

Scanning the news last week, I found rumors of Premier Systems (the voting system vendor formerly known ad Diebold) going open-source, and of the Federal government pondering cases where voting system test results should be confidential. An interesting juxtaposition! The first item I call a rumor not because I disbelieve the blogger in question, but because Premier hasn't announced anything. But the blog article does contain some interesting stuff, including a paraphrase of Premier's CEO opining that releasing source code to the public would be an approach that results in several beneficial outcomes.

At the other end of the spectrum we have some news from a recent meeting of the EAC's standards committee, including discussion of the new Voluntary Voting Systems Guidelines draft, intended for use in Federal certification testing of products like those from Premier. The draft would require that the result of the testing process should include documentation of all attacks the system is designed to resist or detect, as well as any vulnerabilities known to the manufacturer. Some committee members pondered whether the vendors should mark this information as confidential.

Some observers have questioned whether it would be appropriate to certify a system that has known security vulnerabilities. Others have pointed out that every system has vulnerabilities, and that the important issue is to be clear about the definition and boundaries of security, sometimes called a "threat model." Within those defined limits, customers should be very clear about what deployment and operational procedures that they need to adhere to, in order to maintain the integrity of system as defined by the vendor; beyond those limits, caveat emptor.

We might take up that debate another day. But for now, the obvious old adage applies: you can't have it both ways. If a system is truly open, then there are no secrets -- though you can try hushing up issues that can be readily discovered by directly inspecting the open system. However, I think that there is a case to be made that there really are no secrets, especially for systems that are important enough that people really do want to know "whether it really works." Next time, a couple specific examples from recently published voting machine security studies, that have put me in mind of another saying: "Open, Sesame!"

-- EJS

Comment

Hasty Innovation: the Kind We Don't Need

Today's posting landed in my lap in the form of a note from election tech colleague and Pitt researcher Collin Lynch, as part of a discussion about the role of the Federal government (specifically the Election Assistance Commission, or EAC) in "fostering innovation" in the market for voting systems, and ensuring a "healthy market". Well, of course, we think that there is plenty of room for improvement in voting systems, but there is a big difference between (for example) improved usability or reliability, and innovative changes voting system administration that require election officials to change how they do their job. But Collin hit the nail on the head:

Speaking as a software developer I think the cry for "supporting innovation" comes from two mistaken impressions.

  1. The mistaken impression that voting laws should somehow be concerned with the "health of the market", that is, the EAC's responsibility includes not only the stability of our democracy (difficult enough as it is) but also maintaining "healthy market" for the products of voting system vendors. This is a view that has caught on to some extent in defense spending and other areas but in my view a market exists soley to serve some need and artificially inflating that need, at best, tilts the market to no good end.
  2. The mistaken impression that the technology development process can be "stimulated," especially when the market has real needs for problems to be fixed, problems that appear simple and therefore should be fixed quickly. For voting systems in particular, this is not true.

These are fundamental misunderstandings of how good systems development works and how it can be made to work. In the extreme I have seen purchasers of systems assume that programmers "can just work faster" without considering the costs of quality and stability this brings. This is a view encouraged by the (seemingly) breathless pace of .com development which of course ignores the long lead time many of these overnight successes have and the stability problems that result from alphas being rushed to market.

I couldn't agree more. The last thing that we need in voting systems is encouraging vendors' already-existing bent for innovative bell/whistle features that customers (election officials) didn't ask for, and/or pushing for updated systems to be developed quickly and rushed through the regulatory certification and accreditation process. And while we at the TrustTheVote project are hardly in favor of foot-dragging, we do also recognize that quality, reliability, simplicity, integrity, and many other important qualities, fundamentally start with understanding what the customers need, and making sure that we build to those needs -- and with the attention to quality and reliability that is needed to make it through the regulatory process as well.

-- EJS