Hacker News Reader

Comment by _9yre | Hacker News Reader

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.

View on HN

> I think the explanation is quite mundane

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

Insert "aren't" after the first "Slack".

That makes sense; that's how I interpreted it.

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.

As a result of a flaw in the protocol itself or in its implementation?

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

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.

there are very few CPUs supporting AV1 hw encoding now, all is on the CPU

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 (!).)

Achtually its AV1 which is even worse. but saves a bunch of bandwidth

Example of why this is not mundane https://x.com/fedekauffman/status/1811019707165856259

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.

The user could easily install an extension that provides the same debugging capability. Most users don't care, so they won't need it.

Defaults are powerful.

like 90% of the DMA is just this haha

Then why did Google build it into the browser?

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.

Are there any sources that the zoom desktop client is malware?

https://infosecwriteups.com/zoom-zero-day-4-million-webcams-...

https://news.ycombinator.com/item?id=20387298

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.

Very cool that Google built an anticompetitive browser that offers such useful features only to themselves.

Very cool of you as a Google employee to say the quiet part out loud for us.

Are customers better off or worse off?

Worse, by having less alternatives to choose from. This is why anti-monopoly laws exist.

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.

Meet works in non-chromium browsers, so .. forced?

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.

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.

This bit wasn't discovered by looking at the source, though, so I don't think that point is relevant here.

> But even that does not explain why the existence of the API was not disclosed.

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.

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.

Monopoly leveraging is illegal, not mundane.

Are features like this available to other websites outside of Google? Say, could Zoom also add a feature like this?

A level playing field for competition? This is Google we're talking about.

If Zoom makes a chrome extension, then yes.

Will the Zoom extension also be installed by default?

Do you want every person in the world to run a line to your house, or do you want to have 1, and use that service to talk to them?

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.

This also works on all chromium based browsers such as Edge, Vivaldi and Brave

Yes, and then I want them to be heavily regulated.

That is incorrect. Zoom would have to modify the browser source code to enable the API on their domain.

Beside the point, but I don't think Chrome extensions have access to those hardware details.

They do: https://developer.chrome.com/docs/extensions/reference/api/p...

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.

The special built-in API reveals system-wide CPU usage, not just for browser processes. Still surprised extensions can see browser processes though.

Edit: https://developer.chrome.com/docs/extensions/reference/api/s... seems to provide that, though

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.

And they do the same thing with YouTube by slowing down the initial load in other browsers. Google is evil, and this is the least of it.

"don't be evil"

Oh wow.

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.

So helpful that no other website and no other browser can use it?

Looking forward to seeing this comment in discovery

The monopolists' first step towards unfairly dominating a market always seems pretty mundane.

if we are guessing I would drawn my guess from the hyper controlled access to android play services, which do much more than what you are guessing.

my guess would also include some nifty debug info from FLoC ;)

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

Reply on news.ycombinator.com