The Washington Post posted this story a few days ago regarding the FTC’s Do Not Call web site. The most amusing part of the article references a comment I made in a previous post about the lack of security in the process, as anyone could conceivably register or unregister a phone number, even if it wasn’t theirs.

The article contains the following quote:

After looking over the registration site online, Aswath Rao thought its verification and unregistration processes could pose problems. "It looks like one can verify the status of the registration of any telephone number," the Holmdel, N.J., resident wrote. "Worse, any telephone number can be maliciously unregistered."David Torok, the Federal Trade Commission's director of the Do Not Call Registry, says Rao is right, but he doesn't anticipate a big problem.

Now, this seems to be the silliest thing I’ve ever heard of. A limit on the number of times one can use an e-mail address? What happens when I legitimately use my e-mail address too many times? Who corrects that? Even funnier is the fact that Torok seems to not be aware how spammers use millions of e-mail addresses to avoid spam filters. Does he not believe that anyone can do exactly the same thing and create dozens of e-mail addresses on the fly?

It was suggested to me that an amusing experiment would be to unregister a particular exchange to prove the point. That’s a mere 10000 phone numbers and it would be almost trivial to do in Perl. The web site uses a simple URL scheme to post the phone numbers that you want on or off the list. In sendmail, it’s easy to redirect the email from a single domain (“@yourdomain.com”) to a single e-mail address, so generating 10000 e-mail addresses would be no problem. You’d get 10000 e-mails in, each with a URL to validate — easy to collect and process using a trivial piece of POP3 client software. The messages are in text, so processing the message would be similarly easy.

The fact is that this “feel good” service isn’t really going to be that useful. Hackers outside the country will be hired to destroy this service considering how easy it is. Since they will be off-shore, prosecuting them will be difficult at best. The FTC feels so good about this service that they are going to try to set up the same thing with spam. Again, more silliness — spam is even easier to take outside the US. Just think — these are your tax dollars at work.

The FTC’s Do Not Call list has to be one of the silliest exercises that I’ve seen in a long time. This feel good service allows you to register all of your phone numbers (both landlines and cell phones) that you want removed from the telemarketing call lists. I registered the five phone numbers that I possess and walked away with several observations.

First, there’s no security on the process. Anyone can conceivably register a phone number on the list, whether it’s yours or not. You are asked for an e-mail address for confirmation, but there’s no correlation between e-mail addresses and phone numbers anywhere. Where’s the harm here, you ask? After all, we’re talking about the most evil of problems — telemarketing. Well, it turns out that anyone can just unregister a phone number also. It’s trivial to obtain an anonymous e-mail address through Yahoo or HotMail. If I want you back on my list, I’ll just unregister you and then call you. There’s no protection. It would be trivial to write a program that registered every phone number and equally trivial to unregister them.

Second, this list of exclusions is equally silly. The following companies are exempt from the program —

• long-distance phone companies 
• airlines
• banks and credit unions; and
• the business of insurance, to the extent that it is regulated by state law.

Frankly I get more calls from long distance companies and banks offering credit cards than I do from anyone else. I feel bad for the local carpet cleaner who calls once a year because that’s who’s going to have to check the list, not the big banks who call incessently.

I think there’ll be a small, offshore company with a couple of hackers that undoes all of this for the banks. They can afford it and it’d be hard to beat until the phone companies themselves actually get involved in the verification process. Of course, they won’t because they are exempt and this is a huge source of revenue for them.

Honestly, if you want to beat the telemarketers you really have two options — telezapping and call intercepting. I used a telezapper for about two years and it significantly cut down the number of telemarketing calls I got. I still had to answer the phone, but most of the time the caller had already disconnected. I just recently got call intercept, which was offered through my Verizon service. That turned out to be a great option — no one gets through without a valid caller id. If you don’t have a valid caller ID, you need to announce yourself, which the telemarketers don’t do. Even if they do, you have the option of pressing a button telling them not to call again. This works.

At a dinner function last night, the discussion of what happens with Sun and BEA came up. Sun is clearly the odd man out in the operating system war between Microsoft and Linux. BEA seems to also be in trouble given the fact that IBM’s WebSphere and Microsoft’s .NET are now poised to battle it out for web application services. So what happens with these two major players?

Here’s my prediction, posted here and dated for a future “I told you so”. IBM and Sun would be a natural fit as Sun begins to figure out what to do with Linux. Sun has developed some terrific hardware and has excellent operating system development capability. This fits naturally with IBM, who is putting Linux on every CPU they can find. IBM’s AIX business has to be trash right now given the SCO lawsuit. IBM’s hardware platforms don’t get the acclaim that Sun’s do. Thus my prediction of a merger between the two. WebSphere and Linux on Sparc could be hot for all parties involved. The hangups? First, Scott McNealy — he has to want to do this. Second, IBM’s anti-trust restrictions — there may be some holdovers from yesteryear that could cause this to be a problem.

What about BEA? I think they need to merge into HP just as soon as HP finishes digesting Compaq. HP acquired Bluestone to be their application server platform but frankly there’s no cache there. With the continued excellent hardware development at HP, more Linux systems on Itanium, they need platform software to really compete and provide an alternative with Microsoft and IBM. BEA should do that for them. For me this is similar to the Sun/Netscape merger years ago — Sun had hardware and needed software to complete the picture — Netscape had software and needed steady market channels. I think BEA could do the same thing for HP.

Remember, if either of these things happen, you heard it here first.