Google Chrome ofrece una API accesible solo desde `*.google.com`

 (twitter.com/lcasdev)
2 puntos por GN⁺ 2024-07-10 | 1 comentarios | Compartir por WhatsApp
  • Google Chrome ofrece una API que permite acceso solo a sitios *.google.com al uso de CPU del sistema y de la pestaña, uso de GPU, uso de memoria, información detallada del procesador y acceso a un canal de registro de retorno
  • La misma API no está expuesta a otros sitios, lo que genera controversia sobre si un proveedor de navegador puede otorgar privilegios especiales a su propio sitio web
  • La DMA convierte en ley la idea de que los proveedores de navegadores, como guardianes de acceso de internet, deben ofrecer las mismas funciones a todos, y según la interpretación, exponer información adicional solo a propiedades de Google podría constituir una violación de la DMA
  • Zoom podría quedar en desventaja competitiva al no recibir las mismas funciones de depuración de CPU que Google Meet
  • Esta función está implementada como una extensión integrada de Chrome que no se puede desactivar y tampoco aparece en el panel de extensiones; la misma función también se ofrece solo al dominio *.google.com en Microsoft Edge y Brave

Información que expone la API exclusiva de *.google.com

  • Chrome ofrece información del estado del sistema y cercana a depuración solo a sitios *.google.com
    • Uso de CPU del sistema y de la pestaña
    • Uso de GPU
    • Uso de memoria
    • Información detallada del procesador
    • Canal de registro de retorno
  • La misma API no está expuesta a otros sitios y solo puede usarse en el dominio *.google.com

Forma de implementación y comportamiento en navegadores derivados de Chromium

  • Esta función está implementada como una extensión integrada de Chrome que no se puede desactivar y tampoco se muestra en el panel de extensiones
  • El código fuente está en la ruta hangout_services de Chromium
  • No estaba claro si la misma extensión también estaba incluida en otros navegadores derivados de Chromium, pero en una actualización posterior se confirmó el siguiente comportamiento
    • En Microsoft Edge, esta función también se ofrece solo para el dominio *.google.com
    • En Brave también viene preinstalada una extensión que permite a Google obtener esta información solo desde *.google.com, y muestra el mismo comportamiento que Chrome y Edge

