第三方

什麼是第三方？

依此很少見，網站完全是獨立的內容。HTTP Web Almanac 顯示，大部分網站 (約 95%) 都含有一些第三方內容。

Almanac 將第三方內容定義為透過共用和公開來源代管的內容，讓許多網站廣泛使用，而個別網站擁有者也沒有影響。可以是圖片或其他媒體 (例如影片、字型或指令碼)。圖片和指令碼帶來的價值不止於所有元素。第三方內容對開發網站而言並非必要，但也可能是，您幾乎肯定會使用從公開共用伺服器載入的項目，無論是網頁字型、影片內嵌的 iframe 或 JavaScript 程式庫都沒問題。例如，您可能有使用 Google Fonts 提供的網頁字型，或使用 Google Analytics (分析) 評估數據分析；您可能新增了來自社群網路的「讚」按鈕或「登入」按鈕；您可能會將地圖或影片嵌入地圖或影片，或是透過第三方服務處理購物交易；您可以透過第三方監控工具追蹤錯誤並記錄自身開發團隊。

基於隱私權考量，建議您考慮採用稍微不同的定義：第三方資源 (尤其是第三方指令碼) 是由共用和公開來源提供，且廣泛用於示意圖，但並非網站擁有者。決定如何保護使用者隱私時，第三方權威性的重要性。這樣您就會思考目前存在的風險，然後依據這些風險判斷是否要使用第三方資源。如先前所述，這些內容可協助您瞭解情境，進而瞭解需要做出哪些取捨，以及要做出哪些取捨。

這並不是在談論「第三方資源」時的情況，畢竟第一方與第三方之間的差異，其實與使用的情境有關。從其他網站載入的指令碼是第三方資源，載入指令碼的 HTTP 要求可能包含 Cookie，但這些 Cookie 實際上並不是「第三方 Cookie」；這些 Cookie 只是 Cookie，所代表的是「第三方」或「第一方」，取決於指令碼是在網站或指令碼擁有者網站上的網頁載入。

我們為什麼使用第三方資源？

第三方是為網站增添功能的絕佳方法。這類功能可能會向使用者顯示或看不到的開發人員功能 (例如錯誤追蹤)，但會減少開發負載，指令碼本身則是由他人維護：您所納入服務的開發團隊。這一切都歸功於網路的可組合性：能夠將部分組合成一個大於其總值的整體成果。

HTTP 封存的 Web Almanac 提供了很好的說明：

第三方提供一系列不斷更新的圖片、影片、字型、工具、程式庫、小工具、追蹤程式、廣告，以及任何可嵌入網頁中的元素。就算不是技術人員，也能建立內容並發布到網路上。如果沒有第三方，網路可能就是非常無聊的文書式學術媒介 而不是豐富、複雜、沉浸式的平台，而這對現今許多人來說也是不可或缺的一環。

第三方資源有哪些功能？

存取部分資訊

當你在網站上使用第三方資源時，無論內容為何，系統會將部分資訊傳送給該第三方。 舉例來說，如果您加入其他網站的圖片，使用者瀏覽器發出的 HTTP 要求就會一併傳送參照網址標頭和您的網頁的網址，以及使用者的 IP 位址。

跨網站追蹤

延續相同的範例，從第三方網站載入圖片時，圖片可能會包含 Cookie，而當使用者下次要求該圖片時，系統就會將該 Cookie 傳回第三方。這表示第三方可知道他們的服務正在在您的網站上運作，且可以傳回含有該使用者專屬 ID 的 Cookie。這表示使用者下次造訪您的網站或任何其他含有第三方資源的網站時，系統就會再次傳送這個專屬 ID Cookie。如此一來，第三方就能建立使用者造訪的紀錄，例如您的網站、使用相同第三方資源的其他網站，甚至是整個網路上。

這是「跨網站追蹤」：允許第三方收集使用者在許多網站上的活動記錄，前提是這些網站全部使用來自同一個第三方的資源。這可以是字型、圖片或樣式表，全都是靜態資源。容器也可能是動態資源 像是指令碼、社群媒體按鈕或廣告隨附的指令碼可能會收集更多資訊，因為這個指令碼屬於動態性質，可以檢查使用者的瀏覽器和環境，並將資料傳回給原始程式。任何指令碼都能在一定程度上實現這個做法，像是不屬於指令碼的動態資源，例如社群媒體嵌入項目、廣告或分享按鈕。當您查看熱門網站上的 Cookie 橫幅詳細資料時，可以看到一些機構清單，這些組織可能會將使用者加入追蹤 Cookie，以便建立該使用者的活動相片。可能有數百個。如果第三方提供免費服務，要能做到經濟實惠的其中一種方法，就是讓他們收集這些資料並據此營利。

目標隱私權威脅模型提供了實用指南，協助您瞭解瀏覽器應用於保護使用者的隱私權問題類型。本文件仍在討論中，但仍針對存在的隱私權威脅進行一些高階分類。第三方資源帶來的風險主要是「不必要的跨網站辨識」，也就是讓網站在多個網站上識別同一位使用者；而「機密資訊外洩」則可讓網站收集使用者認為敏感資訊。

