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

RE: Intelligent Rating Systems

From: Michael Dillon <michael@junction.net>
Date: Mon, 26 Jun 1995 18:44:49 -0700 (PDT)
To: bede@scotty.mitre.org
Cc: www-talk@www10.w3.org, immedia@netwest.com, nazgul@utopia.com, peterd@bunyip.com, marc@matahari.ckm.ucsf.edu, rating@junction.net, uri@bunyip.com
Message-Id: <Pine.LNX.3.91.950626183249.9236F-100000@okjunc.junction.net>
On Mon, 26 Jun 1995 bede@scotty.mitre.org wrote:

>    Date: Sat, 24 Jun 1995 22:01:13 -0700 (PDT)
>    From: Michael Dillon <michael@junction.net>
>    [ . . . ]
>    This is precisely why I am proposing that ratings be served up by a third 
>    party, i.e. not the WWW author nor the WWW server operator. Any third 
>    party who wishes can set up a ratings server and serve up ratings. In 
>    [ . . . ]
> I might be reading it all wrong, but this looks like a scheme which
> would entail an awful lot of overhead.  Are you suggesting a scheme
> where a client would be required to do two retrievals for every
> document or object retrieved (one to an independent rating server and
> a second one for the document)?

Yes, however the request to the rating server would be small. It would 
merely be the encrypted URL and a client ID code. The ratings server 
would decrypt the URL using the secret key for that particular client, 
then reencrypt the URL and the rating for transmission back to the 
client. Then the client decrypts the packet, makes sure the URL matches 
and then applies the rating to decide whether or not to retrieve the URL. 
I don't believe this protocol would impose any more strain on the 
Internet than DNS.

>  This also suggests that, as is the
> case with commerce protocols like iKP and its ilk, we'd need a new and
> distinct "content-rating" protocol.

I would rather refer to it as a ratings server transaction protocol. The 
actual rating codes returned are a separate matter and should be easily 
extended by any rating server which needs a more complex set of ratings. 

> I'll stick by the notion that rating information should come back to
> the client from the server encoded in an HTTP header line.  The server's
> rating could optionally be verified at its source, assuming it
> contains enough information to identify the source.  This preserves
> the option of checking a URL or URI with a third-party rating service
> *before* retrieving the corresponding document from a server, but if
> you're willing to trust a server's rating estimates the extra step
> isn't necessary.

I don't think you can trust a WWW server's rating at all. There are 
people who will quickly abuse such a system so it is best not even 
attempted. We do have models for secure protocols such as RADIUS, SSL, 
SHTTP and others; let's use them. 

> This leaves the initial responsibility for deriving and/or verifying a
> rating vector with the server operator, and the server operator may
> want to tailor rating vectors to target destinations.  Maybe this
> tailored rating could just be another field in the encoding.

No. Ratings have nothing to do with the server operator nor with the 
document author. Ratings are a client-side thing. The ratings server is a 
3rd party who acts as an agent of the client to preview and rate URL's. 
Server operators and authors have no say in this scheme. No server 
modifications are needed. No modifications to HTML documents are needed.
I also frees the server operators and the authors from responsibility as 
well which is good IMHO.

Michael Dillon                                    Voice: +1-604-546-8022
Memra Software Inc.                                 Fax: +1-604-542-4130
http://www.memra.com                             E-mail: michael@memra.com
Received on Monday, 26 June 1995 22:37:53 UTC

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