更新
2023 年 3 月 23 日：時程已更新，淘汰作業要到 Chrome 117 版才會發生。
2023 年 1 月 19 日：相關時程已更新，直到 Chrome 114 版才會淘汰。
2022 年 8 月 12 日：相關規定已更新，直到 Chrome 109 版才會淘汰。
2022 年 2 月 10 日：更新文章的私人網路存取權：加入預檢
2021 年 8 月 25 日：更新作業時間表公告和淘汰試用機制。
Chrome 已根據私人網路存取權規範，淘汰非安全網站對私人網路端點的存取權。我們的目標是保護使用者免受跨網站偽造 (CSRF) 攻擊的惡意攻擊，透過私人網路使用路由器和其他裝置。這些攻擊影響了數十萬名使用者，讓攻擊者將使用者重新導向至惡意伺服器。
Chrome 將導入以下變更：
- 從 Chrome 94 版開始，封鎖從不安全公開網站向私人網路發出的要求。
- Chrome 的淘汰試用方案簡介
- 如此一來，開發人員就能為所選來源申請延長期限，而這在淘汰試用期間不會受到影響。
- 推出 Chrome 政策，允許受管理的 Chrome 部署作業永久略過淘汰程序。適用於 Chrome 92。
如果您需要更多時間來緩解淘汰註冊作業對淘汰計畫的影響，
如果您具備使用者的管理控制權，可以透過 Chrome 政策重新啟用這項功能。
如要降低新限制的影響，請使用下列其中一種策略：
時間軸
- 2020 年 11 月：致電徵求意見回饋，瞭解即將推出的異動。
- 2021 年 3 月：在審查意見回饋並完成外聯後，公布即將實施的異動。規格已從 CORS-RFC1918 重新命名為私人網路存取權。
- 2021 年 4 月：Chrome 90 在穩定版推出時會顯示淘汰警告。
- 2021 年 6 月：Chrome 92 推出 Beta 版，可針對來自不安全的環境的私人網路要求出價。如果開發人員要求延長調整時間，淘汰後將延後到 Chrome 93 版，同時提供淘汰試用期。
- 2021 年 7 月：隨著開發人員進一步提供意見，淘汰機制和隨附的試用服務已延後至 Chrome 94 版。此外，私人網站也不會受到這項淘汰的影響。
- 2021 年 8 月：Chrome 94 推出 Beta 版。網頁開發人員可以開始註冊試用服務。
- 2021 年 9 月：Chrome 94 已於穩定版推出。網頁開發人員應已申請淘汰試用計畫，並將試用權杖部署至實際工作環境。
- 2022 年 12 月：已傳送來源試用問卷調查並收到意見回饋。淘汰試用期延長至 Chrome 113 版。
- 2023 年 3 月：淘汰試用期已延長至 Chrome 116 版，並在 Chrome 117 中設為結束。一項以權限為基礎的替代機制仍在開發階段，以 Chrome 114 的初始版本為目標。
- 2023 年 5 月 (暫定)：在 Chrome 114 中推出權限式機制。 網站可以使用這個 ID 結束淘汰試用計畫。
- 2023 年 9 月：Chrome 117 推出穩定版，即將結束淘汰試用期。 Chrome 會封鎖來自公開、不安全內容的所有私人網路要求。
什麼是私人網路存取權
私人網路存取權 (舊稱 CORS-RFC1918) 會限制網站向私人網路上的伺服器傳送要求。因為此選項只允許來自安全內容的要求。這項規格也會擴充跨源資源共享 (CORS) 通訊協定，因此網站現在必須先明確向私人網路上的伺服器要求授權，才能傳送任意要求。
「私人網路要求」是指目標伺服器的 IP 位址比擷取要求啟動器時更加私密的要求。例如，公開網站 (https://example.com) 向私人網站 (http://router.local) 發出的要求，或是從私人網站傳送至 localhost 的要求。
如需瞭解詳情，請參閱需要意見回饋：私人網路的 CORS (RFC1918)。
什麼是淘汰試用計畫
淘汰試用 (先前稱為反向來源試用) 是一種來源試用形式，用於簡化網路功能淘汰作業。淘汰試用計畫可讓 Chrome 淘汰特定網路功能，並禁止網站建立新的依附元件，同時讓目前的相依網站有更多時間完成遷移。
根據預設，所有網站都不會提供已淘汰的功能。假如開發人員仍需要使用受影響的功能，就必須註冊淘汰試用計畫並取得指定網路來源的權杖，然後修改網站，使其能夠透過 HTTP 標頭或中繼標記提供這些權杖 (在此情況下為例外狀況)。如果網站提供與來源相符的有效權杖，Chrome 會暫時允許使用已淘汰的功能。
詳情請參閱「開始使用 Chrome 的來源試用」和網頁開發人員指南，瞭解操作說明。
Chrome 異動內容
Chrome 94 版
從 Chrome 第 94 版起，公開的不安全的結構定義 (廣泛，非透過 HTTPS 或私人 IP 位址傳送的網站) 一律禁止向私人網路發出要求。這之前計劃用於 Chrome 92，因此淘汰訊息可能仍會提及先前的里程碑。
此外，在淘汰此版本的同時，也伴隨淘汰試用。網站開發人員可以利用已淘汰的功能，註冊權杖以繼續使用該功能，直到 Chrome 116 版為止。如要瞭解如何在網站上註冊及啟用試用功能，請參閱下文。
一組 Chrome 政策可用來無限期完全或特定來源停用淘汰項目。這麼做可讓受管理的 Chrome 安裝作業 (例如公司設定中的項目) 避免毀損。
Chrome 117
淘汰試用期間結束。所有網站均須從已淘汰的功能中遷移，或遷移使用者所設定的政策，才能繼續啟用這項功能。
建議的開發人員動作
受影響網站的第一步很有可能會購買時間，直到部署適當修正為止：註冊淘汰試用或使用政策。接著，建議採取的處理方式會因每個受影響網站的情況而異。
報名參加淘汰試用計畫
- 按一下「Register」(註冊) 來註冊來自非安全情境來源試用的私人網路存取權，取得參與來源的試用權杖。
- 將來源專用的
Origin-Trial: $token新增至回應標頭。只有在產生的文件使用已淘汰的功能時，才需要在主要資源和導覽回應上設定這個回應標頭。將這個標頭附加至子資源回應實在毫無用處 (但幾乎沒有問題)。
由於在文件發出任何要求之前，必須先啟用或停用試用功能，因此無法透過 <meta> 標記啟用試用。系統只會在子資源要求發出後，從回應主體剖析這類標記。這會對無法控制回應標頭的網站 (例如由第三方提供的 github.io 靜態網站) 構成難題。
詳情請參閱網頁開發人員指南：來源試用指南。
啟用政策
如果您能夠控管使用者的管理控制項，可以使用下列任一政策重新啟用已淘汰的功能：
如要進一步瞭解如何管理使用者政策，請參閱這篇說明中心文章。
存取 localhost
如果您的網站需要向 localhost 發出要求，則只需將網站升級為 HTTPS 即可。
指定 http://localhost (或 http://127.*.*.*、http://[::1]) 的要求不會遭到混合內容封鎖 (即使來自安全內容)。
請注意，WebKit 引擎和瀏覽器 (最主要是 Safari) 與此處的 W3C 混合內容規格不同，並禁止這些要求為混合內容。也未實作私人網路存取權，因此網站可能想要將使用這類瀏覽器的用戶端重新導向至網站的純文字 HTTP 版本，而這類瀏覽器還是能向 localhost 發出要求。
存取私人 IP 位址
如果您的網站需要透過私人 IP 位址向目標伺服器發出要求，則將發起人網站升級至 HTTPS 將無法運作。混合內容會防止安全環境透過純文字 HTTP 發出要求，因此新安全的網站仍會發現無法發出要求。以下幾種方法可以解決這個問題：
- 兩者都升級為 HTTPS。
- 使用 WebTransport，安全地連線至目標伺服器。
- 反向嵌入關係。
將兩端都升級為 HTTPS
這項解決方案需要控制使用者的 DNS 解析，例如內部網路環境中的情況，或者使用者是從您控管的 DHCP 伺服器取得名稱伺服器位址。您也必須擁有公開網域名稱。
透過 HTTPS 提供私人網站的主要問題在於，公開金鑰基礎架構憑證授權單位 (PKI CA) 只會為具有公開網域名稱的網站提供 TLS 憑證。解決方法：
- 註冊公開網域名稱 (例如
intranet.example)，並發布 DNS 記錄，將該網域名稱指向您選擇的公開伺服器。 - 為
intranet.example取得 TLS 憑證。 - 在私人網路內部，設定 DNS 以將
intranet.example解析為目標伺服器的私人 IP 位址。 - 將私人伺服器設為使用
intranet.example的傳輸層安全標準 (TLS) 憑證。這可讓您的使用者存取位於https://intranet.example的私人伺服器。
接著，您可以將發出要求的網站升級為 HTTPS，並像往常一樣繼續發出要求。
這項解決方案具有前瞻性，並降低您在網路中對機構的信任，進而擴大私人網路中的端對端加密使用。
WebTransport
這項解決方案不會讓您控制使用者的 DNS 解析。而是要求目標伺服器執行最少量的 WebTransport 伺服器 (經過修改的 HTTP/3 伺服器)。
您可以使用 WebTransport 及其憑證綁定機制，略過缺少由信任 CA 簽署的有效 TLS 憑證。這樣做可讓您與具有自行簽署憑證的私人裝置建立安全連線。WebTransport 連線允許雙向資料傳輸，但無法擷取要求。您可以將這個方法與 Service Worker 結合，從網頁應用程式的角度，以公開透明的方式透過連線 Proxy 處理 HTTP 要求。在伺服器端，對應的翻譯層可將 WebTransport 訊息轉換為 HTTP 要求。
我們瞭解這會佔比相當高的工作量，但應該比在 WebRTC 上建構的工作簡單許多；我們希望在針對可重複使用的程式庫中實作部分必要投資。我們也認為值得一提的是，由於平台逐漸鼓勵以更強大的方式鼓勵使用 HTTPS，不安全的環境可能會導致您無法再使用更多網路平台功能。無論私人網路存取權為何，這可能都是進行明智的投資。
我們預計透過 HTTP/3 的 WebTransport，預計會在 Chrome 96 中推出 (該程序已開始來源試用)，並可以防範金鑰共用和其他子標準安全性做法，包括：
- 綁定憑證的到期時間較短。
- 用於撤銷受到濫用特定金鑰的瀏覽器專用機制。
我們至少要等到 WebTransport 推出至少兩個里程碑後，才會提供安全環境限制。如有需要，您可以延長淘汰試用期的時間。
反向嵌入
這項解決方案不需要網路的任何管理控制權，且可在目標伺服器效能不足而無法執行 HTTPS 時使用。
您可以從私人伺服器提供應用程式的基本架構，然後從公開伺服器 (例如 CDN) 擷取其所有子資源 (例如指令碼或圖片)，而不是從公開網頁應用程式擷取私人子資源。接著，產生的網頁應用程式可以向私人伺服器發出要求，因為系統會將這類要求視為相同來源。它甚至可以透過私人 IP 向其他伺服器發出要求 (但不是 localhost)，但長期下來可能會改變。
若是僅在私人伺服器上代管架構，則可將新資源推送至公開伺服器，藉此更新網頁應用程式，就像更新公開網頁應用程式一樣。另一方面，產生的網頁應用程式並非安全的環境，因此無法存取網路中一些更強大的功能。
未來的規劃
將私人網路要求限制為安全內容，只是啟動私人網路存取權的第一步。Chrome 正致力在未來幾個月內導入其餘規格。敬請密切關注最新消息！
限制透過私人網站進行 localhost 存取
Chrome 94 中的異動只會影響存取私人 IP 位址的「公開」網站或 localhost。私人網路存取權規格也會將來自私人網站的要求分類至 localhost。Chrome 最終也會淘汰這些資訊。不過，由於許多私人網站沒有網域名稱，因此淘汰了試用權杖的挑戰也稍有不同。
CORS 預檢要求
私人網路存取權的第二部分，是使用 CORS 預檢要求對從安全內容發起的私人網路要求設下限制。如此一來，即使要求是從安全情境發出，系統還是會要求目標伺服器向啟動者提供明確授權。只有在授予成功的情況下，系統才會傳送要求。
簡單來說，CORS 預檢要求是 HTTP OPTIONS 要求，其中包含一些 Access-Control-Request-* 標頭，指出後續要求的性質。伺服器隨後可以藉由以 Access-Control-Allow-* 標頭回應 200 OK，決定是否授予精細存取權。
如要進一步瞭解相關資訊，請參閱規格。
限制導覽擷取
Chrome 即將淘汰並最終封鎖對私人網路發出的子資源要求。這不會影響到私人網路的瀏覽 (也可用於 CSRF 攻擊)。
私人網路存取權規格並未區分兩種擷取作業，而這些擷取作業最終仍適用相同的限制。
Unsplash 上由 Markus Spiske 提供的封面相片