#558: CAPTCHAs are horrible

Visit on Github.

Opened Sep 19, 2020

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.

Discussions

Discussed Nov 9, 2020 (See Github)

Peter: I want to get rid of them. Browsers know that they're being driven by a human. Can browsers send a meaningful signal as part of form submission?

Rossen: that's a strong statement. The browser does not know that it's being driven by a user.

Tess: in trust token world - a trust token would be issue some number of trust tokens - it sees this <input type="token"> and sends one of these.

Peter: it doesn't intrinsically know but it can determine it once and then fill it into forms automatically. Do it in such a way that the browser can display a captcha.

Tess: trust token API that people are working on doesn't have any form submission integration .. this is a natural approach. However if a browser doesn't recognize a type value it displays it - but it could be set to display=none - it would be easy to polyfill.

Rossen: I agree with the premise of the issue. I want to see how it ties into identity... Stronger mechanisms that could be present to signal that a human is driving the browser. Reducing the repitiveness of capchas would be a huge win. Perhaps this is a case where the trust token is indefinite?

Dan: [raising the issue about fraudsters using farms of workers to mint 50 tokens at a time]

Rossen: ... the tokens need to be scoped at the session or something... it would be great to (a) tie it into user identity - verifiable identifier that says I'm logged into a session... browser and slack [running as electron app] - should use same underlying tech. I'm the same user. Can this be somehow associated with a larger scope session?

Rossen: where do we go from here?

[Tess left a comment and @-mentioned others]

Tess: Being worked on in WICG... some concern about the cryptography involved.

Comment by @hober Nov 9, 2020 (See Github)

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.

Comment by @annevk Nov 10, 2020 (See Github)

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

Comment by @dvorak42 Nov 10, 2020 (See Github)

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?

Comment by @csharrison Nov 10, 2020 (See Github)

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
Comment by @dvorak42 Nov 10, 2020 (See Github)

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 (https://github.com/WICG/trust-token-api/issues/49) to avoid needing to do both the issuance and redemption steps when they're happening in the same context/top-level origin.

Discussed Nov 23, 2020 (See Github)

[some new comments]

Rossen: some folks have engaged from the HTML side.

Peter: good to get good feedback

Peter: we talked about maybe starting a community group or taking it to WICG

Rossen: I think what is being discussed here is great - in terms of how this might work. Ways to incorporate this back into form control management. Main point raised by Anne which still stands - we need the protocol underneath. I don't see anyone answering those question.

Peter: the proposal presumes trust tokens or something like it.

Rossen: Have you considered any other than trust token solutions? Any other identity solutions that might work?

Peter: something that a browser can send to asite.. ideally doesn't provide additional PII. Trust tokens fit the bill.

[discussion on who is in trust token work]

Dan: need for a workshop maybe? Engage with Wendy Seltzer to see if there is w3c "strategy" interest? [emails wendy]

Peter: we should let it percolate for a while...

Comment by @Malvoz Dec 28, 2020 (See Github)

CAPTCHAs are an accessibility nightmare

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

Discussed Jan 1, 2021 (See Github)

Peter: Dan reached out to Wendy to see if there's any appetite for a workshop on this topic. As far as I know he haven't heard back yet.

Tess: Maybe the best thing to do is just to ping her again. It'll be tough to make progress on a CG or workshop without anybody in the driver's seat of this.

Discussed Mar 8, 2021 (See Github)

Deferred.

Comment by @plinss Mar 15, 2021 (See Github)

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

Discussed Mar 22, 2021 (See Github)

Peter: we talked about pinging Ping and we haven't heard anything back yet... Will ping again.

Discussed Sep 1, 2021 (See Github)

Tess: doesn't really make sense as a design review issue

Amy: agreed

Tess: mentioned in Trust Token API thread. Close?

Amy: check with Peter..

Comment by @torgo Sep 16, 2021 (See Github)

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