[Bug 32125] Should support auth using captcha

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32125

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cmaiku at gmail.com

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-01-25 09:11:05 PST ---
Maiku and I have been looking at this a bit recently. In principle it shouldn't
be rocket science: we can have a CaptchaAuthentication interface which looks a
lot like SASLAuthentication. In practice, it gets a bit more complicated.

Background
----------

Known users of captchas include:

* MXit, when you connect (possibly just the first time) -
  this can just be ServerAuthentication

* XMPP, whenever it wants to (but most popularly, when you message someone
  or join a MUC) - this would need a new channel type

MXit just sends a simple captcha image (the common "enter the text you see"
sort). This is easy to represent on D-Bus, but impossible to answer if you're
blind or partially sighted; but that's MXit's problem, not ours.

In the XMPP world, captchas are XEP-0158, which is... elaborate. I think it's
safe to say that it's a superset of anything any other protocol will do. The
server can ask you to solve any of:

* ocr: the common "enter the text" sort
* qa: answer an arbitrary ASCII question
* audio_recog: identify a sound
* picture_q: answer the question in an image
* picture_recog: identify an image
* speech_q: answer the question in a sound
* speech_recog: enter the words in a sound
* video_q: answer the question in a video
* video_recog: enter the words in a video
* SHA-256: HashCash (carry out some computation)

Further, it can require that you solve at least n of those, and it can make
some of them mandatory.

SHA-256 is easy: Gabble can do it on your behalf, remove it from the list and
decrement the number remaining to solve. The rest (if any) would need to be
passed to a UI to be answered.

All except "SHA-256" and "qa" come with one or more alternative versions of a
data payload (e.g. audio_recog might be offered as both audio/x-wav and
audio/speex), which can be in-band via XEP-0014, or out-of-band via any URI
(typically HTTP).

As far as I've been able to tell, real implementations of XEP-0158 (in ejabberd
and an unofficial prosody plugin) only use "ocr", so they're just as easy to
spec (and just as bad for blind/partially-sighted users!) as MXit.

Implementations of captchas on the web tend to consist of either OCR only (the
same as MXit), or OCR + one of the audio-based things, where you can solve
either.

Spec
----

There are basically two and a half ways to spec this.

One way is to design an interface modelling what MXit does: one "ocr" puzzle,
which is mandatory. On the one hand, this is easy to spec (I believe Maiku has
a sketch of a spec already), and supports the most common form of captcha. On
the other hand, it can only support protocols which are inaccessible to
partially sighted users, even if those protocols later implement better
captchas, which seems pretty rubbish.

A second way is to design an interface which is basically XEP-0158, and assume
that all practical protocols are going to be some subset of that.

The "and a half" is to present the "ocr" puzzle, but have an extension point
for a UI to request further options: a simple UI which doesn't care about
partially sighted users could just present the "ocr" puzzle. This assumes that
nobody is ever going to deploy a captcha-style system where you have to solve
more than one captcha (which XEP-0158 allows for!), or a system where none of
the puzzles are "ocr".

Implementing for MXit
---------------------

Having a spec won't be sufficient to implement this in Haze for MXit: we'll
also need to enhance libpurple so it can present the captcha in a
machine-readable way (probably something remarkably similar to the Telepathy
API), and only if the UI doesn't handle that, fall back to the current "pop up
a dialog" (which Telepathy doesn't and can't implement, because the UI and the
CM are separate).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.