You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: index.html
+12-31Lines changed: 12 additions & 31 deletions
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,8 @@
10
10
<body>
11
11
<sectionid="abstract">
12
12
<h2>Abstracth2>
13
-
<p>Various approaches have been employed over many years to distinguish human users of web sites from <a>robotsa>. The traditional <a>CAPTCHAa> approach asking users to identify obscured text in an image remains common, but other approaches have emerged. All interactive approaches require users to perform a task believed to be relatively easy for humans but difficult for robots. Unfortunately the very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users. Research findings also indicate that many popular CAPTCHA techniques are no longer particularly effective or secure, further complicating the challenge of providing services secured from robotic intrusion yet accessible to people with disabilities. This document examines a number of approaches that allow systems to test for human users and the extent to which these approaches adequately accommodate people with disabilities, including recent noninteractive and tokenized approaches. We have grouped these approaches by two category classifications: <ahref="#stand-alone-approaches">Stand-Alone Approachesa> that can be deployed on a web host without engaging the services of unrelated third parties and <ahref="#multi-party-approaches">Multi-Party Approachesa> that engage the services of an unrelated third party.p>
13
+
<p>Various approaches have been employed over many years to distinguish human users of web sites from <a>robotsa>. The traditional <a>CAPTCHAa> approach asking users to identify obscured text in an image remains common, but other approaches have emerged. All interactive approaches require users to perform a task believed to be relatively easy for humans but difficult for robots. Unfortunately the very nature of the interactive task inherently excludes many people with disabilities, resulting in a denial of service to these users. Research findings also indicate that many popular CAPTCHA techniques are no longer particularly effective or secure, further complicating the challenge of providing services secured from robotic intrusion yet accessible to people with disabilities. This document examines a number of approaches that allow systems to test for human users and the extent to which these approaches adequately accommodate people with disabilities, including recent
14
+
non-interactive and tokenized approaches. We have grouped these approaches by two category classifications: <ahref="#stand-alone-approaches">Stand-Alone Approachesa> that can be deployed on a web host without engaging the services of unrelated third parties and <ahref="#multi-party-approaches">Multi-Party Approachesa> that engage the services of an unrelated third party.p>
14
15
section>
15
16
<sectionid="sotd">section>
16
17
<section>
@@ -30,8 +31,8 @@
The CAPTCHA Context
30
31
31
32
<p>An early (and still widespread) solution relies on the use of graphical representations of text in registration or comment areas of a web site. The site attempts to verify that the user is in fact a human by requiring the user to complete a task referred to as a "Completely Automated Public <a>Turing Testa>, to Tell Computers and Humans Apart," or <a>CAPTCHAa>. The assumption is that humans find this task relatively easy, while robots find it nearly impossible to perform.p>
32
33
<p>The CAPTCHA was <ahref="http://captcha.net">initially developed by researchers at Carnegie Mellon Universitya> and has been primarily associated with a technique whereby an individual identifies a distorted set of characters in a bit-mapped image, then enters those characters into a web form. This approach is widely familiar to users of the web, though the term CAPTCHA is generally recognized only by web professionals.p>
33
-
<p>In recent times the types of CAPTCHA that appear on web sites and mobile apps have changed significantly. Since our concern here is the accessibility of systems that seek to distinguish human users from their robotic impersonators, the term “CAPTCHA” is used in this document generically to refer to all approaches which are specifically designed to differentiate a human from a computer, including fully noninteractive approaches.p>
34
-
<p>It will surprise no one that we applaud the recent emergence of noninteractive approaches because functional noninteractive approaches pose no accessibility challenge to users. Unfortunately, some current noninteractive approaches come at the price of exposing much data about the individual user to the noninteractive host analysis engine that user might rather prefer to keep confidential. We are further heartened by the even more recent development of tokenized approaches that promise trustable <a>Turing testinga> requiring only minimal interaction with users.p>
34
+
<p>In recent times the types of CAPTCHA that appear on web sites and mobile apps have changed significantly. Since our concern here is the accessibility of systems that seek to distinguish human users from their robotic impersonators, the term “CAPTCHA” is used in this document generically to refer to all approaches which are specifically designed to differentiate a human from a computer, including fully non-interactive approaches.p>
35
+
<p>It will surprise no one that we applaud the recent emergence of non-interactive approaches because functional non-interactive approaches pose no accessibility challenge to users. Unfortunately, some current non-interactive approaches come at the price of exposing much data about the individual user to the non-interactive host analysis engine that user might rather prefer to keep confidential. We are further heartened by the even more recent development of tokenized approaches that promise trustable <a>Turing testinga> requiring only minimal interaction with users.p>
35
36
section>
36
37
<section>
37
38
<h3>The Accessibility Challengeh3>
@@ -186,7 +187,7 @@
Spam Filtering
186
187
<h4>Proof-Of-Workh4>
187
188
<p>One strategy for thwarting misuse of web resources is to load suspicious clients with significant computational workloads, thus
188
189
slowing down the interaction and hopefully deterring malicious parties by reducing their ability to engage in undesirable activities such as disseminating spam. This approach has been explored in the development of proof-of-work challenges. [[kaPoW-plugins]] These can be made arbitrarily expensive computationally based on an associated reputation score for each client that attempts to access a resource. Clients that are adjudged more likely to be malicious are required to solve more computationally expensive problems. Less resource-consumptive problems are provided to clients that are adjudged more likely to be web browsers operated by human users.p>
189
-
<p>The proof of work approach should have a negligible effect on the human user's interactive experience, provided that the reputation scoring is relatively accurate. However, it is designed to impose substantial cost on the operators of web robots—perhaps even greater than the cost of hiring human workers as <a>CAPTCHAa> solvers.p>
190
+
<p>The proof of work approach should have a negligible effect on the human user's interactive experience, provided that the reputation scoring is relatively accurate. However, it is designed to impose substantial cost on the operators of web robots—perhaps even greater than the cost of hiring human workers as <a>CAPTCHAa> solvers.p>
190
191
<p>Implementing this approach is straightforward. It requires the client to execute JavaScript code to solve the computational problem, and the solution is then verified by a server to establish that the work has been performed. It poses no direct accessibility problems, though it may slow performance for users of older hardware.p>
191
192
section>
192
193
<section>
@@ -245,22 +246,9 @@
Version 2: Are you a robot?
245
246
request right now." Users who have depended on audio CAPTCHA alternatives, who have previously been able to function with reCAPTCHA v2, are thus suddenly and seemingly capriciously locked out and denied service on sites still using V2.p>
also informed usa> that their goals with v included increasing "the
256
-
accessibility of the web by removing traditional CAPTCHAs" entirely.
257
-
Obviously, fully noninteractive <a>Turing testinga> is a most welcome development
258
-
direction for accessibility. When the noninteractive <a>Turing testa> returns a
259
-
score indicating high confidence that the user is human, or indeed a score
260
-
indicating high confidence that the user is a robot, and experience has
261
-
demonstrated the noninteractive engine is reliable, we can only offer praise
262
-
and gratitude for technological progress that more effectively supports persons
263
-
with disabilities. p>
249
+
<h4>The Non-interactive Version 3h4>
250
+
251
+
<p>Late in 2018 Google released <ahref="https://webmasters.googleblog.com/2018/10/introducing-recaptcha-v3-new-way-to.html"> reCAPTCHA v3a> promising to eliminate "the need to interrupt users with challenges at all." <ahref="https://lists.w3.org/Archives/Public/public-rqtf/2019Mar/0019.html">Google also informed usa> that their goals with v included increasing "the accessibility of the web by removing traditional CAPTCHAs" entirely. Obviously, fully non-interactive <a>Turing testinga> is a most welcome development direction for accessibility. When the non-interactive <a>Turing testa> returns a score indicating high confidence that the user is human, or indeed a score indicating high confidence that the user is a robot, and experience has demonstrated the non-interactive engine is reliable, we can only offer praise and gratitude for technological progress that more effectively supports persons with disabilities. p>
264
252
265
253
<p>Of course no approach will always return unambiguous results. <a
266
254
href="https://developers.google.com/recaptcha/docs/v3">In such
@@ -270,8 +258,7 @@
The Noninteractive Version 3
270
258
specific to their site to make a more informed judgment." Google intends
271
259
that traditional CAPTCHA no longer be used as a fallback mechanism and has dropped it from v reCAPTCHA, though it remains in their slightly older, 2017 <ahref="https://developers.google.com/recaptcha/docs/invisible">reCAPTCHA v2 Invisiblea> service.p>
272
260
273
-
<p>The reality is that what action is taken in response to an ambiguous core returned by v3 is in the hands of the content provider. Services like reCAPTCHA gain their market share by offering to relieve the content provider of the hard work inherent in mounting effective and accessible <a>Turing testinga>. Sadly this leaves the door open to any fallback approach a content provider might choose. Meanwhile, Google's reCAPTCHA FAQ declares that <ahref="https://developers.google.cn/recaptcha/docs/faq">reCAPTCHA Version 2 is not going awaya>. It is therefore imperative that methods for disambiguating an ambiguous noninteractive score be well documented and easily implementable in order to better overcome the tendency to simply adopt the old familiar approach.
274
-
p>
261
+
<p>The reality is that what action is taken in response to an ambiguous core returned by v3 is in the hands of the content provider. Services like reCAPTCHA gain their market share by offering to relieve the content provider of the hard work inherent in mounting effective and accessible <a>Turing testinga>. Sadly this leaves the door open to any fallback approach a content provider might choose. Meanwhile, Google's reCAPTCHA FAQ declares that <ahref="https://developers.google.cn/recaptcha/docs/faq">reCAPTCHA Version 2 is not going awaya>. It is therefore imperative that methods for disambiguating an ambiguous non-interactive score be well documented and easily implementable in order to better overcome the tendency to simply adopt the old familiar approach. p>
275
262
276
263
section>
277
264
section>
@@ -361,15 +348,9 @@
Turing Tokens from the Cloud?
361
348
<sectionid="fedtoken">
362
349
<h3>Why not Federated Turing Tokens?h3>
363
350
364
-
<p>A host of varied identity management systems with varying features and varying levels of accessibility are in use on the web today. Some, like <ahref="http://lastpass.com">Last Passa>, offer to securely store authentication credentials and frequently used form data that individual users and variously defined groups can invoke across a range of personal devices.
365
-
Services like
366
-
Amazon's <ahref="https://aws.amazon.com/cognito">Cognito,a> allow service providers to support a range of users existing authentications to facilitate accessing a range of cross platform services, in essence contracting out the task of login authentication and access control.
seeks to leverage login authentication on a highly popular web service to grow the ecosystem developed using user data collected on that platform.
371
-
It has been unclear to us at first blush which, if any, of these services prioritize restricting account services to human users only. It is, however, clear that virtually none provides their authenticated users, about whom they know a great deal, support for noninteractively authenticating their humanity with third parties. The only exceptions of which we're aware are <ahref="#recap3">reCAPTCHA v3a and <ahref="#privpass">Privacy Passa.p>
372
-
<p>We believe adding third party CAPTCHA support to identity management services is needed. Any service offering to say to a third party: "You don't know this user so you don't trust them, but you know and trust me, therefore you can trust this user" could only exist after earning trust across the industry. Such a service would indeed need to be careful to sign up only human users. The service that leveraged both user authentication and trusted anonymity would, we believe quickly prove viability. All users, but most certainly persons with disabilities need not only simplified authentication but also the ability to interact across the web using widely accepted trust credentials with minimal interruption for validating their humanity. Such an accessible enhanced quality <a>VPNa> service providing not just cross-site login but also Turing authentication, perhaps for a monthly fee—such a service could conceivably even validate and broker all the user's registered devices across the Internet anonymizing even financial transactions and shipping data as a full service on line trust broker. Letters of credit had a similar beginning in international finance some centuries hence, so why not on line Turing Tokens and privacy protection today?p>
351
+
<p>A host of varied identity management systems with varying features and varying levels of accessibility are in use on the web today. Some, like <ahref="http://lastpass.com">Last Passa>, offer to securely store authentication credentials and frequently used form data that individual users and variously defined groups can invoke across a range of personal devices. Services like Amazon's <ahref="https://aws.amazon.com/cognito">Cognito,a> allow service providers to support a range of users existing authentications to facilitate accessing a range of cross platform services, in essence contracting out the task of login authentication and access control. Others, like <ahref="https://developers.facebook.com/products/account-creation">Facebook's Account Kita>, seeks to leverage login authentication on a highly popular web service to grow the ecosystem developed using user data collected on that platform. It has been unclear to us at first blush which, if any, of these services
352
+
prioritize restricting account services to human users only. It is, however, clear that virtually none provides their authenticated users, about whom they know a great deal, support for non-interactively authenticating their humanity with third parties. The only exceptions of which we're aware are <ahref="#recap3">reCAPTCHA v3a> and <ahref="#privpass">Privacy Passa>.p>
353
+
<p>We believe adding third party CAPTCHA support to identity management services is needed. Any service offering to say to a third party: "You don't know this user so you don't trust them, but you know and trust me, therefore you can trust this user" could only exist after earning trust across the industry. Such a service would indeed need to be careful to sign up only human users. The service that leveraged both user authentication and trusted anonymity would, we believe quickly prove viability. All users, but most certainly persons with disabilities need not only simplified authentication but also the ability to interact across the web using widely accepted trust credentials with minimal interruption for validating their humanity. Such an accessible enhanced quality <a>VPNa> service providing not just cross-site login but also Turing authentication, perhaps for a monthly fee—such a service could conceivably even validate and broker all the user's registered devices across the Internet anonymizing even financial transactions and shipping data as a full service on line trust broker. Letters of credit had a similar beginning in international finance some centuries hence, so why not on line Turing Tokens and privacy protection today?p>
0 commit comments