Buggy Voting Systems in New Jersey
Ed Felten has posted two articles describing bugs in New Jersey’s electronic voting systems. Briefly, the total votes for all of the candidates add up to more than the number of votes the machines believe were cast. That such bugs exist should surprise no one. I’ve posted twice about why bugs are a bigger threat to elections than security issues. (To be sure, buggy code is likely to be insecure code. As Robert H. Morris once said in a talk, "If our code is buggy, what does that say about its security?")
Sequoia’s explanation — which, Felten points out, is inadequate — is not reassuring. Read the memo yourself; basically, though, they’re blaming operator error combined with dubious code choices. Even if their analysis is correct (and again, Felten points out why that seems implausible), it doesn’t excuse things. I very carefully titled this post "Buggy Voting Systems", not "Buggy Voting Machines". Everything — the machines, the poll workers, the process used, even the voters — work together. One component — the voters — is more or less fixed; the rest of the system has to be designed to produce the right result. Machines that produce impossible audit tapes in the presence of poll worker errors are simply broken. Errors should be detected and reported as such; they should not be accepted as excuses for machines that report more total votes cast than voters who cast ballots.
An Outage from Managing P2P Traffic?
I have cable modem service from Comcast. Yesterday, that service was down for eight hours. In fact, many of their Internet customers in New Jersey, Pennsylvania, and Delaware were off the air for that long — and I believe that the problem was due to Comcast’s attempts to manage peer-to-peer traffic.
Network outages at 6:00 on a Saturday morning are neither unknown nor unreasonable. In fact, that’s probably a good time for routine maintenance and upgrades. This one, however, went on far too long. (I know the article says the problem started at 7:00. I noticed the problem at 6:00 and my log files are quite unambiguous; my connectivity problems started an hour earlier than the story indicates.)
The symptoms were odd. I could reach a few sites, but not many. I could, however, ping web sites I couldn’t connect to. I ran traceroute; it showed a normal-looking path to failing sites. However, both ping and non-Windows traceroute use ICMP; web connections use TCP. Was ICMP working, when TCP was not?
I used a traceroute variant that I wrote, which can use UDP or TCP. The results were decidedly odd. UDP traceroutes would go 8 or 9 hops within Comcast’s network, then stop. TCP traceroutes went nowhere. But ICMP traceroute went the full distance. Other tests I did, by using twisty paths to log in to a server I control, showed the same thing: TCP packets were not making it from my house to the server; ICMP packets were.
Treating ICMP, UDP, and TCP differently is not a normal mode of operation for an ISP backbone. In fact, I have no idea why an ISP would do it, unless they were trying to treat some traffic differently. And we know that Comcast is trying to manage peer-to-peer traffic. Is that what happened?
Boxes and distributed systems can fail. The more boxes you have that you rely on, the greater the risk of an outage and perhaps a widespread outage. It seems likely that this is exactly what happened yesterday: because they are trying to restrict peer-to-peer traffic, many people were off the air for many hours. A major underpinning of the Internet’s design was a desire to get away from "must be there" elements. We seem to have taken a step backwards.
Update: In a mailing list message, Declan Forde, a Comcast executive, stated that
We had a routing issue in the PA and NJ areas yesterday that impacted some customers’ ability to reach certain sites. This had nothing to with P2P traffic management.I’ve asked him why TCP, UDP, and ICMP appear to behave differently; that, after all, is why I speculated on the connection to P2P. When I get an answer, I’ll post it here.
Ships Impounded in Cable Cut
A couple of months ago, there was a undersea cable cuts that affected much of the Middle East and Asia. Today, there are press reports that two ships have been impounded for causing the problems off of Alexandria.
The article says that Reliance Globalcom, the owner of the FLAG cable, had identified those two ships after "studying satellite imagery of ship movements around the breakage area". That’s a good way to do it — but why are there suitable satellite images? There are a number of satellites whose imagery is readily purchasable; is near-realtime coverage that good without prearrangement? There are already conspiracy theories being discussed on the NANOG mailing list…
And the root cause? This might be it:
At the time of the cuts, a Flag spokesperson said that ships in Alexandria had been asked to anchor in a different place to normal, around 8.4km off the beach.
We can all put away our tin foil hats now…
Comcast Outage: Not P2P-Related
A couple of weeks ago, I posted a note speculating that the outage I experienced was due to a problem in the gear Comcast was using to manage peer-to-peer traffic. After correspondence with some of their network engineers, I’m happy to say that I was wrong. Here’s the short form of the explanation:
We encountered a memory limitation on a handful of our core routers in the PA-NJ area triggered by an external routing event. The switching mode of the routers changed in that situation. In this new mode, subscriber traffic was subjected to an internal infrastructure security policy that permitted ping and traceroute but denied TCP traffic. This caused the discrepancy of website reachability based on subscriber location and the idiosyncratic ping and traceroute behavior.So — I apologize to Comcast, and I’m quite happy with their willingness to discuss this with me further.
PayPal is Wrong About Unsafe Browsers
PayPal has released a white paper on anti-phishing techniques. While there are some good suggestions in the report, other ideas of theirs are seriously flawed.
The biggest error (Section 4.4) is the notion that browsers that support Extended Validation (EV) certificates are somehow safer. The theory is that these certificates, which are issued only after more validation of the web site, are displayed in a green URL bar in the browser. (Currently, that feature is in IE7 and later and Firefox 3; it is not in Safari or Opera.) The theory is nice; the problem is that it doesn’t work: users don’t notice it and fall for attacks that emulate it. Nor will education help; to quote the paper’s abstract, "reading the help file made users more likely to classify both real and fake web sites as legitimate when the phishing warning did not appear." (Our own research shows that other authentication indicators in the browser’s "chrome" are not very effective at preventing phishing attacks.)
PayPal, of course, disagrees. They say that
For example, we’re seeing noticeably lower abandonment rates on signup flows for IE7 users versus other browsers. We believe that this correlates closely to the user interface changes triggered by our use of EV certificats.It’s an interesting theory, but I’d sure like to see evidence beyond "we believe". And of course, even if correct it proves little, since the attacks aren’t in the wild yet.
What should PayPal do? I have no objection to them blocking known-buggy browsers. Indeed, that would be a very positive step forward. More generally, they should block browsers that make it too easy for evil web sites to install their own software on users’ computers. But that won’t happen, since by some very plausible definitions that would bar any browser that supports ActiveX, which includes all of Microsoft’s versions…
Another questionable idea in the paper is the notion that all email should be signed using DKIM (DomainKeys Identified Mail) signatures. The idea is that forged mail purporting to be from, say, PayPal would be signed by a key controlled by PayPal. That’s good as far as it goes, but it doesn’t go very far. The two biggest problems are that first, there is no way of knowing a priori that mail from a site should be digitally signed; second, there’s no way of knowing a priori what the real site name should be.
Perhaps PayPal is big enough that major ISPs will configure their mailers to look for DKIM signatures. What about others? Suppose I set up my own online payment scheme — should my email be DKIM-protected? How would ISPs and mail providers know this? The DKIM standard leaves that open:
In general, verifiers SHOULD NOT reject messages solely on the basis of a lack of signature or an unverifiable signature; such rejection would cause severe interoperability problems. However, if the verifier does opt to reject such messages (for example, when communicating with a peer who, by prior agreement, agrees to only send signed messages), and the verifier runs synchronously with the SMTP session and a signature is missing or does not verify, the MTA SHOULD use a 550/5.7.x reply code.The DKIM signing practices requirement document points out the same failing.
Beyond that, what is PayPal’s real web site? More precisely, what are their real websites? Sure, they own paypal.com. Is there a premium version called paypalplus.com? (At the moment, that web site exists but appears dubious — it has links for things like "Paypal Credit Card" and "Make a Credit Card Payment" that do no such things.) Overseas? Is paypal.ru theirs? (Right now, that site’s English version says "This site is not related to the PayPal, Inc. (online payment system) at the moment" [emphasis added]; as best I can translate the Russian, it says the same thing. But citibank.ru is legitimate; it’s even linked-to from citibank.com.
There are more issues, including especially privacy; I’ve written about them elsewhere. Digitally signed mail can be a very powerful technology, but it won’t solve the phishing problem.
Other idea in PayPal’s white paper are correct, but almost universally ignored — including by PayPal itself (or rather, by Ebay, their corporate parent). For example, they say "don’t click on links in email" and "go directly to the Web site of the organization concerned". Excellent advice — but when I win an auction on Ebay, I get email that starts
Hi Steven, Congratulations on winning this item! The next step is to pay the seller.which will, after after a click or two, take me to a PayPal login page. Oops. (I’ve written about mistraining users in the past.)================================================================= Pay for it http://payments.ebay.com/ws/eBayISAPI.dll?…
So what should be done? PayPal’s own PayPal Security Key is a good idea as far as it goes, but it doesn’t go very far. It’s also remarkably hard to find that link starting at PayPal’s home page. (I do want to commend them for using https throughout their site; too few financial sites do that. But why, oh why, does their home page have a link to Doubleclick? To show that there’s a difference between confidentiality and privacy?) The problem with the Security Key is that it doesn’t guard against so-called man (or monkey) in the middle attacks. That is, if you go to a phishing site and use your PayPal Security Key, the site can capture the code and use it immediately. Sure, they can’t store it, but a lot of damage can be done in 30 seconds.
So what’s the right answer? There’s no space here for a full description of the right solution, but let me mention a few points. First, and as I noted earlier, authentication has to be tied inextricably to the public key (or certificate) of the site with which you previously interacted. Some sort of token needs to be used, because it’s rarely clear what text box for a password belongs to what site. The display on the token should display the name of the site it’s authenticating to. And only one authentication operation should take place per physical action (i.e., pressing a button, inserting the token, entering a PIN on the token) on the token itself.
New Jersey Supreme Court Protects Internet Users' Privacy
In an interesting ruling, the New Jersey Supreme Court ruled that Internet users have a "reasonable expectation of privacy in their identities while accessing Internet websites". [The quote is from the opinion’s syllabus, not from the actual binding opinion itself.] What makes this especially interesting is that New Jersey law protects personal privacy much more than the equivalent Federal provisions.
In this case, someone used a corporation’s login and password to a supplier’s site to change the corporation’s address, and then change the password to lock the corporation out of its own account. The supplier provided the IP address that made this change; the police got a municipal court subpoena to the ISP for the subscriber’s identity, and she was arrested and charged in short order. However, NJ law does not permit the police to obtain subpoenas for such things, especially when they cite non-existent cases (see the opinion for details). Only a grand jury subpoena will suffice. The real issue, though, is whether the woman had a privacy interest in her identity, given that her IP address was of course known to any site she contacted.
Both the Federal and New Jersey governments are constrained by their respective constitutions. The Federal provision, in the Fourth Amendment, reads
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no warrants shall issue, but upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.The New Jersey text is almost identical:
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated; and no warrant shall issue except upon probable cause, supported by oath or affirmation, and particularly describing the place to be searched and the papers and things to be seized.However, the interpretations are very different.
The Federal interpretation is given in Smith v. Maryland, 442 U.S. 735 (1979). In it (and quoting myself),the Supreme Court ruled that phone numbers were voluntarily given to a third party — the phone company — and that the caller thus had no legitimate expectation of privacy. It noted that
Petitioner concedes that if he had placed his calls through an operator, he could claim no legitimate expectation of privacy. We are not inclined to hold that a different constitutional result is required because the telephone company has decided to automate.
New Jersey feels otherwise. Its Supreme Court has ruled that the New Jersey constitution "affords our citizens greater protection against unreasonable searches and seizures". In Doe v. Poritz, 142 N.J. 1 (1995), the court noted "a constitutional right of privacy … including the disclosure of confidential or personal information". Accordingly, in a case very similar to Smith (State v. Hunt, 91 NJ 338 (1982), not online in any free source I can find), the New Jersey court held that
Under New Jersey law, a telephone subscriber has a reasonable expectation that the calls he makes will be utilized only for the accounting functions of the telephone company and that he cannot anticipate that his personal life, as disclosed by the calls he makes and receives, will be disclosed to outsiders without legal process.because "he is entitled to assume that the numbers he dials in the privacy of his home will be recorded solely for the telephone company’s business purposes." This is an important distinction: people give the phone company — or ISP — a phone number or an IP address for a specific purpose. It is not a general grant, nor are the resulting records the property of the communications carrier with regard to future legal processes. The caller has a privacy interest in them, not the carrier. This is very much in accord with one element of the Code of Fair Information Practices: "There must be a way for a person to prevent information about the person that was obtained for one purpose from being used or made available for other purposes without the person’s consent."
I applaud this ruling by the New Jersey court.
The Fate of Old Hardcopy Journals
I’ve been a member of the ACM for about 35 years. I have a collection of their publications to match. Should I keep them?
There’s little doubt that the form factor is obsolescent at best, and probably obsolete. The ACM Digital Library has the "full text of every article ever published by ACM," so I don’t really need all that hardcopy. What should I do with it?
The obvious answer is to send it to my neighborhood recycling center. The knowledge, after all, still exists. But there are lots of people who don’t have access to the electronic form, especially outside the U.S. In fact, I’m told that the single biggest use of stolen Columbia University logins is to download papers via the university libraries’ subscriptions to many electronic journals.
Should I donate my old journals? To whom? At whose expense? (Shipping around that much paper is expensive, both in dollars and in carbon consumption.) Is there a better solution? What have you done with your old journals?
