- Mientras la propuesta Web Environment Integrity de Google genera controversia, Apple ya desplegó en macOS 13, iOS 16 y Safari un sistema similar de atestación web de dispositivos llamado Private Access Tokens
- Private Access Tokens funciona de modo que, cuando el servidor envía un HTTP 401 con un desafío
PrivateToken, el navegador y el sistema operativo validan el estado del dispositivo con un atestador y reintentan la solicitud con un token firmado - Cloudflare y Fastly lo integraron para reducir los CAPTCHA, pero la misma estructura sirve como base para que los servidores web exijan que el dispositivo del usuario demuestre ser un cliente legítimo
- La cuota de Safari ronda el 20%, así que su impacto es limitado, pero Chromium supera el 70%; si se suma la propuesta de Google, cerca del 90% de los clientes web podrían quedar sujetos a atestación
- La atestación puede excluir navegadores y sistemas operativos nuevos, software de código abierto y dispositivos modificados por el usuario, y existe el riesgo de que las reglas se endurezcan con condiciones como el período oficial de soporte o la instalación de extensiones para bloquear anuncios
El despliegue y el objetivo de Apple Private Access Tokens
- Crece la preocupación en torno a la propuesta Web Environment Integrity, que parece estar siendo desarrollada por autores de Google y prototipada en Chromium
- La propuesta equivale a una atestación en la web, donde el acceso a funciones o incluso a sitios completos podría restringirse según si el cliente fue aprobado por un emisor de confianza
- Los emisores de confianza reales probablemente serían Apple, Microsoft y Google
- Apple ya desarrolló y desplegó hace un año un sistema muy similar, Private Access Tokens, que hoy está integrado en macOS 13, iOS 16 y Safari
- Apple presenta Private Access Tokens como “una herramienta poderosa para demostrar que una solicitud HTTP proviene de un dispositivo legítimo sin revelar la identidad”
- El objetivo principal de esta función es eliminar los CAPTCHA, y Cloudflare y Fastly la integraron como mecanismo para reconocer a clientes reales
- Explicación de Cloudflare: Eliminating CAPTCHAs on iPhones and Macs using new standard
- Explicación de Fastly: Private Access Tokens: Stepping into the privacy-respecting CAPTCHA-less
Cómo funciona Private Access Tokens
- Private Access Tokens es un intercambio relativamente simple que ocurre sobre HTTP, manejado por una API integrada del navegador y conectado con componentes del sistema operativo para verificar si el navegador y el SO son legítimos
- Aquí, el criterio de qué cuenta como “legítimo” lo decide el atestador, es decir, una entidad como Apple
- El flujo básico es el siguiente
- El navegador envía una solicitud HTTP al servidor web
- El servidor web rechaza la solicitud y devuelve una respuesta HTTP 401 con un desafío
PrivateToken - El navegador envía parte del desafío y la información verificada del dispositivo proporcionada por el sistema operativo al atestador
- El atestador confirma si el dispositivo es real y no ha sido modificado, y luego devuelve un token firmado junto con un emisor de tokens en quien el origen confía y que confía en el atestador
- El navegador vuelve a enviar la solicitud incluyendo el token firmado en el encabezado
Authorization - El servidor puede tratar de forma distinta a ese cliente basándose en que fue verificado por un proveedor de confianza
- Este proceso ya ocurre en dispositivos Apple que usan Safari cuando un servicio que aprovecha esta función, como Fastly o Cloudflare, sospecha de la legitimidad de una solicitud
- Private Access Tokens busca proteger la privacidad separando los flujos de origen, emisor y atestador, pero el trato que se recibe en la web pasa a depender de si Apple considera aceptable la combinación de dispositivo, sistema operativo y navegador
La diferencia de alcance entre Safari y Chromium
- Private Access Tokens por sí solo ya representa una carga para la web y para la industria, pero por la cuota de Safari es más difícil que se expanda tan rápido como la propuesta de Google
- La cuota de mercado de Safari en navegadores es actualmente de alrededor del 20%
- En móvil, cerca del 25%
- En escritorio, cerca del 15%
- Chrome supera el 60% en todas las categorías, y todo Chromium, incluyendo Brave, Edge, Opera y Samsung Internet, está unos 10 puntos porcentuales por encima de eso
- Si solo Safari ofrece esta función, algunos proveedores pueden usarla, pero es difícil bloquear o tratar distinto a clientes que no tienen atestación
- Aunque Safari no atestara versiones antiguas del sistema operativo o del navegador, sería difícil que eso afectara mucho a los usuarios; estadísticamente, lo más probable es que vieran más CAPTCHA
- Si Web Environment Integrity se introduce en un contexto donde más del 70% de los clientes web usan Chromium, podría expandirse rápidamente por las partes principales de la web
- Si conviven Web Environment Integrity y Private Access Tokens, alrededor del 90% de los clientes web podrían quedar potencialmente sujetos a atestación, y aumentaría la presión por “tratar como sospechoso a quien no tenga atestación”
Cómo la atestación pone en riesgo la apertura de la web
- La atestación favorece que solo puedan usarse clientes aprobados, lo que perjudica la competencia y la innovación
- Se vuelve más difícil crear nuevos navegadores o sistemas operativos
- Los esfuerzos de código abierto, comunitarios o de pequeños desarrolladores independientes pueden quedar excluidos de forma permanente de este tipo de mecanismos
- Se compara con la idea de que, si hubiera existido atestación en la era de IE6, habría sido un gran obstáculo para el ascenso de Firefox y Chrome
- Esta estructura hace, por diseño, que al usuario le cueste más controlar su propio dispositivo
- Uno de sus objetivos centrales es que los usuarios con software modificado no sean atestados como clientes legítimos
- Podrían quedar excluidos casos de uso como navegar la web desde un teléfono Android rooteado
- Un sistema operativo o hardware completamente modificable por el usuario difícilmente podría ser atestado del modo que estas propuestas pretenden
- Los proveedores de aprobación pueden endurecer las reglas más adelante
- “Solo se atestarán dispositivos dentro del período oficial de soporte de 2 años”
- “No se atestarán navegadores con extensiones de bloqueo de anuncios instaladas”
- Quienes apoyan Web Environment Integrity consideran que los holdbacks, que rechazan la atestación en algunas solicitudes, podrían evitar bloqueos basados en atestación
- Sin embargo, existe preocupación de que, por presiones de negocio, los holdbacks no funcionen en la práctica, y la atestación Android Play Integrity actual de Google no usa este enfoque
- El éxito de la web dependió en gran medida de poder usar libremente distintos clientes y servidores, y la atestación rompe esa premisa por diseño
El riesgo ya visible en Android
- En Android es técnicamente posible crear y ejecutar tu propio sistema operativo, y distribuciones Android como LineageOS siguen funcionando normalmente
- Sin embargo, por las funciones de atestación, sigue existiendo el riesgo de que apps esenciales, como las bancarias, consideren sospechoso al usuario y lo bloqueen
- Frenar la competencia entre versiones de Android ya es un problema, pero impedir la competencia tanto entre navegadores como entre sistemas operativos en la web podría tener consecuencias mucho más graves
- En el Anti-Fraud Community Group también se discuten otras propuestas de posibles funciones web de la misma familia
- El fraude y los bots en la web son problemas reales, y vale la pena debatir formas de defensa, pero bloquear la competencia, debilitar el código abierto y la web abierta, y quitarle al usuario el control de sus dispositivos no es un intercambio razonable
1 comentarios
Opiniones en Hacker News
Ayer, la propuesta inicial de Google recibió muchas reacciones como “dividir la empresa empieza a tener bastante sentido”, “vete al diablo, Google”, “estoy enojado y triste” y “la reputación de los involucrados quedó completamente destruida”.
Hoy se reveló que Apple no solo propuso la misma función el año pasado, sino que además la implementó y la distribuyó, y el tono fue más del estilo “podría ser una oportunidad interesante para retomar sueños desaparecidos hace mucho”, “entiendo en cierta medida ambas posturas” y “por ahora la dejaré activada en Safari y observaré durante 1 o 2 años”.
En general sigue siendo negativo, pero la diferencia de tono hacia Apple y Google es demasiado clara, y el campo de distorsión de la realidad parece seguir intacto.
Uno de ellos incluso publicó directamente en Hacker News, y eso termina alentando el acoso, porque quienes los detestan creen que, si molestan lo suficiente, los involucrados se rendirán.
Apple no pierde tiempo en eso: revisa, planifica y ejecuta. No se puede saber quiénes son los involucrados, normalmente tampoco pide feedback y casi nunca ofrece siquiera una justificación de sus planes. Enojarse con Apple en un foro web es tan inútil como enojarse con una pared de ladrillos.
El cliché de la empresa sin rostro no existe por nada: es una política deliberada para proteger a sus empleados.
Pero con Apple pasa lo contrario. Dicen que la libertad de instalar apps de terceros es peligrosa, que la libertad de usar iMessage en el navegador no tiene sentido y, en su mayoría, no parecen interesarse por la libertad de usar navegadores de terceros en iOS.
Es impresionante que el efecto de bloqueo de otras empresas se considere malo, pero el de Apple sea evangelizado activamente por su base de usuarios.
El enfoque de Apple se parece más a una forma de distinguir usuarios humanos de usuarios no humanos en dispositivos Apple, y no permite que un servicio bloquee arbitrariamente navegadores o sistemas operativos como en la propuesta de Google.
Si ya usas un dispositivo Apple, básicamente te evita tener que hacer un CAPTCHA de “verificar que eres una persona”.
Referencia: https://developer.apple.com/wwdc22/10077
En cambio, Google deja que una minoría ruidosa de detractores de Google siga erosionando su reputación, mientras hace muy poca comunicación para controlar la narrativa.
Parece que todavía cree que el eco de aquel “don’t be evil” va a seguir resonando 20 años después.
Cuando Microsoft metió IE en Windows fue algo terrible, pero cuando Apple mete Safari y bloquea navegadores competidores, se presenta como lo mejor para el cliente.
Este podría ser realmente el punto en que internet se bifurca. Es algo que se viene prediciendo desde los años 90.
De un lado podría quedar una web corporativa “limpia”, aprobada por autoridades, donde todos están excesivamente identificados; del otro, una galaxia más laxa de graynet, con porno y comunidades descentralizadas.
Si todos los tinkers quedan expulsados de la red corporativa, también podría convertirse en una oportunidad interesante para retomar sueños desaparecidos hace mucho.
Siempre imaginé que sobre internet surgió una especie de superestructura social, como una burbuja que representa a la “sociedad”. Desde los años 90 existían versiones pequeñas, pero se consolidó con el auge de redes sociales como Myspace, Facebook y Twitter.
No creo que sea casualidad que la “cultura de la cancelación” apareciera poco después. Cuando surge una plaza pública virtualizada, la cuestión pasa a ser quién decide qué pertenece a ella y qué no.
Es una actitud tipo “por fin podré poner a prueba las habilidades por las que la gente se burló de mí durante tanto tiempo”.
En ambos casos, el problema es que ignoran a la gran mayoría de personas que sufrirían bajo el nuevo orden. Serán poquísimos quienes salgan del jardín amurallado corporativo hacia una autopista de la información libre.
Apenas débiles ecos de la web corporativa se preservan a través de la graynet, y arqueólogos digitales intentan desenterrar los “secretos” de una sabiduría perdida escondida en la web corporativa.
Seguramente alguien ya escribió algo así, pero parece encajar bien.
También se quiere en cierta medida en entornos domésticos donde se cruzan la nube pública y el uso privado, por ejemplo túneles de Cloudflare Access para uso personal y un tenant empresarial de MS365.
Pero definitivamente no quisiera que tocara la experiencia personal de navegación web ni el entorno de un navegador personal.
Hoy esos deseos básicamente chocan entre sí, y la tecnología ya salió de la bolsa.
El sueño cyberpunk de los 90 es genial, pero parece ignorar la realidad física de que, para conectarse a la “red”, siempre hay que pasar por el cuello de botella que es el proveedor de internet.
Al final, existe una barrera irresoluble para cuánto puede internet ser realmente antisistema.
Puede que me equivoque, pero Web Attestation podría ser una sentencia de muerte para que los dispositivos Linux, no Android ni Chrome OS, usen la web como clientes en igualdad de condiciones.
Linux es una plataforma demasiado diversa y con demasiadas posibilidades de hackeo como para que la atestación remota funcione de forma confiable, así que al final quedará completamente excluida.
Solo unas pocas distribuciones “bendecidas” serán la excepción, pero esas distribuciones quedarán bajo el control de la industria y ya no tendrán mucho que ver con el espíritu de Linux.
Casi todos los sitios web te marcan en sus clasificadores antispam, y para acceder a lugares protegidos tienes que resolver captchas entre 3 y 5 veces.
Wikipedia también bloquea la edición: https://meta.wikimedia.org/wiki/Talk:Apple_iCloud_Private_Re...
Como parece que no tengo la fuerza de voluntad para dejar esos sitios, quizá lo que necesito es que del otro lado me impidan cargar el contenido.
Ahora que lo dije aquí, ya no es un secreto.
https://github.com/jwise/28c3-doctorow/blob/master/transcrip...
También son plataformas lo bastante diversas y hackeables como para parecer insuficientes en un futuro en el que tengan que demostrar que poseen cierto hardware específico.
A menudo escucho que unas pocas distribuciones “bendecidas” quedarían bajo control de la industria y que el espíritu de Linux desaparecería, pero rara vez escucho concretamente cómo ocurriría eso.
Linux nació por culpa del UNIX controlado por la industria, y si le quitan ese espíritu a Linux, se bifurcará en otro proyecto comunitario.
Mientras no le quiten la licencia GPL, Linux conservará el “espíritu de Linux” hasta que deje de usarse por completo.
No estoy de acuerdo con el argumento de que, como Safari no es el navegador dominante, esto no es tan peligroso como la propuesta de Google.
En realidad, es igual de malo si lo hace Apple o si lo hace Google, y Apple tomó una decisión totalmente decepcionante.
Aunque Google lo impulsara, si Apple se hubiera negado habría sido difícil imponerlo en la práctica. Sus cifras no son tan altas como las de Chrome, pero sí lo suficiente como para que no se pueda dejar fuera a todos los iDevice.
Las únicas empresas que realmente importan son Apple, Google y Microsoft.
Es una lástima que esta vez no vaya a impedir otra catástrofe.
Por eso también me preocupan las leyes que exigen a Apple abrirse al sideloading. Me gusta la idea de que la gente controle sus propios sistemas, pero temo que en la práctica sea el último clavo que consolide el control total de Google sobre la web hasta el extremo del cliente.
Cada vez que señalo que una función que implementaron no es compatible con varios navegadores, invariablemente me dicen que cambie de Firefox a Chrome.
Nunca he escuchado que me digan que cambie a Safari para que algo funcione. Eso por sí solo dice mucho.
En iOS parece que se puede desactivar esta función.
Hay que ir a Configuración, elegir la cuenta de usuario en la parte superior, entrar a “Password & Security”, bajar hasta Advanced y desactivar “Automatic Verification”.
https://blog.cloudflare.com/how-to-enable-private-access-tok...
https://support.apple.com/en-us/HT213449
System Settings -> iCloud Settings(nombre de usuario) -> Password & Security -> Automatic Verification
Si Chrome despliega WEI, varios forks de Chromium también permitirán desactivarlo aunque Chrome no lo haga, y también podrás usar Firefox.
El problema será cuando tu banco, la agencia tributaria o tu servicio de streaming favorito empiecen a exigir esta función.
El punto clave es que una parte considerable de los usuarios comunes tenga esta función.
De hecho me di cuenta de esto y hasta pensé en escribirlo en un blog, pero creo que la única razón por la que no parecía un problema era que solo estaba implementado en plataformas de Apple, así que los servicios no tenían forma real de restringir usuarios con esto.
Era simplemente un factor adicional que la gente podía usar como una señal más.
En cambio, la propuesta de Google está interesada en impulsarlo explícitamente como una función siempre activada.
La explicación de que casos de uso como la “atestación determinista de integridad de plataforma” actualmente dependen del fingerprinting del cliente es, en definitiva, el argumento de que una prueba determinista con entropía limitada reemplazará al fingerprinting invasivo y, a largo plazo, abrirá la puerta a prácticas más favorables a la privacidad.
Lo único que demuestra el hecho de que Apple lo haya implementado primero es que quien espera que Apple nos salve es ingenuo.
Esta área es realmente interesante y tiene potencial para generar divisiones.
Hay muchísimos casos de uso en los que, en la web, uno quisiera saber si se está comunicando con un stack de hardware y software “confiable”.
Durante años hemos diseñado y construido asumiendo que hay muy poca confianza en el stack, lo que aumenta enormemente la complejidad y los costos, limita funciones y hace que todo sea mucho más difícil de lo que sería si se pudiera asumir un stack confiable.
Al mismo tiempo, como se está señalando con fuerza ahora, cuando entran en juego los monopolios de las grandes tecnológicas, el concepto de confianza se vuelve muy complicado.
Por un lado, hay muy pocas empresas en el mundo que puedan operar grandes equipos de tecnología capaces de enfrentar a actores de amenazas persistentes, así que sería bueno poder confiar en las promesas de seguridad que hacen. Si esas promesas son confiables, son mejores que cualquier promesa que una persona pueda hacer sobre su propio software y plataforma.
Por otro lado, desde el sentido platónico de “hacker”, “confiable” se lee como “garantizado por un monopolio”, “probablemente con una puerta trasera de una agencia gubernamental local”, y como un paso más hacia abajo, hacia un futuro tecnológico fascista dominado por unos pocos actores, con control y falta de innovación.
En última instancia, creo que una solución con posibilidades de éxito debe incluir tecnología abierta de certificación de hardware confiable, no basada en registros. Debe ser posible crear una fuerte atestación local y verificarla de forma independiente.
Conozco algunas empresas tecnológicas que están abordando este problema desde el lado del silicio, pero es un problema muy difícil, y tampoco está claro si hoy existe suficiente demanda para que sobrevivan.
Personalmente, por ahora voy a dejar esto activado en Safari y observar qué pasa durante los próximos 1 o 2 años.
La tecnología DRM también se discute en estos términos, pero su objetivo no es dar confianza al usuario, sino dársela al desarrollador o al dueño del contenido.
Se ve claramente que quizá esto en realidad no sea un asunto de confianza.
Hay que elegir si se quieren disfrutar los beneficios del sistema estatal y si vale la pena asumir sus costos.
El problema de la mayoría de estos sistemas es que no manejan en absoluto las excepciones.
Funcionan bien para el 99% de la población, pero al 1% restante básicamente le dicen que se las arregle como pueda.
Es como intentar acceder a la oficina después del horario laboral solo para recoger las llaves del auto que olvidaste, y que un robot te niegue la entrada.
El sistema está diseñado de forma segura, así que no puedes convencer al robot hablando. Si hubiera sido una persona, por lo general habría sido mucho más fácil convencerla conversando y encontrar una solución que funcionara.
Los tecnólogos terminan intentando resolverlo todo con tecnología. “Si hay un problema, yo lo resuelvo; mira mi tecnología mientras el DJ pincha”.
Así es como terminan hackeándose cuentas bancarias solo porque alguien habla bien y puede construir una historia plausible para convencer a un guardián humano.
Si fuera un medio para decir “sí, esta persona es una persona real”, podría ser útil, pero esto es una simple atestación del sistema, así que no hay forma de saber si puede detener a actores maliciosos ni si será malinterpretado y mal utilizado como otros sistemas, como CORS.
La conclusión lógica de este sistema es: “si tienes un sistema normal, eres un usuario normal; si no, no”.
Entiendo en cierta medida ambas posturas
Si asumimos buenas intenciones en los demás, una web poblada por humanos identificados y sus agentes autorizados podría ser el espacio web ideal más “limpio” que podamos imaginar
Una web llena de cuentas falsas y granjas de enlaces no es ideal
El punto final más claro de esta tendencia es una identificación digital emitida por el gobierno que demuestre la identidad y también funcione como inicio de sesión
Si uno entrecierra los ojos, esto puede parecer un peldaño hacia allá
¿Es la materialización del idealismo de los años 70? No. Pero lo veo como un compromiso razonable hasta cierto punto
¿Y si no se puede confiar en el gobierno? Probablemente eso no lo pueda resolver ningún internet. Es un problema del mundo real
A mí me suena más a una web esterilizada
Dejando de lado por un momento el hecho de que los humanos terminarán encontrando cómo eludir también ese sistema, incluso si asumimos que se convierte en el espacio web más “limpio”, se está dando por hecho que los consumidores quieren eso
En el mundo de las apps nativas ya existen la App Store, controles de bloqueo e identificabilidad de las apps, pero la web sigue dominando el comercio y, con casos como Figma, parece estar fortaleciéndose aún más
Entonces, ¿dónde está el clamor por esta web “purificada”? Al menos del lado de los consumidores, no se ve para nada esa demanda
¿Por qué se necesita una prueba de identidad tan absurdamente fuerte? Si de verdad era necesaria, ¿cómo funcionó internet hasta ahora?
Pero, en la práctica, actualmente nadie está proponiendo algo así. Ni el enfoque de Apple ni el de Google se acercan siquiera. Lo que dicen que harán es garantizar la “integridad” de la plataforma
¿Exactamente qué integridad? En el ejemplo, se dice que muestra que el usuario está ejecutando un cliente web en un dispositivo Android seguro
Es decir, no te dice si el usuario es una persona única ni te da un identificador útil sobre la persona. En este ejemplo, y en el caso de Apple, lo único que informa es que el dispositivo no está rooteado ni tiene jailbreak
En realidad, este concepto solo es útil como parte de un juego más grande del gato y el ratón. Al igual que la protección de derechos de autor, la atestación remota está limitada por aquello que realmente demuestra
Así como es difícil impedir que alguien grabe con una videocámara en una sala de cine y, al final, hay muchos pasos intermedios que aprovechan el hecho de que una película es una secuencia de fotos y cuadros de muestras PCM, aunque los dispositivos sean caros no se puede impedir que alguien consiga varios y los use para trabajar
Ya hay muchas personas con montones de dispositivos Android para engañar sistemas y, en algunos casos, se pueden comprar por 50 dólares cada uno, así que no es una barrera significativa
Al final, solo aumenta el costo y la complejidad de operar bots, y si se eleva lo suficiente el punto de equilibrio, en teoría se podría decir que se ganó. Pero no sucederá, porque las ganancias potenciales del spam y el fraude son demasiado grandes
Tras años de contramedidas, todavía no estamos ni cerca, y el dinero que fluye hacia la industria dedicada a engañar estos sistemas alcanza de sobra para cubrir esos costos
Mezclar identificaciones gubernamentales no cambia las cosas. Detrás de casi toda operación de spam hay personas reales, así que aunque recibas una prueba ciega de que alguien es ciudadano, sabes muy poco sobre esa persona
Para que ayudara, tendría que ser algo como recibir el ID único real de cada persona, no una prueba de que es un sujeto legítimo
Y si ese es el destino final de internet, francamente todo este experimento no valió la pena
También pueden conectar un mouse o teclado falso para suministrar la entrada directamente
El hardware de seguridad no parece tener ventajas. Para quienes difunden desinformación a cierta escala, ni siquiera sería un tope de velocidad
Solo incomodaría un poco a actores maliciosos muy inexpertos o menores, y restringiría mucho a quienes pueden crear navegadores y a quienes usan dispositivos no confiables, como usuarios de Linux o personas que desactivan Trusted Boot
No sé si recuerdan AllAdvantage
Era un servicio de alrededor del cambio de siglo que pagaba por mostrar anuncios en el escritorio, pero solo pagaba cuando realmente se estaba usando la PC
La gente lo engañaba con dispositivos para mover el mouse, y se desató una pequeña carrera armamentista
Esta tecnología sería un sueño para ellos. Podrían saber si una solicitud viene de un navegador real o de un script, y también podrían desactivar la atestación si se simula la entrada con un controlador no confiable o si el navegador está automatizado
Es una tecnología realmente desagradable
Esto se parece más a integrar de forma estrecha en el propio navegador una categoría muy popular de productos de seguridad
Hoy puedes adoptar una postura filosófica y rechazar todos los sitios web que usan reCAPTCHA/hCAPTCHA, y mañana podrás rechazar todos los sitios web que usan PAT