這是「關鍵差異」：不需要的跨網站辨識功能會讓使用者掌控自己的身分，因此即使第三方未從該網站收集額外的機密資訊，也算是不良。取得使用者參照網址、IP 位址和 Cookie 的存取權，並不是個人不善的揭露方式。使用第三方資源搭配規劃元件，說明您要如何在保護隱私權的情況下使用這些資源。其中有些工作是您以網站開發人員的身分委託進行，有些則由瀏覽器以使用者代理程式作為使用者代理程式執行；也就是說，代理程式會代表使用者工作，盡力避免機密資訊外洩，以及不必要的跨網站辨識。以下將進一步說明瀏覽器層級和網站開發層級的緩解措施和解決方法。

伺服器端第三方程式碼

我們先前定義了第三方會刻意修改 HTTP Almanac 而非用戶端的措施 (依其報告適用)，因此將第三方原創性納入其中，因為從隱私權的角度來看，第三方對於任何一方並不熟悉您的使用者。

包括在伺服器上提供服務的第三方，以及用戶端。從隱私權的角度來看，第三方程式庫 (例如 NPM、Composer 或 NuGet 中的程式庫) 也很重要。您的依附元件是否將資料傳送在邊界外？若您將資料傳送至記錄服務或遠端託管的資料庫，如果您同時為其作者加入「電話首頁」，這些程式庫可能有侵犯使用者隱私的問題，因此必須接受稽核。以伺服器為基礎的第三方通常必須由您提供使用者資料，也就是說，第三方資料會由您掌控。相較之下，用戶端第三方 (在網站上包含指令碼或 HTTP 資源，並由使用者的瀏覽器擷取) 可以直接向使用者收集部分資料，而不必針對收集作業提供中介服務。本單元大部分都著重在如何找出您選擇納入及向使用者公開的用戶端第三方，因為您幾乎能採用的中介服務就不多。但值得一提的是，請務必保護伺服器端程式碼，以便瞭解傳出通訊內容，並能記錄或封鎖任何非預期的資料。詳細做法不在我們的範圍內 (並取決於伺服器設定)，但這是資安和隱私權領域的另一個要務。

為什麼需要謹慎與第三方合作？

第三方指令碼和功能相當重要，我們的目標就是網頁程式開發人員要整合這類功能，而非阻力！不過，這仍有潛在問題。如果第三方內容將導入外部服務，可能會產生效能問題，也可能產生安全性問題。但第三方內容也會造成隱私權問題！

討論網路上的第三方資源時，建議您思考一下安全性問題 (以及其他事情)，那就是第三方可以竊取貴公司的資料，以及與隱私權問題 (還有其他問題) 相反，您納入的第三方會在未經您 (或使用者) 同意的情況下竊取或取得您使用者資料的存取權。

舉例來說，「網路滑雪客」會竊取信用卡資訊，而第三方資源包含在使用者輸入信用卡詳細資料的網頁中，這可能就是竊取信用卡資料，並傳送給惡意的第三方。建立這些重點瀏覽腳本的人會發揮創意，規劃要隱藏的版面。 一份摘要說明精簡指令碼在第三方內容中隱藏的方式，像是用於網站標誌、網站小圖示和社群媒體網路的圖片、jQuery、Modernizr 和 Google 代碼管理工具等熱門程式庫，以及即時通訊視窗等網站小工具，以及 CSS 檔案。

隱私權問題稍有不同。這些第三方服務供應商屬於您的產品或服務，為了維持使用者對您的信任，您必須確信使用者能信任「他們」。如果您使用的第三方會收集使用者的資料後，濫用該資料，或難以刪除/發現資料、違反使用者的期望，或是違反使用者的預期，使用者可能會誤以為自己對「您的」服務信任，而不只是第三方。而是你的聲譽和線上形象。因此請務必自問 您是否信任自家網站上使用的第三方？

有哪些第三方範例？

我們通常會討論「第三方」，但實際上種類不同，而且可存取的使用者資料並不相同。 舉例來說，在 HTML 中加入從其他伺服器載入的 <img> 元素，就能為該伺服器為使用者提供與新增 <iframe> 或 <script> 元素不同的使用者資訊。上述範例並未提供完整清單，但如果瞭解網站可使用的各種第三方商品間的差異，將有助於你瞭解應有的差別。

要求跨網站資源

跨網站資源是指你網站上從其他網站載入的任何資源，而且不是 <iframe> 或 <script>。範例包括 <img>、<audio>、<video>、CSS 載入的網路字型，以及 WebGL 紋理。這些項目都是透過 HTTP 要求載入，如先前所述，這些 HTTP 要求會包含其他網站先前設定的任何 Cookie、提出要求的使用者的 IP 位址，以及目前網頁的網址做為參照網址。預設情況下，所有第三方要求都會包含這類資料，不過目前設法減少或隔離透過各種瀏覽器傳送至第三方的資料，詳情請參閱「瞭解第三方瀏覽器防護」一文。

嵌入跨網站 iframe

透過 <iframe> 嵌入網頁的完整文件，除了 Cookie、IP 位址和參照網址之外，還可以要求其他存取瀏覽器 API。具體而言，哪些 API 可供 <iframe> 頁面使用，以及這些 API 要求存取權的方式僅適用於瀏覽器，且目前仍有異動。如要瞭解目前如何遏止或監控嵌入式文件中的 API 存取權，請參閱下方的「權限政策」。

執行跨網站 JavaScript

