重新構想 uMatrix：將細粒度請求控制帶入 Manifest V3

對於進階使用者與隱私愛好者而言，已棄用的 uMatrix 擴充功能不僅僅是一個工具；它是瀏覽器的指揮中心。由 Raymond Hill（uBlock Origin 的開發者）打造，uMatrix 提供直覺的矩陣式介面，讓使用者能控制網站權限與子資源請求。它讓使用者能精確限制第三方可以提供的內容——腳本、框架、字型與影片——將繁瑣的手動流程轉變為可管理的工作流程。

雖然 uBlock Origin（uBO）已吸收許多這些功能，但向 Chrome 的 Manifest V3（MV3）過渡卻留下了缺口。符合 MV3 的繼任者 uBO Lite 缺少使 uMatrix 成為不可或缺的細粒度控制功能。這促使 Tavis Ormandy 探索在新擴充架構限制下，是否仍有可能實現類似 uMatrix 的體驗。

技術挑戰：MV2 與 MV3

在複製 uMatrix 時的主要障礙是從 Manifest V2 轉向 Manifest V3。在 MV2 中，擴充功能可以使用「阻擋」的網路請求，執行 JavaScript 回呼即時決定是否允許或阻擋請求。

MV3 移除了此能力。相反地，擴充功能必須使用 declarativeNetRequest API。這意味著擴充功能無法對每一個請求執行邏輯；必須事先宣告一組規則，由瀏覽器執行。雖然批評者認為這「削弱」了廣告阻擋與隱私工具的功能，Ormandy 認為對於 uMatrix 替代方案的特定使用情境，這些規則仍足夠彈性且實用。

matrix³ 的提案架構

為了恢復 uMatrix 的細粒度控制，Ormandy 提出一個利用現有 Web 標準而非對抗瀏覽器新限制的設計。策略包含兩個主要元件：

1. 利用內容安全政策（Content Security Policy，CSP）

與其嘗試透過 declarativeNetRequest 規則管理每一個請求，提案的解決方案是使用 API 注入自訂的 Content-Security-Policy（CSP）標頭。CSP 是瀏覽器原生機制，用於控制哪些資源可以被載入以及從何處載入。透過將實際阻擋工作交給瀏覽器的 CSP 引擎，擴充功能只需成為這些政策的管理介面。

2. 透過 report-to 自動化偵測

uMatrix 最佳的功能之一是能即時向使用者顯示網站嘗試載入的子資源，讓使用者當場批准或拒絕。為了在 MV3 中重現此功能，Ormandy 建議使用 CSP 中的 report-to 指令。

當發生 CSP 違規時，瀏覽器可以被指示將報告發送至特定端點。透過 declarativeNetRequest 攔截這些報告，擴充功能即可即時填充被阻擋資源的清單。這形成一個回饋迴路：瀏覽器阻擋請求、報告違規，擴充功能將違規資訊呈現給使用者，以便新增「允許」規則。

目前狀態：matrix³

這個概念框架已產出一個名為 matrix³ 的概念驗證。雖然目前仍處於原型階段且使用者體驗極為簡陋，但它證明了在 Manifest V3 下「阻擋 → 報告 → 使用者決策 → 允許」的核心迴路是可行的。

社群觀點與替代方案

圍繞此專案的討論凸顯了瀏覽器生態系統中更深層的緊張關係。許多使用者認為，這類變通方案的需求直接源自 Google 推動 MV3，以限制廣告阻擋工具的效能。

替代路徑

多位社群成員指出了對功能不願妥協者的替代方案：

• Firefox： 由於 Firefox 並未採用與 Chrome 相同的 MV3 限制，uBlock Origin 在該平台仍能完整運作。另有成員建議使用 nuMatrix 作為 Firefox 使用者的現代替代方案。
• Brave： 有使用者指出 Brave 已明確宣佈支援類似 uMatrix 的功能。
• Chrome Flags： 對於堅持使用 Chrome 的使用者，有人建議使用指令列旗標（例如 --disable-features=ExtensionManifestV2Unsupported）暫時保留 MV2 擴充功能，儘管此方案相當脆弱。

「使用者代理」哲學

除了技術實作外，討論亦觸及瀏覽器作為「使用者代理」的哲學。批評者認為，現代瀏覽器缺乏原生、細粒度的請求控制是一種系統性失敗。正如一位評論者所說：

"像 uMatrix 這樣的工具應該直接內建於瀏覽器…它是唯一絕對必需的擴充功能…能在點擊按鈕的瞬間看到大多數網站想載入的垃圾，真的讓人大開眼界。"

將這些控制移至擴充功能，且再透過 MV3 限制這些擴充功能，等於讓瀏覽器不再是使用者的代理人，而是成為網路廣告生態系的守門人。