Chrome 無痕模式安全瀏覽提案？程式碼顯示了什麼

Chrome 無痕模式安全瀏覽提案？一項 Chromium 程式碼變更曾提案在無痕與訪客模式中，透過預設為停用的功能旗標啟用雜湊前綴即時安全瀏覽查詢。然而，程式碼審查記錄 CL 8766497 目前已被標記為廢棄（Abandoned），因此這個修補程式本身並不代表已有活躍的推出計畫或發布日期。早期報導將此提案討論為可能的升級，但檢視該提交內容（Commit）可以發現，其中包含了關於 Chromium 如何在暫時性工作階段狀態與即時威脅遙測之間取得平衡的技術討論。對網頁與行動應用程式開發團隊而言，這場架構上的辯論提供了寶貴的見解，讓人們了解瀏覽器安全模型如何評估導航路徑，以及私密瀏覽環境如何處理外部連結路由。

安全提案：Chromium 程式碼實際顯示了什麼

概覽

一項提案中的 Chromium 程式碼變更探討了將雜湊前綴即時安全瀏覽查詢帶入無痕與訪客模式的可行性，相關功能旗標為 kHashPrefixRealTimeLookupsOnIncognitoAndGuest。
特定的程式碼審查項目 CL 8766497 在提交後不久即被標記為廢棄，這意味著它代表一項探索性實作，而非正式的部署時程表。
該提案解決了一個既有的技術挑戰：在不將私密工作階段期間取得的 OHTTP 金鑰更新寫入硬碟的情況下，縮短本機威脅清單與快速變化的惡意網域之間的延遲差距。

要理解瀏覽器安全架構，必須檢視實際的程式碼實作，而非臆測性的評論。在 2026 年 11 月上旬，科技媒體報導了開源 Chromium 審查儲存庫中的一項實驗性變更。該修改提案旨在探討是否可以在不損害工作階段隱私的前提下，於無痕和訪客視窗內啟用 Chrome 的即時安全瀏覽檢查。

對程式碼審查記錄的技術檢查顯示，該修補程式引入了一個專屬的組態旗標：kHashPrefixRealTimeLookupsOnIncognitoAndGuest。然而，審查日誌指出該變更已於 2026 年 11 月 9 日被標記為廢棄。雖然單一程式碼審查的廢棄並不代表 Google 已經放棄了強化私密瀏覽安全的更廣泛目標，但它確認了 CL 8766497 並非經過批准或排程的正式版本。

Google Chrome 無痕模式的免責聲明介面，詳細說明本機儲存空間界線

背後潛在的技術困境仍然極具關聯性。正如 Google 關鍵字部落格關於安全瀏覽即時防護的文件所述，當 Google 於 2024 年推出桌面版即時安全瀏覽時，平台數據突顯出一個現象：新註冊的惡意網域經常運作不到 10 分鐘，而本機儲存的威脅雜湊清單通常每 30 到 60 分鐘更新一次。在私密瀏覽模式中，如何在最新的威脅偵測與「關閉時必須捨棄工作階段資料」的嚴格要求之間取得平衡，仍是工程上的一大挑戰。

技術深入解析：OHTTP 金鑰範圍與非同步檢查

Chromium 修補程式中的架構討論集中在：當評估 Chrome 無痕模式安全瀏覽功能時，應該如何分割加密金鑰與網路查詢。

記憶體覆寫與防護層級

在標準瀏覽中，Chrome 安全瀏覽是透過使用者設定中組態的不同層級來運作：

標準防護：透過「不留痕跡 HTTP (Oblivious HTTP, OHTTP)」轉送伺服器執行雜湊前綴查詢，向查詢伺服器隱藏用戶端 IP 位址。然而，正如官方 Google Chrome 說明文件中所述，當偵測到可疑的網頁行為時，標準防護也可能會傳輸完整的網址與有限的網頁程式碼片段以進行更深入的分析。
增強防護：主動針對已知威脅評估即時網址、下載項目與系統遙測資料，同時識別先前未知的新興威脅。