加入 <script> 元素後，系統會在網頁的頂層內容載入並執行跨網站 JavaScript。這表示執行的指令碼具有完整的第一方指令碼功能的完整存取權。瀏覽器權限仍會管理這類資料，因此要求使用者的位置 (例如) 仍須取得使用者同意。不過，網頁中呈現或以 JavaScript 變數形式提供的任何資訊，都能透過這類指令碼讀取。同樣地，載入您網頁的第三方指令碼也可提出與您自有程式碼相同的所有 HTTP 要求，也就是說，該指令碼可以向您的後端 API 提出 fetch() 要求來取得資料。

在依附元件中加入第三方程式庫

如前文所述，您的伺服器端程式碼也可能包含第三方依附元件，而且無法與自有程式碼一同區分。從 GitHub 存放區或程式設計語言程式庫 (npm、PyPI、Composer 等) 加入的程式碼，可以讀取其他程式碼可以讀取的所有資料。

瞭解第三方

接著，您需要對第三方供應商名單有所瞭解，以及這些供應商的隱私權、資料收集和使用者體驗原則和政策。這種理解將成為您一系列取捨的部分權衡：服務實用性和重要性，以及在使用者對於使用者需求造成的干擾、不流暢或緩解狀況之間取得平衡。第三方內容能讓您身為網站擁有者的繁瑣工作，為您創造價值，因此您可以專注於自己的核心能力，從而權衡利弊、犧牲使用者舒適度和隱私來創造更佳的使用者體驗。請務必避免使用者對開發人員體驗感到混淆，但「我們的開發團隊建構服務較容易」對使用者來說並不具有吸引力。

從瞭解到這一點就是稽核過程。

稽核第三方

瞭解第三方是指進行稽核的程序。您可以在技術上和非技術層面執行這項作業，也能針對個別第三方和整個集合執行這項作業。

執行非技術稽核

第一步非技術性：請參閱供應商的隱私權政策。如果納入任何第三方資源，請參閱隱私權政策。這些文件將篇幅較長且完整的法律文本，部分文件可能會使用某些方法特別針對「先前模組」發出的警告，例如過於籠統的聲明，而且在無告知移除資料的方式或時機。請務必瞭解，從使用者的角度來看，在您網站上收集的所有資料 (包括第三方) 都會受到這些隱私權政策的規範。即使您已正確做到一切，如果能對目標開誠佈公，並且超過使用者對資料隱私權和敏感性的期望，使用者可能也需要為選擇的第三方所做的任何事情負責。如果您不想在自己的政策中公開政策內容，以免降低使用者的信任，請考慮是否有其他供應商。

正如我們進一步探討技術稽核，就能派上用場。您應該瞭解因為業務關係而納入的第三方資源 (例如廣告聯播網或嵌入內容)，因為現有業務關係存在。如果您想啟動非技術性稽核，這裡就很適合。此外，技術稽核也可以找出第三方，尤其是用於技術而非業務原因的第三方 (外部元件、數據分析、公用程式庫)，且該清單可與以業務為主的第三方清單彙整在一起。這樣一來，身為網站擁有者的您，必須使網站擁有者清楚瞭解網站中含有哪些第三方服務，以及身為企業的您向此第三方廣告空間發表法律顧問，以確保自己履行所有必要的義務。

執行技術稽核

如果是技術稽核，請務必使用網站上的資源；也就是說，不要在測試控管中載入依附元件，並且進行檢查。請務必將依附元件當做實際網站的一部分，並部署在公開網際網路，而非測試或開發模式下。您必須以新使用者的身分 瀏覽自己的網站使用簡潔的新設定檔開啟瀏覽器，確認尚未登入且未儲存任何協議，然後試著造訪網站。

如果您提供了使用者帳戶，請在您的網站上申請新帳戶。您的設計團隊將從使用者體驗的角度來規劃這項新使用者開發程序，但從隱私權的角度來看，這種做法可以當成說明。請勿直接點選條款及細則、Cookie 警告或隱私權政策上的「接受」；您可以自行設定服務使用目的，但不得揭露任何個人資訊或使用任何追蹤 Cookie，看看是否可執行這項操作，以及處理的困難度。此外，您也可以查看瀏覽器開發人員工具，瞭解使用者存取哪些網站，以及哪些資料會傳送到這些網站。開發人員工具會提供個別 HTTP 要求的清單 (通常在「網路」專區中)，而您可以在此看到依類型 (HTML、CSS、圖片、字型、JavaScript、由 JavaScript 發起的要求) 分組的要求。您也可以新增資料欄，顯示每個要求的網域，以顯示聯繫過的不同地點。如果勾選了「第三方要求」核取方塊，則只能顯示第三方。(使用 Content-Security-Policy 報表持續執行持續稽核也有幫助，希望您深入瞭解)。

此外，Simon Hearne 的「Request Map Generator」(要求地圖產生器) 工具也能協助您瞭解可公開存取頁面的所有子要求總覽。

在這個階段，您可以將重點業務第三方認定為非技術稽核的一部分 (也就是您與貴公司有財務關係的公司清單，才能使用他們的資源)。確認程式碼的用途是比對您認為使用的第三方 (財務和法律記錄中的第三方) 清單，以及實際使用的清單 (查看網站發出的第三方 HTTP 要求)。您應能找出發出技術傳出要求的每個業務第三方。如果您在技術稽核中找到透過業務關係識別的第三方要求，請務必找出原因並引導您進行測試：第三方資源可能只會在特定國家/地區載入，或是只在特定裝置類型載入，或是針對已登入的使用者載入。如此即可放大您的網站區域清單，以利稽核並確保您檢視所有的傳出存取作業。(或者，它或許能識別您要付費使用的第三方資源，而該資源總是能為財務部門帶來助益)。

