Article View: alt.internet.media-coverage
Article #205Re: Creating kidspaces on the net (was re: Los Angeles Daily News Article)
From: Mark W Brehob
Date: Wed, 28 Sep 1994 19:34
Date: Wed, 28 Sep 1994 19:34
151 lines
8192 bytes
8192 bytes
Prentiss Riddle (riddle@rice.edu) wrote:
: Pardon the lengthy cascade, but I'm crossposting to a couple of new
: groups here:
: Michael Dillon (mpdillon@halcyon.com) wrote:
: : In article <366sb1$6a9@uuneo.neosoft.com>,
: : Bruce Robertson <broberts@sam.neosoft.com> wrote:
: : > In article <tappd.11.00099EAF@sam.neosoft.com> Dan Tapp,
: : > tappd@sam.neosoft.com writes:
: : > > I mentioned to the folks at Neosoft that they should package a
: : > > "parent-lock" account...just like their standard stuff, but the
: : > > account owner could set the acceptable newsgroups at the server
: : > > with a special password so that the client reader never saw
: : > > them. They expressed some minor interest
: : >
: : > There's no simple way for a service provider to do this. Nor anyone
: : > else, that I can see.
: : >
: : > - Bruce Robertson, Senior Technical Editor
: : > Network Computing Magazine, 713 546-6752
: :
: : I'm surprised that a Senior TECHNICAL Editor at such a magazine
: : can't think of half a dozen ways to do this. Indeed it is
: : technically feasible to make a "safe space" on the Internet
: : for kids and in some ways it is almost a trivial thing to do.
: :
: : As for justification, do we hold school classes on the streets
: : in a red light district or in a bar? No, we create a "safe space"
: : for youngsters and hold classes there, in the school.
: :
: : The moderated newsgroup mechanism combined with controlled
: : feeds (somewhat like clari.*) could be easily adapted
: : to create newsgroups in which only registered people or
: : registered sites could post. This would merely involve
: : a bit of work with shell scripts or PERL scripts.
: :
: : Securing the Web or Gopherspace would be a little more challenging
: : but a start would be a modified Gopher or WWW client that
: : can only access authorised sites or sites registered with
: : a central authority.
: I think that this approach is naive, but not *entirely* unfeasible.
: Some general points:
: (1) There is no way to do this solely at the client side. Existing
: <SNIP>
True, but here is a quick (ok not so quick) and dirty way to do it.
NEWS: A single news sight which only carries a small sub-set of the news-
groups. Now, have some groups of people which lookover the postings
(hold on, don't start screeming yet) These people would do this on
their own time, as they read news (say a hundred+ folks) If they
felt the posting was "bad" they send a message to the news server. If
N people send the message, the posting gets yanked. The "youth" server
would have a delay between when it recieves a message and when it
posts that message. This site would be mirrored. The person running
the site would have to do periodic checks to see what is being canceled
by whom.
Problems:
It puts too much control into a few peoples hands.
It would have to be provided by a com. server.
Some college/company/??? may think that their folks
only need this sub-set.
(2) If the net establishes widely used protocols to allow central
: authorities to control what children can and can't see, then those same
: protocols could be used to control what adults can and can't see. We
: should be aware of this consequence before we adopt such technology.
Yep.
: (3) There are fundamental problems of scale in any such system which
: would necessarily turn a many-to-many interactive medium into a
: few-to-many broadcast medium, thus eroding the principal benefit of
: computer networks. You and I would be unlikely to have this
: conversation under such a scheme.
The above scheme should not have this problem.
: (4) The major attraction of distributed document retrieval systems like
: the World Wide Web and gopher is that they are *distributed*. Many
: individuals and institutions working in parallel come up with a greater
: variety of useful resources than could ever be planned and executed by a
: single, centralized organization. This is fundamentally at odds with
: the concept of a central registry of "approved sites". Furthermore, a
: central approval authority would have to be not merely a registration
: service for sites which educators had deemed harmless, but would have
: to exercise *control* (through a contract or other means) over the
: content at those sites. Otherwise, one would continually find that
: yesterday's kid-safe site had today been blemished by objectionable
: material.
Nope, some groups will be willing to state that they are, and will remain,
"clean". If those groups change there mind, or become un-reliable, they
are pulled from the list. It will be a VERY small sub-set of the list, and
misses the whole beauty of the web. But it might make a parent more likely
to put their child on the net at all...
: (5) One fallacy common to proponents of isolated child-friendly
: networks is that problems only occur when children can communicate
: freely with adults other than their teachers. In fact, children are
: very good at communicating objectionable material to other children.
<clip>
I think I have covered this.
: (6) The existing Usenet moderation mechanism is notoriously easy to
: spoof. Any bright 12-year-old with access to the manuals could figure
Agreed, and should not be an issue above.
: (7) Any system based on adding a backwards-compatible restriction
: mechanism to existing protocols runs the risk of being foiled by users
: surreptitiously gaining access to unrestricted versions of the same
: client software. Thus a kid-safe network would either have to
: guarantee that children couldn't download an unhobbled version of
: Mosaic, say, or it would have to isolate itself further by using
: purposely incompatible protocols.
So things would be something like:
- Have an account on the commersial site "joes-net"
- Have the owner able to password-limit some options on joes-net, now
downloading "unhobbled" software is of no real help.
There are a lot of potential problems with this plan, but a provider like
AOL or netcom may find it profitable.
: For all of these reasons, I have my doubts about the usefulness of
: attempts to build an isolated "kidspace" on the net. If you can't deal
: with the risk that some children at some time will run into some
: objectionable material, keep them off the net and stick to CD-ROMs.
: (Or, the cynical might say: keep them locked in a closet and don't
: teach them to read.)
While not a parent, I would like to have some other option. (I always have
been a fence sitter) I don't think the net is "bad" for anyone over the age
of 12, but ......
: -- Prentiss Riddle ("aprendiz de todo, maestro de nada") riddle@rice.edu
: -- Systems Programmer and RiceInfo Administrator, Rice University
: -- 2002-A Guadalupe St. #285, Austin, TX 78705 / 512-323-0708
: -- Opinions expressed are not necessarily those of my employer.
Mark Brehob
Technical Details
Message-ID:
<36cgga$598@msuinfo.cl.msu.edu>Path:
arc1-ca.pugleaf.net!bga.com!cs.utexas.edu!convex!news.duke.edu!zombie.ncsc.mil!gmi!msuinfo!brehobReferences:
<m0qn9IQ-0005iVC@inviso.com> <366sb1$6a9@uuneo.neosoft.com> <7DrXkapDln3A071yn@halcyon.com> <36c8fr$4cp@larry.rice.edu>Show Full Headers
Complete Article Headers
X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 105b42,a57703c67b7422fb X-Google-Attributes: gid105b42,public X-Google-Thread: 1037c0,9a7388d504f46f67 X-Google-Attributes: gid1037c0,public X-Google-Thread: f9e27,9a7388d504f46f67 X-Google-Attributes: gidf9e27,public X-Google-Thread: 102857,a57703c67b7422fb X-Google-Attributes: gid102857,public X-Google-ArrivalTime: 1994-09-28 12:41:50 PST Path: arc1-ca.pugleaf.net!bga.com!cs.utexas.edu!convex!news.duke.edu!zombie.ncsc.mil!gmi!msuinfo!brehob From: brehob@cps.msu.edu (Mark W Brehob) Newsgroups: alt.internet.media-coverage,houston.efh.talk,comp.infosystems,misc.education Subject: Re: Creating kidspaces on the net (was re: Los Angeles Daily News Article) Date: 28 Sep 1994 19:34:34 GMT Organization: Michigan State University Lines: 152 Distribution: world Message-ID: <36cgga$598@msuinfo.cl.msu.edu> References: <m0qn9IQ-0005iVC@inviso.com> <366sb1$6a9@uuneo.neosoft.com> <7DrXkapDln3A071yn@halcyon.com> <36c8fr$4cp@larry.rice.edu> NNTP-Posting-Host: lobster.cps.msu.edu X-Newsreader: TIN [version 1.2 PL0]