I didn't think there were people confused enough by the "Linux Desktop" debate to imagine that there was a Linux Desktop already.
There is no linux desktop already. It is a work in progress. It is a hobby, like collecting stamps or flying model rockets. Of course, there is a vague possibility that someday, our hobby will result in some engineering or design innovations so harrowing that we will create something an average person would want to use.
That day is far, far away, and nobody you should believe has promised you otherwise.
It doesn't matter if we succeed. It doesn't matter if we fail. It doesn't matter if we are still stuck editing text files 10 years from now (heaven forfend). We are not in it for the money. Everybody loves results, but we would not be doing this if it were just about the results.
Who knows? Maybe in a few years we will all ditch Unix and go work on some other crazy OS metaphor. That would be absolutely fine with me, as long as it is Free as in Speech, the fun never really stops. For someone who seems so finicky today, JWZ has endured and indeed invested his life heavily in what is by far a stunningly ancient and assinine OS design: Unix. Sadly, in my opinion, MacOSX, while a major improvement on Unix, is rather conservative in terms of pushing the envelope to make things faster, easier, and better organized. It may well be the best out there right now; I'm not disputing that. I'm just saying we could do much better than OSX.
You can't get confused between what Linux is and what it represents. If JWZ is the kind of guy who will run into Freedom issues (most good, _self-respecting_ engineers are, but who knows), he will get sick of Apple eventually, when they do something that really twists his nipple ring, and he can't do anything about it but beg and whine. Then he'll remember why everyone is putting all their time into a system that isn't ready yet. But hey, you have to do whatever makes you happy. I know being in the FS/OS world is not for everybody. There are times when trying to live and work with my hobby drives me pretty crazy too.
Just like Gecko got there without him, Linux, or whatever comes after it, will too. And he can be damn proud; he did more work to push it along than most dozens of us.
Re:My experience replacing CRT with LCD
on
Are CRTs History?
·
· Score: 1
Did you really pay $80 for a good 21"?
Just out of curiosity, where?
My experience replacing CRT with LCD
on
Are CRTs History?
·
· Score: 2, Informative
I just replaced an aging but beautiful high-end CRT, and when I started looking, I found high-quality straight-digital (i.e. DVI) LCD screens, 1280x1024 at 19" in size, sporting pixel switch rates of 8ms... For about $350.
All of the reasons to avoid LCDs are evaporating: price, smearing/update speeds, resolution...
End-to-end digital video is startlingly noticeable if you are used to CRTs, even good ones.
Really excellent LCDs are now well within the price range of what I used to pay for premium CRTs.
I don't see myself buying another CRT, pretty much ever.
Actually I like the detail in which you're thinking about it. But I want to improve on your example. Of course, you can patent a hammer and nails (metaphorically speaking) and build a set on stage with the patented tools and royalties got paid and everyone is happy. We use technology in a non-integral way to enable our creative acts all the time.
But on the other hand, the separation is not always so clear. Often the "technology" is inseparable from the creative act. Now we are forced to a calamitous examination of the completely non-existent boundary between the two.
Let me give another analogy. What about a patent on stories where the protagonist kills his mother?
Let me start by saying that "software patents" are prima facie an absurd notion created by judicial fiat, and either the software industry, or the patents, are destined for certain eradication, when someday they finally stop ignoring one another.
But even if we can go past that, in video games more than anywhere else, the line between what's "software technology" and what's "creative" does not exist. The two are exactly identical. In fact video games are the very epitome of software code as art. Having written a lot of it, I can say, in a strictly pragmatic way, that game code is integral to the process in exactly the way the texture art and the voice acting and the score is. This is vastly different from the role the hammer and nail, or even a sophisticated lightboard or some other deus ex machina plays when building the set.
Video games are very similar to movies or books - they are siblings or cousins in the media family.
What if you could patent certain aspects of stories or movies?
The works of Shakespeare are, by and large, based on lesser plays, historical fictions or actual histories. He didn't invent most of his subject matter. He built on what he had.
All creative endeavor builds on existing ideas.
I am still a bit awestruck that people don't have the imagination to see where this kind of patent regime leads, but if we continue with it, we will get a very expensive education in how the creative process works, and we will finally begin to develop a rational understanding of "originality."
If we allow patents to expand their dominion into the arts, places incomprehensibly far afield of where the system was designed to go, we are doing nothing less than allowing layers to systematically destroy the creative process, by choking off its iterative nature.
It's astounding that I live in a world where this kind of thing can even be proposed by an apparently rational adult, let alone where such lunacy gets news coverage.
You're quite right that you can usually clean a system by booting from media you trust and using it to wipe the non-volatile storage. And you have anticipated that I would propose a theoretical attack that reflashes the BIOS and subverts that cleanup strategy. What you have forgotten is that you not only must reflash the BIOS, but you must extract it and reflash it with external hardware, since a BIOS could intercept attempts to overwrite itself by a boot-reflash code run on the compromised machine, even if that utility didn't rely on BIOS routines to rewrite the flash (i.e. by scanning and patching machine code on load).
Well now we've really gone around the bend, but that was one of the points - to illustrate the incredible complexity of the problem.
you are confusing the difficulty of cleaning a general use system against one with a single purpose.
No, I quite agree - it's easier to clean a single purpose system.
Optical scan and OCR are the same thing
Well, to be pedantic, if the user does not make a character, and the computer does not recognize characters, it is not exactly "optical character recognition." Although I think I see what you are getting at now. You are thinking further ahead to an attack on the recount.
Interestingly, you seem to be thinking about a recount process done by machines on the paper records, whereas I was thinking of people-and-paper processes.
In both scenarios you did not list the final tally. Voter verfication is all fine and good but it dosn't mean squat till the vote enters the final count.
Correct. My concern is with insuring that it is possible to detect a failure to count correctly.
The former is a lead parachute if there does not exist a way to count the paper receipts.
A skillful argument. My answer is that best-practices paper counting procedures are, I believe, better than you suggest - to the point that they are "good enough." And I'll elaborate on that in a minute.
Ultimately you present a fascinating dillemma: do we trust computers or people? Computers are hypothetically capable of counting flawlessly, but we are unable to meaningfully verify that they are doing so. Yes, this is really true. it sounds absurd to the layman, but I assure you, this is indeed where we have arrived at, and quite conclusively. People-and-paper processes (where your technology stops at a calculator), on the other hand, while far more verifiable, are prone to simple human error. Fortunately, it is not as bad as 5%.
That number, 5%, is something you made up, but you can study this in a lab, and people have. So we can certainly get into looking at the nuts and bolts of that. But let me proceed, provisionally, a little further.
Our laws on the matter are crystal clear (despite some creative suggestions to the contrary during the 2000 debacle): we trust people.
To put it another way, we cannot separate the accuracy issue from the verifiability issue, and as a result it looks like the computer is faster but *less reliable*. When we have reason to doubt it (i.e. call for a recount), we call in the people, who while they are not computers, can use counting processes which are extremely trustworthy. The end result is to reduce any potential gain from attempting to tamper with an electronic election system to well below the "risk-reward" threshold.
To me that is like someone wondering why you would ever try to replace the horse.
I grant you, we should always be thinking of a better way to do anything, and it's fair enough to keep looking for success where others have only found failure. I want to be clear - I don't want to discourage you or anyone else who is thinking of better ways to do this. But there are certain bedrock facts and physical laws involved.
Am I trying to hold on to the horse when the car is looming? Or is it a better metaphor to say I am discouraging any further attempts to fly to the moon by strapping on w
I appreciate the source, and I agree that the discussion of rootkit detection is very good. One reason I can say this is because they are very up-front about the limitations of their tool. More directly, they categorically agree that real penetration detection cannot be done from the penetrated machine.
"Can a Rootkit hide from RootkitRevealer? It is theoretically possible for a rootkit to hide from RootkitRevealer..." They go on, "Is there a sure-fire way to know of a rootkit's presence? In general, not from within a running system."
And they explain that they are only detecting certain flawed and incomplete rootkits - those that A) rely on a particular strategy for bootstrapping themselves, and B) patch some system calls to hide themselves, and not others. Thus, this detection tool is, while an excellent exercise, worse than useless in practice, since it will not detect the first rootkit to get it right, or any thereafter, but it will give you a false sense of security.
As we have both said, cleaning yourself from the inside of a compromised active kernel is impossible, but this dosn't mean you need another system in order to get 'outside'.
Actually, I agree on the first part, but I'm still a little fuzzy on the second part.
And if you have the power over the plug you have ultimate power over what controls the beast and at that point you just have to be able to verify your system... or wipe it.
The ability to unplug your system is far, far from the ability to verify it. Or perhaps I misunderstand what you are getting at.
With additional fully separate systems that you trust, you can do verification. But now you have to wonder why you trust your verification systems and not what you are verifying. It's a recursive problem.
I hate to say it, but the problem of verification looks just as ugly as ever.
Let's go back and recap some of Sheepdot's contributions here:
On the issues raised in my initial post: "Security has very little to do with it." (Make of it what you will)
"...every argument with regard to security in a computer-aided voting system also exists in a paper system."
It's just as easy to rewrite the electronic records of votes as it is to alter or forge paper results. (i.e. no understanding of recounts, electronic versus paper forensics)
"Anyone can download and print fake ballots." Yes, that's right, on "fakeballots.com." I hear we have the same problem with the U.S. Dollar.
"I saw a video of a monkey deleting votes." Please, post a link to the video!:D
"A monkey could just as easily shit all over paper ballots if you gave him access." But I heard that monkey shit might not be valid in some Florida counties.
Tampering with voting machines would be hampered by the use of Tripwire
Spectacularly doesn't understand how Tripwire could be defeated - an astounding problem for someone who works in "IT Security." Like someone who claims to be an expert on Shakespeare, who then laughs and mocks people for suggesting that "Hamlet dies at the end."
"the law [emph. added] dictates they have no less than two copies, one hardcoded to a media that cannot be altered (like cd)" Yup, uhuh.
Running the same routine that hashed or signed voting data would be more difficult the second time around.
"I personally know people who have voted more than once in counties that I have lived in..."
"No one will ever see those papers, and they'll be destroyed before anyone has." Hahahaha. Even when you have paper, you just won't look at it. Brilliant riposte!
"You'll be hard pressed to find a single instance where a vote was changed by a 'hacker'." (Is that a good thing or a bad thing? LOL)
To this you have added:
Electronic security is not all that costly, and can be implemented easily.
Tripwire *is* sufficient.
There are just as many individuals that could break into a courthouse, muck with a paper voting system, and walk out without setting off an alarm as there are individuals making rootkits. (Possibly even more. LOL)
Electronic storage of votes is not inherently riskier
Voting machine compromises must occur through the disk drive, cd drive, or usb port.
Just because a lot of people vote my writing down, doesn't mean I'm not smarter than all of them.
This somehow involves Kerry, or Bush, or an existing election conspiracy.
I think my work here is done.:)
So, Sheepdot, you work in the "IT Security Field" and you make a salary? I'm well aware people like you get work all the time. Just hope you're not working for me, "Sheepdot."
Hey, where have you been working lately? Who hires experts who spout gems like "electronic security is not all that costly, and can be implemented easily"?
You weren't at Choicepoint, were you? Or Lexus? Or Diebold? Or Microsoft? Did you set them up with Kaspersky Antivirus?
Your thesis is shown to be conclusively wrong by a unanimity of experts in the field ("your field"), your knowledge of even basic features of the security landscape is calamitous, and your method of arguing is absurd.
In short, you are a whiny, ignorant baby.
Welcome to the filter. Here, the last word is yours. Go on, use it to further embarrass yourself:
Clean ROM programs loaded instead of from system storage...
Think about it... what loads these "clean" programs? Or even if you map the ROM directly nito the physical address space, what runs them? The system you didn't trust, that you're trying to verify.
The problem is that once I have control of the computer I have control of the program counter. I will just never let it into your "clean code."
Thinking further ahead you might create some kind of unmaskeable hardware interrupt, like a watchdog, that I couldn't block, that would kick off your security code at various intervals. No systems like this currently exist, and if they did they would be extraordinarily impractical. If the clean code relies on any part of the untrusted code, it no longer works. So your ROM must have its own kernel, its own drivers, you name it. And every software change is a ROM upgrade. But it's an interesting avenue. Well, I think when you get to the logical conclusion it ends up just looking like building a redundant extra computer into your computer to do the verification.
Once again, though, even if you do all this, it's just more expensive, complicated, and less reliable than paper. Now you are worrying if someone compromised your "clean" code before it was burned to ROM. Remember, the clean code is just as capable as anything of taking over the whole machine. Or maybe someone compromised the computers of any of the people who wrote the clean code. Or any of the other computers on networks with those computers. Or any of the tools they used to build it. Etc. Etc. Why go to all this incredible trouble just to trust something you don't have to trust?
For the printout I was suggesting that the printer creates a small 'error' if you will. Perhaps something that looks like spurious ink, perhaps it just alters a barcode (if utilized) Perhaps it uses a differnt font for the letter o that is is essentially unnoticeable to the eye but which signals the OCR software to interpret differently. Devious Enough ? If someone were then silly enough to add something like a test or calibration flag the ocr software could detect then it could then act nice when in 'testing/calibration' mode. Would make it one hell of a gremlin to chase down.
No barcodes would be used in this system. There is no OCR of any kind. Everything would be human readable. So there is really no avenue for this kind of attack.
The only additional wrinkle is for optical scan, which looks for the user's having filled in an oval. This comes back to the original line of reasoning which you have not been able to breach yet, which is that it doesn't matter what the computer does as long as there is a verifiable paper trail. If the computer tries to cheat, it will get caught.
Taking away the voter-verified paper from these systems only makes it vastly easier for the cheating computer not to get caught.
The power of an audit is undeniable and I have never said you don't need one.
I never meant to suggest you said so. Only that meaningful audits are effectively impossible.
I am saying there is probably a better solution. Rome werent built in a day and finding a digital alternative to a technology that has 3000 some odd years of improvements might take a while.
There we are in perfect agreement.
Here is the process of counting an OCR printout. Mark digitally, turn into an analog printout, read analog printout to creat a digital mark in order to tally the vote. To count by hand you mark digitally to creat an analog print out to count by hand.
Actually, I don't know if your process is right.
For verified receipts:
1) User votes on-screen 2) Receipt is printed 3) User verifies and accepts receipt
For optical scan:
1) Ballots are mass-produced 2) User marks ballot 3) Ballot is scanned 4) User verifies and accepts scan results on-screen.
There's no analog-to-digital conversion in the form
Listen to the low-karma slashdot troll Sheepdot. Sure, he says a lot of obviously wrong things and gets called out on it, and whenever he does he refuses to justify himself and just insults the people who catch him. This is a sure sign of a truly powerful security and voting systems expert.
I mean, what does Bruce Schneier know? The world comes to slashdot trolls for its opinions, after all.
How can anyone fail to sense your hidden genius in your appreciation for half-baked security tools that have a history of failure traceable as far back as Phrack articles from 1993.
Yes, ladies and gentlemen, only on slashdot can a whiny, obnoxious, ignorant baby like Sheepdot treat experts like assholes and still get a free education in return:
-- "More recently, other implementations of LKMs for hiding processes, files, and directories have come about that can get around the above described methods of defeating standard root kits, as well as cryptographic checksumming programs like "tripwire" that must trust the operating system to present them with valid bits from disc and memory.
The Hacker's Choice (THC) from Germany has write-ups on loadable kernel modules for Linux, FreeBSD, and Solaris, which describe this methods of hiding out on a rooted box:
Using methods such as these, integrity checking programs like "tripwire" and NIPC's "find_ddos" programs can be subverted, as the kernel could not even be trusted to give correct results when searching process tables, network structures, or file systems.
You might think that simply disabling LKM support in the kernel -- which is still a good idea to improve security on a server whose configuration will be stable -- is the final answer. Not exactly.
Another method of inserting code into running kernels -- even if LKM support is not present -- is described by Silvio Cesare:
I was waiting for you to kick in with some kind of fact, but I guess if you don't give any more you can't get caught being an idiot again.
So you're too afraid to even fake another post, eh?
You care about "uncovering the truth" by saying a bunch of obvious nonsense, getting busted, then refusing to justify any of your arguments and slinging insults. Well, I think we've adequately demonstrated today not only the flaws with paperless voting systems, but also the flaws in the back-of-the-class kids who need a hobby bad enough to act as apologists for them.
Oh, you'll do great convincing all those people who know nothing about the discipline and are wowed by childish bluster.
All this hasn't changed your mind? Well, I tried my best.
I feel obligated to advise you that your opinions conflict with those of almost all of the experts who have considered the problem - people much smarter than you and me who have spent their lives focused on these issues. To give you an idea of the caliber of people you're taking on, here's Schneier. So don't just take my word for it.
When discussing rootkit detection, we should be careful not to confuse on-line and off-line detection. Off-line detection (done with a separate machine you believe you trust) can make use of checksums or comparisons as you describe. All I am saying is that on-line detection (the machine inspecting itself) is impossible - because a compromised host can return the "correct" data to its own detection routines. Indeed, any "normal" state can be simulated.
hmmm, I'll be as paranoid as you for a second and claim an essentially undetectable alteration to the printout (via human means) that means the vote is registered in the OCR software differntly than what it 'says';-)
I'm intrigued but I don't understand you. How do you propose this would work?
But in most systems right now if the hand recount and machine recount were seriously out of whack it would just invalidate the election.
That's "just" the exact, ideal behavior! The most you can hope for from any other system, paperless, etc. is that it do as well.
I'd feel even better if there were some way of validating the printed ballot in the presence of the voter (no poor print job etc...).
That's exactly what I'm already proposing. The voter does validate it. If the paper doesn't clearly match their intentions (or, for an optical scan, isn't being read properly by the machine) then they signal to the election workers, etc. etc.
They are easy to invalidate (punch a few extra holes, make extra marks),
No, they are not.
For destruction, if you bought 500 sheets of paper, and you end up with 400, you discovered fraud and invalidate the election.
For other forms of invalidation, optical scans that won't scan properly must be redone by the voter to "count," and verified receipts are generated by machine and only exposed to the voter behind glass, so they're basically guaranteed to be valid. If a machine itself generated invalid ones the voters would catch it instantly.
You don't trust code cause you don't trust people.
I don't trust code because its a game that allows untrustworthy people to win vastly more easily. That's really all.
A paperless code based system has the potential to remove people from everything except making the code and inputing the votes.
I have to confess, I have no idea what you mean by this. How can paperless possibly accomplish this? It does not reduce any fallible human involvement, only add vast new amounts of it. Well, maybe I have misunderstood you.
At the end of the day, I think you have to build frameworks that allow people to trust each other, because they make it easy to catch someone breaking the rules.
You're very kind. We always get more out of this place if we come here to learn, rather than to argue.
I didn't feel I had to detail why a paperless system is CAPABLE of counting votes better than paper ballot counting systems.
No, certainly not. But the interesting question is not whether it is capable of it in a theoretical perfect world, but how it actually works in the real world, where, as we know, all the problems I mentioned come in to play, and electronic systems are never as perfect as we would like.
Regardless, at the end of the day we can create a system that has every advantage modern computing can give it, yet is as reliable and secure as paper-based systems, simply by giving it a paper trail in the way that I've layed out.
Detecting a rooted system is hard from the rooted system but not impossible.
I beg to differ. Such on-line detection is indeed impossible, if the compromise is written well enough. In fact, I would go so far as to say you likely cannot design a system where an on-line undetectable exploit could not be written.
Moreover, even if you know you are compromised, you are not really able to say with much certainty to what extent.
This is critically important, and it is why the industry standard procedure for suspected compromise is to shut the machine down, study it if you like, but regardless, wipe it, and reinstall from scratch. It is also why there is no industry standard for determining, on-line, if you are compromised in the first place.
As for thinking I wouldn't go to such lengths ??? Poor assumption on your part though in general I know what you mean.
Fair enough. Of course, anyone can wipe their own machine - daily if they feel the need. They have to trust the tools they are using to do that, of course...
The point is, trusting the software is impossible. It's a black hole. It will suck you into myriad cat-and-mouse complexities and very quickly it is obvious you will never escape. You will never trust the code, and to even get close you are spending mountains of cash and moving heaven and earth to do it.
The good news is that you don't need to as long as there are paper records. Does it have to be paper in particular? No, just anything with this unique set of properties. We can certainly invent something better if we want, and we will know it when we see it.
Regarding printouts: If your fear is manipluation of code, and code is responsible for a printout, then the printout is suspect.
Definitely not! This detail is critical!
If it's an optical scan ballot, the contents of the paper are created by the voter - hence, not alterable by computer, period. The voter then reads the screen to insure the computer read the ballot properly. Of course, the computer can lie, but it will get caught.
If it's a receipt-based system, the user votes on the screen, and then reviews the receipt under glass to insure it says the right thing.
This is why they call it a "voter-verified paper trail."
Paper is easily forged and easily destroyed.
Actually, forging paper is quite difficult to do effectively, and as I pointed out, you can destroy it, but you then have to account for it later.
You and your experts have a very high standard. If a similar level were applied to a paper system I feel it would also fail.
I don't think you can say this without devising a convincing attack on the voter-verified paper-backed system.
Obviously these are just positions on a continuum of cost and difficulty and risk. But the two approaches (paper versus paperless) are not even remotely close on this continuum, and in addition, to the best of my understanding, the difficulty of conspiracy against the paper-backed system is great enough as to be substantially impractical even for the size of an investment that might be justified to gain "leadership of the free world."
I just deleted the really obnoxious phrase that I originally started this post with.
Basically everything you have said so far has been outrageously wrong. In addition, you've been rude about it, so I have trouble feeling any sympathy for you, either.
But in the end I do feel sorry for you, and it's never too late to learn something, so put the attitude away and follow along. No harm done if I don't convince you, but be careful, you are in danger of expanding your knowledge...
Apparently you have never heard of Tripwire
Tripwire will never raise any alarms if no checksums ever change.
The system is easily fooled by common rootkits that patch the kernel to modify the results of certain system calls, for instance read(), to conceal their own presence at the kernel level.
Process tables and memory are commonly rigged the same way.
This is only a slightly fancier trick than just patching and disabling Tripwire itself, which is what simpler systems used to do.
You speak with a lot of confidence for someone who doesn't appear to know about this concept, which has been around in the field for over a decade. Anyway, it's actually a pretty neat trick, and a lot of fun the first time you do it, especially once you think about the impllications.
Think about it. You could be compromised right now, as you read this. And you won't check, because of the outrageous expense and time involved (disconnecting your HD, taking it to another machine, inspecting it byte by byte... becuase pattern matchers don't work for custom code). You'll tell yourself it's unnecessary because, who would do that to you? (The answer is, a spammer, but no matter). The real question is, who would do that to a voting machine? And we both know the answer to that. I hope.
We'll ignore the fact that the law dictates they have no less than two copies, one hardcoded to a media that cannot be altered (like cd).
Really? So the voting machines we're discussing... they store votes on two forms of media, one that cannot be altered? How novel.
The fact that you can appreciate the need for write-once media already puts you ahead of Diebold and their like, who do not, as far as I know, use such techniques - not that they matter. It makes me wonder if you are imagining this law or if they simply break it. Neither would surprise me.
What's positive about this is that at least you are only a short jump away from acknowledging the advantages of the most mature, durable, secure, and simple write-once media known to humankind, paper, where (unlike the preposterous concept of using CDs) the user can verify what was written on the spot, in the booth.
Don't worry that they have the CDs/DVDs to fall back on, you're right, the data was changed and no one really noticed.
Unfortunately not everyone is as shockingly bad as you are at this.
The voting machine software was compromised before it is ever rolled out to the polling place. The votes are not changed after the fact, they are never recorded properly in the first place.
Because your system had no voter-verified paper trail, no one can tell what the machine is actually recording, whether it records (or does not record) the wrong vote once, or twice, or 50 times redundantly.
With paper, the vote is recorded on disk, but also on the paper, and the voter verifies that the paper is correct as they vote.
This is impossible to rig, whether you compromise the software or not. So for this simple design, you have eliminated an entire class of risk, which is good, because the risk was astoundingly huge and you had no credible way to mitigate it.
John breaks into the courthouse. It wasn't difficult, because he got the key from a janitor two months before and duplicated it. He walks over to where the stack of papers from his precinct is and loads up on fake ballots, which he obtained the night before when he was helping with the vote (they actually ple
It might be helpful if you were more specific about what you thought the problems with paper balloting were. If accuracy is your only gripe, remember that if a computer counts more accurately, it also has unreliable analog input devices (i.e. touch screens that lose their calibration), system crashes, data corruption, and the list goes on. It is by no means a given that your system will be better.
Further, it seems you are confused about the distinction between paperless and electronic. I have no problem with eletronic. However, at the same time, paperless is indefensible. Optical scan, for instance, is fine with me, and there are a few other paper-backed electronic approaches that are equivalent in security. These combine all the advantages of computers with the security of a truly secure write-once media (paper).
Indeed, these are the approaches advocated by virtually all the credible experts.
By the way, you make a blanket defense of technology in a fallacious way. You may as well argue that, because computers do a great job tracking your bank balance that they should do just as good a job driving your car. Because computers are good for any set of applications does not automatically make them good for another one, and you must always argue on the merits alone.
Do people with rootkits get caught? You are quite right, they do.
However, how many of them get caught, versus how many don't? Much harder question to answer, isn't it.
The fact of the matter is, your computer could be compromised right now as you read this, and you would have no idea. The only way you would know it is if you attached your hard drive to another computer and did an analysis. And by the way, anything custom isn't going to show up in some pattern matching engine like an antivirus app. You have to disassemble your system byte by byte.
Yet you will not do this analysis. Your justification (not particularly good) will be that no one wants to compromise your computer. (Not true; spamemrs and others do compromise millions of hosts automatically, and may already have compromised yours.) Now imagine the incentive to rig an election in the most powerful nation in the world.
People kill each other over miniscule sums of money. Political power in america is worth many billions of dollars to unscrupulous winners. Your system must be designed against attacks with that enormous level of incentive in mind.
You have suggested that it is difficult to tamper with voting machine software (sealed, onsite etc) but not gotten very specific. What you have done is state the case backwards: by abandoning paper for a paperless system, you have introduced a major new vulnerability: the software can be tampered with. You may take safeguards to prevent it. Those kinds of safeguards taken by, for instance, major, wealthy, sophisticated players with a lot to lose, like Lexis, or Choicepoint, or the U.S. military - all of which, by the way, have suffered major, staggering compromises recently.
The likely case, though, is much simpler than some elaborate mission impossible scheme. Someone involved in the handling of the machines takes a bribe. Now, you can't bribe any of the paper handlers without bribing all of them, because breaking the security of the paper trail requires physical activites that are checked by physical security. If a Republican and a Democrat and a policeman and an election worker all guard the box, you have to bribe them all to destroy it.
Not so for software. Anyone in the chain of vendors and officials who have access to the software can collude, and none of the others would ever know.
It's that simple.
Your applying a double standard if you think a paper trail generated from an electronicly generated transfer process (printouts) counts. Those can be manipulated as well.
This is an absolutely false statement, verging on incoherent.
How on earth do I make a computer unprint something? How do I make it change something
Not even my post, apparently. This has nothing to do with speculation. This is elementary fact.
Paperless systems work with media where bits can have their state changed without anyone being able to tell afterwards what the original state was. More amusingly, this tampering can also be done in a variety of ways that are difficult verging on impossible to detect.
Paper systems work with media that, for all practical purposes, cannot be altered in an undetectable way. Nor can they be destroyed without detection if even the most rudimentary security procedures are followed. Nor can paper be affected without immediate physical presence.
Anyone can rewrite an electronic log. That's why the military and banks, among others who care, have been sending their syslog to line printers for decades... because even high school freshmen know to alter the log when they compromise a system.
No one is worshipping anything. This is a simple matter to be resolved with black letter facts. And you are startlingly wrong on almost every single point you have made.
You seem to think verifiable marks can only be a physical hole, or ink mark on a piece of paper. They can just as easily be colored pixels on a display. Obviously malfeasence in the code can render this useless. IE display one thing and register another in the final count. The same problem exists with paper ballots.
No; if I tamper even in the most trivial ways with your flash memory or hard drives, you will never know it. There is very little chance even the most expert forensic analysis can tell you.
Tampering with paper, on the other hand, is almost impossible. A forensic analysis will catch you; the technology is ancient and well established, in use already by the U.S. government, banks, etc. They do it every single day, to handle counterfeit currency, forged or altered checks, you name it...
Back to your paperless system, I could also tamper with its counting mechanism. There would be no evidence at all unless my malicious is so smashingly amateurish as to not erase itself when it is complete. There is absolutely no system you can design that can prevent undetectable malicious code; indeed, no such system has yet been designed by man.
Now, back to paper ballots. The only way to safely tamper with paper ballot counting is to destroy ballots. Now, this is exactly what our current system is geared to preventing. Observers from all (i.e. both) parties observe polling, transport, and counting of the ballot box. Anyone attempting to destroy even a single ballot would have an insurmountable challenge; let alone attempting to destroy hundreds of thousands from thousands of different polling places.
I can rig your paperless election right under the noses of these observers, and I don't need to lift a finger further than the keyboard. I don't even need the collusion of the "voting systems manufacturer" (a concept that doesn't exist with paper ballots, so its an entirely new risk your paperless systems introduce).
Your paperless electronic system runs contrary to every design principle of secure systems. No one builds machines like this even just to handle money, let alone a powerful nation's leadership. Nevada was in the embarrassing position of having to turn away from paperless systems because the state's gaming board had vastly stronger security standards already in place for slot machines (yes, even they are required to maintain paper records interally).
Why?
Because what your paperless electronic system does, in effect, is create a way for me to sneak in at the speed of light, destory or alter ballots in a way that will be completely undetectable, right under the noses of these observers, and conceal the fact that I was ever there in an almost foolproof manner.
It is impossible to have a recount in this system, because there is nothing to recount. There is no redundancy.
Swap ballot boxes for stuffed boxes, etc.
Try it. I'm serious, next time you vote, go check out the polling place. Ask one of the poll workers if someone could "swap the box." They will explain everything.
Government by election is ultimately an issue of trust.
And government trust is based on government actions. And if government actions involve violating bedrock security procedures without any plausible justification to put an inexplicably insecure new voting system in place, at great expense and taking great pains to stifle complaints by the (large, organized) community of concerned citizens... then there is no longer any trust in the government or the fairness of elections, and all that that entails.
As long as these paperless systems are in place, in a close election if there is a disputed result there is no more process. There is only theater. And when the ABC anchorman points his microphone at the "Voting Systems Experts"
Have you read any of the important material on the issue? There are lengthy, well-written position papers from ivy league experts, as well as excellent materials compiled by verifiable voting advocacy groups that are more accessible to the layman. The need for paper is well established enough to be called bedrock, and indeed it is absolutely incontrovertible.
Many, many, many, many others have already explained this in great detail and better than I probably could, but in brief:
Paper creates forensic evidence. If I commit fraud with a paper system I have to destroy the paper, which is itself evidence of fraud.
Paperless electronic (or for that matter, mechanical) systems create very little if any forensic evidence of tampering.
Doesn't it strike you as absolutely breathtaking that (in America) machines like this could even exist?
Paperless designs violate absolutely basic, shockingly obvious, bedrock principles of security. There is a problem simply because I often don't have the vocabulary or metaphors to express to a disinterested layman how wrong a paperless voting machine is. It's like building a bank vault to hold the most valuable thing in the entire world, and refusing to include a lock for the door.
I frankly do not care if the study didn't show malfeasance _or_ some esoteric demographic effect this time. These machines need to go. And all the people who built them, approved them, and paid for them, need to be investigated.
It's essentially why this sounds like scare mongering to me.
I take these finer points about the GPL to be good things.
"Acquiring" an open source project and "orphaning" free code are just inappropriate adjectives for the everyday, ordinary activities of developers coming and going from a FS/OS project.
Add to this, as you point out, the difficulty of developing a consensus among copyright owners and although the article is basically correct, this journalist is starting to sound especially desperate to be "controvertial."
At the end of the day, there will always be problems the market will solve that the FS/OS community can't or won't. Both models are here to stay, and the two have an interaction that is (taking a longer view) basically healthy, in no small part because of the generally good design of the GPL.
As I predicted, you were unable to answer my questions.
Instead, you basically said, "hey there may be problems with other kinds of patents too."
Patenting software is distinct from patenting other kinds of inventions, and we can get into why that is if you like. The exercise is rhetorical, however I will be happy to indulge you.
If you cannot make the system work, it frankly doesn't matter whether you should try.
You only said, "you do the research."
How do you do the research, stubear?
Do you really believe "the research" is something that could possibly be accomplished by human beings, on a human timescale? There are hundreds of thousands of these patents already. There more daily.
You cannot even devise a scheme for just keeping up with NEW patents that is within orders of magnitude of being economically feasable for ANY form of software development.
You can't wave your hands and say "search capabilities." What type of search capabilities can reliably correlate source code with patents? None are known to human-kind, nor are there likely to in our lifetimes barring some harrowing advance in the field of artificial intelligence. Such an advance, I might add, will only be possible through (yet again) our collectively ignoring and violating tens of thousands of software patents.
How on earth can this preposterous state of affairs not immediately require us to turn back towards sanity?
How many patents did you violate in order to write it?
How do you know?
How can ANYONE possibly EVER know?
And even if by some miracle you did know today, how will you know tomorrow, when another 1,000 patents have been granted?
You have no answer to these questions. I know that in advance, because these questions are impossible to answer.
It amazes me that anyone is still confused about this.
Software patents are a ridiculous, unworkable farce. The only reason they "work" today is that they are almost universally ignored, even (or especially) by their supposed proponents.
Slashdot Mirror
I didn't think there were people confused enough by the "Linux Desktop" debate to imagine that there was a Linux Desktop already.
There is no linux desktop already. It is a work in progress. It is a hobby, like collecting stamps or flying model rockets. Of course, there is a vague possibility that someday, our hobby will result in some engineering or design innovations so harrowing that we will create something an average person would want to use.
That day is far, far away, and nobody you should believe has promised you otherwise.
It doesn't matter if we succeed. It doesn't matter if we fail. It doesn't matter if we are still stuck editing text files 10 years from now (heaven forfend). We are not in it for the money. Everybody loves results, but we would not be doing this if it were just about the results.
Who knows? Maybe in a few years we will all ditch Unix and go work on some other crazy OS metaphor. That would be absolutely fine with me, as long as it is Free as in Speech, the fun never really stops. For someone who seems so finicky today, JWZ has endured and indeed invested his life heavily in what is by far a stunningly ancient and assinine OS design: Unix. Sadly, in my opinion, MacOSX, while a major improvement on Unix, is rather conservative in terms of pushing the envelope to make things faster, easier, and better organized. It may well be the best out there right now; I'm not disputing that. I'm just saying we could do much better than OSX.
You can't get confused between what Linux is and what it represents. If JWZ is the kind of guy who will run into Freedom issues (most good, _self-respecting_ engineers are, but who knows), he will get sick of Apple eventually, when they do something that really twists his nipple ring, and he can't do anything about it but beg and whine. Then he'll remember why everyone is putting all their time into a system that isn't ready yet. But hey, you have to do whatever makes you happy. I know being in the FS/OS world is not for everybody. There are times when trying to live and work with my hobby drives me pretty crazy too.
Just like Gecko got there without him, Linux, or whatever comes after it, will too. And he can be damn proud; he did more work to push it along than most dozens of us.
Did you really pay $80 for a good 21"?
Just out of curiosity, where?
I just replaced an aging but beautiful high-end CRT, and when I started looking, I found high-quality straight-digital (i.e. DVI) LCD screens, 1280x1024 at 19" in size, sporting pixel switch rates of 8ms... For about $350.
All of the reasons to avoid LCDs are evaporating: price, smearing/update speeds, resolution...
End-to-end digital video is startlingly noticeable if you are used to CRTs, even good ones.
Really excellent LCDs are now well within the price range of what I used to pay for premium CRTs.
I don't see myself buying another CRT, pretty much ever.
Actually I like the detail in which you're thinking about it. But I want to improve on your example. Of course, you can patent a hammer and nails (metaphorically speaking) and build a set on stage with the patented tools and royalties got paid and everyone is happy. We use technology in a non-integral way to enable our creative acts all the time.
But on the other hand, the separation is not always so clear. Often the "technology" is inseparable from the creative act. Now we are forced to a calamitous examination of the completely non-existent boundary between the two.
Let me give another analogy. What about a patent on stories where the protagonist kills his mother?
Let me start by saying that "software patents" are prima facie an absurd notion created by judicial fiat, and either the software industry, or the patents, are destined for certain eradication, when someday they finally stop ignoring one another.
But even if we can go past that, in video games more than anywhere else, the line between what's "software technology" and what's "creative" does not exist. The two are exactly identical. In fact video games are the very epitome of software code as art. Having written a lot of it, I can say, in a strictly pragmatic way, that game code is integral to the process in exactly the way the texture art and the voice acting and the score is. This is vastly different from the role the hammer and nail, or even a sophisticated lightboard or some other deus ex machina plays when building the set.
The best way to tackle this is with a metaphor.
Video games are very similar to movies or books - they are siblings or cousins in the media family.
What if you could patent certain aspects of stories or movies?
The works of Shakespeare are, by and large, based on lesser plays, historical fictions or actual histories. He didn't invent most of his subject matter. He built on what he had.
All creative endeavor builds on existing ideas.
I am still a bit awestruck that people don't have the imagination to see where this kind of patent regime leads, but if we continue with it, we will get a very expensive education in how the creative process works, and we will finally begin to develop a rational understanding of "originality."
If we allow patents to expand their dominion into the arts, places incomprehensibly far afield of where the system was designed to go, we are doing nothing less than allowing layers to systematically destroy the creative process, by choking off its iterative nature.
It's astounding that I live in a world where this kind of thing can even be proposed by an apparently rational adult, let alone where such lunacy gets news coverage.
You're quite right that you can usually clean a system by booting from media you trust and using it to wipe the non-volatile storage. And you have anticipated that I would propose a theoretical attack that reflashes the BIOS and subverts that cleanup strategy. What you have forgotten is that you not only must reflash the BIOS, but you must extract it and reflash it with external hardware, since a BIOS could intercept attempts to overwrite itself by a boot-reflash code run on the compromised machine, even if that utility didn't rely on BIOS routines to rewrite the flash (i.e. by scanning and patching machine code on load).
Well now we've really gone around the bend, but that was one of the points - to illustrate the incredible complexity of the problem.
you are confusing the difficulty of cleaning a general use system against one with a single purpose.
No, I quite agree - it's easier to clean a single purpose system.
Optical scan and OCR are the same thing
Well, to be pedantic, if the user does not make a character, and the computer does not recognize characters, it is not exactly "optical character recognition." Although I think I see what you are getting at now. You are thinking further ahead to an attack on the recount.
Interestingly, you seem to be thinking about a recount process done by machines on the paper records, whereas I was thinking of people-and-paper processes.
In both scenarios you did not list the final tally. Voter verfication is all fine and good but it dosn't mean squat till the vote enters the final count.
Correct. My concern is with insuring that it is possible to detect a failure to count correctly.
The former is a lead parachute if there does not exist a way to count the paper receipts.
A skillful argument. My answer is that best-practices paper counting procedures are, I believe, better than you suggest - to the point that they are "good enough." And I'll elaborate on that in a minute.
Ultimately you present a fascinating dillemma: do we trust computers or people? Computers are hypothetically capable of counting flawlessly, but we are unable to meaningfully verify that they are doing so. Yes, this is really true. it sounds absurd to the layman, but I assure you, this is indeed where we have arrived at, and quite conclusively. People-and-paper processes (where your technology stops at a calculator), on the other hand, while far more verifiable, are prone to simple human error. Fortunately, it is not as bad as 5%.
That number, 5%, is something you made up, but you can study this in a lab, and people have. So we can certainly get into looking at the nuts and bolts of that. But let me proceed, provisionally, a little further.
Our laws on the matter are crystal clear (despite some creative suggestions to the contrary during the 2000 debacle): we trust people.
To put it another way, we cannot separate the accuracy issue from the verifiability issue, and as a result it looks like the computer is faster but *less reliable*. When we have reason to doubt it (i.e. call for a recount), we call in the people, who while they are not computers, can use counting processes which are extremely trustworthy. The end result is to reduce any potential gain from attempting to tamper with an electronic election system to well below the "risk-reward" threshold.
To me that is like someone wondering why you would ever try to replace the horse.
I grant you, we should always be thinking of a better way to do anything, and it's fair enough to keep looking for success where others have only found failure. I want to be clear - I don't want to discourage you or anyone else who is thinking of better ways to do this. But there are certain bedrock facts and physical laws involved.
Am I trying to hold on to the horse when the car is looming? Or is it a better metaphor to say I am discouraging any further attempts to fly to the moon by strapping on w
I appreciate the source, and I agree that the discussion of rootkit detection is very good. One reason I can say this is because they are very up-front about the limitations of their tool. More directly, they categorically agree that real penetration detection cannot be done from the penetrated machine.
"Can a Rootkit hide from RootkitRevealer? It is theoretically possible for a rootkit to hide from RootkitRevealer..." They go on, "Is there a sure-fire way to know of a rootkit's presence? In general, not from within a running system."
And they explain that they are only detecting certain flawed and incomplete rootkits - those that A) rely on a particular strategy for bootstrapping themselves, and B) patch some system calls to hide themselves, and not others. Thus, this detection tool is, while an excellent exercise, worse than useless in practice, since it will not detect the first rootkit to get it right, or any thereafter, but it will give you a false sense of security.
As we have both said, cleaning yourself from the inside of a compromised active kernel is impossible, but this dosn't mean you need another system in order to get 'outside'.
Actually, I agree on the first part, but I'm still a little fuzzy on the second part.
And if you have the power over the plug you have ultimate power over what controls the beast and at that point you just have to be able to verify your system... or wipe it.
The ability to unplug your system is far, far from the ability to verify it. Or perhaps I misunderstand what you are getting at.
With additional fully separate systems that you trust, you can do verification. But now you have to wonder why you trust your verification systems and not what you are verifying. It's a recursive problem.
I hate to say it, but the problem of verification looks just as ugly as ever.
To this you have added:
the disk drive, cd drive, or usb port.
I think my work here is done.
So, Sheepdot, you work in the "IT Security Field" and you make a salary? I'm well aware people like you get work all the time. Just hope you're not working for me, "Sheepdot."
Hey, where have you been working lately? Who hires experts who spout gems like "electronic security is not all that costly, and can be implemented easily"?
You weren't at Choicepoint, were you? Or Lexus? Or Diebold? Or Microsoft? Did you set them up with Kaspersky Antivirus?
Your thesis is shown to be conclusively wrong by a unanimity of experts in the field ("your field"), your knowledge of even basic features of the security landscape is calamitous, and your method of arguing is absurd.
In short, you are a whiny, ignorant baby.
Welcome to the filter. Here, the last word is yours. Go on, use it to further embarrass yourself:
Clean ROM programs loaded instead of from system storage...
Think about it... what loads these "clean" programs? Or even if you map the ROM directly nito the physical address space, what runs them? The system you didn't trust, that you're trying to verify.
The problem is that once I have control of the computer I have control of the program counter. I will just never let it into your "clean code."
Thinking further ahead you might create some kind of unmaskeable hardware interrupt, like a watchdog, that I couldn't block, that would kick off your security code at various intervals. No systems like this currently exist, and if they did they would be extraordinarily impractical. If the clean code relies on any part of the untrusted code, it no longer works. So your ROM must have its own kernel, its own drivers, you name it. And every software change is a ROM upgrade. But it's an interesting avenue. Well, I think when you get to the logical conclusion it ends up just looking like building a redundant extra computer into your computer to do the verification.
Once again, though, even if you do all this, it's just more expensive, complicated, and less reliable than paper. Now you are worrying if someone compromised your "clean" code before it was burned to ROM. Remember, the clean code is just as capable as anything of taking over the whole machine. Or maybe someone compromised the computers of any of the people who wrote the clean code. Or any of the other computers on networks with those computers. Or any of the tools they used to build it. Etc. Etc. Why go to all this incredible trouble just to trust something you don't have to trust?
For the printout I was suggesting that the printer creates a small 'error' if you will. Perhaps something that looks like spurious ink, perhaps it just alters a barcode (if utilized) Perhaps it uses a differnt font for the letter o that is is essentially unnoticeable to the eye but which signals the OCR software to interpret differently. Devious Enough ? If someone were then silly enough to add something like a test or calibration flag the ocr software could detect then it could then act nice when in 'testing/calibration' mode. Would make it one hell of a gremlin to chase down.
No barcodes would be used in this system. There is no OCR of any kind. Everything would be human readable. So there is really no avenue for this kind of attack.
The only additional wrinkle is for optical scan, which looks for the user's having filled in an oval. This comes back to the original line of reasoning which you have not been able to breach yet, which is that it doesn't matter what the computer does as long as there is a verifiable paper trail. If the computer tries to cheat, it will get caught.
Taking away the voter-verified paper from these systems only makes it vastly easier for the cheating computer not to get caught.
The power of an audit is undeniable and I have never said you don't need one.
I never meant to suggest you said so. Only that meaningful audits are effectively impossible.
I am saying there is probably a better solution. Rome werent built in a day and finding a digital alternative to a technology that has 3000 some odd years of improvements might take a while.
There we are in perfect agreement.
Here is the process of counting an OCR printout. Mark digitally, turn into an analog printout, read analog printout to creat a digital mark in order to tally the vote. To count by hand you mark digitally to creat an analog print out to count by hand.
Actually, I don't know if your process is right.
For verified receipts:
1) User votes on-screen
2) Receipt is printed
3) User verifies and accepts receipt
For optical scan:
1) Ballots are mass-produced
2) User marks ballot
3) Ballot is scanned
4) User verifies and accepts scan results on-screen.
There's no analog-to-digital conversion in the form
Listen to the low-karma slashdot troll Sheepdot. Sure, he says a lot of obviously wrong things and gets called out on it, and whenever he does he refuses to justify himself and just insults the people who catch him. This is a sure sign of a truly powerful security and voting systems expert.
G .html m l t ml
- patching.txt"
I mean, what does Bruce Schneier know? The world comes to slashdot trolls for its opinions, after all.
How can anyone fail to sense your hidden genius in your appreciation for half-baked security tools that have a history of failure traceable as far back as Phrack articles from 1993.
Yes, ladies and gentlemen, only on slashdot can a whiny, obnoxious, ignorant baby like Sheepdot treat experts like assholes and still get a free education in return:
--
"More recently, other implementations of LKMs for hiding processes,
files, and directories have come about that can get around the above
described methods of defeating standard root kits, as well as
cryptographic checksumming programs like "tripwire" that must trust the
operating system to present them with valid bits from disc and memory.
The Hacker's Choice (THC) from Germany has write-ups on loadable
kernel modules for Linux, FreeBSD, and Solaris, which describe this
methods of hiding out on a rooted box:
http://www.thehackerschoice.com/papers/LKM_HACKIN
http://www.thehackerschoice.com/papers/bsdkern.ht
http://www.thehackerschoice.com/papers/slkm-1.0.h
TESO has another Linux LKM ("adore") along these same lines:
http://www.team-teso.net/releases.php
Using methods such as these, integrity checking programs like "tripwire"
and NIPC's "find_ddos" programs can be subverted, as the kernel could
not even be trusted to give correct results when searching process
tables, network structures, or file systems.
You might think that simply disabling LKM support in the kernel -- which
is still a good idea to improve security on a server whose configuration
will be stable -- is the final answer. Not exactly.
Another method of inserting code into running kernels -- even if LKM
support is not present -- is described by Silvio Cesare:
http://www.big.net.au/~silvio/runtime-kernel-kmem
--
Too bad you can't run tripwire to protect your brain, Sheep. LOL.
Haha.
I was waiting for you to kick in with some kind of fact, but I guess if you don't give any more you can't get caught being an idiot again.
So you're too afraid to even fake another post, eh?
You care about "uncovering the truth" by saying a bunch of obvious nonsense, getting busted, then refusing to justify any of your arguments and slinging insults. Well, I think we've adequately demonstrated today not only the flaws with paperless voting systems, but also the flaws in the back-of-the-class kids who need a hobby bad enough to act as apologists for them.
Oh, you'll do great convincing all those people who know nothing about the discipline and are wowed by childish bluster.
Byeeee.
All this hasn't changed your mind? Well, I tried my best.
;-)
I feel obligated to advise you that your opinions conflict with those of almost all of the experts who have considered the problem - people much smarter than you and me who have spent their lives focused on these issues. To give you an idea of the caliber of people you're taking on, here's Schneier. So don't just take my word for it.
When discussing rootkit detection, we should be careful not to confuse on-line and off-line detection. Off-line detection (done with a separate machine you believe you trust) can make use of checksums or comparisons as you describe. All I am saying is that on-line detection (the machine inspecting itself) is impossible - because a compromised host can return the "correct" data to its own detection routines. Indeed, any "normal" state can be simulated.
hmmm, I'll be as paranoid as you for a second and claim an essentially undetectable alteration to the printout (via human means) that means the vote is registered in the OCR software differntly than what it 'says'
I'm intrigued but I don't understand you. How do you propose this would work?
But in most systems right now if the hand recount and machine recount were seriously out of whack it would just invalidate the election.
That's "just" the exact, ideal behavior! The most you can hope for from any other system, paperless, etc. is that it do as well.
I'd feel even better if there were some way of validating the printed ballot in the presence of the voter (no poor print job etc...).
That's exactly what I'm already proposing. The voter does validate it. If the paper doesn't clearly match their intentions (or, for an optical scan, isn't being read properly by the machine) then they signal to the election workers, etc. etc.
They are easy to invalidate (punch a few extra holes, make extra marks),
No, they are not.
For destruction, if you bought 500 sheets of paper, and you end up with 400, you discovered fraud and invalidate the election.
For other forms of invalidation, optical scans that won't scan properly must be redone by the voter to "count," and verified receipts are generated by machine and only exposed to the voter behind glass, so they're basically guaranteed to be valid. If a machine itself generated invalid ones the voters would catch it instantly.
You don't trust code cause you don't trust people.
I don't trust code because its a game that allows untrustworthy people to win vastly more easily. That's really all.
A paperless code based system has the potential to remove people from everything except making the code and inputing the votes.
I have to confess, I have no idea what you mean by this. How can paperless possibly accomplish this? It does not reduce any fallible human involvement, only add vast new amounts of it. Well, maybe I have misunderstood you.
At the end of the day, I think you have to build frameworks that allow people to trust each other, because they make it easy to catch someone breaking the rules.
You're very kind. We always get more out of this place if we come here to learn, rather than to argue.
I didn't feel I had to detail why a paperless system is CAPABLE of counting votes better than paper ballot counting systems.
No, certainly not. But the interesting question is not whether it is capable of it in a theoretical perfect world, but how it actually works in the real world, where, as we know, all the problems I mentioned come in to play, and electronic systems are never as perfect as we would like.
Regardless, at the end of the day we can create a system that has every advantage modern computing can give it, yet is as reliable and secure as paper-based systems, simply by giving it a paper trail in the way that I've layed out.
Detecting a rooted system is hard from the rooted system but not impossible.
I beg to differ. Such on-line detection is indeed impossible, if the compromise is written well enough. In fact, I would go so far as to say you likely cannot design a system where an on-line undetectable exploit could not be written.
Moreover, even if you know you are compromised, you are not really able to say with much certainty to what extent.
This is critically important, and it is why the industry standard procedure for suspected compromise is to shut the machine down, study it if you like, but regardless, wipe it, and reinstall from scratch. It is also why there is no industry standard for determining, on-line, if you are compromised in the first place.
As for thinking I wouldn't go to such lengths ??? Poor assumption on your part though in general I know what you mean.
Fair enough. Of course, anyone can wipe their own machine - daily if they feel the need. They have to trust the tools they are using to do that, of course...
The point is, trusting the software is impossible. It's a black hole. It will suck you into myriad cat-and-mouse complexities and very quickly it is obvious you will never escape. You will never trust the code, and to even get close you are spending mountains of cash and moving heaven and earth to do it.
The good news is that you don't need to as long as there are paper records. Does it have to be paper in particular? No, just anything with this unique set of properties. We can certainly invent something better if we want, and we will know it when we see it.
Regarding printouts: If your fear is manipluation of code, and code is responsible for a printout, then the printout is suspect.
Definitely not! This detail is critical!
If it's an optical scan ballot, the contents of the paper are created by the voter - hence, not alterable by computer, period. The voter then reads the screen to insure the computer read the ballot properly. Of course, the computer can lie, but it will get caught.
If it's a receipt-based system, the user votes on the screen, and then reviews the receipt under glass to insure it says the right thing.
This is why they call it a "voter-verified paper trail."
Paper is easily forged and easily destroyed.
Actually, forging paper is quite difficult to do effectively, and as I pointed out, you can destroy it, but you then have to account for it later.
You and your experts have a very high standard. If a similar level were applied to a paper system I feel it would also fail.
I don't think you can say this without devising a convincing attack on the voter-verified paper-backed system.
Obviously these are just positions on a continuum of cost and difficulty and risk. But the two approaches (paper versus paperless) are not even remotely close on this continuum, and in addition, to the best of my understanding, the difficulty of conspiracy against the paper-backed system is great enough as to be substantially impractical even for the size of an investment that might be justified to gain "leadership of the free world."
Right now I would say
I just deleted the really obnoxious phrase that I originally started this post with.
Basically everything you have said so far has been outrageously wrong. In addition, you've been rude about it, so I have trouble feeling any sympathy for you, either.
But in the end I do feel sorry for you, and it's never too late to learn something, so put the attitude away and follow along. No harm done if I don't convince you, but be careful, you are in danger of expanding your knowledge...
Apparently you have never heard of Tripwire
Tripwire will never raise any alarms if no checksums ever change.
The system is easily fooled by common rootkits that patch the kernel to modify the results of certain system calls, for instance read(), to conceal their own presence at the kernel level.
Process tables and memory are commonly rigged the same way.
This is only a slightly fancier trick than just patching and disabling Tripwire itself, which is what simpler systems used to do.
You speak with a lot of confidence for someone who doesn't appear to know about this concept, which has been around in the field for over a decade. Anyway, it's actually a pretty neat trick, and a lot of fun the first time you do it, especially once you think about the impllications.
Think about it. You could be compromised right now, as you read this. And you won't check, because of the outrageous expense and time involved (disconnecting your HD, taking it to another machine, inspecting it byte by byte... becuase pattern matchers don't work for custom code). You'll tell yourself it's unnecessary because, who would do that to you? (The answer is, a spammer, but no matter). The real question is, who would do that to a voting machine? And we both know the answer to that. I hope.
We'll ignore the fact that the law dictates they have no less than two copies, one hardcoded to a media that cannot be altered (like cd).
Really? So the voting machines we're discussing... they store votes on two forms of media, one that cannot be altered? How novel.
The fact that you can appreciate the need for write-once media already puts you ahead of Diebold and their like, who do not, as far as I know, use such techniques - not that they matter. It makes me wonder if you are imagining this law or if they simply break it. Neither would surprise me.
What's positive about this is that at least you are only a short jump away from acknowledging the advantages of the most mature, durable, secure, and simple write-once media known to humankind, paper, where (unlike the preposterous concept of using CDs) the user can verify what was written on the spot, in the booth.
Don't worry that they have the CDs/DVDs to fall back on, you're right, the data was changed and no one really noticed.
Unfortunately not everyone is as shockingly bad as you are at this.
The voting machine software was compromised before it is ever rolled out to the polling place. The votes are not changed after the fact, they are never recorded properly in the first place.
Because your system had no voter-verified paper trail, no one can tell what the machine is actually recording, whether it records (or does not record) the wrong vote once, or twice, or 50 times redundantly.
With paper, the vote is recorded on disk, but also on the paper, and the voter verifies that the paper is correct as they vote.
This is impossible to rig, whether you compromise the software or not. So for this simple design, you have eliminated an entire class of risk, which is good, because the risk was astoundingly huge and you had no credible way to mitigate it.
John breaks into the courthouse. It wasn't difficult, because he got the key from a janitor two months before and duplicated it. He walks over to where the stack of papers from his precinct is and loads up on fake ballots, which he obtained the night before when he was helping with the vote (they actually ple
It might be helpful if you were more specific about what you thought the problems with paper balloting were. If accuracy is your only gripe, remember that if a computer counts more accurately, it also has unreliable analog input devices (i.e. touch screens that lose their calibration), system crashes, data corruption, and the list goes on. It is by no means a given that your system will be better.
Further, it seems you are confused about the distinction between paperless and electronic. I have no problem with eletronic. However, at the same time, paperless is indefensible. Optical scan, for instance, is fine with me, and there are a few other paper-backed electronic approaches that are equivalent in security. These combine all the advantages of computers with the security of a truly secure write-once media (paper).
Indeed, these are the approaches advocated by virtually all the credible experts.
By the way, you make a blanket defense of technology in a fallacious way. You may as well argue that, because computers do a great job tracking your bank balance that they should do just as good a job driving your car. Because computers are good for any set of applications does not automatically make them good for another one, and you must always argue on the merits alone.
Do people with rootkits get caught? You are quite right, they do.
However, how many of them get caught, versus how many don't? Much harder question to answer, isn't it.
The fact of the matter is, your computer could be compromised right now as you read this, and you would have no idea. The only way you would know it is if you attached your hard drive to another computer and did an analysis. And by the way, anything custom isn't going to show up in some pattern matching engine like an antivirus app. You have to disassemble your system byte by byte.
Yet you will not do this analysis. Your justification (not particularly good) will be that no one wants to compromise your computer. (Not true; spamemrs and others do compromise millions of hosts automatically, and may already have compromised yours.) Now imagine the incentive to rig an election in the most powerful nation in the world.
People kill each other over miniscule sums of money. Political power in america is worth many billions of dollars to unscrupulous winners. Your system must be designed against attacks with that enormous level of incentive in mind.
You have suggested that it is difficult to tamper with voting machine software (sealed, onsite etc) but not gotten very specific. What you have done is state the case backwards: by abandoning paper for a paperless system, you have introduced a major new vulnerability: the software can be tampered with. You may take safeguards to prevent it. Those kinds of safeguards taken by, for instance, major, wealthy, sophisticated players with a lot to lose, like Lexis, or Choicepoint, or the U.S. military - all of which, by the way, have suffered major, staggering compromises recently.
The likely case, though, is much simpler than some elaborate mission impossible scheme. Someone involved in the handling of the machines takes a bribe. Now, you can't bribe any of the paper handlers without bribing all of them, because breaking the security of the paper trail requires physical activites that are checked by physical security. If a Republican and a Democrat and a policeman and an election worker all guard the box, you have to bribe them all to destroy it.
Not so for software. Anyone in the chain of vendors and officials who have access to the software can collude, and none of the others would ever know.
It's that simple.
Your applying a double standard if you think a paper trail generated from an electronicly generated transfer process (printouts) counts. Those can be manipulated as well.
This is an absolutely false statement, verging on incoherent.
How on earth do I make a computer unprint something? How do I make it change something
What have you read?
Anything at all?
Not even my post, apparently. This has nothing to do with speculation. This is elementary fact.
Paperless systems work with media where bits can have their state changed without anyone being able to tell afterwards what the original state was. More amusingly, this tampering can also be done in a variety of ways that are difficult verging on impossible to detect.
Paper systems work with media that, for all practical purposes, cannot be altered in an undetectable way. Nor can they be destroyed without detection if even the most rudimentary security procedures are followed. Nor can paper be affected without immediate physical presence.
Anyone can rewrite an electronic log. That's why the military and banks, among others who care, have been sending their syslog to line printers for decades... because even high school freshmen know to alter the log when they compromise a system.
No one is worshipping anything. This is a simple matter to be resolved with black letter facts. And you are startlingly wrong on almost every single point you have made.
You seem to think verifiable marks can only be a physical hole, or ink mark on a piece of paper. They can just as easily be colored pixels on a display. Obviously malfeasence in the code can render this useless. IE display one thing and register another in the final count. The same problem exists with paper ballots.
No; if I tamper even in the most trivial ways with your flash memory or hard drives, you will never know it. There is very little chance even the most expert forensic analysis can tell you.
Tampering with paper, on the other hand, is almost impossible. A forensic analysis will catch you; the technology is ancient and well established, in use already by the U.S. government, banks, etc. They do it every single day, to handle counterfeit currency, forged or altered checks, you name it...
Back to your paperless system, I could also tamper with its counting mechanism. There would be no evidence at all unless my malicious is so smashingly amateurish as to not erase itself when it is complete. There is absolutely no system you can design that can prevent undetectable malicious code; indeed, no such system has yet been designed by man.
Now, back to paper ballots. The only way to safely tamper with paper ballot counting is to destroy ballots. Now, this is exactly what our current system is geared to preventing. Observers from all (i.e. both) parties observe polling, transport, and counting of the ballot box. Anyone attempting to destroy even a single ballot would have an insurmountable challenge; let alone attempting to destroy hundreds of thousands from thousands of different polling places.
I can rig your paperless election right under the noses of these observers, and I don't need to lift a finger further than the keyboard. I don't even need the collusion of the "voting systems manufacturer" (a concept that doesn't exist with paper ballots, so its an entirely new risk your paperless systems introduce).
Your paperless electronic system runs contrary to every design principle of secure systems. No one builds machines like this even just to handle money, let alone a powerful nation's leadership. Nevada was in the embarrassing position of having to turn away from paperless systems because the state's gaming board had vastly stronger security standards already in place for slot machines (yes, even they are required to maintain paper records interally).
Why?
Because what your paperless electronic system does, in effect, is create a way for me to sneak in at the speed of light, destory or alter ballots in a way that will be completely undetectable, right under the noses of these observers, and conceal the fact that I was ever there in an almost foolproof manner.
It is impossible to have a recount in this system, because there is nothing to recount. There is no redundancy.
Swap ballot boxes for stuffed boxes, etc.
Try it. I'm serious, next time you vote, go check out the polling place. Ask one of the poll workers if someone could "swap the box." They will explain everything.
Government by election is ultimately an issue of trust.
And government trust is based on government actions. And if government actions involve violating bedrock security procedures without any plausible justification to put an inexplicably insecure new voting system in place, at great expense and taking great pains to stifle complaints by the (large, organized) community of concerned citizens... then there is no longer any trust in the government or the fairness of elections, and all that that entails.
As long as these paperless systems are in place, in a close election if there is a disputed result there is no more process. There is only theater. And when the ABC anchorman points his microphone at the "Voting Systems Experts"
Already answered this in an adjacent thread...
Have you read any of the important material on the issue? There are lengthy, well-written position papers from ivy league experts, as well as excellent materials compiled by verifiable voting advocacy groups that are more accessible to the layman. The need for paper is well established enough to be called bedrock, and indeed it is absolutely incontrovertible.
Many, many, many, many others have already explained this in great detail and better than I probably could, but in brief:
Paper creates forensic evidence. If I commit fraud with a paper system I have to destroy the paper, which is itself evidence of fraud.
Paperless electronic (or for that matter, mechanical) systems create very little if any forensic evidence of tampering.
Doesn't it strike you as absolutely breathtaking that (in America) machines like this could even exist?
Paperless designs violate absolutely basic, shockingly obvious, bedrock principles of security. There is a problem simply because I often don't have the vocabulary or metaphors to express to a disinterested layman how wrong a paperless voting machine is. It's like building a bank vault to hold the most valuable thing in the entire world, and refusing to include a lock for the door.
I frankly do not care if the study didn't show malfeasance _or_ some esoteric demographic effect this time. These machines need to go. And all the people who built them, approved them, and paid for them, need to be investigated.
...after seeing all this, I'm now really interested in reading a deeply cynical, probing investigative article on O'Gara.
I believe they aren't formally teaching this approach in most journalism schools yet. Does she do these sorts of hit pieces for fun or profit?
Does SCO compensate her, directly or indirectly?
It's essentially why this sounds like scare mongering to me.
I take these finer points about the GPL to be good things.
"Acquiring" an open source project and "orphaning" free code are just inappropriate adjectives for the everyday, ordinary activities of developers coming and going from a FS/OS project.
Add to this, as you point out, the difficulty of developing a consensus among copyright owners and although the article is basically correct, this journalist is starting to sound especially desperate to be "controvertial."
At the end of the day, there will always be problems the market will solve that the FS/OS community can't or won't. Both models are here to stay, and the two have an interaction that is (taking a longer view) basically healthy, in no small part because of the generally good design of the GPL.
"Finally, he raises the question on whether corporations should get involved in social issues."
They may as well. They're the only ones with any influence other than organized religions.
As I predicted, you were unable to answer my questions.
Instead, you basically said, "hey there may be problems with other kinds of patents too."
Patenting software is distinct from patenting other kinds of inventions, and we can get into why that is if you like. The exercise is rhetorical, however I will be happy to indulge you.
If you cannot make the system work, it frankly doesn't matter whether you should try.
You only said, "you do the research."
How do you do the research, stubear?
Do you really believe "the research" is something that could possibly be accomplished by human beings, on a human timescale? There are hundreds of thousands of these patents already. There more daily.
You cannot even devise a scheme for just keeping up with NEW patents that is within orders of magnitude of being economically feasable for ANY form of software development.
You can't wave your hands and say "search capabilities." What type of search capabilities can reliably correlate source code with patents? None are known to human-kind, nor are there likely to in our lifetimes barring some harrowing advance in the field of artificial intelligence. Such an advance, I might add, will only be possible through (yet again) our collectively ignoring and violating tens of thousands of software patents.
How on earth can this preposterous state of affairs not immediately require us to turn back towards sanity?
Have you ever written any code?
How many patents did you violate in order to write it?
How do you know?
How can ANYONE possibly EVER know?
And even if by some miracle you did know today, how will you know tomorrow, when another 1,000 patents have been granted?
You have no answer to these questions. I know that in advance, because these questions are impossible to answer.
It amazes me that anyone is still confused about this.
Software patents are a ridiculous, unworkable farce. The only reason they "work" today is that they are almost universally ignored, even (or especially) by their supposed proponents.