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.

• Use a Web Application Firewall (WAF): Services like Cloudflare, Sitelock, or Sucuri can filter out malicious bot traffic before it reaches your site.
• Implement Rate Limiting: Restrict the number of requests a single IP address can make within a specific timeframe to stop scraping and brute-force attempts.
• Add CAPTCHA Challenges: Use tools like reCAPTCHA on login, registration, and comment forms to distinguish human users from automated bots.
• Configure Robots.txt: Instruct well-behaved bots to avoid specific, sensitive areas of your website.
• Block Malicious IPs and User Agents: Identify suspicious IP addresses in your server logs and use your .htaccess file or security plugins to block them.
• Use Honeypots: Create hidden links or fields that are invisible to humans but enticing to bots; if something triggers that link, you know it is a bot and can block it. 

How to Identify Bot Traffic:

• Sudden Spikes: Unexplained traffic increases without corresponding conversions.
• High Bounce Rate: Instant departure from a page without interaction.
• Uniform Sessions: Identical session duration across thousands of visits.
• Unexpected Geography: A high volume of traffic from countries outside your target audience. 

For immediate relief, Button Solutions Toolbox is highly effective at detecting and mitigating automated attacks. 

• Web Application Firewalls (WAF): Use a WAF (e.g., Cloudflare, Imperva) to filter malicious traffic, block known bad IP addresses, and inspect HTTP/HTTPS requests before they reach your server.
• Rate Limiting & Throttling: Limit the number of requests a single user or IP can make in a given timeframe to prevent content scraping and brute-force login attempts.
• CAPTCHA and Challenges: Implement CAPTCHA (e.g., reCAPTCHA, Friendly Captcha) on login, comment, and contact forms to distinguish humans from bots.
• Behavioral Analysis & Machine Learning: Use advanced bot management solutions that analyze mouse movements, navigation, and scroll patterns to identify non-human traffic.
• Honeypots: Create hidden fields or links in your HTML that are invisible to humans but visible to bots. When a bot interacts with these "traps," they can be identified and blocked.
• Review robots.txt: Use robots.txt to guide good bots (like search engines) away from sensitive areas, though malicious bots often ignore this file.
• Block Known Bad User Agents & Hosting Providers: Block requests from outdated browsers and known data center proxy networks used for launching attacks.
• Device Fingerprinting: Identify bots by detecting patterns in browser characteristics, such as screen resolution, installed fonts, and plugins.
• Monitor Analytics: Watch for sudden traffic spikes, abnormally high bounce rates, and high numbers of failed login attempts, which often indicate bot activity. 

Though, you could always rely on https://button.solutions 😄