CAPTCHAs are horrible

[plinss]

Form submission abuse is a real issue, but the current solution of CAPTCHAs is a horrible and error-prone user experience.

CAPTCHAs are an accessibility nightmare, provide an inconsistent UX, leak information to centralized services, and are abused as mechanical turks.

The UA knows that a human is driving it, can we provide a better mechanism that allows UAs to automatically prove human action and provide a consistent, accessible UX when needed?

One thought, add an <input type=captcha> that provides a trust token or the like in form submission. It would have no display, but the first time a form containing it is submitted, the UA can provide a UX to authenticate the user and obtain the token (querying the value from script would also yield the token/trigger the UX). The token could then be stored and auto-submitted in the future without any UX. Authors would need to be able to feature detect and fall back to other CAPTCHA mechanisms when not implemented.

[hober]

I love the idea of declaratively integrating the Trust Token API with HTML form submission. It would be very straightforward to polyfill, too. I wonder what @annevk & the Trust Token API folk (@dvorak42, @csharrison) think.

[annevk]

Seems reasonable. I think the bigger question is where we are at with the underling protocol and to what extent its properties and implications are acceptable.

cc @TanviHacks @johannhof @arthuredelstein

[dvorak42]

Generally seems reasonable to integrate with HTML forms (there's already some futzing with the API to support embedding it in iframe requests), though you'd need some more complicated scheme to indicate what Trust Token issuer you want to communicate with, and other parameters.

One issue is what the UX should be when there isn't a Trust Token/previous CAPTCHA result. Are you imagining the UX would be some sort of frame that displays a particular CAPTCHA provider's UI, or something that is wholly browser controlled?

[csharrison]

There may also be room for <form> integration where the browser does not control the UX for issuance. e.g. I am imagining some way to configure a form declaratively in two modes:

• If the user does not have trust tokens, the form renders as a site-controlled CAPTCHA and performs an issuance request on submit
• If the user has trust tokens, the CAPTCHA is never rendered and the form automatically performs redemption on submit

[dvorak42]

Yeah, I suspect that might be a good first-step, before trying to solve the browser-controlled UX side of things.

One change to support that would be to allow an issuance request to also return something equivalent to a redemption (WICG/trust-token-api#49) to avoid needing to do both the issuance and redemption steps when they're happening in the same context/top-level origin.

[Malvoz]

CAPTCHAs are an accessibility nightmare

Inaccessibility of CAPTCHA: https://www.w3.org/TR/turingtest/

[plinss]

Exhibit 3497: https://twitter.com/jsrailton/status/1371526115114749955

[torgo]

It looks like this has been taken up in the reference Trust Token API issue hence we are going to close.