🚀 go-pugleaf

morgan@ms.uky.edu (Wes Morgan) writes:
}I have been working on a "Student Access and Use Policy".  I've finally
}managed to wrangle it into a manageable form.  I'd like to hear any com-
}ments you may have.

Well, here are my comments.  Well, actually my complaints.  If I
left it out, I didn't have any questions about it.

John
My background (bias?) is:
     ISU Comp Ctr Systems Software Engineer
     Member of ISU Computor Advisory [to the Provost] Committee
     Part-time graduate student
}==============================================================================
}DRAFT
}
}                Student Computing Access and Use Policy

}                                          ... No disciplinary action will be
}taken against students by the Engineering Computing Center; if such action
}is contemplated, the matter will be remanded to the appropriate office.
             [this appears to not be true, see below]

}1.1   Use of restricted ECC facilities by those students outside the College
}      of Engineering is prohibited.  [Paragraph 1.21u, CSC] 

What about students not in the Engineering College but who are taking
an Engineering Course?  Where do they fall?

}1.2   Sharing your userid with any other person is prohibited.  [Paragraph
}      1.21u, CSC]
}
}1.3   Using a userid which belongs to another user is prohibited, even if you
}      have been issued a userid of your own.  [Paragraph 1.21u, CSC]

We also have a rule of one userid per person -- it sounds like this is your
situation, maybe that is worth saying explicitly.

}The ECC Staff may, at a later date, establish specific policies to address
}short-term problems or situations.  You are obligated to follow those short-
}term directives and/or policies, just as you are obligated to follow this
}policy.  You may also receive specific personal instructions from ECC Staff;
}those instructions must be followed as well.  Therefore:

Some assurance that these policies and/or instructions will also be in
accordance with, and not superior to, University policy?

}You are allocated a certain amount of disk space on ECC system for storage
}of your files and data.  Each user has their own disk space; you have no need
}to examine the disk space of other users.  The ECC Staff does not, and will
}not, examine student files or data, except during normal computing
}operations (e.g., making system backup tapes).  Therefore:

An assurance that files/data `accidentally' seen will be not be divulged?

}2.2   Attempts to evade or change resource quotas are prohibited.
}      [Paragraphs 1.21a, 1.21h, and 1.21u, CSC]

I assume you *are* allowed to change a quota by requesting a change from ECC?

}While we do not place arbitrary limits on your use of ECC systems, it is quite
}possible for you to consume a significant portion of the systems' resources. 
}As a result, you may impede the work of other users.  If this should occur,
}you will be notified by ECC staff.  Therefore:
}
}2.3   Continued impedance of other users through mass consumption of
}      system resources, after receipt of a request to cease such activity, is
}      prohibited.  [Paragraph 1.21a, CSC]

How does someone who feels his consumption of resourses is warranted
(necessary to their academic success) seek appeal?

}Your access to ECC systems is based on your academic needs.  We cannot,
}and will not, support "for-profit" operations.  Therefore:
}
}2.4   Use of ECC facilities and/or services for commercial purposes is
}      prohibited.  [Paragraphs 1.21g and 1.21u, CSC]

Definition of `for-profit'?  Is, for example, using misc.forsale allowed
or not allowed.

}ECC resources are dedicated to academic work.  At this time, we cannot
}support game or recreational programs.  Therefore:
}
}2.5   The installation/execution of games and/or recreational programs on 
}      ECC systems is prohibited. [Paragraph 1.21u, CSC]

Definition of recreational?  News?  Only certain newsgroups?  E-mail?
Talk?  IRC?  Playing MUD?  Writing MUD?  Writing a program not required
in any class?  Fortune?  FTP?  Archie?  ...

}Section 3: Electronic Mail Policy
     :
}3.4   All mailing lists with more than 10 members must be registered with
}      the ECC staff. [Paragraph 1.21u, CSC]

