Vista Retraction

I previously wrote that I was looking forward to Vista.  I was.  But, now I’m not.  XP is good enough and Vista is terrible.  Its slow, bloated, won’t let you play music and doesn’t offer one iota of interesting new functionality.  It’s like having Microsoft Bob and Clippy and a bunch of security holes

Now, to all you Microsofties out there that read this blog, I hear that when you give an honest Vista review like this one, Microsoft sends bloggers like me a new laptop to evaluate Vista and help us better understand the true value of Vista.   I could be swayed.  But for now, unless Microsoft can help me understand again why I might someday want to install that hopeless piece of garbage, I have to retract my previous “looking forward” statements, and I no longer recommend Vista to my vast subscribership.

Update 01/03/07: Since I’ve had a few comments on this, it’s clear my sarcasm is undetected.  This post is a joke.  I just want Microsoft to send me my free reviewer’s laptop, and then I’ll sing and dance for Vista.  Until then, no recommendation for Vista!!

Vista DRM Controversy

The top 10 results on Google News search for “Vista DRM” today reference this ridiculous Peter Gutmann article.  This is a bunch of Microsoft bashing.  I’m actually surprised at how many so-called news sources are quoting this article without thinking.

Gutmann uses some cool sound-bites, though, like:

 “The Vista Content Protection specification could very well constitute the longest suicide note in history”

and

“This seems a bit like breaking the legs of Olympic athletes and then rating them based on how fast they can hobble on crutches.”

Yeah right.

Do you really think Apple is going to skip DRM, be legally prohibited from displaying HD content, and force their users to use Windows?  Ha!  Don’t blame Microsoft for this one, guys.  It’s the movie and music industry.  And it’s their content and their choice for how to protect it.  If you want, you can cast your vote by not buying the content.  Vista is just another viewing medium – like your TV, CD player, DVR, etc.

Marc Cuban Can’t Let It Go

I’ve been a fan of the Blog Maverick for some time.  But…

I don’t understand why he can’t stop ripping on YouTube.  He’s been wrong about 50 times, and yet he keeps going on and on and on.  With no evidence yet surfacing that he was right, he’s now just on a quest to insult and belittle the whole thing.  In the end, he’s going to be at least partially right – the User-Created Video market is just too immature to not have upheavals which will at least partly corroborate his claims.  Move on to another topic – you’re a smart guy – but you were wrong on this one.  For some reason, I think you are just waiting for some downturn to say “I told you so”.  We all know there will be a downturn.  So don’t take credit for the obvious!

Protecting Your Privacy: Don’t Go To College

Last month I received a letter from UCLA telling me that they had leaked my personal information to a hacker.  I never went to UCLA.  I applied to school there 17 years ago (and was accepted, of course!).  Since I declined their offer to study, I guess they finally got their revenge by giving my information to a hacker nearly two decades later.

I don’t know which is worse, UCLA’s negligent information retention policies, or realizing that its been 17 years since I applied to go to school.

Web Boom 2.0 – The Bubbgle

Don Dodge writes about why this bubble will be less severe than the last bubble.  I found it an interesting read.  It certainly is true that a lot of this bubble is via private institutions and acquisitions.

There is another interesting follow on from Alfred Thompson, lamenting how it’s the employees that get their lives really hurt by way of layoffs when the bubbgle bursts.

I agree with Alfred about who gets hurt.  But I don’t feel very bad for folks that get laid off.  All of us as employees have a responsibility to choose our employers well.  If we fail to do that, we might get burned.  Choose wisely.  Many of us in Silicon Valley have been chasing startups for a long time.  When we choose to work for small companies, there is risk.  We know that.  While it can be devastating to get laid off, all of us need to assess whether we can take the risk before we accept a job. 

For me, personally, I landed at Critical Path by way of acquisition in 2000, and at the time it seemed like a pretty good deal.  9 months later (just after I left), it turned out that Dave Thatcher and Tim Ganley were crooks, and the whole company collapsed.  Was it my fault that the executives lied to investors, employees, family, and friends?  No.  But was it my fault for having invested heavily into a risky company? Absolutely.

So, when the bubbgle bursts, all the folks (including me) that are working for Web 2.0 companies may have a rough time.  For some, it will work out just fine.  For others, it will work out very badly.  That’s Risk.  As Warren Buffett says, “Risk comes from not knowing what you are doing.”  I don’t feel sorry for people that don’t know what they are doing.  Bubbgle or not.

Allchin disputes Vista Security Claims

This week Jim Allchin wrote on the Vista Blog a rebuttal to claims that some of the most recent Windows attacks will also be security holes in Vista. 

First off, for the record, I am a fan of Vista for security reasons – it makes it far more difficult for viruses to compromise the system.  It’s definitely a step forward.

However, I am a bit surprised by Jim’s reluctance to admit that Vista is vulnerable to security holes just like XP.  Sooner or later, Vista is going to be hit by a nasty virus or worm, despite the best that Jim’s team has been able to do so far.   He should not be ashamed of this, it is going to happen, and Vista SP1 will fix a whole series of problems. 

