While my computer is busy pulling down the latest Microsoft patches, Id like to share new information about the amount of bandwidth these downloads consume.
In my Sept. 22 column, I said Microsoft has marked its Windows Update files “noncacheable.” As a result, one small ISP in Wyoming found that more than 90 percent of its bandwidth on a recent day was soaked up solely by customers plugged into Microsofts update service.
Corporate sites and large ISPs, of course, dont have to deal directly with Windows Update. Instead, they can and should use a patch management utility or a caching proxy server, respectively.
But Windows Update threatens to become an industrywide problem, not just an annoyance to a few ISPs. Now that viruses are exploiting new Windows vul-nerabilities within days of their discovery, Microsoft officials are mulling the practice of preconfiguring home PCs to run Windows Update automatically, perhaps daily.
A single upgrade can eat up 30MB. Thats one home user getting Windows XP Service Pack 1a, using Express Install. On the day that 100 million PCs boot up and obediently start downloading fixes such as this, I hope none of your employees or customers need to use the Web.
After my Sept. 22 column appeared, I asked Microsoft to explain why it requires each Windows Update file to be dragged through the pipe over and over instead of just the first time. It appears that the subject of patches is making the software vendor a wee bit touchy these days. After a couple of e-mail exchanges, a Microsoft spokeswoman sent me this final message: “Unfortunately, my colleagues have informed me that Microsoft does not have additional information to add to your piece at this time.”
Fortunately, others arent quite so reluctant to talk. Like many companies, Microsoft makes its downloadable files available through widely distributed servers provided by Akamai Technologies. We can presume that if Windows Update files on Akamai servers are marked noncacheable, Microsoft has ordered them to be configured that way.
“A lot of content providers are worried about the security of downstream [ISP] caches,” said a source at Akamai. “If someone is able to corrupt the files in a cache, it would be blamed on the content provider, not the ISP.”
Since Windows Update files are digitally signed, a malicious hacker could hardly corrupt them in an ISP cache. But even if that werent true, trying to ban caching will ultimately fail anyway. IBMs WebSphere Application Server already includes an “aggressive caching” setting that preserves a copy of files marked noncacheable (see www.bri.li/3401). For smaller installations, an ISP in Australia has published a workaround that redirects Windows Update requests to a private cache (www.bri.li/3402).
Requiring PCs to check for and download patches daily may be a fine idea. But the computer industry should demand a secure way of doing this that doesnt involve bringing the Net to its knees.
Now, if youll excuse me, Ive got to see how that download is coming along. …
Theres Hope for .zip
we may actually have progress on a different front. I wrote in my Sept. 8 column that PKWare, the maker of the PKZip utility, had applied for a patent on a more secure .zip file format. The company long ago dedicated the .zip format to the public domain.
PKWare CEO George Heddix has since told me in an interview that his company has decided to license the secure technology—free of charge—to all competing .zip/.unzip utility makers, whether or not the patent is granted.
This is a step in the right direction, although its awfully tardy. Itll be months before the new files PKZip cranks out are readable by other programs, including Windows XPs built-in .zip support. I urge CIOs to impress upon PKWare executives the importance of planning future changes to the publicly owned .zip format in a fully open manner. ´
Discuss this in the eWEEK forum.
Brian Livingston is editor of BriansBuzz.com and co-author of “Windows Me Secrets” and nine other books. His column appears every other week in eWEEK. To send tips, visit www.briansbuzz.com/contact. Send your comments to [email protected].