The August 11, 1998 issue of Anchordesk has an
article on "Computers
That Understand You". The whole notion of a computer that can listen to natural
English and do what it is supposed to do keeps recurring. It is a very seductive idea and
for the last thirty years we've been almost there but somehow haven't arrived.
There have been accomplishments. In the early 1970's Terry Winograd demonstrated
"Natural Language" processing. But upon closer examination, the techniques used
in this and other similar efforts took advantage of tricks and shortcuts that didn't
correspond to true intelligence. The problem, however, was not in the cheating per
se, but in the constrained environments that allowed for cheap tricks. Andy Clark, in this
book Being There, makes the point that intelligence is, in fact, accomplished by
leveraging the environment rather than complex computation. But we don't understand enough
of this yet to capture it in a software system. Especially one that is disembodied and
thus lacks the support bag of tricks.
But do we want to recreate a human secretary or butler in the computer. The simple
answer is no. The fact that people choose ATMs (Automatic Teller Machines) rather than
human tellers is interesting. Such a device becomes an extension of ourselves whereas a
human teller is another person which requires extraneous social interactions.
Another example is the disappearance of dictation. The reason is similar. While in
theory a human secretary can help with the creative process, in practice dictation is
caught in the middle. If we just want to send a simple message, the purpose of the person
taking dictation is to flesh out some thoughts mechanically to meet business letter
standards. And then the recipient decomposes the letter to discover the message within.
For such messages, email has manage to change the social etiquette to the point that the
message is sent unadorned. On the other hand, if the person taking the dictation is
supposed to add substance, then we just assign the task of creating the message rather
than dictating. This is more than just a mechanical translation system.
Perhaps then, natural language is useful for databases for those who need more
flexibility than filling out forms. After all queries are complex and cumbersome. The
problem is that in order to use a database effectively, one must have an understanding of
databases. At that point, English becomes a problematic way of expressing queries.
SQL or sugared versions on query forms is a much more effective way of describing the
request and generally avoids the pitfalls of English.
There is a long history of using "English" to simplify programming from COBOL
to HyperCard. But both cheated and required rigorous syntax. For the casual reader of a
simple program the use of English seemed to make it more readable and, perhaps, seduced
the naive into programming by making it look natural. But one must rapidly learn the
specifics of the language in order to write programs. And to read programs, one must
understand the idioms of the language which are often obscured by the semantic loading of
the English.
What about dictation? Perhaps. After all, it is much easier to speak than to type. Or
is it? Again, if we have canned phrases that don't require much thought then speaking can
help. And there are those not facile in typing. But before we think about dictation we
must ask the more fundamental question of why we are trying to create text at all? Why not
just send voice messages. Current systems are very capable to capturing speech and sending
it as a message. The problem is that speech is cumbersome for the recipient. But it is
also problematic for the sender since it is difficult to edit. Text serves the needs of
both the author and the "reader". It gives the author the ability to tune the
expression and the recipient the ability to skim and manage messages.
But if the purpose of text is to allow for editing, then the purpose of dictation is to
save on typing. This edge is lost if the speaker must resort to even a small amount of
intervention to correct errors in speech to text translation.
The Palm Pilot with Graffiti and other similar systems represent interesting tradeoffs.
There are environments where entering text with a pen seems useful. But general
handwriting recognition is as problematic as speech. The solution was a compromise -- a
way of writing text that was easier for the computer to process but which wasn't radically
different than normal lettering. And it seems to work. But from my own experience it is
still a cumbersome process that I tolerate only because of the form factor advantage.
Perhaps when single handed keyboards and other devices become more available, they will
have a major advantage of such lettering.
Other language, such as the Chinese/Japanese ideographs are more tuned to writing by
hand and may have more value in text entry but they still require a complex set of strokes
rather than quick selections as on a keyboard. This doesn't mean the keyboard is the
ultimate input device. Even for text one can imaging designing an entry system that uses
efficient stroking systems less beholden to the quill-pen heritage. Perhaps the ideographs
are a step in this direction.
I do expect that natural language, speech dictation and other systems will remain
attractive to those who see anthropomorphizing the computer is the way to go. We also see
this desire in trying to recreate servants with computer agents and in programs that are
supposed to understand our emotions. But these attempts miss the larger goal of giving the
user effective access to the capabilities of these information systems rather than trying
to recreate some idealized past. Do you really want to drive a car with reins?
In keeping with the theme of this issue, I want to address another "computer
science" issue. While the Natural Language stems from a desire to make humans more
like computers, the current approaches to security are based on simple notions of security
from the early days of computing when the world was simple.
You would log into a timesharing systems by giving your name and your password. Your
user name represented your identity on the system and you could specify who could read or
write or you files according to this identity. Very simple. There are some
extensions such as groups and additional access controls for listing directories of files
and permissions for executing programs but the basic idea was simple. One controlled
access to resources within the computer.
There worked well for the target audience, developers and others running programs on a
computer. These were normally developers and computer savvy users. The needs of those less
savvy were simple and typically involved the use of some standard programs and access to
common data.
Access for a far larger class of users didn't fall within this system. They were clerks
and others who used standard programs. The programs themselves determined the true access.
But the rules were typically embodied in complex application-specific code. As database
systems developed they attempted to provide mechanisms to simply controlling access as
well as introducing notions such as temporarily locking data to avoid conflicts. In
general, one accessed the system according to ones role, and the access was associated
with that users. Or it could be associated with a workstation at a geographic location.
Airline reservation systems are good examples.
From the point of view of the software developers, both were programs executing on a
system. There was a major difference in how policy was applied. For a user who had the
ability to create new programs, access control was implemented by the operating system.
This was feasible because the set of resources was simple -- could you read a file and
could you write the file. But this was too simple and mechanisms were created to extend
this. One approach was to allow programs to act as systems extensions and run with
additional privileges. These programs were trusted to be responsible citizens. For
example, such a program might provide an interface for delivering messages to another
user's message queue without allowing direct access to the queue.
In Unix systems which had a very primitive access control system these mechanism was an
important way to extend the system. The "su" (system user) command took a
brute-force approach of giving a program unlimited authority. And errors in such programs
an interactions were a typically way of subverting system security.
As computer systems become more sophisticated, a given process (or session) had
ownership of many kinds of resources beyond files. It was natural to extend the model of
access control to these objects. Adding to the mix are other access control mechanisms on
resources such as disk drives (file systems, to be more specific) and access controls
within applications such as databases.
At the same time, the simple notion of a user logging into a system is problematic. As
computers become tools and agents for a wide variety of tasks, not just one job function,
the simplistic notion that role and identity are identical is not tenable. When I am
sitting at my PC, I may be doing some personal writing and also handling business
correspondence and rapidly moving between them. But we are also in the real world where
such a differentiation is usually ambiguous. If I am performing a job function I'm likely
to be meeting the needs of my customers while also meeting my personal career needs.
The other legacy of Unix and systems in isolation has been a very relaxed notion
towards controlling access to information. If I'm within a workgroup, it might be
acceptable for the default to be to share with my colleagues. After all, a Unix system was
very inexpensive compared with Multics, the system that spawned Unix. Multics was meant to
be a computer utility for a disparate audience and thus emphasized the need for users to
be able to control their access and, more important, trust the system. Thus the default
was to be safe and not grant any access while making it easy to grant and revoke access.
But, given the very benign assumptions, the default openness of Unix was
understandable. And this thinking went further with personal computers. With just one user
why even introduce such complicated notions?
These issues have come to a head as we've connected our systems to the Internet. We can
no longer assume that our systems are isolated islands. And the computers are also being
used for a much wider set of function of functions. Thus we need a way to specify access
in terms of these functions. But how does one specify access to a service (or object)? And
rather than just identity, we need to specify access in terms of the intent of the user as
intermediated by the program.
As noted, in the old days, all this would be embodied in the program providing the
services. This program was executed with many privileges and was carefully debugged. But
such programming is simpler if it would leverage the access primitives and specifications
the systems themselves.
Finally, we have the World Wide Web. As long as one is providing read-only access to
simple files of HTML on a closed system there are few problems. But even from the start,
there were generic problems. To make thing easy, systems would typically provide access to
file directories as well as text files. Thus one could explore a system and find files
that were not intended for publication as well as those that were. The reason was fairly
simple -- the systems themselves continued to be trusting single users systems and the web
servers were privileged programs. Unfortunately, the early systems, like Unix, were
trusting. The fact that many of the initial web developers grew up in the Unix world where
granting access was the default.
Things get considerably worse once we start implementing procedural services on the web
servers. Not only one must trust the web server but all the other procedural mechanisms
such as command line processors that have trap doors. By necessity, these programs must
operate with considerable access. Even just the ability to read an arbitrary file
represents a security exposure. Ideally one could specify what access web users have to
which resource but these depends on describing how to translate a user intent into the
access needs a distant service while still allowing the service itself much latitude. This
isn't really feasible.
It doesn't help that typical systems (such as NT) are distributed maximally vulnerable
and only those that read all the documentation, follow every rule and stay posted on every
security alert have a chance at some security.
So what to do? Well, that's why this is still a "column" vs a full essay.
My generic answer is simplicity and isolation.
But, first, we must have a very simple rule for systems design -- those who don't read
the documentation and who are not careful must not be unnecessarily exposed. This is a
very general statement but even that is violated very often. Administrators put their
system on the web with a default of being able to read every directory and read every
file. And poor innocents find their life published to the world.
Many systems have the notion of a default user access but this spans those who have at
least some identity on the local system to those who have absolutely no credentials. Thus
the simple and default settings are those with maximum vulnerability. We must recognize
that there are some degrees of access and the most common groupings must not be the most
naive.
One other topic on system design -- the whole notion of being bug free and error free
is dangerous.
I visited the cleaners today to pick up my clothes. I don't bother with keeping the
receipts since my phone number is an adequate index into the system. But the clerk was
confused until I told him that they were in boxes. Apparently they just upgraded their
system and it handled rack numbers but couldn't deal with boxes. Perhaps this was a new
system but the general attitude is to be upset at the designers and assume that one must
live with such bad design.
Whether one has errors or not, what is important is how one deals with them and
recovers. By recover I don't mean fix all the problems but make sure the system itself
retains integrity and cleans up the mess. From a design point of view, it's not only OK to
deploy an incomplete system but a requirement. How else can one learn by experience?
What is required is a process for incorporating the learning back into the system
design. This requires a shift from the traditional engineering approach of a sharp
demarcation between prototypes and shipping products. And this is possible in software,
unlike older hardware systems, since upgrading and evolution is doable and, with the
Internet, one can even maintain a link back to the supplier.
This is not a panacea as we really don't know how to keep all the system elements in
synch as systems evolve. But the notion of shipping Betas to customers is actually a very
good result of the Internet. As a customer I can decide on the tradeoffs between a vintage
version or a newer one with capabilities I need.
Another venue for this thinking is the Y2K world which is scrambling to "fix"
all the problems. There are two real dangers here. One is the obvious -- we won't really
be able to fix all the problems. And even if a few leak through we have some real
problems. So the emphasis should be on dealing with the problems that arise. If it is a
financial system, are there other information paths that don't share the same dependencies
which can be used as a cross check. Such an element is fundamental to good system design.
With such checks in place a problem like Y2K might be contained. And Y2K is not the only
problem, focusing on recover and resilience has a much larger payoff than local patches.
The more serious problem with Y2K is that fixing a bug is likely to introduce new bugs
and these won't be discovered until the real conditions -- the turn of the millennia
expose them. And these can be very nasty indeed. For example, patching the high digit of a
date to use "A0" for "100" might work well until that value runs into
a database validity check. But such a problem might not be discovered until the value has
aged sufficiently to pass through a series of archival system. More likely, the problems
will be just simple typos or misunderstanding in existing code.
Of course, maliciousness and other issues are also better addressed as recovery
problems rather than relying on the naively assuming that there will be no surprises.