Google Chrome propose une API accessible uniquement depuis `*.google.com`

• Google Chrome propose une API qui n’autorise l’accès à l’utilisation CPU du système/de l’onglet, à l’utilisation du GPU, à l’utilisation de la mémoire, aux informations détaillées sur le processeur et à un backchannel de journalisation que pour les sites *.google.com
• Cette même API n’est pas exposée aux autres sites, ce qui alimente la controverse sur le fait qu’un éditeur de navigateur puisse accorder des privilèges spéciaux à son propre site web
• Le DMA inscrit dans la loi l’idée qu’un éditeur de navigateur, en tant que gatekeeper d’internet, doit fournir les mêmes fonctionnalités à tous ; selon l’interprétation, le fait de n’exposer des informations supplémentaires qu’aux propriétés de Google pourrait constituer une violation du DMA
• Zoom pourrait être désavantagé face à la concurrence, car il ne bénéficie pas des mêmes fonctions de débogage CPU que Google Meet
• Cette fonctionnalité est implémentée sous la forme d’une extension Chrome intégrée qui ne peut pas être désactivée et n’apparaît pas dans le panneau des extensions ; la même fonctionnalité n’est fournie que pour le domaine *.google.com dans Microsoft Edge et Brave également

---

Informations exposées par l’API réservée à *.google.com

• Chrome fournit des informations proches du diagnostic et sur l’état du système uniquement aux sites *.google.com
  • Utilisation CPU du système et de l’onglet
  • Utilisation du GPU
  • Utilisation de la mémoire
  • Informations détaillées sur le processeur
  • Backchannel de journalisation
• La même API n’est pas exposée aux autres sites et ne peut être utilisée que sur le domaine *.google.com

Mode d’implémentation et comportement des navigateurs dérivés de Chromium

• Cette fonctionnalité est implémentée sous la forme d’une extension Chrome intégrée qui ne peut pas être désactivée et n’apparaît pas dans le panneau des extensions
• Le code source se trouve dans le chemin hangout_services de Chromium
• On ne savait pas clairement si la même extension était aussi incluse dans d’autres navigateurs dérivés de Chromium, mais les mises à jour suivantes ont confirmé le comportement ci-dessous
  • Dans Microsoft Edge aussi, cette fonctionnalité est fournie uniquement pour le domaine *.google.com
  • Brave embarque également une extension préinstallée qui permet à Google de récupérer ces informations uniquement sur *.google.com, avec le même comportement que Chrome et Edge

Enjeux de concurrence et de régulation

• Si un navigateur ne fournit des informations système qu’à certains de ses propres domaines, les autres services web ont plus de mal à implémenter des fonctions de diagnostic du même niveau
• Zoom est cité comme exemple de service qui ne bénéficie pas des mêmes fonctions de débogage CPU que Google Meet, ce qui peut soulever la question d’un traitement préférentiel des services de l’éditeur
• Du point de vue du DMA, la question centrale reste de savoir si un gatekeeper doit garantir un accès équivalent aux fonctionnalités

[GN⁺]

Avis sur Hacker News

• Le nom hangout_services donne l’impression d’un vieux hack issu de dette technique, créé pour faciliter le développement de Google Hangouts
  Ça semblait sans doute destiné à envoyer directement des données de télémétrie à l’équipe Hangouts. Hangouts a été la première application à implémenter les appels vidéo dans le navigateur, et cela a ensuite donné WebRTC. Ce module expose l’utilisation du CPU/GPU/RAM et des informations matérielles que les applications ne peuvent normalement pas voir. Google va probablement voir ce fil Twitter et simplement le supprimer. Hangouts est déjà un produit mort, et même si du code côté serveur l’utilise encore, l’usage de WebRTC est aujourd’hui bien plus large, donc l’équipe Chrome surveille probablement directement les performances via une approche multi-sites

  • Non, c’est utilisé actuellement dans Google Meet. Si on ouvre le panneau « Troubleshooting » de meet.google.com dans Chrome, on voit en temps réel l’utilisation CPU de l’ensemble du système :)
  • Au-delà de l’atteinte à la vie privée, ça ressemble clairement à un problème antitrust, non ? Google abuse de sa domination sur le navigateur pour donner un avantage à son propre produit sur le marché de la visioconférence
  • Je me demande si ça ne sert pas à suivre l’usage CPU/GPU, etc., afin d’ajuster finement la qualité du flux vidéo à utiliser
    Ce n’est pas standard, mais une application native ferait tout à fait ce genre de chose

