June 2006 Archives


June 30, 2006

The Tour de France riders list has been more or less decimated due to accusations of blood doping (autologous transfusions rather than drugs, but still banned). Suspended riders include the two pre-race favorites, Ullrich and Basso. I guess it's too late for me to get in shape and sign up, though....

June 29, 2006

Clayton et al. have a new paper about the Chinese content filtering firewall and how to defeat it. The basic observation is that the firewall doesn't actually block traffic that it doesn't like--that would require too much work on the part of the router--but rather forges TCP RST packets. If the endpoints ignore the RSTs then they can communicate without interruption.

Of course, RSTs aren't the only way to DoS a TCP connection. One obvious approach is to inject bogus traffic. If you're lucky and hit the HTTP headers (e.g., by forging packets immediately after you observe the SYN or SYN/ACK), this will cause one side to abort the connection. Interestingly, secure channel protocols can make the problem much worse: TLS, for instance, aborts the connection if it detects any MAC error (this is a common complaint about TLS but is pretty inherent in running it over TCP). You can, of course, make protocols that are much more resistant to this form of attack--IPsec for example, but it more or less has to be done below the TCP layer.


June 28, 2006

The Michigan Supreme Court has upheld a law which makes it illegal to drive with any detectable amount of marijuana in your system. As Jacob Sullum points out, this is, kind of nuts. Marijuana stays in your system for days to weeks after you're no longer intoxicated. What I wonder about is the standard required for testing; in most states just by driving you're considered to have consented to chemical testing for alcohol. In the particular cases that are the the subject of this suit, there was evidence that the offenders had smoked marijuana, but I wonder if you can just be stopped and randomly tested.

June 27, 2006

News.com reports that AOL, EarthLink, Microsoft, United Online and Yahoo are going to cooperate to block child porn.
The system works like this: When AOL employees become aware of a child pornography image included as an e-mail attachment, they forward the attachment and information about the sender's geographic location to the National Center for Missing & Exploited Children, which in turn sends it to the appropriate law enforcement agency. AOL also generates a digital fingerprint of the image so it can be automatically flagged if it flows through the company's network in the future.


Another possibility, Schoen said, is that child pornographers who know how the system works would simply make a tiny tweak to photographs to avoid detection--rendering the hash detection system useless. Internet providers could counter-attack using a "locality sensitive hash" function that's designed to detect similar files, but even that in turn could be foiled if image files are encrypted.

Schoen is quite right, of course. Cryptographic hashes are particularly poorly suited to this problem because the whole point is for them to be sensitive to even single-bit errors. There certainly are fuzzier hashes but pretty much any hash function you use is going to be easy to defeat by even simple non-cryptographic transformations in the data, let alone by encryption.

There are two challenges to making an encryption scheme work here. The first is that because ciphertext is so high entropy it's generally fairly easy to detect. The good news is that compressed images in general are very high entropy anyway, so ciphertext is fairly easy to hide there using standard steganographic techniques work. There are techniques for detecting steganography but they're not superfast and the job can be made arbitrarily difficult if you're willing to accept a suitably low coding rate.

The second challenge, is to design a scheme that doesn't require the communicating parties to exchange cryptographic keys. You could of course just carry the key in the message. This would still produce a basically random ciphertext which would defeat simple hash matching--until the ISPs reverse engineer your data format and figure out how to extract the encryption keys that is. However, there's a simple workaround use a short encryption key (say 24 bits or so) but don't put it in the message. The recipient just exhaustively searches the key space, which doesn't take long. Obviously, the ISPs could do the same thing but they're at a very severe disadvantage because they have to scan every candidate message--which is basically impractical--whereas you just need to scan the ones sent to you.


June 26, 2006

CBS News reports that Rush Limbaugh has been detained at the Palm Beach Airport:
CBS4 News) WEST PALM BEACH Sources have confirmed to CBS4 News that conservative talk show host Rush Limbaugh has been detained at Palm Beach International Airport for the possible possession of illegal prescription drugs Monday evening.

Limbaugh was returning on a flight from the Dominican Republic when officials found the drugs, among them Viagra.

Limbaugh entered a plea deal back in April in a previous case where his charge of fraud to conceal information to obtain prescriptions was dropped under the condition he continue undergoing treatment for addiction.

