Interferon iirc slows the replication of AIDS virons inside the cell, so it makes sense that throttling an already throttled process should be an effective treatment.
...
What this all boils down to is AIDS has found a new way to use the cells it hijacks. Most other viruses use them as self-destructing viron factories, and a few as places to hide and lay dormant for later relapse. But using cells as lingering attack platforms is just plain scary.
Wait, so why does interferon seem like a good treatment? From what you say it would perhaps delay progression of the virus's spread, but not fundamentally disrupt its operation.
OTOH, perhaps going the other way would have merit. If the virus is so clever because its viron strategy is both stealthy and targeted, perhaps it's worth researching a way to speed up viron production. Then there would be greater chance of early immune response, and of premature death of infected cells. Right?
I always thought these sorts of dirigibles would be useful in a communications network. It seems as though they could have some of the same advantages as satellites, but without the same launch expense, and with lower transmission latency.
Anybody know why these wouldn't beat the pants off Iridium, or at least provide a drop-in (float-in?) solution for battlefields, Katrina-type disaster relief efforts, or cell-forsaken geographic areas?
I guess they could spy on the communications, too. Oh, and there no doubt would be a way for advertising to get tied in. Maybe it would be a joint NSA/Google venture.
I can understand why people hate e-voting - it's susceptible to attack and/or manipulation, there's privacy concerns, etc. etc.
But I have to wonder, is it really all that different to paper voting? If someone wants to rig an election, they'll do it no matter what system you use.
I can't imagine it's significantly harder to rig a paper election than an electronic one.
I wrote this reply many years ago (with a correction to a researcher's name in a follow-up post):
That was for totally electronic voting. I think all the points remain valid today. Schemes that use electronic machines at polling places seem feasible if they make correct use of paper audit trails (easily verified by the voter, and also by officials as needed for recounts or statistical verification of electronic results).
I should note that many of the steps that could be taken to make various aspects of paper-based voting provably secure, actually often are not taken in today's US election process.
The reason is possibly that there is not much perceived need to highly prove security against fraud in the current state of our democracy. However, eliminating paper would make it impossible to institute important protections in the voting process if/when they were to become necessary.
I've posted a few times on this subject (it was the topic for my master's degree project way back in 1999). You could look over my posting history for additional comments.
There is a fundamental conflict between establishing a verifiable audit trail, and maintaining a secret ballot.
For example, a voter that uses a blinding factor as part of a cryptographic voting system is left with a, "receipt." The blinding factor is known only to the voter, and can be used to prove that a particular vote was cast by that voter. This could lead to vote-selling or extortion.
But really, an all-electronic system provides simpler problems. What if software on the voter's PC spies upon, or alters, that voter's vote?
What if your manager asks everyone in your group to vote from the PC in his office, while he looks over your shoulder?
For these reasons and others, it seems sensible to maintain a requirement for a polling place. You should be required to prove your identity to access a voting booth, and this proof should be verified against some token exchanged in advance, as part of a registration process. But, it should not be the case that any device knows both your identity and your vote.
Now that you've gone to a polling place and cast your vote, are you sure you want a purely electronic assurance that it was properly recorded? What if the manufacturer of the voting device was sloppy or malicious? I bet you really want to look at a piece of paper (it can be both human- and machine-readable, like standardized tests with colored ovals), that you can verify, that can be used as an authoritative record for a recount, that can keep the voting device honest.
Many observers from all sides can keep a watchful eye on those pieces of paper, whereas you have no guarantee at all that the bits associated with your vote were even recorded correctly in the first place.
As far as reducing fraud, good protocols aren't even enforced properly in the paper-based case. When I voted for the presidency in Massachusetts, I was not required to prove my identity when I entered the polling place. I heard stories about Florida where folks, trying to turn out the elderly vote, brought absentee ballots to rest homes and passed out multiple copies to anyone who wanted them. There were lots of reported cases of people who were allowed to vote without having registered in advance. As usual, many dead people voted.
One way to address fraud is to establish and enforce rigorous registration procedures; this must be done regardless of whether an election is electronic or paper-based. Such measures are usually opposed, ostensibly because, "it makes it harder for people to vote," but really (in my view) because certain interested parties (on all sides) enjoy having some hooks into the system that let them manipulate the results.
I admit that I haven't followed all the postings to all the SCO stories very closely, but I really expected to see a dozen jokes linking SCO with Mohammed Saeed al-Sahaf modded +5, funny, by now...
----- Dismiss popup Quit viewer Clipboard: Local -> Remote Clipboard: Local - Remote Send ctrl-alt-del Send F8 -----
Also, I didn't have to read a manual to make the windows version do what I wanted.
Also, now that I've typed, "clipboard," there are lots of known annoyances here. With VNC, it usually means that I can only transfer text from the vnc window to a local one if I first put it in an emacs window within the vnc window.
On a windows box, I can open a 1024x768 VNC client, and have it work in full screen mode without any decorations or scroll bars. It looks just as though I'm working on the remote computer.
In Linux, I can't do this. I can only maximize the window. There's no notion of letting an app manage the full screen. So to use the remote machine, I have to keep scrolling to get to the 10% of the remote screen that's not visible at the moment.
I did my master's work on electronic voting. There are some interesting cryptographic developments, but there are interesting, subtle, and hard problems associated with every purely electronic voting scheme I have seen.
Essentially, there is a conflict between the audit trail and the secret ballot.
The last time I checked, there were essentially two classes of proposals to resolve the conflict.
1) Use some sort of cryptographic, "blinding," such that a ballot can be signed by an official while the voter is known but the contents of the ballot are kept secret. Later, the contents (with official signature) are submitted with the contents known, but the voter kept secret.
2) Use some sort of distributed trust mechanism whereby voters submit encrypted ballots, which are only decrypted by a set of trusted officials in a manner such that the tallies become known, but no voter's vote is linked to the voter.
(1) has the weakness that the voter has a receipt; that is, a voter can prove afterwords (using information known only to the voter during, "blinding") a link between the voter and a particular vote. Oddly, this is also a strength in some sense, since a voter could verify that a particular vote was present in the tally.
(2) has the weakness that a small (compared to the set of all voters) set of people could collude to link voters to votes, or even alter votes.
In general, *any* purely electronic scheme is also susceptible to spyware on the device where the vote is cast, or to the presence of malicious third parties. I will make a generic claim that it is a bad idea to make the voter's identity and vote both known to the same device.
Schemes using DRE machines in polling places that print paper copies of ballots get my full support. Unfortunately, these are the least popular, partly due to ignorance, and partly due to efforts by dubious players in the industry.
The idea here is that you register in advance (just like now), go to a polling place where they verify your identity (just like now), and go to a machine to record your vote but not your identity (just like now). The vote can be stored and counted electronically (hooray!); but, to keep everyone honest (like the manufacturers of the DRE machines), you get a printed copy of your ballot, that you inspect for correctness, and deposit in a well-watched ballot box (just like now). The paper ballots (which could in principle be both human- and machine-readable), would be *the* authoritative results. Statistically, some would always be counted, but all would be counted in the event of a recount.
Well, that certainly is true if you think of the pedals in your car as speed controls, which they aren't.
"It's amazing how many people, even on Formula 1 level, think that brakes are for slowing the car down" --Mario Andretti
The interface that *most* people use when they drive is exactly the simple one: speed up with the accellerator, slow down with the brakes, turn with the wheel (most people, I think, in fact have only two pedals in their cars). It is unreasonable to claim that these people have no business driving. Sure, they have no business driving on the Forumla 1 level, and they have no business trying any of the techniques you mentioned above. But, I think they have every right to use a car to go grocery shopping.
ABS and traction control make the car behave more the way most people expect it to behave. This is a good thing, not some evil dumbing-down that caters to people who should not be allowed behind a wheel. If you think you know what you're doing, then just drive a car that lets you disable those features.
It's assuming a lot that the person is going to be changing lanes or swerving? That seems like about the most likely response... either that or just jumping on the brakes at full, which is why we have ABS; to handle panic responses from people who really have no business driving to begin with.
ABS makes a simple interface work as advertised with fewer exceptional cases, and lowers the amount of experience needed to achieve proficiency.
It corrected a flaw in the interface, not in the user. The same is true of traction control. The brake and the steering wheel now, "do what you mean," much more often than before.
Yep, that's exactly right. I did my master's work on electronic voting. I came away unconvinced that any purely electronic scheme ever will be adequate.
One reply in this thread commented that there should be receipts, but they must be deposited before the voter leaves the voting area. Such an arrangement is actually a very good idea, but is still receipt-free -- after the voter leaves, there is no proof that a particular vote was cast. (It's a good idea because it leaves physical tokens that can be used to perform recounts, or count verification.)
Another reply said that it was silly to try to take away the ability for one to tell another how a vote was cast. That has nothing to do with receipts. The point here is that one should not be able to *prove* how a vote was cast.
Yet another reply pointed out the need in some cases for an election administrator to aid disabled voters. That's a good point, but note that neither the voter nor the election administrator should be able to *prove* that the vote was cast a particular way.
One real, unsolvable difficulty with both absentee ballots and internet voting is that it becomes impossible to guarantee people are voting in secret. But we also accept that blind people
...
The bigger challenge in either system is verifying the identity of the voter. This gets worse when
Well, almost.
I did my master's work on electronic voting. The real problem is that it's hard to simultaneously provide a secret ballot and obtain adequate proof of the voter's identity. This is true even when you don't consider the case where someone might be looking over the voter's shoulder during the voting process.
There are several schemes that have been proposed for dealing with this, but none are really adequate. Actually, it has yet to be shown that an adequate solution exists.
Imagine a world in which software companies are criminally and/or civilly liable for ill effects resulting from successful attacks on their products.
I think that in such a world, software quality would improve dramatically, and software manufacturers would be at least as motivated to fix bugs as they are in a world with full disclosure.
Verizon is apparently also blocking port 80 for their DSL customers, in addition to blocking outgoing port 25 and requiring use of Verizon's SMTP servers to send email.
Actually, isn't this exactly what Verizon ought to do to provide a proper audit trail for email? Actually, shouldn't external MTAs be configured to reject those requests even if Verizon let them through, because Verizon's is not one of the domains they serve?
That is, an MTA in the foo.com domain should handle only requests from IPs in the foo.com domain, and additionally should check the envelope (MAIL FROM) to ensure that the purported originating user is known to it, right? These measures aren't perfect by any stretch of the imagination, yet they do impose obstacles to spammers and spreaders of email viruses.
In a nutshell, what's so bad about being forced to use your ISP's MTA? It seems like Verizon is being a good corporate citizen of the 'net, here.
There are two major types of modern electronic voting schemes. The first type is based on the work of Fujioka, Okamoto, and Ohta (FOO). The second type is based on the work of Cramer (C).
For a good introduction to all of the problems associated with electronic voting, look up web publishings of Lorrie Cranor, who also developed a (FOO)-type scheme. A good link is http://www.ccrc.wustl.edu/~lorracks/sensus/hotlist .html
The major problems stem from trying to assure simultaneously that the election is tamper-proof, and that ballots are secret. This turns out to be very difficult. Even paper-ballot elections aren't really very good (e.g. Kennedy-Nixon presidential election, Chicago, "vote early, vote often"), but they have the virtue that to corrupt them an attacker must physically handle lots of pieces of paper in lots of different places.
(FOO)-type schemes try to use 'blind signatures' to let voters get a ballot using their real identities, then cast it using 'blinded' identities. However, blind signatures aren't perfect, and in particular schemes of this type let voters prove how they voted, which could lead to vote coercion or the selling of votes.
(C)-type schemes don't try to blind the identity of the voter. Instead, voters encrypt their ballots in a special manner, and submit them to a trusted group of individuals. This trusted group first combines all the encrypted ballots, then (by virtue of the special encryption) obtains the election result by decrypting the combination. Here, voters trust a relatively small group of officials not to collude to decrypt votes singly, thus revealing how each voter voted.
There is no clear solution to these problems, and the cutting edge is not 'good enough'. The election in Arizona did not use a type of scheme even as good as either of the ones I describe above. Instead, a private company is trusted to count and announce the results (BTW, it seems that nobody could prove that they did not invent the results they wanted), and to keep the identities of voters seperate from their votes (they have one database of voters vs. IDs, and another database of votes vs. IDs, and they swear that they won't cross-reference by ID).
Really, e-voting isn't ready for prime-time.
Re:On the applicability of the Orange Book
on
Auditing for Linux?
·
· Score: 2
... it is often useful to have a low-security, high-assurance system...
It is? What is the point of having a cheap bicycle lock that you are absolutely, positively sure will not stand up to a determined attempt to break it?
Well, the point is, it stops a casual thief. A bicycle lock (cheap or not), as you describe, has low security and high assurance. Anybody willing to get some liquid nitrogen (cheap, BTW), can get by your lock no matter how great it is. But, somebody walking down the street who spontaneously thinks, "that's a nice bike," is thwarted. The brute force attack (liquid nitrogen) will defeat the security, but otherwise somebody has to have the key to get the bike.
Similarly, a situation where you don't do much to prevent people from coming and going, but are sure that their activities are on a security tape (for example, an ordinary bank) calls for low security, high assurance. That is, the bank robber can easily get the teller to hand over the money (that's how tellers are trained, in fact), but we are confident that the police will catch the robber later (and bank robbers are almost universally caught). Anyway, you say that I described class C2 protection. To be honest, I haven't read the Orange Book enough to debate you here. But, I suspect that levels like A1 describe even better assurance than C2 -- but that you can't get credit for those levels of assurance without also having A1 security.
FWIW, it seems worthwhile to point out that "Orange Book" classifications are not all that well thought-out. The problem is that they tie increased security to increased assurance.
It is extremely difficult to establish a high-security system while simultaneously having a high assurance that it is correctly implemented. OTOH, it is often useful to have a low-security, high-assurance system, and the Orange Book doesn't pay much attention to this case.
Indeed, if audit is the only really interesting property in this case, it sounds as though low-security (mostly logging) high-assurance (logging cannot be defeated even by 'creative' users) is exactly the solution that is needed.
"The operating systems wars of today are the equivalent of the browser wars of a few years ago," said Scott Hebner, an IBM software executive. "The operating system is not where the value is."
The first time IBM thought along these lines, it was wrong and gave MS a foot in the door. Now, still thinking along these lines, IBM seems to be correct, and liable to take away significant MS market share.
Without the initial blunder, it seems we wouldn't have a major corporation throwing its weight behind an open-source OS.
College students report something of the same phenomenon - technology keeps them studying, socializing, messaging and researching much of the time, much more than is acknowledged by school administrations. What's the point here? Let's revisit the following truths:
College students should make a serious time commitment to studying.
College students typically spend more time in socialization/recreation than they probably should, in light of the last point. This is, was, and always will be true.
Technology doesn't tell people how to spend their days. People tell people how to spend their days. In other words, those college students aren't forced to stay up until 5am playing net games. It's just more fun than going to bed.
Here is the part that really ought to make you nervous (the rest is just policy, really):
``Electronic signatures provide a level of authentication that far surpasses the ink signature that has come to be the accepted standard,'' said Virginia Republican Thomas Bliley, chairman of the House Commerce Committee. ``Electronic transactions have much less of a chance for human error and provide for more reliable retention after the initial transaction takes place.''
The implication that digital signatures magically sprinkle improved security on stuff is utterly bogus. While the signature algorithms themselves might be quite secure, there exists *no* acceptable (or even legally recognized) public key infrastructure that provides secure and reliable identification of public keys.
That is, if I give you my public key in person, then you can verify my signatures with confidence. If you just look it up in a directory somewhere, you are really trusting the maintainer of the directory. Who do you trust to link your name with your public key? If that entity turns out to be untrustworthy, you are the potential victim of e.g. man-in-the-middle attacks.
I think that digital signatures are a good thing that should gain legal standing. However, I think that there are significant infrastructure issues that should be resolved first. I did my master's work on electronic voting, which essentially requires little more than electronic signatures. I feel the same way on that subject: someday we should have it, but we need to iron out a *lot* of details.
The number one issue to address is that of educating the public about basic public key cryptography. As far as I'm concerned, it should be taught in grade school. The basics aren't that difficult to grasp, and a public aware of the issues would contain far fewer potential victims than an ignorant one.
Use Java for the remote procedure calls, but only for that. You can talk back and forth between Java and C, you know. I've actually done this; I wrote a C program that used the JVM libraries to make RMI calls to another machine that ran a small Java application that received them.
You can be clever with threads, too, so that in your client you can make a call (that immediately returns) that dispatches a thread to perform the RMI call and do something when it returns. The thread is a standard Java thread, even though you're using C to instantiate it! I've done this with good success (admittedly not for a big huge highly important expensive project).
RMI is simple and easy to use. That doesn't mean that you have to be a slave to the restrictions of Java (performance, etc.) everywhere in your code. Your network calls aren't expected to be that fast, anyway, so the layer that makes them may as well be a Java one that has clean, well-enforced, standard semantics.
I am not extremely knowledgeable about these things. FWIW, it doesn't seem to me that Oracle and DB/2 are significantly different in terms of 'solidness'. Both are major players at the high end of database use (and IBM seems to claim that DB2 houses the world's largest data collections, at the moment).
One thing I do recall reading (I think here on/.) is that some people have had very nice things to say about DB/2's documentation and usability. Many people talk about how Oracle is arcane and requires lots of specialized knowledge, and this is why you see Oracle admins getting paid the big bucks.
If you don't already have an Oracle Database Administrator on staff, you have a lot more freedom than many places that are shopping for a database.
In terms of filesystems, note that journaling is a reliability feature, not a performance feature (but no less important for being so).
The whole (real or perceived) problem of filtering inappropriate content is really a special case.
The more general problem is, "how should we index the web?". It's the digital library problem, really.
What we really want is a way to look up exactly the information that we want, getting pointers to all relevant sources and to no irrelevant sources.
For the censorship people, what they want has to do with the keyword 'smut' (and friends). If I look up smut, I should get all and only smut. If I look up something else, I should get no smut.
If the larger problem gets solved, the "censorship" problem is much simpler, and also shouldn't bother those who don't consider it an issue.
Slashdot Mirror
Interferon iirc slows the replication of AIDS virons inside the cell, so it makes sense that throttling an already throttled process should be an effective treatment.
...
What this all boils down to is AIDS has found a new way to use the cells it hijacks. Most other viruses use them as self-destructing viron factories, and a few as places to hide and lay dormant for later relapse. But using cells as lingering attack platforms is just plain scary.
Wait, so why does interferon seem like a good treatment? From what you say it would perhaps delay progression of the virus's spread, but not fundamentally disrupt its operation.
OTOH, perhaps going the other way would have merit. If the virus is so clever because its viron strategy is both stealthy and targeted, perhaps it's worth researching a way to speed up viron production. Then there would be greater chance of early immune response, and of premature death of infected cells. Right?
I always thought these sorts of dirigibles would be useful in a communications network. It seems as though they could have some of the same advantages as satellites, but without the same launch expense, and with lower transmission latency.
Anybody know why these wouldn't beat the pants off Iridium, or at least provide a drop-in (float-in?) solution for battlefields, Katrina-type disaster relief efforts, or cell-forsaken geographic areas?
I guess they could spy on the communications, too. Oh, and there no doubt would be a way for advertising to get tied in. Maybe it would be a joint NSA/Google venture.
I can understand why people hate e-voting - it's susceptible to attack and/or manipulation, there's privacy concerns, etc. etc.
But I have to wonder, is it really all that different to paper voting? If someone wants to rig an election, they'll do it no matter what system you use.
I can't imagine it's significantly harder to rig a paper election than an electronic one.
I wrote this reply many years ago (with a correction to a researcher's name in a follow-up post):
http://slashdot.org/comments.pl?sid=6507&cid=940549
That was for totally electronic voting. I think all the points remain valid today. Schemes that use electronic machines at polling places seem feasible if they make correct use of paper audit trails (easily verified by the voter, and also by officials as needed for recounts or statistical verification of electronic results).
I should note that many of the steps that could be taken to make various aspects of paper-based voting provably secure, actually often are not taken in today's US election process.
The reason is possibly that there is not much perceived need to highly prove security against fraud in the current state of our democracy. However, eliminating paper would make it impossible to institute important protections in the voting process if/when they were to become necessary.
I've posted a few times on this subject (it was the topic for my master's degree project way back in 1999). You could look over my posting history for additional comments.
There is a fundamental conflict between establishing a verifiable audit trail, and maintaining a secret ballot.
For example, a voter that uses a blinding factor as part of a cryptographic voting system is left with a, "receipt." The blinding factor is known only to the voter, and can be used to prove that a particular vote was cast by that voter. This could lead to vote-selling or extortion.
But really, an all-electronic system provides simpler problems. What if software on the voter's PC spies upon, or alters, that voter's vote?
What if your manager asks everyone in your group to vote from the PC in his office, while he looks over your shoulder?
For these reasons and others, it seems sensible to maintain a requirement for a polling place. You should be required to prove your identity to access a voting booth, and this proof should be verified against some token exchanged in advance, as part of a registration process. But, it should not be the case that any device knows both your identity and your vote.
Now that you've gone to a polling place and cast your vote, are you sure you want a purely electronic assurance that it was properly recorded? What if the manufacturer of the voting device was sloppy or malicious? I bet you really want to look at a piece of paper (it can be both human- and machine-readable, like standardized tests with colored ovals), that you can verify, that can be used as an authoritative record for a recount, that can keep the voting device honest.
Many observers from all sides can keep a watchful eye on those pieces of paper, whereas you have no guarantee at all that the bits associated with your vote were even recorded correctly in the first place.
As far as reducing fraud, good protocols aren't even enforced properly in the paper-based case. When I voted for the presidency in Massachusetts, I was not required to prove my identity when I entered the polling place. I heard stories about Florida where folks, trying to turn out the elderly vote, brought absentee ballots to rest homes and passed out multiple copies to anyone who wanted them. There were lots of reported cases of people who were allowed to vote without having registered in advance. As usual, many dead people voted.
One way to address fraud is to establish and enforce rigorous registration procedures; this must be done regardless of whether an election is electronic or paper-based. Such measures are usually opposed, ostensibly because, "it makes it harder for people to vote," but really (in my view) because certain interested parties (on all sides) enjoy having some hooks into the system that let them manipulate the results.
I admit that I haven't followed all the postings to all the SCO stories very closely, but I really expected to see a dozen jokes linking SCO with Mohammed Saeed al-Sahaf modded +5, funny, by now...
Actually, with F8, I see only this:
-----
Dismiss popup
Quit viewer
Clipboard: Local -> Remote
Clipboard: Local - Remote
Send ctrl-alt-del
Send F8
-----
Also, I didn't have to read a manual to make the windows version do what I wanted.
Also, now that I've typed, "clipboard," there are lots of known annoyances here. With VNC, it usually means that I can only transfer text from the vnc window to a local one if I first put it in an emacs window within the vnc window.
Thanks, I missed that one.
On a windows box, I can open a 1024x768 VNC client, and have it work in full screen mode without any decorations or scroll bars. It looks just as though I'm working on the remote computer.
In Linux, I can't do this. I can only maximize the window. There's no notion of letting an app manage the full screen. So to use the remote machine, I have to keep scrolling to get to the 10% of the remote screen that's not visible at the moment.
I did my master's work on electronic voting. There are some interesting cryptographic developments, but there are interesting, subtle, and hard problems associated with every purely electronic voting scheme I have seen.
Essentially, there is a conflict between the audit trail and the secret ballot.
The last time I checked, there were essentially two classes of proposals to resolve the conflict.
1) Use some sort of cryptographic, "blinding," such that a ballot can be signed by an official while the voter is known but the contents of the ballot are kept secret. Later, the contents (with official signature) are submitted with the contents known, but the voter kept secret.
2) Use some sort of distributed trust mechanism whereby voters submit encrypted ballots, which are only decrypted by a set of trusted officials in a manner such that the tallies become known, but no voter's vote is linked to the voter.
(1) has the weakness that the voter has a receipt; that is, a voter can prove afterwords (using information known only to the voter during, "blinding") a link between the voter and a particular vote. Oddly, this is also a strength in some sense, since a voter could verify that a particular vote was present in the tally.
(2) has the weakness that a small (compared to the set of all voters) set of people could collude to link voters to votes, or even alter votes.
In general, *any* purely electronic scheme is also susceptible to spyware on the device where the vote is cast, or to the presence of malicious third parties. I will make a generic claim that it is a bad idea to make the voter's identity and vote both known to the same device.
Schemes using DRE machines in polling places that print paper copies of ballots get my full support. Unfortunately, these are the least popular, partly due to ignorance, and partly due to efforts by dubious players in the industry.
The idea here is that you register in advance (just like now), go to a polling place where they verify your identity (just like now), and go to a machine to record your vote but not your identity (just like now). The vote can be stored and counted electronically (hooray!); but, to keep everyone honest (like the manufacturers of the DRE machines), you get a printed copy of your ballot, that you inspect for correctness, and deposit in a well-watched ballot box (just like now). The paper ballots (which could in principle be both human- and machine-readable), would be *the* authoritative results. Statistically, some would always be counted, but all would be counted in the event of a recount.
The interface that *most* people use when they drive is exactly the simple one: speed up with the accellerator, slow down with the brakes, turn with the wheel (most people, I think, in fact have only two pedals in their cars). It is unreasonable to claim that these people have no business driving. Sure, they have no business driving on the Forumla 1 level, and they have no business trying any of the techniques you mentioned above. But, I think they have every right to use a car to go grocery shopping.
ABS and traction control make the car behave more the way most people expect it to behave. This is a good thing, not some evil dumbing-down that caters to people who should not be allowed behind a wheel. If you think you know what you're doing, then just drive a car that lets you disable those features.
ABS makes a simple interface work as advertised with fewer exceptional cases, and lowers the amount of experience needed to achieve proficiency.
It corrected a flaw in the interface, not in the user. The same is true of traction control. The brake and the steering wheel now, "do what you mean," much more often than before.
Yep, that's exactly right. I did my master's work on electronic voting. I came away unconvinced that any purely electronic scheme ever will be adequate.
One reply in this thread commented that there should be receipts, but they must be deposited before the voter leaves the voting area. Such an arrangement is actually a very good idea, but is still receipt-free -- after the voter leaves, there is no proof that a particular vote was cast. (It's a good idea because it leaves physical tokens that can be used to perform recounts, or count verification.)
Another reply said that it was silly to try to take away the ability for one to tell another how a vote was cast. That has nothing to do with receipts. The point here is that one should not be able to *prove* how a vote was cast.
Yet another reply pointed out the need in some cases for an election administrator to aid disabled voters. That's a good point, but note that neither the voter nor the election administrator should be able to *prove* that the vote was cast a particular way.
The bigger challenge in either system is verifying the identity of the voter. This gets worse when
Well, almost.
I did my master's work on electronic voting. The real problem is that it's hard to simultaneously provide a secret ballot and obtain adequate proof of the voter's identity. This is true even when you don't consider the case where someone might be looking over the voter's shoulder during the voting process.
There are several schemes that have been proposed for dealing with this, but none are really adequate. Actually, it has yet to be shown that an adequate solution exists.
Imagine a world in which software companies are criminally and/or civilly liable for ill effects resulting from successful attacks on their products.
I think that in such a world, software quality would improve dramatically, and software manufacturers would be at least as motivated to fix bugs as they are in a world with full disclosure.
Actually, isn't this exactly what Verizon ought to do to provide a proper audit trail for email? Actually, shouldn't external MTAs be configured to reject those requests even if Verizon let them through, because Verizon's is not one of the domains they serve?
That is, an MTA in the foo.com domain should handle only requests from IPs in the foo.com domain, and additionally should check the envelope (MAIL FROM) to ensure that the purported originating user is known to it, right? These measures aren't perfect by any stretch of the imagination, yet they do impose obstacles to spammers and spreaders of email viruses.
In a nutshell, what's so bad about being forced to use your ISP's MTA? It seems like Verizon is being a good corporate citizen of the 'net, here.
I said, "Cramer (C)".
I think I meant to say, "Cohen (C)".
Sorry for the mix-up.
Actually, electronic voting *is* unsafe.
t .html
I did my Master's work on this topic.
There are two major types of modern electronic voting schemes. The first type is based on the work of Fujioka, Okamoto, and Ohta (FOO). The second type is based on the work of Cramer (C).
For a good introduction to all of the problems associated with electronic voting, look up web publishings of Lorrie Cranor, who also developed a (FOO)-type scheme. A good link is http://www.ccrc.wustl.edu/~lorracks/sensus/hotlis
The major problems stem from trying to assure simultaneously that the election is tamper-proof, and that ballots are secret. This turns out to be very difficult. Even paper-ballot elections aren't really very good (e.g. Kennedy-Nixon presidential election, Chicago, "vote early, vote often"), but they have the virtue that to corrupt them an attacker must physically handle lots of pieces of paper in lots of different places.
(FOO)-type schemes try to use 'blind signatures' to let voters get a ballot using their real identities, then cast it using 'blinded' identities. However, blind signatures aren't perfect, and in particular schemes of this type let voters prove how they voted, which could lead to vote coercion or the selling of votes.
(C)-type schemes don't try to blind the identity of the voter. Instead, voters encrypt their ballots in a special manner, and submit them to a trusted group of individuals. This trusted group first combines all the encrypted ballots, then (by virtue of the special encryption) obtains the election result by decrypting the combination. Here, voters trust a relatively small group of officials not to collude to decrypt votes singly, thus revealing how each voter voted.
There is no clear solution to these problems, and the cutting edge is not 'good enough'. The election in Arizona did not use a type of scheme even as good as either of the ones I describe above. Instead, a private company is trusted to count and announce the results (BTW, it seems that nobody could prove that they did not invent the results they wanted), and to keep the identities of voters seperate from their votes (they have one database of voters vs. IDs, and another database of votes vs. IDs, and they swear that they won't cross-reference by ID).
Really, e-voting isn't ready for prime-time.
It is? What is the point of having a cheap bicycle lock that you are absolutely, positively sure will not stand up to a determined attempt to break it?
Well, the point is, it stops a casual thief. A bicycle lock (cheap or not), as you describe, has low security and high assurance. Anybody willing to get some liquid nitrogen (cheap, BTW), can get by your lock no matter how great it is. But, somebody walking down the street who spontaneously thinks, "that's a nice bike," is thwarted. The brute force attack (liquid nitrogen) will defeat the security, but otherwise somebody has to have the key to get the bike.
Similarly, a situation where you don't do much to prevent people from coming and going, but are sure that their activities are on a security tape (for example, an ordinary bank) calls for low security, high assurance. That is, the bank robber can easily get the teller to hand over the money (that's how tellers are trained, in fact), but we are confident that the police will catch the robber later (and bank robbers are almost universally caught). Anyway, you say that I described class C2 protection. To be honest, I haven't read the Orange Book enough to debate you here. But, I suspect that levels like A1 describe even better assurance than C2 -- but that you can't get credit for those levels of assurance without also having A1 security.
FWIW, it seems worthwhile to point out that "Orange Book" classifications are not all that well thought-out. The problem is that they tie increased security to increased assurance.
It is extremely difficult to establish a high-security system while simultaneously having a high assurance that it is correctly implemented. OTOH, it is often useful to have a low-security, high-assurance system, and the Orange Book doesn't pay much attention to this case.
Indeed, if audit is the only really interesting property in this case, it sounds as though low-security (mostly logging) high-assurance (logging cannot be defeated even by 'creative' users) is exactly the solution that is needed.
The first time IBM thought along these lines, it was wrong and gave MS a foot in the door. Now, still thinking along these lines, IBM seems to be correct, and liable to take away significant MS market share.
Without the initial blunder, it seems we wouldn't have a major corporation throwing its weight behind an open-source OS.
It's funny how these things work out.
Here is the part that really ought to make you nervous (the rest is just policy, really):
``Electronic signatures provide a level of authentication that far surpasses the ink signature that has
come to be the accepted standard,'' said Virginia Republican Thomas Bliley, chairman of the
House Commerce Committee. ``Electronic transactions have much less of a chance for human
error and provide for more reliable retention after the initial transaction takes place.''
The implication that digital signatures magically sprinkle improved security on stuff is utterly bogus. While the signature algorithms themselves might be quite secure, there exists *no* acceptable (or even legally recognized) public key infrastructure that provides secure and reliable identification of public keys.
That is, if I give you my public key in person, then you can verify my signatures with confidence. If you just look it up in a directory somewhere, you are really trusting the maintainer of the directory. Who do you trust to link your name with your public key? If that entity turns out to be untrustworthy, you are the potential victim of e.g. man-in-the-middle attacks.
I think that digital signatures are a good thing that should gain legal standing. However, I think that there are significant infrastructure issues that should be resolved first. I did my master's work on electronic voting, which essentially requires little more than electronic signatures. I feel the same way on that subject: someday we should have it, but we need to iron out a *lot* of details.
The number one issue to address is that of educating the public about basic public key cryptography. As far as I'm concerned, it should be taught in grade school. The basics aren't that difficult to grasp, and a public aware of the issues would contain far fewer potential victims than an ignorant one.
Use Java for the remote procedure calls, but only for that. You can talk back and forth between Java and C, you know. I've actually done this; I wrote a C program that used the JVM libraries to make RMI calls to another machine that ran a small Java application that received them.
You can be clever with threads, too, so that in your client you can make a call (that immediately returns) that dispatches a thread to perform the RMI call and do something when it returns. The thread is a standard Java thread, even though you're using C to instantiate it! I've done this with good success (admittedly not for a big huge highly important expensive project).
RMI is simple and easy to use. That doesn't mean that you have to be a slave to the restrictions of Java (performance, etc.) everywhere in your code. Your network calls aren't expected to be that fast, anyway, so the layer that makes them may as well be a Java one that has clean, well-enforced, standard semantics.
I am not extremely knowledgeable about these things. FWIW, it doesn't seem to me that Oracle and DB/2 are significantly different in terms of 'solidness'. Both are major players at the high end of database use (and IBM seems to claim that DB2 houses the world's largest data collections, at the moment).
/.) is that some people have had very nice things to say about DB/2's documentation and usability. Many people talk about how Oracle is arcane and requires lots of specialized knowledge, and this is why you see Oracle admins getting paid the big bucks.
One thing I do recall reading (I think here on
If you don't already have an Oracle Database Administrator on staff, you have a lot more freedom than many places that are shopping for a database.
In terms of filesystems, note that journaling is a reliability feature, not a performance feature (but no less important for being so).
The whole (real or perceived) problem of filtering inappropriate content is really a special case.
The more general problem is, "how should we index the web?". It's the digital library problem, really.
What we really want is a way to look up exactly the information that we want, getting pointers to all relevant sources and to no irrelevant sources.
For the censorship people, what they want has to do with the keyword 'smut' (and friends). If I look up smut, I should get all and only smut. If I look up something else, I should get no smut.
If the larger problem gets solved, the "censorship" problem is much simpler, and also shouldn't bother those who don't consider it an issue.