The name hangout_services suggests this is some old tech debty hack intended to make developing Google Hangouts easier by giving that team a direct stream of telemetry. For those who have forgotten, Hangouts was the first app that did video calling in the browser using what became WebRTC. If you look at what this module is doing it's exposing stuff like CPU/GPU/RAM usage/hardware details back to the app that it wouldn't normally have.
My guess is that Google will react to this Twitter thread by simply deleting it. Hangouts has been a dead product for a while; if their server side code still uses it they can surely remove it as presumably the Chrome team monitor WebRTC performance themselves in a multi-site way now, given the much wider usage.
No, this is used by Google Meet right now. Open the "Troubleshooting" panel in meet.google.com in Chrome, and you'll see live system wide CPU usage reporting :)
Apart from the privacy violation, isn't this a clear antitrust issue - Google is misusing their Browser dominance to give themselves and edge in the videoconferencing space.
Could it be that it tracks CPU / GPU usage etc to finetune what quality video streams to use? It's nonstandard but I can well imagine a native app would do this as well.
I might be able to shed some light on this (disclaimer: Xoogler).
I worked for a time on Google's internal videoconferencing platform, called GVC. This was in 2010-2011 at a time when a lot of the company's VC equipment was proprietary, specifically Cisco Tandberg units. These were expensive and would be expensive to roll out to thousands of meeting rooms.
around this time a different team was developing Hangouts. It's been awhile so my memory may be off but I think it was called Google Meet at the time? or maybe that was later? It's hard to keep track. I think Hangouts was the name adopted when Google+ came along and rolled Hangouts into its product offering.
There were different configurations of GVC but the most common were these All-in-One ("AIO") monitor/computer combos. It was a full Intel PC. So the GVC platform was a custom Linux distro. The system was designed so GVCs could talk to Google services, which was nontrivial, and so software updates could be rolled out. It kept old distros too in case one didn't boot. These GVCs had to be named and a whole bunch of other issues.
Additionally they needed support for various hardware like a touch panel to dial. Larger units required larger PTZ camera support and support for various microphones.
Anyway, Hangouts became the stack GVC was built on. This ultimately replaced virtually all Tandbergs and saved a fortune. This system was certainly still in use by 2017. I can't speak for later.
Monitoring was a part of all this. So when I see there are *.google.com specific APIs, we need to be sure we're talking about this accurately. Like can Google query any Chrome instance in the world? Or is it only from/to google.com? I don't know the answer and the Tweet doesn't specify.
But given the name hangouts_services and the domain restriction I consider it highly likely this is purely to support monitoring embedded Chrome for GVC. I could be wrong.
I don't think it's this. Tried a Meet call in Firefox just now. If you click the troubleshooting button, there's a CPU chart greyed out that says "try Chrome to see your CPU usage." Sure enough, in Chrome you can view how much CPU Meet is using, or maybe it's systemwide idk, either way I don't think is available through regular APIs. Edit: Definitely systemwide as confirmed with some `yes` background tasks.
P.S. The naming confusion always comes up. GVC is such a nice clear name.
It's a nice story but it doesn't plausibly have any remote connection to this. I'm sure the people running the GCV platform with a custom Linux distro have some other way of reporting machine stats than literally "put our custom extension into every Chrome install ever".
> Like can Google query any Chrome instance in the world? Or is it only from/to google.com?
I'm sorry, I don't understand the distinction you're trying to make? Yes, it sounds like the API is exposed just to the content running on *.google.com, but that's still a lot like "Google can query any Chrome instance" (that visits their site, but that's ~100% given that even if you don't visit Google services, Chrome pulls in NTP content from Google by default).
I don't think this is being used maliciously, but it's still problematic if Google can troubleshoot problems this way, and their competitors in the same space can't. There's no API for Zoom, right?
I never worked at Google.... but this doesn't track for me.
You're saying the reason the 'retail' Google Chrome has this bundled plugin is so Google can get observability on CPU usage on internal appliances for an internal video conferencing platform?
I'm not sure what these APIs are exactly and why they're there, but Firefox also does something similar. It has special APIs available only to Mozilla and/or Firefox domains, for things like installing extensions, or helping with first-run experience.
A blog post about it was shared here on Hacker news <12 months ago, but I'm having trouble finding it...
apis are public, documented and the domain allowlist is both included in the UI and about:config (save from android playstore version where they hide everything to make the browser pure garbage for whatever reason)
and I'm pretty sure devs would at least think about adding your domain by default if you ask nicely with a great use case on bugzilla.
But that is for websites directly related to operating the browser, whereas chrome is exposing APIs used by unrelated google products such as google meet.
This could possibly also be a violation of anti-trust laws since it is using a monopoly in one market (browsers) to get an advantage in another (video conferencing).
It's pretty standard among browsers. The risk should be about equal to someone spoofing the domains that the browser downloads software updates from, and you can turn it off via prefs if you really don't want it.
Those are APIs related to browser functionality and onboarding. They're not there to advantage one of Mozilla's other product offerings at the expense of similar products offered by other companies.
Yes and they should also be criticized for it. Mozilla isn't exactly known for caring about privacy even if their marketing wants you to believe otherwise.
As for the anti-trust aspect, here the market share matters and Firefox is insignificant in that regard.
Disclaimer: I work at Google, but not on Chrome or on these APIs.
I think the explanation is quite mundane. An example usage: open google meet, start an empty meeting (an “instant meeting”), click the “…” menu, click “troubleshooting and help”.
There’ll be plots of various stats, including CPU utilization. I think meet will also helpfully suggest closing tabs if your machine is overloaded during a meet call, too.
It’s very helpful, I check it from time to time.
Edit: now that I think about it, I’m not sure about the suggestion to close tabs is actually a thing. I’ve only actually used the stats view.
> There’ll be plots of various stats, including CPU utilization. I think meet will also helpfully suggest closing tabs if your machine is overloaded
This is not mundane at all, it's a perfect example of giving your product an unfair competitive advantage.
If Meet users are told why their meeting isn't working correctly but Zoom, Teams and Slack, Meet users are going to have a better experience that Zoom, Teams or Slack has no way of replicating.
No wonder every other meeting provider pushes you aggressively into using their desktop app, Google Meet's desktop app is just Chrome!
I believe this is the point, rather than being mundane. Other video conference tools are not able to offer this debugging option - which you have pointed out is useful.
You have a competitor, Zoom. They have an in-browser version. Can they use this API for troubleshooting performance issues? No? The European regulators might be interested in that.
Perhaps this is one reason why Meet performs well in the browser and Zoom doesn't, meaning Zoom users use the native app if they want reasonable performance (particularly with many people in the meeting).
I agree it is very useful! This is also how I discovered this in the first place.
But that is not at all my point. The point is that google.com web properties have access to an API and a browser capability that is not available to it's competitors. Google only allows reading CPU info for itself.
The reason the data is not available for everyone, is because it would be a huge tracking vector. Same reason we don't allow webpages to read the device hostname, or username, or Chrome profile name. Google exposes this to google.com because it trusts itself. That poses this antitrust issue though.
This explanation was the first I read of what this actually does (yeah, yeah, I didn’t read the linked article first) and that’s a lot worse than I expected.
Yeah a whole lot of things really do seem mundane... once you have already accepted the fact you are tracked down to the cpu-percentage-usage-in-time level
I think the submission is a bit wrong in editing the title from the original. I understood it like this:
Chrome has a built-in extension that uses public Chrome APIs that are easily available to other Chrome extensions. The issue described is that this extension shares this information to Google's own domains when they're communicating with the
extension, while other websites can't do this.
Safari also has some Apple specific features, like being able to show a special dialog for logging into other websites with your Apple account that works differently from passkeys or password autofill, or the redirect based flow they make other browsers go through.
Always wondered how it's implemented in JS. WebAuthn with proprietary arguments...?
Google has done this sort of thing before. My memory is fuzzy as to the details, but I think it was Native Client being allowlisted at the domain level to only work on Hangouts, or something like that.
I briefly worked on Internet Explorer in ages past. They would develop APIs with the Windows team for use in IE to give IE special features that other browsers couldn't implement.
So this is a lot like Microsoft using specialized formats or APIs in Windows that competitors cannot access, which was a problem throughout the 90s. The problem never went away - it has just changed appearance.
> So, Google Chrome gives all *.google.com sites full access to system / tab CPU usage, GPU usage, and memory usage. It also gives access to detailed processor information, and provides a logging backchannel.
So I guess the question becomes how quickly you can spoof this ?
You can build Chrome without this by setting `enable_hangout_services_extension` to false. Of course, then none of the WebRTC stuff on google.com will work.
If it's really accessible from *.google.com, wouldn't this be simple to verify/exploit by using Google Sites (they publish your site to sites.google.com/view/<sitename>)?
[+] [-] mike_hearn|1 year ago|reply
My guess is that Google will react to this Twitter thread by simply deleting it. Hangouts has been a dead product for a while; if their server side code still uses it they can surely remove it as presumably the Chrome team monitor WebRTC performance themselves in a multi-site way now, given the much wider usage.
[+] [-] lucacasonato|1 year ago|reply
[+] [-] account42|1 year ago|reply
[+] [-] Cthulhu_|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] cletus|1 year ago|reply
I worked for a time on Google's internal videoconferencing platform, called GVC. This was in 2010-2011 at a time when a lot of the company's VC equipment was proprietary, specifically Cisco Tandberg units. These were expensive and would be expensive to roll out to thousands of meeting rooms.
around this time a different team was developing Hangouts. It's been awhile so my memory may be off but I think it was called Google Meet at the time? or maybe that was later? It's hard to keep track. I think Hangouts was the name adopted when Google+ came along and rolled Hangouts into its product offering.
There were different configurations of GVC but the most common were these All-in-One ("AIO") monitor/computer combos. It was a full Intel PC. So the GVC platform was a custom Linux distro. The system was designed so GVCs could talk to Google services, which was nontrivial, and so software updates could be rolled out. It kept old distros too in case one didn't boot. These GVCs had to be named and a whole bunch of other issues.
Additionally they needed support for various hardware like a touch panel to dial. Larger units required larger PTZ camera support and support for various microphones.
Anyway, Hangouts became the stack GVC was built on. This ultimately replaced virtually all Tandbergs and saved a fortune. This system was certainly still in use by 2017. I can't speak for later.
Monitoring was a part of all this. So when I see there are *.google.com specific APIs, we need to be sure we're talking about this accurately. Like can Google query any Chrome instance in the world? Or is it only from/to google.com? I don't know the answer and the Tweet doesn't specify.
But given the name hangouts_services and the domain restriction I consider it highly likely this is purely to support monitoring embedded Chrome for GVC. I could be wrong.
[+] [-] hot_gril|1 year ago|reply
P.S. The naming confusion always comes up. GVC is such a nice clear name.
[+] [-] stefan_|1 year ago|reply
You can try it for yourself, just
on any *.google.com page.[+] [-] doe_eyes|1 year ago|reply
I'm sorry, I don't understand the distinction you're trying to make? Yes, it sounds like the API is exposed just to the content running on *.google.com, but that's still a lot like "Google can query any Chrome instance" (that visits their site, but that's ~100% given that even if you don't visit Google services, Chrome pulls in NTP content from Google by default).
I don't think this is being used maliciously, but it's still problematic if Google can troubleshoot problems this way, and their competitors in the same space can't. There's no API for Zoom, right?
[+] [-] madeofpalk|1 year ago|reply
You're saying the reason the 'retail' Google Chrome has this bundled plugin is so Google can get observability on CPU usage on internal appliances for an internal video conferencing platform?
[+] [-] deanCommie|1 year ago|reply
So it's possible most of Google didn't even know this was possible until know.
Until know.
Now there's probably DOZENS of Product Managers approaching their product's tech lead going "OK, now...hear me out...."
[+] [-] simonw|1 year ago|reply
[+] [-] madeofpalk|1 year ago|reply
A blog post about it was shared here on Hacker news <12 months ago, but I'm having trouble finding it...
[+] [-] jhdifdhsak|1 year ago|reply
apis are public, documented and the domain allowlist is both included in the UI and about:config (save from android playstore version where they hide everything to make the browser pure garbage for whatever reason)
and I'm pretty sure devs would at least think about adding your domain by default if you ask nicely with a great use case on bugzilla.
[+] [-] thayne|1 year ago|reply
This could possibly also be a violation of anti-trust laws since it is using a monopoly in one market (browsers) to get an advantage in another (video conferencing).
[+] [-] Osmose|1 year ago|reply
It's pretty standard among browsers. The risk should be about equal to someone spoofing the domains that the browser downloads software updates from, and you can turn it off via prefs if you really don't want it.
[+] [-] xxmarkuski|1 year ago|reply
[0] https://news.ycombinator.com/item?id=40631439
[+] [-] kelnos|1 year ago|reply
[+] [-] account42|1 year ago|reply
As for the anti-trust aspect, here the market share matters and Firefox is insignificant in that regard.
[+] [-] _9yre|1 year ago|reply
I think the explanation is quite mundane. An example usage: open google meet, start an empty meeting (an “instant meeting”), click the “…” menu, click “troubleshooting and help”.
There’ll be plots of various stats, including CPU utilization. I think meet will also helpfully suggest closing tabs if your machine is overloaded during a meet call, too.
It’s very helpful, I check it from time to time.
Edit: now that I think about it, I’m not sure about the suggestion to close tabs is actually a thing. I’ve only actually used the stats view.
[+] [-] miki123211|1 year ago|reply
> There’ll be plots of various stats, including CPU utilization. I think meet will also helpfully suggest closing tabs if your machine is overloaded
This is not mundane at all, it's a perfect example of giving your product an unfair competitive advantage.
If Meet users are told why their meeting isn't working correctly but Zoom, Teams and Slack, Meet users are going to have a better experience that Zoom, Teams or Slack has no way of replicating.
No wonder every other meeting provider pushes you aggressively into using their desktop app, Google Meet's desktop app is just Chrome!
[+] [-] john-n|1 year ago|reply
[+] [-] not2b|1 year ago|reply
Perhaps this is one reason why Meet performs well in the browser and Zoom doesn't, meaning Zoom users use the native app if they want reasonable performance (particularly with many people in the meeting).
[+] [-] RIMR|1 year ago|reply
Very cool of you as a Google employee to say the quiet part out loud for us.
[+] [-] oldkinglog|1 year ago|reply
[+] [-] 3D30497420|1 year ago|reply
[+] [-] lucacasonato|1 year ago|reply
But that is not at all my point. The point is that google.com web properties have access to an API and a browser capability that is not available to it's competitors. Google only allows reading CPU info for itself.
The reason the data is not available for everyone, is because it would be a huge tracking vector. Same reason we don't allow webpages to read the device hostname, or username, or Chrome profile name. Google exposes this to google.com because it trusts itself. That poses this antitrust issue though.
[+] [-] tamimio|1 year ago|reply
[+] [-] vundercind|1 year ago|reply
This explanation was the first I read of what this actually does (yeah, yeah, I didn’t read the linked article first) and that’s a lot worse than I expected.
[+] [-] trickstra|1 year ago|reply
[+] [-] heavyset_go|1 year ago|reply
[+] [-] creatonez|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] jhdifdhsak|1 year ago|reply
my guess would also include some nifty debug info from FLoC ;)
[+] [-] beefnugs|1 year ago|reply
[+] [-] Tiberium|1 year ago|reply
Chrome has a built-in extension that uses public Chrome APIs that are easily available to other Chrome extensions. The issue described is that this extension shares this information to Google's own domains when they're communicating with the extension, while other websites can't do this.
There's no "special hidden API".
[+] [-] tantalor|1 year ago|reply
https://developer.chrome.com/docs/extensions/reference/api/s...
You can see all the permissions requested by this extension here:
https://source.chromium.org/chromium/chromium/src/+/main:chr...
[+] [-] MisterDizzy|1 year ago|reply
[+] [-] Pesthuf|1 year ago|reply
Always wondered how it's implemented in JS. WebAuthn with proprietary arguments...?
[+] [-] pcwalton|1 year ago|reply
[+] [-] leros|1 year ago|reply
[+] [-] blackeyeblitzar|1 year ago|reply
[+] [-] htrp|1 year ago|reply
So I guess the question becomes how quickly you can spoof this ?
[+] [-] dijit|1 year ago|reply
That file was very telling to be honest and was well commenter. Firefox has a similar file.
[+] [-] jeffbee|1 year ago|reply
[+] [-] bonestamp2|1 year ago|reply
[+] [-] daitangio|1 year ago|reply
[+] [-] simonw|1 year ago|reply
[+] [-] lashkari|1 year ago|reply
[+] [-] theshrike79|1 year ago|reply
It's turning (and mostly has already turned) into the new Internet Explorer.
Use Safari or Firefox, or any other browser that's not based on Chromium.