February 26, 2007
Disclosed Source
[Originally posted on Black Box Voting, in a thread about ACCURATE's recent annual report (PDF, 240Kb). I take exception the advice of self-appointed computerized voting experts that we citizens shouldn't have access to the source code of our computerized voting and counting machines.]
Joseph Hall-
It took a while to find the papers about use of "disclosed source" (putting vendor's source code in escrow and permitting access). In the future, it'd be great if those ACCURATE reports included citations, bibliography, or whatever else it is academics do to reference work.
[For the viewing audience, here's the link for Transparency and Access to Source Code in E-Voting (a paper submitted to the EVT'06 conference) and Open Source Software - Does It Have A Place In California’s Electoral System? (a prepared statement for a hearing on same).]
This is a brief response. To be fair, I'd do a better job. But my follow thru is often lacking, so that might not happen. So here it is.
You correctly identify many of the challenges faced with the current regime of computerized voting and counting machines. I quite like the phrase "“enclosure of transparency”" and the analogy of the taking of the commons that occurred in Ireland. Very apt.
So it pains me that you've concluded that public access, transparency, while good, shouldn't be done too hastily. That any inspection is best done by experts.
I'm sorry, but relying on the experts is exactly how we got to this point today.
Further, while I'm by no means an expert, as a tax payer and citizen, I'm more than qualified to inspect our voting and election systems. It's my right.
Your paper even suggests that one step towards transparency could be to have recognized experts sign NDAs before any inspection. Because known bugs in the wild could hypothetically jeopardize the vote count.
First, you're perpetuating the status quo of placing corporate property rights over the prior, inalienable rights of citizens. (Who among us doesn't acknowledge that the complicated task of adding numbers, having no prior art, is sufficiently novel to protect behind trade secrets and patents?)
Second, by advocating "security through obscurity", you're furthering the fine tradition of all entrenched interests who don't want to forfeit the advantages of vendor lock-in. Because any public disclosure of flaws would necessarily crack open the door to how these systems work and reveal that the problem they attempt to solve is not intrinsically complicated. I'll also note such advice is usually accompanied with a suggestion to have "trusted" bug reporting and databases, which I believe you omitted.
Third, you've ignored the role of certification and procedures for the physical security of the devices. While I recognize that relying on every jurisdiction to use adequate and proper procedures is expecting too much, to do so would be in keeping with your optimistic recommendations.
Fourth, who gets to decide who the experts are? That selection process is subject to the discretion, judgment, bias, or whatever of some authority. What establishes the legitimacy of that authority? With your proposal, you end up with a "it's turtles all the way down" type of rationalization. (The world is on the back of a turtle, which itself is on a turtle, etc.) With each step one further away from public oversight.
Fifth, your paper ignores the majority of the proprietary software vendors provide. Although everyone gets worked up about computerized voting and computerized counting, there's also candidacy filing, GIS systems, ballot design, ballot construction, ballot printing, voter databases, reconciliation (tracking who voted), mail sorters (inbound and outbound), bar code readers, signature verification, and probably a few others. What of those systems? What about them warrants secrecy? Isn't the examination of those systems also part of the public vote count?
As you well know, being a computer security expert, all trusted cryptography and security systems are publicly vetted. No party who is serious about security would ever rely on obscurity. The issue isn't even worth debating, except to again point out the fallacy.
Similarly, you also know that the biggest security threats are insider (trusted) access and leaks. NDAs and trade secrets have done nothing to prevent others from learning about the security flaws in the existing computerized voting and counting systems.
In summary, I'll repeat my disappointment in your conclusions. Frankly, I don't understand how you added 2 + 2 and ended up with "fish".
I do value your work, however. As with many really bad ideas, only after every conceivable attempt has been made to mitigate the inherent flaws of computerized voting (an exhaustive search of the solution space), with no positive results, will the die-hards reluctantly admit that, gosh, it looks like it was all a bad idea after all. (The concluding step is usually finding a scapegoat.) So it's best to fully fund efforts such as yours, so that we may hasten its conclusion.
So please continue. Happy hunting.
Cheers, Jason Osgood / Seattle WA
Joseph Hall-
It took a while to find the papers about use of "disclosed source" (putting vendor's source code in escrow and permitting access). In the future, it'd be great if those ACCURATE reports included citations, bibliography, or whatever else it is academics do to reference work.
[For the viewing audience, here's the link for Transparency and Access to Source Code in E-Voting (a paper submitted to the EVT'06 conference) and Open Source Software - Does It Have A Place In California’s Electoral System? (a prepared statement for a hearing on same).]
This is a brief response. To be fair, I'd do a better job. But my follow thru is often lacking, so that might not happen. So here it is.
You correctly identify many of the challenges faced with the current regime of computerized voting and counting machines. I quite like the phrase "“enclosure of transparency”" and the analogy of the taking of the commons that occurred in Ireland. Very apt.
So it pains me that you've concluded that public access, transparency, while good, shouldn't be done too hastily. That any inspection is best done by experts.
I'm sorry, but relying on the experts is exactly how we got to this point today.
Further, while I'm by no means an expert, as a tax payer and citizen, I'm more than qualified to inspect our voting and election systems. It's my right.
Your paper even suggests that one step towards transparency could be to have recognized experts sign NDAs before any inspection. Because known bugs in the wild could hypothetically jeopardize the vote count.
First, you're perpetuating the status quo of placing corporate property rights over the prior, inalienable rights of citizens. (Who among us doesn't acknowledge that the complicated task of adding numbers, having no prior art, is sufficiently novel to protect behind trade secrets and patents?)
Second, by advocating "security through obscurity", you're furthering the fine tradition of all entrenched interests who don't want to forfeit the advantages of vendor lock-in. Because any public disclosure of flaws would necessarily crack open the door to how these systems work and reveal that the problem they attempt to solve is not intrinsically complicated. I'll also note such advice is usually accompanied with a suggestion to have "trusted" bug reporting and databases, which I believe you omitted.
Third, you've ignored the role of certification and procedures for the physical security of the devices. While I recognize that relying on every jurisdiction to use adequate and proper procedures is expecting too much, to do so would be in keeping with your optimistic recommendations.
Fourth, who gets to decide who the experts are? That selection process is subject to the discretion, judgment, bias, or whatever of some authority. What establishes the legitimacy of that authority? With your proposal, you end up with a "it's turtles all the way down" type of rationalization. (The world is on the back of a turtle, which itself is on a turtle, etc.) With each step one further away from public oversight.
Fifth, your paper ignores the majority of the proprietary software vendors provide. Although everyone gets worked up about computerized voting and computerized counting, there's also candidacy filing, GIS systems, ballot design, ballot construction, ballot printing, voter databases, reconciliation (tracking who voted), mail sorters (inbound and outbound), bar code readers, signature verification, and probably a few others. What of those systems? What about them warrants secrecy? Isn't the examination of those systems also part of the public vote count?
As you well know, being a computer security expert, all trusted cryptography and security systems are publicly vetted. No party who is serious about security would ever rely on obscurity. The issue isn't even worth debating, except to again point out the fallacy.
Similarly, you also know that the biggest security threats are insider (trusted) access and leaks. NDAs and trade secrets have done nothing to prevent others from learning about the security flaws in the existing computerized voting and counting systems.
In summary, I'll repeat my disappointment in your conclusions. Frankly, I don't understand how you added 2 + 2 and ended up with "fish".
I do value your work, however. As with many really bad ideas, only after every conceivable attempt has been made to mitigate the inherent flaws of computerized voting (an exhaustive search of the solution space), with no positive results, will the die-hards reluctantly admit that, gosh, it looks like it was all a bad idea after all. (The concluding step is usually finding a scapegoat.) So it's best to fully fund efforts such as yours, so that we may hasten its conclusion.
So please continue. Happy hunting.
Cheers, Jason Osgood / Seattle WA
Defending Plain Text
Elliotte Rusty Harold gets his geek on pointing out that Plain Text Files are Confusing. We all know that Apache's config system blows. Harold argues that XML can help.
If XML is the answer, then it's likely you're asking the wrong question.
The correct answer is to use a grammar. Perhaps with a tool like ANTLR.
Say we follow Harold's advice. Even if you (mis)use XML, you're only getting a (very poor) lexer to handle the syntax. You still have to parse the tokens yourself to handle the semantics.
Like the rest of us, I've wrestled with plenty of horrible XML. So it's not like that's a cure all.
Of course, XML apologists will argue that the offenders are doing it incorrectly. To which I answer that the medium is the message; the offenders have no choice but to misuse XML, for there is no correct usage option available.
If XML is the answer, then it's likely you're asking the wrong question.
The correct answer is to use a grammar. Perhaps with a tool like ANTLR.
Say we follow Harold's advice. Even if you (mis)use XML, you're only getting a (very poor) lexer to handle the syntax. You still have to parse the tokens yourself to handle the semantics.
Like the rest of us, I've wrestled with plenty of horrible XML. So it's not like that's a cure all.
Of course, XML apologists will argue that the offenders are doing it incorrectly. To which I answer that the medium is the message; the offenders have no choice but to misuse XML, for there is no correct usage option available.
February 01, 2007
Grammar for HTTP?
I'm creating a mini HTTP server for embedding in my application. It's
kind of fun. So I've been scanning a bunch of other mini HTTP
servers. Thus far, they all hard code the parsing of HTTP headers.
Seems silly. I looked around to see if anyone had a grammar (e.g. lex/
yaxx, ANTLR) for lexing and parsing HTTP. I've found none so far.
Might be a useful thing to do.
kind of fun. So I've been scanning a bunch of other mini HTTP
servers. Thus far, they all hard code the parsing of HTTP headers.
Seems silly. I looked around to see if anyone had a grammar (e.g. lex/
yaxx, ANTLR) for lexing and parsing HTTP. I've found none so far.
Might be a useful thing to do.
