구글 크롬, 사용자 동의 없이 4GB AI 모델 설치

Image generation details Model Flux.1 Dev (q8p) Architecture Flux DiT (Diffusion Transformer) + T5-XXL + CLIP-L text encoders · 12B (DiT) + 4.7B (T5-XXL) + 0.4B (CLIP-L) Text encoders T5-XXL + OpenAI CLIP ViT-L/14 VAE Flux VAE (f16) Sampler EulerA · 20 steps · guidance 4 Resolution 1344×768 Seed 37565907 Clip skip 1 Generator DrawThings (Flux.1 Dev q8p) via TPG Blog Pipeline Hardware Apple M1 Ultra · 20 cores (16 performance + 4 efficiency) · 48 cores GPU · 128 GB unified OS macOS 26.3 (build 25D125) Author Alexander Hanff Prompt A vast scorched cracked desert landscape, deep dry fissures splitting the orange-brown earth across the foreground, glowing embers visible deep in the cracks, hazy dark red sky thick with smoke and ash, blackened skeletal dead trees scattered on the horizon, broken silicon circuit boards motherboards and torn server racks half-buried in the cracked ground, low afternoon sun, photorealistic, shallow depth of field. (c) Hanff & Co. AB - CC BY-NC-SA 4.0 · https://www.thatprivacyguy.com/ This could be you Reach privacy, DP, security and AI leaders ~100k monthly readers — CPOs, DPOs, general counsel, CISOs, compliance teams. No tracking, no ad tech, no auction. Direct deal only. Get in touch Google Chrome silently installs a 4 GB AI model on your device Two weeks ago I wrote about Anthropic silently registering a Native Messaging bridge in seven Chromium-based browsers on every machine where Claude Desktop was installed [1]. The pattern was: install on user launch of product A, write configuration into the user's installs of products B, C, D, E, F, G, H without asking. Reach across vendor trust boundaries. No consent dialog. No opt-out UI. Re-installs itself if the user removes it manually, every time Claude Desktop is launched. This week I discovered the same pattern, executed by Google. Google Chrome is reaching into users' machines and writing a 4 GB on-device AI model file to disk without asking. The file is named weights.bin . It lives in OptGuideOnDeviceModel . It is the weights for Gemini Nano, Google's on-device LLM. Chrome did not ask. Chrome does not surface it. If the user deletes it, Chrome re-downloads it. The legal analysis is the same one I gave for the Anthropic case. The environmental analysis is new. At Chrome's scale, the climate bill for one model push, paid in atmospheric CO2 by the entire planet, is between six thousand and sixty thousand tonnes of CO2-equivalent emissions, depending on how many devices receive the push. That is the environmental cost of one company unilaterally deciding that two billion peoples' default browser will mass-distribute a 4 GB binary they did not request. This is, in my professional opinion, a direct breach of Article 5(3) of Directive 2002/58/EC (the ePrivacy Directive) [2], a breach of the Article 5(1) GDPR principles of lawfulness, fairness, and transparency [3], a breach of Article 25 GDPR's data-protection-by-design obligation [3], and an environmental harm of a magnitude that would be a notifiable event under the Corporate Sustainability Reporting Directive (CSRD) for any in-scope undertaking [4]. What is on the disk and how it got there On any machine that has Chrome installed, in the user profile, sits a directory whose name is OptGuideOnDeviceModel . Inside it is a file called weights.bin . The file is approximately 4 GB. It is the weights file for Gemini Nano. Chrome uses it to power features Google has marketed under names like "Help me write", on-device scam detection, and other AI-assisted browser functions. The file appeared with no consent prompt. There is no checkbox in Chrome Settings labelled "download a 4 GB AI model". The download triggers when Chrome's AI features are active, and those features are active by default in recent Chrome versions. On any machine that meets the hardware requirements, Chrome treats the user's hardware as a delivery target and writes the model. The cycle of deletion and re-download has been documented across multiple independent reports on Windows installations [5][6][7][8] - the user deletes, Chrome re-downloads, the user deletes again, Chrome re-downloads again. The only ways to make the deletion stick are to disable Chrome's AI features through chrome://flags or enterprise policy tooling that home users do not generally have, or to uninstall Chrome entirely [5]. On macOS the file lands as mode 600 owned by the user (so it is deletable in principle) but Chrome holds the install state in Local State after the bytes are written, and as soon as the variations server next tells Chrome the profile is eligible, the download fires again - the architecture is the same, only the file permissions differ. How I verified this on a freshly created Apple Silicon profile Most of the existing reporting on this behaviour is from Windows users who noticed their disk filling up - useful, but Google could (and probably will) try to characterise those reports as anecdotes from non-representative configurations. So I went looking for a clean witness on a different platform. The witness I found is macOS itself. The kernel keeps a filesystem event log called .fseventsd - it records every file create, modify and delete at the OS level, independent of any application logging. Chrome cannot edit it, Google cannot remotely reach it, and the page files that record the events survive the deletion of the files they reference. I created a Chrome user-data directory on 23 April 2026 to run an automated audit (one of the WebSentinel 100-site privacy sweeps). The audit driver is fully Chrome DevTools Protocol - it loads a page, dwells for five minutes with no input, captures events, closes Chrome between sites - and the profile had received zero keyboard or mouse input from a human at any point in its existence. Every "AI mode" surface in Chrome was untouched - in fact every UI surface in Chrome was untouched, the audit driver only interacts with the document via CDP and the omnibox is never reached. By 29 April the profile contained 4 GB of OptGuideOnDeviceModel weights - and I knew it because a routine du -sh of the audit-profile directory caught it during a cleanup pass. I went back to .fseventsd to ask exactly when those 4 GB landed. macOS gave me the answer, byte-precise, in three sequential page files: 24 April 2026, 16:38:54 CEST (14:38:54 UTC) - Chrome creates the OptGuideOnDeviceModel directory in the audit profile (page file 0000000003f7f339 ). 24 April 2026, 16:47:22 CEST (14:47:22 UTC) - three concurrent unpacker subprocesses spawn temporary directories in /private/var/folders/.../com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.*/ . One of them ( 5xzqPo ) writes weights.bin , manifest.json , _metadata/verified_contents.json and on_device_model_execution_config.pb . The second writes a Certificate Revocation List update. The third writes a browser preload-data update. Chrome batched a security update, a preload refresh and a 4 GB AI model into the same idle window, as if they were equivalent (page file 00000000040c8855 ). 24 April 2026, 16:53:22 CEST (14:53:22 UTC) - the unpacked weights.bin is moved to its final location at OptGuideOnDeviceModel/2025.8.8.1141/weights.bin along with adapter_cache.bin , encoder_cache.bin , _metadata/verified_contents.json and the execution config. Concurrently four additional model targets (numbered 40, 49, 51 and 59 in Chrome's optimization-guide enum) register fresh entries in optimization_guide_model_store - these are the smaller text-safety and prompt-routing models that pair with the LLM. None of these targets existed in the profile before this moment (page file 00000000040d0f9c ). Total install time, from directory creation to final move: 14 minutes and 28 seconds . Total human action against the profile during that window: none . The audit driver was either dwelling on a third-party home page or transitioning between sites - the unpacker fired in the background while a tab waited for a five-minute timer t