On Fri, May 22, 2009 at 8:17 AM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > On Friday 22 May 2009 08:17:55 bbackde at 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. > - Limits on identity churn in any trust list (1 new identity per day averaged > over a week or something), to ensure that an attacker who has trust cannot > constantly add new identities. This is clearly required (to prevent a spammer multiplying a limited trust to introduce many throw-away identities, each of which spams up to the message count limits). However, it does present a new problem: because trust capacities are limited, it provides a far more effective DOS of the CAPTCHA queue than simply answering all CAPTCHAs. I'm not sure how to handle that. A DOS that prevents new users from joining is particularly vicious. > > It probably also requires: > - Some indication of which trusted identities trust a spammer when you mark an > identity as a spammer. > - Sending an ultimatum to the trusted identity that trusts more than one > spammer: stop trusting spammers or we'll stop trusting you. This would have > to be answered in a reasonable time, hence is a problem for those not > constantly at their nodes. > > evanbd has argued that the latter two measures are unnecessary, and that the > limited number of spam identities that any one identity can introduce will > make the problem manageable. An attacker who just introduces via a CAPTCHA > will presumably only get short-lived trust, and if he only posts spam he > won't get any positive trust. An attacker who contributes to boards to gain > trust to create spamming sub-identities with has to do manual work to gain > and maintain reputation among some sub-community. A newbie will not see old > captcha-based spammers, only new ones, and those spam identities that the > attacker's main, positive identity links to. He will have to manually block > each such identity, because somebody is bound to have positive trust for the > spammer parent identity. Well... I argue that they *may* be unnecessary. Specifically, I think we can defer implementation until there are problems that warrant it. > > In terms of UI, if evanbd is right, all we need is a button to mark the poster > of a message as a spammer (and get rid of all messages from them), and a > small amount of automatic trust when answering a message (part of the UI so > it can be disabled). Only those users who know how, and care enough, would > actually change the trust for the spammer-parent, and in any case doing so > would only affect them and contribute nothing to the community. > > But if he is wrong, or if an attacker is sufficiently determined, we will also > need some way to detect spam-parents, and send them ultimatums. I'm not certain that's the right way to grant manual trust. (Or perhaps we need more than one level of it.) You don't want a spammer to be able to get manual trust by posting a message to the test board consisting only of "Hi, can anyone see this?" -- they can do that automatically. I think there should be a pair of buttons, "mark spammer" and "mark non-spammer." Evan Daniel
