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-10 19:49

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.

Name: Anonymous 2013-11-10 21:36

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

Name: Anonymous 2013-11-10 21:39

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

Name: Anonymous 2013-11-10 22:30

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

Name: Anonymous 2013-11-10 22:32

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

Name: Anonymous 2013-11-11 2:39

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

Name: Anonymous 2013-11-11 2:47

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

Name: youtu.be/NWYJYcpSpCs 2013-11-11 3:17

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

Name: >>9 2013-11-11 3:20

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

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.

Name: Anonymous 2013-11-11 4:08

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?

Name: >>12 2013-11-11 4:24

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.

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