El caso de una persona bloqueada de la cuenta de accesibilidad de hCaptcha por “no ser ciega” (2023)
(michaels.world)- Una persona usuaria con discapacidad visual consultó por un problema en el que la cookie de la cuenta de accesibilidad de hCaptcha no se configuraba en Brave, pero el equipo de soporte respondió que ese uso de accesibilidad no estaba permitido y notificó la eliminación de la cuenta y el bloqueo para volver a registrarse
- En ese momento, hCaptcha ofrecía una cuenta especial que evitaba el desafío CAPTCHA mediante una cookie en lugar de un CAPTCHA de audio, y luego se añadió una corrección indicando que en una actualización posterior se agregó una opción de CAPTCHA de texto
- La cuenta funcionaba en Firefox y Chromium, pero en Brave la cookie no se configuró durante aproximadamente un año, y en la consola de JavaScript el endpoint de set cookie devolvía 401 Unauthorized
- El equipo de soporte decidió que la persona usuaria no era ciega y bloqueó el uso de la cuenta de accesibilidad, y mantuvo el bloqueo incluso después de que la persona solicitó el desbloqueo afirmando que sí tenía discapacidad visual
- Un sistema que delega la accesibilidad en una vía de evasión separada puede excluir a personas usuarias reales del servicio en el momento en que esa vía se bloquea de forma arbitraria
El método de evasión de accesibilidad de hCaptcha
- hCaptcha es un servicio CAPTCHA en el que la persona usuaria marca una casilla y luego selecciona ciertas imágenes, como casas
- En ese momento, hCaptcha no ofrecía CAPTCHA de audio para personas con discapacidad visual y argumentaba que eso facilitaría que los bots lo superaran
- En cambio, existía un método para dar a personas ciegas una cuenta especial que configuraba una cookie y evitaba pasar por el desafío CAPTCHA
- Más tarde se añadió una actualización indicando que hCaptcha incorporó una opción de CAPTCHA de texto, pero se aclara que el señalamiento principal del texto sigue siendo válido
Solo en Brave no se configuraba la cookie
- La persona usuaria usaba Brave como navegador principal, y durante aproximadamente un año la cuenta de accesibilidad de hCaptcha no pudo configurar la cookie en Brave
- La misma cuenta sí funcionaba correctamente en otros navegadores como Firefox y Chromium
- Siguiendo las instrucciones, verificó medidas básicas como permitir cookies de terceros, pero el problema continuó en Brave, y el mensaje de error indicaba que si persistía debía enviarse un correo al equipo de soporte
Una consulta de soporte que terminó en sospecha
- La persona usuaria finalmente envió un correo al equipo de soporte de hCaptcha, y el equipo le indicó pasos básicos de solución de problemas
- Al revisar la consola de JavaScript para acotar el problema, informó que en Brave la llamada al endpoint de set cookie de hCaptcha parecía devolver
401 unauthorized - La persona usuaria proporcionó esta información para ayudar al soporte técnico, pero considera que eso pudo haber despertado las sospechas del equipo de soporte
Eliminación de la cuenta de accesibilidad y bloqueo de nuevo registro
- Mientras hablaba con una persona encargada de soporte, otra persona del equipo respondió en esencia lo siguiente
- Esa forma de uso no está permitida
- No se reciben créditos por el pase de accesibilidad
- Todas las cuentas usadas de esa manera se eliminan de hCaptcha
- Si la persona usuaria intenta volver a registrarse en una cuenta de accesibilidad, será bloqueada
- La persona usuaria expresó su confusión, ya que no estaba haciendo nada no permitido, sino solo intentando lograr que funcionara en Brave
- Después, el equipo de soporte explicó que la persona usuaria no era ciega, por lo que no debía usar una cuenta de accesibilidad
Después de alegar que sí tenía discapacidad visual
- La persona usuaria declaró que en realidad sí tenía discapacidad visual y pidió que se levantara el bloqueo, pero el equipo de soporte envió una respuesta estandarizada manteniendo el bloqueo de la cuenta
- La cuenta efectivamente quedó bloqueada, y la persona usuaria afirmó que para superar hCaptcha tendría que violar los términos del servicio y usar un programa de resolución automática
- Esto lleva a la advertencia de que no se debe confiar en que una empresa que ofrece un producto intencionalmente inaccesible mantendrá de forma estable una vía alternativa de accesibilidad por separado
- También insta a quienes administran sitios web que usan hCaptcha a considerar esta experiencia, y añade que Cloudflare ya parece usar su propio sistema
1 comentarios
Opiniones de Hacker News
Yo también soy una persona ciega, y hCaptcha es lo peor.
Como su estúpida cookie expira, casi cada vez que me topo con hCaptcha tengo que pasar por el proceso de recibir un correo y configurar la cookie.
Si usas varios dispositivos y navegadores, la experiencia de usuario es especialmente horrible, y creo que otras personas simplemente se rendirían.
Los bots pueden resolverlo más fácil que una persona ciega, o incluso subcontratarlo casi gratis a trabajadores del tercer mundo. Ej.: Anticaptcha [0]:
Te muestra imágenes diminutas que casi no se distinguen entre sí; es casi impresionante que hayan logrado hacerlo mucho peor que reCaptcha.
Los captchas de Google, aunque los resuelva bien durante más de 3 minutos, casi siempre me mandan a un bucle infinito y terminan fallando siempre; en cambio hCaptcha me deja pasar si resuelvo bien entre 1 y 3.
Uso cookies de sesión, pero no hay razón para que tenga que permitirle a una empresa plantar una cookie en mi sistema para evitar sus estúpidos CAPTCHA.
Dicho de otro modo, no debería tener que revelarles nada. No debería importar si ellos creen que soy una IA.
Solo por el título, parece un problema mucho menos grave de lo que realmente es.
Según el artículo, aunque el autor en realidad es ciego, hCaptcha lo acusó varias veces, de forma grosera y sin fundamento, de estar mintiendo.
No es una defensa, sino una explicación; pero al mismo tiempo muestra por qué la idea de “no darles a las personas ciegas un medio para eludir el CAPTCHA, salvo hacer una excepción solo para las personas ciegas ‘de verdad’ para cumplir con la ADA” es completamente inviable e imposible de escalar.
Incluso compañías del tamaño de Google, Facebook o Amazon tendrían dificultades para manejar la carga de un sistema que determine quién es “realmente” ciego. Y eso aun ignorando preguntas como qué significa exactamente “ceguera” en primer lugar.
Esto no es algo que debería convertirse en un problema después de desplegarse; es una idea que debió haberse revisado durante 5 minutos en una reunión de propuesta y bloqueado antes de que llegara siquiera a la etapa de diseño.
Si existiera un sistema capaz de determinar perfectamente rasgos como “quién es ciego” en un entorno con ataques adversarios extremos, eso sería algo mucho más valioso que el propio sistema CAPTCHA.
Esta idea solo funciona si ya tienes una solución más fuerte que el problema que CAPTCHA intenta resolver, así que lógicamente no se sostiene desde la raíz.
Algunos captchas se están volviendo cada vez más discriminatorios. No todo el mundo vive en Occidente ni puede reconocer los objetos que pide el captcha.
Hace poco vi uno que pedía elegir la figura con el mismo número que la cantidad de conoides (conoids) en la pantalla; si le preguntas a la gente en la calle qué es un conoid, bastantes se quedarían con la mirada en blanco.
Aun así, ahora al menos sé que hay gente que llama crosswalk a esas marcas.
Supongo que lo que querías decir era “no todo el mundo vive en Estados Unidos”.
Tampoco tengo ni idea con los hidrantes, taxis amarillos o autobuses amarillos.
Claro que, gracias al imperialismo cultural estadounidense a través de cosas como los CAPTCHA, se supone que todo el mundo debe conocer los referentes culturales de EE. UU., así que en la práctica sí los conozco.
Todavía no sé hasta dónde se supone que debo seleccionar un objeto, y tampoco está claro qué cuenta como semáforo. No sé si incluir el poste o no.
Las motos también son bastante difíciles, y una vez me salió una foto llena de escaleras; creo que marqué como 15 casillas.
El diccionario de Google dice que es un término zoológico que significa “aproximadamente con forma de cono”, y el panel de Wikipedia dice que en geometría es una superficie reglada que cumple ciertas condiciones, pero las imágenes tampoco son nada intuitivas.
El resultado de Merriam-Webster dice: “estructura con forma de cono, especialmente un orgánulo celular hueco con forma de cono truncado en el extremo anterior de un organismo”.
No parece tener ninguna relación, así que abrí la pestaña de imágenes y solo aparecen gráficas complicadas estilo Mathematica que no se parecen mucho a un cono.
Parece que otras personas en los comentarios de HN tampoco lo saben.
¿Puedes describir qué viste en la pantalla? ¿Qué creía el captcha que era un conoid? ¿Algo como un cono de tránsito?
Cuando compites con Google, la primera lección debería ser: “no trates a los usuarios peor que Google”. Si no, la gente simplemente usará Google.
Aunque su modelo de negocio sea así, depender de la buena voluntad de una minoría de “personas que jamás usan Google” no es un camino al éxito.
Mientras hCaptcha arruina su propia reputación, el resto del mundo seguirá usando reCaptcha y ni siquiera le prestará atención a la existencia de hCaptcha.
Por cierto, la ortografía es intentional, no “intensional”. Hay que pensarlo como “intent” + “-tion” + “-al”, no como “in-” + “tension” + “-al”.
En esencia, el autor era demasiado inteligente para ser ciego.
Parece que pensaron: ¿cómo va a “mirar” una persona ciega la consola de JavaScript?
Claro que decir “hice que el lector de pantalla me leyera el contenido de la consola de JavaScript” es un poco largo.
A mí también me pasa esto demasiado seguido. Como estoy en lugares donde “no debería” estar o hago cosas que “no debería” poder hacer, entonces resulta que no soy ciego.
El experimento de los CAPTCHA ya debería terminar pronto. No funcionó.
La verificación por número de teléfono tampoco es ideal, pero al menos eleva en cierta medida el costo del spam. Los CAPTCHA no. Casi todos los servicios CAPTCHA llave en mano se resuelven por unos centavos.
Resolver el problema del spam y del tráfico malicioso es difícil, y temo que al final se reduzca a tres posibilidades.
Primero, renunciar al anonimato de los usuarios. Si se verifica lo suficiente la identidad real, se puede bloquear permanentemente a individuos maliciosos y filtrar bots con bastante eficacia, pero desaparece el anonimato en línea. En mi opinión, eso es literalmente inaceptable.
Segundo, cerrar la plataforma. Enfoques como Web Environment Integrity y Private Access Tokens allanan el camino para cerrar la plataforma web. La mayoría de los usuarios de la web usan Google Chrome o Safari en dispositivos con Secure Boot, así que se puede atestiguar toda la cadena de arranque. Con el tiempo, crecerá la cantidad de usuarios en los que esto pueda aplicarse.
En ese futuro, la web no seguirá siendo abierta de forma significativa. Las alternativas serán cada vez menos útiles y, por ejemplo, aunque el aprendizaje automático no llegue a la inteligencia artificial general, superará por completo todos los CAPTCHA que tenemos enfrente, así que es muy probable que sin este método sea difícil entrar a sitios web.
Tercero, aumentar la responsabilidad de los operadores de red. Nos guste o no, internet se ha beneficiado mucho de operadores en zonas grises con poca supervisión o transparencia. Pero otra forma de eliminar el tráfico malicioso es imponer más responsabilidad a los operadores de red y desconectar de internet a los proveedores que no cooperen. Esto también probablemente sea malo y fomentará abusos de poder.
Aun así, es complicado. ¿Qué más se puede hacer? Aunque se intente reducir los incentivos del tráfico malicioso, es difícil hacerlo sin reducir el valor que ofrece el servicio; y con ofuscación se puede dificultar el tráfico malicioso, pero es difícil detener a un adversario decidido.
En cualquier caso, se siente que la era de la web abierta prácticamente terminó. La web abierta puede seguir existiendo, pero es muy probable que quede eclipsada por una web nueva y mucho más cerrada.
En nuestro sitio web, sin CAPTCHA, los bots llenan decenas de formularios por día. Al poner un CAPTCHA, pasan a ser 0.
Aunque el costo de romper un CAPTCHA sea bajo, parece que en nuestro sitio nadie quiere superar esa pequeña barrera.
Un CAPTCHA solo es útil cuando resolverlo tiene un costo. Se convierte en una señal de costo de que esta solicitud proviene de una persona real, o al menos de algo mayor que una milmillonésima parte de una persona real. Es decir, no es un sistema de spam totalmente automatizado.
El servicio postal también tiene un costo. Para enviar algo por correo, cualquiera tiene que comprar una estampilla. El costo de transporte es una forma “natural” de regular el tráfico y frenar el spam.
Con una combinación de arquitectura de red y criptomonedas, se podría cobrar un costo de transporte por cada intento de envío o de inicio de sesión. Si cada email de spam o cada intento de adivinar un login costara apenas 1 centavo, sería un costo prohibitivo para la mayoría del spam totalmente automatizado.
El componente de criptomoneda sirve para permitir transacciones tipo efectivo, como las estampillas, preservando a la vez el anonimato del acceso a una billetera personal.
Las redes sociales mataron a USENET, y el correo electrónico ha gestionado el problema del spam gracias al filtrado.
También habrá demasiados usuarios que harán clic en cualquier cosa por la oportunidad de ganar un premio y, en el proceso, autorizarán que su identidad se use para spam.
Cosas como Web Environment Integrity o Private Access Tokens nunca funcionarán bien. Porque a los spammers les basta con romper un solo modelo de dispositivo popular.
Quienes proponen esto son estafadores, o empresas de plataformas que quieren usarlo para crear un efecto de bloqueo. Los spammers invierten recursos en romper el sistema, pero los usuarios comunes no toleran las molestias; al final, se termina bloqueando a competidores y la interoperabilidad.
La responsabilidad de los operadores de red ya ocurre en buena medida. Los rangos de IP con mala reputación se bloquean. Pero cuando aparece una botnet de usuarios repartidos entre muchos ISP, algunos ISP tienen distinta disposición a responder, incluso si responden no pueden hacerlo de inmediato, y algunos a los que no les importa están en jurisdicciones que no se pueden controlar pero son demasiado grandes como para bloquearlas.
La mejor solución probablemente sea exigir, al crear una cuenta, un pequeño aporte en dinero, criptomoneda o prueba de trabajo. Los usuarios comunes solo necesitan unas pocas cuentas que mantendrán por mucho tiempo, mientras que los spammers necesitan grandes cantidades de cuentas que serán bloqueadas casi de inmediato, creando la estructura de costos asimétrica que requiere un sistema funcional.
Incluso entonces había que seguir haciendo las tareas más difíciles para mantenerse por delante del software de reconocimiento.
Ahora pasamos a un terreno en el que a las máquinas les resulta más fácil resolverlos que a los humanos, así que ya no sirven para su propósito original.
Lamentablemente, parece que la mayoría de las opciones de accesibilidad no están hechas para que realmente se usen.
Si eres un gobierno o una gran empresa, la accesibilidad entra en los requisitos básicos. Tienes que poder decir “sí, somos accesibles”, porque si no se arma ruido en la opinión pública.
Por eso, de la lista de proveedores se elimina a quienes no digan que ofrecen accesibilidad. Los proveedores lo saben y siempre dicen que la ofrecen.
Pero es una función difícil de hacer bien y solo corresponde a una pequeña parte de los usuarios. Cada tipo de discapacidad requiere apoyos distintos. Nadie en el equipo de desarrollo entiende bien los requisitos reales.
Las personas que necesitan accesibilidad se van a otro lado o se quejan y se las arreglan como pueden. Ninguna de las dos cosas aparece en el tablero de métricas.
Esta combinación fomenta el shelfware: algo que se compra y se deja en algún estante, pero que en la práctica no se usa.
Si entendí bien, ¿el problema de accesibilidad creado por hCaptcha está impidiendo que esta persona ciega acceda a varios sitios web?
¿No podría eso crearles un problema desde el punto de vista de la ADA a muchos clientes de hCaptcha?
Si el autor quisiera demandar, esto parecería casi un caso de victoria evidente.
Los términos de servicio no te protegen de la responsabilidad bajo la ADA.
No entiendo por qué todavía existen los captchas
Si alguien quiere scrapear algo o crear una automatización, ¿no sería mejor simplemente dejarlo? De todos modos deberían respetar los sistemas que requieren iniciar sesión
También está el beneficio de privacidad de no exponer a los visitantes a un servicio de captcha con decenas de subprocesadores de datos o más
Los bots creaban miles de cuentas falsas usando direcciones de correo de otras personas, y los correos de verificación que enviábamos eran reportados como spam porque los destinatarios nunca se habían registrado
Al final, nuestro proveedor de correo suspendió nuestra cuenta por la gran cantidad de reportes de spam
Yo sí lo hice, y en cuestión de días los bots empezaron a enviar spam mediante ese formulario
Puse un captcha trivial hardcodeado, tipo “2+3=”, pero si la escala hubiera sido mayor habría sido imposible de manejar
También hay que considerar la creación automática de cuentas para enviar spam por mensajes privados o abusar de los tiers gratuitos
La automatización y el scraping se saltan eso
Si quitas el captcha de un formulario de inicio de sesión, descubres que todos los días atrapas a cientos de usuarios a los que hay que enviarles correos de “por favor confirma tu dirección de correo” sin motivo alguno
La idea de que “ellos también deberían respetar los sistemas que requieren iniciar sesión” es excelente, pero cuando operas algo en internet te das cuenta de que, con o sin intención, la gente golpea los sistemas hasta que se caen
Esos bots no soportan CSS, así que funcionan aún mejor si se combinan con campos de formulario ocultos
Pero si se trata de un ataque dirigido, apenas logran subir la tasa de bloqueo de bots de 95% a 99%, haciendo sufrir solo a los usuarios legítimos