What's weird about this story is that Viagra isn't at all hard to get legally. If you're too embarassed to ask your doctor, lots of online pharmacies will "diagnose" you, write you a scrip for the Erectile Dysfunction meds of your choice (this variety pack is pretty clever), and ship them to you FedEx. Now, it's true that Internet pharamacies are a bit of a gray area, but it's not like you're going to get arrested for it. So, why would you bring in drugs from outside the country, which is pretty clearly (illegal), though seldom prosecuted.

Now, this would make more sense if the drugs in question were opiates, which are in general harder to get and probably even harder for Limbaugh, given his history. But if he was bringing in opiates, why don't the news reports say anything about them? Very puzzling.

UPDATE Turns out that the story is that his prescription was in his doctor's name, apparently for privacy purposes. Probably not the best decision.


June 25, 2006

Date hiked: June 16-18
Sections hiked: Escondido Camp to Higgins Camp
General condition: Difficult

The descent from Escondido to Arroyo Seco is clear with obvious tread. The river crossing is fine but getting back on the right trail afterwards is a bit tricky. The section from Escondido to the ridge line is in reasonably good shape with clear tread. Descending to Fish Camp, the trail gets increasingly overgrown and after Lost Valley Camp you have to push through brush about half the time. Both of us ended up with scratches all up and down our arms. Based on the rather complete spider webs on the trail, it looks like it's not getting much use. The trail improves a little bit between Pelon and Higgins, but it's not still fairly bad.


June 23, 2006

In response to criticism over adult/child contact, MySpace is instituting some new security measures:
In trying to allay the public, MySpace.com, which is owned by Rupert Murdoch's News Corp., put in place Wednesday added security for 14- and 15-year-old members, new options for privacy settings for all members and restrictions on ad placements to teens.

"MySpace is committed to innovating new product features to heighten online safety, particularly in the area of 14 to 15 year olds," Hemanshu Nigam, chief security officer for MySpace.com, said in a statement. "In addition to technology innovation, MySpace remains dedicated to a multi-pronged approach that also involves education and collaboration with law enforcement, teachers, parents and members."

MySpace.com recently hired Nigam, a former federal prosecutor against Internet child exploitation for the U.S. Department of Justice, to oversee its child protection measures.

The added security features include preventing a person 18 or older from contacting a member under 16 years old, unless he knows either the email address or first and last name of the minor.

I understand that people are concerned that adult "predators" will contact children on MySpace, but it's hard to believe that this is really going to work, depending, as it does, on voluntary compliance on both sides. If you're an adult looking to have sex with children (illegal, remember) then it's not like you're going ot mind lying about your age. On the flip side, if 14 and 15 year olds want to talk to adults and be taken seriously (which I remember wanting to do when I was under-16) they're likely to lie about their age, no? Absent some sort of externally verifiable age verification system, it's hard to believe that MySpace can really do much enforcement.


June 21, 2006

The West Wing Episode 1: Pilot (reformatted):
Mary: I dont like what Ive just been accused of.

Toby: [raising his voice] I'm afraid thats just tough, Mrs. Marsh.

Van Dyke: The First Commandment says "Honor thy Father".

Toby: No it doesnt.

Josh: Toby--

Toby: It doesnt.

Josh: Listen--

Toby: No, if I'm gonna make you sit through this preposterous exercise, were gonna get the names of the damn commandments right.

Mary: Okay. Here we go.

Toby: "Honor thy Father" is the Third Commandment.

Van Dyke: Then whats the First Commandment?
A booming voice comes from off screen. The camera moves to show PRESIDENT JED BARTLET with a cane standing in the doorway with several Secret Service agents.

President Jed Bartlet: "I am the Lord your God. Thou shalt worship no other God before me." Boy, those were the days, huh?

Congressman Lynn Westmoreland on the Colbert Report:

Colbert: You co-sponsored a bill requiring the display of the Ten Commandments in the House and the Senate. Why was that important to you?

Westmoreland: Well, the Ten Commandments is not a bad thing for people to understand and respect.

Colbert: I'm with you.

Westmoreland: Where better place could you have something like that than in a judicial building or in a courthouse?

Colbert: That is a good question. Can you think of any better building to put the Ten Commandments in than in a public building?

