Lots of good stuff yesterday at the Meltdown conference. Rather than summarize it all, let me give you two random observations about the discussion.

The security session descended into a series of rants about the evil of spam. Lately this seems to happen often in conference panels about security. This strikes me as odd, since spam is far from the worst security problem we face online. Don’t get me wrong; spam annoys me, just like everybody else. But I don’t think we’ll make much progress on the spam problem until we get a handle on more fundamental problems, such as how to protect ordinary machines from hijacking, and how to produce higher-quality commercial software.

Another interesting feature, noted by Michael Froomkin, was the central role of identification technologies in the day’s discussions, both in diagnoses of Internet policy problems, and in proposed solutions. When the topic was spam, people liked technologies that identify message senders; but on other topics, identification was considered harmful. I hope to see more discussion about identification at the conference. (I’ll have another posting on online identification later this week.)

[Susan Crawford has an interesting summary of yesterday's discussion. She says I was "wise in the hallways", whatever that means.]

From today through Wednesday, I’ll be at the PFIR Internet Meltdown conference. I’ll post reports on the conference here.

If you missed yesterday's Senate hearing on the proposed Induce Act, you can check out the video, thanks to Thomas Barger. (As a bonus, he also offers a video of the May 12 hearings on Rep. Boucher's DMCRA.)

The written testimony of all witnesses, and the statements of Sens. Hatch and Leahy, are available too.

Today's Senate hearing on the Induce Act will be webcast (link) at 2:00 PM Eastern time.

Anybody who is listening to the webcast is invited to discuss the hearing while it happens, in the comments section of this post. I'll be listening, and watching the comments.

An op-ed in today's Wall Street Journal, by recently retired Intel VP Les Vadasz, urges the Senate to reject the INDUCE Act. News junkies may remember Vadasz's testimony against the now-infamous Hollings CBDTPA at a Senate hearing, during which Vadasz was treated quite harshly. They may also remember that Vadasz's view ultimately prevailed, because it was right.

Vadasz paints the INDUCE Act as the second coming of CBDTPA:

Two years ago, I had the "pleasure" of testifying before the Senate Commerce Committee on the so-called Hollings bill, which aimed to protect entertainment content against piracy by getting the government involved in the design of the innards of personal computers. Far from protecting against piracy, the bill would have suffocated innovation in the high-tech industry. Rationality prevailed, and the bill never moved forward.

Yet last month, a bill with similar goals was introduced by Orrin Hatch. The Inducing Infringement of Copyrights Act of 2004 -- the "Induce bill" for short -- would make liable anyone who "intentionally aids, abets, induces or procures" a copyright violation. As President Reagan once remarked, "Here we go again." Sen. Hatch and others argue that the bill will protect kids from porn and punish those who "intentionally induce" piracy. In reality it will do neither. But it will do serious harm to innovation.

There's a hearing on the INDUCE Act tomorrow. Who will play the Vadasz role this time?

A two-year-old internal memo from Hewlett-Packard predicted that Microsoft would soon launch patent-infringement suits against companies that distribute open-source products such as Linux and Apache, according to a Joe Barr story at NewsForge. (The article reprints the memo in full.) The memo is clearly based on statements made by Microsoft negotiators during a patent licensing negotiation with HP.

My first reaction to the story was that this was just a negotiating ploy by Microsoft, to scare HP into granting better patent licensing terms -- an implicit threat to sue HP if you they rejected an offered deal. But after reading the whole memo, that seems unlikely. Apparently the eventual agreement did not protect HP against the threatened suits; so raising a false alarm about such suits would have made the negotiation harder for Microsoft, not easier.

Another possibility is that Microsoft really did intend at the time to file suits. If so, the question is why, two years later, no suits have been filed. Slashdot posters suggested that the SCO-IBM suit is providing the FUD (fear, uncertainty, and doubt) about open-source that Microsoft was hoping to create with its suits, rendering a Microsoft suit unnecessary. But if some FUD is good for Microsoft, why isn't more better?

Perhaps Microsoft changed its mind, because it couldn't find a strong enough patent to assert, or because it feared patent-infringement countersuits from the intended targets of its litigation. This one also seems unlikely. If Microsoft's goal was to create FUD and run up a defendant's litigation expenses, then even an iffy patent would suffice, and Microsoft would have no trouble at all finding a patent to use. And if the goal of a suit was just to create FUD, then it wouldn't much matter who they sued, so they would certainly be able to find somebody without a big patent portfolio to go after.

