[comp.edu] The ethics of dribble files

ken@aiai.ed.ac.uk (Ken Johnson) (02/07/90)

This is an attempt to get peoples' opinions on `dribble files'.  I don't
know whether the term `dribble file' is a peculiarly Edinburgh term, so
first I will define it: a dribble file is a file which contains a record
of the conversation between a user and a computer. 

These are commonly used as research tools. 

I think I first felt there was an ethical issue when I heard at a
conference a speaker say that the computer could keep a record of
everything typed and display the record in response to some ``coded
password'' [sic].  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. 

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?

-- 
Ken Johnson, AI Applications Institute, 80 South Bridge, Edinburgh EH1 1HN
E-mail ken@aiai.ed.ac.uk, phone 031-225 4464 extension 212
`I have read your article, Mr Johnson, and I am no wiser now than when I
started'.  -- `Possibly not, sir, but far better informed.'

pritchaj@agnes.acc.stolaf.edu (John Pritchard) (02/07/90)

 There is a good article in the Higher Education Chronical (I believe it
is the latest issue) which discusses the rights of a teacher, computer 
center, student with respect to sending mail or posting of information.

If I understand you correctly, dribble files are the conversation between
just the computer and the user, with no intention of passing the informa-
tion on to a another party?  If so, I would think the ethics could be more
liberal, just due to the fact that there is less danger of abuse (since
the teacher is the only other person involved).

If the teacher had intentions of 'using' that dribble for some reason (say
to determine a grade, to place in a report, or book, or to pass on some
of the information in a conversation) I begin to become more conservative 
(i.e. a warning might be an ethical thing to do).  It may depend on your
definition of what 'using' would mean.  Just reading the dribble will 
affect your perception of the user, and therefore _could_ be considered
'using'.
John Pritchard
Carleton College
Northfield, MN 55057
jpritcha@carleton.edU

morgan@ms.uky.edu (Wes Morgan) (02/07/90)

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 <not to
mention graduate assistants and the like> 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 <mine> 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 <or their analogues on non-SysV> 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 <username> | sort <by start time> | awk <format and report>.

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.

doner@henri.ucsb.edu (John Doner) (02/08/90)

In article <1691@skye.ed.ac.uk== ken@aiai.UUCP (Ken Johnson) writes:
==This is an attempt to get peoples' opinions on `dribble files'.  I don't
...
==I think I first felt there was an ethical issue when I heard at a
==conference a speaker say that the computer could keep a record of
==everything typed and display the record in response to some ``coded
==password'' [sic].  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. 
==
==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.''

I'm a teacher, and I think the use of dribble files in the manner
described by you and some others is highly unethical.  I would not
consider it.  (I might have once, long ago, before I really thought
about such things.)  If a teacher wants a dribble file, he/she should
simply request the student to make it; it certainly should not be
accomplished automatically without the student's immediate knowledge.
The message idea is more acceptable.  But it would not be acceptable
to provide the message only at the beginning of the term, or even only
at the beginning of a session.  It should be issued repeatedly during
the session, rather the same way that people recording telephone
conversations are required to broadcast a tell-tale beep periodically.

-------------------------------------------------------------------------
John E. Doner         |"The beginner...should not be discouraged if...
Math. Dept., UCSB     |he finds that he does not have the prerequisites
Santa Barbara, CA     |for reading the prerequisites."

hammer@wsucsa.uucp (Tim .D. Hammer) (02/09/90)

In article <11184@thor.acc.stolaf.edu>, pritchaj@agnes.acc.stolaf.edu (John Pritchard) writes:
> 
>  There is a good article in the Higher Education Chronical (I believe it
> is the latest issue) which discusses the rights of a teacher, computer 
> center, student with respect to sending mail or posting of information.

     This is another issue that occasionally arises when discussing the
ethical/legal ramifications of computing, not only in academia but in
business as well.  How much "Big Brother" activity will be tolerated.
How do we react to the knowledge that **someone** can review our activity
and decide whether we are productive or not.

In a school setting we worry about the teacher being able to check on our
progress, this could be a useful item and in the right situation could
lead to better work and more interaction on a project.  But used improperly
leads to paranoia and resentment.

