On Friday 15 May 2009 00:14:52 Matthew Toseland wrote: > On Thursday 14 May 2009 17:33:29 Evan Daniel wrote: > > 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. > > Agreed, I have no problem with not reducing message trust in this case. > > > >> >> 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? > > Yes, sorry. > > > >> 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. > > Because there is a limit on churn, and one spamming identity can be blocked > trivially. Does this eliminate the need for reducing trust in an identity > that trusts spammers (hence ultimatums)? > > > >> 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. > > Right, because it's not an effective DoS. Which means we've won, more or > less, although it will continue to annoy newbies, and put them off Freenet, > and thus may be a useful attack. > > > 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. > > Ok. > > At this point I think we are in sufficient agreement that I would like some > input from p0s... >
I've sent my input some posts higher in the thread hierarchy today. -------------- 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/80f4a5c4/attachment.pgp>