I'm sorry, this seems absolutely absurd.

}It is important to note that the ECC staff will make arrangements for large
}mailing lists; however, we will not support mailing lists whose subjects
}violate University policy, State law, or Federal law.  (In any situation where
}this is a possibility, the University Counsel will be asked for a decision.)

How could the existence of a mailing list could be illegal?

}Section 4: Network Use Policy
    :
}There are a limited number of network ports available to certain systems. 
}It is possible to connect to other systems via ECC systems.  This misuse of
}ECC systems may result in depriving other users of access to our systems. 
}We cannot support use of computers outside of the ECC.  Therefore:
}
}4.2   Use of ECC systems and/or networks to connect to other systems, in
}      evasion of the physical limitations of the remote system/network, is
}      prohibited. [Paragraph 1.21a and 1.21u, CSC]

I don't understand this.  For example, we have a system with 1 serial
connection.  Is telneting to that system an "evasion of the physical
limitations"???  Why is that banned???


}Section 6: Incident Handling
     :
}In the event that you, knowingly or unknowingly, violate ECC or University
}policy, you will be contacted by the ECC Staff.  This contact will usually take
}the form of an electronic mail message.  It is your responsibility to follow
}any instructions you may receive from ECC Staff, and to confirm your
}receipt of those instructions.  If you believe that the instructions given to
}you are unreasonable, you should immediately contact the Director of
}Engineering Computing or the Assistant Dean of the College of Engineering. 
}If you do not register your complaint with either the Director of Engineering
}Computing or the Assistant Dean, it is expected that you will follow the
}instructions given to you.  Therefore:
}
}6.1   Disregarding instructions of ECC Staff may result in the temporary
}      revocation of your computing access.

How do you know if they have even received your instructions (e-mail?).
If, for example, I was not on the system for a week or so, tried to use
the system some Saturday to complete a project due Monday morning and
found I my access revoked because I had not followed instructions (that
I never received) and my academic success was jepordized I would be furious.

Also, in my mind this is punishment -- something you stated at the top
would not happen.

}If your access is temporarily revoked, you should immediately contact the
}ECC Staff for an explanation of the situation.  In most cases, the revocation
}will be lifted within 1 working day.  Quite often, temporary revocation is the
}result of a minor, or apparently unintentional, violation of ECC or University
}policy; such revocations will be lifted as soon as the ECC Staff discusses the
}relevant policies with you.

See above--this is unacceptable.

}The ECC will abide by the decision of the Dean of Students.  If the Dean of
}Students chooses not to bring disciplinary action against you, or if the
}judicial proceedings are resolved in your favor, your complete access to ECC
}facilities will be immediately restored.

Access is restricted BEFORE the guilt of the student is determined?!?

john@iastate.edu (John Hascall) writes:
>morgan@ms.uky.edu (Wes Morgan) writes:
>}I have been working on a "Student Access and Use Policy".  I've finally
>}managed to wrangle it into a manageable form.  I'd like to hear any com-
>}ments you may have.
>
>}                                          ... No disciplinary action will be
>}taken against students by the Engineering Computing Center; if such action
>}is contemplated, the matter will be remanded to the appropriate office.
>             [this appears to not be true, see below]

Hmmmm....I'll change "disciplinary action" to "PERMANENT disciplinary action".

>}1.1   Use of restricted ECC facilities by those students outside the College
>}      of Engineering is prohibited.  [Paragraph 1.21u, CSC] 
>
>What about students not in the Engineering College but who are taking
>an Engineering Course?  Where do they fall?

We usually handle this through the instructor; they give me a class roll, and
I crank up the guest accounts.  I'll formalize a procedure and put it in the
next draft.

>}1.2   Sharing your userid with any other person is prohibited.  [Paragraph
>}      1.21u, CSC]
>}
>}1.3   Using a userid which belongs to another user is prohibited, even if you
>}      have been issued a userid of your own.  [Paragraph 1.21u, CSC]
>
>We also have a rule of one userid per person -- it sounds like this is your
>situation, maybe that is worth saying explicitly.

