What's the thinking behind implementing captcha? I really, really hate ReCaptcha. For most sites the payoff to a spammer isn't really worth even the simplest robot test. A new site that throws ReCaptcha is an instant bounce.
>What's the thinking behind implementing captcha? I really, really hate ReCaptcha.
It might be useful if it only shows up on the login/signup page after failed attempts, but it might also be overkill. Personally, I prefer overt solutions to opaque ones like shadowbanning and throttling IPs. But mostly it seemed like a good way to figure out some basics (managing keys, how the app server manages the form loop, API responses and JSON.)
I could finish the test I have, push that and leave integration for later.
I agree with overt vs shadowbanning. My tendency is to just add tools for moderation. Let bots sign up and spam, but make it easy to take them down and ban them at that point. Arc is reasonably decent there.
Sorry, my comment was rather lazy. Let me try again.
I get the impression many of the people who want to start a HN like clone are considering using it as a content delivery platform. For example http://arclanguage.org/item?id=20452 notes a revenue sharing model for specialized content. Now, if that's the case these site owners will have both spammers and content scrapers to contend with. So my initial comment was also referring content scrapers too.
However there's another thing to consider: Session storage costs. About 6 months ago I went through a process to reduce the cost of data held in memory for session storage (redis in this case). The session data was continually analyzed for determining both who the bad users were and for knowing what value the good users are getting out of the app (feature planning etc). It was an interesting process, where just by reshaping the session data, thousands of dollars per month could be saved in db fees. Now I realize the someone starting a HN clone is probably not dealing with that, but I'd be willing to bet that part of the reason Captcha was implemented in HN proper was to reduce fees associated with the volume of requests, session costs and even network load. It's my feeling that, generically speaking, adding captcha functionality is a good Option to have.
> I'd be willing to bet that part of the reason Captcha was implemented in HN proper was to reduce fees associated with the volume of requests, session costs and even network load.
Let me add some info to that.... I'm not sure if anyone noticed, but HN has implemented new session management strategies. You can see this as your login is now maintained across multiple devices, where the arc code (that we have access to) logs you out upon logging in elsewhere. I also believe that when pg handed over the HN code significant changes occurred including how session data is stored and how that data is utilized to integrate with cloudflare. Obviously I'm making big guesses, because I don't have access to the code, but I'm willing to bet the changes HN has put in place would surprise everyone here.
Sadly everyone who sees HN today will come here and look for the source code not realizing what's available here is not modern nor comparable.
>Sadly everyone who sees HN today will come here and look for the source code not realizing what's available here is not modern nor comparable.
One thing I noticed when Arc gets brought up on HN is that everyone seems interested in the language but not so much the application. People seem to cargo-cult the forum for some reason.
> For most sites the payoff to a spammer isn't really worth even the simplest robot test.
Maybe I am missing something.... Isn't captcha just a fairly simple robot test (and thus preventing spam)? Or are you suggesting something even simpler? Because I've run a few sites and had tried implementing very simple programmatic obstacles and it really didn't stop the spammers.
Maybe the better question is - what would you suggest?
Simple captchas are totally fine. My problem is with Google's ReCaptcha in particular, where the problems have gotten so difficult that I mostly can't prove I'm a human.
Hmm... That's not my experience. 90% of ReCaptcha tests are invisible if not a simple checkbox. Only a small optional subset requires introducing a problem solver.
One time I spent a good 20 minutes identifying cars, signs, and storefronts before it would let me in, and that was with no VPN or Tor or anything. At some point they oughta be paying us. :-p
This is probably going to sound super crazy, but I have to say it...
I know you (akkartik) have a google account, because I remember when you moved your blog over to google's services (I think they call it 'circles' or some such). I also remember you created a news aggregator application that scraped content. Yes, I know, it was a long time ago in a galaxy far, far away..., but still...
I'm thinking that google identified your scraping work and deemed you a risky robot type, but they also probably correlated your IP from the scraping to your IP from your google services login and tagged you that way. So now, even if your IP changed, they'll continue to have you in their cross-hairs for, like, ever.
Any takers? If you'd like I can also look into who killed JFK...
a) My cookie acceptance policies are non-standard. (I no longer even remember what they are anymore.)
b) I'm often behind a VPN for work.
c) I'm often on my phone, or tethering from my phone.
Complaints about ReCaptcha are fairly common if you look on HN and so on. You don't have to have run a scraper to hit it, I don't think. I think you may be a robot from the future for never having problems with the pictures of signs and cars :p
Final minor correction: I've played with Google+ in the past (I actually worked at Google on Circles for a year) but I never moved my blog there. I just linked to my blog posts from there.
> Complaints about ReCaptcha are fairly common if you look on HN and so on.
Yeah I'm aware of the complaints, but in my mind HN wouldn't be the best resource of information for such an assessment. By default HN members are non-standard in most ways that would matter to ReCaptcha.
It's an interesting dilemma and one that I'm coming up on soon as I plan to release a new app in a few months time. In my case the intended audience for the app is very widespread and not specific to a tech audience. It could be that the vast majority of my users (if I get any - lol) would never have a problem, because the vast majority of people using the net don't know what a VPN is or how to change a cookie setting (just as examples).
I'll have to give it some more thought, but in the mean time, are you aware of any resources on the matter that would be more reflective than HN?
edit: I often find info like this [1]:
"Different studies conducted by Stanford University, Webnographer and
Animoto, showed that there is an approximately 15% abandonment rate when the
users are faced with CAPTCHA challenge."
But really I do expect to take some loss when using reCaptcha. The question really becomes is it worth it? After all spam can also cause users to leave and content scrapers can also de-value your product.
Certainly, it's an issue only tech-savvy people will have.
However, every step you put users through is a place where your funnel will leak. So in your place I wouldn't turn on captcha until I actually see spam being a problem.
Also, independently, since I am personally ill-disposed towards ReCaptcha I have zero urge to help maintain it in Anarki :) You're welcome to hack on it, though!
I think it's less important to have Recaptcha or not than it is to have a working POC for interaction with a remote JSON API, and for parsing JSON in general, since that opens up a lot of possibilities. Recaptcha itself is just the low-hanging fruit for that, since it's so simple.
As far as integration goes, we could just leave it up to whomever wants to do the work or make it easily configurable with the default being not to use it at all.
It's great to see a JSON API integrated in Arc. :)
I took a look and found fixes for the unit tests. Before I got into that debugging though, I noticed some problems with the JSON library that I'm not sure what to do with. It turns out those are unrelated to the test failures.
The JSON solution is a quick and dirty hack by a rank noob, and I'm sure something better will come along.
And in hindsight the problem with the (body) macro should probably have been obvious, considering HTML tables are built using (tab) and not (table). I'm starting to think everything other than (tag) should be done away with to avoid the issue in principle, but that would be a major undertaking and probably mostly just bikeshedding.
