Why I Stopped Letting Websites Download Gemini Nano Into Every Browser Profile

The issue of websites downloading Gemini Nano into every browser profile has become a significant concern. Initially, a synced browser profile's backup size increased from 56 MB to 2.74 GB compressed overnight. Upon unpacking, 93 MB of the data was the user's cookies, local storage, and IndexedDB, while the remaining 3.3 GB was attributed to Google's components.

These components included OptGuideOnDeviceModel, Gemini Nano, SODA, SODALanguagePacks, On-device speech recognition, OCR and accessibility, TranslateKit, Offline translation, and WasmTtsEngine, OnDeviceHeadSuggestModel, among others. This backup was being carried out by a tool that packs everything in the user-data directory except a blacklist, which had not included these folders.

Consequently, every time the browser closed, 2.7 GB of data was uploaded. Opening the browser on a second machine resulted in a 30-minute download before the window appeared.

The authors noticed that the downloads were happening across 2,068 profiles on their laptop, with 82 copies of the speech models (about 3.5 GB) and 83 copies of the translation model. Each model was downloaded separately, by a different profile, through that profile's proxy. This highlighted that it was not Chrome being greedy but rather the page that was making these requests.

The authors discovered that a web page asks for these components directly through an "await Translator.create()" or "await LanguageModel.create()" statement. After a single click on example.com, two new entries appeared in chrome://components: Chrome TranslateKit de-en and nano_v3_cpu_component. These components were downloaded into the profile and the download started.

The authors tested two command-line switches to see if they could prevent this behavior. The first switch was "--disable-component-update LanguageModel.availability() downloadable unavailable downloadable Translator , LanguageDetector , SpeechRecognition downloadable downloadable downloadable." This switch caused the page to see the on-device AI features as unavailable, but the downloads still happened.

The second switch, "--disable-component-update," made the APIs say they were downloadable, but it did not stop the page-triggered downloads. In fact, it stopped other updates as well. The authors concluded that this issue cannot be fixed with a launch flag and that the page must not be able to tell the difference between the modified and unmodified builds.

They were able to achieve this by making the availability() return the same value as before, registration and eligibility checks staying untouched, and refusing the download for the affected components.