- Botnet operations are hacked PCs. They aren't paying for CPU time.
- Low-rent spammers often use hacked or rented servers. They aren't paying for CPU time.
- Even I don't pay for CPU load on my VPS.
This won't stop spam. Simple as that. You might get money from this but you're also going to keep getting spam. Oh and you'll chronically annoy everybody on a slow computer who doesn't want to wait.
Compare it to this $0.70/1000 for CAPTCHAs. That's really expensive because it's real money. It also takes time. It also doesn't guarantee posting (many sites have secondary spam-detection features) which might mean 90% are insta-deleted, 5% are held for moderation and only 5% make it through. $0.014/post is actually pretty expensive. Much more than they're spending to get past you.
Botnets may not have a marginal cost, but they still have a limited supply, and a demand for their use, which determined the cost to consumers. If they are less effective per time on spamming, either the cost of spamming will increase, or botnet operators will shift into other more profitable verticals.
So the user enters the CAPTCHA, then some other botted computer enters it in the real webform.
Basically these types of measures are stupid because any virused computer can be made to do them anyway this is why CAPTCHAs are only 70 cents / 1000, it isn't because people in India are lining up to enter CAPTCHAs at an Indian minimum wage.
At the very least, you can replace all ads on the Web with ads you make money from. And/or you could phish users and steal e-mail/bank passwords. And/or you could replace binaries the user tries to download with malicious ones.
And so on. I suspect captchas are pretty far down on the list of things you'd do if you had this capability. :)
There's still an opportunity cost. Would they prefer to hit a service which limits their machines to a few thousand attempts per day, or a service which does not and lets them put through several million attempts per day?
> Even I don't pay for CPU load on my VPS.
Perhaps not, but it sets a hard limit on how much you can do in a given time period.
> That's really expensive because it's real money.
If they're stealing computer time via a botnet, they're probably not going to be paying Amazon Turk with their own credit card.
This could be used by those downloader sites that make users wait.
Why is that a good thing?
Showing a captcha each time, for a repetitive task would be a horrible UX decision.
Letting my mind go wild and wondering whether it would make sense to let visitors actually pay for the login. This could be DOGE-Coins for example. One could set up a DOGE-faucet and give back the WOWness.
Is that idea totally dumb or does it make any sense?
Would love to read your opinion.
That means that even if you scale the work to take at most 10 seconds on the client machine, you'll be able to crack 1/s on a $5/mo on digitalocean. That's ~2.6M answers a month. That's $0.002 per 1000 captchas, instead of $0.70 mentioned on the website and as a bonus it removes the part where you rely on people who could mistype things.
I really want it to work, but does the economic balance actually work here against the spammers or for them?
If you don't want to annoy your visitors you're going to need to have the max runtime on any device at around 25 seconds.
Now you can't scale this per device, because you can't rule out devices spoofing what they are. So this means you're looking at barely a few seconds to break it on any sort of desktop hardware, and even less on any dedicated server.
Spammers are probably waiting longer than that to just load the page they want to spam, so it wont slow them down. For this to work you need to solve this issue, and I hope you can, but I don't see how.
Regarding feasibility & cost, what do you think of the old '"Proof-of-Work" Proves Not to Work' paper?  From what I remember, the time to hash adequately would be too long to be of practical use/benefit.
And you remove CAPTCHA :)
Even if you reduced the proof of work from 30 seconds to two seconds, that's negligible to the user when submitting a form, but limits a computer to performing a mere 42,200 signups per day, which is several orders of magnitude better than the 1.6 million figure above.
And nothing says you can't also implement rate limiting per IP, which is frankly not terribly useful when facing botnets.
Most generic spammers (wordpress/mediawiki pharma spammers) post 1-100 messages and then move on to the next site. If someone wanted to specifically target your site, they would use a botnet or write a GPU proof-of-work solver.
You're also right about IP rate limiting not being useful against botnets, but neither is this. For pretty much the same exact reason. Each machine in a botnet comes with a unique IP address, but also 2 or more CPU cores.
Just use a CAPTCHA. CAPTCHAs aren't the problem. The way we use them is. Don't show CAPTCHAs to every user. Ask some questions first. Is there something unusual about this user? Is there something unusual about the user's browser? Location? Is the user doing something unusual? Show them a CAPTCHA. Those "surprise" CAPTCHAs are less annoying to the real user and more frustrating to the spammer, since unpredictable behaviour makes testing their scripts harder. There's a reason why Facebook and Google do this.
A much more exciting development in the field of bot/spam detection is verifying the integrity of the user's browser by comparing the exposed functionality (HTML5 and JS) and quirks to the ones expected for its user-agent header. I believe this is the method that Dan Kaminsky's "White Ops" startup uses.
Adding a delay that costs computing power will both slow down and add real costs to spammers (though if it's a bot net they'll not care about the latter).
I really dislike how impossible CAPTCHAs have become, and the slew of startups working on advertising based ones is not the solution the users want.
As a user, all I want is ease. I'm fine waiting a few seconds... just don't give me an impossible task to perform or use the inconvenience you've created as an opportunity to advertise. All I want is to do whatever I wanted to do, read, write... I can wait a moment, just don't make it painful.
Also, even if they are paying for it, the "proof of work" is probably less expensive as captcha breaking.
What I'd really like to see is a more sites that do analysis to block bots, rather than annoying users. Spammers generally need to place a link and do so quickly. It seems much easier to target people who post links in their first 5-10 posts than to do anything else.
The issue I encountered was a miniscule rate of return on the JS-based mining. Do you think that if HashCash integrates with BitCoin for monetization/mining purposes, JS speed will be a limiting factor?
Right now there is no payouts to webmasters, but this is next feature I am working on. It will be made directly to webmaster dogecoin address from p2pool I am running for this project.
I've been trying to get Hamiyoca's JS miner to work with mupool without much success. (Stratum is straitforward. I'm just dumb.) p2pool is way easier from the cursory glance I've given it. I'm surprised I hadn't heard of it before.
Any chance I could trouble you for an invite for jo.jcat at gmail? I'm already using proof-of-work to keep spam off my blog (josephcatrambone.com), but I wouldn't mind switching early to something more conducive. Hell, if the payouts are nonzero when they roll around, I might be able to strip the ads. Alternatively, what's the official way to request an invite? Sign up for the news letter and wait?
I will definitely email invite codes to everyone once it is ready to go.
Have you done tests on many platforms to show which ones are supported?
I'd probably like it to be more automatic... a single clickable progress bar without the need for the 2 text fields or generate button.
But yeah... this is ace.
Pretty sure this code is vulnerable to local file inclusion. Running file_get_contents on unchecked user input is a terrible idea, even more so coming from a "security solution".
if(strspn($_REQUEST['hashcashid'], 'abcdef0123456789-') !=
The work was defined as: Given the following salt, construct a payload such that a md5 hash of the salt and payload would result in a hash with n consecutive 0's.
Simple to implement on both ends, and fast enough to not impede much in the user experience but still expensive enough to limit spam. And it becomes easy to increase the work proof required - just increment 'n'.
I always wanted to go back and put in a TOTP seed and properly productize it to make it easier to use, but I never made the time. It makes me happy to see someone take it seriously, and build a proper version for modern browsers.
The problem is that a native implementation is an order of magnitude faster than the best JS interpreter, and it can be 2 or 3 orders faster than an old browser, or on mobile. It would leave IE7 hanging actually.
I concluded that the only way to use a proof of work system effectively would be native crypto primitives in the browser itself.
Another way we explored was making a very simple challenge (not computationally intensive), that yet you can only realistically solve with a JS interpreter. The goal shifted to "spend cpu time", to "raise the difficulty of programming a bot".
I know there are lots of ways to include a decent JS interpreter in a headless program, but it seems this hasn't caught on with bot makers yet.
Here's more info about my browser: http://aboutbrowser.com/view/JRv4J
I don't see any reason why this needs a third party, although I do grant that makes it easy to use.
This way you don't need to buy API credits or stuff like that, login and billing are somewhat conflated.
Maybe someone with better knowledge of Bitcoin can comment on the feasibility.
The computers can't solve the business need, but they are certainly right often enough to get some spam comments posted (because their cost of being wrong is zero.)
This is probably not a great user experience (getting banned because someone above you invited a bunch of spammers), but I think it's conceptually interesting to distribute the anti-spam onus to the users of the community instead of the administration in a form other than 'report spam'.
Just having an invite-only system should solve the problem equally as effectively (although it creates its own issues with politics, groupthink, etc.)
They're definitely onto something though.
Checkout jQuery plugin github repository for details on available options.