你有沒有發現過，硬碟空間無緣無故少了 4GB？不是 Windows 更新、不是 macOS 系統快照，而是你的瀏覽器——Chrome——在背景偷偷下載了一個 AI 模型。

這件事不是偶然。安全研究員 Michael Moran 在自己的 macOS 筆電上發現，Chrome 在沒有跳出任何同意視窗的情況下，默默下載了約 4GB 的 Gemini Nano 模型檔案。更驚人的是，就算你把檔案手動刪掉，Chrome 下次啟動又會自動重新下載。這不是 bug，這是 Google 的工程設計。

檔案怎麼進去你的電腦的？

一切要從一個名叫 OptGuideOnDeviceModel 的目錄說起。

在你的 Chrome 使用者設定檔中，藏著這個目錄。裡面有個檔案叫 weights.bin，大小約 4GB。這是 Gemini Nano——Google 的裝置端大型語言模型——的權重檔。Chrome 用它來驅動「幫我寫」（Help me write）、裝置端詐騙偵測，以及其他 AI 輔助瀏覽功能。

重點是：這個檔案出現的時候，沒有任何同意對話框。Chrome 設定裡沒有「下載一個 4GB 的 AI 模型」這個核取方塊。下載會在 Chrome 的 AI 功能啟用時觸發，而在近期版本的 Chrome 中，這些功能預設就是開啟的。只要你的硬體符合需求，Chrome 就會把你的裝置當成部署目標，直接寫入模型。

Moran 在報告中列舉了多個 Windows 使用者的回報：使用者手動刪除檔案後，Chrome 重新下載；再次刪除，再次下載。已經形成一個「刪除→下載→刪除→下載」的循環。根據社群報告，讓刪除真正生效的唯一方法，是透過 chrome://flags 關閉 Chrome 所有 AI 功能，或者使用企業政策工具——後者對一般家用使用者來說幾乎不可能操作。

14 分 28 秒：作者如何抓到鐵證

Moran 不是第一個發現這件事的人。網路上早有 Windows 使用者抱怨硬碟空間被默默吃掉。但 Google 可以（而且很可能會）把這些指控歸類為「非典型配置下的個案」。

所以他選擇了另一個平臺——macOS——來做乾淨的驗證。

macOS 有一個核心層級的檔案系統事件記錄，叫做 .fseventsd。它會記錄每一次檔案建立、修改和刪除，獨立於任何應用程式的日誌系統。Chrome 沒辦法改寫它，Google 沒辦法遠端刪除它，而且記錄這些事件的頁面檔案在你刪除原始檔案後仍然存在。

Moran 在 2026 年 4 月 23 日建立了一個全新的 Chrome 使用者資料目錄，用來執行自動化的 WebSentinel 隱私掃描。測試驅動程式完全使用 Chrome DevTools Protocol 運作：載入一個頁面、停留五分鐘（不輸入任何東西）、關閉 Chrome、然後切換到下一個網站。從頭到尾沒有人類的鍵盤或滑鼠操作。所有 Chrome 的「AI 模式」介面從未被觸及——事實上所有 UI 介面都未被觸及，因為驅動程式只透過 CDP 與文件互動，網址列從未輸入過任何內容。

到了 4 月 29 日，這個設定檔中多出了 4GB 的 OptGuideOnDeviceModel 權重檔。Moran 回頭查 .fseventsd，拿到了三份精確到 byte 的時間戳記錄：

4 月 24 日 16:38:54（歐洲中部時間）——Chrome 在使用者設定檔中建立了 OptGuideOnDeviceModel 目錄。

16:47:22——三個並行的解壓縮子程序在 /private/var/folders/.../com.google.Chrome.chrome_chrome_Unpacker_BeginUnzipping.*/ 建立了暫存目錄。其中一個（代號 5xzqPo）寫入了 weights.bin、manifest.json、_metadata/verified_contents.json 和 on_device_model_execution_config.pb。另外兩個分別寫入了憑證撤銷清單更新和瀏覽器預載資料更新。Chrome 把安全性更新、預載資料更新，以及 4GB 的 AI 模型，全部打包在同一個閒置時段下載，彷彿它們是同等級的東西。