這項被廢棄的 Chromium 提案探討了 OHTTP 通訊協定在私密個人資料（Profiles）中的運作方式。具體來說，該修補程式將無痕個人資料設計為在建立時從使用者的一般個人資料讀取快取的 OHTTP 公開金鑰，同時將任何新取得或輪替的金鑰導向至記憶體內的覆寫層。此結構確保了在私密工作階段期間取得的加密金鑰更新僅儲存於揮發性 RAM 中，並在關閉所有無痕視窗時清除，而不會寫入持續性磁碟儲存空間中。

[使用者在無痕模式中導航]
                  │
                  ▼
[頁面導航啟動] ───────────────────────┐
         │                                                               │
         ▼ (並行查詢)                                       ▼ (平行載入)
[遠端 / 本機安全瀏覽檢查]                               [資源擷取與算繪]
         │                                         │
         ├─────────────────────────────────────────┤
         ▼                                         ▼
(收到威脅判定結果？)                          (檢查進行中 / 安全)
         │                                         │
    ┌────┴────┐                                    ▼
    │         │                          [顯示目標頁面]
  (是)      (否)
    │         │
    ▼         ▼
[警告] [繼續]

註：非同步遠端檢查的簡化圖解；某些本機安全評估仍保持同步執行。

釐清查詢延遲與安全性中介畫面的關係

行銷與成長分析常將查詢效能與威脅判定混為一談。Google 關於在 Chrome 中優化安全瀏覽檢查的技術出版品解釋說，Chrome 支援可在網頁載入時執行的非同步遠端安全瀏覽檢查；部分本機檢查則維持同步執行。

單純的延遲飆升並不能將網站歸類為危險網站。安全瀏覽警告取決於適用防護機制的威脅判定；單純的雜湊前綴符合不應被視為最終的不安全判定。此外，一般個人資料中的持續性 Cookie 並不會降低安全瀏覽查詢的延遲，中介重新導向的每一個跳躍點也不會觸發獨立的同步雲端查詢。

對於評估外部行銷漏斗的工程團隊而言，實際的收穫是：避免不必要的重新導向層級、維持已驗證的網域聲譽，並將導航效能、安全警告與深度連結路由視為獨立且可觀察的指標。

Google Chrome 無痕模式新手上路通知，說明本機瀏覽資料刪除機制

跨隱私環境管理網頁到應用程式（Web-to-App）旅程

雖然安全瀏覽控管導航安全性，但私密瀏覽模式也引入了明確的工作階段界線。根據 Google Chrome 有關無痕模式的說明文件，Cookie 與網站資料在活躍的無痕工作階段期間會保留在暫時性儲存空間中，允許單一工作階段導航正常進行。一旦所有無痕視窗關閉且私密個人資料遭到銷毀，該暫時性狀態即會被刪除。

這種短暫的生命週期意味著標準瀏覽器 Cookie 無法作為連接至私密工作階段結束後才安裝的原生應用程式的橋樑。當開發團隊執行使用者造訪可能在無痕模式下進行的獲客活動時，必須圍繞著支援且符合隱私規範的機制來建構其路由與參數保留策略。

下表對比了管理跨管道情境連續性的標準方法：

方法	所需輸入	跨安裝能力	缺少參數時的備用方案
直接連結導航	網址參數與支援的應用程式路由	本身不提供跨安裝的延遲恢復功能	應用程式定義的預設或引導檢視
Google Play 安裝參考來源 (Install Referrer)	來自支援的 Play 商店安裝的可用參考來源資料	提供參考來源資料，供應用程式端透過 Play 用戶端進行解析與路由	應用程式定義的預設或引導檢視
支援的延遲連結（例如 OpoInstall）	擷取的行銷活動參數與支援的對應機制	可在支援的條件下恢復參數	應用程式定義的預設或引導檢視

在支援的獲客工作流程中，OpoInstall 提供了參數安裝與延遲深度連結功能，可協助應用程式在安裝後接收所擷取的行銷活動參數。可用性取決於瀏覽器、平台、整合方式與對應條件。這些功能不會改變安全瀏覽判定、無法保證免受安全警告影響，也無法保證能從每一個私密瀏覽工作階段中恢復資料。