That is mentioned explicitly in the "rationale" section preceding these two
points.  Are these two rules *that* unclear?  How should I rephrase them?

>Some assurance that these policies and/or instructions will also be in
>accordance with, and not superior to, University policy?
>
>An assurance that files/data `accidentally' seen will be not be divulged?

You got it; suitable assurances will be in the next draft.

>}2.2   Attempts to evade or change resource quotas are prohibited.
>}      [Paragraphs 1.21a, 1.21h, and 1.21u, CSC]
>
>I assume you *are* allowed to change a quota by requesting a change from ECC?

Yup; I'll put a formal procedure in the next draft.

>}2.3   Continued impedance of other users through mass consumption of
>}      system resources, after receipt of a request to cease such activity, is
>}      prohibited.  [Paragraph 1.21a, CSC]
>
>How does someone who feels his consumption of resourses is warranted
>(necessary to their academic success) seek appeal?

Hmmmm......I guess I'll put a "Complaint/Appeal Policy" in the next draft.

>}2.4   Use of ECC facilities and/or services for commercial purposes is
>}      prohibited.  [Paragraphs 1.21g and 1.21u, CSC]
>
>Definition of `for-profit'?  Is, for example, using misc.forsale allowed
>or not allowed.

How about something like this?

	"Use of ECC facilities and/or services for explicitly commercial
	 purposes is prohibited.  ECC facilities and/or services may be 
	 used for personal business, such as the sale of personal property; 
	 such use must be within the other provisions of this policy.  ECC
	 facilities may not be used on behalf of outside agencies."

That would allow Joe Shmo to advertise his old Macintosh for sale, but not
(in my mind) announce the current sales at his company, Bluegrass Computing.
	 
>}ECC resources are dedicated to academic work.  At this time, we cannot
>}support game or recreational programs.  Therefore:
>}
>}2.5   The installation/execution of games and/or recreational programs on 
>}      ECC systems is prohibited. [Paragraph 1.21u, CSC]
>
>Definition of recreational?  News?  Only certain newsgroups?  E-mail?
>Talk?  IRC?  Playing MUD?  Writing MUD?  Writing a program not required
>in any class?  Fortune?  FTP?  Archie?  ...

True; I think the reference to "recreational" will be removed.  The
provision prohibiting "network-based applications" will eliminate
MUD/IRC/Netrek/etc. programs, so this provision can be safely rewritten.

>}Section 3: Electronic Mail Policy
>}3.4   All mailing lists with more than 10 members must be registered with
>}      the ECC staff. [Paragraph 1.21u, CSC]
>
>I'm sorry, this seems absolutely absurd.

My rationale behind this provision comes from several experiences:

	1) I have had problems with users creating *massive* mailing
	   lists (over 200 members) with the 'alias' function of mailx.
	   One of these lists started shipping uuencoded images around.
	   Chaos ensued.
	   
	2) Users have also created mailing lists of people they don't
	   even know, in the hopes of meeting them. 

	3) Several students have left this organization without informing
	   their list members; as a result, I've been getting dozens of
	   messages from users/postmasters complaining about "user unknown"
	   email bounces.

	4) Two users tried to import the entire UK "email phone book" into
	   a mailing list.  There are over 6000 addresses in the "phone book";
	   with the transcription errors that were made, it took me over two
	   weeks to fix the errors, track it down and kill it.

>}It is important to note that the ECC staff will make arrangements for large
>}mailing lists; however, we will not support mailing lists whose subjects
>}violate University policy, State law, or Federal law.  (In any situation where
>}this is a possibility, the University Counsel will be asked for a decision.)
>
>How could the existence of a mailing list could be illegal?

I know that this particular example has been bounced around for years, but
what about a "child porn image list"?  What about a list that passes out
credit card numbers?

>}There are a limited number of network ports available to certain systems. 
>}It is possible to connect to other systems via ECC systems.  This misuse of
>}ECC systems may result in depriving other users of access to our systems. 
>}We cannot support use of computers outside of the ECC.  Therefore:
>}
>}4.2   Use of ECC systems and/or networks to connect to other systems, in
>}      evasion of the physical limitations of the remote system/network, is
>}      prohibited. [Paragraph 1.21a and 1.21u, CSC]
>
>I don't understand this.  For example, we have a system with 1 serial
>connection.  Is telneting to that system an "evasion of the physical
>limitations"???  Why is that banned???

UK uses an Ungerman-Bass network, in which each host has a finite number
of ports.  When a "popular" system A's ports are all in use, users will 
grab a port to another machine B, log in, and telnet to the system they
*really* want to use (system A).  This action, in turn, limits the num-
ber of ports to system B that are available for real work.  

Very few systems on this campus use hard-wired terminals; the vast majority
(over 90%,  in my estimation) of the connections are made through UBNet.  The
folks who don't want to wait for access to system A are tying up all the ports
on system B.  Right now (and for the past year or so), my systems are acting 
as system B; my legitimate users are tired of it, and so am I.

>How do you know if they have even received your instructions (e-mail?).

Well, a quick check of the sendmail logs will indicate success/failure of
delivery.  As far as I'm concerned, the fact that they didn't check their
email doesn't absolve them of responsibility.  In the "real world", the
Circuit Court doesn't care if you "didn't receive" their summons; they'll
haul you in anyway.  What's the difference?

>If, for example, I was not on the system for a week or so, tried to use
>the system some Saturday to complete a project due Monday morning and
>found I my access revoked because I had not followed instructions (that
>I never received) and my academic success was jepordized I would be furious.

Your access wouldn't be revoked unless the action(s) continued.  I thought
I made that clear.  I thought that "Disregarding instructions" implied that
the violations were continuing; I'll reword it in the next draft.

Here's the scenario I envisioned (and the one that has occured several times):

	1) User actions cause problems.
	2) ECC sends email message to user.
	3) Action continues.    
	4) Temporary revocation.

>}If your access is temporarily revoked, you should immediately contact the
>}ECC Staff for an explanation of the situation.  In most cases, the revocation
>}will be lifted within 1 working day.  Quite often, temporary revocation is the
>}result of a minor, or apparently unintentional, violation of ECC or University
>}policy; such revocations will be lifted as soon as the ECC Staff discusses the
>}relevant policies with you.
>
>See above--this is unacceptable.

What's the alternative?  I had a user who consistently crashed the system
with a shell script that hosed out the ethernet card.  I sent THREE email
messages; he kept running the script.  I tried to telephone him, but his num-
ber wasn't listed.  What the heck am I supposed to do?

>}The ECC will abide by the decision of the Dean of Students.  If the Dean of
>}Students chooses not to bring disciplinary action against you, or if the
>}judicial proceedings are resolved in your favor, your complete access to ECC
>}facilities will be immediately restored.
>
>Access is restricted BEFORE the guilt of the student is determined?!?

Yup, it sure is.  If I have evidence that a user is using one of the
systems for cracking attempts on other systems, you'd better believe that
I'm going to throw him into a "no network access" restricted shell until
we know more.  (I should point out that NONE of the classes in Engineering
require network access; therefore, this action will not restrict his class-
work) 

If I have evidence that a user is using other user directories as storage
(in violation of resource quotas), you'd better believe that he's going to
find himself in a restricted shell when next he logs in.

-- 
 morgan@ms.uky.edu    |Wes Morgan, not speaking for|     ....!ukma!ukecc!morgan
 morgan@engr.uky.edu  |the University of Kentucky's|   morgan%engr.uky.edu@UKCC
 morgan@ie.pa.uky.edu |Engineering Computing Center| morgan@wuarchive.wustl.edu
        "I was going to rip your head off, but I'm past that now."