Cuestiones de competencia y regulación

  • Si un navegador ofrece información del sistema solo a determinados dominios propios, a otros servicios web les resulta difícil implementar funciones de diagnóstico del mismo nivel
  • Se menciona a Zoom como un caso que no recibe las mismas funciones de depuración de CPU que Google Meet, lo que puede derivar en un problema de trato preferencial a servicios propios por parte del proveedor del navegador
  • Desde la perspectiva de la DMA, sigue en pie como cuestión central si un guardián de acceso debe ofrecer un acceso equivalente a las funciones

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-07-10
Opiniones de Hacker News

  • Por el nombre hangout_services, parece un hack antiguo de deuda técnica creado para facilitar el desarrollo de Google Hangouts.
    Probablemente servía para pasar datos de telemetría directamente al equipo de Hangouts. Hangouts fue la primera app en implementar videollamadas en el navegador, y eso después se convirtió en WebRTC. Este módulo expone uso de CPU/GPU/RAM e información de hardware que una app normalmente no podría ver. Creo que Google verá este hilo de Twitter y simplemente lo eliminará. Hangouts ya es un producto muerto y, aunque el código del lado del servidor todavía lo use, hoy WebRTC tiene un alcance mucho más amplio, así que el equipo de Chrome seguramente monitorea el rendimiento directamente con un enfoque multisitio.

    • No, esto se usa ahora en Google Meet. Si abres el panel de "Troubleshooting" de meet.google.com en Chrome, se ve en tiempo real el uso de CPU de todo el sistema :)
    • Más allá de la invasión a la privacidad, me parece que esto es claramente un tema antimonopolio. Google está abusando de su dominio del navegador para darle ventaja a su propio producto en el mercado de videoconferencias.
    • Quizás sea para ajustar con precisión qué calidad de stream de video usar, rastreando el uso de CPU/GPU y cosas similares.
      Aunque no sea estándar, es algo que una app nativa perfectamente podría hacer.

  • Creo que puedo explicar un poco esta parte. Como referencia, soy exempleado de Google.
    En su momento trabajé en GVC, la plataforma interna de videoconferencias de Google. Alrededor de 2010-2011, muchos de los equipos de videoconferencia de la empresa eran dispositivos propietarios como Cisco Tandberg, y eran caros, así que desplegarlos en miles de salas de reuniones costaba mucho. Más o menos por la misma época, otro equipo estaba desarrollando Hangouts; no recuerdo bien si en ese entonces se llamaba Google Meet o si tomó ese nombre después. Creo que el nombre Hangouts se adoptó cuando se integró al producto con la llegada de Google+. Había varias configuraciones de GVC, pero la más común era una combinación de monitor/computadora All-in-One (AIO), y era una PC Intel completa. Por eso la plataforma GVC era una distribución Linux personalizada, diseñada para comunicarse con servicios de Google y distribuir actualizaciones de software. También manteníamos una distribución antigua por si fallaba el arranque, y había varios problemas como la asignación de nombres a los equipos. También necesitábamos soporte para hardware diverso, como paneles táctiles, cámaras PTZ grandes y varios micrófonos. Al final, Hangouts se convirtió en la pila base de GVC y reemplazó casi todos los Tandberg, ahorrando muchísimo dinero. Sé con certeza que este sistema se usaba hasta 2017; después no lo sé. El monitoreo también era parte de eso, así que si se ve una API exclusiva para *.google.com, hay que mirarlo con precisión. Solo por el Tweet no se puede saber si Google puede consultar todas las instancias de Chrome del mundo, o si solo es posible desde google.com. Pero por el nombre hangouts_services y la restricción de dominio, parece muy probable que sea soporte de monitoreo de Chrome embebido para GVC. Podría estar equivocado.

    • No creo que sea eso. Acabo de hacer una llamada de Meet en Firefox, y al presionar el botón de solución de problemas, el gráfico de CPU aparece deshabilitado y muestra el texto "prueba Chrome para ver el uso de CPU".
      En Chrome se puede ver el uso de CPU, aunque no sé si es el de Meet o el de todo el sistema; en cualquier caso, no parece algo posible con una API normal. Lo comprobé con algunas tareas yes en segundo plano y definitivamente es de todo el sistema. Además, siempre hay confusiones con los nombres, pero GVC es un nombre realmente claro y bueno.
    • Historia interesante, pero no parece haber posibilidad de que esté conectada con este caso, ni siquiera remotamente. No creo que la gente que operaba la plataforma GCV con una distribución Linux personalizada haya elegido “metamos una extensión personalizada que hicimos en todas las instalaciones de Chrome del mundo” como forma de reportar estadísticas de las máquinas.
      Se puede probar directamente en cualquier página *.google.com:
      chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });
    • No entiendo bien la diferencia entre “si Google puede consultar todas las instancias de Chrome del mundo, o si solo es posible desde google.com”.
      La API parece estar expuesta solo al contenido que se ejecuta en *.google.com, pero aun así eso es casi lo mismo que “Google puede consultar todas las instancias de Chrome que visitan sus sitios”. Incluso si no usas servicios de Google, Chrome por defecto obtiene de Google el contenido de la página de nueva pestaña, así que en la práctica se acerca al 100%. No creo que se use con mala intención, pero si Google puede diagnosticar problemas de esta forma y sus competidores en el mismo rubro no, sigue siendo un problema. Zoom no tiene una API así, ¿no?
    • Nunca trabajé en Google, pero esta explicación no me convence.
      ¿O sea que para observar el uso de CPU en un appliance interno de una plataforma interna de videoconferencias, metieron este plugin incluido en Google Chrome para usuarios comunes?
    • Interesante. Tal vez la mayoría de Google tampoco sabía hasta ahora que esto era posible.
      Me imagino a decenas de gerentes de producto acercándose ahora a los tech leads de sus productos con un “bueno, primero escúchame…”.

  • Esta función parece haberse agregado en octubre de 2013: https://github.com/chromium/chromium/commit/422c736b82e7ee76...
    Es un commit que incluye en Chrome la extensión Hangouts Services. BUG=291271, URL de revisión: https://codereview.chromium.org/35873003. La URL de esa revisión es https://codereview.chromium.org/35873003.

  • No sé exactamente qué es esta API ni por qué existe, pero Firefox hace algo parecido.
    Tiene API especiales que solo se pueden usar en dominios de Mozilla y Firefox, como para ayudar con la instalación de extensiones o la experiencia del primer inicio. Hace menos de 12 meses se publicó en Hacker News una entrada de blog relacionada, pero cuesta encontrarla.

    • No es casi lo mismo.
      La API es pública y está documentada, y la lista de dominios permitidos también está en la UI y en about:config. La versión de Android Play Store es la excepción, porque esconde todo, como si quisieran convertir el navegador en pura basura. Además, si llevas un buen caso de uso y lo pides con respeto en Bugzilla, creo que los desarrolladores al menos considerarían agregar dominios predeterminados.
    • Eso es para sitios web directamente relacionados con la operación del navegador. En cambio, Chrome expone una API que usan productos separados de Google, como Google Meet.
      Como usa su monopolio en un mercado, el de los navegadores, para obtener ventaja en otro mercado, el de las videoconferencias, podría ser una violación de las leyes antimonopolio.
    • Hace tiempo escribí sobre la parte de UITour: https://www.mkelly.me/blog/content-uitourjs/
      Es una práctica bastante estándar entre los navegadores. El nivel de riesgo debería ser similar al de que alguien falsifique el dominio desde el que el navegador descarga actualizaciones de software, y si de verdad te molesta, puedes desactivarlo en las preferencias.
    • El mes pasado se compartió un commit de Quirks.cpp de WebKit [0]. Probablemente no sea lo que buscabas, pero tiene una sensación parecida.
      [0] https://news.ycombinator.com/item?id=40631439
    • Esas API están relacionadas con funciones del navegador y el onboarding. No se incluyeron para favorecer otros productos de Mozilla por encima de productos similares de otras empresas.

  • Como referencia, trabajo en Google, pero no en Chrome ni en esta API.
    La explicación me parece bastante normal. Por ejemplo, si abres Google Meet, inicias una reunión vacía, es decir, una “reunión instantánea”, y luego en el menú “…” haces clic en “Solución de problemas y ayuda”, aparecen varias gráficas de estadísticas, incluido el uso de CPU. También parece que, si la máquina está bajo carga durante una llamada de Meet, te sugiere amablemente cerrar pestañas. Es bastante útil y lo reviso de vez en cuando. Pensándolo de nuevo, no estoy seguro de que realmente exista la sugerencia de cerrar pestañas; lo que sí he usado es la pantalla de estadísticas.

    • A diferencia de la explicación de que es “bastante normal”, esto no tiene nada de normal. Es un ejemplo perfecto de darle una ventaja competitiva injusta a su propio producto.
      Si los usuarios de Meet reciben orientación sobre por qué una reunión no funciona bien, pero Zoom, Teams y Slack no pueden hacer lo mismo, la experiencia de uso de Meet inevitablemente será mejor. No sorprende que todos los demás servicios de reuniones insistan tanto en usar sus apps de escritorio. La app de escritorio de Google Meet es, básicamente, Chrome.
    • Más bien, ese es el punto. Otras herramientas de videoconferencia no pueden ofrecer estas opciones de depuración y, como acabas de decir, esa función es útil.
    • Zoom, que es competidor, tiene una versión para navegador. ¿Puede usar esta API para diagnosticar problemas de rendimiento? Si no puede, los reguladores europeos podrían interesarse.
      Tal vez esa sea una de las razones por las que Meet funciona bien en el navegador y Zoom no, y por la que, especialmente cuando hay muchos participantes en una reunión, los usuarios de Zoom terminan usando la app nativa si quieren un rendimiento adecuado.
    • Qué genial que Google haya creado un navegador anticompetitivo que ofrece funciones útiles solo para ellos.
      Gracias por decir directamente la parte que un empleado de Google normalmente dejaría pasar en silencio.
    • La transferencia de poder monopólico no es algo normal; es ilegal.

  • Creo que al cambiar el título del envío respecto del original se tergiversó un poco. Según lo entiendo, es esto:
    Chrome tiene una extensión integrada que usa API públicas de Chrome que otras extensiones de Chrome también pueden usar fácilmente. El problema es que esta extensión comparte esa información cuando se comunica con los propios dominios de Google, pero otros sitios web no pueden hacerlo. No hay ninguna “API oculta especial”.

    • “Especial” significa que no fue instalada por el usuario como otras extensiones, sino que viene integrada en Chrome.
      “Oculta” significa que no aparece en la lista aunque vayas a chrome://extensions. Y, como ya se dijo, también es una API de Chrome.
    • Si pegas esto en la consola de Chrome DevTools de un sitio de Google, se ve como una API especial:
      chrome.runtime.sendMessage( 'nkeimhogjdpnpccoofpliimaahmaaome', { method: 'cpu.getInfo' }, response => { console.log('CPU Info:\n', JSON.stringify(response, null, 2)); } );
    • Si no se puede desactivar una “extensión integrada”, sigue siendo parte del navegador.
    • También hay una explicación inocua y simple. Se puede imaginar que parte de la funcionalidad del navegador no está implementada como C++ compilado/enlazado, sino como una webapp firmada de google.com.
      Sería raro que código del navegador implementado como PWA tuviera que pedir permisos separados para acceder a información del sistema, porque forma parte de la propia funcionalidad del navegador. Otro uso de una API privada que existe desde hace mucho es integrar el navegador Chrome con sitios web exclusivos de Google que proporcionan funciones esenciales, como Chrome Web Store, permitiendo instalar y desinstalar extensiones desde una página web.
    • Funcionalmente es lo mismo.

  • Esto parece usar la API chrome.system.cpu, a la que cualquier extensión puede acceder si tiene el permiso "system.cpu"
    https://developer.chrome.com/docs/extensions/reference/api/s...
    Todos los permisos que solicita esta extensión se pueden ver aquí:
    https://source.chromium.org/chromium/chromium/src/+/main:chr...

    • Correcto, y ese es justamente el problema. Google está incluyendo en Chrome una extensión que no tiene relación con el funcionamiento propio del navegador, para darle acceso privilegiado a otro producto, Hangouts
      Otras apps de videoconferencia no tienen ese acceso a menos que el usuario pase por el gran paso de instalar manualmente una extensión aparte

  • No sorprende mucho. Es un comportamiento muy de Google. La cuestión es si esto también está en otros navegadores Chromium. ¿Qué pasa con Edge, Brave, Chromium y Ungoogled Chromium?

    • No sé los demás, pero ungoogled chromium probablemente no lo tenga, porque justamente para evitar cosas así mezcla deliberadamente todas las partes del código donde aparece la cadena "google"
    • En Edge está activado. Si abres la solución de problemas de Google Meet en Edge, puedes ver la CPU del sistema
      Si lo intentas en Firefox, dice “para ver el uso de CPU, prueba usar Google Chrome”

  • Safari también tiene funciones exclusivas de Apple. Por ejemplo, al iniciar sesión en otros sitios web con una cuenta de Apple, puede mostrar un cuadro de diálogo especial que funciona distinto del autocompletado de passkeys o contraseñas
    En otros navegadores te manda por un flujo basado en redirecciones. Siempre me dio curiosidad cómo está implementado eso en JavaScript. ¿Será algo como WebAuthn con argumentos propios?

  • Google ya ha hecho algo así antes. Los detalles los tengo algo borrosos, pero creo que Native Client estaba configurado para funcionar solo en Hangouts mediante una lista de permitidos a nivel de dominio, o algo por el estilo