> 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?
Google doesn't need any extra help to track users who are browsing Google sites in the Google browser. It is probably instead anticompetitive functionality that lets Google sites work better in Chrome in ways that other sites can't replicate.
> Google doesn't need any extra help to track users who are browsing Google sites in the Google browser.
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.
Don't know about the rest, but ungoogled chromium scrambles every occurrence of the string "google" in the code specifically to avoid things like this, so probably not.
I understood what the commenter was saying and the "security implication." I am mocking the thing that people want: to use Google Chrome but with the "googly" bits removed. It isn't super practicable. Just use Firefox.
Yes, Edge has it enabled. If you open Google Meet troubleshooting in Edge you can see your system CPU. If you try it in Firefox it says "Try Google Chrome to see your CPU usage".
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.
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.
That's still just as unfair, though. Google always has access to that information because their extension is preinstalled and you can't disable it, but other websites have no access to that information unless you go out of your way to install a third-party extension to do so.
OK. That's a point of view. I just thought it should be accurately described.
I think the idea that you will download a web browser from Google and then it won't be able to figure out what model of CPU it is running on is a bit weird, when you think it through. There are lots of features of Chrome that are only "available to Google" for example it will only download updates from Google, unless you've modified its source code.
Google would naturally have privileged access to the browser, but that doesn't need to mean they have secret privileged access to my computer's hardware
If correct, once you access a `.google.com` website, the browser makes available through javascript an API allowing the querying of a lot of information about all the open tabs (if open, for example, your banking website) and can send the collected information to the "mother ship".
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.
> an API allowing the querying of a lot of information about all the open tabs (if open, for example, your banking website)
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...
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.
FWIW I once tried and failed to compile Chrome. My machine didn't have enough RAM to compile chrome at the time. Even though it was able to fully compile any other software I threw at it.
> 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 ?
The case here was just injecting a domain. There's another thread for this post pointing out you would also need to inject a malicious root cert for https traffic, which is correct, but not impossible (and given some bad/lazy practices I've seen places do when they sign their own certs for internal infrastructure, not a far stretch)
If they can do that, they can spoof or proxy any website and collect your passwords, auth cookies, and anything else sent over the network. At that point, who cares if they can also see how much CPU you're using?
I've unlearned over my years that trying to come up with what malicious actors can do under what scenarios and conditions isn't worth the effort, because they are many, know more than me, have different goals than me, and I am one. There's endless permutations of environments and additional weakness or scenarios or a particular sensitivity of information that you don't or can't consider that make some attack really painful. For this case, maybe CPU usage or aggregate changes in CPU usage tips off an attacker on what someone is ramping up internally that can be used for espionage or even timing attacks.
What I have learned in place of that is plug holes to minimize attack vectors.
So if you can just trick someone into trusting a bogus root CA, take control of their DNS resolution, and get them to open an attacker controlled domain in Chrome then you can... Use this API to get information about their current CPU utilisation.
Or anyone who controls your DNS resolution which has a number of paths (for example a local hosts file, possibly a router, changing your config or how you get your config to a malicious DNS server, etc)
Is it really that easy? I just kind of assumed that devs could create subdomains under a dev TLD like googdev123.com, but not google.com until it was a fully-fledged product release.
Agree. I work at Google. I promise nothing happens quickly. It can take over a week to set up a new SQL database & client. Half coding (don't get me started on boq...) and half data integrity and criticality annotations for the data...
I don't know what setting up a new domain is like but I can't imagine it's something you "just do".
In what world does "system / tab CPU usage, GPU usage, and memory usage" mean "full access to the system"? Any Chrome extension can access this info easily, the point that the tweet makes is that there's a built-in Chrome extension that shares this info with Google's own websites without any confirmation.
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.
If you mean can another domain trick Chrome into letting it access those APIs… probably not; it seems it’s based on the browser extension architecture which is already somewhat hardened and I believe doesn’t even load the code for the extension if you’re not on a matching domain (though the typical protection goes the other way around — preventing extensions from accessing website data without permission).
So if you install your own certificate authority and then spoof the DNS it might be possible? Not so useful as an attack vector, but potentially useful for people who want to do fun things with the browsers they own.
This. I think chrome is now using something called certificate transparency, but it has the same effect it won't trust your own installed CA for google.com
Google Docs is designed to not let you run arbitrary JS in a trusted (i.e. google.com origin) context, or else the author of any doc you visit could act as you on Google properties.
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.
Google spent billions muscling their way into their majority market share of web browsers, now they're going to keep on cashing out with unfair practices like these.
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.
What? You think that Mozilla devs would think about adding your domain to the whitelist of domains allowed to install extensions if you just asked nicely? That would be insane from a security perspective.
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 really. Browser developers add lots of different website-specific hacks to make sites behave better in their browser. Mozilla actually used to do this a lot, when they were originally the underdog 20+ years ago and were trying to get people to switch to the Mozilla suite (and then Firefox), when the argument against switching was often related to websites not working or rendering properly in Mozilla/Firefox that behaved properly in IE.
(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.)
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).
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.
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.
There is potentially an innocuous and straightforward explanation for this. Imagine the browser comes with some functionality implemented as a google.com-signed web app (as opposed to compiled/linked C++ as a lot of the older Chrome UI).
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.
My examples are of core browser functionality, just implemented with a different tool chain (a web app instead of C++). Should the user be asked for permission for C++ to send an IPC to another C++ component? Should the Chrome Web store ask for permission to install extensions in Chrome?
Down-thread I see that this is being used for Google Meet functionality, for which I agree it should ask for the user's permission.
In any multi-process software (of which Chrome is on the more complex end of the spectrum), there are dozens if not hundreds of different IPC message types sent between different components of the software.
To prompt the user for every type of IPC would make the software unusable. No desktop software does that on any platform.
It would be like a car asking the user for permission for the steering wheel to access the front axle.
I think it is a mistake to give a company like Google the benefit of the doubt. Consumer protection is a lot like security, we should theorize the worst case scenario, and assume the company is willing to work against consumer interest if it serves their own interests.
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.
For what its worth, I'm on Brave (chromium based) and this also works there, so it appears to not necessarily be only Chrome but potentially any chromium browser where they haven't specifically blocked/disabled this
Arguably, Chromium is more important to Google than Chrome is.
By controlling the engine, they have de facto control over the standards.
By keeping Chromium open, they incentivise forks. Most people who don't want to use Chrome because it's Google's or for some other reason will use one of the forks or Chromium-based browsers.
By keeping this illusion of choice, Google extends its control.
People are running it because they think Google is trustworthy, so telling about abuses might be useful in order to erode that trust and let people know they shouldn't run anything from that company
Chrome extensions can access CPU and GPU statistics via a public API that any extension developer can use. Google Chrome comes bundled with a hidden "Hangouts Services" extension, which has permissions for *.google.com (that extension's ID is the 'nkeimhogjdpnpccoofpliimaahmaaome' referenced in the examples). That extension has a function that will return those stats when called from JavaScript running on a webpage. As a result, any JavaScript running on *.google.com can get the current CPU and GPU utilization.
And? Google uses Chrome to retrieve data about the user.
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...
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 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>)?
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.
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.
Except that is not what Google is doing. They have exclusive access to the one line that is preinstalled for all houses. Only they can use it. And if you want a different provider, you can't use that same line. You have to pay for the installation of a line from that provider with your own cash.
Huh, Chrome doesn't come preinstalled unless you are talking about ChromeOS.
I guess I just don't see the problem in a feature like this in a third party browser software that is completely optional to install and use and has lots of alternatives.
Yeah, so people with a choice of browsers might prefer it not be the one exposing exclusive APIs for its parent company, and it might affect that company's "we're not evil" image.
But yeah, having that build into your browser is a huge advantage over having to nag your users to install an extension or worse convincing the IT department that it's worth installing.
This isn't a mundane explanation though: this is exactly the example Luca gives in the original thread. It's anti-competitive, because it's functionality only available to Google Meet. Google is using its browser monopoly to advantage its other products.
They are just trying to make their products better. Anti competitive behavior is generally perceived to be about doing things that put the company in question in a better position without improving the product.
Ask yourself the question - are customers better or worse off because of this?
Yes, in the real world if something is so inconsequential, in practice gets left alone. It hasn't had any effect on the market. This isn't kindergarten, "THAT'S NOT FAIR!!" isn't valid unless it actually matters.
That's not what anti-competitive means at all. Having APIs that Google Meet can use but competing products can't reduces competition, which makes customers worse off.
"All they're doing is making their product better."
"Making your product better by privileging your own domains in the browser is the anti-competitive part."
"Come on, it's not like it's making their product better."
----
This really isn't complicated. Is this making Google Meet better? I would quote:
> danielmarkbruce: "They are just trying to make their products better."
Okay. So then Google Meet would be a worse product if they didn't have privileged API access over other apps. So... this does make it harder for those other apps to compete, unless you think that the quality of a product is somehow irrelevant for competition.
Sure, Google Meet still isn't winning, but who knows where they'd be in the market if they didn't privilege themselves.
You're saying that their product would be worse if they didn't do this, but also that it somehow doesn't matter because they're not the best product. Which has a similar energy to me cutting a loop out of a marathon and saying, "Come on guys, I only came in third. It's not cheating unless I come in first, everybody knows that. As long as I don't come in first I'm allowed to take shortcuts. Give me my third place medal that I definitely earned fairly, why is everybody mad about this?"
> The point of products is to provide value to customers.
This is idealistic, the point of a product is to provide value to the company.
And competition is not a by-product that exists by accident, it is the mechanism through which we get companies who are building things for their benefit to incidentally provide benefits to consumers.
Products are competitions. From a business point of view, the point is to win. From a social point of view, yes, obviously we want products to provide value to consumers. But don't make the mistake of assuming that Google (or any other company) has the same goals as society. Every business wants to be a monopoly.
----
> Misleading analogies don't illuminate.
Now, you may not like the analogy, but the general point here is exactly the same regardless of what analogy you use. I'll repeat:
> This really isn't complicated. Is this making Google Meet better? I would quote:
> > danielmarkbruce: "They are just trying to make their products better."
> Okay. So then Google Meet would be a worse product if they didn't have privileged API access over other apps. So... this does make it harder for those other apps to compete, unless you think that the quality of a product is somehow irrelevant for competition.
----
You can not in one breath argue that this is good because it made Google Meet better, and in the next breath argue that it's fine because it didn't impact the market. Those two ideas contradict each other.
And the fact that Google is so inept at product design that it can't capture the entire market even when it unfairly advantages itself does not mean that it is not unfairly advantaging itself or that it isn't causing harm. The Internet as a platform is better for both consumers and businesses when it is a common platform, not one that privileges specific companies. The Internet (and the market overall) is harmed by breaches of market rules regardless of the final outcomes, because each breach emboldens companies to attempt even more lawless stunts and destroys trust in the market.
I mean, seriously, call it whatever analogy you want, it's still awfully silly to argue that Google cheating to give itself a leg up over competitors is fine... because even with the advantage Google still couldn't build a good enough conferencing app to capture the entire market. That does not let them off the hook for cheating.
"It doesn't matter what the market effect was, only that Google engineers meant well" is certainly an argument, but it both contradicts the question you originally asked (are customers better off), and also (to be blunt) is a really heckin bad argument.
I'm just kind of blown away by the rapid shift from "this helped consumers", to "actually, no, the effect was minimal", to "actually, it doesn't matter if anybody was harmed, the result is immaterial." :)
"Google should not use a near-monopoly position in the browser to privilege it's own sites and services" is a very simple standard, and this really is not a complex case.
It only becomes complicated if you start trying to rephrase a simple principle as: "Google shouldn't privilege their sites unless they mean well, and then the result is immaterial, but no wait actually I didn't mean immaterial, I meant minimal, and anyway it's not like Zoom isn't still popular so-"
Or... Google could also just not ship invisible extensions as part of Chromium's build process that privilege Google-owned services with extra API access in direct contradiction to the principles of an independent Internet. Because the effect of casually breaking that contract isn't minimal. It does actually matter that the web be a neutral platform. If businesses expect that Google can get away with privileging Google platforms in the core browser, that perception and allowance of interference degrades the entire Internet as a commercial platform - and of course emboldens Google to go even further in the future.
I... what? Today I learned that the Federal Trade Commission is a figment of my imagination.
I'm sorry, your argument has devolved to the point where you're now saying that Chrome privileging Google sites isn't anticompetitive behavior because antitrust isn't a natural law? I can't believe I have to say this, but that's not the standard that the FTC or courts use.
Google is literally being sued right now for, in part, using browsers (both its own and others through browser deals) to privilege it's own services. No, the FTC was not created for the purpose of the Internet, but that is not a thing that anyone said, and I very genuinely believe that you are smart enough to understand that I was talking about the provably false claim that a neutral Internet that doesn't exist to privilege Google is some fantasy that only tech nerds have rather than a repeated principle in multiple current antitrust efforts by multiple governments around the world, including the US.
That being said:
> You keep moving the goal posts.
You're right, and I apologize. We weren't discussing whether or not antitrust was a natural right. That's off-topic, and that's on me. We started this out discussing, in your words:
> Anti competitive behavior is generally perceived to be about doing things that put the company in question in a better position without improving the product.
Which I hope at this point we've established is just straight-up wong, that's just not an accurate evaluation of antitrust. Then of course you went on to say there was no effect, and that if there was an effect it didn't matter because "result = immaterial" (which is also absurd, even the most conservative, limited perspective on antitrust in the government does not say that the results of a company action aren't relevant to antitrust). And then you went on to imply that having a neutral platform on the web isn't something anyone should expect anyway, which... yeah, okay, absurdities aside you're correct that now we're starting to get off topic.
The on-topic response to this as far as I can tell is: I don't think you understand what antitrust is, how it works, or why we have it, and everything you're saying here is absurd.
But it's very easy to get caught up in minute rhetorical debates: part of what's been wild about this conversation has been watching you make even more indefensible claims that you never had to make, just to avoid the appearance of one contradiction. And it's worth resisting that impulse, taking a step back from this and looking at the original questions: was anyone harmed? Is this anticompetitive behavior?
You say no, but you also say that no one should have any expectation of an Internet that exists independently of a single company's monopoly hold over its standards and APIs. So you're not really in a position to know if anyone was harmed because where competition on the Internet is concerned, you appear to reject an entire category of commonly understood harm.
So just taking a step back and looking at these ideas: are people overreacting over Google? Does this cause harm? Was the purpose of this to make people's lives better, or was it to privilege Google's services over competitors? If you believe absurd things about antitrust, competition, corporate intentions, and the Internet itself -- it doesn't really mean much when you say that Google's intentions are good and everyone is over-concerned.
If you tell people not to be concerned about the loss of a neutral, independent Internet, and it turns out you don't believe in a neutral, independent Internet, then... surprise, people aren't going to listen to you.
Materiality matters, in practice. This is a tiny thing.
The result of the action matters, in practice. Meet is an also ran.
The intent/motivation matters, in practice. They were trying to do the right thing, improve their product.
Using a dominant positing in one market to promote/dominate in another market via distribution is where regulators tend to push cases. And, people tend to (rightly, mostly) get upset. Improving the product via another product? Find me a list of cases.
Have you considered some people actually deal with anti trust on a day to day?
On whether platform APIs (like those in a web-browser) can be anti-competitive:
> Apple has used one or both mechanisms (control of app distribution or control of APIs) to suppress the following technologies...
[...]
On the need for neutral API access as a tool to increase competition:
> Messaging apps that work equally well across all smartphones can
improve competition among smartphones [...]. Apple makes
third-party messaging apps on the iPhone worse generally and relative to Apple
Messages, Apple’s own messaging app, by prohibiting third-party apps from sending
or receiving carrier-based messages...
[...]
On the suppression of APIs for third-party services:
> By suppressing key functions of third-party smartwatches —including the ability to respond to notifications and messages and to maintain consistent
connections with the iPhone—Apple has denied users access to high performing
smartwatches with preferred styling, better user interfaces and services, or better
batteries, and it has harmed smartwatch developers by decreasing their ability to
innovate and sell products.
[...]
On the use of privacy as an excuse restrict 3rd-party APIs that are not restricted for 1st-party services:
> In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple’s financial and business interests.
[...]
If you need it stated even more clearly:
> Apple selectively designates APIs as public or private to benefit Apple, limiting the
functionality developers can offer to iPhone users even when the same functionality is available
in Apple’s own apps, or even select third-party apps.
This is directly analogous to what Google is doing here. Shipping a by-default extension which takes advantage of a distribution channel (Chrome's list of default extensions) that is not available to 3rd-party developers. That extension grants Google access to a private API that benefits Google while limiting the functionality that third party sites can offer their users, and I quote: "even when the same functionality is available in [Google]'s own apps."
You do not know what you are talking about.
> Have you considered some people actually deal with anti trust on a day to day?
You're saying it's not a big deal while also saying it improves the product. The debug panel is apparent, but we don't know what else the API's data is used for. Maybe Meet uses it to improve performance too.
If so, the API has to be available to competitors. Maybe this is why Meet is in-browser while all the other ones work better in apps. Despite this, Meet still hasn't won because it's just not very good.
The goal or motivation is irrelevant; what they actually did and its potential effects are what matters.
I'm not sure why you seem to be having so much trouble with this concept. Google's majority-market-share browser gave their browser-based videoconferencing product a privilege and advantage that other browser-based videoconferencing products did not get.
That's it. You don't need to dig into their motivations or their intentions. It doesn't matter if it even "worked" or not; it is completely immaterial that Google is so incompetent that it can't even win when it has given itself the tools to play dirty.
Motivation is a basic concept in the legal world which goes a long way to deciding criminal cases, has an impact on civil cases and will certainly influence whether the DOJ brings a case and what the result is. It's also a basic concept used by humans.
Saying it is irrelevant shows a complete lack of understanding of the legal and regulatory environment in which businesses operate.
Anti-competitive behaviour doesn't need to mean other companies can't compete. It just means it makes it harder to compete, which this does. Having access to this data improves Google Meet, and evidently gives enough advantage to justify adding it to the browser. Other products don't have access to these APIs, so can't improve their products in the same way. Google has used their browser monopoly to give their other products an unfair advantage. That is anti-competitive behaviour, and is illegal.
> are customers better or worse off because of this?
Worse. Google's Hangouts/Meet customers are better off, but everyone else is not. That's what anti-competitive behavior is: using your monopoly in order to advantage your own products at the expense of others.
Yeah, crazy to think that Google of all companies would track people in unexpected ways :eyeroll:.
Your post is evidence that the scrutiny Google gets is actually helping matters. Companies, especially powerful ones, should default to not tracking personal data any more than necessary. I'm glad to hear that at least one department took that seriously.
Ah yes, the good old "Sorry we accidentally violated your privacy and illegally disadvantaged competitors using our monopoly. But everyone is actually just doing the best they can, honest mistake. Teehee."
Sorry but at some point people will stop buying that shit and Google is well past it.
They should fix the situation. They try to do too many things at once.
But it's hard to give engineers leeway to just work on things and at the same time make sure the combination of data collected can't be added in a way that is "bad" on some dimension. If you think about the combination of hundreds of groups doing things... it's just a hard problem.
If you imagine running just maps and email and youtube, and you try to improve those products by instrumenting them in a pretty vanilla way... you just end up with a lot of data on people. Consider person X watches videos about lung cancer treatment options. Person X also drives from location a to b with some frequency. Location a is a residential address and location b is a hospital. You track both these things so you can recommend videos they might like amongst the bajillion videos available, and so they can get in their car and immediately choose location b without having to enter the address.Person X has their name in their email account so it displays their name when they send an email. Person X's name is John Smith. Put it all together - John Smith, who lives at 12 Main Street, Chicago, has lung cancer. And when he stops driving that route and stops looking at cancer videos but is still active... he's been cured.
Tracking is very rarely useful to the application but can be useful to the company when the application isn’t profitable on its own. Google has demonstrated this before.
This is almost precisely backwards. Developers want so much telemetry for their applications, almost all of which is totally useless outside of the need to debug or improve that application.
Exactly. In a world with sufficient anti-trust and privacy enforcement Google would instill into their employees a fear of even thinking about pulling stunts like this. Instead we have Googlers and ex-Googlers running defence for it claiming they see nothing wrong.
In such world, no one does anything without running it by the lawyers first, and then a months long debate occurs around every single little move, and nothing gets done.
Don't you find it hilarious how people who work or worked at Google happen to think that things Google does are "mundane", even when other people think they're outrageous? Hilarious coincidence, really. Can't stop laughing.
Even if you take the mundane explanation -- that this was just to allow Google engineers to troubleshoot user issues with Hangouts -- you still have a company using their market power to give their product (Hangouts) a benefit that no other product (Zoom, Teams, literally any other WebRTC video conferencing solution.) gets to use.
Worse off. I have to use Meet for work, and I'm forced to run Chrome for Google's shitty software to run acceptably.
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.
Trying to be generous, the only reason I can think for why customers would be worse off is that Google is literally the only one who can be trusted with this kind of power. Not Zoom, not Microsoft, not the user whose data is being transmitted, etc.
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.
"Of course we are the good guys, it's everyone else who is misguided when they get upset after finding out out about our awesome work."
Choosing to work for an advertising giant already calls into question either your ability to tell what "the right thing" is our your honesty in claiming to do it.
Microsoft Edge's source code isn't available. We don't know really know what kind of stuff they patch in.
It's just that Google keeps most stuff in Chrome open.
To me it looks like Google wants to use some analytics on Google Meet to improve it (e.g. a/b testing on CPU consumption), or they just want to provide that interactive CPU% widget in it, but they don't think it would be a good idea to let just any website use it, as it can could be used for fingerprinting (e.g. if you have two different sites open in separate tabs, they could detect this by co-operating to correlate the CPU% time series data, even if the connections are over Tor or proxies).
For non-Google services they provide a mechanism to do the same by having the customer install an extension with the correct permission.
That's the internal API used by the hangout_services extension. It's the extension itself that is undocumented.
A user might reasonably expect that web pages do not have access to the system.cpu API by default. And that's mostly true, but thanks to the pre-installed but hidden hangout_services extension, google.com does have access to this API. That's at least a little dubious.
> 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!
> 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.
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.
At least other video conferencing tools don't lag like Meet, so users don't need to debug ;) I think this has to do with all of them using H.264 while Meet uses VP8/9.
The implementation is what I was thinking of. I've also heard claims that VP9 is inherently slower to encode than H.264, but no idea if that's accurate. AVC/H.264 has very broad hardware support. For example, the 2019 MBP I'm using right now can't do hardware-accelerated VP9 encoding, but even 2011-ish MBPs can do H.264 acceleration in both directions. Intel's support matrix: https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video
AV1 looks like it's getting broader support, but it's still new. Zoom's release notes mention they'll use AV1 if the participants support it, and I don't see a similar note about VP8/9.
It's only in newer chips, but it's broader than VP8/9 was. Intel and Nvidia's newest chips support hardware en/decoding of AV1, while Nvidia never supported VP8/9.
Having had the dubious pleasure of trying to use Meet from various Apple devices, Meet didn’t lag because Meet couldn’t produce video at all. Maybe I only operate at the wrong edge of the Meet ecosystem, but it did not compare well to anything else out there.
(I’ve tried Safari, I’ve tried the native app, and I’ve even tried the phone bridge (!).)
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.
Changing Firefox's UserAgent to Chrome's, results in a speed-up. Because when the useragent isn't Chrome, YouTube checks for feature availability, whilst on Chrome, they just assume it is all there.
Thanks for giving me a specific example. At this point in the evolution of web standards and their implementations, that kind of UA check is stupid enough that I can believe there is at least some level of intent to not also making assumptions about available features on other browsers.
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.
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).
Mind you, Zoom does everything in their power to steer users away from their web client and toward their ~~malware~~ desktop client, so I don't think they're too upset about the status quo.
This is a link to a five year old issue, when Zoom was a much smaller operation and their quality was far worse than it is now. They implemented a convenience feature in an incredibly stupid and insure way, in 2019.
Do you have any evidence that the current Zoom client is "malware"?
Apparently, this system statistics API is generally available to extension developers. The underlying issue is that they bundle a hidden "Hangouts Service Extension" with Chrome. Zoom, Teams, etc. would have access to this API through a Chrome extension, although they wouldn't have the advantage of having that extension pre-installed.
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
414 comments
[ 3.0 ms ] story [ 283 ms ] thread> 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.
If you don’t want to use Google’s browser, don’t use Google’s browser.
Edit, if it’s not obvious: an unclaimed domain with special permissions is a massive security hole.
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...
Other web pages don't have such access.
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.
I think the idea that you will download a web browser from Google and then it won't be able to figure out what model of CPU it is running on is a bit weird, when you think it through. There are lots of features of Chrome that are only "available to Google" for example it will only download updates from Google, unless you've modified its source code.
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...
[1] https://liberda.nl/weblog/heres-your-copium/
So I guess the question becomes how quickly you can spoof this ?
What I have learned in place of that is plug holes to minimize attack vectors.
Wow some attack you got there.
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.
I don't know what setting up a new domain is like but I can't imagine it's something you "just do".
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.
https://en.wikipedia.org/wiki/Certificate_Transparency
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.
https://source.chromium.org/chromium/chromium/src/+/main:chr...
https://source.chromium.org/chromium/chromium/src/+/main:chr...
The extension ID is: nkeimhogjdpnpccoofpliimaahmaaome
https://chromeenterprise.google/policies/?policy=ExtensionIn...
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.
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.
[0] https://news.ycombinator.com/item?id=40631439
(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.)
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).
As for the anti-trust aspect, here the market share matters and Firefox is insignificant in that regard.
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.
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.
Down-thread I see that this is being used for Google Meet functionality, for which I agree it should ask for the user's permission.
Yes. We need much more of this on the desktop.
To prompt the user for every type of IPC would make the software unusable. No desktop software does that on any platform.
It would be like a car asking the user for permission for the steering wheel to access the front axle.
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.
By controlling the engine, they have de facto control over the standards.
By keeping Chromium open, they incentivise forks. Most people who don't want to use Chrome because it's Google's or for some other reason will use one of the forks or Chromium-based browsers.
By keeping this illusion of choice, Google extends its control.
I'm not saying it's right/wrong, just that no evidence was presented.
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.
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.
I guess I just don't see the problem in a feature like this in a third party browser software that is completely optional to install and use and has lots of alternatives.
But yeah, having that build into your browser is a huge advantage over having to nag your users to install an extension or worse convincing the IT department that it's worth installing.
Edit: https://developer.chrome.com/docs/extensions/reference/api/s... seems to provide that, though
my guess would also include some nifty debug info from FLoC ;)
Ask yourself the question - are customers better or worse off because of this?
"Making your product better by privileging your own domains in the browser is the anti-competitive part."
"Come on, it's not like it's making their product better."
----
This really isn't complicated. Is this making Google Meet better? I would quote:
> danielmarkbruce: "They are just trying to make their products better."
Okay. So then Google Meet would be a worse product if they didn't have privileged API access over other apps. So... this does make it harder for those other apps to compete, unless you think that the quality of a product is somehow irrelevant for competition.
Sure, Google Meet still isn't winning, but who knows where they'd be in the market if they didn't privilege themselves.
You're saying that their product would be worse if they didn't do this, but also that it somehow doesn't matter because they're not the best product. Which has a similar energy to me cutting a loop out of a marathon and saying, "Come on guys, I only came in third. It's not cheating unless I come in first, everybody knows that. As long as I don't come in first I'm allowed to take shortcuts. Give me my third place medal that I definitely earned fairly, why is everybody mad about this?"
This is idealistic, the point of a product is to provide value to the company.
And competition is not a by-product that exists by accident, it is the mechanism through which we get companies who are building things for their benefit to incidentally provide benefits to consumers.
Products are competitions. From a business point of view, the point is to win. From a social point of view, yes, obviously we want products to provide value to consumers. But don't make the mistake of assuming that Google (or any other company) has the same goals as society. Every business wants to be a monopoly.
----
> Misleading analogies don't illuminate.
Now, you may not like the analogy, but the general point here is exactly the same regardless of what analogy you use. I'll repeat:
> This really isn't complicated. Is this making Google Meet better? I would quote:
> > danielmarkbruce: "They are just trying to make their products better."
> Okay. So then Google Meet would be a worse product if they didn't have privileged API access over other apps. So... this does make it harder for those other apps to compete, unless you think that the quality of a product is somehow irrelevant for competition.
----
You can not in one breath argue that this is good because it made Google Meet better, and in the next breath argue that it's fine because it didn't impact the market. Those two ideas contradict each other.
And the fact that Google is so inept at product design that it can't capture the entire market even when it unfairly advantages itself does not mean that it is not unfairly advantaging itself or that it isn't causing harm. The Internet as a platform is better for both consumers and businesses when it is a common platform, not one that privileges specific companies. The Internet (and the market overall) is harmed by breaches of market rules regardless of the final outcomes, because each breach emboldens companies to attempt even more lawless stunts and destroys trust in the market.
I mean, seriously, call it whatever analogy you want, it's still awfully silly to argue that Google cheating to give itself a leg up over competitors is fine... because even with the advantage Google still couldn't build a good enough conferencing app to capture the entire market. That does not let them off the hook for cheating.
I'm just kind of blown away by the rapid shift from "this helped consumers", to "actually, no, the effect was minimal", to "actually, it doesn't matter if anybody was harmed, the result is immaterial." :)
It's not that complicated. No need to be blown away. Most cases around competition law are significantly more complex.
It only becomes complicated if you start trying to rephrase a simple principle as: "Google shouldn't privilege their sites unless they mean well, and then the result is immaterial, but no wait actually I didn't mean immaterial, I meant minimal, and anyway it's not like Zoom isn't still popular so-"
Or... Google could also just not ship invisible extensions as part of Chromium's build process that privilege Google-owned services with extra API access in direct contradiction to the principles of an independent Internet. Because the effect of casually breaking that contract isn't minimal. It does actually matter that the web be a neutral platform. If businesses expect that Google can get away with privileging Google platforms in the core browser, that perception and allowance of interference degrades the entire Internet as a commercial platform - and of course emboldens Google to go even further in the future.
I... what? Today I learned that the Federal Trade Commission is a figment of my imagination.
I'm sorry, your argument has devolved to the point where you're now saying that Chrome privileging Google sites isn't anticompetitive behavior because antitrust isn't a natural law? I can't believe I have to say this, but that's not the standard that the FTC or courts use.
That being said:
> You keep moving the goal posts.
You're right, and I apologize. We weren't discussing whether or not antitrust was a natural right. That's off-topic, and that's on me. We started this out discussing, in your words:
> Anti competitive behavior is generally perceived to be about doing things that put the company in question in a better position without improving the product.
Which I hope at this point we've established is just straight-up wong, that's just not an accurate evaluation of antitrust. Then of course you went on to say there was no effect, and that if there was an effect it didn't matter because "result = immaterial" (which is also absurd, even the most conservative, limited perspective on antitrust in the government does not say that the results of a company action aren't relevant to antitrust). And then you went on to imply that having a neutral platform on the web isn't something anyone should expect anyway, which... yeah, okay, absurdities aside you're correct that now we're starting to get off topic.
The on-topic response to this as far as I can tell is: I don't think you understand what antitrust is, how it works, or why we have it, and everything you're saying here is absurd.
But it's very easy to get caught up in minute rhetorical debates: part of what's been wild about this conversation has been watching you make even more indefensible claims that you never had to make, just to avoid the appearance of one contradiction. And it's worth resisting that impulse, taking a step back from this and looking at the original questions: was anyone harmed? Is this anticompetitive behavior?
You say no, but you also say that no one should have any expectation of an Internet that exists independently of a single company's monopoly hold over its standards and APIs. So you're not really in a position to know if anyone was harmed because where competition on the Internet is concerned, you appear to reject an entire category of commonly understood harm.
So just taking a step back and looking at these ideas: are people overreacting over Google? Does this cause harm? Was the purpose of this to make people's lives better, or was it to privilege Google's services over competitors? If you believe absurd things about antitrust, competition, corporate intentions, and the Internet itself -- it doesn't really mean much when you say that Google's intentions are good and everyone is over-concerned.
If you tell people not to be concerned about the loss of a neutral, independent Internet, and it turns out you don't believe in a neutral, independent Internet, then... surprise, people aren't going to listen to you.
The result of the action matters, in practice. Meet is an also ran.
The intent/motivation matters, in practice. They were trying to do the right thing, improve their product.
Using a dominant positing in one market to promote/dominate in another market via distribution is where regulators tend to push cases. And, people tend to (rightly, mostly) get upset. Improving the product via another product? Find me a list of cases.
Have you considered some people actually deal with anti trust on a day to day?
https://9to5mac.com/wp-content/uploads/sites/6/2024/03/UNITE...
Emphasis mine:
On whether platform APIs (like those in a web-browser) can be anti-competitive:
> Apple has used one or both mechanisms (control of app distribution or control of APIs) to suppress the following technologies...
[...]
On the need for neutral API access as a tool to increase competition:
> Messaging apps that work equally well across all smartphones can improve competition among smartphones [...]. Apple makes third-party messaging apps on the iPhone worse generally and relative to Apple Messages, Apple’s own messaging app, by prohibiting third-party apps from sending or receiving carrier-based messages...
[...]
On the suppression of APIs for third-party services:
> By suppressing key functions of third-party smartwatches —including the ability to respond to notifications and messages and to maintain consistent connections with the iPhone—Apple has denied users access to high performing smartwatches with preferred styling, better user interfaces and services, or better batteries, and it has harmed smartwatch developers by decreasing their ability to innovate and sell products.
[...]
On the use of privacy as an excuse restrict 3rd-party APIs that are not restricted for 1st-party services:
> In the end, Apple deploys privacy and security justifications as an elastic shield that can stretch or contract to serve Apple’s financial and business interests.
[...]
If you need it stated even more clearly:
> Apple selectively designates APIs as public or private to benefit Apple, limiting the functionality developers can offer to iPhone users even when the same functionality is available in Apple’s own apps, or even select third-party apps.
This is directly analogous to what Google is doing here. Shipping a by-default extension which takes advantage of a distribution channel (Chrome's list of default extensions) that is not available to 3rd-party developers. That extension grants Google access to a private API that benefits Google while limiting the functionality that third party sites can offer their users, and I quote: "even when the same functionality is available in [Google]'s own apps."
You do not know what you are talking about.
> Have you considered some people actually deal with anti trust on a day to day?
And I hope to God that you're not one of them.
Disingenuous.
Correct. And Google made it harder for other companies to compete by leveraging their monopoly position in the browser space.
Even if we take the positive spin on it and say that Google made it easier for themselves to compete, that's not a material difference.
I'm not sure why you seem to be having so much trouble with this concept. Google's majority-market-share browser gave their browser-based videoconferencing product a privilege and advantage that other browser-based videoconferencing products did not get.
That's it. You don't need to dig into their motivations or their intentions. It doesn't matter if it even "worked" or not; it is completely immaterial that Google is so incompetent that it can't even win when it has given itself the tools to play dirty.
Saying it is irrelevant shows a complete lack of understanding of the legal and regulatory environment in which businesses operate.
Worse. Google's Hangouts/Meet customers are better off, but everyone else is not. That's what anti-competitive behavior is: using your monopoly in order to advantage your own products at the expense of others.
Your post is evidence that the scrutiny Google gets is actually helping matters. Companies, especially powerful ones, should default to not tracking personal data any more than necessary. I'm glad to hear that at least one department took that seriously.
Can you really blame people for that when the company in question has been enmeshed in a case like this [1] involving Chrome.
1: https://www.reuters.com/legal/google-settles-5-billion-consu...
Sorry but at some point people will stop buying that shit and Google is well past it.
But it's hard to give engineers leeway to just work on things and at the same time make sure the combination of data collected can't be added in a way that is "bad" on some dimension. If you think about the combination of hundreds of groups doing things... it's just a hard problem.
If you imagine running just maps and email and youtube, and you try to improve those products by instrumenting them in a pretty vanilla way... you just end up with a lot of data on people. Consider person X watches videos about lung cancer treatment options. Person X also drives from location a to b with some frequency. Location a is a residential address and location b is a hospital. You track both these things so you can recommend videos they might like amongst the bajillion videos available, and so they can get in their car and immediately choose location b without having to enter the address.Person X has their name in their email account so it displays their name when they send an email. Person X's name is John Smith. Put it all together - John Smith, who lives at 12 Main Street, Chicago, has lung cancer. And when he stops driving that route and stops looking at cancer videos but is still active... he's been cured.
I hope the anti-trust regulators notice this one.
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.
Strange statement given that there's absolutely no evidence of that.
Choosing to work for an advertising giant already calls into question either your ability to tell what "the right thing" is our your honesty in claiming to do it.
Maybe that was true in 1998, but it's certainly not true now.
The existence of the API is documented: https://developer.chrome.com/docs/extensions/reference/api/s...
To me it looks like Google wants to use some analytics on Google Meet to improve it (e.g. a/b testing on CPU consumption), or they just want to provide that interactive CPU% widget in it, but they don't think it would be a good idea to let just any website use it, as it can could be used for fingerprinting (e.g. if you have two different sites open in separate tabs, they could detect this by co-operating to correlate the CPU% time series data, even if the connections are over Tor or proxies).
For non-Google services they provide a mechanism to do the same by having the customer install an extension with the correct permission.
A user might reasonably expect that web pages do not have access to the system.cpu API by default. And that's mostly true, but thanks to the pre-installed but hidden hangout_services extension, google.com does have access to this API. That's at least a little dubious.
> 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 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.
For PCs with dedicated GPUs, Nvidia's matrix doesn't even mention VP8/9 encoding, and for decode there are a lot of VP8/9 "no"s for GPUs that have "yes" for H.264: https://developer.nvidia.com/video-encode-and-decode-gpu-sup...
AV1 looks like it's getting broader support, but it's still new. Zoom's release notes mention they'll use AV1 if the participants support it, and I don't see a similar note about VP8/9.
(I’ve tried Safari, I’ve tried the native app, and I’ve even tried the phone bridge (!).)
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.
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.
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).
https://news.ycombinator.com/item?id=20387298
Do you have any evidence that the current Zoom client is "malware"?