Communications of the ACM
Communications of the ACM
Forum
I agree with Hal Berghel's thesis ("Digital Politics 2000," Nov. 2000, p. 17) that the major presidential candidates' Web sites did nothing to advance the state of democracy. The column raises a few questions, including: What steps are necessary to improve the state of democracy? Berghel mentions low voter turnout and the influence of monied interests as two aspects of democracy's fragility. More interesting, he mentions that the "voting electorate and responsible citizens are not coextensive" and that there are "subtle but effective obstacles to isolating the principles of free speech ... from the economic and social realities of the moment."
How can voters be made responsible? How can the exercise of free speech, press, and assembly be freed from the obstacles he refers to?
The second question has to do with, as Berghel says, the claim of some that "the Internet is the ultimate proselytizing agent and protector of democracy—the technical advance with the greatest potential for overcoming the fragility of democracy." What is the basis for this claim? What is so special about Internet technology that gives it so much potential for improving the state of democracy and addressing the fragilities Berghel describes?
Frankly, I worry that the Internet will exacerbate the tendency of citizens to disengage from the community. I worry that as media channels proliferate and specialize, most citizens will choose to be informed only by channels that reinforce their existing prejudices without challenging them. And I wonder if there is any viable vision of the future use of the Internet and of the media in general that is good for democracy.
Mike Zraly
Somerville, MA
Hal Berghel Responds:
In order for the Internet to become a democratizing experience, politicians will have to embrace the technology for what it is, rather than as an instrument of proselytism. That's a big pill for a politician to swallow, because it implies bidirectional information flow at a very personal level.
As an illustration, consider the typical town hall forum (assuming it's not broadcast far and wide). Few people are involved, and the conversation doesn't go much beyond the walls of the hall. This gives the politician a lot of latitude with respect to "burning issues" upon which he or she wants to remain politically pliable. Now contrast that with an Internet chat room, an Internet teleconference, or even just email posted on a bulletin board. In these cases, there is an audit trail of political rhetoric left behind that can be resurrected at a moment's notice. So far, politicians have decided these are not preferred venues of the body politic.
As far as free speech is concerned, examples of the vulnerability of the hoi polloi are to be found in virtually every corner of the globe. In many areas, engaging in a political dialogue inconsistent with the current view of the local government can be hazardous to one's health. The implications of one's free expressions tagged with email and IP addresses are alarming. Unfortunately, the best solutions we've come up with so far are such aberrant technologies as anonymizers, encryption services, remailers, and pseudonym services. None of them clearly fall within the category of a social good, and all are capable of malevolence.
Regarding the claim that the Internet is the ultimate democratizing agent, a claim frequently made in both the lay and trade press, I didn't say I agreed with it, just that I frequently heard it. The basis for the claim is connectivity. Some would have us believe the Internet and Web are inherently enfranchising and immersing, and that the potential for a truly responsible, representative government lies therein. I'd agree with this claim were this a perfect world. But it isn't, and I don't.
Zraly's concerns are legitimate ones, and we've already documented the potential for networked communications to foster Balkanization. Some are even studying the same effects within organizations. Email has become a political weapon in organizational politics. As IT specialists and practitioners, we failed miserably at predicting the harmful social consequences of email. Lets hope that we fare better with the Web.
Who Needs Digital Signatures
Boaz Gelbord raises some interesting issues about digital signatures ("Signing Your 011001010," Dec. 2000, p. 27). However, he makes one statement that is not entirely correct: "The main advantage of digital signatures over written signatures is their security. The mathematics ... guarantee that it is essentially impossible to forge a signature." Gelbord makes no mention that digital signatures can be copied easily and therefore misused.
If my computer, which contains my digital signature, is stolen, my identity is also stolen. If my credit card is stolen, there is a liability limitation of $50. But a digital signature, in order to be usable as a guarantee, will have to be without limitation. For example, the use of my digital signature in a transaction will be prima facie evidence that I ordered that particular item or service. It is my burden to prove my signature was stolen.
A digital signature can be copied without knowledge of the user. For example, it could be duplicated when a computer is serviced. Any protection of the signature (say by a password) could be cracked easily. If the signature were tied into a particular computer (for example, by the Pentium chip serial number), then the end user would have difficulty using it. Every time a new computer is purchased, users would have to reidentify themselves to the certificate issuer.
Business users have more need for digital signatures because of the number of transactions they process. They also have the resources to safeguard their signatures. For the average consumer, few documents need to be actually signed, much less digitally signed. For that group, the digital signature is a solution looking for a problem to solve.
Ken Pugh
Durham, NC
Misinformation and the Emulex Hoax
Bruce Schneier's statement that "The people who lost the most in the Emulex hoax were the ones with preprogrammed sell orders" ("Inside Risks," Dec. 2000, p. 168) caused me to wonder if the author himself was not guilty of the topic of his column. Was this more a hypothesis on his part or was it just an unchecked perpetuation of something someone else reported. After all, how could Schneier really know how much each investor lost without knowing when they bought?
I decided to take a quick look at Emulex's stock performance and found another surprise. Schneier wrote that the 61% drop occurred after an August 25, 2000 press release. According to the charts at Quote.com, the drop happened closer to March 25, 2000. Moreover, the stock had been trading at around $40 as late as October 1999. Thus, anyone who bought the stock before October 1999 then sold as it was spiralling down, did not lose any money at all, but instead had a gain.
I understand and I am in agreement with the general theme of Schneier's column. However, as he points out, misinformation is not a new problem.
Mat H. West
Greenville, SC
OOSCD Not Really So Unified
To claim that object-oriented system design (OOSD) "has evolved into what is defined by Ivar Jacobson, Grady Booch, and James Rumbaugh as the 'unified software development process'" will surely mislead some readers ("The Ups and Downs of Object-Oriented Systems Development," Oct. 2000, p. 69). Many of us endorse, teach, and enthusiastically practice OO development with little or no use of the "unified" methodology.
Furthermore, in quoting them as authorities, Johnson should have mentioned that Jacobson, Booch, and Rumbaugh are associated with a company whose principal products are CASE tools specifically oriented toward their own unified modeling language.
Conrad Weisert
Chicago, IL
Go Back to Non-OOSD
My impressions of OOSD are very different from those in Johnson's survey ("The Ups and Downs of Object-Oriented Systems Development," Oct. 2000, p. 69), although there is a big caveat. My non-OOSD development was under Unix, VMS, OS-2, and DOS. My OOSD was under Windows 9x, and Windows adds its own features into the mix.
In non-OOSD, it was fairly simple to exchange code (assuming standard C languages) between embedded processors and higher-level systems. With my Windows OOSD experience, internal to a project, much of the code sharing would occur easily without the OO features. In general, I want a subroutine to do A. Class C has that feature, but at this point in time, I don't have an object of class C. Is it easier to instantiate a class of type C to call the function (assuming you can get the results), call the function, then destruct the class, or just copy the code into Class D, where I need the call now? Generally, it appears that copying the code is easier.
Without the OO overhead (and assuming the code was written properly) the program that once was class D could just generically call the function in class C without any problem. You may need to link one of the object modules that was class C, but usually even that isn't necessary.
I've been a systems programmer (generally real-time data collection from the factory floor) for almost 15 years, involved in OOSD and design for only 1.5 years. Overall, if I had my way, we would go back to non-OOSD.
Terry Steyaert
Harrison Township, MI
Richard Johnson Responds:
While the average opinion of developers in my survey was very favorable toward OOSD, Steyaert is probably representative of several who do not hold a favorable view. Acceptance may depend on the exact languages, tools, methodologies, and support that different developers use or receive.
©2000 ACM 0002-0782/01/0200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2001 ACM, Inc.
No entries found