4 ms·
As someone with experience in both implementing and bypassing spam protection, this idea makes no sense to me. Let's say it takes the user 30 seconds to calcula
by vomitcuddle 12y ago
As someone with experience in both implementing and bypassing spam protection, this idea makes no sense to me. Let's say it takes the user 30 seconds to calculate proof-of-work. 30 seconds per sign up (at effectively no cost) is quite good compared to current solutions spammers use to bypass CAPTCHAs - third-world sweatshops with people solving CAPTCHAs for <$1/hour. What's stopping a spammer from implementing your algorithm in more efficient C? Still assuming the algorithm takes ~30 seconds, all this does is limit the user/spammer to 172,800 sign-ups per CPU core per day, making it (much) less effective than rate-limiting sign-ups coming from the same IP address. Increasing the difficulty of the proof-of-work would just frustrate real users and make them leave your page for a competitor. I know cryptocurrencies are hip and all, but the problem space for proof-of-work algorithms is much smaller than some people here seem to think.
- vomitcuddle 12y agoEffectively, this achieves the complete opposite of what CAPTCHA does. It's a test that only computers can solve. 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.
- falcolas 12y ago172,800 signups per cpu core per day seems... off. Since there are only 84,400 seconds per day, wouldn't that be 2,880 signups per core per day? Doesn't seem terribly profitable. Particularly when compared to, say, 20 signups per core per second with no proof of work (~1.6 million per core per day). 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.
- danbruc 12y ago86,400
- falcolas 12y agoWhelp, that's embarrassing. 86,400 is indeed the correct number of seconds per day.
- vomitcuddle 12y agoOops. You're right. I got my numbers wrong, but my point still stands. Unless your goal is denial of service (which this does nothing against), you don't need to make more than 2,880 requests a day. 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.
- bitJericho 12y agoIf I made cash money everytime a bot solved a problem I'd be elated that he chose to attack me. It means I can spend my time or hire someone to moderate/delete the crap and get paid for it too.
- hippich 12y agoThis is next step - implement Dogecoin payments directly to site owner. How much it will generate tho - not sure yet.
- thrwf34f33 12y agoOn few of my sites running drupal and which had ALOT of bogus registrations and comments, all spam was stopped. So far it works. Different story once it get big enough to warrant specific implementation, but we are not there yet.