1 puntos por GN⁺ 2023-07-26 | 1 comentarios | Compartir por WhatsApp
  • En un issue de Mozilla standards-positions se pidió una postura sobre la API Web Environment Integrity, y Mozilla concluyó con position: negative al considerar que esta propuesta entra en conflicto con los principios de apertura de la web
  • La propuesta indica que el prototipo de Chromium actualmente depende de Google Play Integrity, pero que a nivel de especificación es neutral respecto del proveedor; quien hizo la solicitud expresó preocupación de que, como ocurrió con EME, en la práctica pueda consolidarse alrededor de unos pocos proveedores
  • Mozilla considera que esta API puede convertirse en un mecanismo para restringir la elección de dispositivo, sistema operativo y navegador, por lo que perjudica la apertura del ecosistema web y no es buena para los usuarios
  • Entre los casos de uso propuestos, la “detección de tráfico no humano” puede impedir usos ya existentes de la web que transforman, verifican, indexan o resumen contenido para personas, como las tecnologías de asistencia, las pruebas automatizadas, el archivado y los spiders de motores de búsqueda
  • Mozilla dijo que detectar fraude y tráfico inválido es un problema difícil y que le interesa resolverlo, pero considera que esta propuesta explica insuficientemente cómo haría avanzar los casos de uso reales y que su adopción tendría desventajas claras

Solicitud del issue y alcance de la propuesta

Preocupaciones iniciales planteadas

  • Quien hizo la solicitud puso como ejemplo a EME: aunque en teoría es neutral respecto del proveedor, en la práctica hay pocos proveedores ampliamente aceptados
    • Google Widevine: usado en Firefox, Chrome y Android en la mayoría de las plataformas
    • Microsoft PlayReady: usado en Microsoft Edge, Windows y junto con Widevine en algunos dispositivos Android
    • Apple FairPlay: usado en Safari y el ecosistema de Apple
  • Existe la preocupación de que la misma situación se repita con la API Web Environment Integrity, y que los sitios web terminen exigiendo navegadores preaprobados
  • Un comentario criticó que esta API no ofrece nada al usuario final y solo puede usarse para restringir a los usuarios, además de que la especificación es ambigua y el mecanismo subyacente no está claro

Razones de la oposición de Mozilla

  • Mozilla declaró que esta propuesta va en contra de los principios y la visión de la web de Mozilla
  • La visión web de Mozilla sostiene que los navegadores, servidores y publicadores que implementen estándares comunes deben convertirse automáticamente en parte de la web
  • Los estándares deben evitar suposiciones sobre el hardware o software que puede desplegarse, y ninguna entidad específica debería decidir qué formatos, dispositivos, sistemas operativos o navegadores pueden acceder a la web
  • Esta libertad de elección permite que personas diversas lleguen a la misma web en términos de tecnologías de asistencia, localización, formato y precio
  • Por lo tanto, los mecanismos que buscan restringir esa elección perjudican la apertura del ecosistema web y no son buenos para los usuarios

Problemas del caso de uso “detección de tráfico no humano”

  • Mozilla considera que los casos de uso propuestos dependen de la capacidad de “detect non-human traffic”
  • Ese enfoque podría obstaculizar usos ya existentes de la web
    • Tecnologías de asistencia

      • pruebas automatizadas
      • archivado
      • spiders de motores de búsqueda
      • Estas herramientas deben poder tomar contenido para personas y volver a transformarlo, probarlo, indexarlo o resumirlo para personas
      • El resguardo propuesto en el documento, “holdback”, o el método de hacer que la generación de attestation falle aleatoriamente, probablemente no sea efectivo y se considera insuficiente para resolver las preocupaciones planteadas por Mozilla

Conclusión y tratamiento del issue

  • Mozilla señaló que detectar fraude y tráfico inválido es un problema difícil y que tiene interés en resolverlo
  • Sin embargo, la propuesta de la API Web Environment Integrity no logra explicar cómo produciría un avance sustancial en los casos de uso enumerados, y presenta desventajas claras si se adopta
  • Con base en este análisis, un miembro de Mozilla etiquetó la postura sobre la propuesta como negative
  • Como esta propuesta proviene de un repositorio personal de GitHub y no es trabajo de una vía formal de estandarización ni de un grupo público de incubación, se consideró que no hacía falta una entrada aparte en el dashboard
  • El issue se cerró como completado después de recibir la etiqueta position: negative el 25 de julio de 2023