Most likely, the lawsuit threat was a ploy, designed to create FUD at HP about its use of open-source products. And the HP memo is evidence that it was working; the author clearly wanted to reduce HP's "exposure" from its use of open-source.

Dan Bricklin has a provocative new essay arguing that at least some software should be built to last for a long time, perhaps as long as 200 years.

We need to start thinking about software in a way more like how we think about building bridges, dams, and sewers. What we build must last for generations without total rebuilding. This requires new thinking and new ways of organizing development. This is especially important for governments of all sizes as well as for established, ongoing businesses and institutions.

It's definitely worth thinking about how to do this, but after some thought I am skeptical that this kind of long-term investment really makes sense given the present rate of improvement in software.

Whenever we trade off present spending against future spending, we have to be careful that costs in the future are properly discounted, to account for the time value of money and for the greater efficiency of future engineers. What should the discount rate be for software investments? That's arguable, but the correct rate is reasonably large.

Some costs deflate according to Moore's Law, or about 60% per year (compounded). Others deflate according to the rate of improvement in programmer productivity, which I will estimate (via an utterly unsupported wild guess) as 10% annually. Some deflate as standard business expenses would; I'll estimate that rate at 5% annually. According to those rates, over a 200 year period, Moore's Law expenses will deflate, astronomically, by a factor of about 10 to the 40th power; programming time will deflate by a factor of about 200,000,000; and ordinary expenses will deflate by a factor of about 17,000. So an investment of $1 now is only worthwhile if it saves year-2204 expenses of $17,000 (for ordinary expenses), $200 million (of programming expenses), or a bazillion dollars of Moore's-Law-sensitive expenses.

Given those numbers, how much should we be willing to invest now, to provide benefits to our 200-years-from-now descendants? Present investment is only worthwhile if it creates enormous savings in that distant future -- and it's hard to believe that we know much of anything about what will be wanted, technologically, that far in the future. Remember, it was only sixty years ago that Thomas Watson of IBM famously estimated that the total world market would demand only five computers.

There is one area where it certainly makes sense to invest now to provide future benefits, and that is in ensuring that records of major events (birth and death records, and similar social archives) are recoverable in the future. The easy part of doing this is ensuring that the data are archived in an easily decoded format, so that it can be reconstructed later, if necessary. (Remember, programmer effort in the far future is cheap.)

The hard part of preserving these records is in making sure that the data is stored on a medium that is still readable (and hasn't been misplaced) two hundred years from now. Many of today's storage media have a life much shorter than that. I understand that there is a method involving patterns of pigment on thin cellulose-based sheets that is quite promising for this purpose.

In mid-August I'm going to a small technical workshop that has a "cool stuff" session, where everybody is invited to demonstrate or explain to the group something cool. It doesn't have to be useful or technological; the only requirement is that a group of uber-geeks will think it is cool.

Perhaps you can help me out with suggestions....

Ernest Miller is on a roll lately, especially on the topic of the INCUDE/IICA Act. I would be saying more about this dangerous bill, but Ernie is saying most of what needs to be said. James Grimmelmann at LawMeme made a nice index of Ernie's INDUCE/IICA writings.

Ernie has instituted Hatch's Hit List, a list of technologies that would appear to be banned by the IICA, as inducers of copyright infringement. (This is modeled on Fritz's Hit List, a feature I introduced here in response to an earlier overreaching technology-regulation bill.)

Chris Palmer at the EFF published a piece this week debunking the Audible Magic technology. He focuses on the CopySense technology.

Audible Magic's CopySense™, a network appliance product, examines network traffic at the content layer -— that is, it analyzes the actual file transferred in an application-layer transaction. In order to determine whether the content is a copyrighted song, CopySense treats the content as audio and analyzes its acoustic properties. It examines only a small portion of the content, extracting an "acoustic fingerprint." This fingerprint is then matched against the fingerprints of copyrighted musical works in a pre-compiled database. Audible Magic boasts a database of more than 3.7 million fingerprints, growing continually.

