[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] update mechanism

From: Christian Grothoff
Subject: Re: [GNUnet-developers] update mechanism
Date: Sun, 18 Aug 2002 17:13:21 -0500
User-agent: KMail/1.4.1

Hash: SHA1

On Sunday 18 August 2002 11:42 am, Martin Uecker wrote:
> On Sat, Aug 17, 2002 at 10:45:21PM +0300, Igor Wronsky wrote:
> > On Sat, 17 Aug 2002, Martin Uecker wrote:
> > > IMHO the solution to the spam problem are trust metrics.
> > > This basically solved the problem on the web (google, page rank).
> >
> > How do you propose to do this on gnunet? I admit I don't
> > know page rank by heart, but I think it was based on
> > reasoning how the web pages link to one another.
> > Is there any natural measure now that can be used?
> We can start rating down submitters who provide false
> meta data which can be automatically checked
> (SHA-1, MD5 and other). This is more protection against
> fraud than spam prevention but still a good idea.

You can *never* rank down. That's the same problem as in negative trust (read:
an excess based economy). Submitters are anonymous, but even if they signed
the RNode, they can use a pseudonym exactly once, in which case negative
ratings are useless (they would only apply after the damage has been done).
You can only do positive rankings.

> Then a node could search for files it has locally stored
> and rate people high who submitted the same files.
> > I don't see how content-level trust metrics could be done
> > without forcing the users to explicitly rank some
> > content/submitter as good or bad.
> The user has advantages from doing so because he might get
> much better search results if his client rates the results
> based on his personal trust database.

That's right. Every user could over time find out who are the good guys (and
then even add transitivity such that a trusts c if a trusts b and b trusts c,
but again, this should not be a 'boolean' trust but rather an (unsigned)
integer metric).

> > If the trust
> > was entirely local (and not published), it would
> > have to be possible to query only for the content
> > inserted by the trusted people (trusted by the user)
> > because otherwise the spam gets propagated again
> > (even if locally filtered out in the end).
> The actual data would expire some time because it would never
> be requested. The problem are the R-blocks which would be
> propagated. This is a problem unique to the gnunet design
> where a node can not know if the data for a certain R-block
> is ever requested.
> There are two thinks which must be done to get rid of those
> blocks:
> * The node storing those blocks should not have an economic
>   advantage (earn reputation) by returning them as search
>   results.
> * The node must somehow learn this fact.
> This could be done with trust metrics because a node can
> evaluate the trust of the submitter and discard the R-block
> if he is not trusted by the community to provide good
> (meta)-data.
> Another way which is much easier to implement are feedback
> messages. But those are problematic because they might
> be misused.

And/or be hard to do in an anonymous system. There is also the problem that
the node that stores the RNode can not decrypt it (deniability!), thus it can
not verify the signature or even tell that it is an RNode.

> > BTW, the same pseudonyms could be included to file
> > insertion (voluntarily), we could in a same way
> > look only for files inserted by certain pseodonyms.
> > This also fits nicely with planned collection/index
> > /directory -files, where spamming might be problem.
> Why pseudonyms? Individuals are best identified by the hashes
> of their pub keys. Those can't by hijacked because the owner
> can prove with a signature that he is the owner of his pub
> key.

Well, the hash of the public key *is* a pseudonym, as long as there is not a
public database that links public keys to individuals. And since you can make
up new public keys anytime, you can make new pseudonyms at any time - as many
as you feel like.


Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see


reply via email to

[Prev in Thread] Current Thread [Next in Thread]