[freenet-dev] How to fix Frost

[Matthew Toseland]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20070810/77879147/attachment.pgp