Westmoreland: No. I think if we were totally without 'em we may lose a sense of our direction.

Colbert: What are the Ten Commandments?

Westmoreland: What are all of them? You want me to name 'em all?

Colbert: Yeah. Please.

Westmoreland: Don't murder. Don't lie. Don't steal. Uh... I can't name 'em all.

Colbert: Congressman, thank you for taking time away from keeping the sabbath day holy to talk to us.


June 20, 2006

Forbes reports that the Bush Administration is considering responding to North Korea's impending missile test by trying to shoot down the missile.
The Bush administration is weighing responses to a possible North Korean missile test that include attempting to shoot it down in flight over the Pacific, defense officials told The Associated Press on Tuesday.

Because North Korea is secretive about its missile operations, U.S. officials say they must consider the possibility that an anticipated test would turn out to be something else, such as a space launch or even an attack. Thus, the Pentagon is considering the possibility of attempting an interception, two defense officials said, even though it would be unprecedented and is not considered the likeliest scenario.

The officials agreed to discuss the matter only on condition of anonymity because of its political sensitivity.

Pentagon spokesman Bryan Whitman said he could not say whether the unproven multibillion-dollar U.S. anti-missile defense system might be used in the event of a North Korean missile launch. That system, which includes a handful of missiles that could be fired from Alaska and California, has had a spotty record in tests.

The first thing you need to know here is that although this is being pitched as the DPRK testing a missile that has "sufficient range to reach U.S. territory", what we're talking about is a Taep'o-dong 2 (TD-2), with a range of under 3000 miles according to FAS. It's about 3700 miles from Pyongyang to Anchorage (pop 260,000), so even Alaska is pushing things pretty substantially. We're not talking about the DPRK nuking LA here.

The second thing you need to know is that the US "missile shield" doesn't work in what you'd call a reliable kind of way, even in pretty favorable tests, and hasn't really been tested at all in situations where the missile isn't cooperating. Sure, we might hit some missile fired by North Korea, but it's not something you'd want to bet money on.

Now, obviously if we know that the DPRK has launched a missile that's intended to land in the US, then it's worth trying the defense system. Even if it doesn't work, what's there to lose. But based on my imperfect understanding of the technology and the news coverage, it appears that at the point where we have to make the decision, we can't tell enough about the targetting to know one way or the other.

Given that assumption, let's do the case analysis here. Either the DPRK is up to something more nefarious than a missile test or it's not. If they're not up to something nefarious and we don't try to intercept the missile, then they get to test their missile and the US look slightly weak. If we do try to intercept the missile and it works, then the US gets to look tough and it provides some deterrent against future ballistic missile attack. On the other hand, since single-missile attacks are stupid (more on this later), it's not much of a deterrent. On the other hand, if we try to intercept the missile and the defense system fails (which is the most likely case), the US looks stupid and it confirms what people already expected; that the missile defense system doesn't work.

