Log for Ubuntu 台灣社群
連 archive.ubuntu.com 和 security.ubuntu.com 都在炸……
Google Chrome 未經同意，悄悄在你的裝置上安裝 4 GB 的 AI 模型 （★ 142 分）
文章指控 Google Chrome 會在未明確告知與未徵得同意的情況下，把 Google 的裝置端大型語言模型 Gemini Nano（LLM, Large Language Model）下載到使用者裝置中。該模型檔名為 `weights.bin`，位於 Chrome 使用者資料中的 `OptGuideOnDeviceModel` 目錄，大小約 4 GB，用於「Help me write」、裝置端詐騙偵測、分頁群組建議、頁面摘要等 AI 功能。作者指出，相關 AI 功能在新版 Chrome 中可能預設啟用，使用者刪除檔案後 Chrome 仍會重新下載；若要阻止，通常得進入 `chrome://flags` 停用相關功能、使用企業政策工具，或移除 Chrome。
作者以全新 Apple Silicon macOS 測試環境驗證此行為：該 Chrome profile 只由自動化稽核工具透過 Chrome DevTools Protocol 操作，沒有人工鍵盤或滑鼠輸入，卻在背景於 14 分 28 秒內建立 `OptGuideOnDeviceModel` 目錄並寫入 4 GB 模型權重。macOS 的 `.fseventsd` 檔案系統事件、Chrome 的 `Local State`、功能旗標，以及 GoogleUpdater 紀錄均相互印證：Chrome 先判斷硬體效能與記憶體條件，再由瀏覽器本身下載與安裝模型。文章也批評 Chrome 147 的「AI Mode」膠囊狀按鈕容易讓人以為查詢會在本機模型處理，但實際上它連到 Google 雲端搜尋 AI 體驗，與本機 Gemini Nano 是不同路徑，可能造成使用者對資料流向的誤解。
在法律面，作者主張此作法可能違反 ePrivacy Directive（歐盟電子隱私指令）第 5(3) 條，因為在使用者終端設備儲存資訊通常需要事前、明確且知情同意；也可能牴觸 GDPR（General Data Protection Regulation，歐盟一般資料保護規則）第 5(1) 條的合法性、公平性與透明性原則，以及第 25 條的資料保護預設設計義務。文章並把問題延伸到 ESG（環境、社會與治理）：每台裝置一次 4 GB 下載約耗電 0.24 kWh、排放 0.06 公斤 CO2e（二氧化碳當量）；若有 1 億、5 億、10 億台裝置收到模型，估計分別造成 6,000、30,000、60,000 噸 CO2e，還不含重新下載、模型更新、推論耗能與 SSD 儲存空間的隱含碳排。作者建議 Google 改採明確選擇加入、首次使用 AI 功能時才下載、在設定中清楚列出模型大小與用途、提供「移除並停止下載」按鈕、尊重刪除行為，並在永續報告中揭露這類模型配送的範疇三第 11 類排放（售出產品使用階段排放）。
Hacker News 留言多半把焦點放在「同意」與瀏覽器信任邊界。有些人認為瀏覽器不可能對每個相依元件都逐一詢問，但 4 GB 的隱藏模型已超出一般更新或快取的合理預期；也有人反問若 4 GB 可以接受，那 40 GB 或 400 GB 的界線在哪裡。許多留言批評自動更新已被大型科技公司濫用，應限於安全修補與錯誤修正；也有不少人因此推薦 Firefox、LibreWolf、Helium、Orion 或去 Google 化的 Chromium 變體，特別提到 Firefox 可關閉 AI 功能、仍能完整使用 uBlock Origin。不過也有人指出 Chrome 在 Google Meet 等服務仍有體驗優勢，反映使用者即使不信任 Google，也常因相容性與工作需求被迫保留 Chrome。
技術討論中，有留言補充 Chrome 的 `#optimization-guide-on-device-model` 與 `#prompt-api-for-gemini-nano` 旗標若啟用，網頁可透過 `LanguageModel.create()` 觸發一次性模型下載；也有人指出 Chrome 148 起桌面版可能把此行為變成預設，且下載前會檢查磁碟與暫存空間。另有使用者回報最新版 Chrome 尚未出現模型檔，推測這可能是分批推出或依硬體資格啟用。環境論述則引發分歧：批評者認為把 4 GB 傳輸稱為氣候災難過度誇張，且本機 LLM 可能比雲端資料中心推論更省；支持者則強調 Chrome 規模會把個別小成本放大成 PB 到 EB 等級流量，對限量行動網路、慢速 ADSL、漫遊方案與低容量筆電儲存空間都是實際負擔，也等於把 Google 的 AI 運算與儲存成本轉嫁給使用者。
👥 156 則討論、評論 💬
https://news.ycombinator.com/item?id=48019219
文章指控 Google Chrome 會在未明確告知與未徵得同意的情況下，把 Google 的裝置端大型語言模型 Gemini Nano（LLM, Large Language Model）下載到使用者裝置中。該模型檔名為 `weights.bin`，位於 Chrome 使用者資料中的 `OptGuideOnDeviceModel` 目錄，大小約 4 GB，用於「Help me write」、裝置端詐騙偵測、分頁群組建議、頁面摘要等 AI 功能。作者指出，相關 AI 功能在新版 Chrome 中可能預設啟用，使用者刪除檔案後 Chrome 仍會重新下載；若要阻止，通常得進入 `chrome://flags` 停用相關功能、使用企業政策工具，或移除 Chrome。
作者以全新 Apple Silicon macOS 測試環境驗證此行為：該 Chrome profile 只由自動化稽核工具透過 Chrome DevTools Protocol 操作，沒有人工鍵盤或滑鼠輸入，卻在背景於 14 分 28 秒內建立 `OptGuideOnDeviceModel` 目錄並寫入 4 GB 模型權重。macOS 的 `.fseventsd` 檔案系統事件、Chrome 的 `Local State`、功能旗標，以及 GoogleUpdater 紀錄均相互印證：Chrome 先判斷硬體效能與記憶體條件，再由瀏覽器本身下載與安裝模型。文章也批評 Chrome 147 的「AI Mode」膠囊狀按鈕容易讓人以為查詢會在本機模型處理，但實際上它連到 Google 雲端搜尋 AI 體驗，與本機 Gemini Nano 是不同路徑，可能造成使用者對資料流向的誤解。
在法律面，作者主張此作法可能違反 ePrivacy Directive（歐盟電子隱私指令）第 5(3) 條，因為在使用者終端設備儲存資訊通常需要事前、明確且知情同意；也可能牴觸 GDPR（General Data Protection Regulation，歐盟一般資料保護規則）第 5(1) 條的合法性、公平性與透明性原則，以及第 25 條的資料保護預設設計義務。文章並把問題延伸到 ESG（環境、社會與治理）：每台裝置一次 4 GB 下載約耗電 0.24 kWh、排放 0.06 公斤 CO2e（二氧化碳當量）；若有 1 億、5 億、10 億台裝置收到模型，估計分別造成 6,000、30,000、60,000 噸 CO2e，還不含重新下載、模型更新、推論耗能與 SSD 儲存空間的隱含碳排。作者建議 Google 改採明確選擇加入、首次使用 AI 功能時才下載、在設定中清楚列出模型大小與用途、提供「移除並停止下載」按鈕、尊重刪除行為，並在永續報告中揭露這類模型配送的範疇三第 11 類排放（售出產品使用階段排放）。
Hacker News 留言多半把焦點放在「同意」與瀏覽器信任邊界。有些人認為瀏覽器不可能對每個相依元件都逐一詢問，但 4 GB 的隱藏模型已超出一般更新或快取的合理預期；也有人反問若 4 GB 可以接受，那 40 GB 或 400 GB 的界線在哪裡。許多留言批評自動更新已被大型科技公司濫用，應限於安全修補與錯誤修正；也有不少人因此推薦 Firefox、LibreWolf、Helium、Orion 或去 Google 化的 Chromium 變體，特別提到 Firefox 可關閉 AI 功能、仍能完整使用 uBlock Origin。不過也有人指出 Chrome 在 Google Meet 等服務仍有體驗優勢，反映使用者即使不信任 Google，也常因相容性與工作需求被迫保留 Chrome。
技術討論中，有留言補充 Chrome 的 `#optimization-guide-on-device-model` 與 `#prompt-api-for-gemini-nano` 旗標若啟用，網頁可透過 `LanguageModel.create()` 觸發一次性模型下載；也有人指出 Chrome 148 起桌面版可能把此行為變成預設，且下載前會檢查磁碟與暫存空間。另有使用者回報最新版 Chrome 尚未出現模型檔，推測這可能是分批推出或依硬體資格啟用。環境論述則引發分歧：批評者認為把 4 GB 傳輸稱為氣候災難過度誇張，且本機 LLM 可能比雲端資料中心推論更省；支持者則強調 Chrome 規模會把個別小成本放大成 PB 到 EB 等級流量，對限量行動網路、慢速 ADSL、漫遊方案與低容量筆電儲存空間都是實際負擔，也等於把 Google 的 AI 運算與儲存成本轉嫁給使用者。
👥 156 則討論、評論 💬
https://news.ycombinator.com/item?id=48019219
CVE-2026-31431：Copy Fail 對上 rootless 容器 （★ 122 分）
這篇文章實測 CVE-2026-31431（Copy Fail）在 rootless Podman（以非 root 身分執行的 Podman）中的影響。作者先拆解公開 exploit，指出所謂 shellcode 其實是一個極小的 ELF（Executable and Linkable Format，Linux 常見可執行檔格式）二進位檔，會透過 `setuid(0)` 嘗試取得 root，接著執行 `/bin/sh`。攻擊手法不是直接改寫磁碟上的 `/usr/bin/su`，而是利用 Linux 核心的 AF_ALG（核心提供給使用者空間的加密 API）與 `splice()`，把惡意 ELF 分段寫入 `/usr/bin/su` 的頁面快取（page cache），讓系統執行 `su` 時載入被污染的快取內容。
作者在 Fedora 43、Linux 6.17.1 的測試環境中重現漏洞，並用 `strace` 追蹤 system call（系統呼叫），確認 exploit 會建立 AF_ALG socket、綁定到 `authencesn(hmac(sha256),cbc(aes))`，再以 4 位元組為單位將 payload 寫入頁面快取。由於 `strace` 會影響 SUID（Set User ID，執行時套用檔案擁有者身分）程式的權限轉換，作者另用 eBPF（extended Berkeley Packet Filter，可在核心層追蹤事件的機制）從主機觀察 `setuid(0)`：未受 `ptrace` 干擾時，漏洞確實能在容器內取得 root shell。
關鍵結論是，rootless Podman 的 User Namespace（使用者命名空間）阻止了這次權限提升擴散到主機。容器內的 UID 0 會對應到主機上的一般使用者 UID 1000，也就是 `podman` 帳號；因此攻擊者即使在容器內看到 root prompt，也無法修改主機系統檔案、讀取主機 `/etc/shadow`，或操作命名空間外的主機程序。作者認為這正是 rootless 架構的價值，也建議 OpenShift 使用者啟用 pod 的 User Namespace。不過文章後續補充指出，頁面快取仍可能在同一主機上被共享：若多個容器共用相同映像檔層，一個惡意 CI 工作可能污染某個二進位檔的快取，導致其他使用同一層的容器執行被毒化的版本，削弱容器之間的隔離。
Hacker News 討論多半肯定文章對 exploit 機制的拆解，但也有不少人提醒，這不是新的 CVE 公告，而是一次 rootless 容器情境下的實驗紀錄。技術上最受重視的批評是：Copy Fail 的「寫入唯讀頁面快取」原語仍然成功，rootless Podman 只是讓這個特定的 `su` 權限提升無法變成主機 root；若攻擊目標換成共用映像檔層、唯讀 bind mount、憑證目錄或其他 CoW（copy-on-write，寫入時複製）來源，仍可能破壞跨容器或跨租戶隔離。也有人指出，單靠 systemd 的 CapabilityBoundingSet（能力邊界設定）只能限制完整 root 權限，無法涵蓋 Copy Fail 可造成的其他檔案快取污染情境。
社群也討論了緩解方式與架構取捨。有人建議暫時停用 `algif_aead` 模組，或在 seccomp（secure computing mode，Linux 限制 system call 的沙箱機制）政策中封鎖 AF_ALG；Docker/Moby 與 containers 生態也已有相關政策或工具更新。反方則質疑是否應因單一漏洞長期停用核心加密介面，但多位留言者認為 AF_ALG 很少被一般工作負載使用，且過去曾多次出現安全問題，封鎖它的實務成本相對低。更廣泛的討論則集中在容器是否足以作為安全邊界：有人主張容器是便利邊界而非強安全邊界，microVM、gVisor 或完整 VM 的攻擊面較小；也有人認為安全隔離本來就是連續光譜，rootless 容器至少能有效降低這類 Linux 核心本機權限提升漏洞的直接傷害。
👥 57 則討論、評論 💬
https://news.ycombinator.com/item?id=48017813
這篇文章實測 CVE-2026-31431（Copy Fail）在 rootless Podman（以非 root 身分執行的 Podman）中的影響。作者先拆解公開 exploit，指出所謂 shellcode 其實是一個極小的 ELF（Executable and Linkable Format，Linux 常見可執行檔格式）二進位檔，會透過 `setuid(0)` 嘗試取得 root，接著執行 `/bin/sh`。攻擊手法不是直接改寫磁碟上的 `/usr/bin/su`，而是利用 Linux 核心的 AF_ALG（核心提供給使用者空間的加密 API）與 `splice()`，把惡意 ELF 分段寫入 `/usr/bin/su` 的頁面快取（page cache），讓系統執行 `su` 時載入被污染的快取內容。
作者在 Fedora 43、Linux 6.17.1 的測試環境中重現漏洞，並用 `strace` 追蹤 system call（系統呼叫），確認 exploit 會建立 AF_ALG socket、綁定到 `authencesn(hmac(sha256),cbc(aes))`，再以 4 位元組為單位將 payload 寫入頁面快取。由於 `strace` 會影響 SUID（Set User ID，執行時套用檔案擁有者身分）程式的權限轉換，作者另用 eBPF（extended Berkeley Packet Filter，可在核心層追蹤事件的機制）從主機觀察 `setuid(0)`：未受 `ptrace` 干擾時，漏洞確實能在容器內取得 root shell。
關鍵結論是，rootless Podman 的 User Namespace（使用者命名空間）阻止了這次權限提升擴散到主機。容器內的 UID 0 會對應到主機上的一般使用者 UID 1000，也就是 `podman` 帳號；因此攻擊者即使在容器內看到 root prompt，也無法修改主機系統檔案、讀取主機 `/etc/shadow`，或操作命名空間外的主機程序。作者認為這正是 rootless 架構的價值，也建議 OpenShift 使用者啟用 pod 的 User Namespace。不過文章後續補充指出，頁面快取仍可能在同一主機上被共享：若多個容器共用相同映像檔層，一個惡意 CI 工作可能污染某個二進位檔的快取，導致其他使用同一層的容器執行被毒化的版本，削弱容器之間的隔離。
Hacker News 討論多半肯定文章對 exploit 機制的拆解，但也有不少人提醒，這不是新的 CVE 公告，而是一次 rootless 容器情境下的實驗紀錄。技術上最受重視的批評是：Copy Fail 的「寫入唯讀頁面快取」原語仍然成功，rootless Podman 只是讓這個特定的 `su` 權限提升無法變成主機 root；若攻擊目標換成共用映像檔層、唯讀 bind mount、憑證目錄或其他 CoW（copy-on-write，寫入時複製）來源，仍可能破壞跨容器或跨租戶隔離。也有人指出，單靠 systemd 的 CapabilityBoundingSet（能力邊界設定）只能限制完整 root 權限，無法涵蓋 Copy Fail 可造成的其他檔案快取污染情境。
社群也討論了緩解方式與架構取捨。有人建議暫時停用 `algif_aead` 模組，或在 seccomp（secure computing mode，Linux 限制 system call 的沙箱機制）政策中封鎖 AF_ALG；Docker/Moby 與 containers 生態也已有相關政策或工具更新。反方則質疑是否應因單一漏洞長期停用核心加密介面，但多位留言者認為 AF_ALG 很少被一般工作負載使用，且過去曾多次出現安全問題，封鎖它的實務成本相對低。更廣泛的討論則集中在容器是否足以作為安全邊界：有人主張容器是便利邊界而非強安全邊界，microVM、gVisor 或完整 VM 的攻擊面較小；也有人認為安全隔離本來就是連續光譜，rootless 容器至少能有效降低這類 Linux 核心本機權限提升漏洞的直接傷害。
👥 57 則討論、評論 💬
https://news.ycombinator.com/item?id=48017813