Do Manufacturers Have Any Responsibility?
I'll readily admit that I don't use any Microsoft products: in fact, none of my machines has a DOS or a Windows partition. And I think early 1997 was the last time I sat down at an x86 box running Windows. But this spring's outbreak of viruses has caused me to think about the burden that should be borne by a manufacturer.
Any manufacturer has both a moral and a legal accountability to its customers. The various manufacturers of automobiles, children's toys and tobacco products, for example, have learned painful lessons about accountability through product liability suits.
“ILOVEYOU” and “Killer Resume” exploit holes in Microsoft Outlook that any less-avaricious company would have tried to stop several software generations ago. (I might note that the first RFC concerning security is 602 (December 1973), and was written by Bob Metcalfe, the inventor of Ethernet.) In my view, Microsoft has willfully ignored customer security for at least 20 years.
As Gene Spafford (Purdue University) has pointed out, even though Microsoft (and the tobacco companies) sell products that customers appear to want to buy,
does that make the tobacco companies less culpable for selling a product they know to be dangerous? Does it matter that the consumers shell out money willingly for the product? (Even those who have some idea of the danger believe they have no control or choice.)
There is a fundamental question involved in the area of informed consent. If the consumers actually understood the technology and the risks posed by their choices, and if they actually were able to make an unconstrained choice, would they make the purchases? If not, there is a moral (and potentially, legal) obligation for the vendor to make wise decisions on their behalf.
Gerald Shifrin (on the IP mailing list) noted:
As an ordinary non-attorney consumer of computer products, it seems reasonable to me to expect that my software should ask permission before sending email to everyone in my address book or performing a mass deletion or modification of my files. If vendors like Microsoft allow or assist unsolicited foreign email to perform these acts, they are, at least in my mind, guilty of gross negligence.
In fact, I found it puzzling that after “Melissa” and then “ILOVEYOU” and now “Killer Resume”, the newspapers aren't noting mass filings of product liability suits against Microsoft. If the world's economy can be brought to its knees by very simple code delivered via e-mail to PCs running Outlook or Observer or Explorer, then parts of that economy should be holding the manufacturer responsible.
Kevin G. Barkes (on the IP mailing list) posted:
Another real-world analogy: you're tooling down the Interstate in your Chevy and hit a bump in the road. The doors fall off and the engine explodes. You have the ambulance driver stop at the dealership on the way to the trauma center so you can chew out the service manager. He sneers at you condescendingly and points to a paragraph of six-point type buried in a totally unrelated portion of the owners' manual:
The doors of your car will fall off and the engine will explode when you hit a bump while traveling on an Interstate highway. One of our engineers thought this feature would be neat and we have added it at no extra charge to you. If you disagree (you weenie), you can disable this feature by performing the following procedure. First, obtain three chickens, two brown recluse spiders, a length of nylon rope and a virgin ...
Barkes points out that “Melissa” and “ILOVEYOU” were “badly-written programs created by rank amateurs”. What would happen if a really malicious first-rate programmer wanted to target Microsoft Outlook or Outlook Express?
Another list member said this about Spafford's posting:
To further agree with Gene's point about tobacco and “what consumers want”, let me suggest that at any one point the market offers only a tiny subset of what is possible to create for consumers. Mere selection cannot create possibilities that are not developed or invented. Monopolies distort the creation of selections—in particular in systems' properties like security.
Because of its installed base dominance, Microsoft's primary drive for innovation comes from a need to motivate an orderly “upgrade” revenue stream, while at the same time blocking competitors from entering the market to take that revenue away. That means innovations will be small, incremental, and extremely easy for customers to adopt.
By the time you read this, all questions on the DoJ's case against Microsoft will have been answered, pending a decade of appeals. But even a partly knowledgeable reaction on the part of customers may well put Microsoft into the product liability dock, and send Outlook and its kin the way of the Chevy Corvair.
Peter H. Salus, the author of A Quarter Century of UNIX and Casting the Net, is an LJ contributing editor. He can be reached at email@example.com.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SourceClear Open
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Non-Linux FOSS: Caffeine!
- SuperTuxKart 0.9.2 Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide