- 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
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 21:44:01 UTC