there are a lot of ways to solve the spam problem that will work if "everybody does it my way." so far, nobody has figured out how to impose their will on the rest of the net.
-- Keith Moore, on the IETF mailing list
It's better to be passionate about what you do than just grind it out like a lawyer or something.
-- Scott McNealy in SFGate interview
Web designers can be divided into two groups. In one group are those who want precise layout, who use design tools such as Dreamweaver, and who could care less about using CSS for page layout. You can easily recognize the HTML that these designers produce, as it contains deeply nested <table> elements. In the other group are those who prefer a more fluid, flexible layout based on CSS. The goal of the designers in this group is to create layouts that use <table> elements only for tabular data, and never for layout. Their mantra is "separation of content and presentation."
(I suppose I fall more into the second group of designers, though I would never claim to have real talent in graphical design.)
Those who insist on CSS layout claim that good layout without tables is possible. That's true. But layout without tables is hard! One of the reasons it's hard, is because Internet Explorer does not support the features of CSS that would make it easier. However, even if IE did have near-perfect support for CSS Level 2, layout with style sheets would still be hard. Anyone who has programmed graphical user interfaces for desktop applications understands this. In GUI development, the layout is controlled by program code, often by a layout manager. One of the most capable layout managers available to Java programmers is the GridBagLayout. What's interesting, is that the GridBagLayout provides layout capabilities that are very similar the layout capabilities of HTML tables.
So, considering that a grid -- or shall we say it? a table! -- is a useful layout device in GUI programming, why isn't it a useful layout device in HTML layout? The answer, of course, is that a table is a useful device for HTML layout. I think there is a bit of history behind the situation that we should consider. Yes, back in the early days of HTML, tables were for presenting tabular data. But since there was no <grid> element for layout, designers started using the <table> element for layout.
I don't think it will ever happen, but why don't we add a <grid> element to HTML? Then, we could have a decent layout manager for HTML pages. Current HTML provides frames, which divide up the browser window into discrete areas. Couldn't future HTML provide a grid layout, with appropriate tags, that similarly divides the browser window? Constraints could be specified as attributes to the HTML elements. If implemented correctly, a grid layout would make it simple to create many of the most commonly used web page layouts, such as the popular three column layout with a header and a footer.
In the last few days I noticed that Comcast High-Speed Internet has dropped support for plus aliases. (A plus alias is an email alias that is formed using a plus sign. For example, joe+63noggin@example.net is an alias for joe@example.net.) This disturbs me. With plus aliases, an email user has an unlimited number of aliases, which he can use to dodge spammers. The concept is simple: if an email alias is compromised to spammers, one can create a new alias.
It may be true that plus aliases are not easy to use. But that's only because mail clients don't take advantage of them. And mail clients don't take advantage of them because the largest ISPs don't support them. And the largest ISPs don't support them because there is no consumer demand. And there is no consumer demand because most consumers don't know about them or understand them. And most consumers don't know about them or understand them because the mail clients don't handle them. In short, it's the classic chicken-and-egg problem.
And now Comcast has taken a step backwards. Could it be because of AT&T's patent?
The SoBig.F worm is sent as an executable file attachment in an email message. The worm does not spread unless the recipient runs the executable file. I assume Outlook and Outlook Express run the executable if the user opens the attachment. (I don't use either application, nor have I tested either.) That being the case, who is responsible for the worm spreading?
My first inclination is that Microsoft is responsible. An executable file should never be run if it is opened from an email client application. However, after further consideration, I don't think we can say that Microsoft is legally liable. The fact that Outlook Express will run an executable file if it is opened as an attachment is a feature. In my opinion, it's a horrible feature, but still a feature. The fact is, that Outlook Express behaves exactly as it was designed to behave. Users are not supposed to open attachments that contain executable files, unless they know who it is from and are expecting to receive it.
I suppose this is obvious. The point I want to make, is that SoBig.F is different from other worms in a significant way: in SoBig.F, the software is behaving exactly as it was designed to behave. In the case of MSBlaster, the worm exploits a bug in the software, so the software is not behaving as it was designed to behave.
And now a question of a more philosophical nature. The person who wrote SoBig.F is not abusing any software. He is just using a feature of the software (the email client), but he is not exploiting any flaw. Is that person liable? It's possible to answer "no," which means you take the position that the user that opened the attachment is liable.
In summary, there are three parties that we could consider liable. First, there is Microsoft, which made it too easy to run an executable file that was sent in an email attachment. Second, there is the author of the worm software, who wrote software that behaves in a way that the reasonable man would consider malicious. And third, there is the recipient, who caused the executable file to run.