當應用程式在初次啟動時收到還原的參數時，客戶端路由邏輯必須在顯示目標介面之前獨立驗證酬載。使用 Google Play 安裝參考來源說明文件或第三方連結框架的平台會向用戶端應用程式提供路由詮釋資料。然而，後端服務仍然負責驗證使用者帳戶、檢查資源存取權限以及確認交易資格。

測試矩陣：驗證導航連結與情境連續性

審查網頁到應用程式行銷連結的技術團隊可以圍繞著可驗證、受控制的測試環境來建構其品質保證。

受控導航與安裝測試

測試協定：在最近的 Chrome 建置版本中，於明確開啟的無痕與訪客個人資料中執行受控測試，記錄防護層級（標準與增強）、重新導航延遲以及最終著陸解析度。這些測試建立了目前的瀏覽器行為，並未驗證 CL 8766497 的部署。
網域聲譽稽核：透過 Google Search Console 的安全性問題報告檢查所有行銷活動網域與中介子網域，以主動識別合法的分類問題。
連結拓撲優化：將宣傳資產直接指向設定了已驗證 Android App Links 或 iOS Universal Links 的已驗證主要網域，藉此減少多跳躍追蹤鏈。

應用程式內場景還原驗證

Intent 處理：驗證應用程式路由元件是否能妥善處理遺失、格式錯誤或延遲的參數酬載，預設顯示一般分類檢視而非空白狀態。
路由與權限分離: 將深度連結參數視為螢幕導航的提示。確保帳戶餘額、促銷點數與使用者權限是嚴格透過已驗證的伺服器端點進行驗證。
備用機制檢測：實作客戶端記錄功能，記錄外部連結成功開啟應用程式的時間點，以及安裝流程退回預設首頁的時間點。

常見問題 (FAQ)

Chrome 無痕模式會讓網路瀏覽完全匿名嗎？

不會。無痕模式可防止 Chrome 在關閉所有私密視窗後儲存本機瀏覽記錄、Cookie 和表單資料。然而，造訪過的網站、身分識別提供者、管理企業網路的雇主以及網際網路服務供應商仍然可以觀察網路流量與目標端點，不過加密的 HTTPS 連線限制了對特定網址路徑與網頁酬載的能見度。

Chromium CL 8766497 提出了什麼內容，目前的狀態為何？

Chromium 程式碼審查 CL 8766497 提案透過使用記憶體內金鑰儲存模型，將雜湊前綴即時安全瀏覽查詢引入無痕與訪客個人資料中。該程式碼審查項目已於 2026 年 11 月 9 日被標記為廢棄，這意味著它代表一項探索性實作，而非已獲批准的發布版本。

使用深度連結 SDK 是否能防止網站觸發安全瀏覽警告？

不會。安全瀏覽是根據自動化惡意軟體、網路釣魚和社交工程威脅情資來評估網站安全性。深度連結與參數傳遞 SDK 是在應用程式路由層運作，對 Google 的安全性分類或瀏覽器中介畫面警告沒有任何影響。

工程團隊的關鍵要點

圍繞著私密瀏覽安全的架構辯論說明瞭在平衡客戶端隱私與即時威脅情資時所面臨的持續挑戰。雖然像 CL 8766497 這樣的實驗性實作證明瞭瀏覽器工程師正在探索在不損害本機資料隔離的情況下更新安全檢查的方法，但開發團隊必須建構尊重平台隱私界線的系統。

為了確保具備韌性的使用者旅程，工程組織應專注於乾淨的網域架構、強健的 Android App Links 以及透明的狀態管理。團隊不應依賴脆弱的重新導向鏈或假設瀏覽器 Cookie 會持續存在，而應部署經過驗證的第一方路由連結，並在支援的情況下搭配伺服器端參數還原。維持嚴格的安全衛生並建構優雅的備用機制，有助於隨著平台安全模型的演進而提升系統韌性。