Re: reCAPTCHA: audio alternatives and audio formats

On Tue, 17 Jul 2007 18:10:11 +0100, Ben Maurer <bmaurer@andrew.cmu.edu>  
wrote:

> Hey,
>
> On Tue, 17 Jul 2007, Gregory J. Rosmaita wrote:
>
>> aloha, all!
>>
>> concerning the cascade of aural CAPTCHA equivalents, i have pondered
>> the issue of baseline audio formats for quite some time, but can't
>> find the post i was preparing on the topic, so i'll just simply ask:
>> what is the cascade order for aural filetypes in the real world
>> today?
>>
>>   .ogg
>>   .mp3
>>   .au
>
> AFAIK, no brwoser has support for a cascade like this. Doesn't make that  
> topic somewhat moot.

The following works fine in Opera (i.e. according to the HTML spec). But  
it fails in safari. I don't know what other browsers do:

<object type="audio/unknown"  
data="http://mpegmedia.abc.net.au/local/some.ogg">
   <object type="audio/mp3"  
data="http://mpegmedia.abc.net.au/local/melbourne/faine_m1401278.Mp3">
     <p>FAIL</p>
   </object>
</object>

> .wav would be a good baseline. We initially considered serving up .wav  
> reCAPTCHAs, however:
>
> 1. Bandwidth was potentially prohibitive (25 KB mp3 vs 250 KB wav)
> 2. Disk space was also prohibitive
> 3. mp3 was universal enough for us.

Support for mp3 is probably as broad as support for any other format.

>> 4) are .mp3 files capable of being played using the user agent or
>> operating system's default sound renderer?
>
> AFAIK, all audio files are played by browsers with support of plugins.  
> Ogg, mp3 and wav are equal in this sense.

Not necessarily. Due primarily to non-technical issues, browsers are  
moving towards including native players - and there is more motivation for  
some formats than others. At the moment, however, to a first approximation  
audio is played with plugins.

>> has any thought gone into serving up pure sounds (dog bark, duck quack,
>> train whistle) to defeat the voice-recognition?  this would involve a
>> quick lookup for the appropriate answer in lang="x" or, through
>> content negotiation serve up a version of the CAPTCHA that corresponds
>> to the requesting user agent's language preferences, which would make
>> the verification look-up faster...
>
> Some issues here:
>
> - WE would still need quite a bit of distortion & background noise
> - There are multiple answers (dog barking -- bark, dog, dog bark, woof)
> - If multi-word answers are used, segmentation of the answers becomes  
> hard.
> - Much harder to translate
> - Need to do spelling correction
> - Requires better understanding of language at hand
> - Need to acquire a large number of sounds.

Actually, taking a handful of sounds, and asking a multiple-choice  
question would mean you need a handful of sounds. Alternatively you could  
tell people to write one of "horse", "steam train", "cat", "motor-bike",  
"person".

(Since two multiple choice questions with 5 answers each takes people  
about 30 seconds or so to fill in, and only gives 95% protection. Three  
questions goes to better than 99%, but starts to get annoying as a user).

So I guess that putting a bit more thought to the idea might suggest ways  
it can be done cheaply. But as Al said, CAPTCHA is just an arms race, and  
people are destined to lose. Expecting anything to survive popular  
adoption is a mistake. The best CAPTCHA isn't the strongest one, just the  
one that is so unusual nobody bothers writing an automated solution. And  
there are strategies that can be used to co-opt people into cracking a  
CAPTCHA that was previously unrecognised.

Cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com    Catch up: Speed Dial   http://opera.com

Received on Wednesday, 18 July 2007 05:54:57 UTC