'

[Irl-dean] Accessibility of visual challenge response systems

Joshue O Connor joshue.oconnor at ncbi.ie
Fri Sep 8 10:18:20 IST 2006


Big thanks to Hugh for an enjoyable day and good to see you all!

I also wrote a short introduction to CAPTCHA's on the CFIT site a while back

http://www.cfit.ie/captcha/captcha.html

I think that Gez's idea is a very interesting one. Not testing the
ability of the
user but their identity via a distributed network takes the burden of
proof off the user,
doesn't alienate people with cognitive disabilities. These tests just
wish to tell if a
potential user is human, not their ability to perform a task.

The idea of using a different model, for me, highlights a deeper part of
the problem,
and a simple but important flaw in the way the Turing test was applied.

The CAPTCHA has become a testing mechanism for more situations/scenarios
than it has a
practical application for. As Gez mentions, they are often more
difficult for people to use than machines.
So some good questions are: "In what situations are the use of
traditional CAPTCHA's still applicable?" and
"Are there situations that need a different model (such as one based on
trustworthiness)?" or
"If the motivation for use is greater security, are CAPTCHA's the right
tool at all?",
"Are there better methods to achieve greater security without penalizing
users?"

These tests have been badly misapplied. There are other ways to improve
security and server side
mechanisms that can work under the hood to look for irregular patterns
of behaviour etc.

In terms of models as well as "trustworthiness", how about intent?
Robots do not have conscious intent.
They can simulate intent if the are running a program but this is a very
human quality, but I just don't know how
that would fly hmm,...

Josh



Gez Lemon wrote:
> On 07/09/06, Laurence Veale <laurence.veale at iqcontent.com> wrote:
>>
>> First, thanks to Hugh for organising yesterday's event.
> 
> I second this. It was a pleasure to meet you, Hugh, along with other
> members from this group.
> 
>> I've just blogged on the "Accessibility of visual challenge response
>> systems" and am interested in your comments on it.
> 
> The fundamental problems with Completely Automated Public Turing test
> to Tell Computers and Humans Apart (CAPTCHA)s is that they attempt to
> distinguish between humans and robots by testing for ability. Whether
> it's sensory, mobility, or cognitive ability, testing for the user's
> ability will always create barriers that are insurmountable to some
> people.
> 
> Microsoft's approach of providing both a visual and audio CAPTCHA is
> better than providing a single method, but still falls a long way
> short of being accessible. Some robots have sophisticated algorithms
> that are able to distinguish obscure patterns, which mean extra noise
> must be introduced to these patterns so that even people without
> sensory impairments are unable to distinguish the data from the noise.
> For the elderly, it is not possible to use services that determine
> humans from machines by sensory ability alone, as sensory abilities in
> humans diminish over time, but not in robots.
> 
> Another approach that is quite common is to ask questions that are
> intended to be incredibly simple for humans, but difficult for a
> robot. An example might be, "what colour is an orange?" along with an
> edit box to type the answer. On the surface, this seems quite a
> reasonable approach, but free-format text does cause problems for
> people with cognitive disabilities, as well as visitors who aren't
> native speakers of the natural language of the web page. Questions
> that have to remain simple also have obvious patterns, and are
> relatively simple for a robot to crack.
> 
> Another technique that is surprisingly popular is obscurity. Any book
> on security will quite rightly suggest that obscurity is no defence
> against an online attack. Despite this advice, methods that involve
> obscurity usually receive a lot of attention because they appear to be
> successful at a glance, although their success is usually short lived.
> For example, a submission form might contain an edit box where the
> user just has to enter, "banana". No robot would automatically know to
> do that (but could easily be trained to do so), and for a short time,
> that technique would remain successful. Of course, some people would
> have no idea what data they were meant to provide, yet it would be
> incredibly simple for a robot to provide that data. There was an
> example of this approach recently on another mailing list where
> someone came up with the idea of using RSS feeds as a method of
> identifying a person from a robot. The example asked the visitor to
> enter the most recent post by a blogger that was selected randomly
> from a list of bloggers. This is an example of obscurity that would be
> incredibly simple for a robot to crack, yet requires the person
> wanting to use the service to jump through all kinds of hoops (go to
> the blog of the person in question, identify the last post, memorise
> the title of the article along with punctuation, and enter it in an
> extraneous form field) that could easily confuse visitors to the
> website. Most ideas that people come up with for distinguishing humans
> from machines are usually far simpler for machines to process than it
> is for a human.
> 
> Personally, I think developers aren't asking the right questions.
> Realistically, they don't want to know what capabilities the person at
> the other end of the connection has, but whether or not they are
> trustworthy. Testing for ability is not the same thing as testing
> trustworthiness, yet all these types of services want to know is
> whether or not they can trust whoever is at the other end of the
> connection. Unfortunately, trustworthiness is a difficult trait to
> test.
> 
> One possibility would be to use some kind of social networking service
> that worked on an invitation only basis based on the six degrees of
> separation theory [1]. For example, an invitation-only service might
> reward points for people who have shown themselves to be trustworthy.
> At first, the person may only have limited access to sites that don't
> afford much security, but in time, the user could become know as
> trustworthy online, which in turn allows them greater access to other
> online services. If ever the person breaks that trust, they would
> become known as being untrustworthy. Being offered through an online
> service, it has the benefit of making this type of information
> available to everyone immediately. Anyone recommended by the person in
> question, along with the person who originally recommended them could
> immediately be suspended in the event of untrustworthy behaviour,
> pending an enquiry (which would also ensure that people were
> particular about who they recommended, as there would be a penalty
> should they recommend someone who was unsociable). The service would
> also need to include a list of people who provided online services
> that were eligible to provide feedback on people's performance to
> avoid malicious attacks against individuals. There will be a lot of
> work required to make this foolproof, and it would also take time to
> establish a trustworthy community, but I think it's a more reasonable
> approach than testing for a person's ability.
> 
> [1] http://en.wikipedia.org/wiki/Six_degrees_of_separation
> 
> Best regards,
> 
> Gez
> 


********************************************************************

NOTICE: The information contained in this email and any attachments 
is confidential and may be privileged.  If you are not the intended 
recipient you should not use, disclose, distribute or copy any of 
the content of it or of any attachment; you are requested to notify 
the sender immediately of your receipt of the email and then to 
delete it and any attachments from your system.

NCBI endeavours to ensure that emails and any attachments generated 
by its staff are free from viruses or other contaminants.  However, 
it cannot accept any responsibility for any such which are 
transmitted.  We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email 
and any attachments are those of the author and do not necessarily 
represent the views of NCBI


********************************************************************






More information about the CEUD-ICT mailing list