When last we left our intrepid explorers...
morgan@ms.uky.edu (Wes Morgan) writes:
}john@iastate.edu (John Hascall) writes:
}>morgan@ms.uky.edu (Wes Morgan) writes:
}>}I have been working on a "Student Access and Use Policy".  I've finally
}>}managed to wrangle it into a manageable form.  I'd like to hear any com-
}>}ments you may have.

}>}1.2   Sharing your userid with any other person is prohibited.  [Paragraph
}>}      1.21u, CSC]
}>}
}>}1.3   Using a userid which belongs to another user is prohibited, even if you
}>}      have been issued a userid of your own.  [Paragraph 1.21u, CSC]
}>We also have a rule of one userid per person -- it sounds like this is your
}>situation, maybe that is worth saying explicitly.
}That is mentioned explicitly in the "rationale" section preceding these two
}points.  Are these two rules *that* unclear?  How should I rephrase them?

Well, here at least, we have a number of people who keep asking for another
userid for some purpose -- we don't do this.  This is what I was wondering
about.

}How about something like this?
}
}	"Use of ECC facilities and/or services for explicitly commercial
}	 purposes is prohibited.  ECC facilities and/or services may be 
}	 used for personal business, such as the sale of personal property; 
}	 such use must be within the other provisions of this policy.  ECC
}	 facilities may not be used on behalf of outside agencies."
}
}That would allow Joe Shmo to advertise his old Macintosh for sale, but not
}(in my mind) announce the current sales at his company, Bluegrass Computing.

Looks good to me.

}>}Section 3: Electronic Mail Policy
}>}3.4   All mailing lists with more than 10 members must be registered with
}>}      the ECC staff. [Paragraph 1.21u, CSC]
}>I'm sorry, this seems absolutely absurd.
}My rationale behind this provision comes from several experiences:
}
}	1) I have had problems with users creating *massive* mailing
}	   lists (over 200 members) with the 'alias' function of mailx.
}	   One of these lists started shipping uuencoded images around.
}	   Chaos ensued.

	I can certainly understand this one.  Maybe its just "10" I
	didn't like.  We have mail-lists for each course (for example:
	math_123@iastate.edu).  Now we create these ourselves, but if
	we didn't I sure wouldn't want to hear about all of them!

}	3) Several students have left this organization without informing
}	   their list members; as a result, I've been getting dozens of
}	   messages from users/postmasters complaining about "user unknown"
}	   email bounces.

	You'll never shake this one....    :-(

}>}It is important to note that the ECC staff will make arrangements for large
}>}mailing lists; however, we will not support mailing lists whose subjects
}>}violate University policy, State law, or Federal law.
}>How could the existence of a mailing list could be illegal?
}I know that this particular example has been bounced around for years, but
}what about a "child porn image list"?  What about a list that passes out
}credit card numbers?

Well, it seems it is the use which is illegal, not the list.  Surely if
I was to ask you (as my SysAdmin) to setup such a list I wouldn't ask to
call it something like ``WeFondleLittleBoys@ms.uky.edu'', but rather
something ordinary sounding like ``wflb@ms.uky.edu''.  But then again,
maybe these people are really stupid...

}UK uses an Ungerman-Bass network, in which each host has a finite number
}of ports.  When a "popular" system A's ports are all in use, users will 
}grab a port to another machine B, log in, and telnet to the system they
}*really* want to use (system A).  This action, in turn, limits the num-
}ber of ports to system B that are available for real work.  
}Very few systems on this campus use hard-wired terminals; the vast majority
}(over 90%,  in my estimation) of the connections are made through UBNet.  The
}folks who don't want to wait for access to system A are tying up all the ports
}on system B.  Right now (and for the past year or so), my systems are acting 
}as system B; my legitimate users are tired of it, and so am I.

