weemba@brahms.BERKELEY.EDU (Matthew P. Wiener) (06/13/86)
I've directed followups to net.news only. >> 3) ability to "kill" selected submitors >>for a given newsgroup, throughout the USENET system. [Dan Greening] > >3) Who decides who gets to "kill" the articles? Who would you trust to >censor the net? I can think of no one (reasonable) who would aspire >to such a responsibility. [Gene Spafford] I propose that giving sites KILL files ala rn should be available in the software even if it is not actually used for censorship. Thus, instead of the current talk.* implementation, the part of the backbone that wishes to drop talk.* can instead use KILL files to junk such groups entirely. (Of course, site A sending news to site B first gets B's KILL file, and A junks before transmitting, not B after receiving.) Small pieces of the net would probably be able to censor mach!name, or certain endless debate topics, without really bothering anyone under this scheme. Larger pieces would probably do no more than junk the running puns and possibly the talkgroups. At first. Actually, the existence of an endless debate topic is best solved by form- ing a separate newsgroup. Presumably some appropriate netiquette would evolve (quickly!), involv- ing warnings and probationary periods etc. Just knowing that you are be- ing watched closely would have a salubrious effect on most people. Thus in the most obvious case, backbone site E, upon seeing the pure A***OLE flame come by would send a quick note to said flamer that the second such gets the sender junked netwide at E. Using KILL files would, of course, enable all this to be fine tuned to individuals within selected newsgroups only. One thing missing is the ability to junk responses to fixed individuals. As it is now set up, it is possible to junk responses to machines, by matching on the tail of the References line. Of course, most of these censoring schemes could be gotten past by the determined poster. Eventually USENET will grow too big again, and another cycle of cuts will have to come again, and another round of moaning and groaning will occur. talk.* seems too coarse grained an approach for the future. (Also, how about a temporary group net.news.talk next time around?) If everyone thinks that moderated groups are the ideal solution, except for the delays and mailing problems, perhaps having multiple moderators per group spread across the net, so as to ease the existing defects in the moderated groups should be tried out. Moderators are, after all, just another form of censorship. It's not a question of free speech, but of expensive speech. ucbvax!brahms!weemba Matthew P Wiener/UCB Math Dept/Berkeley CA 94720 They can all go to hell. Of course, some should go before others. One has a responsibility to make discriminations. -Simon Lacerous
stu@jpusa1.UUCP (Stu Heiss) (06/14/86)
Summary: Expires: In article <14347@ucbvax.BERKELEY.EDU> weemba@brahms.UUCP (Matthew P. Wiener) writes: >> I propose that giving sites KILL files ala rn should be available in the >> software even if it is not actually used for censorship. Thus, instead >> (Of course, site A sending news to site B first gets B's KILL file, and >> A junks before transmitting, not B after receiving.) This is the most reasonable scheme I've heard yet. It would really help all the sites as the sa at each site can tune that site's kill file any time. >> Presumably some appropriate netiquette would evolve (quickly!), involv- >> ing warnings and probationary periods etc. >> in the most obvious case, backbone site E, upon seeing fill_in_the_blank >> flame come by would send a quick note to said flamer that the second such >> gets the sender junked netwide at E. Also reasonable. >> Eventually USENET will grow too big again, and another cycle of cuts will True, but it's growth is in proportion to it's value (more information reaching more people) and we need to implement resonable solutions to noise/cost/flame problems. I think the kill file is a very workable idea. Maybe it could get in 2.10.3 yet (hint). -- Stu Heiss {ihnp4!jpusa1!stu}