On Tuesday 26 May 2009 22:02:37 xor wrote: > On Thursday 07 May 2009 11:23:51 Evan Daniel wrote: > > > Why exactly? Your post is nice but I do not see how it answers my > > > question. The general problem my post is about: New identities are > > > obtained by taking them from trust lists of known identities. An > > > attacker therefore could put 1000000 identities in his trust list to > > > fill up your database and slow down WoT. Therefore, an decision has to > > > be made when to NOT import new identities from someone's trust list. In > > > the current implementation, it is when he has a negative score. > > [...] > > > I have not examined the WoT code. However, the Advogato metric has > > two attributes that I don't think the current WoT method has: no > > negative trust behavior (if there is a trust rating Bob can assign to > > Carol such that Alice will trust Carol less than if Bob had not > > assigned a rating, that's a negative trust behavior), and a > > mathematical proof as to the upper limit on the quantity of spammer > > nodes that get trusted. > > > > The Advogato metric is *specifically* designed to handle the case of > > the attacker creating millions of accounts. In that case, his success > > is bounded (linear with modest constant) by the number of confused > > nodes -- that is, legitimate nodes that have (incorrectly) marked his > > accounts as legitimate. If you look at the flow computation, it > > follows that for nodes for which the computed trust value is zero, you > > don't have to bother downloading their trust lists, so the number of > > such lists you download is similarly well controlled. > > I have read your messages again and all your new messages and you are so > convinced about advogato that I'd like to ask you more questions about how > it would work, I don't want you to feel like everyone is ignoring you :) (- > I am more of a programmer right now than a designer of algorithms, I > concentrate on spending most available time on *implementing* WoT/FT > because nobody else is doing it and it needs to get done... so I have not > talked much in this discussion) > > Consider the following case, using advogato and not the current FMS/WoT > alchemy: > > 1. Identity X is an occasional and trustworthy poster. X has received many > positive trust values from hundreds of identities because it has posted > hundreds of messages over the months, so it has a high score and capacity > to give trust values, and all newbies will know about the identity and it's > high score because it is well-integrated into the trust graph. > > 2. Now a spammer gets a single identity Y onto the trust list of X by > solving a captcha, his score is very low because he has only solved a > captcha but the score is there. Therefore, any newbie will see Y because X > is well-integrated into the WoT > > 3. X is gone for quite some time due to inactivity, during that time Y > creates 500 spam identities on his trust list and starts to spam all > boards. X will not remove Y from his trust list because he is *away* for > weeks.
Also consider the case that instead of 500 new identities he just posts 5000000 messages with his single identity Y. How do we get rid of Y? > 4. Newbies will see the 500 spam identities and their spam because everyone > trusts X, and X trusts Y. Newbies will NOT know how to block anything > because they are newbies. > > 5. Now the *core* task of the WoT is in question: How can we as the > community make the spam-identities introduced by Y disappear with advogato > trust metrics, without negative trust?? > > - As you've said, we cannot take away the trust which Y receives from X > because that is THE attribute of non-negative-trust-metrics. > - Further, we cannot cause EVERYONE who has trusted X to remove the trust > value because X is in way too many trust lists of idle people, etc. > - So what can we do with advogato, if we are the community and want to mark > Y as the root of evil? > > xor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090526/c6b5869e/attachment.pgp>
