August 29, 2016

Archives for July 2004


Apple Threatens Real

Pay attention now, ’cause this story gets kinda complicated.

See, Apple had this product called iPod that lets you listen to music. That sounds like a good idea. But Apple thought it would be better if the iPod could do less. So their engineers pulled a bunch of all-nighters to make sure that the iPod couldn’t play just any music a customer might have laying around. They called this DRM. I think that stands for Don’t Replay Music.

Now Apple had a competitor called Real. And Real was unhappy that Apple had made its product less useful. So Real’s engineers pulled a bunch of all-nighters, so that they could make Apple’s product better. They could’ve spent that time making their own product better, but that would have been a waste after all of the time they had already spent making their own product worse by making it do DRM too.

You still with me? Good.

Okay, so Apple was mighty ticked off that Real had made Apple’s product better, without even getting permission or anything. So Apple cried foul. Apple was shocked ‘n’ saddened that Real was trying to improve Apple’s product, like those hacker guys are always doing. So Apple drew a line in the sand, and swore to make its own product worse again.

I don’t know about you, but I find this all very confusing. I guess I just don’t have a head for business.



Monday was the second anniversary of Freedom to Tinker. Two years seems like a long time, but I still enjoy doing this. Thanks to all of you for your attention, and for keeping me alert and honest with your comments and feedback.

Here are the obligatory statistics about the site: 604 posts; 1409 comments; 3.2 million visits; 5.2 million page views; 90 gigabytes of data transferred.


Wiretapping the Net

Another interesting day at the Meltdown conference. John Morris of CDT gave an eye-opening talk about online wiretapping and the policy debate over how to apply CALEA to VoIP services.

Let me explain the jargon. CALEA is the Communications Assistance to Law Enforcement Act of 1994, which says that telecommunications providers must design their networks so as to allow (properly authorized) government wiretapping. CALEA applies to “telecommunications” but not to “information services,” so Internet software has thus far been exempt. However, the FCC, which regulates telecom, has some power to expand the application of CALEA.

VoIP is Voice over IP, a term referring to services that transmit voice over the Internet. Some VoIP services can substitute for traditional phone service; others provide similar functions in different form, such as voice-enabled instant messaging; and some provide entirely new functions.

In March, law enforcement agencies asked the FCC, which regulates telecom, to apply CALEA to “IP-enabled services” such as VoIP. Conventional wisdom says that the FCC will issue some kind of regulation in this area. But what exactly?

It seems likely that the FCC will require VoIP providers to be ready to provide information to law enforcement. The key question is whether providers will only have to provide the information that they already gather or whether providers will be required to (re-)design their technology so that it can gather the information that law enforcement wants.

A “design for wiretapping” requirement would seem to rule out certain designs, particularly those that rely on open protocols and the end-to-end principle. Such designs leave too much control in the hands of end users, so that no vendor can be assured of having access to the information that they would be required to gather. On the other side, law enforcement will argue that CALEA is toothless without design requirements, and existing telecom providers would be happy to see open, end-to-end architectures outlawed.

Coincidentally, as I was writing the previous paragraph, sitting in my hotel room with the television on in the background, a commercial came on CNN, urging viewers to ask their legislators to “update our telecom laws.” Then I ran across today’s New York Times article on the telecom regulation battles.

This is definitely an issue to watch.


Too Much Spam, Not Enough Identification

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.]


PFIR "Internet Meltdown" Conference

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


Induce Act Hearing Video

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.


Induce Act Hearing Webcast, Live Discussion

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.


Vadasz Attacks INDUCE Act

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?


MS to Sue Linux over Patents?

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.


Software That Lasts 200 Years

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.