[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.

If you're using connection-based transmission, you could randomly order the list of receivers for each post (include one's self in list) and wait for a short random time (to avoid tracing by latency) between each transmission.

On the DistBB project...

Is there a wiki for this?
This would definitely organize our efforts.
If not? I'd be satisfied with an editable page like a single wiki article.

I guess I'm not much of a /prog/rider when I don't know the full details of DistBB...

I thought you had proposed using random delays to avoid timing attacks?

>>3
I would also like this. There must be something out there we can use without much effort.

>>3
My bad, I forgot to restart the service after rebooting the server.

https://ivasiwlrjq5dxk6b.onion/p/distbb/

It's fossil-hosted so it has a built-in wiki.

To get an account (so you can edit freely), see
https://ivasiwlrjq5dxk6b.onion/faq.html#register

>>1
Why didn't you just update your thread and bump:
https://bbs.progrider.org/prog/read/1378443345
I don't mind necrobumping when it is relevant or useful topics.

Second issue is: why don't you use a datastore, like in GNUnet or Freenet, so that nodes are not used, but the database instead? With Randomized Recursive Routing for Restricted-Route Networks (R5N), you can get rid of spammers.

>>7

Why didn't you just update your thread and bump:

Sorry, thought I'd make a challenge thing for the guy in the other thread.

Second issue is: why don't you use a datastore, like in GNUnet or Freenet, so that nodes are not used, but the database instead? With Randomized Recursive Routing for Restricted-Route Networks (R5N), you can get rid of spammers.

I don't see how that gets rid of the spammers. That's (from what I understand) a scalable DHT system. Its purpose is not to prevent people from inserting a lot of bogus entries in the 'table'. The problem I am struggling with is really as follows: how do you rate limit anonymous insertion into a distributed database?

>>6
Ah, then bump that one lol.

how do you rate limit anonymous insertion into a distributed database?

R5N fights repetitively rapid abuse of the network. We can use robots to defend against repetitive posts, like r9k. The latter, if the posts are random, we can use karma/votes as a mean to note that a post chain is terrible, at the choice of the user if they want to censor. Sort of like NNTP, but with a voting system, and a filter daemon.

s/>>6/>>8/
too angst Still, I hope the pun/link came out well done, 敬二

>>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.

No user could be differentiated from spammers, so spammers could not be prevented from posting.

That's the point of the karma/voting system, to downvote spam, never mind the user, since we want an anonymous network before all else.

but they can always post more and at an automated pace.

We we have a filter bot, to determine what is junk or not. Plus, the bot will not remove, but flag, so that the user discerns if the posts should be ignored. The point being is that everyone can post, at the convenience of anti-censorship, even if the message is ciphered to someone else. Think of anonymous remailers.

the spammer can create new identities to keep the spam flowing.

Thanks for adopting/considering my idea. In that system where you create usernames and passwords just for session validation and posting, use a captcha to defend the creation of usernames for the sake of spamming. But again, our aim is to let anyone post, regardless of content(even if the post looks like spam). The system should just allowing anyone to post, and have a section for tagging posts, kinda like folksonomy, so that multiple categories can be created for the user to filter through, even if it means creating another thread/database. IoW, the users decides to filter something or not, post are accepted regardless of content, everything under perfect forward secrecy, and satinized every X time (community or admin decides). In GNUnet we are doing it every 12 hours. It's up to the users to repost/keep-alive. If you need a reference:
https://gnunet.org/internetistschuld
https://gnunet.org/sites/default/files/grothoff_slides_berlin.pdf

The distributed-ness would prevent tyranical bans.

Exactly the point; which is why pseudonyms sessions for filtering posts essentially disrupts the ability of anyone to post, destroying anonymity. with randomized delays (both user posting and datastore publishing)

I think a distributed net of client/servers, where each is free to maintain their own white list of other pseudonyms would be effective.

I concur. A tagging or karma system helps distributing a list of categories, even if it is marked "spam".

Spam proof and anonymous might not really be possible from a design.

Everyone here would agree being anonymous at the cost of spam is a better cost than removing spam at the sake of identify-ability. With a tagging or voting list for each post, users can delegate their our rules of filtering content. Folksonomy is a great way allow the community to decide what they like about the post, even if it is "spam" or "2hu".

Using common-lithpth

Good to see you have evolved your toolset. I like reading your threads. You finished your bachelors now, right?

s/We We/Why we/
s/In GNUnet/In Secushare/
s/destroying anonymity. with randomized delays/destroying anonymity, with randomized I/O delays/ ##something required for anonymity, when a post was made, if ever.
s/about the post, even if it is /about the posts, even if they are/

You finished your bachelors now, right?

No irony intended.

