Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

[CHALLENGE] Useful challenge [DistBB]

Name: the distbb guy 2013-11-10 19:29

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.

Name: Anonymous 2013-11-11 3:27

>>7,8

I don't think spam control is possible in a true anonymous posting board. No user could be differentiated from spammers, so spammers could not be prevented from posting. Their posts would be deleted after posting, but they can always post more and at an automated pace.

If pseudonyms are required for posting, the spammer's pseudonym can be banned, but if a new pseudonym can be created at little expense, the spammer can create new identities to keep the spam flowing. So the problem is not solved.

Using a white list of pseudonyms of users that have demonstrated themselves to not be spammers would prevent abuse with minimal effort in moderation. But good pseudonyms must start as new users, so spammers may still deliver spam by continuously re-entering as a new user. But at least with this, users may choose to view content only submitted by white-listed pseudonyms, and ignore new users with the advantage of disabling spam and the disadvantage of ignoring potentially good but new users who have not yet established the reputation of their pseudonym.

What if it was computationally expensive to create a pseudonym? This would inconvenience all users, but it would inconvenience spammers more, as they must create a new name each time their old name is banned. It can't be too inconvenient though, since it would discourage new users. This isn't a good solution.

I think a distributed net of client/servers, where each is free to maintain their own white list of other pseudonyms would be effective. The distributed-ness would prevent tyranical bans. The white list makes it difficult for new users to establish their identities, but some operators/readers may be more open to store/read the posts of new users at the expense of seeing spam content and banning its associated pseudonym.

Anyways, I'm starting a bit of work for distbb. Using common-lithpth. But regardless of the implementation, I think it would be a wise development strategy to keep it simple at first and add in restrictions as the needs arise. Spam proof and anonymous might not really be possible from a design.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List