Re: Web User Verification Screens

  • From: Chris Hofstader <cdh@xxxxxxxxxxxxx>
  • To: programmingblind@xxxxxxxxxxxxx
  • Date: Tue, 17 Aug 2010 12:11:37 -0400

Of course, inverse grade 2 that only uses contractions would be another good 
cipher that a bot looking for some relatively "normal" range of ASCII or code 
page based characters and these would find a spot in these tables but be 
entirely wrong when the translation is performed by the bot. The encoded G2 
braille could be a pointer to anther place on the screen entirely where a phone 
number missing digits or something may reside.

Hiding in plain site is often the best disguise. The bots will overcomplicate 
things as that's what they think the security dude did; simple inversions and 
offsets should work great.

Ask Vanderheiden how his works, it couldn't be simpler and and it works great 
but not for people with hearing problems.

cdh


On Aug 17, 2010, at 11:15 AM, Peter Donahue wrote:

> Hello,
> 
>    If we can develop cars drivable by the blind, put men on the moon for 
> God sakes we should be able to find ways to make captcha data available 
> while hiding it from spam bots. Furthermore I'd like to see solid research 
> on the subject to see how many of this spam bot crap is real and how much is 
> myth! I would strongly urge you to develop a captcha solving solution that 
> works for those with limited hearing or are deaf-blind and quit making 
> excuses of why it's impossible to do so. The next thing I wish to hear from 
> you is how you achieved this and not why it can't be done. Otherwise you 
> picked a fight with the wrong hearing-impaired user. Now get it done!
> 
> Peter Donahue
> 
> From: "E.J. Zufelt" <lists@xxxxxxxxx>
> To: <programmingblind@xxxxxxxxxxxxx>
> Sent: Tuesday, August 17, 2010 10:06 AM
> Subject: Re: Web User Verification Screens
> 
> 
> Good morning Peter,
> 
> This is not as easy as it may seem.
> 
> The purpose of these scripts is to deter automated systems from being able 
> to successfully pass the challenge.  embedding information about the 
> solution to the challenge within the page is not a successful means of 
> ensuring that automated systems cannot pass the challenge.
> 
> There are some things that can be attempted.
> 
> Question / answer challenges.  Although these are not really a CAPTCHA, 
> since they are not "completely automated", they can be solved more easily by 
> some users than standard visual / audio challenges.  I have some anecdotal 
> data that shows that these styles of CAPTCHA are more easily solved by 
> automated systems than visual and audio CAPTCHAs.
> 
> Another method is to provide a contact link where users can request to have 
> their accounts exempt from the challenge.  This as well can be problematic. 
> For starters this is not a real time solution to the problem, users have to 
> wait to receive a response, sould they ever receive one at all.  Secondly, 
> this may not be possible on sites where users are not authenticated with 
> credentials, such as the CAPTCHAs required on some sites to expose e-mail 
> address or to send contact forms.
> 
> This is a complicated problem with non-trivial solutions.  I think that the 
> most important, by far, factor to consider when contacting an organization 
> about the CAPTCHA on their site is to allow them to know that you fully 
> recognize their need to have some form of automated verification system to 
> protect their site and other users.  This means that the conversation will 
> start from a position of respect.
> 
> HTH,
> Everett Zufelt
> http://zufelt.ca
> 
> Follow me on Twitter
> http://twitter.com/ezufelt
> 
> View my LinkedIn Profile
> http://www.linkedin.com/in/ezufelt
> 
> 
> 
> On 2010-08-17, at 10:56 AM, Peter Donahue wrote:
> 
>> Hello everyone,
>> 
>>   Also include the ability to make this information available to screen
>> readers while hiding it from spam bots. There are people being left behind
>> such as the deaf-blind. Audio captchas won't work if you cannot hear them.
>> This population is tired of being left out of Web accessibility.
>> 
>> Peter Donahue
>> 
>> 
>> ----- Original Message ----- 
>> From: "Tom Ladis" <tom@xxxxxxxxxxxx>
>> To: <programmingblind@xxxxxxxxxxxxx>
>> Sent: Tuesday, August 17, 2010 8:48 AM
>> Subject: Web User Verification Screens
>> 
>> 
>> Hello all. I have been running into more and more of the web based
>> verification screens that ask me to read a bunch of scrambled text, which 
>> I
>> usually cannot. Sometimes they offer a "speak it out loud" link, but that
>> often gets stepped on by JAWS announcing the popup.  There are third party
>> solutions to the problem, but they require that the user knows about them
>> and that they work correctly with their browser.
>> 
>> Does anyone have any ideas for a good replacement for the screen that 
>> would:
>> 
>> 1. Present the scrambled text
>> 
>> 2. Speak it out loud without a popup
>> 
>> 3. Be portable across the many platforms
>> 
>> ?4. Be a simple replacement to existing solutions
>> 
>> 
>> 
>> I feel that it would be a huge advantage to have all of the necessary
>> features built into an accessible control that I could present to some of
>> the major web sites for their use, to replace the mess that is spreading
>> across the web with the many solutions which all have problems.
>> 
>> 
>> 
>> Maybe something like a Macromedia Flash control but accessible and 
>> portable.
>> 
>> 
>> 
>> Thanks,
>> 
>> Tom Ladis a
>> 
>> __________
>> View the list's information and change your settings at
>> //www.freelists.org/list/programmingblind
>> 
>> __________
>> View the list's information and change your settings at
>> //www.freelists.org/list/programmingblind
>> 
> 
> 
> __________
> View the list's information and change your settings at 
> //www.freelists.org/list/programmingblind
> 

__________
View the list's information and change your settings at
//www.freelists.org/list/programmingblind

Other related posts: