W3C home > Mailing lists > Public > www-talk@w3.org > May to June 1995

RE: Agent-mediated access, kidcode critiques, and community standards

From: <bede@scotty.mitre.org>
Date: Wed, 21 Jun 1995 22:04:47 -0400
Message-Id: <199506220204.WAA05454@scotty.mitre.org>
To: peterd@bunyip.com
Cc: www-talk@www10.w3.org
   From: Peter Deutsch <peterd@bunyip.com>
   Date: Wed, 21 Jun 1995 12:29:00 -0400

   [ . . . ]

   I'm absolutely convinced that commercial quality
   information is coming, but I seriously doubt that it will
   _replace_ that which is on the net today. Rather, we can
   expect it to complement the many free offerings. After
   all, nobody is paying for most of what is out there right
   now yet many, many people continue to put up their
   offerings and they do so for a variety of non-monetary
   rewards. This is a fundamental part of the attraction of
   the net and I expect it will continue to be so. On the
   net, everyone's a publisher...

I certainly don't claim commercialized information resources will
completely replace free resources, Peter!  On the other hand, I think
many of the free resources we have now will charge for access, if only
for the sake of cost recovery -- once the means to do this become
available.  So, for example, some government and university archives
will undoubtedly charge "fair and reasonable" fees for delivering
electronic documents.

I'm still perfectly free to publish my autobiography, digitized
Polaroid snaps from my vacation in Montreal, and an audio chat link to
my cat, Teenie --- all at no charge.

Your point about the mass of free information being a major attraction
is very well taken, though.  The exponential growth of uncensored free
information exchanged over the global Internet in the last few years
is also a spectacular justification of the roughly 20 years of R&D
represented in our current IP-based packet-switched Internet.  For the
sake of our kids, at least, we need to do everything we can to ensure
this trend can't be choked off by censors or rampant commercialization.

But we're getting way off-topic...

   [ . . . ]

   The problem with this approach, as you point out, is that
   it provides nothing more than hints and thus wont work in
   all cases (after all, there are people that can't/wont rate
   their offerings for whatever reason). Because censors will
   still have to do other forms of client side filtering
   anyways, and because these hints don't provide any benefit
   to the rater,

Ah, but there *is* a benefit to the rater, and I'll get back to this
in just a sec...

                 I don't see this proposal serving any real
   purpose except to show people who are hot under the
   collar right now that we're doing "something". 

I don't think this "something" necessarily has to be done just for
enabling potential censorship, but it seems fairly clear that unless
there is something visibly available in the spec (not necessarily
perfect in itself or universally applicable) to support content
ratings, there could be legislative action requiring us to slap
content ratings on every shred of accessible information on the net.
What a nightmare (also Lawyer Heaven).

I suggested that *embedded* labeling could amount to nothing more than
a hint, because in the present scheme of things the geographic
location of a document is a required part of the context needed to
determine its "rating" (if any).  The only realistic way to handle a
content "rating" in a document server is at the protocol or
transaction level.  Given some rules about various destinations, you
can probably come up with an acceptably reliable document rating for
each destination.

What the client or end user does with a content rating in hand is not
of any concern to the document server (it's not knowable, in any
case).  Obviously, if your market is elementary schools, you might
want to pay much closer attention to content ratings than if you're
aiming for college campuses.  Note that in this scheme all the
automated censorship is happening on the client side.  Servers could
do censorship, of course, but I think such a scheme depends wholly on
the availability of reliable authentication, and discussing that would
lead into stuff like FORTEZZA-like smart cards, certificates, crypto
keys, and such.

   It might be nice to have the hint, but I don't see it as
   becoming widely used. After all, what is my incentive to
   me to provide these hints? I'm based in Canada, and unless
   the U.S. plans an invasion some time soon (something we of
   course can't rule out... ;-) I'm outside your jurisdiction
   right now...

Different countries have different standards, of course.  Having
a spec for a content rating line in the spec for HTTP headers doesn't
mean everyone uses it the same way, if at all.  That's one reason I
suggested placing rating information in the protocol, not the document
itself.  The sort of thing you *might* consider putting in a document
might be some relevant "objective" features about the document known to
be of importance to various ratings schemes.  Who knows what bizarre
features these could be...

Now, about those benefits to the rater:  one can quite easily imagine
import restrictions on digital goods requiring labeling.  For example,
merely possessing child pornography is illegal in the U.S. so news
that such material is entering the country via the Internet could
quickly lead to import labeling restrictions, complete with fines or
jail for the hapless recipient of unlabeled or "improperly" labeled
imported bits.  Local laws always have a form of jurisdiction in
foreign countries in that if you, over "there", want to market your
stuff "here", then your goods can be required to comply with
completely arbitrary local restrictions on imports to "here".  Note
that the folks who actually enforce these restrictions on you are your
potential customers over "here", not the cops.  The obvious benefit to
the rater is a market.

- Bede McCall   <bede@mitre.org>

  The MITRE Corporation            Tel: (617) 271-2839
  Bedford, Massachusetts           FAX: (617) 271-2423
Received on Wednesday, 21 June 1995 22:04:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:57 UTC