Re: Requesting Horizontal Review: APA's Updated CAPTCHA Note Draft

Thank you, Angel, for these excellent and most timely comments.

Thank you especially for your remarks on phone and SMS validation. We
just simply missed that category. We will absolutely add such a section
before publishing.

We will also pick up on your other suggestions ...

reCAPTCHA V. 2 is certainly open for business only as long as Google
keeps it open. So, I think that even if it's open today still, we should
move to more past tense discussion. We hope this document remains useful
for years, so your suggestion provides us a better way to consider how
we present V. 2.


I've cc'd my response both to public-apa and public-rqtf which are both
holding telecons today. We'll take up your valuable comments.

Thanks again for such a quick turnaround!

Janina

Ángel writes:
> On 2019-05-14 at 15:13 -0400, Janina Sajka wrote:
> > Dear W3C Colleagues:
> (...)
> > https://w3c.github.io/apa/captcha/
> > 
> > We expect there are still editorial issues with this draft, but we
> > believe we've addressed all substantive concerns of which we're aware.
> > 
> > Our question to you: Have we fairly represented the state of CAPTCHA
> > today? If not, what have we missed or mischaracterized?
> > 
> > Thanking you in advance for your assistance on this document,
> > 
> > Janina Sajka,
> > APA Chair
> 
> Hello Janina
> 
> I'm not sure where you expect feedback about this draft to be sent
> (public-apa@w3.org ? that seems to be a restricted list), so rather than
> [potentially] spamming multiple lists I am initially just sending it to
> you individually.
> 
> The piece about reCAPTCHA V. 2 seems a bit inconsistent: it claims to be
> "recent" (without specifying a date), but it's already gone. I suspect
> it may be an old contribution that was left as-is. Could probably
> improve by changing all this paragraph to past tense.
> > One recent reCAPTCHA V. 2 innovation has seemed most promising. (...)
> > Unfortunately, as of this writing it appears that audio CAPTCHAs
> > previously available are now no longer being provided
> 
> 
> > 
> > Google is intent that a traditional CAPTCHA not be the fallback
> mechanism.
> 
> It could be rephrased eg.
> "with the intent that the implemented fallback mechanism is not a
> traditional CAPTCHA."
> 
> 
> s/ammounts/amounts/
> 
> > [[privacy-pass],
> 
> broken markdown link
> 
> 
> I could prepare a diff and/or pull request for these minor things, if
> you prefer (or several commits if you want).
> 
> 
> Additionally, I miss a section about phone validation captchas. -it
> considered. Looking in the archives, it seems to have been briefly
> mentioned on January, but I'm confused about how it concluded.
> For a while now, it has been a trend to request a phone number as a
> captcha. None of the three big email providers (Gmail, Yahoo and
> Outlook) allow you to create an email account without providing a mobile
> phone number.¹
> 
> 
> ¹ Being strict, outlook _allows_ the creation of the account, but it
> requires phone validation as soon as the user tries to send their first
> email.
> 
> As another example, a few weeks ago, I created a twitter account not
> providing a phone number. About 5-10 minutes after that, it considered
> that the behavior was suspicious and required passing a Google recaptcha
> *and* a phone verification in order to unlock the account. Despite it
> had been a normal use, having only manual interaction with the website
> from a mainstream browser.
> 
> 
> 
> The usage of phone numbers for validation has both privacy and
> accessibility implications. I don't think the first needs much
> explanation, and some people is quite reluctant about sharing their
> phone number with websites that want it "just for validation".
> 
> Amongst the potential drawbacks:
> It assumes that all users have a phone number they can use for their
> validation. Some people, while they could make calls through shared
> services if needed, don't have a line on their own.
> Often validation is only provided as SMS. But some people only have a
> landline number, which is not capable of sms reception (even if their
> terminal do, the network doesn't).
> There are people that do have a mobile phone, but is only able to
> perform very basic functions, and does not know how to read received
> SMS. (Depending on the resource that is being protected, it is possible
> that it too would be too complex, and thus may consider this not to be a
> concern, though)
> 
> Kind regards
> 
> Ángel
> 
> 

-- 

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 Wednesday, 15 May 2019 12:43:16 UTC