The Mystery of Google Chrome's On Device Model

Button Solutions

Button Solutions

— 5 min read


https://www.linkedin.com/feed/update/urn:li:activity:7457020608120242178/
https://www.thatprivacyguy.com/blog/chrome-silent-nano-install/


This at first glance appears correct - but on deeper analysis does not measure up on Linux/Ubuntu. I measured 355MB download on Chrome 143 for the entire .config/google-chrome directory and 784MB for .cache/google-chrome
(using du -h -d 0)

It's possible on Mac OS that these numbers are larger. Below, we show that on Mac OS specifically, there are flags that do more than on other OS types.

Background

Google doesn't need to train on device - every keystroke you type into the search/navigation bar is sent to google as an autocomplete request (unless you provide a different provider aka keylogger).

Google provides several features through this service:

  • Helps with writing or rephrasing text
  • Warns you about scams
  • Summarizes web pages
  • Organizes your tabs

Given the diversity of scams, it seems like a decent feature to keep around. The writing/rephrasing etc. seems less relevant for an on-device model, but if you must have an AI model, better to keep it local.

Presence in Chromium Based Browsers

I also saw that in Brave that 7.6 MB of the exact same format in ~/snap/brave/current/.config/BraveSoftware/Brave-Browser/OnDeviceHeadSuggestModel in my case, was downloaded - same as in Google Chrome. This indicates strongly, combined with no apparent patches to block, that Brave uses the behavior of chrome and Google's on device model.

Chromium however did not show anything in the OnDeviceHeadSuggestModel directory - which is possible if they maintain either a separate set of patches or disable the flags by default (which can be the case for non-official builds)

Microsoft Edge 145 did not show this directory (but an interesting RevisitationBloomfilter did show up). Microsoft Edge is a closed source fork of chromium (https://github.com/MicrosoftEdge/MSEdge is the closest thing to open source) - so it is unclear what this does exactly without ghidra or similar.


4GB

Anyway, this particular claim of 4GB for me didn't measure up - but that doesn't mean it doesn't exist.

We see here in src/chrome/build.gn that the on device model is only included for this particular module in mac. Of course there are 249 instances of this string as of May 7th in .gn files - so this is a weak indicator.

It seems that the install of this 4GB is even less likely on Android:

(see the assert on line 7)

however src/components/optimization_guide/proto/BUILD.gn might indicate otherwise.

So we need to look deeper.

There appears to be a build flag, USE_ON_DEVICE_MODEL_SERVICE, which controls the include of this. It is set in src/services/on_device_model/public/cpp/BUILD.gn. We find in src/services/on_device_model/on_device_model.gni that the on device model really isn't included on android:

declare_args() {
  is_cbx = is_chromeos && overlay_include_cbx
}

declare_args() {
  # The on device model service is only enabled on a subset of platforms.
  # Exclude it on other platforms due to binary size.
  use_on_device_model_service = is_win || is_mac || is_linux || is_ios || is_cbx
}

declare_args() {
  # Constraint code is disabled on platforms where the on-device model does not
  # run due to binary size.
  enable_constraints = use_on_device_model_service
  enable_ml_internal =
      build_with_internal_optimization_guide && use_on_device_model_service
  use_chromeos_model_service = is_chrome_branded && is_cbx

  # Use MLKit public APIs to access AICore for non-Chrome branded builds.
  # MLKit is the developer-facing APIs and AICore is the system-level AI runtime
  # to host on-device model services. Chrome-branded builds use internal/private
  # APIs to access AICore directly.
  use_mlkit_for_aicore = !is_chrome_branded
}

So we have a few branches here: One, that if the builder is making chromium for Chrome OS, Mac OS, Windows, or Linux, we use the model service. If we are in Chrome OS only with branded Google Chrome, install a more complete on device model. We still have one flag, build_with_internal_optimization_guide, found in src/components/optimization_guide/features.gni:

declare_args() {
  # You can set the variable 'build_with_internal_optimization_guide' to true
  # even in a developer build in args.gn.  Setting this variable explicitly to true will
  # cause your build to fail if the internal files are missing.
  #
  # If changing the value of this, you MUST also update the following files depending on the
  # platform:
  # Android: Internal expectations files that verify the native libraries  are compiled into the Android binary.
  # ChromeOS: //lib/chrome_util.py in the Chromite repo (ex: https://crrev.com/c/3437291)
  # Linux: Internal archive files. //chrome/installer/linux/common/installer.include handles the
  # relevant files not being present.
  # Mac: //chrome/installer/mac/signing/parts.py
  # Windows: //chrome/installer/mini_installer/chrome.release and internal archive files
  if (is_fuchsia || is_android || is_ios) {
    # Fuchsia, Android, and iOS should work but are not included in the set we release for,
    # so we do not needlessly increase the binary size.
    build_with_internal_optimization_guide = false
  } else {
    # Use is_chrome_branded as a proxy for "does src-internal exist".
    build_with_internal_optimization_guide = is_chrome_branded
  }
}

What is interesting is that MLKit apparently runs even in non-branded chrome. We also might find that for iOS the Google Chrome build does not include the ML/AI model. But upon downloading latest Chrome for different OS'es, this is found to be false:

The biggest downloaded file is still iOS (not that the windows exe really counts).

So we are still left with a mystery, and no explanation for the 4GB claimed size. Exaggerated? Maybe.

Finally Found

This is not a random event. You can trigger it manually with chrome://flags/#optimization-guide-on-device-model with BypassPerfRequirements.

When does this happen? Is it a conspiracy - as stated by a bunch of posts on linkedin? Probably not - but it is interesting.

Diving Deep

The claim that 100 million devices are now lugging around 4GB of data they didn't ask for is a big one.

First off, in order to trigger download, I had to manually enable a flag to bypass performance requirements. So we need to know what those requirements are.

We also need to test some claims, like the potentially ai generated post here: https://www.vishwamdhavale.com/blog/chrome-gemini-nano-on-device. This file "cannot be deleted". If you delete weights.bin and disable this flag, the directory surprisingly becomes empty:

so, why this claim? It is problematic to have research like this.

Fortunately, I have a friend with a MacOS computer, and was able to verify that by default now the 4GB model is downloaded.

However, contrary to the sensationalist claims of the original writer - you can disable this model in chrome://flags.

So, in conclusion - don't trust everything you read, especially if it looks like it was written by AI and doing an expose on a giant corporation that will suffer much financial loss for such a claim, without more evidence than the words of the writer - especially if non-reproducible.

Why this relates to bots

This is the type of deep diving that leads to the sensors we use. Often times, hidden behind an obscure #define, we find an anomaly in TLS only available for Mac OS in a particular version of Chrome.

There are a lot of variants always being tried out on Chrome in particular - but if you know what you're doing, you don't have to rely on machine learning or AI to determine if access is valid or not.

Read more