Another thought that has been posted is that of how resources are used-
the REXX programming example. Have we become so cost-oriented that, as
a colleague of mine (reading over my shoulder) said, "God forbid that the
student learn more than they should!"  I encourage my first-semester students
to experiment and learn on their own because chances are they can learn
things better that way as well as useful things that I might miss. Somehow
we need to return to the Hacker Ethic as described by S. Levy in _Hackers_,
open systems that encourage learning.

		Tim .D.

-------------------------------------------------------------------------------
Tim .D. Hammer                         BITNET: TDHAMMER@TWSUVAX
Research Assistant                     UUCP: uunet!ncrlnk!ncrwic!wsucsa!hammer
Computer Science Dept.		       INTERNET: tdhammer@oz.wsu.UKans.EDU
Wichita State University               
Wichita, Ks.  67208-1595               TalkNET: (316)689-3156
                                      
#include <std.disclaimer>
#define VIEWS_and_OPINIONS  MY_OWN  /* no one else would admit to them */
-------------------------------------------------------------------------------
"A little learning is a dangerous thing." Alexander Pope

FRISBY-T@osu-20.ircc.ohio-state.edu (Tony Frisby) (02/11/90)

We recently had a LAN installed in my work area which allows this sort of
monitoring.  Not surprisingly it also reports when you log on (supposedly 
the first thing you do) and logoff (the last).  Most of us who are doing
programming log to read any mail or news - and then log out and do the 
work on our own computers.  The LAN is distracting to work with because
ours allows people to interupt what your doing to send an *important* message
to you.  Another reason many of us dont use it as much as it could be.

I guess I'm saying that I'm against this sort of monitoring in the work
place - but I don't find it necessarily an evil for an instructor to do so.
As long as the instructor looks at it as a tutor would - to see if the student
is able to do the assignments - or surpass them - I think it would be a good
thing.  If the instructor is doing to curb natural curiosity with student
experimentation I would be against that.  (insert it after doing)

Tony.

byoder@smcnet.UUCP (Brian Yoder) (02/13/90)

In article <12769@wsucsa.uucp>, hammer@wsucsa.uucp (Tim .D. Hammer) writes:
 
 
> In a school setting we worry about the teacher being able to check on our
> progress, this could be a useful item and in the right situation could
> lead to better work and more interaction on a project.  But used improperly
> leads to paranoia and resentment.

Quite true, particularly considering the existence of electronic mail and
word processing systems in which quite personal information might be
"dribbled" into the teacher's awareness.  Whether non-class work is
allowed or not, doing this in an unannounced way seems like phone taping.
If it is done (which I think is not a particularly good idea unless the 
dribbles are available for review and editing by the student) it should
not be done in secret.
 
> Another thought that has been posted is that of how resources are used-
> the REXX programming example. Have we become so cost-oriented that, as
> a colleague of mine (reading over my shoulder) said, "God forbid that the
> student learn more than they should!"  

When I was in school I had to fight this kind of attitude every day.  The
educational establishment seems full of teachers who are terrified of the
idea that a student might learn more than is on the syllabus (there are 
of course exceptions, but darn few in my experience).  At one time I
was considering spending the time to get a PhD in Computer Science.  Before
making my decision on this, I went on a little tour of the facilities
of the University (Michigan State in case anyone is interested) which I 
found reasonably impressive.  Later, I interviewed several of the 
professors to see if it was worth my time to take classes there.  One of
the questions I asked each of them was "What would I have to do to get
mainframe time to do exploratory programming and learning about how
the computer works, aside from my assigned programs?".  I already knew 
the answer (which was, "There is no way.") but I was interested in hearing
their opinions on the issue.  In each case, they started confused about what
I was asking for, and then became agitated as though I had asked permission
to break all of the windows in the building.  They seemed to not only 
disapprove of individual exploration of this kind, they didn't even
seem to understand it.  As a result, I chose not to enter the program there
(or anywhere else).  I don't know what to do about that attitude, but
it seems quite prevalent.

> I encourage my first-semester students
> to experiment and learn on their own because chances are they can learn
> things better that way as well as useful things that I might miss. Somehow
> we need to return to the Hacker Ethic as described by S. Levy in _Hackers_,
> open systems that encourage learning.

Good for you.  Keep up the good work.


Brian Yoder 
-- 
-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-
| Brian Yoder                 | answers *byoder();                            |
| uunet!ucla-cs!smcnet!byoder | He takes no arguments and returns the answers |
-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-<>-