Path: utzoo!attcan!uunet!samsung!uakari.primate.wisc.edu!uflorida!mephisto!ukma!morgan From: morgan@ms.uky.edu (Wes Morgan) Newsgroups: comp.edu Subject: Re: The ethics of dribble files Summary: stifling interest, killing experimentation Message-ID: <14055@s.ms.uky.edu> Date: 7 Feb 90 12:51:18 GMT References: <1691@skye.ed.ac.uk> Organization: U of Ky, Math. Sciences, Lexington KY Lines: 70 In article <1691@skye.ed.ac.uk>, ken@aiai.ed.ac.uk (Ken Johnson) writes: > a dribble file is a file which contains a record > of the conversation between a user and a computer. > > So the first issue is whether teachers should have > privileges (like inspecting dribble files) reasons other than the > protection of the integrity of a system. > It occurs to me that the responsibility for the integrity of a given system lies with that system's *administrators* rather than those teachers who may be using the system. Many faculty members are far to busy with their regular commitments to deal with system integrity and security. > Secondly, I feel a bit dubious of the ethics of letting the teacher > overhear conversations like this. When I last implemented a dribble > file, it was possible to set up the system so that it started up without > the user's (a school child typically 7-12 years old) knowledge. I now > feel that it would have been more nearly ethical to give a message along > the lines of ``This session is being recorded.'' > > Any ideas about this? Hmmmmm...my only concern would be the possible stagnation of the student's curiosity. I remember when I started learning BASIC-PLUS-2 on a PDP-11/34 under RSTS/E. After discovering how to read system stats with the SYSTEM() function, I wrote a small program to simply list the characteristics of my terminal and port. The next day, I received a rather stern letter from a sysop flatly telling me that students were NOT allowed to write such pro- grams. He admitted that the program in question had caused no problems; it was, according to him, simply a "matter or policy" that students could not conduct "unauthorized programming experiments". Much the same thing happened when I started learning REXX on an IBM 370/165. I had written several small REXX programs, but found them missing upon my logon one morning. In their place was a piece of mail informing me that since my account was given to me for the purpose of learning PL/1, I had no business writing REXX routines. Both of the episodes above were, in my opinion, the results of dribble files or their equivalent. While I can understand the teacher's con- cern about completion of assignments, I feel that care must be taken to allow the student a little leeway, especially if they are performing well in their classes. Most systems already have measures in place to prevent potentially dangerous dabbling by normal users; VMSECURE and FILDAE are good examples. Having already placed responsibility for system integrity with the sysadmins rather than the teachers, we must consider the tools available in this area. acctcom, acctcms, ps, /etc/whodo, find, and su are just a few examples. If all these tools are available, why bother with a verbatim transcript? If necessary, a good sysadmin can reconstruct a session from the accounting files with a minimum of hassle; for example, I use acctcom -u | sort | awk . There *is* an instructional use for dribble files, though, especially in complex packages such as ANSYS or SPICE (or SPSS-X or CBDS or....). Cer- tainly, review of dribble files can locate problems areas for each user. Why not patch the individual packages to create dribble files? After all, these packages are the crux of the teacher's interest; he shouldn't care if the student reads USENET after his classwork is completed. To summarize, I would have no ethical problem with implementing dribble files for individual packages such as SPICE or f77; global dribble files are not necessary for general user sessions, nor are they ethical if imple- mented without cause. Wes Morgan ps> Replies to morgan@engr.uky.edu or ...!ukma!ukecc!morgan, please.