You might remember that I ditched the Google Toolbar a couple of months ago. Steve Rubel is reporting on another good reason to do so: the newest version includes a feature called Autolink. Greg Linden explains it very simply: with this feature turned on, Google's modifying web page content to add its own links. For example, addresses are linked to Google Maps pages. Book ISBNs and package tracking numbers are linked too.

The folks at Google Blogoscoped toss this off with "talk about the Google OS taking over our lives", but you know what? Microsoft tried something similar with their IE support for smart tags. Smart tags are exceptionally useful in Office, because you can easily write your own smart tag code to recognize objects unique to your business (like chemical compound names for a pharmaceutical company). I wrote one that recognizes scripture verses (you know, like "John 3:16"). When MS proposed extending this feature to IE, the furor was incredible. Walt Mossberg, Dave Winer, Dan Gillmor, and a host of other influencers immediately started screaming that Microsoft was taking control over web content and generally acting like an 800-lb gorilla. The EFF even opined that the MS smart tag implementation might be illegal. In fact, here's what Chris Kaminski had to say:

Even if smart tags don’t violate copyright or deceptive trade laws, they still violate the integrity of the web. Part of the appeal of the web is that it allows anyone to publish anything, to take their thoughts, feelings and opinions and put them before the world with no censors or marketroids in the way. By adding smart tags to web pages, Microsoft is interposing itself between authors and their audience. Microsoft told Walter Mossberg “the feature will spare users from ‘under-linked’ sites.” Microsoft is in effect deciding how authors should write, and how developers should build, websites.

Worse, Microsoft’s decisions may be at odds with the intent of the site’s author or developer. If an Internet Explorer 6 user visits Travelocity and looks at a page with information on visiting Nice, France, the smart tag that aggravated Thurrott will link the word “Nice” to Microsoft’s Expedia site. With smart tags, Microsoft is able to insert their ads right into competitors’ sites.

Microsoft is crossing the Rubicon of journalistic and artistic integrity. Editors and authors no longer have final authority over what their sites say; Microsoft and its partners do. For a preview of what the web may look like for Internet Explorer 6 users who also have Office XP or Windows XP installed, take a look at InteractiveWeek’s Connie Guglielmo’s preview. With smart tags, Microsoft is effectively extending its role from being a supplier of tools people use to view content to being the executive editor and creative director of every site on the web.

So, check that out: Kaminski accuses Microsoft of "deciding how authors should write", "insert[ing] their ads right into competitors' sites", and becoming "the executive editor and creative director of every site on the web". He left out barratry and mopery and dopery in the spaceways, but that's still a pretty damning list.

Now Google's doing the same thing. Will we see the same reaction?

My guess is "no". Google's widely publicized mantra of "don't be evil" is increasingly often being used to excuse behavior for which Microsoft, Oracle, or IBM would be roundly condemned. This is just the latest such instance. Don't get me wrong: as a user, I think Autolink could potentially be a useful feature (but then I thought the same thing about smart tag support in IE). As a web content provider, I'm not comfortable with the idea that another entity (which may not have my best interests at heart) is modifying my content before someone else sees it. If Microsoft was wrong then, so Google is wrong now.

SearchEngineWatch says "the commercial possibilities are massive"-- I'd have to agree. My somewhat cynical guess, though, is that , and that raises the question of whether it's OK for Google to make money by modifying other people's web content. My guess would be "not so much"-- look back at the Kaminski quote and see the part about ad insertion again. On the other hand, I see that Dave Winer is labeling this as "a line they must not cross"-- an encouraging early sign.

Update: Adam Gaffin points to this article, pointing out that I have Google ads enabled. True. One prominent difference, of course, is that I get to choose whether ads appear on my page or not; I have some reasonable control over the ads' appearance, and I could filter out competitors if I wanted to. Autolink doesn't provide any of these features, except that it allows you to disable it. If I'm an Amazon affiliate, let's say, how do I stop Autolink from doing something nasty to Amazon links on my page? Sure, it might not do that now, but as any competitive strategist knows, you judge competitors by their capabilities, not by their intentions.

FedEx is up to no good. I got my corporate Amex bill and noticed that there were two shipments listed-- one for $25 and one for $55. I'd used FedEx to ship my SPOT watch (< 1lb) back for repair and to seen a book to a friend in Long Beach. Sure enough, the shipment dates and tracking numbers matched. When I called FedEx to ask them WTF, the explanation was simple:

