With accounts it is no problem, we can just make them enter a captcha when registering and assume they're human from now on.
However where an IP contributor enters a captcha, we can't assume it's human because IPs are often shared. There is lots of past discussion on distinguishing between IP users and authenticating them in some way, but they all hit various low ceilings (enter private browsing mode, etc) and the conclusion was to continue treating them as group of people, while we always have to allow for one of them being a spam bot. Therefore I can't see how to implement your suggestion without piping all logged out contributors into the "mice" pile. This is unacceptable.
--
svetlana
On Thu, 4 Dec 2014, at 15:35, Robert Rohde wrote:
> We have many smart people, and undoubtedly we could design a better captcha.
>
> However, no matter how smart the mousetrap, as long as you leave it strewn
> around the doors and hallways, well-meaning people are going to trip over
> it.
>
> I would support removing the captcha from generic entry points, like the
> account registration page, where we know many harmless people are
> encountering it.
>
> However, captchas might be useful if used in conjunction with simple
> behavioral analysis, such as rate limiters. For example, if an IP is
> creating a lot of accounts or editing at a high rate of speed, those are
> bad signs. Adding the same external link to multiple pages is often a very
> bad sign. However, adding a link to the NYTimes or CNN or an academic
> journal is probably fine. With that in mind, I would also eliminate the
> external link captcha in most cases where a link has only been added once
> and try to be more intelligent about which sites trigger it otherwise.
>
> Basically, I'd advocate a strategy of adding a few heuristics to try and
> figure out who the mice are before putting the mousetraps in front of
> them. Of course, the biggest rats will still break the captcha and get
> through, but that is already true. Though reducing the prevalence of the
> captcha may increase the volume of spam by some small measure, I think it
> is more important that we stop erecting so many hurdles to new editors.
>
> -Robert Rohde
>
> On Wed, Dec 3, 2014 at 3:08 PM, Ryan Kaldari
rkaldari@wikimedia.org wrote:
>
> > The main reason our captcha is easy for bots to bypass isn't because it's
> > easy to read (it's not); it's because it works the same way as 90% of other
> > captcha's on the internet. So if you're a spam-bot writer, all you have to
> > do is download one of the dozens of generic captcha-breaking programs on
> > the internet and point it at Wikipedia. I imagine about half of them would
> > be able to break our captcha out of the box. We could deter the majority of
> > spam-bots just by having a unique type of captcha. And it doesn't have to
> > be one that is difficult for humans to solve, just one that would require a
> > halfway significant investment for a programmer to solve. In other words, I
> > don't think that making our captcha easier necessarily means getting more
> > spambots. We just have to jump out of the existing captcha design
> > band-wagon. Here are some ideas:
> >
> > 1. Show an animated GIF of a scrolling marquee that reveals a word
> > 2. Show an animated GIF that sequentially unblurs the letters in the
> > captcha (from an initially totally blurred state) and then reblurs them in
> > a cycle
> > 3. Show three words in different shades of grey and ask the user to type
> > the darkest word (too trivial?)
> >
> > Surely we can come up with a creative idea that is:
> > * Easy for humans to solve
> > * Can't be solved by out-of-the-box captcha breakers
> > * Isn't trivial for programmers to solve
> >
> > Kaldari
> >
> > On Wed, Dec 3, 2014 at 1:53 PM, Chad
innocentkiller@gmail.com wrote:
> >
> > > On Wed Dec 03 2014 at 1:27:33 PM svetlana
svetlana@fastmail.com.au
> > > wrote:
> > >
> > > > I like these thoughts:
> > > > -
https://lists.wikimedia.org/pipermail/wikitech-l/2014-
> > > > November/079340.html "Literally an anti-captcha. Letting bots in and
> > > > keeping humans out."
> > > > -
https://lists.wikimedia.org/pipermail/wikitech-l/2014-
> > > > November/079346.html "Why not disable the ConfirmEdit extension for a
> > > > week and see what happens?"
> > > >
> > > > Shoulw we go to a wiki and see if we can gain local consensus on such
> > > > move? Which wiki would be better, a bigger one or a smaller one, for a
> > > > start?
> > > >
> > > >
> > > mw.org? Find one or two other devs and you've got consensus :)
> > >
> > > -Chad
> > > _______________________________________________
> > > Wikitech-l mailing list
> > > Wikitech-l@lists.wikimedia.org
> > >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> > >
> > _______________________________________________
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> >
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l