On Thu, May 14, 2009 at 11:32 AM, Matthew Toseland <toad at amphibian.dyndns.org> wrote: >> IMHO these are not solutions to the contexts problem -- it merely >> shifts the balance between allowing spam and allowing censorship. ?In >> one case, the attacker can build trust in one context and use it to >> spam a different context. ?In the other case, he can build trust in >> one context and use it to censor in another. >> >> Right now, the only good answer I see to contexts is to make them >> fully independent. ?Perhaps I missed it, but I don't recall a >> discussion of how any other option would work in any detail -- the >> alternative under consideration appears to be to treat everything as >> one unified context. ?I'm not necessarily against that, but the >> logical conclusion is that you're responsible for paying attention to >> everything someone you've trusted does in all contexts in which you >> trust them -- which, for a unified context, means everywhere. > > Having to bootstrap on each forum would be _bad_. Totally impractical. > > What about ultimatums? "these" above refers to WoT with negative trust, right? > Ultimatums: I mark somebody as a spammer, I demand that my peers mark him as > a spammer, they evaluate the situation, if they don't mark the spammer as > spammer then I mark them as spammer.
Right. So all the forums go in a single context. I don't see how you can usefully define two different contexts such that trust is common to them but responsibility is not. I think the right solution (at least for now) is one context per application. So you have to boostrap into the forums app, and into the filesharing app, and into the mail app, but not per-forum. Otherwise I have to be able to evaluate possible spam in an application I may not have installed. Ultimatums sound like a reasonable approach. Though if Alice sends Bob an ultimatum about Bob's trust for Sam, and Bob does not act, I'm inclined to think that Alice's client should continue downloading Bob's messages, but cease publishing a trust rating for Bob. After all, Bob might just be lazy, in which case his trust list is worthless but his messages aren't. >> >> Also, I don't see how this attack is specific to the Advogato metric. >> >> It works equally well in WoT / FMS. ?The only thing stopping it there >> >> is users manually examining each other's trust lists to look for such >> >> things. ?If you assume equally vigilant users with Advogato the attack >> >> is irrelevant. >> > >> > It is solvable with positive trust, because the spammer will gain trust > from >> > posting messages, and lose it by spamming. The second party will likely be >> > the stronger in most cases, hence we get a zero or worse outcome. >> >> Which second party? > > The group of users affected by the spam. The first party is the group of users > who are not affected by the spam but appreciate the spammer's messages to a > forum and therefore give him trust. Ah. You meant "solvable with *negative* trust" then? >> OK. >> >> I think you really mean "Pure positive only works *perfectly* if every >> user..." > > Hmm, maybe. > >> We don't need a perfect system that stops all spam and >> nothing else. ?Any system will have some failings. ?Minimizing those >> failings should be a design goal, but knowing where we expect those >> failings to be, and placing them where we want them, is also an >> important goal. >> >> Or, looked at another way: ?We have ample evidence that people will >> abuse the new identity creation process to post spam. ?That is a >> problem worth expending significant effort to solve. ?Do we have >> evidence that spammers will actually exert per-identity manual effort >> in order to send problematic amounts of spam? > > I don't see why it would be per-identity. Per fake identity that will be sending spam. If they can spend manual effort to create a trusted id, and then create unlimited fake ids bootstrapped from that one to spam with, that's a problem. If the amount of effort they have to spend is linear with the number of ids sending spam, that's not a problem, regardless of whether the effort is spent on the many spamming ids or the single bootstrap id. > >> Personally, I'm not >> worried about there being a little bit of spam; I'm worried about it >> overwhelming the discussions and making the system unusable. ?My >> intuition tells me that we need defenses against such attacks, but >> that they can be fairly minimal -- provided the defenses against >> new-identity labor-free spam are strong. > > So you consider the problem to be contained if a spammer can only trust 20 > identities, everyone reads his messages, everyone reads his sub-identities' > spams, and then individually blacklist them? Those targeted by the spam would > then not trust the spammer's main identity in order to not see his > sub-identities' spam, but those who talk to him would as they don't see them. > Maybe you're right, if we have some severe constraints on changes to trust > lists? Yes, I consider that a solution, for two reasons. First, that's a manageable amount of spam. Annoyingly high, but manageable. Second, I think that if the amount of spam they can send is limited to that level, they (generally) won't bother in the first place, and so in practice you will only rarely see even that level of spam. Constraining trust list changes is definitely required. I would start with a system that says that if Alice is calculating her trust web, and Bob has recently removed Sam from his trust list, then when Alice is propagating trust through Bob's node, she starts by requiring one unit of flow go to Sam before anyone else on the list, but that that unit of flow has no effect on Alice's computation of Sam's trustworthiness. Or, equivalently, Bob's connection to the supersink is sized as (1 + number of recently un-trusted identities) rather than the normal constant 1. That allows Bob to manage his trust list in a prompt fashion, but if he removes people from it then he is prevented from adding new people to replace them too rapidly. The definition of "recent" could be tweaked as well, possibly something like only 1 identity gets removed from the recent list per time period, rather than a fixed window during which any removed id counts as recently removed. Evan Daniel
