However: we still need a model for editing entries that arrive at the
server. Or some other policy mechanism to keep the data clean and valid.
I don't think we've seen anything like that proposed so far.
[copying the cdin nospam at cdin.org mailing list to archive this information for
future readers; leaving the rest of this post un-snipped for that
benefit, too]
Cheers,
-g
Jason Dufair wrote:
>
> Let me preface this by saying that I like PGP, I use PGP, I've done PGP
> development, and think it serves a great purpose. A model of simplicity,
> it is not. People want to pop a CD in and see the track titles pop up.
> They'll add them if it's not there. I think building a whole web of trust
> is not necessary for this model. I'm quite sure people won't generate
> public keys to use their CD player app. I continue to suggest a simple
> majority on an ASCII match with precedent to the initial entry lacking a
> clear majority.
>
> At 08:24 PM 3/9/99 GMT, you wrote:
> >On Tue, 09 Mar 1999 19:36:24 +0000 Ian Clarke <I.Clarke nospam at ed.ac.uk> wrote:
> >> In the initial discussions I suggested that the first person to submit a
> >> CD entry has their email address stored. If someone else attempts to
> >> change this entry then the first person gets sent an email and is
> >> invited to reject the new entry if it is not serious. A person can also
> >> elect to resign as the "guardian" of particular database entries.
> >This is open to abuse too---what if the first person is up to no good?
> >And I'm not sure I would want my email address publicised in quite
> >this way. Remember that the data in the servers must be public, so you
> >couldn't keep the addresses secret. Spammers' heaven!
> >
> >But having the ability to trace entries is useful. With something like
> >a public key signature, well-respected contributors could unforgably
> >sign their entries. Clients could then give preference to those entries
> >whose contributors they have been instructed to trust over ``competing''
> >entries. The assignment of trust has to be up to the individual user,
> >but the process can be almost transparent: whenever you download an
> >entry, you have the option of saying whether you think the quality of
> >this entry is especially good or bad. Gradually, your client builds
> >up a list of people you think write good entries. Then if a new query
> >returns multiple entries, your client may be better able to pick the
> >one you will think best.
> >
> >To automate the trust mechanism further, when you see a good entry,
> >you could ``second'' it, adding your signature to the original author's
> >(or vote against it). People who trust you will then be able to benefit
> >from your judgement of others. I imagine that a few well-known groups
> >would evolve to act as database police---but rememeber that they can't
> >throw out entries; merely say that they think the entries are no good.
> >If no-one listens to them, they are ineffective. Unfortunately, this does
> >not protect the servers from a malicious flooding attack, but it does
> >go some way to protecting the clients.
> >
> >To take it even further (and imitate another good idea from PGP) users
> >could submit their own trust lists to the database. Then, when you find
> >someone who you think is reliable and (transitively) you trust to make
> >reliability judgements, you can merge their trust list with your own.
> >A web of trust is quickly established. But this issue is rather beyond
> >the realm of current discussion and more like the subject for a PhD:-)
> >
> >I presume the existing cddb solves this by having what amounts to a
> >moderator? Is this another single point of failure? If so, we definitely
> >need to come up with a workable alternative.
> >
> >Robin.
> >--
> >R.M.O'Leary <robin nospam at acm.org> +44 7010 7070 44, PO Box 20, Swansea SA2 8YB, UK
> >
> >
>
> -----
> Jason Dufair
> funne nospam at iquest.net
> http://www.iquest.net/~funne
> http://www.iquest.net/~funne/jdufair.asc for PGP public key.
> "A laugh for the newsprint nightmare, a world that never was
> Where the questions are all 'why' and the answers are all 'because'"
> -Bruce Cockburn
-- Greg Stein, http://www.lyra.org/