FedEx: We've been encouraging our customers to use our shipping materials. When you ship a package with nonstandard packaging, we automatically dim weight it.

Me: What does that mean?

FedEx: We take the package dimensions and calculate a standardized weight, then bill you for that.

Me: (incoherent spluttering) Why didn't anyone tell me this?

FedEx: You should have noticed the change in your latest Service Guide.

Me:

(more spluttering) I didn't GET a service guide this year!

They were kind enough to remove the overcharge for those two packages, but there are two more enroute right now that'll have to be re-rated once I get the bill. In the meantime, FedEx's perverse website has decided that two addresses which look the same to humans aren't really the same, so it won't let me log in to order some more of the Holy FedEx Boxes that I have to use in order to not be grossly overcharged. Grrrrr.

Amazon released their 2004 list of the best computer books, and once again Secure Messaging with Microsoft Exchange Server 2003 wasn't on it. Dang! I was all set to be depressed, but then I saw this great post from fellow author Ed Bott, with whom I agree totally:

Nothing on Windows XP or Windows Server 2003. Nothing on Linux or Mac OS X or cascading style sheets or PHP or Adobe Photoshop or computer security or digital music or photography. You know, topics that lots of people might actually be interested in.
From all of us computer book authors, thanks for the support, Amazon. (Not.)

I've had a long series of email discussions with Troy Werelius, CEO of GOExchange's parent company. I'm now convinced that the sales rep didn't intend to be dishonest, but that he was trying to bolster his case that eseutil is complex (true), dangerous (true), and not for use by the unwary (true). He pointed out that it was unfair of me to criticize GOExchange as "little more than a scheduling engine that wraps around eseutil" without having used it. That's a fair criticism, although in my defense he has been reluctant to talk about what the product actually does do. To avoid confusion, I've removed my earlier post.

However, let me make something perfectly clear: I do not think that it is a good idea to run eseutil except in certain specific, well-defined circumstances. It is not a tool for routine or casual use. Reasons to use eseutil include fixing a damaged database or running an offline defrag, neither of which are routine maintenance operations. I think that's where the central point of disagreement between my viewpoint and Troy's lies.

Troy is working on arranging a technology demo for the Exchange MVPs that will help all of us understand better what the product actually does-- I'll post my impressions of its functionality after the demo.

Via my inbox, I found a very interesting blog post that outlines the timeline for fixing the recent shell: vulnerability in Mozilla. I tip my hat to the Mozilla team for their speedy response.. except that they forgot a couple of important things.

First of all, where was the testing? In the timeline, I don't see any mention of any kind of testing to see whether their fix had any impact on legitimate uses of shell:. That implies that either a) they didn't test it, b) they did test it but forgot to mention it in the timeline (unlikely, given how complete it is otherwise), or c) there aren't any legitimate usages of shell: (in which case one might wonder why they implemented it.)

Next, what about code review? I notice that there was a (wait for it) three minute review listed in the timeline. I guess for a trivial change this might suffice. Then again it might not. Many eyes might make all bugs shallow, but in this case only one set of eyes spent 180 seconds reviewing the fix before approving it.

Third, if you have a look at this bug, you'll notice in comment #11 that this was flagged as security critical in October 2002. However, it wasn't fixed until July 2004. Oops.

Fourth, the original bug was tagged as "won't fix". Why? The dev team thought it was a Windows-only problem. Maybe it was, but oddly IE didn't suffer from it-- that sure makes it seem more like a Mozilla bug to me.

Fifth, I would point out that just because the team released a patch quickly, there's no guarantee (heck, there's no data) on whether users actually got that patch or not. Complain all you want about IE, but at least Microsoft has a robust system for notifying people of updates and, optionally, pushing them to affected machines.

So, now it's getting personal. From Rob Novak via Ed Brill:

While standing there, I saw a title from Microsoft Press: "Secure Messaging for Exchange Server 2003".  OK, that sounds reasonable.  It belongs there. Then I realized something.  Why in the WORLD would you need a 506-page book to tell you how to do secure messaging???  You just have to Sign and Encrypt!  What is with these people?

Fair question, one deserving of a comprehensive answer. The short answer: there's a hell of a lot more to messaging security than "sign and encrypt"! What about anti-spam protection? What about hardening the base OS? What about risk assessment? What do you do if your boss comes to you and says he wants to read a coworker's mail?

