You might look to something like the silkroad for a case study; the guy(?) who runs that site is pretty active on the forums and would likely give you some time if he agreed with your mission (he has a strong anarcho leaning, I suspect he would, in this case).

Spam can be relatively easily avoided with some captchas; but I don't know how you can avoid fake reports; or how being anonymous even helps or hinders the likliehood that reports would be fake.

I agree with other posters that recommending, teaching, or even requiring them to use Tor is a good idea. tormail for example is reachable from the clearnet, but to actually use their service you are required to connect to their hidden service, which has the added benefit that they are basically impossible to shut down; even if they get your clearnet server (which really just has instructions and metainfo on it); the actual server doing the work is nearly impossible to find, and if it is found but the key is kept safe you can just pop it up again.

It's worth considering protecting not only your clients but your selves; running as a Tor hidden service can go a long way toward this.

For a start, you could remove the 6 or so 3rd party scripts from the homepage that record IP address and other personally identifiable information. The social media scripts may be useful for spreading word of mouth but unfavorable to true anonymity.

thanks for a tip. we'll do that.

While it doesn't directly answer your question, keep in mind the best thing you can do for maintaining your client's security is teaching them to use Tor. Nothing server-side will protect them because you may make mistakes, you may be compromised, or they may be MITMed.

Why do you log ip addresses at all? What happens when you get a subpoena, you have to turn it all over, right? Wouldn't it be safer not to store that info at all?

Protect your sources by all means necessary if you want to built trust, the technology is in place to do this, the legal footing on the other hand can be tricky. You should host your servers in a country that has a solid legal framework in place to protect your data, Iceland for example. Honestly consult a lawyer who specializes in this, it is a legal issue and not a tech one.

The real problem is vetting your material, you will need to analyse and verify submissions before posting using real people, there is really no alternative when lives are at stake. This is the reason wikileaks collaborates with researchers and journalists, and there is an entire approval process. I must stress this point, you MUST have due diligence on your sources or else don't even bother.

Also keep in mind that several countries make anonymous services very difficult to use and even so they still might be monitored, you need to enable multiple avenues of submission and do a really good job at informing your user base on which is best.

You should have a very solid and dynamic server setup that can withstand attacks/DDos and domain name/ISP related takedowns.

tl;dr Learn from all the issues wikileaks had with tech and submissions and how they overcame these challenges.

The problem is that you can't really "vet" stuff like "Official Mr. XYZ demanded payment of US$ 20 so that I can get the permit faster".

Vetting a leak is easy. Vetting an accusation of bribery is next to impossible unless you're an undercover policeman and catch the bribed person red-handed (or, the building/exchange place is under CCTV surveillance).

The point is to identify officials who would do it ordinarily: his service can respond that no one else has mentioned that official, and encourage their users to ask a friend to testify too. More than establish a proof that could be legally binding for local institutions (a long shot) it will encourage people to consider how many friends are influenced, and would be ready to do something. Just talking about filling in a form, no matter how empty that process can be, sets them in a changing path. What the original comment was pointing out is to set up process to avoid adversaries of his service to discredit him by posting fake accusation, and ‘showing’ how wrong his service is; ‘vetting’ it indeed hard, but you don't need hard proof to fight endemic corruption.

> no open IP logging taking place (IP addresses associated with submissions are stored in the DB in an encrypted format).

Given how small the IP space is, does that actually add anything?

With a random IV and CBC, is it actually not secure? Assuming you have the encrypted entries, and can even create more on-demand, what can you do besides brute force the key? Plus, almost any 4-byte result is a valid result.

I'm not sure, but OP didn't mention using random IVs or CBC.

Try instituting an expiration policy on your logs. Have addresses expire after some set amount of time. It might be a few hours, days, or weeks - whatever you determine to be the necessary time to prevent abuse.

Regarding the IP addresses, we use bcrypt algorithm, obviously with salt, to obfuscate IPs and since we're hosted in Germany, gettings hands on these entries the legal way is a long process.

To address the problem of spam, we have already implemented a combination of selective captchas and Akismet filter running in the background.

We also use name entity extraction algorithm to obfuscate any names we identify in the submitted reports. It takes a couple of minutes and is not 100% proof, but at least reduces the risk of names being called.

The major problem that we are thinking about, however, is how do we structure the "vetting", given that reports are sometimes hard to verify without first hand knowledge of situation.

So far we tried to analyze how one goes about these things in real life and recreate natural constraints in the virtual space. The fact that we require every report to be geo-tagged works to our advantage in this situation.

As a practical example, ordinary people usually do not have access to president's palace, so if someone claims to be paying a petty bribe there, it is obviously a fake and we would automatically suspend such report.

The real way to solve this problem is to make it distributed so that everyone can contribute and anyone can read all of the posts from a single node. Then there is no single way to get a list of IP addresses

There is network called Freenet just for this purpose.

When you're dealing with bribery, you can't prevent blackmailing/fake reports at all.

What you can do, though, is to provide HTTP, HTTPS and TOR access to your webservice to allow everyone to submit stuff at his/her own security choice.

If possible, change your IP address(es) and domain names on random intervals; you can use free domains like .de.vu and friends to have reliable "entry points" (an example is canna.cu.to).

If you have an android app anyway, try building a "distributed" service like BitTorrent or Bitcoin for information exchange.

Having spent some time interviewing typical users I can say that this would work only if we put the distributed service bits under the hood, while leaving service with all the trappings of a normal website.

Regular users often times find it difficult to use regular apps, not to mention things like TOR access. And since we want as many users as possible being able to use it, we cannot just waive them off saying "go learn Internet" :)

It seems to me, that for your particular problem domain, the solution is simply to be hosted in a country that is unlikely to serve you a subpeona for the kind of information you're dealing with - ie. most western European countries and the US. Iceland seems to be on a data protection binge lately. You "no names" policy further protects you in this regard.

Here is some tutorial about how to run Tor's Onion hidden service inside Linux VPS: http://torforum.org/viewtopic.php?f=5&t=18268

Both you and your visitors will always stay anonymous. Not your hoster nor their ISP's will never have a chance to reveal someones identity.

Possibly relevant. I wrote this few months ago regarding some of the challenges with crowdsourcing crime reporting in the Mexican Drug War: http://readwrite.com/2012/08/14/the-problem-with-crowdsourci...