16:53:22——解壓縮後的 weights.bin 被移動到最終位置 OptGuideOnDeviceModel/2025.8.8.1141/weights.bin，同時還有 adapter_cache.bin、encoder_cache.bin 以及配套的 metadata 和執行設定檔 on_device_model_execution_config.pb。與此同時，四個額外的模型目標（編號 40、49、51、59）在 Chrome 的最佳化指南模型儲存庫中註冊了新的條目——這些是與 LLM 搭配的較小型文字安全和提示路由模型。在這一刻之前，這個設定檔中完全不存在任何這些目標。

總安裝時間：14 分 28 秒。整個過程中人類對設定檔的操作：零次。 測試驅動程式當時要麼停留在第三方首頁，要麼正在轉換網站——解壓縮程序在背景中觸發，而一個分頁正在等待五分鐘的計時器到期。

Moran 強調，暫存目錄的名稱是最關鍵的證據。前綴 com.google.Chrome.chrome_chrome_* 是 Chrome 自己的套件 ID 和子程序命名慣例——不是 com.google.GoogleUpdater.*，不是 com.google.GoogleSoftwareUpdate.*。寫入檔案的就是 Chrome 本身——是你安裝來瀏覽網頁的那個瀏覽器程序，直接伸進你的檔案系統。

不只是隱私問題，更是氣候問題

這不是 Moran 第一次揭露這種行為。幾週前他才報導過 Anthropic 的 Claude Desktop 在做類似的操作——當使用者啟動 Claude Desktop 時，在同一個程序中自動將 Native Messaging bridge 註冊到七個 Chromium 瀏覽器（Chrome、Edge、Brave、Opera、Vivaldi 等）的設定檔中，而且同樣會在使用者手動刪除後自動重建。

這兩件事的分析框架有顯著相似性：違反軟體信任邊界、缺乏同意對話框、沒有退出選項、刪除後自動重建。

但 Chrome 的案例多了一個全新的維度：環境影響。

以 Chrome 的龐大規模——約 20 億臺裝置——來計算，一次模型推送的碳排放量，取決於多少裝置實際接收，落在 六千到六萬公噸 CO₂ 當量 之間。

這是一個什麼概念？根據 Moran 引用的估算數據，這相當於 Google 單方面決定——20 億人的預設瀏覽器要大規模散佈一個他們未曾要求的 4GB 二進位檔——而產生的環境代價。更不用說，這不是一次性事件：如果模型需要更新版本（新的權重修正、新的版本號），同一套自動推送機制會再次觸發，每次都是同樣的碳排放量。

從法律層面來看，Moran 認為這直接違反了歐盟 ePrivacy 指令第 5(3) 條（未經同意在終端設備上儲存資訊）、GDPR 第 5(1) 條的合法性、公平性和透明性原則，以及第 25 條的資料保護設計義務。對受 CSRD（企業永續性報告指令）規範的企業來說，這種程度的環境影響還必須列為應通報事件。

為什麼「裝置端 AI」沒有想像中無害

你可能會想：Google 不是說裝置端 AI 處理比較好嗎？資料不用上雲端、隱私更安全、處理速度更快？

這些說法本身沒有問題。裝置端推論確實避免了資料傳輸到雲端伺服器的風險。但問題在於：模型本身的下載與儲存是分開的議題。

一個 4GB 的 LLM 權重檔，對現代旗艦手機或高階筆電來說或許還好，但對以下裝置就不是這麼回事了：

不只是儲存空間。這 4GB 模型的下載本身就要耗費網路頻寬。對使用行動網路或有限量方案的使用者來說，這是實質的費用。模型下載後的解析和解壓縮，會消耗 CPU 和電力——對筆電使用者來說，這代表電池續航力的直接損失。

更重要的是：你沒有被詢問。沒有人問你願不願意花這 4GB 空間、用不用得到這些 AI 功能、接不接受背景流量的增加。Chrome 安靜地在背景中完成了這一切。

