Google ha empezado a reemplazar captchas por un sistema que pide escanear un código QR y exige Google Play Services actualizado para completar la verificación; la medida, reportada en 2026, deja fuera a custom ROMs como GrapheneOS y a dispositivos sin la capa propietaria de Google (según Xataka, 11/5/2026). Este es el dato central: una verificación diseñada contra bots se basa ahora en software propietario, y eso cambia quién puede acceder a sitios y servicios.
¿Qué introdujo Google y por qué importa?
Google Cloud Fraud es la evolución de reCAPTCHA: cuando detecta tráfico sospechoso solicita escaneo de QR desde un smartphone con Play Services actualizado. Google dice que así se combate mejor el fraude y los bots, pero el requisito técnico es explícito: Play Integrity API, parte de Play Services, es la que responde a las webs. Esto importa porque Android no es marginal: Android tenía aproximadamente 71% de cuota global en abril de 2024, según StatCounter, por lo que el control sobre Play Services equivale a control sobre el acceso de la mayoría de usuarios móviles.
La consecuencia técnica es que sistemas basados en AOSP sin Play Services, como GrapheneOS, no pueden pasar esa verificación aun cuando algunos de esos dispositivos son más seguros sobre el papel. Para muchos desarrolladores open source esto no es una mejora de seguridad sino una barrera de acceso.
¿Cómo nos afecta en Argentina y en la región?
En Argentina y LATAM la gran mayoría de móviles usan Android o servicios compatibles, así que la medida tiene impacto real: sitios sensibles o servicios financieros podrían empezar a exigir verificaciones que dependen de Play Services. Si un banco o marketplace adopta este tipo de verificación, usuarios con custom ROMs o teléfonos sin certificación quedarían bloqueados para autenticarse o completar transacciones.
A nivel regulatorio, esto plantea preguntas prácticas. En 2023 Google intentó algo parecido con Web Environment Integrity (WEI) y terminó retrocediendo ante críticas de la comunidad y de estándares web, según cobertura de The Verge en 2023. La diferencia ahora es que la funcionalidad parece implementarse desde 2026 en producción, no solo como propuesta, por lo que la ventana para discutir mitigaciones es corta.
¿Es legítimo y qué reclama la comunidad open source?
Google está en su derecho a diseñar mecanismos de seguridad en sus plataformas. El problema es la concentración: cuando el estándar de facto para verificar si un usuario es ‘legítimo’ lo controla la misma empresa que vende el software y el hardware necesarios, los incentivos comerciales y técnicos confluyen. GrapheneOS y otros proyectos señalan que Play Integrity API discrimina configuraciones seguras que no incorporan Play Services.
La comunidad reclama transparencia: métricas públicas que muestren cuántos accesos legítimos se bloquean, documentación en español sobre cómo funcionan las APIs y mecanismos de apelación humana para casos reales. Es la misma demanda que venimos sosteniendo respecto a adopciones masivas de IA y domótica: gobernanza, documentación localizada y revisión humana antes de despliegues amplios.
Qué debería pedirse a Google y a reguladores
Primero, métricas públicas: cuánto bloquea Google Cloud Fraud, tasas de falsos positivos y su evolución mes a mes, con fuentes verificables. Segundo, documentación técnica en español que explique cómo integrar o justificar accesos sin Play Services. Tercero, alternativas técnicas que respeten la interoperabilidad y los estándares abiertos: permitir comprobaciones basadas en pruebas verificables del dispositivo sin requerir una sola implementación propietaria.
Si la respuesta es que esto mejora la seguridad, que lo demuestren con datos públicos; si la respuesta es que protege modelos de negocio, que se discuta en políticas públicas. Nosotros apoyamos medidas de seguridad operativas, pero exigimos métricas públicas, documentación en español y gobernanza con revisión humana antes de despliegues amplios. El riesgo de normalizar un estándar bajo control propietario es que sustituya la competencia técnica por la dependencia comercial, y eso termina afectando a usuarios, desarrolladores y la insistencia por estándares abiertos.