• Je peux peut-être apporter un peu de contexte sur cette partie. Pour référence, je suis un ancien employé de Google
  J’ai travaillé un temps sur GVC, la plateforme interne de visioconférence de Google. En 2010-2011, une grande partie des équipements de visioconférence de l’entreprise étaient des matériels propriétaires comme Cisco Tandberg, très coûteux, et leur déploiement dans des milliers de salles de réunion revenait cher. À peu près à la même époque, une autre équipe développait Hangouts, même si je ne me souviens plus si cela s’appelait déjà Google Meet à l’époque ou si ce nom est venu plus tard. Il me semble que le nom Hangouts a été adopté quand le produit a été intégré à Google+. Les configurations GVC variaient, mais la plus courante était une combinaison moniteur/ordinateur tout-en-un (AIO), qui était un véritable PC Intel. La plateforme GVC reposait donc sur une distribution Linux personnalisée, conçue pour communiquer avec les services Google et déployer des mises à jour logicielles. Elle conservait aussi d’anciennes distributions en cas d’échec de démarrage, et il y avait toutes sortes de problèmes comme la dénomination des équipements. Il fallait également prendre en charge divers matériels comme des écrans tactiles, de grandes caméras PTZ et plusieurs microphones. Au final, Hangouts est devenu la pile de base de GVC et a remplacé presque tous les Tandberg, ce qui a permis d’économiser beaucoup d’argent. Ce système était encore clairement utilisé en 2017, mais je ne sais pas après. Comme la supervision en faisait aussi partie, s’il existe vraiment une API réservée à *.google.com, il faut regarder cela précisément. Impossible de savoir, à partir du seul Tweet, si Google peut interroger toutes les instances Chrome du monde ou seulement celles sur google.com. Cela dit, vu le nom hangouts_services et la restriction de domaine, il est très plausible qu’il s’agisse d’un support de supervision pour Chrome embarqué dans GVC. Je peux me tromper

  • Je ne pense pas que ce soit ça. Je viens d’essayer un appel Meet dans Firefox, et si on clique sur le bouton de dépannage, le graphique CPU est désactivé avec un message disant « utilisez Chrome pour voir l’utilisation CPU »
    Dans Chrome, on peut voir l’utilisation CPU, sans savoir si c’est celle de Meet ou celle de tout le système, mais dans les deux cas ça ne semble pas possible via une API standard. J’ai vérifié avec quelques tâches yes en arrière-plan, et c’est clairement l’ensemble du système. Cela dit, la confusion sur les noms arrive toujours, mais GVC est vraiment un nom clair et bien choisi
  • Histoire intéressante, mais il ne semble pas y avoir le moindre lien, même lointain, avec ce cas. Les gens qui faisaient tourner la plateforme GCV sur une distribution Linux personnalisée n’ont probablement pas choisi comme méthode de remontée des statistiques machine « mettons l’extension personnalisée qu’on a créée dans toutes les installations Chrome du monde »
    On peut le tester directement depuis n’importe quelle page en *.google.com :
    chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });
  • Je ne comprends pas bien la distinction entre « Google peut interroger toutes les instances Chrome du monde » et « c’est possible uniquement sur google.com »
    L’API semble n’être exposée qu’aux contenus exécutés sur *.google.com, mais cela revient presque à dire que « Google peut interroger toutes les instances Chrome qui visitent ses sites ». Même sans utiliser les services Google, Chrome récupère par défaut le contenu de la page Nouvel onglet depuis Google, donc on est en pratique très proche des 100 %. Je ne pense pas que ce soit utilisé de manière malveillante, mais si Google peut diagnostiquer des problèmes de cette façon et que les concurrents dans le même domaine ne le peuvent pas, ça reste un problème. Zoom n’a pas une telle API, si ?
  • Je n’ai jamais travaillé chez Google, mais cette explication ne me paraît pas très convaincante
    Tu veux dire que, pour observer l’utilisation CPU sur des appliances internes de visioconférence, ils ont intégré ce plugin bundlé dans Google Chrome destiné au grand public ?
  • Intéressant. Il est possible que la plupart des équipes chez Google n’aient même pas su jusqu’à présent que c’était possible
    J’imagine déjà des dizaines de product managers aller voir le lead technique de leur produit avec un « écoute, attends une seconde… »

