[1167] in Public-Access_Computer_Systems_Forum
GopherCon '92-Trip Report, Pt. 2 of 2
daemon@ATHENA.MIT.EDU (Public-Access Computer Systems For)
Tue Sep 8 09:50:47 1992
Date: Tue, 8 Sep 1992 08:36:25 CDT
Reply-To: Public-Access Computer Systems Forum <PACS-L%UHUPVM1.BITNET@ricevm1.rice.edu>
From: Public-Access Computer Systems Forum <LIBPACS%UHUPVM1.BITNET@ricevm1.rice.edu>
To: Multiple recipients of list PACS-L <PACS-L%UHUPVM1.BITNET@ricevm1.rice.edu>
From: emv@msen.com (Edward Vielmetti)
Subject: Trip Report: GopherCon '92 (by) Prentiss Riddle
From: riddle@is.rice.edu (Prentiss Riddle)
Subject: GopherCon '92 trip report
GopherCon '92: Trip report
Prentiss Riddle
riddle@rice.edu
8/17/92
Part 2 of 2
HARDWARE OFFER FROM NeXT: One of the few non-university attendees was
Greg Smedsrud of NeXT, who surprised us on the second day by making a
special offer. NeXT has 120 NeXT 040 cubes which they are willing to
sell to be used as Gopher servers at 70% off list. There are various
configurations available, but a 16 Mb/400 Mb cube with NeXTStep 3.0
would go for about $3200. There was some discussion of how much
performance this would mean; Allan Tuchman of UICU said he had a
similar configuration running as a Gopher server which took
approximately 100K Gopher connections per day with no problem. (An
important distinction was made between a telnet connection to a public
Gopher client and a Gopher protocol connection; Allan of course meant
the latter.) This offer will only be good for the next two weeks. I
don't know that it was clear whether the offer extended to everyone in
Gopherland or only the conference attendees. Serious inquiries only go
to gsmed@next.com.
REPORTS FROM THE OTHER BOFS: The "Usability" BOF liked Gopher+,
suggested "gophernews" or the ability in a client to limit a view to
only new or changed items. The "Gopher+/RFC" BOF went into detail on
the proposed protocol extensions. Some ideas: more types (archive and
binary archive and the ability for a client to "peek inside" a .tar.Z
file on a server), the ability for the client to ask the server for
specific attributes, and SEE-ALSO, PREVIOUS and NEXT attributes to
allow items to include links to other items.
The "Distributed Workload" BOF divided the Gopher development job up
into three main areas: (1) code development, (2) documentation, and (3)
resource management. Documentation in particular was agreed to be an
area where the Gopher community at large could help the UMinn
Gopher Team. Andrew Gilmartin (Andrew_Gilmartin@brown.edu) volunteered
to head up a Gopher documentation effort. Three areas for enhanced
documentation which need people to work on them: server installation
and administration, porting existing Gopher software to new platforms,
and product development.
SERVER ADMINISTRATION PANEL: A common theme among everyone on the panel
was the need for some degree of centralization of Gopher administration
in order to provide a reliable and high-quality CWIS. This is not to
say that an institution as large as a university should have only one
Gopher server: we should look forward to "competing" top-level views,
perhaps in the form of departmental Gopher servers, but someone
mandated to bring up a CWIS would not be well advised to pursue the
"Gopher server on every desktop" model of totally decentralization, if
only because desktop users tend to turn their machines off and go on
vacation.
Joel Cooper of Notre Dame reported on his organization's Gopher
administration methods. Notre Dame uses its campus-wide Andrew File
System as the place for individuals to maintain data intended for the
CWIS. Each data provider registers with the CWIS administrators and is
assigned a node in the CWIS data tree (perhaps shared with others).
Henceforth, anything which the user puts in her ~/gopher directory is
automatically examined for inclusion in the CWIS. All documents
submitted to the CWIS must include a template at the top specifying an
expiration date, title, and optional keywords. The collection robot
adds to this the provider's name, organization, e-mail address, a
posting date, and, at the bottom of the document, a disclaimer to avoid
"kill-the-messenger" problems. All of this information appears
together with the document text itself in a single file and is visible
to the Gopher user. Subdirectories under the provider's ~/gopher
directory will be mirrored in the CWIS's data tree. Micro users who do
not wish to work in an AFS directory can use ftp or a mail interface.
Mail forgery problems are avoided by a feedback loop: when a document
is accepted by mail, the provider receives an acknowledgement by return
mail. Similarly, documents are expired from the CWIS on the expiration
date and mailed back to the providers, who are free to extend the
expiration date and resubmit them. Notre Dame's CWIS was designed by a
committee and quality control is ensured by peer review (providers who
do a bad job managing their Gopherspace are asked to do better). The
Notre Dame method has certain limitations (no indexing, no links out
into Gopherspace, and poor scalability to very large bodies of data)
but it seems to work well for the majority of Notre Dame's information
providers. It has certain site-specific dependencies (AFS, the CSO
nameserver and the local mailer) but it may be useful as a design model
for other sites.
Dennis Boone of Michigan State reported on several tools he has
developed (largely as perl scripts) for Gopher administration. They
include his well-known gophertree and gopherls tools and a recently
released pair of scripts which allow keyword searches of Gopher item
titles. His CWIS allows multiple views of the same data to suit
different needs (topical, organizational and and indexed).
SECURITY AND PRIVACY: This was one of the liveliest sessions at a
lively conference. I went into it with concerns about possible
security problems in Gopher+, but was surprised by something I hadn't
thought of: the privacy issue raised by the Gopher server's logging
mechanism. Gopher logs show what was read at what time from what IP
address, often sufficient information to point to an individual user.
While the computer people in the crowd immediately thought of the
possibly trivializable issue of sexual materials on the net, librarian
Nancy John pointed out that (1) libraries constantly face subpoenas for
their user records in court cases involving intellectual property and
other matters, and (2) this is a serious intellectual freedom issue
with far-reaching implications. In addition to subpoenas,
administrators at state-funded universities must face the fact that
"everything is FOIAble!" (under the Freedom of Information Act).
Librarians have responded by retaining detailed user records only until
materials are returned, then replacing them with general demographic
information. A short-term solution for concerned Gopher administrators
may be to turn off logging. Long-term, the server may be modified to
record only a partial IP address or to decouple what is read from what
site is doing the reading.
The discussion turned to access control. It was pointed out that
hostnames are easily forged, so the Gopher mechanism of restricting
access by hostname or IP address is not perfect. Wide-area equivalents
of Kerberos may be coming which will allow real authentication,
although not everyone was equally optimistic about that. An important
distinction was drawn between two levels of authentication: (1)
licensed data (Clarinet, Medline, etc.) when a reasonable effort at IP
address authentication or simply asking the user to enter an ID number
may be sufficient, and (2) sensitive internal data for which only
Kerberos or some not-yet-Gopherized mechanism is good enough. The
second class of data should not yet be served out using Gopher. A
complication of authentication for Gopher is that the protocol does not
maintain a connection for multiple transactions and the server does not
maintain state between transactions, so authentication can only apply
to a single transaction.
The security implications of Gopher extensions were a hot topic. The
use of the Gopher+ "ASKP" mechanism to ask users for passwords was
considered quite harmful: it is not really a secure password method and
it invites spoofing. The Gopher Team has withdrawn it from the Gopher+
proposal. The Gopher+ "ASKF" mechanism, which allows the server to
request a file to be uploaded from the client with the user's approval,
was also considered dangerous: a naive user could be fooled into
authorizing that "/etc/passwd" or other sensitive data be uploaded to
the server. Suggestions for making "ASKF" safer included limiting the
requested file to the current working directory or to some
predetermined temporary file name.
Next came security concerns involved in running a public Gopher client
(a Gopher client accessible via telnet or on a public terminal which is
not tied to a particular user's account). There have already been
cases of such Gopher clients being used by system crackers to "launder
IP addresses". The Gopher practice of leaving people at the "front
door" of a telnet site is dangerous (library systems are particularly
notorious about having crackable systems accessible through the same
port as the online catalog). This is ultimately the responsibility of
the targeted systems, but a responsible public Gopher administrator
will log connections and participate in the tracing of crackers. This
is an area where better documentation is needed: there should be a
simple document on how to properly set up a public client.
Scripting got delayed till the "open mike", but I'll mention it here:
it was stressed that any scripting language implemented in a Gopher
client must not contain hooks for manipulating local files or uploading
data under the control of the server. This includes programs
masquerading as simple data (e.g., clients should interpret PostScript
only with a "safe" previewer). One type of scripting which is strongly
desired is the ability to script telnet or tn3270 sessions (e.g., to
log into a library without the user having to type "NOTIS" once the
telnet connection is made). This is a problem if the communications
protocol used includes a "send file" ability. The Gopher Team has not
yet proposed adding scripting capability to the protocol, but a number
of independent efforts are pushing in this direction.
REGIONAL COOPERATION: This discussion was mostly of interest to CICnet
members. I will say that I was impressed with CICnet's determination
to provide network services, not just connections. The work they put
into GopherCon was strong evidence of this.
FUTURE CONFERENCES: CICnet has indicated its willingness to continue to
host GopherCons, perhaps every six months, although not always in Ann
Arbor. As with this one, they will be small regional conferences with
a limited number of slots for attendees from outside, essentially by
invitation only. They were kind enough to "grandfather in" anyone who
attended the first conference. I expect that they will continue to be
excellent.
-- Prentiss Riddle ("aprendiz de todo, maestro de nada") riddle@rice.edu
-- Unix Systems Programmer, Office of Networking and Computing Systems
-- Rice University, POB 1892, Houston, TX 77251 / Mudd 208 / 713-285-5327
-- Opinions expressed are not necessarily those of my employer.
End of Part 2 of 2
