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.
They can, if those other websites provide an accompanying extension for it. Are you aware that the Zoom website can use the Zoom extension to have that exact same type of interactions?
In fact, that’s literally how other videoconferencing websites operate and have been since forever (the dreaded cisco webex extension comes to mind). The only difference is that GMeet can be counted as a part of the browser itself, so it requires no additional extension.
> GMeet can be counted as a part of the browser itself, so it requires no additional extension.
That is the enraging part. If I install extensions, I am aware that they could send information and diagnostic stuff. Plain websites shouldn't be able to. Also (not 100% sure here), afaik Firefox tells me which information the extension gets, so there's even more awareness about the information sent.
Also, which VC websites are you talking about? Zoom doesn't need a extension, BigBlueButton and Jitsy don't need a extension, afaik Teams also doesn't need it. People using WebEx certainly don't care about privacy so actually I would leave that out. (Googled it, since I never use it: apparently WebEx also doesn't use an extension anymore, although I remember the old plugin that they required some time ago, that barely worked at all)
Cisco is the only recent-ish video chat app I can think of that has required an extension.
The other I can remember is original Hangouts about a decade ago, cause at the time WebRTC wasn't commonly supported. Chrome was the only browser that didn't need an extension for that, but you know what, other VC apps were free to use Chrome's early WebRTC features too, and they later did.
Unequivocally, why can’t other video chat companies provide their own browser? They could presumably fork chromium and change a single string (if it’s really just “*.google.com”).
Obviously that’d go nowhere and no one would use it, but I can’t imagine this really matters to any competitor anywhere.
Think even bigger, why not reinvent the wheel every time every product is developed? Why have a common platform for anything?
If you think about it, what value is there in all these companies using the same roads to ship products? Can't they build their own? And is it really important that every business accept the same currency?
Yes, platform independence and shared universal access to common standards that consumers can consistently trust to provide similar experiences across products and ecosystems does admittedly reduce wasted development resources, increase competition, and makes the market more accessible to new businesses. And sure, I guess technically it reduces consumer confusion, and sure it benefits consumers by making products and services more interoperable. But who are we to say that any of that is good? /s
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?
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.
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.