• Cette fonctionnalité semble avoir été ajoutée en octobre 2013 : https://github.com/chromium/chromium/commit/422c736b82e7ee76...
  C’est le commit qui bundle l’extension Hangouts Services dans Chrome. BUG=291271, URL de review : https://codereview.chromium.org/35873003. L’URL de review en question est https://codereview.chromium.org/35873003

• Je ne sais pas exactement ce qu’est cette API ni pourquoi elle existe, mais Firefox fait quelque chose de similaire
  Il existe des API spéciales réservées aux domaines Mozilla et Firefox, par exemple pour l’installation d’extensions ou l’accompagnement de la première utilisation. Un billet de blog à ce sujet est passé sur Hacker News il y a moins de 12 mois, mais il est difficile à retrouver

  • Ce n’est pas tout à fait la même chose
    L’API est publique et documentée, et la liste des domaines autorisés est présente dans l’interface et dans about:config. La version Android du Play Store est une exception, puisqu’elle cache tout, comme si le but était de transformer le navigateur en déchet absolu. Et si vous arrivez sur Bugzilla avec un bon cas d’usage et une demande polie, les développeurs examineront probablement au moins l’ajout de domaines par défaut
  • C’est destiné à des sites web directement liés à l’exploitation du navigateur. Chrome, en revanche, expose une API utilisée par un produit Google distinct, comme Google Meet
    Cela pourrait donc relever du droit de la concurrence, puisqu’il s’agit d’exploiter un monopole sur un marché — le navigateur — pour obtenir un avantage sur un autre, la visioconférence
  • J’avais écrit il y a longtemps à propos de la partie UITour : https://www.mkelly.me/blog/content-uitourjs/
    C’est une approche assez standard parmi les navigateurs. Le niveau de risque devrait être comparable à celui d’une usurpation du domaine depuis lequel le navigateur télécharge ses mises à jour logicielles, et si vous détestez vraiment ça, vous pouvez le désactiver dans les préférences
  • Le mois dernier, un commit WebKit sur Quirks.cpp a été partagé [0]. Ce n’est probablement pas ce que vous cherchiez, mais ça donne une impression similaire
    [0] https://news.ycombinator.com/item?id=40631439
  • Ces API concernent les fonctionnalités du navigateur et l’onboarding. Elles n’ont pas été ajoutées pour avantager un autre produit de Mozilla par rapport à des produits similaires d’autres entreprises

• Pour information, je travaille chez Google, mais pas sur Chrome ni sur cette API
  L’explication me paraît assez banale. Par exemple, si vous ouvrez Google Meet, démarrez une réunion vide — une « réunion instantanée » — puis cliquez sur « … » puis « Dépannage et aide », vous obtenez plusieurs graphiques de statistiques, y compris l’utilisation CPU. Il me semble aussi qu’en cas de forte charge sur la machine pendant un appel Meet, il suggère gentiment de fermer des onglets. C’est assez utile, donc il m’arrive de le consulter. En y repensant, je ne suis plus certain que la suggestion de fermer des onglets existe vraiment ; en pratique, je n’ai utilisé que l’écran des statistiques

  • Contrairement à l’idée que l’explication serait « assez banale », ce n’est absolument pas banal. C’est un exemple parfait d’avantage concurrentiel déloyal accordé à son propre produit
    Les utilisateurs de Meet reçoivent des indications sur les raisons d’un dysfonctionnement, alors que Zoom, Teams et Slack ne peuvent pas faire la même chose ; l’expérience Meet ne peut donc qu’être meilleure. Il n’est pas étonnant non plus que tous les autres services de réunion poussent activement leurs applications desktop. L’application desktop de Google Meet, c’est essentiellement Chrome
  • Au contraire, c’est précisément le cœur du sujet. Les autres outils de visioconférence ne peuvent pas proposer ce type d’option de débogage, et comme vous venez de le dire, cette fonctionnalité est utile
  • Le concurrent Zoom a une version navigateur. Peut-elle utiliser cette API pour diagnostiquer des problèmes de performance ? Si ce n’est pas le cas, les régulateurs européens pourraient s’y intéresser
    C’est peut-être aussi une des raisons pour lesquelles Meet fonctionne bien dans le navigateur alors que Zoom non, et pourquoi les utilisateurs de Zoom finissent par utiliser l’application native s’ils veulent des performances correctes, surtout quand il y a beaucoup de participants
  • Super, Google a créé un navigateur anticoncurrentiel qui fournit des fonctions utiles uniquement à lui-même
    Merci à l’employé de Google d’avoir dit tout haut la partie qu’il aurait été facile de passer sous silence
  • Le transfert de pouvoir monopolistique n’a rien de banal, c’est illégal

