Chrome auto-downloads Gemini Nano weights (weights.bin, ~4 GB) into OptGuideOnDeviceModel with no consent prompt, re-downloading if deleted, on profiles with zero human input.
Key Takeaways
The install is triggered by OnDeviceModelBackgroundDownload flag, enabled before the settings UI that would let users refuse it even appears.
macOS .fseventsd kernel logs, Chrome Local State JSON, Chrome feature flags, and GoogleUpdater logs form a four-way evidence chain confirming the silent install on a never-human-touched audit profile in 14 minutes.
Removal requires finding a hidden profile path, deleting a read-only file (Windows), then disabling flags via chrome://flags or enterprise policy – or Chrome re-downloads automatically.
The component control plane (appid {44fc7fe2-65ce-487c-93f4-edee46eeaaab}) ships over plain HTTP; weights arrive via a separate OnDeviceModelComponentInstaller CDN path, not GoogleUpdater.
Author argues the pattern breaches ePrivacy Directive Article 5(3), GDPR Articles 5(1) and 25, and may trigger CSRD reporting obligations at billion-device scale.
Hacker News Comment Review
Commenters identified a concrete mitigation: disabling #optimization-guide-on-device-model and #prompt-api-for-gemini-nano in chrome://flags blocks the download, though the flags exist because the Prompt API lets any webpage call LanguageModel.create() to trigger it.
The environmental framing drew skepticism – several commenters called attributing 4 GB per device across a billion users as a climate disaster a stretch, separating that argument from the legitimate consent issue.
A notable side observation: because Chrome ships Gemini Nano (not Gemma), the weights are now effectively public, extractable without an Android device.
Notable Comments
@sigmoid10: Gemini Nano weights (called XS internally) are now de facto open since Chrome ships them – no Android phone required to extract them.
@z3t4: “Auto update is basically a root backdoor” – especially acute when the user is the product, not the customer.