Now consider the case where the DPRK is up to something nefarious. Maybe Kim Jong Il is afraid of grizzly bears or is pissed he never got to compete in the Iditarod. Anyway, they decide to attack Alaska. If we don't attempt to intercept the missile, it either works or it doesn't work (e.g., doesn't reach the US or misses or something). If it doesn't work but it's clear that they tried to attack us, we presumably attack the DPRK, which surely isn't something they think it's desirable. If it does work, we almost certainly attack the DPRK. Given that the DPRK has nukes and could attack us in a much simpler, effective, and most importantly deniable fashion by shipping a nuke into one of our ports, it's hard to see why they would take this particular tactic.

Finally, consider the cases where they're up to something nefarious and we do try to intercept. If it doesn't work, then we're back to the cases in the previous paragraph. If, on the other hand, by some miracle it works, then we've managed to save the land of the midnight sun. Congratulations!

Obviously, you can assign your own probabilities to these cases, but it seems to me that this decision requires weighing the very small chance of a good outcome (the chance that we're actually being attacked times the chance that the the system will work) against the very high chance of looking incredibly stupid if the system doesn't work.

WaPo reviews Ron Suskind's One Percent DoctrineJack Balkin):
Which brings us back to the unbalanced Abu Zubaydah. "I said he was important," Bush reportedly told Tenet at one of their daily meetings. "You're not going to let me lose face on this, are you?" "No sir, Mr. President," Tenet replied. Bush "was fixated on how to get Zubaydah to tell us the truth," Suskind writes, and he asked one briefer, "Do some of these harsh methods really work?" Interrogators did their best to find out, Suskind reports. They strapped Abu Zubaydah to a water-board, which reproduces the agony of drowning. They threatened him with certain death. They withheld medication. They bombarded him with deafening noise and harsh lights, depriving him of sleep. Under that duress, he began to speak of plots of every variety -- against shopping malls, banks, supermarkets, water systems, nuclear plants, apartment buildings, the Brooklyn Bridge, the Statue of Liberty. With each new tale, "thousands of uniformed men and women raced in a panic to each . . . target." And so, Suskind writes, "the United States would torture a mentally disturbed man and then leap, screaming, at every word he uttered."



June 19, 2006

There's obviously a lot of interest in working on various enhancements
to Web and Web Services applications. Unfortunately, after reading
the various drafts and mailing list postings produced by the proponents
of various technologies, I don't come away with the sense that people
have a common view of what is needed. This message is a first cut
at a taxonomy of requirements/features and technical options.


June 18, 2006

Following up on Scott D's comment recommending Zanfel, I found this very interesting review article on poison ivy-induced dermatitis. Probably the most interesting bit is:

Systemic steroids are the standard treatment for severe Toxicodendron dermatitis. The typical dose of oral prednisone is 0.5-2.0 mg/kg/day (usually 1.0 mg/kg/day) tapered over a 14-21 day period.2, 6, 8, 34 Based on the results of one study,50 three-weeks is a reasonable duration, although this aspect of treatment is debated. If steroids are stopped earlier than 14 days after onset of dermatitis, the eruption will "break through".3 Alternatively, intramuscular triamcinolone acetonide, 1.0 mg/kg, naturally tapers over 3-4 weeks and, in the author's experience, compliance is 100%,35 and there are less acute side effects such as emotional lability, water retention, hyperactivity, and increased appetite. Rare side effects of corticosteroid use include exacerbation of gastric ulcers, diabetes, hypertension, and rarely, avascular necrosis of the hip.49 Corticosteroids decrease inflammation by reversing increased capillary permeability and by suppressing neutrophil activity. Corticosteroids reduce itching by inhibiting a delayed type hypersensitivity response.


While systemic steroids are extremely effective when indicated, it is common for patients to seek further treatment for Toxicodendron dermatitis after receiving a dosepak of methylprednisolone. This 6-day treatment regimen contains the equivalent of 30-25-20-15-10-5 mg of prednisone on each of the six days. This is a lower and shorter dose than will effectively treat Toxicodendron reactions.8, 49 The dermatitis 'recurs' because it requires at least 3 weeks to run its course,50 and stopping the steroids merely allows the natural disease to "come out of hiding."

This appears to be a fairly common mistake. I've been prescribed dosepaks before, and at least once noticed the rebound effect. Clearly this is something to mention if you have to go to the doctor for steroid treatment. The only article I was actually able to get a copy of was:

Brodell RT, Williams L. Taking the itch out of poison ivy. Are you prescribing the right medication? Postgrad Med. 1999;106:69-70.

This article cites a bunch of others (note that I haven't been able to actually get copies of them):

Ives TJ, Tepper RS. Failure of a tapering dose of oral methylprednisolone to treat reactions to poison ivy. JAMA 1991;266(10):1362
Baer RL. Poison ivy dermatitis. Cutis 1986;37(6):434-6
Wooldridge WE. Acute allergic contact dermatitis: how to manage severe cases. Postgrad Med 1990;87(4):221-4
Funk JO, Maibach HI. Horizons in pharmacologic intervention in allergic contact dermatitis. J Am Acad Dermatol 1994;31(6):999-1014

To make things even better this article claims that oral antihistamines don't help the dermatitis at all (there's actually a controlled trial indicating that they don't) though they may make it easier to sleep. As I've long suspected, neither does 1% hydrocortisone cream. Hydrocortisone cream + oral antihistamines is of course the standard treatment you get if you show up at your doctor with poison ivy. Topical antihistamines don't work either.

As for Zanfel, there's a single controlled trial that indicates that it works early on and an apparently uncontrolled one that indicates that it works four days after exposure. I don't have any reliable anecdotal data one way or the other.


June 16, 2006

I'll be out in the Ventana Wilderness through Sunday. Blogging should resume then, assuming I'm not eaten by poison oak.

June 15, 2006

Flonase, one of the first line corticosteroid nasal sprays (for allergic rhinitis, etc.) is now available in generic from PAR pharmaceutical. When you look on the box, though, you notice something interesting: it's actually made by GlaxoSmithKline, the people who make Flonase: [*]:
First-quarter sales growth was driven by fluticasone propionate nasal spray. In February, Par announced that it entered into a supply and distribution agreement with GlaxoSmithKline (GSK) in the U.S. to distribute the product. Fluticasone propionate nasal spray is fully substitutable for GSK's allergy spray Flonase and is manufactured by a GSK subsidiary. After a restraining order temporarily halted distribution of generics, shipments of Par's product resumed in March. In the first quarter, fluticasone achieved sales of $57.8 million.

I'm not an expert on generic drugs, but my impression was that mostly the manufacturing was done in different plants operated by the generic manufacturers, rather than by the original patent-holder. Of course, you can still buy Flonase at a rather substantial markup. I believe this is what's known as "price discrimination".

Interestingly, generic Flovent (the inhaled aerosol version of the same drug) does not appear to be available yet. I wonder if this has anything to do with Flovent changing their propellent over from CFCs.


June 14, 2006

One of the big concerns people have about RFID systems such as RFID passports is that they leak identity information. In your most simple RFID protocol, the reader sends out a probe signal and the transponder (passport, tag, etc.) responds with its stored data. In the case of a price tag, it's some sort of identifier for the product and likely a unit-specific number. For a passport, it's your name, biometric information, etc. This protocol has two main drawbacks. First, any passive observer can capture your information. Second, anyone who can build or buy a reader can capture it.

The simplest fix for this is to encrypt the data on the token using some static key known to all the readers in an organization. This partially solves the problem of someone buying a reader on the open market--since they won't have the right key, but only partially. First, since the encrypted data is static, you can still track people even if you can't read their data. Second, it's subject to a catastrophic failure mode: if the attacker can get a reader with a valid key--or just the key--then he can decrypt the data. Nevertheless, this is the best we can do with a memory-only card. 1

If you're willing to do processing on the token, then you can do somewhat better: the reader provides its public key certificate. The token verifies the certificate and encrypts under the public key. This stops the tracking problem for readers without the key, but not for readers with the key. And since any reasonable-sized organization will have lots of readers, the probability that one will go missing is fairly high. In order to contain this, you need some kind of process for revoking readers, which makes life massively more complicated.

1.One exception is that if we have a side channel, we can encrypt the data with a per-token key communicated via the side channel. This has been proposed for passports (having the key printd on the passport) but doesn't really work for lots of applications, since much of the point of contactless cards is to avoid having to have such a side channel.


June 13, 2006

As I discovered today while sitting down to watch Transporter 2, the MPAA has decided to subject us to some free propaganda about how downloading movies is stealing. Better yet, they've marked the stop key (and fast forward, etc.) a user prohibited operation, so you can't skip past it. On the other hand, I did borrow the movie from a friend, which would probably be illegal if they had their way.

June 12, 2006

Schneier points to an article by Helena Handschuh from smartcard manufacturer Gemplus about how contactless smartcards (aka RFID) are no less secure than ordinary contact smartcards. Most of the paper focuses on the comparative difficulty of using side channel attacks to extract keying material. I'm not saying this isn't an important attack, but it's not clear it really represents the right threat model.

The concern that most people have about contactless cards isn't that they're going to be cracked but rather that they can be used to compromise your privacy: the attacker probes your card and gets it to identify itself and so at minimum you can be tracked. Cryptography can be used to protect against this to some extent (though actually getting it right can actually be quite tricky) and you can also store your contactless card in a RF shielded container (typically an aluminized mylar bag) but it's not really an issue for ordinary smartcards, which need to make physical contact with the reader. So, I don't really think it's fair to say that contactless smartcards are no inherently less secure.


June 11, 2006

One of the systems I work on has a feature that lets you add new functionality via loading shared libraries (i.e., plugins). This is a pretty conventional technique for programs like Apache, IE, etc. but we add a new wrinkle; there are multiple programs that all need to load the same shared object. For instance, if you want to add a new protocol decoder, you're actually adding it in three places:

  • Into the packet processing stack (the obvious place).
  • New commands into the management shell.
  • A statistics pretty printer into the statistics command line utility.

So, at some level here you actually have three plugins that work together, one for each application. You could do this as three separate .sos, but that makes for a nasty management problem, especially as the number of applications goes up, and of course it makes code re-use difficult. So, ideally, you'd like to just have one .so.

Getting something like this to work properly requires a fair amount of attention to dependencies (I'm assuming you know how to make a .so using ld -shared.) The simplest problem is that the plugins need to invoke functions that are in the main program. For instance, in the management shell we need to call functions in the main program in order to register our new commands. Normally, functions that are linked into the main program aren't exported to dynamically loaded objects, so you need to use the --export-dynamic argument to ld when you link the main program.

A secondary problem with this kind of reference is that there may be functions that plugins depend upon that aren't called anywhere in the program itself. Plugins need to be able to know they can call a specific API. In order to make this work, you need to force all the API functions to be linked into the application program (so they can be re-exported to the plugins). Basically, you do this by creating a new source file that references the API functions via placing a function pointer for the API function into some static variable. On UNIX-type systems, files are linked in one at a time, and the transitive closure of all references needs to be linked in. So, what you do is create some API forcing file which points to each API file (at least transitively) and then have that file export some variable that gets referenced in some source file that is actually used in the main program.

The above two techniques take care of making the functions we need available. Now we have to deal with the opposite problem, which is having things work when not everything is available. So, for instance, if we're writing an SSL processing module, it needs to reference OpenSSL in order to do its thing. But, the prettyprinter for its stats doesn't need OpenSSL. We don't want to force the stats system to link with OpenSSL just to print some values.

This is taken care of with two techniques. First, when we dynamically load modules, we call dlopen with the argument RTLD_LAZY. This tells it only to try to resolve functions when they're first referenced rather then when the library is loaded. This gets us part but not all of the way there. The second thing is that we need to compile our plugins with position-independent code---code which can run correctly no matter where the library is loaded into memory. With gcc, this is done with the -fPIC falg.

This is a simple fact and something I knew about, but when I started writing shared libraries for this system, I hadn't written one in a long time and I forgot -fPIC and yet all my shared libraries seemed to load and work properly so I never noticed the problem. Then I noticed that I was starting to have problems where even though I was loading with RTLD_LAZY, dlopen was still trying to resolve all the symbols referenced in the .so. This isn't just a code size issue: remember that the module needs to call functions in all the application programs, but the management shell doesn't provide the functions that are in the packet processing stack, so you get linkage errors. A little debugging resolved what appears to be the problem: if you don't provide -fPIC you get relocatable code and the linker automatically relocates it, but it tries to resolve all (or at least some) of the symbols even if they're not referenced, which, as I mentioned before, is bad.

So, to recap:

  • Forcibly link all the APIs that plugins can depend on.
  • Use --export-dynamic to make those APIs available to the plugins.
  • Compile your plugin code with -fPIC
  • Use RTLD_LAZY when you link in the modules.

Fun, eh?


June 9, 2006

The D.C. Court of Appeals has upheld the FCC's decision that "facilities-based broadband Internet access and interconnected VoIP services" need to provide CALEA access (see previous post here):
In a split decision, two of three judges on the panel concluded that the 2005 Federal Communications Commission requirement was a "reasonable policy choice" even though information services are exempted from the government's wiretapping authority.

The FCC has set a May 14, 2007, deadline for compliance, and the ruling drew praise from the FCC and the Justice Department, which sought the access.

"Today's decision will ensure that technology does not impede the capabilities of law enforcement to provide for the safety and security of our nation," the department said in a statement.

But the chief author of the 1994 wiretapping law, U.S. Sen. Patrick Leahy, criticized the court's decision, saying Congress had deliberately excluded the Internet when it wrote the wiretap law.

"The court's expansion of (the wiretapping law) to cover the Internet is troubling, and it is not what Congress intended," Leahy, a Vermont Democrat, said in a statement.

I'm not sure whether the FCC exceeded its authority or not, but I'm not sure it really matters one way or the other. First, the Bush Administration seems pretty aggressive about wiretapping without bothering to go through the standard legal channels. Second, the responses to revelations about Administration wiretapping suggest that it wouldn't be that hard for wiretapping proponents to revise the law to require CALEA access to this kind of system anyway.


June 8, 2006

Oh, one more thing: last time I logged into LinkedIn to accept one of these things it insisted that I was accepting their new user agreement and privacy policy, which basically say:
  1. You can't use LinkedIn for anything (you agree not to use it for communications which are "unlawful, libelous, abusive, obscene, discriminatory, or otherwise objectionable", which pretty much covers the space.)
  2. We can terminate your account at any time for any reason.
  3. You indemnify LinkedIn for any kind of damage resulting to anyone form your use of LinkedIn.
  4. We currently protect your privacy but in the future we might decide not to.
  5. "Any sensitive information that you provide will be secured with all industry standard protocols and technology". I guess this one means that they'll use SSL, IPsec, SSH, and S/MIME all together.

I guess if I actually used LinkedIn, I might want to export my data every so often so I couldn't be held hostage whenver they decided to change their policies. The link you want for that is here.

Periodically, one of my friends discovers LinkedIn and then the conventional thing seems to be to invite everyone you know, like this:
Lisa Dusseault has invited you to become a connection. Lisa will also become your connection.

Invitation date: April 11, 2006

Lisa's note:

I found you while I was searching my network at LinkedIn. Let's connect directly, so we can help each other with referrals. If we connect, both of our networks will grow. To add me as your connection, just follow the link below.

- Lisa

Anyway, I don't really use LinkedIn for my own contacts, but somehow it feels rude to just ignore these messages or (horrors!) reject them. So, despite myself I've ended up with a fairly extensive contact list. What now?


June 6, 2006

Reporting (rather dismissively) from the Human Enhancement Technologies and Human Rights conference, William Saletan writes:
De Grey, the guy with the beard, called for higher taxes and research funding to "end the slaughter" of human aging. He argued, incoherently, that our failure to do everything possible to stop aging this instant was tantamount to mass murder.

Maybe Saletan is saying that De Grey's argument is presented incoherently, but I suspect he's saying that the whole argument is incoherent, which I'm not sure I agree with. The basic argument here, that failure to do something that would prevent people suffering or death is morally equivalent to causing that suffering or death, though not particularly widely respected, has a respectable pedigree. Indeed, if you replace aging with world poverty in Saletan's statement above, you get pretty close to Peter Singer's famous argument about famine relief.

Saletan doesn't deign to argue against De Grey, he just calls him incoherent, but it seems to me that there are three basic arguments against what Saletan reports Grey to be saying:

  • We shouldn't do "everything possible" to cure aging because their are other important goals. I strongly suspect that De Grey would agree with this, at least as far as health goes, since dying of cancer isn't any better than dying of old age.
  • The whole concept of "curing" old age is silly. It's of course possible that life extension won't work, but it's also possible that it will. It's certainly not inconceivable that it will, and so it seems to me that as far as the relief of suffering and death goes, working on life extension has roughly the same status as working on cancer or HIV.
  • The usual action/inaction distinction; not working to cure something isn't the same as working to cause it. This is a perfectly reasonable philosophical perspective, of course, but I wonder if Saletan would be so glibly dismissive if the topic was whether we should fund AIDS research.

I certainly wouldn't put the point anywhere as strongly as Saletan suggests De Grey did, but I don't think that De Grey's position is incoherent either. Certainly, if life extension can be made to work, it seems like there are pretty strong moral arguments to be made for investing in it, just as there are strong moral arguments for investing in curing any other life threatening medical condition.


June 5, 2006

The FDA has followed up on its committee's recommendation and decided to allow Tysabri to return to market. For those who just tuned in, Tysabri appears to be an unusually effective MS drug with a rare but nasty side effect--risk of death from a brain infection called PML. This seems like a good thing, but as I argued earlier, it would have been even better to have let people make their own decisions rather than have the FDA make some global cost/benefit decision.

June 4, 2006

BBC reports that the Archiveus extortion virus has been cracked. The way that Archiveus works is that it infects your computer and then encrypts your files. In order to get the encryption key (password, whatever) you are instructed to go buy drugs from a particular web site to get the decryption password. Anyway, it turns out that the virus uses a static key for everyone and someone has recovered that key. 1.

One way to think of an extortion virus is as a particularly pernicious form of involuntary DRM. As with standard DRM systems, you want to design such a system so that it doesn't have catastrophic failure modes where compromise of a single instance leads to compromise of the entire system. Having a single symmetric key that does all the encryption is clearly a loser as far as this is concerned, as we saw with CSS. Even better, we'd prefer that reverse engineering the virus didn't buy you anything. On the other hand, you'd really like all of the virus copies to be the same.

Luckily, modern cryptography comes to the rescue in the form of public key cryptography. What you do is generate a public key pair and embed the public key (Kpub) in the virus. The virus author keeps the private key (Kpriv). When the virus goes to encrypt your files, it generates a random symmetric key (Ksym) and encrypts the files under Ksym. It encrypts the Ksym under Kpub (E(Kpub,Ksym)) and stores the result on the disk somewhere and then erases Ksym.2 At this point, the only person who can recover Ksym (and hence your files is the person who has Kpriv). No amount of analysis of the binary can recover Kpriv because the virus doesn't know it, and if it's written correctly, Ksym is long gone.

Of course, this design has one downside: because Ksym is different for each victim, you somehow need to get ahold of E(Kpub,Ksym) in order to recover Ksym. Given this particular method of recovering the money, the obvious approach is to require the user to cut-and-paste the value into some field in the order form, which kind of screws up plausible deniability for the vendor who's collecting the money, assuming they had any in the first place. An alternative approach is to have the virus send a copy of E(Kpub,Ksym) to the virus author along with your e-mail address. Then, when you order the drugs they look up your e-mail address and send you Ksym. Of course, if you're going to do things this way, then you don't really need public key at all: just send Ksym in the clear and assume (almost certainly rightly) that the victim isn't running a traffic recorder on their network and so won't capture it.

1. Come to think of it, it's not clear why this took analysis. If it gives the same password to everyone, surely this is something you could detect without any kind of reverse engineering.
2. When I first heard about extortion viruses a few years back from Paul Kocher, this was the technique he described.


June 2, 2006

The DoJ is starting to press ISPs to "keep records on the Web-surfing activities of their customers" [*].
The director of the Federal Bureau of Investigation, Robert S. Mueller III, and Attorney General Alberto R. Gonzales held a meeting in Washington last Friday where they offered a general proposal on record-keeping to a group of senior executives from Internet companies, said Brian Roehrkasse, a spokesman for the department. The meeting included representatives from America Online, Microsoft, Google, Verizon and Comcast.


While initial proposals were vague, executives from companies that attended the meeting said they gathered that the department was interested in records that would allow them to identify which individuals visited certain Web sites and possibly conducted searches using certain terms.

It also wants the Internet companies to retain records about whom their users exchange e-mail with, but not the contents of e-mail messages, the executives said. The executives spoke on the condition that they not be identified because they did not want to offend the Justice Department.

A few initial thoughts:

  • It's not purely a matter of data retention: it's not clear that the providers even have the records in question. Remember that the basic service that an ISP gives you is generic packet transit, which doesn't really require collecting any kind of records at all (your average router isn't exactly loaded with hard disk space). So, actually collecting this data could entail pretty substantial new equipment costs for the ISP.
  • Even if you did start collecting this data, you'd mostly have the IP addresses for the client and server, which might or might not let you identify which sites were being visited (see virtual host). The ISP could of course put a sensor (e.g., a Narus) on the wire to collect this data, but now you're talking real equipment costs.
  • If you're running some kind of application layer gateway like a Web proxy or an SMTP server (which is a very common way for end-users to send e-mail through their ISP) then you'd be more likely to collect this kind of information in server logs, so it's primarily an issue of storage cost then. Obviously, this goes double for search engines like Google which already collect your search terms as a matter of normal operation.
  • Keeping all this data around seems like it would entail a pretty substantial privacy risk. Do we expect ISPs to encrypt it? If so, who's going to hold the keys. (See Antonelli et al. for a paper on how to do this kind of encryption).

It would be nice to have some more details about what the feds are really going to insist on. So far, I've just seen this kind of vague summary.