Comment by Tiberium

6 months ago

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's no "special hidden API".

20 comments

Tiberium

Reply
Cyphus  6 months ago

"special" in the sense that unlike other extensions which are user-installed, this one is built into Chrome.

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

simonw  6 months ago

Paste this into a Chrome DevTools console on a Google site - sure looks like a special API to me:

    chrome.runtime.sendMessage(
        'nkeimhogjdpnpccoofpliimaahmaaome', {
            method: 'cpu.getInfo'
        }, response => {
            console.log('CPU Info:\n', JSON.stringify(response, null, 2));
        }
    );

  • Jcampuzano2  6 months ago

    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

    • cassianoleal  6 months ago

      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.

danans  6 months ago

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.

  • runarberg  6 months ago

    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.

  • ranger_danger  6 months ago

    Any time things like this are needed, I think it should ask the user for permission first.

    • danans  6 months ago

      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.

      2 replies →