>>12
>>11 isn't me.

>>2-13
Thank you for all your replies.
To clarify, the main problem is not moderation of regular posts, it's about how to stop a single person from spam posting so fast that all of king's horses and all of king's men wouldn't sift through all of that crap again.

>>11

computationally expensive pseudonyms

Not a bad idea (i.e. it is effective against spammers), the problem is that all of your posts become tied with that pseudonym. If you wanted to truly remain anonymous you would have to be generating new pseudonyms all the time. The same problem applies if instead of being computationally expensive, the pseudonym 'authentication' is done via CAPTCHA on a per-node basis.

Spam proof and anonymous might not really be possible from a design.

Spam proof means you are preventing a user from posting at very high rates. It is difficult to do that when the user is unidentifiable (anonymous), hence this thread.

>>9
That works fine if the shit/spam posts are at a slow enough rate that they can be 'handled' by the community.

Sorry, I'd write some more but I'm on a few deadlines.

What about Hashcash or some other POW system?
https://en.wikipedia.org/wiki/Hashcash

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.

single person from spam posting so fast

With randomized I/O delays and R5N, they can't post so fast to the datastore, it will be dropped.

>>16
I agree. It just some people here hate captcha for some reason. They already type some much shit, why not a little more for authenticating a post. Image captcha is stupid, although. I am fine w/ text captcha. But the deletion thing, should be left to time daemon. We don't want groups of people just to delete post that look like spam. Just have the user ignore them instead. Recall, users can still abuse the tagging or voting system.

>>14

all of your posts become tied with that pseudonym

Why exactly? You could use that pseudonym only to authorize access to the network without tying it to every post.

The idea I had for a normal human-moderated centralized BBS was

* The user wants to enter the BBS. He is given a easy problem such as a function that returns
- the sum of the divisors of x
- the xth ``squared'' Fibonacci number (F_n = F_n-1² + F_n-2²)
- the gcd of two numbers
The problems are generated randomly.

* The human moderator (or an automatic judge) evaluates the program made by the user

* If the user passes the test, he's given a ``login key''
Welcome to progrider[i]![/i]
Your key: [asdf12345_______] (Login)


* The user logs in and proceeds to shitpost about Javashit in /prog/.

* If the user does something terrible, his key is banned.

This would be the POW system that would double as a non-programmer filter. I'd hope it keeps the spammers out. And you don't have to tie the key to the user's posts, just check if the key is in a file and let the user in.

I know this sounds like a 14yo trying to recruit users for his epic secret forum, but I hope you can at least point out the flaws of my infantile design if nothing in it contributes to the DistBB POW system.

>>18

Why exactly? You could use that pseudonym only to authorize access to the network without tying it to every post.

The authorizer can keep logs of which pseudonym inserts which posts. In fact, they have to so they can retract their authorization for spammers.

[to get a post key, write a program that solves a human-generated problem]

The problem is that operator intervention is required not only to generate the problem, but also to judge the result.

The moderation system is far more refined than what you describe. See
https://ivasiwlrjq5dxk6b.onion/p/distbb/artifact/f6bbcf1cab252361d04dab785933b478436fbac6

>>16

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.

I have accounted for that. See the link above.

>>17

We don't want groups of people just to delete post that look like spam. Just have the user ignore them instead. Recall, users can still abuse the tagging or voting system.

No, they can't. See the link above.

R5N

I promise to read that paper in its entirety sometime soon (as opposed to just skimming).

>>15

What about Hashcash or some other POW system?

That's another option, albeit with a memory-hard function. What I would like is a memory-hard non-parallelizable function with an arbitrary difficulty parameter such that checking the result takes a very short time.

If one is willing to switch to complete pseudo-anonymity

Then they can just post directly to their own node; their posts will get synchronized with the rest of the network. Alternately, they can convince another node operator to accept their signed posts.

>>19
We could probably get away with only forcing captcha to post or to get a posting token during times of continuous spam. Like if the post rate exceeds a certain amount within a time interval, then captcha becomes active for a time and deactivates later. As long as the system is automatically triggered, it should respond to a spam storm in time.

>>17
Randomized post delays would reduce the post rate, but a spammer could clog the system and prevent other posters from posting. With pure anonymous posting, it isn't possible easy to detect which posts are made by which users, so it's either block/delay everyone or block none.

>>19

The authorizer can keep logs of which pseudonym inserts which posts

That's a problem indeed. It works only for a centralized BBS.

The problem is that operator intervention is required not only to generate the problem, but also to judge the result.

You could add random components to the programs. There exist many automated evaluators, but you could automate it with just a few test cases implemented with asserts.

Anyway, thank you for taking the time to reply.

Thank these dubs

DistBB NEVER