法律怎麼看這件事？

Moran 在報告中明確指出，Google 這一行為至少違反了三項歐盟法規。首先是 ePrivacy 指令第 5(3) 條，該條文規定未經使用者同意不得在終端設備上儲存或存取資訊。4GB 的模型檔案顯然符合「資訊」的定義，而 Chrome 沒有跳出任何同意識窗或核取方塊。

其次是 GDPR 第 5(1) 條的合法性、公平性和透明性原則。合法意味著有法律依據（通常是用戶同意或正當利益）；公平意味著使用者知道他們同意了什麼；透明意味著公司必須清楚說明資料處理的範圍。Chrome 在背景中下載 4GB 模型，沒有告知、沒有同意、沒有說明——三個原則一次違反。

第三是 GDPR 第 25 條的資料保護設計義務。這個條文要求資料控管者在設計系統時，就應將資料保護原則納入考量。將 AI 模型下載設為預設啟用、且不提供明確的退出選項，正好與此原則背道而馳。

對台灣使用者來說，雖然歐盟 GDPR 不直接適用，但台灣的個人資料保護法在 2023 年修訂後，對於「自動化處理」和「個人資料的國際傳輸」有了更明確的規範。如果 Chrome 在下載模型時同時收集了使用者的硬體資訊（例如 Moran 發現的 GPU 型號、VRAM 大小等用於判斷是否符合硬體需求），這些資料可能涉及個資法的適用範圍。

使用者可以怎麼處理？

如果你不想讓 Chrome 擅自下載 4GB 的 AI 模型，目前有以下幾種方法：

方法一：關閉 Chrome AI 旗標（最直接）

在 Chrome 網址列輸入 chrome://flags，在搜尋欄輸入 optimization-guide 或 on-device-ai，把所有相關旗標設為「Disabled」。根據 Moran 的測試，這包括 Optimization Guide、Help me write、Compose 等功能的旗標。

但注意：Google 更新頻繁，旗標名稱和可用選項會隨版本變動。你可能需要每隔一段時間重新檢查。

方法二：檢查 Chrome 設定中的 AI 功能

進入 Chrome 設定 → 「AI」或「進階」相關區塊，關閉所有 AI 相關的開關。但 Moran 指出，目前 Chrome 的設定頁面中並沒有「下載 4GB 模型」這個選項，所以這個方法只能作為輔助。

方法三：考慮替代瀏覽器

這是最直接、最徹底的方法：

方法四：接受但管理

如果你的電腦儲存空間充足、使用固網不需擔心流量，也可以選擇接受這個下載——畢竟裝置端 AI 確實有一些實用功能。但要意識到這是你「選擇接受」而不是「被強迫接受」的區別。

打開你的儲存空間，檢查那 4GB

這件事的本質，說穿了不是關於 AI 好不好，也不是關於 Google 是不是壞人。而是關於一個基礎權力問題：誰可以決定你的電腦上放了什麼軟體和資料？

以往這個問題的答案是「使用者自己」。你安裝了應用程式，應用程式在你的許可下使用資源。但 Moran 揭露的這個模式顯示，我們正在進入一個新階段：AI 公司為了讓自己的模型能夠在裝置端運作，開始繞過正常的軟體安裝流程，在使用者的電腦上執行寫入操作。從技術角度來看，這最有效率——直接寫入目標位置，不需要使用者點擊任何安裝精靈。從使用者角度來看，這叫做不請自來的軟體行為。

更值得關注的是，這不是單一事件。Anthropic 和 Google 都在做類似的事。未來可能會有更多 AI 公司跟進。如果你今天允許瀏覽器未經同意下載 4GB，明天你可能允許作業系統未經同意上傳你的資料——因為兩者背後的邏輯是相同的：「這對你有好處，所以我們不需要問你」。

打開你的磁碟工具，搜尋 weights.bin 或 OptGuideOnDeviceModel。如果找到了，你知道那是什麼了。從那裡開始，決定你的下一步。