Doug's Inner Net News

Content-Based Spam Filters

Andy Lester makes this request: Please stop working on content-based spam filtering.

There seems to be a certain school of anti-spam developers who believe that content-based filtering is the solution to the spam problem. (Example: the DSpam developers.) I keep hoping that these developers will one day see the light: that the goal is not to build better and better content-based filters -- that the goal is to stop spam. As Andy demonstrates, content-based filters alone just cannot solve the problem.

More on User Mode Linux

I knew about Linode.com, a company that offers Linux virtual servers. Other companies offer similar virtual servers. These virtual servers run on User Mode Linux. There is a list of such companies on Source Forge.

Standardizing NATs

For peer-to-peer application developers, Network Address Translators (NATs) are an obstacle. One of the biggest problems is that a developer cannot assume consistent behavior of all NAT implementations. There is now an effort underway to create a standard for consistent NAT behavior. The effort takes place within the IETF's BEHAVE working group.

In a recent Internet draft entitled Application Design Guidelines for Traversal of Network Address Translators, the authors talk about "BEHAVE-compliant NATs" and "BEHAVE-compliant applications." A BEHAVE-compliant NAT is one that behaves according to the emerging standard. A BEHAVE-compliant application is one that correctly operates when the participating peers are separated by BEHAVE-compliant NATs. There is no cooperation -- no protocol -- between a BEHAVE-compliant NAT and a BEHAVE-compliant application. It's just that the application makes certain assumptions about how the NAT operates.

Emacs, The Do Everything Editor

I use emacs every day. One of the things I especially like about emacs is that it provides me with maximal working space. In that regard, it's different from many other editors that waste vertical space with toolbars that are only occasionally needed.

There are many other reasons to like emacs. There are also many reasons to hate emacs. Peter M. Bagnall, at his usability web site named SurfaceEffect, discusses the good and bad of emacs. It seems that you can divide the population into those who love emacs, those who hate it, and those who don't know much at all about it.

Another thing I like about emacs is that there is always something new to learn to make me more productive. emacs.org has some useful tips.

Security usability

The IETF has a web form for subscribing to the IETF-Announce mailing list. The form has this admonition:

Do not use a valuable password as it will occasionally be emailed back to you in cleartext.

This admonition is a gentle reminder that not all passwords are equal.

But considered at a different level, it's a reminder that security is not easy for users. Just considering this one specific issue, we note that different passwords -- and different password strengths -- are required for different functions. A password that you use to update your mailing list subscription and a password that you use to update your bank account are vastly different in value. So, an interesting question might be: how many levels of passwords should I have? Just right at the start, I know I need at least two: one for mailing list subscriptions and one for bank accounts. How many more? Typical individuals don't want to think about these questions.

A related issue is the sharing of personal information. Whom should you give your cell phone number to? Whom should you give your instant messaging ID to? Whom should you give your email address to? Which email address? How many different email addresses or instant messaging IDs should you have?

A Spam Strategy

An article at Inifinite Ink has what I think is the best strategy yet for dealing with spam. The author calls the technique reverse spam filtering.

The idea basically is to filter non-spam rather than spam. That's why it's called reverse filtering. If you use this technique, most of your mail goes into a default folder, assuming that mail is mostly spam. The mail your reverse filter selects goes into your inbox. You may also review mail in the default folder, but the recommended way to do this is to sort the messages by their spam score. You view the messages starting with the lowest spam score and stop when you feel you've viewed enough.

The article mentions a few tricks that I was never aware of. For example, if you have your spam filter to put the spam score at the beginning of the subject line, then you can easily sort messages by their spam scores.

The Blame Game for IDN Vulnerability

Well, it looks like the blame game has started for the well-known vulnerability for Internationalize Domain Names (IDN), the standard that allows domain names -- hence, web URIs -- to contain Unicode characters.

The story is covered at news.com. See also IDN and Homographs Spoofing.

Who is to blame? There's a lot of blame to go around.

Start with IDN itself, which solves a problem that should have been solved through a different means. Web users around the world want easy to remember names for web sites. But instead of adding a layer above DNS, like Real Names, the IETF and ICANN gave in to the pressure to allow DNS to become overly complex and vulernable.