縮小要納入稽核作業的第三方要求清單後，點選個別要求即可查看所有詳細資料，尤其是傳送到該要求的資料。如果程式碼啟動的第三方要求接著發出許多其他第三方要求，也很常見。此外，這些額外的第三方也會「匯入」到您的隱私權政策。這項工作十分重要，但通常可以插入現有分析中；您的前端開發團隊應該已經是基於效能考量 (也許是 WebPageTest 或 Lighthouse 等現有工具) 稽核要求，並且將資料和隱私權稽核整合至該程序有助於簡化作業。

web.dev 要求對應。
(大幅簡化) web.dev 要求對應，顯示要求其他第三方網站的第三方網站等。

正確做法

以全新的使用者設定檔開啟瀏覽器，代表您未登入且未儲存協議；接著開啟瀏覽器開發人員工具「Network」面板，查看所有傳出要求。新增資料欄以顯示每個要求的網域，然後勾選「第三方要求」核取方塊 (如果有的話)，只顯示第三方。接著：

  • 造訪你的網站。
  • 如果您提供了使用者帳戶，請註冊新的帳戶。
  • 嘗試刪除已建立的帳戶。
  • 在網站上執行一兩則正常操作 (確切來說取決於網站的用途，但挑選大多數使用者最常執行的常見動作)。
  • 執行您確定涉及第三方依附元件的動作。包括分享內容至社群媒體、啟動結帳流程或嵌入其他網站的內容。

執行每項工作時，請查看網路面板，記錄非您網域所要求的資源。這些是您的部分第三方。要達到這個目的，最好使用瀏覽器網路工具，擷取 HAR 檔案中的網路要求記錄。

HAR 檔案與擷取

HAR 檔案是指網頁發出的所有網路要求的標準化 JSON 格式。 如要取得特定網頁的 HAR 檔案，請在下列位置使用：

Chrome

開啟瀏覽器開發人員工具 (依序選取「選單」>「更多工具」>「開發人員工具」)，前往「網路」面板，然後載入 (或重新整理) 頁面，接著在右上方「不節流」下拉式選單附近選擇向下箭頭儲存符號。

Chrome 開發人員工具網路面板，醒目顯示「下載 HAR」符號。
Firefox

開啟瀏覽器開發人員工具 (依序選取「選單」>「更多工具」>「網頁開發人員工具」)，前往「網路」面板，然後載入 (或重新整理) 頁面，然後在右上角的「限速」下拉式選單旁選擇齒輪符號。從選單中選擇「全部儲存為 HAR」**。

Firefox 開發人員工具「Network」面板，其中醒目顯示「Save All As Har」選項。
Safari

開啟瀏覽器開發人員工具 (依序選取「選單」>「開發」>「顯示網頁檢查器」；如果您沒有「開發」選單，請在選單列中依序點選「選單」>「Safari」>「偏好設定」>「進階」>「顯示開發選單」)，然後前往「網路」面板、載入 (或重新整理) 頁面，然後選擇畫面右上方的「匯出」 (可能必須向右放大)。

醒目顯示「HAR 匯出」選項的 Safari Web Inspector「Network」面板。

如需更多詳細資料，您也可以記錄要傳遞給第三方的內容 (在「要求」部分中)，雖然這項資料通常經過模糊處理，因此不具實質意義。

整合第三方的最佳做法

您可以針對您的網站使用的第三方設定專屬的政策：依據做法變更您使用的廣告供應商、使用者對於 Cookie 同意聲明彈出式視窗的干擾程度或乾擾程度。或者，您是否要在 Twitter 中使用社群媒體按鈕，或是在電子郵件或 utm_campaign 連結中使用 utm_campaign 連結來追蹤 Twitter 訊息中。開發網站時要考慮的其中一個面向是分析服務的隱私與安全防護機制。部分數據分析服務明確著重於保護隱私權。第三方指令碼經常也可採取一些方法，本身已增添隱私保護：您不是第一個想改善使用者隱私，且不讓第三方資料收集者的團隊，目前可能已有解決方案。最後，比起過去，許多第三方供應商對資料收集問題更敏感，因此通常可以新增功能或參數來啟用使用者防護模式。以下是幾個範例。

新增社群媒體分享按鈕時

建議您直接嵌入 HTML 按鈕：https://sharingbuttons.io/ 網站會提供一些設計完善的範例。 您也可以新增純 HTML 連結。這麼做的缺點在於，您失去「分享次數」統計資料，也無法在 Facebook 數據分析中將客戶分類。舉例來說，與第三方供應商相比，第三方服務供應商接收到的數據分析資料較少，需要權衡利弊。

一般來說，當您嵌入第三方提供的互動式小工具時，通常可以改為提供該第三方的連結。這表示您的網站沒有內嵌體驗，但會改變您與第三方分享資料的決定權，由您的使用者自行選擇與對方互動。

舉例來說，您可以新增 Twitter 和 Facebook 的連結，藉此在 mysite.example.com 上分享您的服務，如下所示：

