Re: Picking Nits (was Re: CAPTCHA Status and Next Steps)

Here's what I've come up with provisionally to address David's points.
Comments welcome:

Furthermore, since research findings also indicate that many popular
CAPTCHA techniques are no longer particularly effective or secure, it is
necessary to
   reconsider which available approaches can block robots while
   still supporting ingress for people with disabilities.

      This document examines a number of potential solutions that allow
      systems to test for human users, and the extent to which these
      solutions adequately accommodate
         people with disabilities.


David Sloan writes:
> Hi Janina, all
> 
> Following up on the feedback below, I wanted to add my own. Overall, it's looking great! I had written some comments on the abstract as it stood on May 30th, but the June 2nd revision has addressed almost all. Here are just a couple more minor comments:
> 
> *  "Furthermore, research suggests that many popular CAPTCHA techniques are neither particularly effective nor secure.” 
> 
> This sentence as it stands seems to be a non-sequitur. Is the point we want to convey here is that not only do most current CAPTCHA methods have issues that mean they falsely identify people with disabilities as robots, but also that they have limitations that prevent them from meeting their objectives in stopping malicious robots, and therefore we need to look at better solutions? If that’s so, perhaps we could extend the sentence to make that position clearer?
> 
> * "This document examines a number of potential solutions that allow systems to test for human users while preserving access for users with disabilities."
> 
> The way this sentence is written, it could be perceived as distinguishing two separate groups: “human users” and “users with disabilities”, when our position is quite the opposite. So perhaps rewrite to say something like: "This document examines a number of potential solutions that allow systems to test for human users, and the extent to which these solutions adequately accommodate people with disabilities.”
> 
> Dave
> 
> 
> > On 2 Jun 2018, at 15:53, Janina Sajka <janina@rednote.net> wrote:
> > 
> > Thanks, John. Always happy to pedal past your shed! <grin>
> > 
> > These mostly look good to me, so I'
> > m going to implement them. Where I do have comments, they appear below.
> > I will delete the intervening points to ease the scroll.
> > 
> > I want to also thank you for the URIs. Very helpful!
> > 
> > John Foliot writes:
> >> Hi Janina,
> >> 
> >> I have gone over this with my red pencil. A few minor style, editorial, and
> >> grammatical observations (and a wee bit of bike-shedding) follows. I hope
> >> you will not be offended by these (OCD-like) thoughts.
> >> 
> > Nah, I love this stuff!
> >> ...
> >> "...Web sites with resources that are attractive to aggregators such as
> >> sign-up Web pages, travel and event ticket sites, Web-based email
> >> accounts<ins>,</ins> and social media portals have taken measures to ensure
> >> that they can offer their service to individual users without exposing
> >> their data and content to Web robots.
> >> 
> >> 
> >> Edit shown inline. [JF: Oxford comma fan since the 1970's...]
> >> 
> > I thought the Oxford comma was still controversial. I have decided to
> > agree with you because the list is of phrases, not simple words at that
> > point. And your additional Oxford comma related items below make sense
> > to me as well.
> > 
> > Yes, sometimes Oxford is needed. Do you know this one:
> > 
> > "I want to thank my parents, Ayn Rand and God." as opposed to
> > "I want to thank my parents, Ayn Rand, and God."
> > 
> > OH, "Come, Thou fount of every blessing." <evil grin>
> > 
> >> 5: ...
> >> 
> >> "...makes it impossible for users with certain disabilities to create
> >> accounts, write comments, or make purchases on such sites—in essence, such
> >> CAPTCHAs fail to properly recognize users with disabilities as human,
> >> obstructing their participation in contemporary society."
> >> 
> >> Bike-shedding. I question the use of em-dash here (suggests semi-colon
> >> instead). If we stick with em-dash, recommend some white-space before and
> >> after: "...on such sites — in essence..." Proposed Edit shown inline.
> >> 
> >> (ref: AP Style guide. See also:
> >> https://apvschicago.com/2011/05/em-dashes-and-ellipses-closed-or-spaced.html
> >> )
> >> 
> > Thanks for the semicolon suggestion. I decided to split this into two independent sentences. The construct still remains complex, even at that.
> > 
> > I am personally accustomed to no spaces around mdash. I was surprised to
> > read there are issues with that, though I understand when the concern is
> > preserving line break opportunities.
> > 
> >> Question, does W3C favor one style guide over the other? AP? Chicago?
> >> Oxford? Other?
> >> 
> > 
> > I'm unaware of a formal preference. I do believe Michael likes Chicago,
> > but we've discussed such things only rarely.
> > 
> > Remind us to check this some time on an APA when we're not too
> > overburdened by our agenda.
> > 
> >>> From the "3.3 Sound output" section:
> >> ...
> >> 14.
> >> ...
> >> Question: do we only want to call out one such voice-input system?​ (Alexa)
> >> Perhaps also reference Siri and Cortana to preserve vendor neutral
> >> appearance:
> >> 
> > 
> > I've thought about that. Creating a more comprehensive list risks
> > dminishing the impact of the sentence. The top two products, Alexa and "OK Google"
> > hold over 80% of the market, afaik. However, I doubt many people would
> > recognize the product/app name behind the famous "OK Google" command.
> > 
> > Please check what I've done here and tell me whether you believe it
> > addresses your point while also avoiding the product brochure effect.
> > "As with visual CAPTCHA however, robots are also capable of recognizing
> > spoken content--as Amazon's Alexa and Android's "OK Google" have so ably
> > demonstrated."
> > 
> > Could also be "OK Google command have so ably demonstrated."
> > 
> >> "...as Amazon's Alexa, Apple's Siri, Microsoft's Cortana, and other such
> >> platforms have so successfully demonstrated."
> >> ...
> >> ​17.
> >> 
> >> "...There are also temporal issues in that if it any portion of an audio
> >> CAPTCHA is not understood, the entire CAPTCHA must be replayed generally
> >> several times."
> >> 
> >> ​Struggling with the use of "generally" here. A couple of possible
> >> different options:
> >> 
> >> "...There are also temporal issues in that if it any portion of an audio
> >> CAPTCHA is not understood, generally the entire CAPTCHA must be replayed
> >> several times."
> >> 
> >> (Moves the adverb to the front of the sentence-fragment. Could also replace
> >> "generally" with the term "often" or "usually", which is more accurate and
> >> precise.)
> >> 
> >> "...There are also temporal issues in that if it any portion of an audio
> >> CAPTCHA is not understood; the entire CAPTCHA must be replayed, generally
> >> several times."
> >> 
> >> (Changed first comma to semi-colon, added comma to re-enforce the
> >> conditional term "generally")
> >> 
> > 
> > Yes, good points. I've made these, and a few more changes. Actually, I
> > think I want to rewrite this section further to explain more fully how
> > different working with temporal media is compared to visual stills. The
> > stark truth is that just providing an audio alternative is not, on it's
> > own, equivalent access. That's being strongly implied. I want to starkly
> > say so.
> > 
> > But, first the remainder of your list ...
> > 
> > 
> >> 
> >> ​More bike-shedding.
> > 
> > Hardly!
> > 
> >> ...
> >> 20.
> >> 
> >> "...More advanced systems can control attacks based on posting frequency,
> >> filter content sent using the TRACKBACK]] protocol, and ban users by IP
> >> address range..."
> >> 
> >> Presuming an issue with "Trackback" (ends with two right square-brackets,
> >> no beginning left square bracket - is this also supposed to be a link?)
> >> 
> > 
> > Ah, yes. Thank you! It's respec goodness, and it is certainly broken.
> > Now fixed.
> > 
> >> 24.
> >> 
> >> "...A subset of this concept, in which only people with disabilities who
> >> are affected by other verification systems would register, raises a privacy
> >> concern in that the user would necessarily inform every site that she has a
> >> disability. The stigma of users with disabilities having to register
> >> themselves to receive the same services should be avoided."
> >> 
> >> 
> >> This is really hard to parse - the sentence feels incomplete. Is this
> >> saying that it would be a "specialty service" that the PwD would have to
> >> register with?
> >> 
> >> Proposed re-write:
> >> 
> >> "...A subset of this concept, in which only people with disabilities (who
> >> are negatively affected by other verification systems) would be required to
> >> register with a "specialty service" for authentication, raises a privacy
> >> concern in that the user would necessarily inform every site that she has a
> >> disability. The stigma of users with disabilities having to register
> >> themselves to receive the same services should be avoided."
> >> 
> > 
> > No, the idea is that pwds should not be the only ones registering.
> > That's the stigmatization. But, I take your point that this needs a
> > rewrite. I'll work on it. I've left it for now.
> >> 26.  Question: do we not traditionally link out to external references?
> >> Speaking here of the legal standards being noted (EN 301 549, section 5.3;
> >> section 255 of the Communications Act in the United States - 36 CFR 1194,
> >> Appendix C, section 403)
> >> 
> > 
> > 
> > Yes, it's a todo.
> > 
> >> 
> >> ...and... that's all I could spot.
> >> 
> > 
> > Thanks again. Good catches!
> > 
> > Janina
> > 
> >> JF
> >> 
> >> 
> >> On Fri, Jun 1, 2018 at 9:54 AM, Janina Sajka <janina@rednote.net> wrote:
> >> 
> >>> Colleagues:
> >>> 
> >>> I have concluded editing our draft CAPTCHA document for the time being.
> >>> Yes, I have made significant and numerous edits since our call.  So, at
> >>> your convenience, please review:
> >>> 
> >>> https://rawgit.com/w3c/apa/captcha-janina/captcha/index.html
> >>> 
> >>> In addition to any further edits we may want to make, we still have
> >>> broken links to resolve.
> >>> 
> >>> I now have a working URI for the Cnet article reference--and it's an
> >>> even more meaningful reference in the current draft, imo.
> >>> 
> >>> While the specific Anti-Phishing PDF document the 2004 CAPTCHA note
> >>> references now yields a 404, the site itself is still functioning. Is
> >>> there some specific document there we would choose to point to in our
> >>> current note?
> >>> 
> >>> http://antiphishing.org/
> >>> 
> >>> 
> >>> Lastly, I have collect terms we may want to include in a glossary. Your
> >>> opinions on which to keep, and where to point to in reference to them
> >>> are solicited. Here's my current list:
> >>> 
> >>> CAPTCHA
> >>> https://en.wikipedia.org/wiki/CAPTCHA
> >>> http://www.dictionary.com/browse/captcha
> >>> 
> >>> Turing Test
> >>> https://en.wikipedia.org/wiki/Turing_test
> >>> 
> >>> assistive technology
> >>> https://en.wikipedia.org/wiki/Assistive_technology
> >>> https://www.w3.org/WAI/people-use-web/tools-techniques/
> >>> 
> >>> alternative text
> >>> https://www.w3.org/WAI/alt/
> >>> Should probably now point to WCAG 2.1 ...
> >>> 
> >>> screen reader
> >>> http://www.afb.org/ProdBrowseCatResults.aspx?CatID=49
> >>> https://en.wikipedia.org/wiki/Screen_reader
> >>> https://www.w3.org/WAI/people-use-web/tools-techniques/
> >>> 
> >>> web robot
> >>> https://en.wikipedia.org/wiki/Internet_bot
> >>> 
> >>> Google Recaptcha
> >>> https://www.google.com/recaptcha/intro/index.html
> >>> 
> >>> iso8859-1
> >>> https://en.wikipedia.org/wiki/ISO/IEC_8859-1
> >>> 
> >>> spider
> >>> https://en.wikipedia.org/wiki/Web_crawler
> >>> 
> >>> spam filtering
> >>> https://en.wikipedia.org/wiki/Email_filtering
> >>> 
> >>> heuristics
> >>> https://en.wikipedia.org/wiki/Heuristic
> >>> 
> >>> continuous authentication
> >>> https://www.networkworld.com/article/3121240/security/contin
> >>> uous-authentication-the-future-of-identity-and-access-management-iam.html
> >>> 
> >>> hot words
> >>> I've not found a useful pointer for this one yet.
> >>> 
> >>> Bayesian filtering
> >>> Too many choices! No winner yet.
> >>> 
> >>> Public-key infrastructure
> >>> https://en.wikipedia.org/wiki/Public_key_infrastructure
> >>> 
> >>> polymorphism
> >>> https://www.britannica.com/science/polymorphism-biology
> >>> Good source for the term, but not applied to computing!
> >>> 
> >>> Chafee Amendment
> >>> https://www.loc.gov/nls/about/organization/laws-regulations/
> >>> copyright-law-amendment-1996-pl-104-197/
> >>> 
> >>> --
> >>> 
> >>> Janina Sajka
> >>> 
> >>> Linux Foundation Fellow
> >>> Executive Chair, Accessibility Workgroup:       http://a11y.org
> >>> 
> >>> The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> >>> Chair, Accessible Platform Architectures        http://www.w3.org/wai/apa
> >>> 
> >>> 
> >>> 
> >> 
> >> 
> >> -- 
> >> John Foliot
> >> Principal Accessibility Strategist
> >> Deque Systems Inc.
> >> john.foliot@deque.com
> >> 
> >> Advancing the mission of digital accessibility and inclusion
> > 
> > -- 
> > 
> > Janina Sajka
> > 
> > Linux Foundation Fellow
> > Executive Chair, Accessibility Workgroup: http://a11y.org
> > 
> > The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
> > Chair, Accessible Platform Architectures http://www.w3.org/wai/apa
> > 
> > 
> 
> --
> David Sloan
> --
> UX Research Lead
> The Paciello Group
> https://www.paciellogroup.com
> A VFO™ Company http://www.vfo-group.com/
> --
> This message is intended to be confidential and may be legally privileged. It is intended solely for the addressee. If you are not the intended recipient, please delete this message from your system and notify us immediately.
> Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful.
> 
> 
> 
> 
> 
> 

-- 

Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup: http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures http://www.w3.org/wai/apa

Received on Monday, 4 June 2018 19:59:38 UTC