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’ve tried Safari, I’ve tried the native app, and I’ve even tried the phone bridge (!).)
I had to re-read this a few times; did you accidentally omit a word?
> If Meet users are told why their meeting isn't working correctly but Zoom, Teams and Slack aren't, Meet users are going to have a better experience that Zoom, Teams or Slack has no way of replicating.
I fully agree with you, though; it's anticompetitive for them to use Chrome to give their other products an advantage.
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).
Very cool of you as a Google employee to say the quiet part out loud for us.
Edit: And for some reason I have a Chrome profile even though I never created one and never "logged into" Chrome. Another thing that's been forced on me by Google's product team.
But even that does not explain why the existence of the API was not disclosed. Do you agree that that looks bad for them?
Then there is the fact that Google is far from being a company people trust. They should be rushing to be transparent about their decision, if there is a good, persuasive reason for it. They could use the good press. Instead, they made a secret API that can read privileged system information, locked it so that nobody else could use it, and then never told anybody about it—all while claiming to be secure, and privacy-focused, and definitely not abusing their browser monopoly.
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.
my guess would also include some nifty debug info from FLoC ;)
So I guess the question becomes how quickly you can spoof this ?
But you could have teams with DNS zone delegation who can.create.anything.like.this.google.com
If that malicious actor can install a custom ca too, they can already install whatever spyware they want.
Only to leak your CPU/GPU utilization though as far as I understand it. Those can also be exposed in other ways by legitimate JS/WebGPU by measuring/profiling shader runs/etc.
[Google's browser] comes with [code] that [does things] in a default installation of [Google's browser] that [Google's competitors] can't do in a default installation of [Google's browser].
Ostensibly [Google's websites] are websites like any other, but [Google's browser] treats them differently. IIRC Mozilla does similar things for addons.mozilla.org, but googles seem more broad since they are not as clearly linked to browser functionality.
I'm still no sure why I should care.
... but other people remember that in the time since, that entire Microsoft monopoly fiasco is held up as an example of bad prosecution, and we don't go after companies like that anymore.
This, but also, I still don't see anyone posting a compelling reason why I should care about this issue. The government and I don't necessarily have the same interests. Personally I don't care that google gives their own browser more access to my computer when I use google services, and if it improves my experience, I actually want that to be the case.
The bulk of the complaints about this just seem to be tattletale behavior you see from children, not any thought out complaints based upon an actual harm.
[0]: https://www.zdnet.com/article/youtube-is-slowing-video-loads...
Is it just Google's competitors, or it is everyone?
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.
P.S. The naming confusion always comes up. GVC is such a nice clear name.
Here[0] are the docs for the specific one discussed above, for example.
0. https://developer.chrome.com/docs/extensions/reference/api/s...
Obviously that’d go nowhere and no one would use it, but I can’t imagine this really matters to any competitor anywhere.
You can try it for yourself, just
chrome.runtime.sendMessage("nkeimhogjdpnpccoofpliimaahmaaome", {"method":"cpu.getInfo"}, (resp) => { console.log(resp); });
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 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?
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?
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.
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...."
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.
Edit: I guess if you only want to make a local debug tool, you could make it callable only from a completely isolated sandbox. Maybe?
I worked at Google, and I can guarantee ya people don't go back and change names in old code for the latest rebrand done for eyewash 4 layers above me. Not out of laziness, either, it just has 0 value and is risky.
Also, video conference perf was/is a pretty big deal (c.f. variety of sibling comments pointing out where it is used, from gSuite admin to client app). It is great on ye olde dev machine but it's very, very hard on $300 WintelChromebook thrown at line-level employees
FWIW, they shouldn't have hacked this in, I do not support it. And I bet they'll just delete it anyway because it shouldn't have been there in the first place. Some line-level employee slapped it in because, in the wise words of Ian Hickson: "Decisions went from being made for the benefit of users, to the benefit of Google, to the benefit of whoever was making the decision."
But the Git history of it is fascinating, starting at the initial merge that got it in that went with the old school trick of "just call X to explain why this is needed" to get your stuff merged. Then every non-trivial change ever to it is inevitably auto-reverted due to some failure before being resubmitted, this must be the "unparalleled Google developer environment" in action - nobody can or bothers to run the tests on a piece of software this big. Half the commits are various formatting nonsense. One third is my favorite - someone making a change to an extension API only to realize the fucking hangout guys sneaked an actual extension into the code base and they will have to update that one to reflect their change. I can feel their anger personally.
(but yeah it would just be easier to yoink it)
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".
"hidden" in the sense that when I go to chrome://extensions it is not listed.
And as you already mentioned, it's a Chrome API.
chrome.runtime.sendMessage(
'nkeimhogjdpnpccoofpliimaahmaaome', {
method: 'cpu.getInfo'
}, response => {
console.log('CPU Info:\n', JSON.stringify(response, null, 2));
}
);It would be silly if that PWA-implemented browser code would need permission to access the system information, since it is part of the browser's functionality itself.
Another use case for a private API (that has long existed) is integration of the Chrome browser with Google-specific websites that provide core functionality, like the Chrome Web store, to allow for installation/removal of extensions from a web page.
If there exists a mundane and reasonable explanation for this, that doesn’t matter if there also exists a potential to exploit it in a way that harms consumers’ interests.
If this flag is true then the extension is added: https://source.chromium.org/chromium/chromium/src/+/main:chr... and https://source.chromium.org/chromium/chromium/src/+/main:chr...
If you don’t want to use Google’s browser, don’t use Google’s browser.
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.
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.
(Not that this is not the same thing as a website developer adding browser-specific hacks to make their site behave better/worse in a particular browser.)
As for the anti-trust aspect, here the market share matters and Firefox is insignificant in that regard.
If true, as usually, a lot of people have a Google tab open, you can easily deduct what it means.
This is definitely something to be investigated, for the moment, we only have a tweet.
No. It uses the chrome.system.cpu API, that any extension can access, which gives CPU and RAM utilization info about your tabs. It doesn't give anyone "a lot of information about all the open tabs", and does nothing to expose your banking website...
https://developer.chrome.com/docs/extensions/reference/api/s...
That API is baked into Google Chrome. It's hardcoded to only let google.com use it.
The allowlisting going on here is that normally when you install an extension in Chrome it asks you to confirm the access to those APIs on the sites where the extension wants to run, but this one comes pre-confirmed from the factory. A quick GitHub search finds ~1000 manifest files that list system.cpu, possibly because that API is also in the boilerplate example chrome extension manifest.
Other web pages don't have such access.
> 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.
Those things can absolutely be used to "improve" fingerprinting. I don't think it's fair to assume it's being used for that though, without any further evidence. But it certainly could be used for it.
Anyone have any further context? As it stands right now, it's just a random claim without any proof what so ever? There is link in another comment, but how is that related to the tweet?
Maybe in this situation we should distinguish "fair" vs. "probable".
I'd guess it's improbable that Google is trying to use this for fingerprinting.
But if we've previously found them with their hand in the cookie jar, then maybe it's fair to treat them as guilty until proven innocent?
I would not be surprised if there are cases where this would let them track users they otherwise couldn't. Like someone running two isolated Chrome instances with separate network connections but on the same PC.
I'm not saying it's right/wrong, just that no evidence was presented.
It should be possible to point to the source code of whatever google.com extensions that may exist.
Or is this only available in the packaged distributions of Chrome?
The extension ID is: nkeimhogjdpnpccoofpliimaahmaaome
https://chromeenterprise.google/policies/?policy=ExtensionIn...
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...
This is allowing Google to do something TO you that no one else can do to you, and that you assumed no one could do to you.
That file was very telling to be honest and was well commenter. Firefox has a similar file.
chrome.runtime.sendMessage(
'nkeimhogjdpnpccoofpliimaahmaaome', {
method: 'cpu.getInfo'
}, response => {
console.log('CPU Info:\n', JSON.stringify(response, null, 2));
}
);
{
"value": {
"archName": "arm64",
"features": [],
"modelName": "Apple M2 Max",
"numOfProcessors": 12,
"processors": [
{
"usage": {
"idle": 26879793,
"kernel": 5270058,
"total": 42511068,
"user": 10361217
}
},
{
"usage": {
"idle": 27925505,
"kernel": 5045974,
"total": 42900999,
"user": 9929520
}
},
{
"usage": {
"idle": 29153545,
"kernel": 4688719,
"total": 43152989,
"user": 9310725
}
},
{
"usage": {
"idle": 30140852,
"kernel": 4360719,
"total": 43319960,
"user": 8818389
}
},
{
"usage": {
"idle": 34426211,
"kernel": 2169516,
"total": 43433582,
"user": 6837855
}
},
{
"usage": {
"idle": 38586206,
"kernel": 1338183,
"total": 43658789,
"user": 3734400
}
},
{
"usage": {
"idle": 41067872,
"kernel": 598226,
"total": 43874597,
"user": 2208499
}
},
{
"usage": {
"idle": 41795321,
"kernel": 412479,
"total": 43965499,
"user": 1757699
}
},
{
"usage": {
"idle": 34484688,
"kernel": 2180147,
"total": 43500079,
"user": 6835244
}
},
{
"usage": {
"idle": 38604714,
"kernel": 1340358,
"total": 43680869,
"user": 3735797
}
},
{
"usage": {
"idle": 41086212,
"kernel": 599273,
"total": 43883401,
"user": 2197916
}
},
{
"usage": {
"idle": 41802500,
"kernel": 411499,
"total": 43970596,
"user": 1756597
}
}
],
"temperatures": []
}
}
Actually, do modern Macs even allow normal software to discover the CPU ID?
Every Chromium-based browser has 'hidden' APIs only accessible on certain domains. That's how the custom (read: closed source) extensions work. "Component extensions" are used to interact with them normally: https://chromium.googlesource.com/chromium/src/+/main/extens...
See https://blogs.opera.com/security/2021/09/8000-bug-bounty-hig... and https://blogs.opera.com/security/2021/09/bug-bounty-guest-po... for examples of when there are vulnerabilities in those extensions, and how they can be abused for remote code execution.
Any whitelisted domains for these APIs cannot be written to using user-installed extensions, in order for a malicious extension to not be able to inject a script and execute the special API.
At Opera, we previously tried attacking the underlying implementation about how these 'hidden' APIs are accessible. Although we found a lot of Opera-specific issues, the Chromium logic seems sound and a "bypass" for other websites accessing the API is unlikely. It also seems that the developer here was just a bit overzealous in allowing this API to be accessed from all google.com subdomains.
If it's "just extension", make it available to all domains.
https://developer.chrome.com/docs/extensions/reference/api/s...
Bundle Hangouts Services extension with Chrome
BUG=291271
Review URL: https://codereview.chromium.org/35873003
Always wondered how it's implemented in JS. WebAuthn with proprietary arguments...?
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.
Isn't that implemented in a similar way to this?
I agree with the concerns about unfair competition, and I think this auto-login "feature" could also qualify as an example.
now, is it bad that it is being done at all or that only google.com host requests can access it?
personally i see the value during debugging but having it forced enabled this way (also for only one company) is not great and should be remedied.