<a href="https://facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Facebook" target="_blank" >Share on Facebook</a>
<a href="https://twitter.com/intent/tweet/?text=My%20cool%20service!&amp;url=https%3A%2F%2Fmysite.example.com"
   rel="noopener" aria-label="Share on Twitter" target="_blank">Share on Twitter</a>

請注意，Facebook 可讓您指定要分享的網址，Twitter 則允許指定網址和部分文字。

嵌入影片時

嵌入影片代管網站的影片時，請在嵌入程式碼中尋找隱私權保護選項。 舉例來說，如果是 YouTube，請將嵌入網址中的 youtube.com 替換為 www.youtube-nocookie.com，避免追蹤嵌入頁面的使用者所套用的 Cookie。從 YouTube 本身產生分享/嵌入連結時，也可以勾選「啟用隱私加強保護模式」。這個例子充分說明如何使用第三方提供的加強保護模式。(https://support.google.com/youtube/answer/171780 以及 YouTube 專用的其他嵌入選項，會有更多詳細說明)。

其他影片網站的相關選項較少，舉例來說，在編寫本文時，TikTok 無法在未追蹤的情況下嵌入影片。您可以自行代管影片 (使用替代方法)，但可能需執行大量工作，尤其是支援多種裝置。

如同先前討論的互動式小工具，創作者通常能將內嵌影片替換成提供網站的連結。 這種互動方式比較少，因為影片不會以內嵌方式播放，但會讓使用者自行決定是否觀看影片。這可做為「門面模式」的範例，用於動態將互動式內容替換為需要使用者操作才能觸發的元件的名稱。您可以將內嵌的 TikTok 影片替換為 TikTok 影片頁面的純連結，但只要再多投入一些工作，就能擷取和顯示影片縮圖，並建立相關連結。即使所選影片供應商不支援在沒有追蹤功能的情況下嵌入影片，許多影片主機都支援 oEmbed。這個 API 會在取得影片或嵌入內容的連結時傳回以程式輔助方式產生的詳細資料，包括縮圖和標題。TikTok 支援 oEmbed (詳情請參閱 https://developers.tiktok.com/doc/embed-videos)，意即您可以使用 https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173 將 TikTok 影片 https://www.tiktok.com/@scout2015/video/6718335390845095173 的連結轉換為該影片的 JSON 中繼資料，進而擷取要顯示的縮圖。舉例來說，WordPress 通常會使用這個函式要求嵌入內容的 oEmbed 資訊。您可以使用此程式輔助方式，顯示互動性的「門面」；使用者選擇點按互動式影片時，即可切換嵌入或連往互動式影片。

嵌入數據分析指令碼時

Analytics (分析) 旨在收集使用者的相關資訊，以便進行分析，這就是所謂的用途。基本上，分析系統是用來收集和顯示存取和使用者相關資料的服務，這些作業是在 Google Analytics (分析) 等第三方伺服器上執行，以便簡化導入作業。有些自行託管的分析系統 (例如 https://matomo.org/) 其實比使用第三方解決方案還要費心。不過，在自有基礎架構上執行這樣的系統，有助於減少資料收集作業，因為該系統不會離開您自己的生態系統。另一方面，管理、移除資料及設定資料政策則由您負責。使用者之所以擔心跨網站追蹤，大多是因為資料安全且隱密，或是因為使用完全不需要收集資料的服務而產生副作用。分析軟體的設計也過於嚴格，目的是收集資料，讓網站擁有者瞭解使用者的相關資訊。

以往，其實有個方法可以收集你所有的各種資料 (例如巨魚網)，然後再分析出有趣的模式。基本上，這種思維產生了令人不舒服的感覺，並對資料收集在第 1 部分討論感到不滿。現在，許多網站會先釐清想提出的問題，然後收集有限的具體資料來回答這些問題。

如果您的網站和其他網站都使用某些第三方服務，而且該服務會將這些網站的 JavaScript 加到您的網站，並且為每個使用者設定 Cookie，那麼您必須考量那些第三方服務可能會進行不必要的跨網站辨識，也就是追蹤您跨網站的使用者。雖然有部分可能/不一定，但是在保護隱私權的原則中，我們會假設這類第三方服務確實會執行跨網站追蹤，除非您有充分理由思考或瞭解其他情況。這本身並不是避免這類服務的原因，而是在評估使用這些服務的優缺點時，需要考慮的是。

在數據分析中，有利於選擇是否使用數據分析，因此過去只能選擇是否使用資料：收集所有資料並侵害隱私權，以便取得深入分析和規劃資料，或是完全放棄深入分析結果。但現在已非如此，且在這兩種極端關係之間通常都有中間地位。請查看分析服務供應商，瞭解有哪些設定選項能限制收集的資料，並減少儲存的資料量和時間長度。由於您已擁有先前所述的技術稽核記錄，因此您可以重新執行稽核的相關部分，確認變更這些設定確實能減少收集的資料量。如果在現有的網站上進行轉換，這麼做可以獲得一些可量化的測量結果，以供使用者查看。舉例來說，Google Analytics (分析) 提供多項啟用 (因此預設為停用) 隱私權功能，其中許多功能可能有助於您遵守當地資料保護法規。設定 Google Analytics (分析) 時，可以考慮採取的做法包括：將收集的資料保留期限設為低於預設值 26 個月 ([管理] > [追蹤資訊] > [資料保留])，以及啟用部分 IP 去識別化等技術性解決方案 (詳情請參閱 https://support.google.com/analytics/answer/9019185)。

以保護隱私權的方式使用第三方

到目前為止，我們討論了在應用程式設計階段，如何避免使用者不受第三方影響，同時在您規劃應用程式用途。這項計畫包括決定完全不使用特定第三方，而稽核使用行為也屬於這個類別：關於隱私權立場的決定。不過，這些決策本來就不是非常精細的決定，而是選擇使用特定第三方，或選擇不進行細項決定。很有可能會地想到以下兩者間：需要或計劃使用特定第三方服務，但減少任何侵犯隱私權的行為 (無論是蓄意或意外)。這是在「建構時間」保護使用者的任務：新增保護措施，減少您未預期的傷害。這些都是您在服務頁面時可提供的新 HTTP 標頭，用來提示或指令使用者代理程式採取特定隱私權或安全性規定。

參照網址政策

正確做法

將政策設為 strict-origin-when-cross-origin 或 noreferrer，即可避免其他網站在連結到參照網址標頭時，或網頁以子資源的形式載入時，接收這些標頭：

index.html:
<meta name="referrer" content="strict-origin-when-cross-origin" />

或是在伺服器端，例如 Express 中：

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

如有需要，可針對特定元素或要求設定寬鬆政策。

為什麼這麼做可以保護使用者隱私

根據預設，瀏覽器發出的每個 HTTP 要求都會傳入 Referer 標頭，該標頭包含啟動要求的網頁網址 (連結、嵌入圖片或指令碼)。這可能會造成隱私權問題，因為網址可能含有私人資訊，且第三方可以使用的網址將私人資訊傳遞給他們。Web.dev 列出了部分包含私人資料的網址範例，藉由瞭解使用者是透過 https://social.example.com/user/me@example.com 來到您的網站，您就可以知道該使用者是誰，因而造成了明確的資料外洩風險。然而，即使網址本身並未公開私人資訊，也還是讓特定使用者 (如已登入帳戶的使用者) 從其他網站來到這裡，因此可以看到該使用者造訪了其他網站。之所以有這些風險，是因為透露了這些資訊，有可能不瞭解使用者的瀏覽記錄。

提供 Referrer-Policy 標頭 (拼字正確！) 可讓您改變此設定，以防部分參照網址傳遞。MDN 會列出完整詳細資料，但大多數瀏覽器現在預設採用 strict-origin-when-cross-origin 的假設值，也就是說，參照網址現在只會以來源的形式 (而非 https://web.dev/learn/privacy) 傳遞到第三方，因此這非常實用。這確實非常實用，您不必採取任何行動。https://web.dev不過，您可以指定 Referrer-Policy: same-origin 進一步加緊，避免將任何參照網址資訊傳遞給第三方 (或使用 Referrer-Policy: no-referrer 避免傳遞給包括您自有來源的任何使用者)。(這是一個很好的例子，說明隱私權與公用程式的平衡；新預設值比以往擁有更多隱私保護，但仍可將高階資訊提供給您選擇的第三方，例如您的分析服務供應商)。

明確指定這個標頭也很有幫助，因為這樣您就能確切知道政策是什麼，而非依賴瀏覽器預設值。如果無法設定標頭，則可在 <head> 中使用中繼元素為整個 HTML 網頁設定參照政策：<meta name="referrer" content="same-origin">；如果擔心特定第三方，也可以在個別元素上設定 referrerpolicy 屬性，例如 <script>、<a> 或 <iframe>：<script src="https://thirdparty.example.com/data.js" referrerpolicy="no-referrer">

內容安全政策

Content-Security-Policy 標頭 (通常稱為「CSP」) 會指定外部資源載入來源位置。 主要用於安全考量，可防止跨網站指令碼攻擊和指令碼插入。如果搭配使用和定期稽核，這個 API 也可以限制所選第三方的傳送資料目的地。

這可能會有不愉快的使用者體驗；如果您的某個第三方指令碼開始從不在清單中的來源載入依附元件，該要求將遭到封鎖，指令碼會失敗，而您的應用程式可能會失敗 (或至少縮減為 JavaScript 失敗的備用版本)。如果實作 CSP 以確保安全性，這個做法就很實用，因為其正常用途：防止跨網站指令碼問題發生 (為此，請使用嚴格 CSP)。知道網頁使用的所有內嵌指令碼後，您可以列出這些網頁、計算雜湊值或為每個隨機值 (稱為「nonce」) 新增，然後將雜湊清單加入內容安全政策。這麼做可避免載入不在清單中的任何指令碼。這需要在網站的實際工作環境中製備：網頁上的指令碼必須包含 Nonce，或是在建構過程中計算雜湊值。詳情請參閱 strict-csp 的文章。

幸好，瀏覽器支援相關標頭 Content-Security-Policy-Report-Only。如果提供這個標頭，系統就不會封鎖違反所提供政策的要求，但會將 JSON 報告傳送至提供的網址。這類標頭可能如下所示：Content-Security-Policy-Report-Only: script-src 3p.example.com; report-uri https://example.com/report/，且如果瀏覽器從 3p.example.com 以外的任何位置載入指令碼，則該要求會成功，但系統會將報表傳送至提供的 report-uri。通常在實作政策前可用來測試政策，但這有助於執行「持續稽核」。除了前述的一般稽核功能，您可以開啟 CSP 報告，查看是否出現任何非預期的網域，這可能意味著您的第三方資源正在載入自行載入的第三方資源，而您需要考慮及評估。(當然，這也可能代表某些跨網站指令碼漏洞攻擊超出您的安全性邊界，這點也很重要！)

Content-Security-Policy 是易於使用的複雜 API。這就是已知的。我們將著手建構「新一代」的 CSP，目標雖然相同，但使用上較不複雜。我們目前還沒有準備就緒，但如果您想知道具體的開發方向 (或想要瞭解相關設計，或是瞭解相關設計)，請前往 https://github.com/WICG/csp-next 瞭解詳情。

正確做法

將這個 HTTP 標頭新增至提供的網頁：Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://a-url-you-control。 將 JSON 發布至該網址時，請儲存。查看儲存的資料，取得您的網站在他人造訪時要求的第三方網域。 更新 Content-Security-Policy-Report-Only 標頭以列出您預期的網域，以便查看清單變更的時間：

Content-Security-Policy-Report-Only: default-src 'self' https://expected1.example.com https://expected2.example.com ; report-uri https://a-url-you-control

為什麼要

這將是技術稽核的一環，長期下來。您進行初始技術稽核時，會提供網站共用或傳送使用者資料的第三方清單。這個標頭會使網頁要求即時回報目前聯絡的第三方，而且您可以追蹤長期的變化。這不僅會提醒您現有第三方所做的變更，也會標記未納入技術稽核的新增第三方。請務必更新標頭，停止針對預期的網域回報資料，但也請務必不時重複手動進行技術稽核 (因為 Content-Security-Policy 方法不會標記已傳遞的「哪些」資料，只有已送出要求)。

請注意，您不需要將這個參數加入每次提供的網頁或每個網頁中。請調整收到標頭的網頁回應數量，以便您取得一份具代表性的報表樣本，這些回應的數量不會超過預期。

權限政策

Permissions-Policy 標頭 (在 Feature-Policy 名稱下所導入) 與 Content-Security-Policy 的概念類似，但會限制存取強大的瀏覽器功能。舉例來說，您可以限制使用裝置硬體 (例如加速計、相機或 USB 裝置)，也可以限制非硬體功能，例如具備進入全螢幕模式的權限，或使用同步 XMLHTTPRequest。這些限制可套用至頂層網頁 (避免載入的指令碼試圖使用這些功能)，或套用至透過 iframe 載入的子頁框網頁。這項 API 使用限制其實與瀏覽器「指紋」無關，也就是要禁止第三方執行幹擾性作業 (例如使用功能強大的 API、彈出權限視窗等)。這項定義是由目標隱私權威脅模型 (Target Privacy Threat Model) 定義為「幹擾」。

Permissions-Policy 標頭會指定為 (功能、允許的來源) 組合清單，因此：

Permissions-Policy: geolocation=(self "https://example.com"), camera=(), fullscreen=*

在這個範例中，此頁面 (「本身」) 和來源 example.com 的 <iframe> 可使用來自 JavaScript 的 navigator.geolocation API；允許這個頁面和所有子頁框使用全螢幕 API，並禁止任何頁面，包括使用相機讀取影片資訊。如需更多資訊，請參閱這裡列出的可能範例。

由 Permissions-Policy 標頭處理的功能清單很大，可能隨時變動。目前清單保留於 https://github.com/w3c/webappsec-permissions-policy/blob/main/features.md。

正確做法

根據預設，支援 Permissions-Policy 的瀏覽器會在子頁框中停用強大功能，而您必須手動啟用這類功能！ 根據預設，這個方法不會對外公開。如果您的網站需要這些子頁框，可視需要新增這些子頁框。 不過，系統預設並未對主頁面套用權限政策，因此由主頁面載入的指令碼 (包括第三方指令碼) 不會限制使用這些功能。因此，根據預設，對所有頁面套用嚴格的 Permissions-Policy，然後逐步加回網頁需要的功能。

影響 Permissions-Policy 的強大功能包括：要求使用者的位置資訊、感應器存取權 (包括加速計、陀螺儀和磁力儀)、全螢幕權限，以及要求存取使用者的相機和麥克風。如要查看 (變更) 完整功能清單，請點選上方連結。

遺憾的是，根據預設，封鎖所有功能，然後選擇性地重新允許，需要在標頭中列出所有功能，而這可能會覺得難以處理。不過，Permissions-Policy 標頭是很好的入門起點。permissionspolicy.com/ 提供方便點選的產生器，可用來建立這類標頭：透過這個標頭建立標頭，停用所有功能，結果如下：

Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(),
display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(),
fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(),
payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=()

瞭解網路瀏覽器內建的隱私權功能

除了「建構時間」和「設計時間」保護措施之外，系統還有「執行時間」下的隱私保護機制，也就是說，瀏覽器本身導入的隱私權功能可以保護使用者。儘管這些功能屬於產品功能，您可以直接控製或做為網站開發人員使用的功能，但您必須留意這些功能，因為您的網站可能會受到這些產品對瀏覽器的影響。以下舉例說明這些瀏覽器保護措施對網站的影響：如果您的用戶端 JavaScript 需要等待第三方依附元件載入後再繼續設定頁面，且第三方依附元件完全不載入，則頁面設定可能無法完成，因此系統向使用者顯示半載入的頁面。

包括 Safari (和基礎 WebKit 引擎) 中的智慧防追蹤功能，以及 Firefox (及其引擎 Gecko) 中的加強型追蹤防護功能。這些措施讓第三方很難建立詳細的使用者個人資料。

瀏覽器的隱私權功能措施經常變動，請務必隨時更新。以下提供的保護措施清單在書面時皆正確無誤。瀏覽器也可能會導入其他保護措施，請注意，以下清單僅列舉部分項目。請參閱最佳做法模組，瞭解各種變更內容的做法，務必使用即將推出的瀏覽器版本測試可能會影響專案的變更。請注意，無痕模式/私密瀏覽模式有時會採用與瀏覽器預設設定不同的設定 (例如，這類模式預設可能會封鎖第三方 Cookie)。因此，在不使用私密瀏覽模式的情況下，大多數使用者的一般瀏覽體驗不一定能反映無痕模式中的測試。另外要注意的是，如果在不同情況下封鎖 Cookie，可能表示除了 Cookie 之外，其他儲存解決方案 (例如 window.localStorage) 也會遭到封鎖。

Chrome

  • 我們預計日後會封鎖第三方 Cookie。截至本文所述為止，系統預設不會封鎖這些擴充功能 (但使用者可以自行啟用)：https://support.google.com/chrome/answer/95647 提供詳細資訊。
  • 您也可以前往 privacysandbox.com/，瞭解 Chrome 的隱私權功能，以及 Chrome 與 Google 和第三方服務通訊的功能。

Edge

  • 系統預設不會封鎖第三方 Cookie (但可由使用者啟用)。
  • 根據預設，系統會封鎖 Edge 的追蹤防護功能，封鎖來自未造訪網站的追蹤程式和已知的有害追蹤器。

Firefox

如要深入瞭解可能遭封鎖的項目，並協助偵錯問題，請按一下網址列中的盾牌圖示，或是在 Firefox 中前往 about:protections。

Safari

  • 系統預設會封鎖第三方 Cookie。
  • 在智慧型追蹤防護功能中，Safari 會將傳送至其他網頁的參照網址減少為頂層網站，而非特定網頁：(https://something.example.com，而非 https://something.example.com/this/specific/page)。
  • 瀏覽器 localStorage 資料會在七天後刪除。

(如需這些功能摘要，請參閱 https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/)。

如要深入瞭解可能遭到封鎖的項目，並協助偵錯問題，請在 Safari 的開發人員選單 (電腦版) 中啟用「智慧追蹤預防偵錯模式」。(詳情請參閱 https://webkit.org/blog/9521/intelligent-tracking-prevention-2-3/)。

API 提案

為什麼需要新的 API？

雖然瀏覽器產品中的全新隱私權保護功能和政策有助於維護使用者隱私，但也帶來諸多挑戰。許多網路技術雖可供跨網站追蹤使用，但可用於其他用途。舉例來說，我們每天使用的許多身分聯盟系統都是仰賴第三方 Cookie。目前發布商仰賴的許多廣告解決方案是以第三方 Cookie 為基礎打造而成。許多詐欺偵測解決方案仰賴數位指紋採集。如果第三方 Cookie 和數位指紋採集功能淘汰，這些用途會受到什麼影響？

因為瀏覽器難以區分用途，而且確實區分違反隱私權的用途。這也是大多數主要瀏覽器為了保護使用者隱私而封鎖第三方 Cookie 和數位指紋採集功能或打算這麼做的原因。

您需要採用新的方法：隨著第三方 Cookie 逐漸淘汰並減少數位指紋採集，開發人員需要專門建構的 API 以便滿足用途 (但還沒停用)，但設計為保護隱私權。我們的目標是設計及建構無法跨網站追蹤的 API與前一節所述的瀏覽器功能不同，這些技術想要成為跨瀏覽器的 API。

API 提案範例

以下僅列舉部分內容，只是我們討論的一些內容。

用來取代第三方 Cookie 技術的 API 提案範例：

以下提供這些 API 提案取代以被動追蹤為基礎建構的技術：

其他 API 日後可在不使用第三方 Cookie 的情況下建構的其他提案範例：

此外，我們也即將推出另一種類型的 API 提案，以便針對瀏覽器個別進行隱密追蹤。 其中一個範例是隱私預算。在上述各種用途中，Chrome 最初提議的 API 一律屬於 Privacy Sandbox 的一部分。

Global-Privacy-Control 標頭旨在與網站通訊，讓使用者知道哪些網站收集的個人資料不會與其他網站共用。這項功能的用意與已停用的「不追蹤」功能類似。

API 提案的狀態

其中大部分的 API 提案尚未部署、僅於標記後方或有限的環境中部署，以供實驗之用。

這個公開轉型階段相當重要：瀏覽器廠商和開發人員會收集討論和經驗，瞭解這些 API 是否實用，以及是否實際執行這些 API 的設計。開發人員、瀏覽器廠商和其他生態系統的執行者會使用這個階段來疊代 API 的設計。

如要瞭解目前提議的新 API，建議您查看 GitHub 上的隱私權團體提案清單。

是否需要使用這些 API？

如果產品是直接採用第三方 Cookie 或數位指紋採集等技術建立而成，建議您運用這些新的 API 進行測試，並對討論和 API 設計貢獻自己的經驗。在所有其他情況下，您在撰寫內容時不一定知道這些新 API 的所有細節，但最好瞭解即將推出的內容。