PACT：為 Web 設計的匿名憑證架構
Mozilla Hacks · 2026-06-23
Mozilla 密碼學工程師 Dennis Jackson 於 2026 年 6 月 23 日在 Mozilla Hacks 發表 PACT（Privacy-preserving Anonymous Credential Technology）的技術設計文件，說明如何在不暴露使用者身份的前提下，以密碼學憑證對抗爬蟲與濫用行為。PACT 以 Privacy Pass 協議為基礎，結合新型匿名信用憑證（Anonymous Credit Tokens，ACT），試圖在瀏覽器層面提供兼顧隱私與可信度的解決方案。這項提案正在 IETF 及 W3C 雙軌推進標準化，規格草稿與 WebAPI 設計已公開於 MoLE GitHub 組織。
背景
現有的反機器人機制（CAPTCHA、IP 封鎖、裝置指紋）正面臨兩難：越強力的驗證手段，對普通使用者越具侵入性，而使用 VPN 或 Tor 的隱私用戶則因「看起來像機器人」而遭到不公平限制。Privacy Pass 協議最初於 2018 年在 PETS 學術研討會發表，目的是減少 Cloudflare 對 Tor 使用者出現的 CAPTCHA 摩擦，其核心概念是「可驗證盲簽名（VOPRF）」——簽發方無法追蹤某張令牌的簽發與兌換之間的關聯。PACT 在此基礎上增加了狀態管理能力，讓網站可依行為動態調整信任等級，而不需要知道使用者是誰。
核心改動
PACT 架構引入三類角色。錨點（Anchor）是提供「稀缺性信號」的實體，例如訂閱服務或已驗證帳戶，其職責是依照 Privacy Pass 模型向符合條件的使用者發放 Endorsement 令牌，且簽發過程採用零知識技術，確保令牌在簽發與兌換之間不可連結（unlinkable）。協調器（Moderator）負責驗收 Endorsement 並發放具狀態的 Credential；Credential 內含計數器，記錄使用者行為的累積程度，但不對外揭露精確數值。Credential 呈現流程允許網站依行為結果給予獎勵或懲罰，整個過程不需要取得使用者的真實身份。
隱私保護的技術核心有兩層。第一層是「發行方盲化（Issuer Blinding）」，透過零知識證明讓 Moderator 無法得知使用者是透過哪個 Anchor 取得 Endorsement。第二層是針對匯聚式評分的多方運算（MPC），採用 Mozilla Prio 系統，讓多個簽發方可以協同計算聚合分數，卻不會洩漏個人記錄。Apple Private Relay 及 Private Cloud Compute 皆採用類似的隱私拆分設計。
規格細節
IETF 端的草稿包含兩份關鍵文件：draft-schlesinger-cfrg-act-00（Anonymous Credit Tokens 規格）以及 draft-orru-zkproof-sigma-protocols-01（用於零知識盲化的 Sigma 協議）。ACT 解決了 Privacy Pass 的根本限制——原始設計中每張令牌對應一次兌換，無法動態調整速率限制；ACT 透過可更新的內部計數器讓 Credential 本身持有狀態，實現細粒度的行為追蹤而不必重新發放令牌。W3C 端有一份 WebAPI 草稿，放在 MoLE 組織的 web-drafts repository，目標是讓瀏覽器能在背景透明地完成 Endorsement 取得與 Credential 交換。
對於 AI 代理的場景，PACT 設計允許代理攜帶使用者的 Credential 執行任務，讓操作者（operator）對代理行為負責，而不需要替代理建立獨立身份。缺少合適 Endorsement 的新使用者可透過現有的 CAPTCHA 或帳號建立流程啟動信任鏈，逐步累積 Credential 分數。W3C 反詐欺社群組已於 2026 年 5 月舉辦工作坊，Cloudflare 與 Google Chrome 團隊均有參與。
影響範圍
PACT 目前仍處於提案早期，尚待解決的問題包括：完整的密碼學安全分析、動態速率調整的令牌撤銷問題，以及如何防止 Moderator 角色被少數大型平台壟斷。規格草稿標示為「早期版本，未經過正式審查」，目前提案不包含任何實作代碼，WebAPI 設計規格也在持續演進中。
Node.js 22.23.1 修補安全版本引入的 HTTP keep-alive 回歸問題
Node.js Blog · 2026-06-23
Node.js 團隊於 2026 年 6 月 23 日釋出 22.23.1（代號 Jod，LTS），這是一個緊急修補版本，專門修正五天前安全版本 22.23.0 引入的回歸問題。根本原因是 CVE-2026-48931 的修補方式在 HTTP keep-alive 場景下造成副作用，導致使用 node-fetch@2 的應用程式在正常的 socket 複用時丟出錯誤。本次釋出由 Rafael Gonzaga 主導，僅包含兩個 commit。
背景
22.23.0 是一個包含 11 個 CVE 修補的安全版本，其中 CVE-2026-48931（HTTP 回應佇列污染，HTTP Response Queue Poisoning）是核心修補之一。這個漏洞影響 http.Agent 的閒置 socket 管理——攻擊者或惡意伺服器可在 socket 閒置期間推送未被請求的 HTTP 回應，污染後續請求的回應佇列。安全版本的修補策略是在閒置 socket 上掛載公開的 'data' 事件監聽器，以攔截任何非預期的資料抵達。
然而，node-fetch@2 在處理回應關閉時，會主動檢查 socket.listenerCount('data')；一旦偵測到 data 監聽器存在就會判斷 stream 提前關閉，並拋出 ERR_STREAM_PREMATURE_CLOSE 錯誤，即便這次的 HTTP 交易本身完全正常。這個問題被追蹤為 Issue #63989。
核心改動
修復由 Matteo Collina 完成，收錄於 PR #64004，commit hash 為 eaa292549e。解法是改變閒置 socket 防護的實作方式：放棄掛載公開的 'data' 流事件監聽器，改為直接操作 socket handle 的內部 onread 鉤子。當 socket 在閒置池（free pool）中等待時，onread 指向一個專用的防護回呼；當 socket 被複用時，正常的 stream 讀取回呼則被完整還原。
這個設計的優點在於：防護邏輯對外部完全不可見，任何依賴 listenerCount 來偵測 socket 狀態的第三方套件都不受影響。安全防護的語意保持不變——閒置期間到達的非預期資料依然會被攔截並丟棄，CVE-2026-48931 的保護未被削弱。相同的修補也已 backport 至 v24.x LTS 分支，收錄於同日釋出的 v24.18.0。
影響範圍
本版本同時包含一個 build 相關 commit（41d2ee13be），將 Windows CI 的 coverage 任務從已過時的 windows-2019 環境切換至 windows-2022，屬於基礎設施維護。受影響的使用者主要是直接使用 node-fetch@2 搭配 HTTP keep-alive 的專案，或是間接依賴此行為的套件（如部分版本的 axios、got 封裝層）。
跨來源儲存 API 提案：讓瀏覽器跨網域共享 AI 模型快取
Hugging Face Blog · 2026-06-23
Hugging Face 工程團隊於 2026 年 6 月 23 日發表技術文章，說明他們在 Transformers.js 中實驗性地整合了 W3C WICG 的 Cross-Origin Storage（COS）API 提案。COS 的核心想法是以 SHA-256 雜湊值取代 URL 作為快取識別鍵，讓同一份大型 AI 模型或 WebAssembly 執行期能跨越不同網域共享，而非由每個來源各自重複下載。此提案由 Google Chrome 的 Thomas Steiner 等人主導，目前尚未有原生瀏覽器實作，但已有 Chrome 擴充套件 polyfill 可供測試。
背景
現代瀏覽器的快取機制以 origin（來源）加 URL 作為識別鍵。當相同的 AI 模型（例如 Xenova/whisper-tiny.en，約 177 MB）被部署在不同網域的應用程式中時，每個來源都必須各自下載並儲存一份完整副本，形成大量重複浪費。Flutter 的 canvaskit.wasm（5–6 MB）每天被不同來源請求超過 596,000 次；同一份 React 或 Vue 套件包也被無數網站分別快取。這個問題在本地端 AI 推論普及後愈發嚴重，因為模型動輒數 GB，冗餘下載的頻寬與儲存成本難以忽視。
核心改動
COS API 透過 navigator.crossOriginStorage.requestFileHandle(hash, options) 讓開發者以雜湊值讀取或寫入跨來源共享的檔案：
const hash = {
algorithm: 'SHA-256',
value: '8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4',
};
try {
const handle = await navigator.crossOriginStorage.requestFileHandle(hash);
const fileBlob = await handle.getFile();
} catch (err) {
// 快取未命中，回退至網路下載後以 create: true 寫入
}
寫入時瀏覽器會自動驗證資料的雜湊值是否相符，確保完整性；讀取時透過 origins 參數控制可見範圍——設為 '*' 表示全域可見，設為特定來源陣列則限制讀取方，省略則僅限同站。Transformers.js 啟用此功能的方式為 env.experimental_useCrossOriginStorage = true，函式庫會自動從 Xet-tracked 模型檔案中提取 SHA-256 雜湊值作為 COS 鍵值。
規格細節
提案文件訂定了多層隱私防護機制。可用性閘控（Availability Gating）：瀏覽器對非常見資源不會確認是否存在，防止攻擊者透過詢問特定雜湊值來探測使用者的瀏覽歷史；資源必須存在於一定數量的不同來源才被視為「公開常見」。GREASE 機制允許瀏覽器偶爾回傳假的 NotFoundError 以引入噪訊，但規格明文規定「不得對因假陰性而需重新下載代價過大的大型檔案套用 GREASE」，避免懲罰大型模型使用者。
可見性只能升級、不能降級的單向規則確保了供應鏈安全性：一旦某個資源被標示為全域可見，就無法縮回至更嚴格的存取範圍，防止惡意方在資源廣泛分發後再試圖限制存取。CSS 端也有對應的宣告式語法，可與 integrity() 搭配用於字體等資源：
src: url("font.woff2")
integrity("sha256-xyz...")
cross-origin-storage(*);
影響範圍
Chrome 狀態頁（chromestatus.com）已將 COS 列入考量，但尚無實作時程。目前可透過 Chrome Web Store 的擴充套件 polyfill 測試，也有實驗性的 Vite 外掛（vite-plugin-cross-origin-storage）。對於部署本地端 AI 推論的 Web 應用而言，COS 若正式落地，可大幅降低首次使用者的等待時間與頻寬消耗；提案文件以 0.013 kWh/GB（傳輸）與 0.081 kWh/GB（儲存）的基準估算，減少冗餘下載也直接減少碳排放。目前與 COS 同步實驗的函式庫除了 Transformers.js 外，還包括 WebLLM 與 wllama。