Ah!  I can see we are very fortunate not to have such a thing.  Our serial
network is an AT&T ISN (and much as I hate to praise them, it is nice).  In
any event, serial is fading pretty fast here.  Looks like you don't have
much choice but to have that rule.

}>How do you know if they have even received your instructions (e-mail?).

}As far as I'm concerned, the fact that they didn't check their
}email doesn't absolve them of responsibility.  ...
}Your access wouldn't be revoked unless the action(s) continued.  I thought
}I made that clear.  I thought that "Disregarding instructions" implied that
}the violations were continuing; I'll reword it in the next draft.
}Here's the scenario I envisioned (and the one that has occured several times):
}	1) User actions cause problems.
}	2) ECC sends email message to user.
}	3) Action continues.    
}	4) Temporary revocation.

I was thinking of things which can continue `passively'.  Like you created
an 11-person mailing list, or whatever.

}>}If your access is temporarily revoked, you should immediately contact the
}>}ECC Staff for an explanation of the situation.  In most cases, the revocation
}>}will be lifted within 1 working day.  Quite often, temporary revocation is the
}>}result of a minor, or apparently unintentional, violation of ECC or University
}>}policy; such revocations will be lifted as soon as the ECC Staff discusses the
}>}relevant policies with you.

}>See above--this is unacceptable.

[examples omitted]

I still have a real problem with possibly interferring with a student's
academic success for `minor, or apparently unintentional, violation[s]'.
Certainly if they are a real threat to the system or other users, then
immediate action is called for.

}>}The ECC will abide by the decision of the Dean of Students.  If the Dean of
}>}Students chooses not to bring disciplinary action against you, or if the
}>}judicial proceedings are resolved in your favor, your complete access to ECC
}>}facilities will be immediately restored.

}>Access is restricted BEFORE the guilt of the student is determined?!?

Same comment as above.

----
Overall, I think you have made a really fine effort; I just like
to play the devil's advocate.  ;-)

Cheers,
John

There is lots of good stuff in the policy. I especially like the
references to general university policy and the tie in regular
university disciplinary channels.

The whole temporary/permanent access restriction/reduction is very,
very complex and confusing. Here is a summary:

A.
Being suspected of violating a rule and
  Not getting the ECC's email or
  Not getting the ECC's email or
  Not following the instructions of the ECC's email
	-> temporary revocation

B.
Being suspected of violating a rule and
In the opinion of the ECC staff immediate revocation is necessary
        -> temporary revocation

C.
Being suspected of a significatant violation of a rule and
The Dean of Students decides judicial proceedings are necessary
        -> restricted access for the duration of the proceedings
           The amount of restriction depends on the nature of the charges.

It is open for abuse by the ECC staff. (I don't think that Wes Morgan
would abuse "his own" policy, but others could). I think the procedure
could be improved by mentioning in parts B and C that supensions and
restrictions before a finding will only be imposed "for reasons
relating to his physical or emotional safety and well being, or for
reasons relating to the safety and well-being of students, faculty, or
university property." [student.freedoms] This could be reenforced
having the head of ECC OK such actions. (Similar to the OK required in
the U. of Delaware policy).

Part C is especially unclear about how the restiction "depends" on the
nature of the charges. A staff member could read it and this that he
or she is suppose to punish users before it has been determined that
they have volated policy.

Which gives me a chance to use a quote that I've been saving for
weeks:

   "No, no," said the Queen: "The sentence first -- the verdict
    afterwards." -- Lewis Carroll, _Alice in Wonderland_.

Finally, here are some notes on the wording of this section.

=========================
In the event that you, knowingly or unknowingly, violate ECC or University
                                                 ^^^^^^^
policy, you will be contacted by the ECC Staff.
--
This probably also applies if they merely appear to violate policy.
The staff shouldn't assume that a violation has occured until
after at speaking with the user.
================
"In the event that you, knowingly or unknowingly, violate ECC or
University policy, you will be contacted by the ECC Staff."
                   ^[replace with:]The ECC will try to contact you

