On Fri, May 22, 2009 at 4:16 PM, Matthew Toseland <t...@amphibian.dyndns.org> wrote: > On Friday 22 May 2009 15: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. > > Right, this is something I keep forgetting to mention. When marking a user as > a spammer, the UI should ask the user about people who trust that spammer and > other spammers. However, it does encourage militancy, doesn't it? It > certainly doesn't solve the problem the way that ultimatums do...
I don't know how much militancy the software should encourage. I'm inclined to think it should start low, and then change it if that doesn't work. >> >> > - 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. > > I was under the impression that WoT already used Advogato, apart from > supporting negative trust values and therefore negative trust. The documentation mentions Advogato, and there are some diagrams that relate to it, but none of the detailed description of the algorithm is at all related. Advogato is based on network flow computation. WoT as described on the freesite is not -- an identity with 40 trust points is permitted to give up to 40 points *each* to any number of child identities, with the actual number given determined by a trust rating. In contrast, Advogato has multiple levels of trust, and each identity either trusts or does not trust each other identity at a given level. The number of trust points an identity gets is based on capacity and the optimal flow path. It does not speak to how trustworthy that identity is; at a given trust level, the algorithm either accepts or does not accept a given identity. Multiple trust levels (eg, a level for captcha solving and a level for manual trust) implies running the algorithm multiple times on different (though related) graphs; when running at a given level, connections at that level and all higher levels are used. This implies running Ford-Fulkerson or similar; it's more complicated than the current system, though not drastically so. http://en.wikipedia.org/wiki/Ford-Fulkerson_algorithm >> >> > - 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. > > Not bad. Currently CAPTCHA identities are seen by everyone iirc, this may be > a desirable (if not scalable) property. For the current size of the network, they should probably be seen by everyone or nearly everyone. For larger networks, that probably changes. >> >> 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. > > Yeah... so far p0s has resisted any suggestion that any identity won't be > seen by everyone... Also the anti-censorship lobby probably object to any new > identity not being seen by them. Since each identity performs its own calculations, different people can use different capacity vs distance functions. People who are strongly anti-censorship could elect to see anyone who solved a CAPTCHA from someone they accept; other people could use shorter-range functions and see fewer new identities and (presumably) less spam. >> >> > - 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. > > Not sure I follow. You would have to answer all the CAPTCHAs in order to > reach the limit, no? And anyway, these are captchas, they are not the same as > really trusted identities, as e.g. in your algorithm above. So it is solvable. Suppose we limit trust list churn to a few identities per day. I publish unlimited CAPTCHAs. Mallory then solves several of my CAPTCHAs, creating throwaway identities. These identities then send out spam. Since I'm attentive and responsible, I promptly mark them as such. However, they appear on my (captcha-level) trust list and then disappear. When Alice runs her trust calculations and sees this, the churn limit triggers. As a result, my CAPTCHA queue is useless to newbies, since the introductions get ignored thanks to the churn limits. This should be solvable; I just think solving it requires paying attention to it :) . eg allowing more churn at the CAPTCHA level than the manual level, combined with lower message count limits at the CAPTCHA level. How big a problem it is also depends greatly on how effective you believe the CAPTCHAs are -- something I'm fairly pessimistic about, in the face of a determined attack. >> >> > 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 spam, that would be the day we release. :) Evidence? FMS didn't have huge spam problems on release (I haven't used it recently enough to speak to the present situation). We don't have a data point for the case where spam requires manual effort. My working assumption is that there are a very small number of spammers, and that they're very willing to write bots, regardless of effort required, but that they're unwilling to put in per-spam-message effort. >> >> > 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." > > No, by posting _interesting_ messages. That is, if somebody replies to a > message, by default they gain some trust, but there is a box you can uncheck > ... we could even have this turned off by default on test boards? Defaulting to off for test boards is probably sufficient. People are likely to want to send out test pings, and sending replies is reasonable, but should not grant any trust at all. > > Nobody will ever bother to click "Mark non-spammer" imho. Maybe so. But at least some people maintain trust lists on FMS, and that requires effort. If the list of new messages displayed the trust status of the poster, as a drop-down menu, would that be any better? If there is any sort of address book (for sending mail / private messages / IMs), people will use that, and that may be a better source than replies. Also, marking identities so I can easily see that t...@[crypto junk 1] is who I think it is, but t...@[crypto junk 2] isn't is useful -- I remember using the Frost features to do that, many moons ago. Evan Daniel _______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
