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.
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
|Introduction to MapReduce with Hadoop on Linux||Jun 05, 2013|
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
- Weechat, Irssi's Little Brother
- New Products
- Tech Tip: Really Simple HTTP Server with Python
- Poul-Henning Kamp: welcome to
1 hour 24 min ago
- This has already been done
1 hour 25 min ago
- Reply to comment | Linux Journal
2 hours 10 min ago
- Welcome to 1998
2 hours 58 min ago
- notifier shortcomings
3 hours 22 min ago
4 hours 59 min ago
- Android User
5 hours 58 sec ago
- Reply to comment | Linux Journal
6 hours 54 min ago
9 hours 43 min ago
- This is a good post. This
14 hours 56 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?