• Le titre soumis semble avoir été légèrement déformé par rapport à l’original. Si j’ai bien compris, voici de quoi il s’agit
  Chrome intègre une extension interne qui utilise une API Chrome publique, accessible assez facilement à d’autres extensions Chrome aussi. Le problème est que cette extension partage ces informations lorsqu’elle communique avec des domaines appartenant à Google, alors que les autres sites web ne le peuvent pas. Il n’y a pas d’« API spéciale cachée »

  • Le côté « spécial » vient du fait qu’elle est intégrée à Chrome, et non installée par l’utilisateur comme les autres extensions
    Le côté « caché » vient du fait qu’elle n’apparaît pas dans la liste si l’on va sur chrome://extensions. Et comme cela a déjà été dit, c’est aussi une API Chrome
  • Si vous collez ceci dans la console Chrome DevTools d’un site Google, cela ressemble à une API spéciale :
    chrome.runtime.sendMessage( 'nkeimhogjdpnpccoofpliimaahmaaome', { method: 'cpu.getInfo' }, response => { console.log('CPU Info:\n', JSON.stringify(response, null, 2)); } );
  • Même s’il s’agit d’une « extension intégrée », si elle ne peut pas être désactivée, elle fait toujours partie du navigateur
  • On peut aussi en donner une explication inoffensive et simple. On peut imaginer qu’une partie des fonctionnalités du navigateur est implémentée non pas en C++ compilé/lié, mais sous forme de web app signée google.com
    Il serait étrange qu’un code du navigateur implémenté en PWA doive demander une autorisation distincte pour accéder aux informations système, puisque cela fait partie intégrante des fonctionnalités du navigateur. Un autre usage de longue date de cette API privée consiste à intégrer le navigateur Chrome à des sites Google réservés comme le Chrome Web Store, qui fournissent des fonctions essentielles, en permettant l’installation et la suppression d’extensions depuis une page web
  • Fonctionnellement, c’est la même chose

• On dirait que cela utilise l’API chrome.system.cpu, à laquelle n’importe quelle extension peut accéder si elle dispose de l’autorisation "system.cpu"
  https://developer.chrome.com/docs/extensions/reference/api/s...
  Toutes les autorisations demandées par cette extension sont visibles ici :
  https://source.chromium.org/chromium/chromium/src/+/main:chr...

  • Exact, et c’est précisément le problème. Google intègre à Chrome une extension sans rapport avec le fonctionnement du navigateur lui-même, afin d’accorder un accès privilégié à un autre produit, Hangouts
    Les autres applications de visioconférence n’ont pas ce type d’accès, sauf si l’utilisateur passe par l’étape importante consistant à installer manuellement une extension séparée

• Ce n’est pas très surprenant. C’est tout à fait le genre de chose que ferait Google. La question est de savoir si c’est aussi présent dans les autres navigateurs Chromium. Qu’en est-il d’Edge, Brave, Chromium et Ungoogled Chromium ?

  • Je ne sais pas pour les autres, mais ungoogled chromium ne l’a probablement pas, puisqu’il brouille volontairement toutes les occurrences de la chaîne "google" dans le code précisément pour éviter ce genre de choses
  • C’est activé dans Edge. Si on ouvre le dépannage de Google Meet dans Edge, on peut voir le CPU du système
    Si on essaie dans Firefox, il affiche « pour voir l’utilisation du CPU, essayez d’utiliser Google Chrome »

• Safari a aussi des fonctionnalités réservées à Apple. Par exemple, lors de la connexion à d’autres sites web avec un compte Apple, il peut afficher une boîte de dialogue spéciale qui fonctionne différemment des passkeys ou du remplissage automatique des mots de passe
  Dans les autres navigateurs, cela passe par un flux fondé sur des redirections. Je me suis toujours demandé comment cela était implémenté en JavaScript. Une sorte de WebAuthn avec des arguments propriétaires ?

• Google a déjà fait ce genre de chose auparavant. Les détails sont flous, mais il me semble que Native Client ne fonctionnait que pour Hangouts via une liste d’autorisation au niveau du domaine, ou quelque chose dans ce genre