Then there are the registries, who, if you believe what some critics say, should never allow a domain name to be registered if it uses characters from more than one script. Is there any part of Unicode that specifies what script each character belongs to? Not that I know of. Maybe the Unicode Consortium is to blame.

And then there is blame for the Mozilla and Firefox teams, who should never have implemented IDN without first solving the security problem. One thing is certain: Microsoft did the right thing by not implementing IDN. It's only the fact that Firefox users tend to be a small and web-knowledgeable group that keeps this security flaw from being major headline news. If it were Microsoft, instead of the Mozilla/Firefox team, it's quite possible that some individuals would have had their bank acounts wiped out by now.

The IDN vulnerability is very serious. Any solution must take into consideration that most users cannot be expected to learn what to look for.

Update: Paul Hoffman defends IDN on CircleID. Read what Paul says, and keep in mind that part of his "solution" -- which he doesn't mention, but which I believe is so -- is to have all web users take an evening class so that they know how to browse the web safely.

Telephone numbers versus URIs

Chris Holland does a good job explaining why SIP URIs matter. I read his blog entry a few weeks back. Since that time, I have been thinking about URIs versus numbers in telephony, with regard to usability.

One problem with URIs is that they are hard to enter if you use a small keypad.

One advantage of URIs is that they can be easy to remember. But that may not always be the case. In a crowded namespace, one can not always choose an easy-to-remember URI. And there are those individuals who choose unusual aliases that have nothing to do with their names.

If you must leave someone a voice mail message with your phone "address," which would you rather say? A number or a URI? (I think the number is easier: "Please call me at 5-5-5 1-2-3-4." versus "Call me at doug sauder -- that's spelled S-A-U-D-(as in danny)-E-R -- at eye pee tell dot org." )

So, it seems that URIs may be easier to remember. But most of the other factors weigh toward numbers, strange as that may seem. For most people, numbers are the clear winner. Ordinary people understand them, and they just work.

If URIs are like email addresses, then we won't type them. Instead, we will choose them from an address book. No problem. But what if the phone you use is shared by many individuals? That means the address book won't be stored in the phone's memory. Could the address book be stored somewhere in the network, accessable from any future phone? That may be possible, but there are security risks.

If numbers remain far more usable than URIs, that presents a serious problem to the long-term future of alternative communications, which includes such services as Skype. And it's great for legacy phone services. At issue is control of the namespace. Anyone could set up a SIP server and dole out SIP URIs. It's much harder to get an allocation of PSTN numbers.

AT&T Not What It Was

In 1983, AT&T had 1,009,000 employees! That's over one million! On January 1, 1984, AT&T had 373,000 employees. Of course, that was the day the Modified Final Judgement took effect, which broke up AT&T. Today, AT&T has 61,600 employees, and falling.

You can read about AT&T's history on AT&T's web site

IPv6 4 U

xs26.net has free access to the IPv6 Internet. (xs26 is like "Access to six", that is IPv6.) The POPs are in Europe, so users in North America must connect across the Big Pond. I plan to check this out in more detail when I have some spare time.

Those of us who aspire to be full-fledged citizens of the Internet, with a global network address, will one day be using IPv6. And we won't need to get IPv6 access from our ISP. Instead, we will gain access to a provider like xs26.net via a tunnel across the IPv4 Internet. The best tunnel technology for most home users will be teredo, which is designed to work in the presence of NATs. But it may also be possible to gain access via a statically configured tunnel.

I wonder how long it will be before those who design peer-to-peer applications realize that rather than fighting NATs, they really should just use IPv6. Apparently, Microsoft gets it, as its peer-to-peer technology is built on IPv6.

Local telco monopoly power

Real competition actually works. Judge Greene divided Ma Bell geographically back in 1984, and competitive long-distance rates dropped 95% in 20 years. So why haven’t local rates?

That quote is from Andy Kessler in a recent WSJ article. It's a good read. If you think about it for awhile, it might even make you mad. How could it cost $0.04 per minute to call from the USA to Germany, while it costs $0.22 per minute to call many places in the same state. (Incidentally, I recently received a notice from Verizon that they were applying for an increase in the toll rate -- up to $0.30 per minute.) It doesn't take the knowledge of an industry insider to realize that something is seriously wrong with telecom policy.

The story is also covered at Techdirt.