PROBLEM: We have a problem with Frost. The spammer automatically posts ALICE-generated replies to every message posted on a variety of boards on the list shipped with Frost. This is a minor annoyance for oldies - all they do is tell Frost to ignore CHECK messages (messages from posters who haven't been marked yet), and enable threaded view so they see replies from their friends to newbies. The problem is, newbies don't have a database of trustworthy people. If they post a question, they will get a nonsensical reply from a bot, probably before any real person responds. And half of the messages on Frost are such nonsense spam. Now, because this doesn't DoS Frost for oldies, very little is being done about it, but it does seriously harm Freenet by making it unlikely that newbies will use Frost, and therefore significantly increasing their chance of leaving... Apart from this, there are many other attacks possible on the KSK-queues that Frost uses, the simplest being the Message of Death: simply post continually to the KSK-queue, it doesn't matter what you post, it'll make it take a loooong time to either find new messages or post a message. If the spammer was to change tactic he could probably render Frost unusable even to oldies, at least on a few boards, with very little effort, and he could certainly make it impossible to identify newbie posts among all the spam.
PROPOSED SOLUTION: 0. ULPRs. (Node) Ultra-Lightweight Persistent Requests are the basis of all that follows. Essentially this is a means to limit the load caused by polling clients such as Frost, to get messages to the clients faster, and to make messages which have been lost by being in the wrong place findable if they are popular. Issues: If this is deployed without the below, it will only make spam easier, because the messages will be propagated even faster. 1. True Web of Trust. (Frost) Frost must publish the list of users marked manually by users. So if you trust a particular user, you automatically have (a slightly reduced) trust in the users that he trusts. If you then mark somebody as not trustworthy, Frost will ask you if you want to reevaluate the people who trust him, and indicate how many/which people you have marked as bad are trusted by those posters. Benefits: For oldies, faster propagation of trust in newbies etc. For newbies, if we ship an initial list of likely to be trustworthy posters, much faster assimilation; they can have a fairly usable Frost, minus spam. But we still need some experienced people to watch the boards for posts from newbies. 2. Outbox Polling. (Frost) Frost, or some similar app, can poll outboxes of specific users rather than watching a global KSK queue. These might be global for that user (encrypted for specific boards), which might work well with ULPRs, or they might be per user per board. Prerequisites: ULPRs! This will generate a lot of traffic otherwise, but with ULPRs it should be feasible. Benefits: For oldies, Frost will work efficiently and is completely immune to Message of Death attacks and similar KSK queue DoS'es. Note that we still need a means for newbies to introduce themselves, initially this would be a KSK queue. Issues: Currently threaded view with CHECK disabled works relatively well. It doesn't require explicit trust settings. Maybe we should have automatic marginal trust when you reply to an untrusted post, unless you tell Frost not to? 3. Thinkcash/Hashcash introductions. (Frost) Each poster can publish hashcash/thinkcash puzzles. The puzzle when solved yields a key, which enables a newbie to send a message to the poster. This message will be seen regardless of trust settings, and the poster will be given an initial marginal trust (OBSERVE??). After that, if nobody marks the newbie poster as bad, he can post freely, and his messages will be seen by the people who trust the original poster. IMPLEMENTATION I may implement ULPRs after opennet is ready. The rest will have to be implemented by Frost devs etc.
pgpXkrkBPEcKY.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
