First, no court or judge can overturn a verdict of "not guilty". That's the "double indemnity clause". You can't be tried twice for the same crime -- once you're found innocent, that's it.
An appellate judge has lots of options. They can look at the evidence themselves and decide that a guilty verdict was unfair (as in this case,) or they can look at the evidence and decide that the lower court failed to take it all into account and demand the case be retried. They can also look at the procedures as well as the people. A sleeping defense lawyer, a drunk judge, a jury foreman who was found to belong to the KKK, any number of things can go wrong at the lower court. The appellate judge has the responsibility and the power to set things straight.
It brings up a good discussion on the power of judges. For example, it's common practice in civil proceedings for the lawyers to go "judge shopping", which is to get their case heard in a jurisdiction that has a judge with a track record of siding with their client. (Criminal procedings typically take place where the crime was committed, and unless there's a public uproar the cases are almost never moved.)
I will say that every time I've been in a courtroom the judges have been universally, absolutely professional. I have never failed to be impressed by a judge's common sense approach. Lawyers will try their slick speeches on juries, defendants will come up with bullshit stories, and the judges I've seen simply have had no tolerance for any shenanigans. "Get to the point, please" has got to be the most commonly spoken phrase in court (except for "I didn't do nuthin', your Honor!")
The judge did not write the law. The state wrote it. The judge's job is to uphold it.
Personally, I have always thought the 9 years was far too stiff. There are wife beaters, rapists, thugs and murderers that get far lighter sentences, and who deserve far more. Spammers have the ability to make millions of people a tiny bit miserable with their crime. Rapists have the ability to totally destroy a handful of people with their crime. Which is worse? Which is more needful of punishment? In these days of finite prison budgets, imprisoning which one makes society better off? I've even got the analysis -- to anyone who answered "spammer", you're far more selfish than I can even imagine.
As hinted at in TFA, a looming menace is "Trusted Computing." The BIOS is where the lockout has to start for Treacherous Computing to be successful.
With a lockout, your BIOS can ensure that only a "signed OS" will be allowed to boot. Microsoft will sign their OS. But what about Linux? Will only a Red Hat Enterprise signed kernel be able to boot? You'll even need to get your signature issued on a per-computer license. Allowing random people compiling the kernel to "sign their own" will completely defeat the purpose of checking the signature on the kernel in the first place, which is to keep unknown, untrusted software from running on it.
If Treacherous Computing is going to be possible, by definition it must start with an absolutely closed BIOS.
One other thing I failed to mention in the previous post: the fully laden wings droop substantially, and I believe they almost drag on the ground when full. It would be extremely difficult (if not impossible) to land a craft in a condition like that without accidentally dragging a wingtip.
I think the problem with this live test is that the plane may not be capable of withstanding a landing fully loaded with fuel. It might be designed such that it wouldn't survive a hard impact (wings full of fuel have a lot of inertia, hit the ground hard enough and they WILL bend or fall off.)
Think of this plane as a one-shot deal. Reusability wasn't the goal -- getting around the world was.
Sure, pilot safety is a consideration -- in some emergency situations, the pilot could probably dump the fuel to land safely. In a worst case scenario, he could probably land with full tanks, but as I mentioned before that might not be without substantial risk to the aircraft. It might even be expected that the plane's airframe would fail if it landed full.
There's a lot of FUD in this discussion, and I'd like to clear a bit of it up. First, track data is very strictly formatted. If you are issuing a card for use in financial transactions, it needs to be encoded according to ISO 7811, 7812 and 7813 standards. These standards declare what each and every character on the cards means, how it is to be encoded, how it is to be read and how it is to be interpreted. And these standards do NOT currently contain a field for "Primary language of cardholder". Therefore, they can't store this information on the card, because nobody would know where to use it.
And just for more information, track 2 has space for only 40 bytes of numeric data (it's a 4 bit character set that has no alpha capacity.) It has provisions for a country code, but only for cards in a specific format. The country code is to be used primarily to determine and display exchange rates to the cardholder. Currently, most credit cards issued in the United States use anywhere from 29 to 36 of the 40 available bytes. Many European cards use 33 to all 40. And some cards violate the standards, and exceed the maximums. Customers of these banks get turned away by retailers whose driver software refuses to parse these tracks.
Any remaining space not covered by the required fields falls into a "discretionary data" field. This can be anywhere from 0 - 11 digits. Typically banks place a random nonce into the cards to ensure that the stripe could not be created without the card present.
Technically, a specific bank could choose to issue cards that have an ISO language code embedded in their own discretionary data field, and could program their ATMs to respond to their cards. (They could also choose to have their own 0-9 language code, offering ATM services in one of 10 languages.) But any such system would be proprietary, and would not be respected outside of their own private network. That's why people see "Retrieving preferences" messages: the card is looked up first, and the preferences are transmitted back to the ATM. This method can be implemented by any ATM system, and will work regardless of what the issuing bank does on the mag stripes.
Something else to keep in mind is that mag stripes turn over very slowly. That means you cannot just change the stripe format and expect magic to happen overnight. These cards are issued at great expense once every four years or so. I believe it costs somewhere around $2.50 or $3.00 to create and mail a new card. Multiply that by a million card holders, and that's an expense you want to avoid as much as possible.
Finally, keep in mind that all this is based on 1970s era technology, and was developed with a distinctly American bias. Languages and disabilities were not a part of the landscape of the era.
That's among the reasons we "looked" at their fingerprinting technology, instead of "bought" it. I think the Visa thumbs-down probably had more to do with it, however. That, plus the per-workstation cost would have been quite high.
These guys claim to have a good liveness detector in their pad. But they're still $100 dollar pads, not the $1000 ones the FBI uses, which means that they could be that much less secure.
They also described their software as storing and transmitting "a third" of your fingerprint, whatever that means.
Your PIN is never stored on your card, and hasn't been since the early 1980s. Not even in an encrypted format.
When you key your PIN, the PIN pad accepting it will encrypt the PIN along with other transactional information plus its own serial number using a key injected securely by a representative of the issuing bank.
This blob plus the other data is transmitted to an authorizer, where the account is looked up and a local copy of the blob is created. If it matches the incoming blob, it's a go.
The bank almost certainly did not encode your card in the scenario you described above. Encoding is usually done with a machine-fed stripe writer, and is almost never done by hand-swiping the stripe anymore. (The timing is usually better on machine fed devices.) What the bank most likely did was to generate a blob similar to the one I described above for transmission to their authorizing computer, who immediately stored it and activated it for use.
Yes, the original intent of mag stripes was to enable offline transactions. However, bad guys quickly figured out how to read stripes and forge PINs, so everyone went to strictly on-line authorizing in the early 1980s.
There are companies offering just that. We looked at PayByTouch, a company that offers a "digital wallet" that you can access at participating retailers. As a customer, you go to a kiosk, register your fingerprint, and swipe the cards you want to store in the "wallet". At the point of purchase, you key your phone number and touch the fingerprint reader, and the PIN pad brings up your wallet where you can scroll through your cards and select the one you want for this transaction.
According to PayByTouch, the phone number is used as an index to speed fingerprint matching. The PBT computer located at the point of sale device turns the fingerprint data into a hash on the spot prior to sending the request over the network, so the "clear" fingerprint isn't stored or sent anywhere.
I personally thought customers would find "fingerprinting" to be too Big-Brotherish, but many pilot customers preferred the idea of using a fingerprint over carrying a wallet full of credit cards and shopper loyalty cards. But at the time we looked at them, Visa refused to certify them as being as secure as a mag stripe, so the idea died around here.
What I don't understand is why people purchase ringtones at all when almost every phone I've dealt with accepts MIDI formatted music of one type or another.
There are websites that have have huge collections of MIDI. There's everything from TV themes to pop music to automated Mozart minuette generators. Grab one, shove it in your phone and begin annoying people immediately. It's just not that hard. $2.00 seems usurious.
Sure, COM has problems, but show me a still-viable object interop system that's 14 years old that doesn't.
It would be nice if it had strong type safety. It would be nice if full type information was present on every interface. It would be nice if didn't have stupid funky memory management issues. It would be really nice if it didn't have the awful apartment models. It would be nice if it had a lot of things, actually. But what it does have is a pretty simple design, and it scales. It allows for neat extensions. It allows for a slick upgrade path. And even if I think DCOM is the spawn of Satan, the fact that it was possible to implement it after-the-fact with a legacy set of objects is still kind of neat.
The other thing that I like about it is it strictly enforces the "black box" usage of the interfaces (for the most part.) Even though our COM objects are written in C++ and mostly used by C++ applications, we use VB test programs. Why? Partly because some of the objects end up getting used in ASP web pages, but also because we know if we can fully test it with an IDispatch caller, the coders aren't playing "pointer shenanigans" through the interface.
Jeez, listen to me. I sound like a Billy the Gates fanboi, eh? Well, Don Box made me say it!
Wow, thank you, thank you! I hadn't checked recently for an updated flashblock. As it was, I detest flash so much that I was certainly willing to put up with the annoyances at the few sites I frequent where it's required.
Anyone else heading over to update their version of flashblock, don't forget to stop your browser and delete your userprofile/chrome/flashblock.jar file before trying to install the new one.
Yeah, ordinary COM is implemented in vtables, so once you've located the IID in the registry and loaded the DLL into your process, calling a COM method is exactly the same speed as calling a native method.
As long as you're using the native interface on an in-process object on the same thread. If you go thru a late binding interface (such as IDispatch in Microsoft's COM for VB) then you get the performance penalties of lookups (which I believe are cached, so it doesn't stay awful.) And if you go across threads in the wrong apartment model, out of process, or, (god-forbid) off-machine via DCOM, then you get to add the very substantial performance hit of marshalling in addition to whatever context switching costs you.
I don't know anything about the internals of XPCOM, or how it's used in Mozilla. But COM itself doesn't necessarily have to suck.
The one feature I wish Flashblock would add is a whitelist. There are some pieces of flash I'd always like to see, such as navigation bars on some sites. The rest of flash, forget it.
Flash is one of the worst things ever to happen to the web. "Look folks, here's another non-standard standard we're going to foist off on you, one complete with its own security holes and annoying behaviors that you (as an end user) can't modify."
That's pretty much what I said, except that I don't mind too much if a machine prints "JOHN SMITH FOR PRESIDENT" instead of my marking an X next to John Smith's name. I also think sealing the printing system from the voters prevents the voters from stuffing the ballot boxes.
One thing I don't want is a barcode indicating my vote. As a human, I have no way of verifying whether a specific code indicates SMITH or JONES. My intent is reflected only by the printed name, and it's my intent that must be counted, not some random-looking pattern of stripes.
A good friend of mine is a Briton, and he tells me the votes there are still done strictly with pencil and paper. However, he's been in the USA for the last eight years. I'm curious to know if that's still true, or have you been stuck with electronic machines, too?
Great point -- two independent systems are way harder to hack (in a synchronized fashion) than one.
It would be even more true if one of those is running on Linux, while the other runs Windows (or OS X or anything else.) There would be no "leveraging" of hacks or weaknesses between the two, making it even harder.
If you can't trust the voting software, what makes you trust the OCR tabulation software?
Again, I'd say that the importance of rapid ballot counting is only of interest to news organizations. The outcome of the election is truly irrelevant to the rest of us until the winner takes office, which is months away. OCR just introduces more machinery and more complexity between my vote and the election results.
Sure, there could be an OCR reader located at the ballot box watched by the election judges. Fine. I just don't think it's necessary when there's already some software that knows how you cast your ballot. The paper is for the recounts, not for the election.
Because it's new technology, we get to pass laws regarding its usage. You don't have to have a 100% hand-recount to be sure the voting machines haven't been tampered with. Recounting a RANDOM SAMPLING of a small fraction of the precincts would be enough to statistically ensure that the voting machines hadn't been tampered with.
Of course, that turns into a different crypto-related problem: who determines which precincts get recounted? Coin flips? Rolled dice? Lottery style ping-pong balls? A poorly-constructed pseudorandom number generator running under Microsoft Excel located on a PC in the offices of the Secretaries of State? We have to be careful, because if the bad guys can predict which precincts will be recounted, they can avoid the tampering in those locations.
Heh, I just thought of a way to accomplish your "certainty of code" -- distributing the voting programs on Knoppix. That's also a good way of ensuring the whole machine (not just the voting application) is open source. Finally, it's the perfect way to get this bill killed by Microsoft, Diebold, Disney, Sony and all the other corporations with absolutely everything to fear from the open source movement.
Well, according to the bill the receipts ARE the vote (at least for purposes of recounting.) So yes, the electronic count is redundant.
I'm not sold on the electronic voting machines at all. Why does the ADHD generation need to see who the next president is going to be by the 6:00 news? There are two months before the candidate will take office, and the reason for those two months are so the ballots can be counted. Sure, this may be a holdover from the horse-and-wagon days, but 24 hours won't make a difference. 48 hours won't make a difference. Even a month won't matter. We'll know by inaugural day, and that's good enough. It sure doesn't have to be done the same day.
The "best" (for my humble opinion of best) way to handle this is to have the printed output sealed under glass. After you make your selections, you press "VOTE". The receipt is printed, and kept under glass but above the ballot box. The voter then reads the actual paper to ensure that the printed words say "GEORGE BUSH" or "JOHN KERRY" or whoever it was they voted for. If it doesn't, they call for the election judge. If it does, they press "MY VOTE IS VALID" and the vote is dropped into the integrally sealed ballot box.
The box system is sealed so the voter cannot "stuff" it with pre-printed ballots. The system gives the voter the opportunity to ensure the paper ballot matches their intent.
An alternate system would be with a "captive journal printer", where the printed output is spooled on a take up reel (old cash register journal tape printers are examples of this.) Your votes are printed, and you can see them scrolling by, but they aren't cut or separated. The drawback to this is less secrecy: anyone watching the booth can count people and figure out that you were the 33rd voter of the day, and the 33rd voter cast a ballot for LaRouche.
With printed receipts, you don't need OCR (and the complexities and costs associated with it.) The ordinary results are counted electronically, transmitted electronically, and the election results are determined electronically, even with paper receipts.
But to ensure the machinery hasn't been tampered with, you still have a percentage of the precincts (I've seen suggestions anywhere from 0.5% to 33%) take the paper receipts and balance them against their reported electronic results. If there's a discrepancy at ANY polling place, then you have to start recounting paper everywhere.
Actually, paper receipts are the heart of integrity. They provide the doublechecks to the electronic record, and when the typical contested election degenerates into "we counted x", "no, we counted y", the paper ballots can be trotted out and physically counted by everyone. And these paper records (probably printed on thermal tape) will be sealed inside the machine. Nobody should be able to tamper with them, and there shouldn't be big discussions about hanging chads or pregnant punches.
Strangely enough, Open Source voting code is far less important to me than the paper ballots themselves. Code correctness is only a small piece of security. First, I personally have no way of seeing into these voting machines to validate that they're running the code they say they're running. Sure, you can show me a printout of "OSVote2008.cpp", but what does that prove? It proves exactly that you have a piece of paper with code on it. It does NOT prove that's the code running inside the machine.
Or what if it is? What if I have totally trusted, verifiable code running in the typical Windows machine? What's to prevent a virus or other piece of malware inside from hijacking that code and switching enough votes from one candidate to the other to help throw the election?
Code isn't the answer. Physical tokens (in this case paper records) backed by judges performing spot checks, is ultimately the only trustable way to count an election.
Slashdot Mirror
And as someone else pointed out, it's not double indemnity, it's double jeopardy. I just haven't drunk enough liquor tonight to make sense yet. :-)
An appellate judge has lots of options. They can look at the evidence themselves and decide that a guilty verdict was unfair (as in this case,) or they can look at the evidence and decide that the lower court failed to take it all into account and demand the case be retried. They can also look at the procedures as well as the people. A sleeping defense lawyer, a drunk judge, a jury foreman who was found to belong to the KKK, any number of things can go wrong at the lower court. The appellate judge has the responsibility and the power to set things straight.
It brings up a good discussion on the power of judges. For example, it's common practice in civil proceedings for the lawyers to go "judge shopping", which is to get their case heard in a jurisdiction that has a judge with a track record of siding with their client. (Criminal procedings typically take place where the crime was committed, and unless there's a public uproar the cases are almost never moved.)
I will say that every time I've been in a courtroom the judges have been universally, absolutely professional. I have never failed to be impressed by a judge's common sense approach. Lawyers will try their slick speeches on juries, defendants will come up with bullshit stories, and the judges I've seen simply have had no tolerance for any shenanigans. "Get to the point, please" has got to be the most commonly spoken phrase in court (except for "I didn't do nuthin', your Honor!")
Personally, I have always thought the 9 years was far too stiff. There are wife beaters, rapists, thugs and murderers that get far lighter sentences, and who deserve far more. Spammers have the ability to make millions of people a tiny bit miserable with their crime. Rapists have the ability to totally destroy a handful of people with their crime. Which is worse? Which is more needful of punishment? In these days of finite prison budgets, imprisoning which one makes society better off? I've even got the analysis -- to anyone who answered "spammer", you're far more selfish than I can even imagine.
With a lockout, your BIOS can ensure that only a "signed OS" will be allowed to boot. Microsoft will sign their OS. But what about Linux? Will only a Red Hat Enterprise signed kernel be able to boot? You'll even need to get your signature issued on a per-computer license. Allowing random people compiling the kernel to "sign their own" will completely defeat the purpose of checking the signature on the kernel in the first place, which is to keep unknown, untrusted software from running on it.
If Treacherous Computing is going to be possible, by definition it must start with an absolutely closed BIOS.
Oh, shoot, that was the previous two-person around-the-world plane that had such droopy wings. Sorry, my error.
One other thing I failed to mention in the previous post: the fully laden wings droop substantially, and I believe they almost drag on the ground when full. It would be extremely difficult (if not impossible) to land a craft in a condition like that without accidentally dragging a wingtip.
Think of this plane as a one-shot deal. Reusability wasn't the goal -- getting around the world was.
Sure, pilot safety is a consideration -- in some emergency situations, the pilot could probably dump the fuel to land safely. In a worst case scenario, he could probably land with full tanks, but as I mentioned before that might not be without substantial risk to the aircraft. It might even be expected that the plane's airframe would fail if it landed full.
And just for more information, track 2 has space for only 40 bytes of numeric data (it's a 4 bit character set that has no alpha capacity.) It has provisions for a country code, but only for cards in a specific format. The country code is to be used primarily to determine and display exchange rates to the cardholder. Currently, most credit cards issued in the United States use anywhere from 29 to 36 of the 40 available bytes. Many European cards use 33 to all 40. And some cards violate the standards, and exceed the maximums. Customers of these banks get turned away by retailers whose driver software refuses to parse these tracks.
Any remaining space not covered by the required fields falls into a "discretionary data" field. This can be anywhere from 0 - 11 digits. Typically banks place a random nonce into the cards to ensure that the stripe could not be created without the card present.
Technically, a specific bank could choose to issue cards that have an ISO language code embedded in their own discretionary data field, and could program their ATMs to respond to their cards. (They could also choose to have their own 0-9 language code, offering ATM services in one of 10 languages.) But any such system would be proprietary, and would not be respected outside of their own private network. That's why people see "Retrieving preferences" messages: the card is looked up first, and the preferences are transmitted back to the ATM. This method can be implemented by any ATM system, and will work regardless of what the issuing bank does on the mag stripes.
Something else to keep in mind is that mag stripes turn over very slowly. That means you cannot just change the stripe format and expect magic to happen overnight. These cards are issued at great expense once every four years or so. I believe it costs somewhere around $2.50 or $3.00 to create and mail a new card. Multiply that by a million card holders, and that's an expense you want to avoid as much as possible.
Finally, keep in mind that all this is based on 1970s era technology, and was developed with a distinctly American bias. Languages and disabilities were not a part of the landscape of the era.
These guys claim to have a good liveness detector in their pad. But they're still $100 dollar pads, not the $1000 ones the FBI uses, which means that they could be that much less secure.
They also described their software as storing and transmitting "a third" of your fingerprint, whatever that means.
When you key your PIN, the PIN pad accepting it will encrypt the PIN along with other transactional information plus its own serial number using a key injected securely by a representative of the issuing bank.
This blob plus the other data is transmitted to an authorizer, where the account is looked up and a local copy of the blob is created. If it matches the incoming blob, it's a go.
The bank almost certainly did not encode your card in the scenario you described above. Encoding is usually done with a machine-fed stripe writer, and is almost never done by hand-swiping the stripe anymore. (The timing is usually better on machine fed devices.) What the bank most likely did was to generate a blob similar to the one I described above for transmission to their authorizing computer, who immediately stored it and activated it for use.
Yes, the original intent of mag stripes was to enable offline transactions. However, bad guys quickly figured out how to read stripes and forge PINs, so everyone went to strictly on-line authorizing in the early 1980s.
According to PayByTouch, the phone number is used as an index to speed fingerprint matching. The PBT computer located at the point of sale device turns the fingerprint data into a hash on the spot prior to sending the request over the network, so the "clear" fingerprint isn't stored or sent anywhere.
I personally thought customers would find "fingerprinting" to be too Big-Brotherish, but many pilot customers preferred the idea of using a fingerprint over carrying a wallet full of credit cards and shopper loyalty cards. But at the time we looked at them, Visa refused to certify them as being as secure as a mag stripe, so the idea died around here.
There are websites that have have huge collections of MIDI. There's everything from TV themes to pop music to automated Mozart minuette generators. Grab one, shove it in your phone and begin annoying people immediately. It's just not that hard. $2.00 seems usurious.
It would be nice if it had strong type safety. It would be nice if full type information was present on every interface. It would be nice if didn't have stupid funky memory management issues. It would be really nice if it didn't have the awful apartment models. It would be nice if it had a lot of things, actually. But what it does have is a pretty simple design, and it scales. It allows for neat extensions. It allows for a slick upgrade path. And even if I think DCOM is the spawn of Satan, the fact that it was possible to implement it after-the-fact with a legacy set of objects is still kind of neat.
The other thing that I like about it is it strictly enforces the "black box" usage of the interfaces (for the most part.) Even though our COM objects are written in C++ and mostly used by C++ applications, we use VB test programs. Why? Partly because some of the objects end up getting used in ASP web pages, but also because we know if we can fully test it with an IDispatch caller, the coders aren't playing "pointer shenanigans" through the interface.
Jeez, listen to me. I sound like a Billy the Gates fanboi, eh? Well, Don Box made me say it!
Anyone else heading over to update their version of flashblock, don't forget to stop your browser and delete your userprofile/chrome/flashblock.jar file before trying to install the new one.
As long as you're using the native interface on an in-process object on the same thread. If you go thru a late binding interface (such as IDispatch in Microsoft's COM for VB) then you get the performance penalties of lookups (which I believe are cached, so it doesn't stay awful.) And if you go across threads in the wrong apartment model, out of process, or, (god-forbid) off-machine via DCOM, then you get to add the very substantial performance hit of marshalling in addition to whatever context switching costs you.
I don't know anything about the internals of XPCOM, or how it's used in Mozilla. But COM itself doesn't necessarily have to suck.
The one feature I wish Flashblock would add is a whitelist. There are some pieces of flash I'd always like to see, such as navigation bars on some sites. The rest of flash, forget it.
Flash is one of the worst things ever to happen to the web. "Look folks, here's another non-standard standard we're going to foist off on you, one complete with its own security holes and annoying behaviors that you (as an end user) can't modify."
One thing I don't want is a barcode indicating my vote. As a human, I have no way of verifying whether a specific code indicates SMITH or JONES. My intent is reflected only by the printed name, and it's my intent that must be counted, not some random-looking pattern of stripes.
A good friend of mine is a Briton, and he tells me the votes there are still done strictly with pencil and paper. However, he's been in the USA for the last eight years. I'm curious to know if that's still true, or have you been stuck with electronic machines, too?
It would be even more true if one of those is running on Linux, while the other runs Windows (or OS X or anything else.) There would be no "leveraging" of hacks or weaknesses between the two, making it even harder.
Again, I'd say that the importance of rapid ballot counting is only of interest to news organizations. The outcome of the election is truly irrelevant to the rest of us until the winner takes office, which is months away. OCR just introduces more machinery and more complexity between my vote and the election results.
Sure, there could be an OCR reader located at the ballot box watched by the election judges. Fine. I just don't think it's necessary when there's already some software that knows how you cast your ballot. The paper is for the recounts, not for the election.
Of course, that turns into a different crypto-related problem: who determines which precincts get recounted? Coin flips? Rolled dice? Lottery style ping-pong balls? A poorly-constructed pseudorandom number generator running under Microsoft Excel located on a PC in the offices of the Secretaries of State? We have to be careful, because if the bad guys can predict which precincts will be recounted, they can avoid the tampering in those locations.
Heh, I just thought of a way to accomplish your "certainty of code" -- distributing the voting programs on Knoppix. That's also a good way of ensuring the whole machine (not just the voting application) is open source. Finally, it's the perfect way to get this bill killed by Microsoft, Diebold, Disney, Sony and all the other corporations with absolutely everything to fear from the open source movement.
I'm not sold on the electronic voting machines at all. Why does the ADHD generation need to see who the next president is going to be by the 6:00 news? There are two months before the candidate will take office, and the reason for those two months are so the ballots can be counted. Sure, this may be a holdover from the horse-and-wagon days, but 24 hours won't make a difference. 48 hours won't make a difference. Even a month won't matter. We'll know by inaugural day, and that's good enough. It sure doesn't have to be done the same day.
The box system is sealed so the voter cannot "stuff" it with pre-printed ballots. The system gives the voter the opportunity to ensure the paper ballot matches their intent.
An alternate system would be with a "captive journal printer", where the printed output is spooled on a take up reel (old cash register journal tape printers are examples of this.) Your votes are printed, and you can see them scrolling by, but they aren't cut or separated. The drawback to this is less secrecy: anyone watching the booth can count people and figure out that you were the 33rd voter of the day, and the 33rd voter cast a ballot for LaRouche.
With printed receipts, you don't need OCR (and the complexities and costs associated with it.) The ordinary results are counted electronically, transmitted electronically, and the election results are determined electronically, even with paper receipts.
But to ensure the machinery hasn't been tampered with, you still have a percentage of the precincts (I've seen suggestions anywhere from 0.5% to 33%) take the paper receipts and balance them against their reported electronic results. If there's a discrepancy at ANY polling place, then you have to start recounting paper everywhere.
Strangely enough, Open Source voting code is far less important to me than the paper ballots themselves. Code correctness is only a small piece of security. First, I personally have no way of seeing into these voting machines to validate that they're running the code they say they're running. Sure, you can show me a printout of "OSVote2008.cpp", but what does that prove? It proves exactly that you have a piece of paper with code on it. It does NOT prove that's the code running inside the machine.
Or what if it is? What if I have totally trusted, verifiable code running in the typical Windows machine? What's to prevent a virus or other piece of malware inside from hijacking that code and switching enough votes from one candidate to the other to help throw the election?
Code isn't the answer. Physical tokens (in this case paper records) backed by judges performing spot checks, is ultimately the only trustable way to count an election.
Heh. I think a friend of mine with Logic Audio just downloaded a "Weird Shit(tm)" module for it... at least that's what it sounds like.