The one question I wanted to know which I haven’t seen answered yet, is if you take this same set of 10 attacks, how many will compromise a fully-patched XP system?  I think the answer is zero?  If so, it isn’t clear that this study proves any strength (or weakness) in Vista yet.

Should Have Software

I posted last week the list of software I installed in wave 1.  Here is the software I have had to install since then.  I guess these are the “should have software” :-)
 

  1. Axialis Icon Workshop
  2. Foxit
  3. Google Earth – I really only downloaded this because I wanted to see Santa.
  4. Google Desktop – I downloaded this because there was a new version out.  The UI is incredibly improved over the last version.  No need to wait for Vista’s sidebar – Google’s Desktop gives you the sidebar running on Windows XP.   To be fair, though, I haven’t been a big fan of either the Microsoft or Google offering.  This version is much better, but unless you’ve got dual monitors like me, I suspect you won’t want to give up the precious screen real estate.  To see the coolest feature ever, though, be sure to install and hit ctrl-ctrl (control key twice).  Fantastic!
  5. Cygwin
  6. Yahoo Toolbar – I really have no idea how this got on my system.  Those Yahoo folk are tricky!

Time to Replace SMTP – Part 2

In my last article, we talked about spam as the problem which SMTP can never solve.  So what is the solution? 

First, let’s be clear on the goals:

  1. Reliable transport of email
  2. Efficient transport of email
  3. No spam
  4. Ability to send a message just by knowing a user’s address, nothing more.  If we make it more complicated, users will not switch.

Sender Challenge

My first choice for reducing spam is to use a CAPCHA or another challenge-response system the first time a sender sends email to a particular recipient.  This would mean that the first time you tried to send email to a Joe, you would be challenged with a CAPCHA-like system to verify that you are indeed human.  You don’t need to know anything about the Joe other than his email address, but you do need to be able to decipher this code.  This simple challenge would kill most all spam, as spammers would no longer be able to send millions of emails per day.  Once you’ve sent email to a recipient and passed the challenge, that recipient could add you to the list of “no challenge required”.  Communicating further with that user would not require additional challenges.  There is a drawback to this, however, which is that spammers will start trying to figure out who is on your whitelist, and forging emails from your approved contacts.  Still, this will be much more difficult than the current system where spammers can simply flood the net.

There are some of downsides to using a Sender Challenge.  But I think these are surmountable.  First, mail would need to be able to lookup challenges in real time, rather than the current store-and-forward technology which is used today.  With SMTP, “email relaying” is a core concept for delivery of mail.  After all, it was designed in the 70’s/80’s when the Internet was an interconnect of many different networks, many of which were disconnected for most of the day.  Most mail servers today intentionally disable mail relaying, because it is a spammer’s dream.  Relaying could still exist, but only if the challenge could still be done in real time.  Switching to a real-time protocol seems pretty practical at this point.

Another problem is how to receive automated email from legitimate sources.  For example, you really do want Amazon to send you an email when your purchase has shipped.  But Amazon’s computer won’t be able to pass your email-client’s challenge.  To overcome this, I think you’d need to specifically give Amazon a pre-approved token for sending email.  Your mail server could be configured to determine the lifetime of that token.  You could either allow Amazon to send you email via that token forever, or for a short period of time, or for just 3 emails.  The receiver would be in control. 

 

DiffMail – A Pull-based email approach

In researching new SMTP mechanisms, I came across DiffMail.  DiffMail is also a proposal for altering SMTP to make it better able to deal with spam.  It does have one fantastic recommendation – pull based email.

Today, SMTP pushes email from the sender to the recipient.  That is, when the sender sends email, the recipient’s server is required to accept it.  DiffMail proposes that we switch it around.  Sending an email would merely send an informational notice to the receiver saying “I have mail for you on my server if you want it.”  The sender would be required to keep the email on his server until the recipient picks it up.  (Keep in mind the user would never see this – this is just what the protocol is doing on behalf of the user) 

When SMTP was designed, a pull-based approach was not feasible – you couldn’t guarantee the sender’s server would be up when the receiver wanted to read mail.  Today, however, this is not an obstacle.  This model again clips the wings of the spammer, because it requires the spammer to remain online in order to deliver the message.  And of course, if the spammer’s content is online, it is much easier to pinpoint the spammer and stop him altogether.  Further, if we add a little cryptography to the format of email, we can force the spammer to either have a sophisticated spam server application or keep a lot of email stored on his own disk.  Both of which help reduce his ability to send spam at large scale.   The end user, of course, would never see any of this “push” or “pull” of email.  It would all happen under the covers of the email client.

An interesting feature emerges from switching to the pull model.  Have you ever wished to “retract” an email after you sent it but before it was read?  This model would allow you to edit the email as many times as you wish before the receiver downloads it.  Of course, if the receiver pulls it right away, you may not be able to retract. 

DiffMail proposes the pull-based email with the Sender Challenge as an optional component.  But I don’t think pull-based email is enough.  Imagine arriving at your machine and having to sort through 200 potential “new contact requests” to find the one person that is legitimate?  It is really the same problem as manually filtering out spam email, except that you would only have the sender’s email address to use for determining whether you would open the message.