He points out that the product's scanning can easily be defeated by encrypting content, for example by using a popular session encryption protocol such as SSL/TLS. Blocking such a protocol entirely would be unacceptable, since it is used for secure web accesses. In fact, any lightweight encryption method, even a fairly insecure one, would be enough to defeat CopySense in practice. This is a very powerful argument against systems like CopySense.

He also argues that the method CopySense uses to terminate (suspected) infringing transfers is also used in various network attacks, so endpoint machines will, over time, adopt defenses against it, making it harder for CopySense to block connections it doesn't like.

Interestingly, Chris Palmer is able to describe how CopySense would be defeated in practice, without even reaching the question of whether Audible Magic's underlying audio-scanning technology is sound. His encryption argument applies to any system that claims to detect infringing music transfers by listening to network traffic.

It may turn out -- and I suspect it would, if independent experts were able to study Audible Magic's technology -- that copyrighted music files could be tweaked in a way that made them undetectable to Audible Magic's algorithms, while still sounding fine to typical human listeners.

Ernest Miller makes one more interesting point with respect to Audible Magic, arguing that CopySense may violate wiretap laws. Audible Magic says that CopySense "listens to all traffic on the network". Ernie argues that unless that listening meets one of the narrow exceptions in wiretap laws -- and he thinks it probably won't -- then it's illegal.

A group of large movie and technology companies is about to form yet another consortium to solve the digital copyright problem, according to a John Borland story at news.com. This looks like one more entry in the alphabet soup (SDMI, CPTWG, ARDG) of fruitless efforts to standardize on an effective anti-copying technology.

The new entity will fail just as badly as the old ones, and for the same reason: there is no effective anti-copying technology on which to standardize. You can get together as many company representatives as you like, and you can issue as many joint reports and declarations as you like, but you cannot change the fact that the group's goal is infeasible. This just isn't the sort of problem that can be solved by negotiation.

But perhaps the group's real goal is to limit the use of digital media technology by law-abiding consumers. That's certainly achievable. And, as Ernest Miller notes, they may also be able to erect barriers to entry in technology markets, by creating "security" requirements that lock out smaller companies.

In the end, my prediction is that the new group will fail to reach any meaningful agreement. They'll hold some meetings and issue some vaguely optimistic press releases, but when it comes to the hard technical issues, they'll fail to reach a consensus.

Despite this, the group will provide its members with a certain piece of mind. It will help the movie companies sustain their fantasy of the infringement-free, pay-per-view future. And it will help the tech giants sustain the fantasy that they, rather than their customers, will decide the future of media technology.

I wrote recently about the Velvet Revolver album that is "protected" by SunnComm 's ineffectual CD anti-copying technology. The technology was doomed to fail -- and has in fact failed -- to keep the music off the popular P2P filesharing systems.

It turns out that things are even weirder than I had thought: the very same album was released in Japan without DRM (according to Alex Halderman, who has a copy of the Japanese release). So even if the DRM technology were perfect, the music still would have leaked, via Japanese buyers, onto the P2P darknet.

DRM costs the record company money to deploy, because the DRM technology must be licensed, and because of lost sales due to DRM-induced consumer inconvenience. So why in the world would a record company pay to DRM an album in some places and not in others?

One possible explanation is that the record company is not thinking clearly about the consequences of their DRM strategy. Based on the conversations I have had with record industry executives about their DRM strategy, this theory is quite plausible.

Another possibility is that they aren't actually trying to prevent P2P copying of this album, but are instead trying to create evidence that US consumers will accept DRMed products. As I wrote previously ("Lame Copy Protection Doesn't Depress CD Sales Much"), experience with the Velvet Revolver album seems to indicate that consumers see the DRM as a drawback, but many are buying it anyway because they think the music is good enough to outweigh the harmful DRM.

A third possibility is that they are worried about some other threat model, not involving P2P. Perhaps they think the DRM can prevent individual disc-to-disc copying. It's not clear how much the technology will really do to prevent such copying, or how many sales would be saved by preventing such copies. (My guess is that most people who make disc-to-disc copies would not have bought a second copy.)

My best guess is that this is just one of those odd behaviors ones sees in large organizations that are in denial about an important issue. Shipping DRMed discs in the US shows that deployment of CD DRM is proceeding on schedule, thus allowing some in the industry to maintain their self-delusion that the CD DRM strategy is viable.