Google Chrome bietet eine API, die nur auf *.google.com zugänglich ist

 (twitter.com/lcasdev)
2 Punkte von GN⁺ 2024-07-10 | 1 Kommentare | Auf WhatsApp teilen
  • Google Chrome bietet eine API, die nur auf Websites unter *.google.com Zugriff auf System-/Tab-CPU-Auslastung, GPU-Auslastung, Speichernutzung, detaillierte Prozessorinformationen und einen Logging-Backchannel erlaubt
  • Auf anderen Websites ist dieselbe API nicht verfügbar, was die Frage aufwirft, ob ein Browser-Anbieter seiner eigenen Website Sonderrechte einräumen darf
  • Der DMA schreibt die Idee gesetzlich fest, dass Browser-Anbieter als Internet-Gatekeeper allen dieselben Funktionen bereitstellen müssen; je nach Auslegung könnte die Offenlegung zusätzlicher Informationen nur für Google-Eigenschaften einen Verstoß gegen den DMA darstellen
  • Zoom könnte im Wettbewerb benachteiligt sein, weil es nicht dieselben CPU-Debugging-Funktionen wie Google Meet erhält
  • Die Funktion ist als integrierte Chrome-Erweiterung implementiert, die sich nicht deaktivieren lässt und auch nicht im Erweiterungs-Panel erscheint; dieselbe Funktion wird in Microsoft Edge und Brave ebenfalls nur für die Domain *.google.com bereitgestellt

Welche Informationen die API nur für *.google.com offenlegt

  • Chrome stellt nur Websites unter *.google.com systemnahe Status- und nahezu debuggingrelevante Informationen bereit
    • CPU-Auslastung des Systems und des Tabs
    • GPU-Auslastung
    • Speichernutzung
    • Detaillierte Prozessorinformationen
    • Logging-Backchannel
  • Dieselbe API wird anderen Websites nicht offengelegt und ist nur auf der Domain *.google.com nutzbar

Implementierung und Verhalten in Chromium-basierten Browsern

  • Die Funktion ist als integrierte Chrome-Erweiterung umgesetzt, die sich nicht deaktivieren lässt und auch nicht im Erweiterungs-Panel angezeigt wird
  • Der Quellcode befindet sich im Chromium-Pfad hangout_services
  • Zunächst war unklar, ob dieselbe Erweiterung auch in anderen Chromium-basierten Browsern enthalten ist, doch ein späteres Update bestätigte folgendes Verhalten
    • Auch in Microsoft Edge ist diese Funktion ausschließlich für die Domain *.google.com verfügbar
    • In Brave ist ebenfalls eine Erweiterung vorinstalliert, die Google erlaubt, diese Informationen nur auf *.google.com abzurufen; das Verhalten entspricht damit Chrome und Edge

Wettbewerbs- und Regulierungsfragen

  • Wenn ein Browser Systeminformationen nur für bestimmte eigene Domains bereitstellt, können andere Webdienste Diagnosefunktionen auf demselben Niveau nur schwer umsetzen
  • Als Beispiel wird Zoom genannt, das nicht dieselben CPU-Debugging-Funktionen wie Google Meet erhält; dies könnte auf eine Bevorzugung eigener Dienste durch den Browser-Anbieter hinauslaufen
  • Aus DMA-Sicht bleibt die zentrale Frage, ob Gatekeeper den Zugang zu Funktionen gleichwertig für alle bereitstellen müssen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-07-10