1 comentarios

 
GN⁺ 2023-07-26
Opiniones en Hacker News
  • El ataque funciona más o menos así: el atacante fabrica un dispositivo, como un smartphone, genera un par de claves y lo guarda dentro del HSM del dispositivo, normalmente llamado trusted enclave, y luego firma la clave pública con una clave maestra.
    El dispositivo ejecuta software del atacante y está diseñado para que, si el software elegido por el usuario se ejecuta con privilegios elevados, el HSM se entere de ese hecho de una forma que no puede revertirse hasta reiniciar. El HSM firma la frase “este dispositivo está ejecutando software del atacante” y el contenido que el software del atacante quiere transmitir, pero no firma si el software elegido por el usuario está en ejecución. Además incluye la clave pública firmada con la clave maestra, para que un cómplice pueda verificar que el dispositivo no está bajo el control del usuario, sino bajo el control de una entidad que restringe la libertad del usuario.
    Opcionalmente, esta prueba puede pasar por el servidor del atacante y convertirse en una nueva prueba que haya sido anonimizada o sometida a verificaciones de condiciones arbitrarias. Al final, con este método, un tercero obtiene la garantía de que el dispositivo está ejecutando software del atacante, y puede impedir que el usuario ejecute el software que quiera o hacer que use el dispositivo de la forma que el atacante y sus cómplices desean. Este ataque ya está en marcha en Android mediante SafetyNet y Play Integrity API de Google, y en iOS por parte de Apple, y ahora se está extendiendo a la web.

    • Me gusta que esto se defina como un ataque. Todavía no había logrado clasificar mentalmente a Google y sus amigos como “intermediarios”, pero en la práctica eso es exactamente lo que está pasando.
      Esta Web Integrity API es un medio para consolidarse no como intermediarios opcionales, sino como intermediarios obligatorios.
    • Sería útil presentar el problema con este encuadre en la prensa, blogs, etc. El otro lado ya está estirando a la fuerza el significado de las palabras, y fue realmente repugnante que presentaran el DRM como “la columna vertebral de la Internet abierta”.
    • En este escenario, el atacante fabrica mi hardware, lo cual no tiene sentido. Si esa es la situación, de todos modos puede hacer lo que quiera, y no parece muy distinto de “el atacante posee el hardware, así que literalmente todo es posible”.
      Además, este “atacante” no obtiene nada. No es un atacante, es el fabricante del dispositivo. Es raro, porque básicamente se está explicando el proceso de certificación remota llamando atacante al TPM.
    • Al final, por la realidad de enviar electricidad por cables, también hay efectos secundarios que no se pueden corregir: una parte adicional con suficiente capacidad para modificar el hardware todavía puede atacar al atacante y a sus cómplices.
      Por eso, este tipo de régimen traslada costos a los usuarios comunes, mientras solo beneficia a quienes tienen esa capacidad.
    • ¿Hay alguna forma de evitar este ataque usando un smartphone? Me viene a la mente el moribundo Ubuntu Phone.
  • Era algo esperable, pero no significa nada si no logramos mandar a la gente a Firefox y alejarla de la familia Chromium. Quienes han invertido en la seguridad, la protección y, en sentido amplio, la confianza de la web tienen cierta responsabilidad.
    Todavía no vi nada sobre si Brave lo va a soportar. Pero si lo entendí bien, mientras use Chromium no parece tener opción, y espero estar equivocado.

    • Viendo las críticas que Mozilla recibe en torno a esto, espero que al menos se le reconozca el mérito que merece.
      En última instancia, creo que deberíamos volver de forma permanente a una pantalla de elección de navegador respaldada por ley, como después del caso de la venta atada de IE. De lo contrario, la fricción y los incentivos seguirán consolidando aún más a un solo jugador dominante.
    • El resultado final probablemente será que los sitios con DRM y los sitios bancarios digan: “usa Chrome para continuar”. Los usuarios seguirán migrando a Chrome y Mozilla terminará viéndose obligada a implementarlo.
    • La expresión “seguridad y protección” se ha vuelto detestable para mucha gente. Porque evoca la distopía autoritaria que Google y otros están construyendo.
      Lo más importante son la libertad y la interoperabilidad.
    • Otra opción es que los administradores de sistemas u organizaciones de TI que atienden a pymes preinstalen Firefox en las estaciones de trabajo. Los usuarios se acostumbran a ese navegador y también pueden usarlo personalmente.
      De paso, también se puede preinstalar uBlock Origin. Nosotros hacemos eso.
    • Esa migración ocurrirá recién cuando la gente ya no pueda hacer en su navegador habitual las cosas que solía hacer. Pensé que Manifest V3 rompería los scripts de usuario y haría engorroso bloquear anuncios, pero por ahora eso no pasó, así que no he tenido motivo para dejar Chrome.
      Si esto se implementa, podría ocurrir que la identidad de un usuario se considere “insuficiente” y que no pueda acceder a ciertos sitios o servicios; entonces podría tener un incentivo para cambiarse a otro navegador que no tenga esta función.
  • Ya lo dije en otros lados, pero la gente tiene que usar Firefox. Si todos se detienen, no quedará nadie con voz para enfrentar las tonterías de Google. Google es dueño de Chrome y puede hacer lo que quiera.
    No digo que Firefox sea perfecto ni mejor, sino que es necesario. Necesitamos un navegador competidor con una cuota significativa, que tenga un motor de renderizado que Google no controle en última instancia. Si no, no queda más que dejar de quejarse y permitir que Google haga lo que quiera.

    • ¿No viene la mayor parte de los ingresos de Mozilla de la colocación pagada de Google como motor de búsqueda predeterminado? No sé si eso cambió en los últimos años.
      Buscando por encima, hace 5 a 10 años más del 50% de los ingresos venía de Google, pero no encontré datos más recientes. Si Google es la principal fuente de ingresos de Mozilla, especialmente si representa la mayoría, entonces Google en la práctica controla a Mozilla mediante la palanca de poder cortar su mayor fuente de ingresos.
      También surge la pregunta de qué empresa u organización debería desarrollar un navegador. Todos esperan que los navegadores sean gratis, pero desarrollarlos, operarlos y mantenerlos no es gratis. Las empresas de navegadores con fines de lucro como Brave no tienen más remedio que monetizar el navegador con cosas como el token cripto BAT o anuncios en la nueva pestaña.
    • Si Firefox realmente me sirviera, lo usaría, pero no es así, así que no puedo.
  • ¿Mozilla también podría aclarar su postura sobre su propia propuesta IPA, que rastrea a los usuarios en todo Internet?
    Si ves un anuncio de un producto en searchengine.example, luego buscas ese producto en reviews.example y después lo compras en shop.example, el navegador de Mozilla enviaría todos esos eventos a uno o más servicios de agregación, para que shop.example pueda entender, al menos a nivel agregado, que el usuario estuvo expuesto al anuncio en searchengine.example y también volvió a estar expuesto en reviews.example. Por supuesto, bajo la premisa de confiar en el cártel que opera los servicios de agregación.
    Antes, una empresa de tecnología publicitaria podía rastrear a los usuarios con base en la dirección IP de origen aunque desactivaran las cookies, pero IPA permite rastrearlos a través de múltiples direcciones IP mediante un identificador de seguimiento único, independientemente de la configuración de cookies. También se ha propuesto que el sistema operativo proporcione un identificador de seguimiento único utilizable por todas las apps y navegadores del dispositivo, lo que permitiría distinguir varios dispositivos detrás de la misma IP.
    https://github.com/patcg-individual-drafts/ipa/

    • Para que la publicidad funcione, la atribución es necesaria. Si no hay atribución independiente de la plataforma donde se compró el anuncio, esa plataforma publicitaria puede cometer fraude.
      Esto es algo distinto del seguimiento publicitario que construye perfiles de intereses de los usuarios, o del remarketing, donde se compran anuncios dirigidos a visitantes anteriores. La mayoría de los sistemas de atribución privada están diseñados para que el operador del anuncio pueda contar cuántas personas hicieron clic en un anuncio, pero no saber quién hizo clic ni qué más hizo. La propuesta de Safari tenía un límite en la cantidad de campañas ejecutables por dominio, para evitar crear una “campaña” separada por usuario y hacer fingerprinting de una sola vez. No sé en qué se diferencia la propuesta de Mozilla.
      Si los user agents deberían preocuparse por este tipo de cosas es una pregunta aparte.
      https://www.theregister.com/2023/06/29/google_trueview_skepticism/
      En particular, el remarketing es lo que genera esa “sensación de estar vigilado” de la publicidad moderna: buscas una cosa y durante toda la semana siguiente te persiguen diez mil anuncios de ese producto.
    • Viendo el texto original, parece que se puede preguntar por la postura de Mozilla abriendo un issue en GitHub en https://github.com/mozilla/standards-positions
    • Para ser justos, “Web Integrity”, es decir, la atestación remota o el agente de vigilancia corporativa metido en “mi” hardware, es un problema mucho más fundamental. Porque podría impedir directamente ejecutar un navegador derivado que elimine vulnerabilidades de seguridad intencionales como IPA.
      Es lamentable que Mozilla se acomode a basura como IPA, pero al menos por ahora el usuario tiene la libertad de desactivarla, eliminarla, hacer un fork, etc. En cambio, la atestación remota es prácticamente el fin del juego para el concepto mismo de user agent.
    • Por más mala que sea la propuesta de Mozilla, esto es una cortina de humo. Al final termina sirviendo a los intereses de Google y defendiendo una propuesta mucho más distópica.
    • Lo de que “el navegador de Mozilla envía todos esos eventos a uno o más servicios de agregación” se refiere a cuando el usuario lo permite.
  • Detección del navegador, detección del “entorno”
    Como forma de protesta, ciertos operadores de sitios web podrían diseñar sitios web inaccesibles desde Chrome. Sería interesante ver a Google intentando esquivar eso. Sobre todo si se vuelve popular solo entre sitios pequeños y no comerciales.

    • Buena idea. Podría ayudar entrenando a los usuarios para que usen varios navegadores con frecuencia. Mis hijos ya usan varios navegadores en sus dispositivos Android para bloquear anuncios de YouTube. Cuando hay una razón suficiente, la gente está dispuesta a usar otros navegadores.
      Eso sí, en vez de bloquearlo por completo, dejaría solo la funcionalidad imprescindible y seguiría indicando que cambien a otro navegador o usen algo como Tampermonkey. También habría que dar instrucciones claras sobre qué hacer.
      ¿Cuál sería una buena forma de detectar si esta función está soportada? ¿Una API de JavaScript?
    • Durante seis largos años, Chrome no pudo acceder a mi sitio web. Todos los demás navegadores sí podían, pero Chrome no respetaba una configuración del lado del servidor que forzaba la negociación solo de métodos que no fueran HTTP/3 y permitía únicamente ChaCha/Poly, excluyendo AES/RSA. Microsoft Edge lo arregló después de un tiempo.
      Por suerte, Google también lo arregló hace unos 4 meses. Varias herramientas gratuitas de pruebas cross-browser todavía pueden mostrar esa rotura mediante pruebas por versión.
    • Puede servir de referencia: https://news.ycombinator.com/item?id=25240299
  • Su contraparte móvil, la Play Integrity API, debería ilegalizarse y disputarse en los tribunales. Como la idea central es eliminar las ROM de terceros, creo que probablemente también contradice el derecho a reparar de la UE y las leyes sobre residuos electrónicos.
    Hay que empezar a redirigir el foco del debate hacia los problemas de seguridad que Google y su publicidad han creado.

    • Google está abusando de la computación confiable. Puedo entender que algunos bancos prefieran que el código de procesamiento de pagos se ejecute en dispositivos bloqueados, pero hoy esos dispositivos Android contienen adware y spyware de Google que no son necesarios en absoluto para un dispositivo confiable de pagos.
      Google debe dividirse para que sus intereses no contaminen Android y Chrome.
  • Quiero donar a Mozilla, pero me preocupa que mi dinero termine en los bolsillos de ejecutivos de nivel C. ¿Hay alguna forma de donar específicamente al equipo central de Firefox o a MDN?

    • Especificarlo así no tiene sentido desde la perspectiva de Mozilla. Aunque hubiera donaciones para Firefox, si no pueden pagarle al personal de limpieza de la oficina, la renta, ni a quienes se encargan de RR. HH., contabilidad y asuntos legales, no pueden contratar ni operar el “equipo central de Firefox y MDN”.
      Incluso un CEO que cobra una cantidad absurdamente excesiva es necesario para una empresa. No creo en el argumento de que en EE. UU. hay que pagar mucho para conseguir un buen CEO, pero un mal CEO puede destruir una empresa, como GE, Enron, Boeing o Twitter.
      Un ejemplo interesante de cómo fallan las restricciones sobre el uso del presupuesto es MARTA, en Atlanta. Hace tiempo, por una ley de financiamiento, se fijó una división 50/50 entre gastos operativos y gastos de capital; terminaron con trenes nuevos, pero todo lo demás se estaba viniendo abajo.
    • ¿Haces el mismo análisis con cada compra? La sandwichería donde compraste el almuerzo podría haber usado ese dinero para comprarles pizza al dueño y a su esposa, que ni siquiera trabajaron ese día. ¿Eso te molesta?
      Un negocio funciona así: entra dinero, sale dinero y se fabrican productos. Tú eliges si pagas o no por un producto que te gusta. Cómo usen el dinero que reciben es asunto de ellos.
    • Puedes hacer una donación restringida a Mozilla Foundation y, si la aceptan, quedan sujetos a esa restricción salvo que el donante acepte lo contrario.
      Pero el dinero es fungible. Si donas 500 dólares para apoyar a MDN, esos 500 dólares pueden reemplazar los 500 que antes iban a MDN desde los ingresos normales, y otros 500 dólares pueden terminar en bolsillos de nivel C o en Pocket, etc. Los dólares en sí van al destino designado, pero pueden habilitar otros gastos que no te gusten.
      En cambio, si donaras 50 mil millones de dólares para apoyar a MDN, sería un poco distinto. El presupuesto existente para MDN sin duda quedaría liberado, pero como es imposible que el gasto de MDN sea de 50 mil millones de dólares, el dinero que exceda las necesidades de MDN no tendría adónde ir.
    • Mozilla no es una cooperativa, es simplemente una entidad sin fines de lucro. Los desarrolladores también son empleados de esa entidad, como en cualquier otra empresa. Francamente, creo que la empresa tiene ingresos considerables y no depende mucho de las donaciones.
      Usar sus productos y convertirse en cliente probablemente sea más valioso para ellos y para su manifiesto.
    • Por ahora, lo más cercano es pagar por uno de sus productos. Están Pocket Premium, Firefox Relay y Mozilla VPN.
  • Mozilla puede oponerse, pero si se incorpora en Chrome y empieza a usarse activamente, al final lo implementarán como pasó con CDM.
    Al final, el usuario solo verá que cierto sitio web funciona en Chrome y no en Firefox. Cuando exista un costo real en forma de posible pérdida de cuota de mercado, Firefox decidirá que no tiene motivos para oponerse.

    • Basta con recordar cómo le fue en cuota de mercado a la estrategia de “no es Chrome, pero casi”. Ese tipo de usuario no tiene problema en usar Chrome directamente, así que puede que ese mercado en realidad no sea tan grande.
  • También vale la pena ver la postura de WebKit sobre estándares: https://webkit.org/standards-positions/
    Este caso aún no está reflejado y probablemente se opongan.

  • Hay una larga historia de hackers, en el sentido clásico, usando computadoras para hacer cosas que otras personas no querían, mientras esas otras personas no podían hacer nada o, a lo mucho, entraban en una carrera armamentista. Fue malo para ellos, pero muy bueno para la sociedad en conjunto.
    Eso dio origen a GNU, “IBM Compatible”, los bloqueadores de anuncios, Firefox, BitTorrent, YouTube ReVanced/youtube-dl y muchísimas otras cosas.
    El objetivo de la atestación de dispositivos para software de consumo es acabar con eso. Apple fue pionera en iOS, y ahora, por la fuerza del capitalismo, se está extendiendo a toda la computación. La atestación de dispositivos significa que los hackers pierden, y ese es un mal desenlace.
    Otra amenaza gemela es que la industria del software está poniendo en orden la seguridad de verdad. Antes era común hacer jailbreak a iOS, pero pasamos un año sin jailbreak de iOS. Rust tampoco ayuda.
    Nos estamos precipitando hacia un mundo en el que los productores y titulares de propiedad intelectual controlan por completo el contenido que crean, y mantienen ese estado mediante criptografía de punta y software extremadamente seguro pero hostil para el consumidor. Es uno de los desarrollos más peligrosos de la historia y, si se vuelve realidad, no se podrá revertir. Stallman tenía razón.

    • Bien resumido. En la práctica, toda esta basura de atestación, a mi modo de ver, es DRM. Claro, se comercializa como una función opcional que “puede mejorar la experiencia”.
      Es como decir que entregar la cartera a punta de pistola puede mejorar tu felicidad.