=======================
"If you do not register your complaint with either the Director of
                             ^^^^^^^^^
Engineering Computing or the Assistant Dean, it is expected that you
will follow the instructions given to you."
--
Contesting an accusation is not a "complaint".

==============

6.2   Temporary revocations of computing access will be dissolved within
      one working day of the resolution of the violation.
                                               ^^^^^^^^^^
--
There may not be a violation; it may only appear that way.


- Carl
-- 
Carl Kadie -- I do not represent EFF; this is just me.
 =kadie@eff.org, kadie@cs.uiuc.edu, or (anonymous) ap.3619@layout.berkeley.edu=

Wes Morgan writes:

>>}Section 3: Electronic Mail Policy
>>}3.4   All mailing lists with more than 10 members must be registered with
>>}      the ECC staff. [Paragraph 1.21u, CSC]
[...]

>My rationale behind this provision comes from several experiences:

>	1) I have had problems with users creating *massive* mailing
>	   lists (over 200 members) with the 'alias' function of mailx.
>	   One of these lists started shipping uuencoded images around.
>	   Chaos ensued.

I think it would be better to prohibit this mailing list on the
grounds of "substantial disruption", than not preapproved.

>	2) Users have also created mailing lists of people they don't
>	   even know, in the hopes of meeting them. 

I don't think this is limited to lists of over size 10. Also, I don't
see how preapproval will help, unless you are going to double check
all the entries in the list.

If a person complains about unwanted email, you should tell the sender
to stop sending email to that person.

>	3) Several students have left this organization without informing
>	   their list members; as a result, I've been getting dozens of
>	   messages from users/postmasters complaining about "user unknown"
>	   email bounces.

This must happen with regular email, too. Also, from what I know about
list members, many will ignore notification anyway. How about just
suggesting that departing students send a "change of address" message
to their frequent email correspondents.

>	4) Two users tried to import the entire UK "email phone book" into
>	   a mailing list.  There are over 6000 addresses in the "phone book";
>	   with the transcription errors that were made, it took me over two
>	   weeks to fix the errors, track it down and kill it.

Again, get them for "substantial disruption"

>>}It is important to note that the ECC staff will make arrangements for large
>>}mailing lists; however, we will not support mailing lists whose subjects
>>}violate University policy, State law, or Federal law.  (In any situation where
>>}this is a possibility, the University Counsel will be asked for a decision.)

>I know that this particular example has been bounced around for years, but
>what about a "child porn image list"?  What about a list that passes out
>credit card numbers?

These lists are already prohibited because they are illegal. Do you
really want to take even partial responsibility for the lists that you
do approve of? What if you give it an official University OK, and
*then* it starts being used for credit cards?

I'm enclosing a reference.

- Carl

The book _Law of the Student Press_ by the Student Press Law Center
(1985,1988), p. 37:

"Only two court cases have considered the liability question, and in
both cases the courts found that the institution was free from
liability because control was in the hands of the students."{33,34}

...

"Thus, despite arguments by administrators that they need to prevent
libel, it appears that just the opposite is true: Where administrators
have not exercised control over the content of student publications,
the courts have refused to hold their schools responsible for libel
appearing in such publication. If, however, administrators exercise
the power of prior review, then the court will also hold them and
their schools liable for the contents of such publications.
Encouraging the establishment of a clear-cut separation between school
administration and editor functions may also result in the reduction
of libel suits, for potential plaintiffs will realize that substantial
funds are beyond their reach.

{33} _Mazart v. State_ 441 N.Y.S.2d 600 (1981)

{34} _Milliner v. Turner_ 436 So.2d 1300 (La. App. 1983)

- Carl
-- 
Carl Kadie -- I do not represent EFF; this is just me.
 =kadie@eff.org, kadie@cs.uiuc.edu, or (anonymous) ap.3619@layout.berkeley.edu=