Meinungen auf Hacker News

  • Der Name hangout_services sieht nach einem alten technischen Schulden-Hack aus, der die Entwicklung von Google Hangouts erleichtern sollte.
    Vermutlich war er dazu gedacht, Telemetriedaten direkt an das Hangouts-Team durchzureichen. Hangouts war die erste App, die Videoanrufe im Browser umgesetzt hat, und daraus wurde später WebRTC. Dieses Modul legt CPU-/GPU-/RAM-Auslastung und Hardwareinformationen offen, die eine App normalerweise nicht sehen kann. Google wird diesen Twitter-Thread vermutlich sehen und es einfach entfernen. Hangouts ist längst ein totes Produkt, und selbst wenn serverseitiger Code es noch nutzt, ist WebRTC heute viel breiter im Einsatz; das Chrome-Team dürfte die Performance daher direkt über mehrere Sites hinweg überwachen.

    • Nein, das wird derzeit in Google Meet verwendet. Wenn man in Chrome auf meet.google.com das Panel „Troubleshooting“ öffnet, sieht man die systemweite CPU-Auslastung in Echtzeit :)
    • Abgesehen vom Datenschutz scheint mir das ein klares Kartellrechts-Thema zu sein. Google missbraucht seine Browser-Dominanz, um dem eigenen Produkt im Videokonferenzmarkt einen Vorteil zu verschaffen.
    • Vielleicht dient es auch dazu, durch das Tracking von CPU-/GPU-Auslastung usw. fein abzustimmen, welche Qualität des Videostreams verwendet werden soll.
      Es ist zwar nicht standardisiert, aber eine native App würde so etwas durchaus tun.

  • Dazu kann ich vielleicht etwas erklären. Zur Einordnung: Ich bin ehemaliger Google-Mitarbeiter.
    Ich habe einmal an GVC, der internen Videokonferenzplattform von Google, gearbeitet. Um 2010–2011 herum bestand ein großer Teil der Videokonferenztechnik des Unternehmens aus proprietären Geräten wie Cisco Tandberg; sie waren teuer, und der Rollout in Tausende Konferenzräume kostete entsprechend viel. Etwa zur gleichen Zeit entwickelte ein anderes Team Hangouts; ich erinnere mich nicht mehr genau, ob es damals schon Google Meet hieß oder erst später so genannt wurde. Der Name Hangouts wurde, glaube ich, übernommen, als es mit dem Erscheinen von Google+ in das Produkt integriert wurde. Es gab verschiedene GVC-Konfigurationen, aber die häufigste war eine All-in-One(AIO)-Monitor-/Computer-Kombination, also ein vollwertiger Intel-PC. Deshalb war die GVC-Plattform eine angepasste Linux-Distribution, die dafür ausgelegt war, mit Google-Diensten zu kommunizieren und Softwareupdates auszurollen. Für den Fall von Boot-Fehlern wurde auch eine ältere Distribution vorgehalten, und es gab diverse Themen wie die Benennung der Geräte. Außerdem mussten unterschiedliche Hardwarekomponenten unterstützt werden, etwa Touchpanels, große PTZ-Kameras und mehrere Mikrofone. Am Ende wurde Hangouts zum Basis-Stack von GVC und ersetzte fast alle Tandberg-Systeme, was eine Menge Geld sparte. Dieses System war definitiv bis 2017 im Einsatz; danach weiß ich es nicht. Monitoring gehörte ebenfalls dazu. Wenn also eine API nur für *.google.com auftaucht, muss man genau hinschauen. Ob Google alle Chrome-Instanzen weltweit abfragen kann oder ob das nur auf google.com möglich ist, lässt sich allein aus dem Tweet nicht erkennen. Angesichts des Namens hangouts_services und der Domain-Beschränkung wirkt es aber sehr wahrscheinlich, dass es sich um Monitoring-Unterstützung für ein eingebettetes Chrome in GVC handelt. Ich kann mich natürlich irren.

    • Ich glaube nicht, dass es das ist. Ich habe gerade in Firefox einen Meet-Anruf ausprobiert; wenn man auf den Troubleshooting-Button klickt, ist das CPU-Diagramm deaktiviert und es erscheint der Hinweis „Verwenden Sie Chrome, um die CPU-Auslastung zu sehen“.
      In Chrome kann man die CPU-Auslastung sehen, wobei ich nicht weiß, ob es die von Meet oder die des gesamten Systems ist; so oder so scheint das nicht über eine normale API möglich zu sein. Mit ein paar yes-Hintergrundjobs habe ich es geprüft: Es ist eindeutig das ganze System. Nebenbei: Namensverwirrung gibt es immer, aber GVC ist wirklich ein klarer und guter Name.
    • Interessante Geschichte, aber es scheint keine Möglichkeit zu geben, dass sie auch nur entfernt mit diesem Fall zusammenhängt. Leute, die die GCV-Plattform mit einer angepassten Linux-Distribution betreiben, hätten wohl kaum als Methode zum Melden von Maschinenstatistiken gewählt: „Lasst uns unsere eigene Custom-Erweiterung in jede Chrome-Installation weltweit einbauen.“
      Man kann es direkt auf jeder beliebigen *.google.com-Seite ausprobieren:
      chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });
    • Ich verstehe die Unterscheidung zwischen „ob Google alle Chrome-Instanzen weltweit abfragen kann oder ob das nur auf google.com möglich ist“ nicht so ganz.
      Die API scheint zwar nur für Inhalte offengelegt zu werden, die auf *.google.com laufen, aber das ist praktisch fast dasselbe wie „Google kann alle Chrome-Instanzen abfragen, die seine Site besuchen“. Selbst wenn man keine Google-Dienste nutzt, lädt Chrome standardmäßig Inhalte für die Neuer-Tab-Seite von Google, also liegt das faktisch nahe bei 100 %. Ich glaube nicht, dass es böswillig genutzt wird, aber wenn Google auf diese Weise Probleme diagnostizieren kann und Wettbewerber im selben Bereich nicht, bleibt es trotzdem ein Problem. Zoom hat so eine API doch nicht, oder?
    • Ich habe nie bei Google gearbeitet, aber diese Erklärung überzeugt mich nicht.
      Soll das heißen, dass man dieses gebündelte Plugin in Google Chrome für normale Nutzer eingebaut hat, um auf internen Appliances einer internen Videokonferenzplattform die CPU-Auslastung zu beobachten?
    • Interessant. Vielleicht wusste bis jetzt sogar der Großteil von Google nicht, dass das möglich ist.
      Jetzt gehen vermutlich Dutzende Produktmanager zu den Tech Leads ihrer Produkte und sagen: „Also, hört erst mal zu …“

  • Diese Funktion scheint im Oktober 2013 hinzugefügt worden zu sein: https://github.com/chromium/chromium/commit/422c736b82e7ee76...
    Es ist ein Commit, der die Hangouts-Services-Erweiterung in Chrome bündelt. BUG=291271, Review-URL: https://codereview.chromium.org/35873003. Die betreffende Review-URL lautet https://codereview.chromium.org/35873003.

  • Ich weiß nicht genau, was diese API ist und warum es sie gibt, aber Firefox macht etwas Ähnliches.
    Es gibt spezielle APIs, die nur auf Mozilla- und Firefox-Domains genutzt werden können, etwa zur Unterstützung bei der Installation von Erweiterungen oder beim First-Run-Erlebnis. Vor weniger als 12 Monaten gab es dazu einen Blogbeitrag auf Hacker News, aber er ist schwer zu finden.

    • Das ist nicht annähernd dasselbe.
      Die APIs sind öffentlich und dokumentiert, und die Domain-Allowlist ist sowohl in der UI als auch in about:config enthalten. Die Android-Play-Store-Version ist eine Ausnahme, weil dort alles versteckt ist – als wolle man den Browser zu reinem Müll machen. Und wenn man in Bugzilla mit einem guten Use Case höflich anfragt, würden die Entwickler vermutlich zumindest prüfen, ob sie eine Standard-Domain hinzufügen.
    • Das ist für Websites gedacht, die direkt mit dem Betrieb des Browsers zusammenhängen. Chrome hingegen stellt eine API bereit, die von separaten Google-Produkten wie Google Meet genutzt wird.
      Das könnte ein Verstoß gegen das Kartellrecht sein, weil Google seine Monopolstellung in einem Markt, nämlich Browsern, nutzt, um sich in einem anderen Markt, Videokonferenzen, einen Vorteil zu verschaffen.
    • Ich habe vor langer Zeit einmal über den UITour-Teil geschrieben: https://www.mkelly.me/blog/content-uitourjs/
      Unter Browsern ist das eine ziemlich übliche Praxis. Das Risiko sollte in etwa dem entsprechen, dass jemand die Domain fälscht, von der der Browser Software-Updates herunterlädt; und wenn man es wirklich nicht mag, kann man es in den Einstellungen abschalten.
    • Letzten Monat wurde ein Commit zu WebKits Quirks.cpp geteilt [0]. Es ist vermutlich nicht das, was du gesucht hast, fühlt sich aber ähnlich an.
      [0] https://news.ycombinator.com/item?id=40631439
    • Solche APIs haben mit Browserfunktionen und Onboarding zu tun. Sie wurden nicht eingebaut, um ein anderes Mozilla-Produkt gegenüber ähnlichen Produkten anderer Unternehmen zu bevorzugen.

  • Zur Einordnung: Ich arbeite bei Google, aber nicht an Chrome oder dieser API.
    Die Erklärung wirkt auf mich ziemlich banal. Wenn man zum Beispiel Google Meet öffnet, ein leeres Meeting, also ein „Sofortmeeting“, startet und dann im „…“-Menü auf „Fehlerbehebung und Hilfe“ klickt, sieht man mehrere Statistikdiagramme, darunter zur CPU-Auslastung. Es scheint auch, als würde Meet während eines Anrufs freundlich vorschlagen, Tabs zu schließen, wenn die Maschine unter Last steht. Das ist ziemlich nützlich, deshalb schaue ich gelegentlich hinein. Wenn ich noch einmal darüber nachdenke, bin ich mir nicht sicher, ob es den Vorschlag zum Schließen von Tabs tatsächlich gibt; tatsächlich genutzt habe ich nur die Statistikansicht.

    • Entgegen der Beschreibung als „ziemlich banal“ ist das überhaupt nicht banal. Es ist ein perfektes Beispiel dafür, dem eigenen Produkt einen unfairen Wettbewerbsvorteil zu verschaffen.
      Meet-Nutzer bekommen Hinweise, warum ein Meeting nicht richtig funktioniert; wenn Zoom, Teams und Slack dasselbe nicht tun können, muss die Nutzungserfahrung von Meet zwangsläufig besser sein. Kein Wunder, dass alle anderen Konferenzdienste ihre Desktop-Apps so aggressiv pushen. Die Desktop-App von Google Meet ist im Grunde Chrome.
    • Genau das ist doch der Punkt. Andere Videokonferenz-Tools können diese Debugging-Optionen nicht anbieten, und wie gerade gesagt wurde, ist die Funktion nützlich.
    • Der Konkurrent Zoom hat eine Browser-Version. Kann sie diese API nutzen, um Performance-Probleme zu diagnostizieren? Wenn nicht, könnten sich europäische Regulierer dafür interessieren.
      Vielleicht ist das einer der Gründe, warum Meet im Browser gut funktioniert und Zoom nicht, sodass Zoom-Nutzer, die ordentliche Performance wollen, besonders bei vielen Teilnehmern, zur nativen App greifen.
    • Sehr schön, dass Google einen wettbewerbswidrigen Browser gebaut hat, der Funktionen bereitstellt, die nur ihnen selbst nützen.
      Danke, dass ein Google-Mitarbeiter den Punkt ausspricht, über den man sonst stillschweigend hinweggehen würde.
    • Übertragung von Marktmacht ist keine banale Sache, sondern illegal.

  • Beim Ändern des Einreichungstitels gegenüber dem Original scheint etwas schiefgelaufen zu sein. Nach meinem Verständnis ist es so:
    Chrome hat eine eingebaute Erweiterung, die eine öffentliche Chrome-API nutzt, die auch andere Chrome-Erweiterungen leicht verwenden können. Das Problem ist, dass diese Erweiterung diese Informationen teilt, wenn sie mit Googles eigenen Domains kommuniziert, andere Websites das aber nicht können. Es gibt keine „spezielle versteckte API“.

    • „Speziell“ bedeutet, dass sie nicht wie andere Erweiterungen vom Nutzer installiert wurde, sondern in Chrome eingebaut ist.
      „Versteckt“ bedeutet, dass sie auch unter chrome://extensions nicht in der Liste erscheint. Und wie bereits gesagt: Es ist auch eine Chrome-API.
    • Wenn man das in der Chrome-DevTools-Konsole auf einer Google-Website einfügt, sieht es wie eine Spezial-API aus:
      chrome.runtime.sendMessage( 'nkeimhogjdpnpccoofpliimaahmaaome', { method: 'cpu.getInfo' }, response => { console.log('CPU Info:\n', JSON.stringify(response, null, 2)); } );
    • Wenn man eine „eingebaute Erweiterung“ nicht deaktivieren kann, ist sie trotzdem Teil des Browsers.
    • Es gibt auch eine harmlose und einfache Erklärung. Man kann sich vorstellen, dass ein Teil der Browserfunktionalität nicht als kompiliertes/gelinktes C++ implementiert ist, sondern als von google.com signierte Web-App.
      Es wäre seltsam, wenn als PWA implementierter Browsercode eine separate Berechtigung anfordern müsste, um auf Systeminformationen zuzugreifen. Er ist schließlich Teil der Browserfunktion selbst. Eine weitere Verwendung schon lange existierender nicht öffentlicher APIs ist die Integration exklusiver Google-Websites, die Kernfunktionen bereitstellen, wie des Chrome Web Store, mit dem Chrome-Browser, sodass Webseiten die Installation und Entfernung von Erweiterungen erlauben können.
    • Funktional ist es dasselbe.

  • Das scheint die chrome.system.cpu-API zu verwenden, auf die jede Erweiterung zugreifen kann, wenn sie die Berechtigung "system.cpu" hat
    https://developer.chrome.com/docs/extensions/reference/api/s...
    Alle Berechtigungen, die diese Erweiterung anfordert, sind hier zu sehen:
    https://source.chromium.org/chromium/chromium/src/+/main:chr...

    • Genau, und das ist eben das Problem. Google bündelt eine Erweiterung, die nichts mit dem Verhalten des Browsers selbst zu tun hat, mit Chrome und gewährt damit einem anderen Produkt, Hangouts, privilegierten Zugriff
      Andere Videokonferenz-Apps haben diese Zugriffsrechte nicht, es sei denn, der Nutzer geht den großen zusätzlichen Schritt und installiert manuell eine separate Erweiterung

  • Nicht besonders überraschend. Sehr Google-typisch. Die Frage ist, ob das auch in anderen Chromium-Browsern steckt. Wie sieht es mit Edge, Brave, Chromium, Ungoogled Chromium aus?

    • Bei den übrigen weiß ich es nicht, aber ungoogled chromium dürfte das wahrscheinlich nicht haben, weil es absichtlich alle Stellen im Code durcheinanderbringt, an denen der String "google" vorkommt, um genau so etwas zu vermeiden
    • In Edge ist es aktiviert. Wenn man in Edge die Fehlerbehebung für Google Meet öffnet, kann man die System-CPU sehen
      Wenn man es in Firefox versucht, heißt es: „Um die CPU-Auslastung zu sehen, verwenden Sie Google Chrome“

  • Auch Safari hat Apple-spezifische Funktionen. Wenn man sich zum Beispiel mit einem Apple-Konto auf anderen Websites anmeldet, kann es einen speziellen Dialog anzeigen, der anders funktioniert als Passkeys oder das automatische Ausfüllen von Passwörtern
    Andere Browser müssen einen redirect-basierten Ablauf verwenden. Ich habe mich immer gefragt, wie das in JavaScript implementiert ist. Ist das so etwas wie WebAuthn mit proprietären Argumenten?

  • Google hat so etwas auch früher schon gemacht. Die Details sind verschwommen, aber ich glaube, Native Client war über eine Allowlist auf Domainebene so eingerichtet, dass es nur in Hangouts funktionierte, oder etwas in der Art