On Fri, May 22, 2009 at 5:03 PM, Matthew Toseland <t...@amphibian.dyndns.org> wrote: >> >>>> - 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. >> >>> This would require adding trust to new people, As you can see with FMS, >> >>> having everyone spending >> >>> dayly time on trustlist adjustments is just an idea, which wont come >> >>> true. So this would mean that >> >>> every identity that is not very active will loose any trust and would >> >>> have to introduce himself >> >>> again. More pain and work resulting in less users. >> >> >> >> See my proposal (other mail in this thread, also discussed >> >> previously). Short-range but long-lived trust is a better substitute, >> >> imho. >> > >> > I would call it censorship because those that see you because of captcha >> > announcement can themselves >> > say what happens, >> > -if they dont give you trust, most wont see you => you are lost, are >> > censored >> > -if the give you trust, everyone will see you => not censored >> > >> > This would give a small group of people the chance to censor newly >> > announced identities (also the >> > group may be different for every identity). >> >> Then use a more permissive capacity:distance function. There is no >> requirement that you use a shorter range function, or that you use the >> same function as everyone else. IMHO, the default should be somewhat >> shorter range, in an attempt to balance the number of people that see >> new identities. As you observe, too few leads to censorship >> possibilities (out of malice or just plain laziness). Too many means >> that an identity with CAPTCHA trust only can spam and have everyone >> see that spam, which provides the spammer a reasonably efficient way >> to send spam. > > So it's a tradeoff which can be easily configured by the user.
Yes. As always, intelligent defaults are important; they should be applicable to most newbies, but don't need to meet everyone's needs. And if you change it unwisely, you hurt only yourself (other people don't even notice). > > I agree with pretty much all of the above, but the medium-term worry is that > we will start to have to worry about those who trust spammers, and those who > trust those who trust spammers. By eliminating negative trust, Advogato > forces us to either tolerate a certain (and unclear) amount of spam, or spend > a lot of effort on hunting down those who trust spammers, resulting in > massive collateral damage. >> >> >> >> Also, what do you mean by review of identities added from others? >> >> Surely you don't mean that I should have to manually review every >> >> poster? Isn't the whole point of using a wot in the first place that >> >> I can get good trust estimates of people I've never seen before? >> > >> > In FMS, there is currently a simple page, where the latest added >> > identities are listed and how they >> > where listed. So if you get many spamming identities and they are all >> > added from 1 trusted peer, >> > just remove his trustlist trust and all those new spamming identities wont >> > reach you. > > We want to make it easy, or nobody will do it. Poring over your trust list > day after day is not most people's idea of fun. > > There are three approaches, given positive trust only. Depending on the level > of effort exerted by the spammer, we move from one tradeoff between spam > resistance and censorship resistance to the next. IMHO the last stage > involves significant risk of censorship or at least collateral damage, while > obviously having the strongest spam resistance. > > The first approach is to mark spammers as spammers, and limit the capacity of > trusted identities to create new spammers by for example limits on the number > of identities that can change in a trust list in one day. This means that > everyone will have to mark all the spam identities as spam, much as in Frost > with the Alice bot. It will deter newbies, but it should be usable for the > determined. Note that it is *essential* on a positive trust only network that > our spam markings override others' positive trust levels. > > The second approach is when we mark an identity as spam, WoT realises that an > identity trusting that spammer also trusts a lot of other spammers, and > proposes that we mark the parent identity as a spammer, at least for purposes > of trust list trust. Hopefully this will be enough. The cost for every user > will be to mark a few spammer posts as spam, and then accept WoT's > recommendation to mark the parent as spammer. "A few" will be an arbitrary > parameter that will have to be argued about, higher means less chance of > marking non-spammers as spammers, but at the cost of seeing more spam. > > The third approach is that when we mark the parent identity as spam, WoT > suggests marking those who trust the parent identity also as spammers for > purposes of trust list trust (if we trust them; if we don't, it's not our > problem; we are trying to optimise the network *for other people*, > particularly for newbies, here). We can try to be polite about this using > ultimatums, since it's likely that they didn't deliberately choose to trust > the spam-parent knowing he is a spam-parent - but if they don't respond in > some period by removing him from their trust list, we will have to reduce our > trust in them. This will cause collateral damage and may be abused for > censorship which might be even more dangerous than the current problems on > FMS. However, if there is a LOT of spam, or if we want the network to be > fairly spam-free for newbies, the first two options are insufficient. :| I'm not certain you're correct about this. The first two methods are, imho, sufficient to limit spam to levels that are annoying, but where the network is still usable. Even if they download a bunch of messages, a new user only has to click the "spam" button once per spamming identity, and those are limited in a well defined manner (linear with modest coefficient with the number of dummy identities the spammer is willing to maintain). My suspicion is that if all they can aspire to be is a nuisance, the spammers won't be nearly as interested. There is much more appeal to being able to DoS a board or the whole network than being able to mildly annoy the users. So if we limit the amount of damage they can do to a sane level, the actual amount of damage done will be noticeably less than that limit. There is another possible optimization we could do (I've just thought of it, and I'm not entirely certain that it works or that I like it). Suppose that Alice trusts Bob trusts Carol (legitimate but confused) trusts Sam (a spammer), and Alice is busy computing her trust list. Bob has (correctly) marked Sam as a spammer. In the basic implementation, Alice will accept Sam. Bob may think that Carol is normally correct (and not malicious), and be unwilling to zero out his trust list trust for her. However, since this is a flow computation, we can place an added restriction: when Alice calculates trust, flow passing through Bob may not arrive at Sam even if there are intermediate nodes. If Alice can find an alternate route for flow to go from Alice to Carol or Sam, she will accept Sam. This modification is in some ways a negative trust feature, since Bob's marking of Sam as a spammer is different from silence. However, it doesn't let Bob censor anyone he couldn't censor by removing Carol from his trust list. Under no circumstances will Alice using Bob's trust list result in fewer people being accepted than not using Bob's trust list. It does mean that Bob, as a member of the evil cabal of default trust list members for newbies, can (with the unanimous help of the cabal) censor identities in a more subtle fashion than simply not trusting anyone. The caveats: this is a big enough change that it needs a close re-examination of the security proof (I'm pretty sure it's still valid, but I'm not certain). If it sounds like an interesting idea, I can do that. Also, I don't think it's compatible with Ford-Fulkerson or the other simple flow capacity algorithms. The changes required might be non-trivial, possibly to the point of changing the running time. Again, I could look at this in detail if it's interesting enough to warrant it. Evan Daniel _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
