研究揭露：Chrome 擴充功能外傳 3,700 萬名使用者的瀏覽資料 https://qcontinuum.substack.com/p/spying-chrome-extensions-287-extensions-495
研究者針對 Chrome 擴充功能建立自動化掃描管線：在 Docker 容器內執行 Chromium 瀏覽器，把所有流量導向 MITM（man-in-the-middle，中間人代理）來側錄請求，再用不同長度的測試 URL 觸發瀏覽行為，觀察對外送出的流量大小是否會隨 URL 長度線性成長，以此推定擴充功能是否把瀏覽網址（甚至整個 HTTP 請求）外傳。團隊用這套方法標記出 287 個會外洩瀏覽紀錄的擴充功能，合計約 3,740 萬次安裝，約占全球 Chrome 使用者的 1%。報告指出涉入者橫跨資料經紀商與多個開發群體，包括 Similarweb、Curly Doggo、Offidocs、疑似中國相關行為者，以及被推測可能是 Similarweb 延伸勢力的「Big Star Labs」。
他們以
報告強調風險不只在「被看過哪些網站」，而是這些 URL 常含個資識別線索與查詢參數，可能延伸到廣告投放側寫、企業內網與 SaaS 控制台網址外洩，甚至在某些情境下可與 Cookie 等資料拼出更完整的使用者工作階段。文中列出多種外傳手法：最常見是直接把
留言區把焦點拉回擴充功能機制本身的結構性問題：不少人震驚於擴充功能權限的粗粒度，認為即便只是改 CSS 的擴充功能，也可能在內容腳本情境中讀到密碼欄位，主張應該拆出更細的權限；但也有人指出，若嚴格隔離頁面情境，可能衝擊大量既有登入介面與相容性。多位開發者分享「收購邀約」長期轟炸的經驗：只要擴充功能有一定使用者規模，就有人出價要求置入追蹤或惡意行為，形成典型供應鏈攻擊（買下既有信任再翻轉用途），因此有人乾脆只信任 uBlock Origin、Bitwarden 等知名且開源的工具。另一條討論延伸到「開源也不等於可信任交付」：就算程式碼公開，商店發佈的套件未必可證明是由同一份原始碼建置；不過也有人回應，擴充功能安裝後是本機檔案（如 .crx、Firefox 的 .xpi），可以自行解壓比對，並推薦 CRX Viewer 等工具，同時提到 npm 的 provenance／trusted publishing 作法值得借鏡。整體輿論也批評 Google 對 Chrome Web Store 的審核與自動更新機制過於寬鬆，有人甚至以「下載後用 Load unpacked 安裝、避免自動更新」來提高可稽核性，但也引發另一派擔憂：停用更新會讓已知漏洞更難被修補；此外也有人提醒，就算移除擴充功能，既有的資料側寫可能已被建檔、轉賣並持續影響你之後看到的內容。
https://news.ycombinator.com/item?id=46973083
研究者針對 Chrome 擴充功能建立自動化掃描管線：在 Docker 容器內執行 Chromium 瀏覽器，把所有流量導向 MITM（man-in-the-middle，中間人代理）來側錄請求，再用不同長度的測試 URL 觸發瀏覽行為，觀察對外送出的流量大小是否會隨 URL 長度線性成長，以此推定擴充功能是否把瀏覽網址（甚至整個 HTTP 請求）外傳。團隊用這套方法標記出 287 個會外洩瀏覽紀錄的擴充功能，合計約 3,740 萬次安裝，約占全球 Chrome 使用者的 1%。報告指出涉入者橫跨資料經紀商與多個開發群體，包括 Similarweb、Curly Doggo、Offidocs、疑似中國相關行為者，以及被推測可能是 Similarweb 延伸勢力的「Big Star Labs」。
他們以
mitmdump 產出的 JSON 記錄計算每個目的網域與端點的 bytes_out（送出位元組）與 payload_size（壓縮後 URL 長度總和），用簡單迴歸得到外洩比例 R；R ≥ 1 視為「確定外洩」，0.1 ≤ R < 1 視為「高度可疑」再人工檢視，並採兩階段測試以節省成本。整體掃描估計花了 930 個 CPU 天、平均每個擴充功能約 10 分鐘。團隊也架設 honeypot（蜜罐）並投放「誘餌 URL」，觀察到多個 IP 範圍反覆抓取資料，其中 Kontera 相關來源最活躍，另外也出現與 HashDit、Blocksi AI Web Filter 相關的來源；搭配 OSINT（open-source intelligence，開源情蒐）檢視開發者信箱、隱私權政策、商店描述與外傳網域的憑證等，進一步把 Similarweb 的擴充功能、Kontera 抓取端與其他擴充功能串成關聯網。作者表示為避免對手快速繞過偵測，未公開完整掃描程式碼與環境細節。報告強調風險不只在「被看過哪些網站」，而是這些 URL 常含個資識別線索與查詢參數，可能延伸到廣告投放側寫、企業內網與 SaaS 控制台網址外洩，甚至在某些情境下可與 Cookie 等資料拼出更完整的使用者工作階段。文中列出多種外傳手法：最常見是直接把
visited_url 放在查詢參數或 POST 內容明文送出；也有用 ROT47（字元替換式簡單混淆）、XOR + Base64、Hex 編碼，或用 LZString 壓縮後再傳送；更進階者會在瀏覽器端產生一次性 AES-256（Advanced Encryption Standard，對稱式加密）金鑰加密資料，再用內嵌的 RSA（非對稱式加密）公鑰封裝金鑰一併送出，讓外部難以直接解密但仍可被「流量與 URL 長度同步成長」的方式抓到。此外也看到把瀏覽資訊塞進請求標頭，甚至利用 Google Analytics（GA，Google 的網站分析服務）的 Measurement Protocol 上送「page_location」等欄位。作者同時提醒，並非所有被標記的擴充功能都必然出於惡意，有些可能以安全檢測或功能需求為由取得瀏覽紀錄，但整體規模仍令人警惕。留言區把焦點拉回擴充功能機制本身的結構性問題：不少人震驚於擴充功能權限的粗粒度，認為即便只是改 CSS 的擴充功能，也可能在內容腳本情境中讀到密碼欄位，主張應該拆出更細的權限；但也有人指出，若嚴格隔離頁面情境，可能衝擊大量既有登入介面與相容性。多位開發者分享「收購邀約」長期轟炸的經驗：只要擴充功能有一定使用者規模，就有人出價要求置入追蹤或惡意行為，形成典型供應鏈攻擊（買下既有信任再翻轉用途），因此有人乾脆只信任 uBlock Origin、Bitwarden 等知名且開源的工具。另一條討論延伸到「開源也不等於可信任交付」：就算程式碼公開，商店發佈的套件未必可證明是由同一份原始碼建置；不過也有人回應，擴充功能安裝後是本機檔案（如 .crx、Firefox 的 .xpi），可以自行解壓比對，並推薦 CRX Viewer 等工具，同時提到 npm 的 provenance／trusted publishing 作法值得借鏡。整體輿論也批評 Google 對 Chrome Web Store 的審核與自動更新機制過於寬鬆，有人甚至以「下載後用 Load unpacked 安裝、避免自動更新」來提高可稽核性，但也引發另一派擔憂：停用更新會讓已知漏洞更難被修補；此外也有人提醒，就算移除擴充功能，既有的資料側寫可能已被建檔、轉賣並持續影響你之後看到的內容。
https://news.ycombinator.com/item?id=46973083
