[CHALLENGE] Useful challenge [DistBB]

Hi. I have not forgotten about you. I have, however, been drowning in work (and I still am).

I've realized that the design of DistBB allows an attacker with low to moderate resources to track down the exact node that posts something, simply by polling every node at short intervals and seeing where the node appears first. If nodes are hidden services (Tor or I2P or otherwise), the attacker doesn't immediately find out the poster's identity, but can accumulate a large number of posts coming from their node and figure out your identity from that. Unless, of course, the poster slips up at any point. This is a definite privacy leak.

So far every solution for true anonymous posting I've come up with involves either reimplementing a whole web-of-trust scheme (and using that as a remailer system), a proof-of-work system, or a CAPTCHA. The obvious constraint is preventing spammers from posting far faster than moderators can keep up with.

Web-of-trust sounds, and is, fairly complicated. It would definitely stray away from the goal of simplicity of the project.

Proof-of-work may work out to be sufficiently simple. The main problem is then that users with low resources will be penalized. The system may also not be entirely effective against spammers with large amounts of resources.

Finally, offering both textual and visual CAPTCHAs should be a viable solution, at the cost of some simplicity.

My proposal is as follows: Keep the anonymous posting part separate from ``the'' DistBB protocol, and specify a separate anonymous posting protocol with proof-of-work and CAPTCHA methods.

If you have better ideas I want to hear them.

Otherwise, the actual challenge is in designing a simple yet effective textual (and maybe visual) CAPTCHA system.

Captcha is a good solution. Captcha required on posting maintains complete anonymity, has strong control over post rates, but makes for inconvenient user experience.

Captcha for a temporary post pass somewhat harms anonymity by linking posts made by a single user made within a single session together as seen by the node operator. But this isn't too bad, and a user may choose to refresh their token with a new captcha on each new post if they wish. Post rate can be controlled by limiting the post frequency made with a single token. User experience is much better than captcha per post, and is probably the best it can get. If one is willing to switch to complete pseudo-anonymity, the token could be configured to not expire and user experience is unaffected if stored in a cookie. If people don't like the cookie, they could copy and paste the code back and forth.

Two concerns of spamming is one, forcing the nodes to store and process too much content, and two diluting the board with irrelevant content. With post rate controlled, the node storage abuse is no longer an issue. Spam posts may still be made, but if their rate is controlled then users can use a rating system to flag spam. This distributed moderation will need to be done by trusted pseudo-identities, or else a single voter could create many identities to skew the ratings, making them unreliable. The ratings would be stored alongside the post in each node, and users may configure their client/userscript to only display posts above a configured rating. Node operators may delete flagged posts manually or automatically via the rating system.