There is a big risk with DiffMail, however.  With SMTP, the sender delivers the email content to the recipient immediately (disregard mail queues or relays for the moment).  In the new model, the sender most host a copy of that email on his server, waiting for the intended recipient to come back and fetch it.  How will it know if a bad guy isn’t trying to steal the email by pretending to be the real recipient?  DiffMail proposes to solve this by basically making the email contain a really big random number to hide the content.  But it isn’t a very safe solution.  I do believe the security issues can be overcome, but they are definitely not trivial.

 

Sender Challenge or Pull-based Email or Both?

The Sender Challenge system seems pretty straightforward to me to implement.  It fits within the email model that we have today, but introduces an optional challenge which the sender must be able to respond to.  Receivers of email need to be able to identify which people sending email to them need to be challenged and which do not.   That is a slightly tricky concept, but manageable.  The drawback to only using a Sender Challenge is that spammers could continue to exist.  Their new job would be to find ways to beat the challenge- either by random guessing or more sophisticated techniques.  If they can figure out ways to do this, we’ll have spam again.

The pull-based email system makes it costlier for the spammer to send mail at scale.  It also is a somewhat more logical way to communicate given universal access to the network.  However, it does represent a major architectural shift, and it will be a challenge for ISPs to deploy.

For the best spam protection, the combination of the two may be the best bet, but will obviously force a lot of changes to our existing systems.

 

Compatibility with Existing SMTP

It does seem attractive to make this system compatible with SMTP.  DiffMail attempts to this by proposing some modest additions to the SMTP protocol.  However, I think this is not the right approach for a couple of reasons. 

First off, even if we only change the protocol slightly, the mail servers all need to change radically.  With SMTP, we all deal with our outbound mail servers (SMTP) and our inbound mail storage (POP/IMAP/WebMail).  These are distinct servers.  Using any pull-based email mechanism will require the sender’s outbound mail server to now store data.  Further, routers and firewalls will need to be reconfigured.  Everything in the system is different from a deployment perspective, so why pretend it is the same via the protocol?   It does allow a recipient to receive both types of mail via a single server, which is helpful if your correspondents aren’t willing to move from SMTP.  But, in that model, you have no benefit over existing SMTP, as the spammers can still get to you.

Another problem with maintaining SMTP compatibility is that the protocol is not very efficient.   Sending each email via SMTP is at least 4 round trips to the server.  Using a model of sending all headers in one half trip and receiving the responses in the second half trip would allow for much lower cost server deployments.  If we’re breaking the world, we may as well do it right.

 

Comments? 

Time to Replace SMTP

It seems to me that SMTP is showing enough strains with spam that it is time to invest in a new protocol.  If you don’t know what SMTP is, well, you probably aren’t interested in this article.  But maybe RFC 2821 can help.

I don’t take this proposal lightheartedly.  Replacing a protocol is extremely hard and expensive to do.  It’s as crazy as a plan to change all cars on the road to use a new style of brake lights.  With the billions of deployed mail clients and millions of deployed mail servers that are all working, it is virtually impossible to replace them all – unless there is a really compelling reason to do so.  Perhaps there is.

The problem with SMTP is spam, of course.  SMTP simply does not provide protection from spam.  It is so bad that today most users receive far more spam than legitimate email.  This has been a nuisance to end users, but is also a very costly problem for mail administrators and even for internet bandwidth as a whole.  Mail administrators today spend a significant amount of time and energy managing whitelists and blacklists for who can or cannot send email.  This is a manual process.  The spammers keep changing their addresses, and the cycle goes on.  So far, the spammers are winning, and there is currently no plan to change it.

I think we need to change it now.  SMTP was great for getting email started.  But it doesn’t work anymore, as defined by RFC 2821 itself:

“The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently”

There is no doubt that today SMTP meets neither of these objectives. 

First, due to spam filters, email is no longer reliable.  Every email user has lost messages due to errant spam filters.  We don’t know how much we miss, but it is significant. And a mail transport is either reliable 100% of the time, or it is not reliable.  SMTP is not reliable.

Second, again due to spam, email is not efficient.  When a user must filter out 100 junk messages in order to find one real message, that is inefficient.  And most experts agree, this trend is getting worse, not better.

Our current path of improving spam filters ad-nauseam will never make SMTP able to accomplish it’s primary objective.  We need something better.  And while we’re at it, maybe we can finally add some interesting new mail features too.

More thoughts coming in my next article.

Alternative PDF Viewer

I’ve been a big fan of Foxit’s PDF reader for a while.  It is a 1.5MB download, and it is blazingly fast to display PDF documents.  I must admit, with version 1.3, I did notice some PDF documents (maybe 5%?) were unreadable for various reasons by Foxit.  This was frustrating, because I really didn’t want to download Adobe’s 60-ton Acrobat.

Good news – Foxit has a new version 2.0 available for download, and it seems to be solid.  I not a good enough PDF tester to know how good it is, but it is the only PDF viewer I have installed, and I haven’t seen any errors yet.  If you haven’t tried it, you should, it will change the way you feel about PDF!