On Friday 22 May 2009 16:39:06 Evan Daniel wrote: > On Fri, May 22, 2009 at 8:17 AM, Matthew Toseland > > <t...@amphibian.dyndns.org> wrote: > > On Friday 22 May 2009 08:17:55 bbac...@googlemail.com wrote: > >> Is'nt his point that the users just won't maintain the trust lists? > >> I thought that is the problem that he meant.... how can Advogato help us > > > > here? > > > > Advogato with only positive trust introduces a different tradeoff, which > > is still a major PITA to maintain, but maybe less of one: > > - Spammers only disappear when YOU mark them as spammers, or ALL the > > people you trust do. Right now they disappear when the majority, from the > > point of view of your position on the WoT, mark them as spammers (more or > > less). > > When they *fail to mark them as trusted*. It's an important > distinction, as it means that in order for the spammer to do anything > they first have to *manually* build trust. If an identity suddenly > starts spamming, only people that originally marked it as trusted have > to change their trust lists in order to stop them. > > > - If you mark a spammer as positive because he posts useful content on > > one board, and you don't read the boards he spams you are likely to get > > marked as a spammer yourself. > > Depends how militant people are. I suspect in practice people won't > do this unless you trust a lot of spammers... in which case they have > a point. (This is also a case for distinguishing message trust from > trust list trust; while Advogato doesn't do this, the security proof > extends to cover it without trouble.) You can take an in-between > step: if Alice marks both Bob and Carol as trusted, and Bob marks > Carol a spammer, Alice's software notices and alerts Alice, and offers > to show Alice recent messages from Carol from other boards. > (Algorithmically, publishing "Sam is a spammer" is no different from > not publishing anything about Sam, but it makes some nice things > possible from a UI standpoint.) This may well get most of the benefit > of ultimatums with lower complexity. > > > - If a spammer doesn't spam himself, but gains trust through posting > > useful content on various boards and then spends this trust by trusting > > spam identities, it will be necessary to give him zero message list > > trust. Again this has serious issues with collateral damage, depending on > > how trigger-happy people are and how much of a problem it is for newbies > > to see spam. > > > > Technologically, this requires: > > - Changing WoT to only support positive trust. This is more or less a one > > line change. > > If all you want is positive trust only, yes. If you want the security > proof, it requires using the network flow algorithm as specified in > the paper, which is a bit more complex. IMHO, fussing with the > algorithm in ways that don't let you apply the security proof is just > trading one set of alchemy for another -- it might help, but I don't > think it would be wise. > > > - Making sure that my local ratings always override those given by > > others, so I can mark an identity as spam and never see it again. Dunno > > if this is currently implemented. > > - Making CAPTCHA announcement provide some form of short-lived trust, so > > if the newly introduced identity doesn't get some trust it goes away. > > This may also be implemented. > > My proposal: there are two levels of trust (implementation starts > exactly as per Advogato levels). The lower level is CAPTCHA trust; > the higher is manually set only. (This extends to multiple manual > levels without loss of generality.) First, the algorithm is run > normally on the manual trust level. Then, the algorithm is re-run on > the CAPTCHA trust level, with modification: identities that received > no manual trust have severely limited capacity (perhaps as low as 1), > and the general set of capacity vs distance from root is changed to > not go as deep. > > The first part means that the spammer can't chain identities *at all* > before getting the top one manually trusted. The second means that > identities that only solved a CAPTCHA will only be seen by a small > number of people -- ie they can't spam everyone. The exact numbers > for flow vs depth would need some tuning for both trust levels, > obviously. You want enough people to see new identities that they > will receive manual trust.
It is absolutely INACCEPTABLE for a discussion system to only display messages of newbies to "some people" due to the nature of discussion: - The *value* of a single post from a new identity which has posted a single message can be ANYTHING... it can be absolute crap... but it can also be a highly valuable secret document which reveals stuff which is interesting for millions of people. In other words: The fact that someone is a newbie does not say ANYTHING about the worth of his posts. In more other words: NO individual has the right to increase the "worth" of his posts - as in the amount of people reading them - by speaking very much on Freetalk and gaining lots of trust with that. EVERY SPEAKER SHALL BE EQUAL! :) Thats freedom of speech. Therefore, the probability of messages of a valid identity not being seen by everyone must be reduced to nearly zero. Further, "a small number of people" will mean random people, and because you cannot expect newbies to solve thousands of captchas, a newbie will only solve 10 or so. So if you really mean only the people who have published the captchas, how high do you consider the probability that: 0. They actually use Freetalk currently? 1. They read (maybe single!) board where the newbie posts? 2. They read the posts of him? 3. They are interested in the posts? 4. They actually give him real trust then, thats the product of all the probabilities!..... This is VERY unlikely! So if we want newbies to have ANY chance to gain trust, we need thousands of people to see their posts until someone is actually interested, because if only 10 people see them, it is very likely that not a single one will read the posts and give trust.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
