← Back to context

Comment by cletus

6 months ago

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.

  • This seems pretty unequivocal then- they're clearly using this to provide additional functionality to their own applications (at least Meet) that other companies who don't control the browser can't match.

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".

You can try it for yourself, just

    chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });

on any *.google.com page.

> 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?

  • That API is available to all extensions. So Zoom could create an extension that uses that API and get their users to install that extension and approve the permission for that API.

    • Is there a reason why Google can't get its users to install the extension and approve the permission for that API?

      I would theorize the reason Google doesn't go through that process is that it's unrealistic to expect users en mass to do that, and the only way to get wide rollout would be to build it into a browser by default and then for good measure to hide the fact that it's installed -- something which, notably, Zoom can't do.

      But I mean, if it's no big deal to get users to install an extension, then Google can stop bundling it by default and instead ask users to install it, 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 reading the tea leaves here. I have no direct knowledge of the situation. I'm retelling a story that seems (at least to me) to be consistent with what little information is here. There's plenty you can criticize Google on but I'm not sure this qualifies. Let's not attribute malice without cause. Or even negligence. It's fair to ask if this needs to be here still and what it's for. Let's just not fly off the handle prematurely.

    As for "retail" Chrome having this plugin, it would make total sense. Chrome is a massive codebase. Maintaining a fork is a significant amount of effort. It would be far easier to add APIs to Chrome and whitelist them for only google.com extensions/JS.

Fascinating!

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...."

  • There are zero product managers who read this Twitter thread about a random decade-old Chromium hack and will do anything about it.

    • 2.1M views on Twitter, thousands of comments on Reddit, a couple hundred comments on HN.

      yeah sure, no Google PMs are seeing this /s