[Mailman-Developers] UI for Mailman 3.0 update

Stephen J. Turnbull stephen at xemacs.org
Wed Jun 16 06:03:20 CEST 2010

Cristóbal Palmer writes:

 > While I could in theory maintain a patch, I have a lot of machines to
 > herd, and I am unlikely to customize anything unless I must do so in
 > order to meet a requirement.

This is a straw man in the context of the Mailman pipelined
architecture and the CheeseShop.

 > While I share your distaste for bad implementations of... anything,
 > really, CAPTCHAs do not annoy me unless they are poorly implemented,
 > and they do not have to be poorly implemented.

Show me some well-implemented CAPTCHAs.  Maybe I don't have to avoid
them any more.  However, the ones I have seen recently are no better
than the ones I was seeing 3 or 4 years ago, and they still involve
extra clicks, extra typing, and eyestrain.  For blog comments, a
CAPTCHA invariably means I'll move on.

I'd also like to see evidence that CAPTCHAs work better than other
efforts at confusing the attacker.
-------------- next part --------------

 > M Motoyama, K Levchenko, C Kanich, D McCoy, GM. Re:
 > CAPTCHAs~Understanding CAPTCHA-Solving Services in an Economic
 > Context. Proceedings of the USENIX Security Symposium, Washington,
 > D.C., August 2010. http://cseweb.ucsd.edu/~savage/papers/UsenixSec10.pdf
 > Reverse Turing tests, or CAPTCHAs, have become an ubiquitous defense
 > used to protect open Web resources from being exploited at scale. An
 > effective CAPTCHA resists existing mechanistic software solving, yet
 > can be solved with high probability by a human being. In response, a
 > robust solving ecosystem has emerged, reselling both automated solving
 > technology and real-time human labor to bypass these
 > protections. Thus, CAPTCHAs can increasingly be understood and
 > evaluated in purely economic terms; the market price of a solution vs
 > the monetizable value of the asset being protected. We examine the
 > market-side of this question in depth, analyzing the behavior and
 > dynamics of CAPTCHA-solving service providers, their price
 > performance, and the underlying labor markets driving this economy.

Heck, I could have written that paper.

 > So I'm going to disagree with your premise that CAPTCHAs are
 > necessarily annoying to most people unless you give more than
 > anecdotal evidence that that is the case,

There are plenty of studies showing that every extra click is costly.
What I mean by "annoying" is "increases the probability of an exit
click vs. staying on this site".

 > and I'm going to disagree that they are always or even usually
 > useless for protecting parts of WUIs.

The question is "what are they protecting?"  My claim is that if
you're protecting economic resources (bandwidth, accurate counts of
real users) they may be more or less useful.  If it's a security issue
-- including ways of harvesting email addresses that involve
subscribing -- though, you're busted.

 > > (2) it should need to be enabled by the site admin (and off by
 > >     default);
 > Agreed, but only to the extent that having it available by default
 > would add a dependency, which is too much of a burden on the MM team.

Mailman should clearly not provide any CAPTCHA implementation itself,
given your claims of rapid progress in the field.

 > > (3) both configuration tools should have documentation indicating that
 > >     captchas do not provide security; what they do is chase off the
 > >     frivolous (both bona fide users and would-be abusers).  This is a
 > >     genuine benefit in several ways for many lists; it's just not real
 > >     security because serious abusers will get through.
 > Disagree. This is like saying that putting a $30 (USD) cable lock on
 > my bike is not security because serious thieves could defeat it with a
 > large pair of bolt cutters.

Yes, exactly.  My point is that you and I understand defense in depth
and the economic aspects of security; most people think in terms of
privacy leaks or hacking the financial system, which is far more
severe than the loss of a bicycle.

 > Mind you, I use a ~$100 (USD) chain lock on my bikes, but that
 > doesn't mean the $30 (USD) cable lock is useless,

It is where I live.  My $25 USD (1982 prices) Kryptonite lock is still
in service, and I have never lost a bike when using it.  I did lose a
$150 bike with a 4000 yen (1993 prices, ~$30) chain lock on it, in
less than 4 months, though.

 > You seem to think that only $100 (USD) chain locks are worth the
 > effort,

In fact, for the bike lock, I do.  A good bike lock lasts forever
(unless the thieves take the whole bike rack, nothing's perfect ;-).
Unless you know your bike-riding life will last less than a year,
there's no real point in buying less than than best bike lock
available.  Note how much knowledge and planning is required to make a
good decision here!  Computers are even harder....

This is not true for computer network services, however, where the
stakes are higher and defense in depth is necessary.

 > and that I'm insisting people use cheap locks.

No, that's not my claim.  My claim is that it is unethical to make
weak locks available for free, without explaining to people their
correct use.

 > What I want is the ability to flip a switch and have CAPTCHAs
 > available to me, and then have switches in one or more places
 > (eg. moderator login, user signup) for those CAPTCHAs to be used every
 > time or after the Nth attempt, for example.
 > As I said before, there are several non-CAPTCHA approaches that I'd
 > like to see used by default, too. For example, forcing signups to
 > include a NONCE, rate limiting signups, etc. I don't want to get too
 > hung up on CAPTCHAs in particular, but I also don't want us to
 > completely reject them, since they are in fact useful and good if used
 > properly. I'm very sorry you dislike them so much and have had bad
 > experiences with them, but please let's have a more scientific
 > discussion of the merits of CAPTCHAs.

The first thing I want to see, then, is documentation that CAPTCHAs
are more effective than other methods of confusing the dumb 'bots.

More information about the Mailman-Developers mailing list