The book's 506 pages because it:

• begins at the beginning with a detailed discussion of fundamental security principles, including the need for good physical security and the difference between various methods of authentication, encryption, and access control
  
• covers risk assessment and physical and operational security in some depth-- rare for a non-textbook security book
  
• completely describes a workable patch management process, something that every Windows or Linux admin had better be good at (particularly on the Linux side, where patch auditing, assessment, and deployment tools suck. Disclaimer: I don't talk about Linux patch management. Ha ha.)
  
• explains how to deploy and use S/MIME-- a topic that's poorly explained in most of the Exchange and Domino books I've evaluated to date. Can you cross-certify? Can you issue certificates to use the web client with smartcards? My readers can.
  
• explains how to use and secure a number of Exchange 2003 features that Domino doesn't even have, like wireless device access, attachment blocking and control for the web client, the anti-virus API, and so on
  
• tackles several issues that even Domino admins care about, like message archiving and retention requirements and legal issues about when you can, cannot, should, and should not open or scan user mail for legal or law enforcement reasons, the DMCA, and so on.
  

In fact, I'm so confident that even Domino administrators who run on Windows would find the OS hardening, archiving/retention, and legal chapters to be useful that I'll make a bet: I'll let the Domino community pick a representative to review the book, and I'll supply a review copy. If the reviewer doesn't honestly think that this is a terrific and useful book, and that it does a great job of explaining the wealth of security features provided in Exchange 2003, then I'll donate US$250 to a charity of Ed Brill's choice. On the other hand, if the reviewer finds-- as I'm confident he will-- that the book rocks, the reviewer will post reviews at Slashdot, ERCB, his own site, and Ed's site. Deal?

All right, I've had it. I am tired of waiting for "real" media to pick up on this story.

Oracle won't give its customers security patches unless they buy a support agreement. This is flat-out wrong. It holds customers hostage in a particular nasty and egregious way: if you don't buy support, you can't get the patches you need to protect against vulnerabilities in products you've bought and paid for even if they're still current.

If Microsoft did this, they'd be (rightly) pilloried. As it is, you can get any security patch for any supported product for free, either as part of a service pack or by directly calling Microsoft PSS. Microsoft has even extended the end-of-support date for Windows 98 and Windows NT so that customers can continue to get support (and patches) for them.

Of course, very few large Oracle customers run in production without support, as you would expect from such a large, complex group of products. Perhaps their customers don't care that they can't get patches without support because they all have it. I still think it's wrong.

(n.b. I don't know what IBM and Novell do in this scenario, but I aim to find out. Stay tuned.)

I keep seeing hysterical reports that Bill Gates wants to impose e-mail postage to stop spam. A quick Feedster search for "gates spam postage", for example, turned up 90 posts. Most of these are based on this CNN/AP story .

Unfortunately, virtually all of the articles and commentary miss the point: Microsoft's not calling for people to pay money for postage. Instead, they're floating the idea of using a hashcash-like system that requires the sender to perform a calculation (something like a hash of the message plus the sender's address, with some additional crypto thrown in) before sending the message. The MS Research system (described somewhat here) uses a similar idea: if you require a certain amount of computation to send messages, that raises the cost to people who send out millions of messages, i.e. spammers. (Interestingly, the BBC article says that Cynthia Dwork, who first floated the idea of computational-postage systems in 1992, is now working at Microsoft Research. Her original paper, here, makes for interesting reading).

Now, here's the part that most people are missing in all the "Bill Gates wants my postage" kerfuffle. If the message doesn't have a valid hashcash token, it can be passed through a normal spam filter. . In other words, if it has "postage" (which is created by burning a few CPU-seconds on the sender's machine), it can be directly accepted (or not), but if it doesn't have "postage" it gets the full proctologist's treatment with SpamAssassin, the Exchange IMF, or whatever. (n.b. Ecto's spellchecker recognized "proctologist's"-- pretty cool, huh?) This is exactly analogous to what we all do with postal mail: if I get something that was mailed bulk rate (thus lacking "postage"), it's much more likely to get canned.

Microsoft is not suggesting that we pay actual cash for any of this (although these guys, and others, are). Calm down, everybody. Considering that there aren't any viable micropayments systems (and yes, I include Peppercoin in that dismissal), the idea of requiring actual micropayments for email is laughable, and no one knows that better than MS. However, a hashcash-like system is a useful adjunct to (not replacement for) other filtering systems. In fact, there's already at least one hashcash implementation, FirePay.

So, Ed Brill has been reading the Exchange team blog, probably for much the same reason that Microsoft PMs read his blog-- know your enemy, and all that. So, let me leave aside the fact that it's disingenuous (and, IMO, slimy) of Ed to say "I'm not spinning, but $spin..." and point out one key difference between IBM and Microsoft's support programs.

With Microsoft, any customer with a credit card can call Microsoft PSS and get support for any active product. If you want to buy a support contract, fine, but if you don't, you can still get support. The PSS org thus has to be sized for variable call volume from an unpredictable mix of 5.5, 2000, and 2003 customers, calling at unpredictable intervals. As far as I can tell, the only way to get any support from IBM (apart from their relatively useless support forums) is to buy a Passport Advantage contract, pricing information for which isn't publicly available. This gives IBM a pretty good way to predict required staffing levels, given that they know exactly how many customers they're obligated to support.

It's an interesting tension: limiting your support to contracted customers helps screen out a large percentage of customers, who are then hosed when they do need support, but that smaller support base means you need fewer support engineers, who will generally have lower utilization. Of course, MS would hire more PSS engineers if they could; in fact, they're aggressively hiring for the Exchange support team, but the skill bar is pretty high, so it takes time to fill the open positions.

Ed and I are in agreement on one thing, though: it is refreshing to see the blog-driven openness that is slowly permeating Microsoft, IBM, and other large companies. (Well, we agree on two things: AT&T's new upgrade program stinks.) That openness is all the more refreshing when it's factual and technical, not just more marketing spin and hype.

Update: Ed was kind enough to link here from the comments to his post, in which he points out that edbrill.com isn't an IBM web site. That's true, and I should have made it more clear that Ed is of course speaking only for himself, so I retitled this post slightly.

Among others, CNet is carrying this story. There's a great deal of additional material at their site, including this interesting architecture diagram. Is this a credible threat? Not yet. These guys have literally millions of man-hours of catchup to do before producing a product that does what Exchange and SharePoint Portal Server (their apparent targets) can do. I won't even attempt to list the hundreds of features that have to be implemented before they even reach parity with Exchange 5.5, much less Exchange 2000... much less Exchange 2003. Of course, since they're not trying to implement a mail engine they get off the hook for a lot of stuff. We'll see.

Is there some reason why you can't just give me a context menu item to add a sender to the server's whitelist? Having to review messages in the console and then add them to the configurator is a pain in the butt-- just let me right-click an item in the console and say "add to Friendly Senders" or "Add to Friendly Listservers". Just a suggestion that your competitors have already implemented...

Woo! If I was a drinker, I'd buy Tim Mullen a beer for this column.

MS Press has generally been quite competent and pleasant to work with, but I'm not very happy with them right now. My book is due to be on shelves in 9 days (2/5, baby!), but do you think it's mentioned on their web site? Noooo, of course not. There's no "Robichaux" in the author list, and searching for "secure" turns up three books, none of which are mine. My original editor is out on parental leave, but his replacement has promised to investigate.

Why should you care? Well, until they get the MS Press page for the book up, I have no sample chapters to post here. That means you have two choices: be a trusting soul and buy the book sight unseen, or wait for the samples. Personally, I prefer the first option, but I realize that not everyone likes to buy on faith alone. I'll have the samples up this week, even if I have to make them myself.

My wife likes to play bridge; so do all of my other female relatives (well, OK; most of them, anyway). She plays once a week against my mom, sister, and aunt, using Yahoo! Games' Java bridge applet. Their applet usually works fairly well, but that was before I installed ISA Server, which is much more capable than the appliance firewall I was using before.

To make a long story short, you must open some ports to make the Yahoo! Java games work right. They admit this, but they get the port numbers wrong! Ack! I eventually found the correct answer at Tom Shinder's ISA Server site, but I shouldn't have had to-- not to mention the 20 minutes or so I wasted trying various combinations of ports according to Yahoo!'s specs. Idiots.

So, word to all vendors: if you're going to publish security information, get it right. Otherwise, I will have to sic Russ Cooper on you.