第三方

什麼是第三方？

一個網站極為罕見，十分罕見。HTTP Web Almanac 可顯示大部分網站 (約 95%) 包含一些第三方內容。

Almanac 將第三方內容定義為共用和公開來源代管的內容，可供所有人使用 且不受個別網站擁有者的影響。這些項目可能是圖片或其他媒體，例如影片、字型或指令碼。 圖片與指令碼所涵蓋的不只是所有其他元素。第三方內容不是網站開發不可或缺的一環 但也可能是您幾乎可以確定使用的是從公開共用伺服器載入的項目，無論是網路字型、 影片、廣告或 JavaScript 程式庫的內嵌 iframe。舉例來說，您使用的網路字型可能是 Google Fonts、 或使用 Google Analytics 評估數據分析您在社交網路上加入「喜歡」按鈕或「登入」按鈕； 您可能會嵌入地圖或影片，或是透過第三方服務處理購物交易；您就可以追蹤錯誤 ，透過第三方監控工具為自家開發團隊進行記錄。

在保護隱私權方面，建議將定義稍有不同但用途較小：第三方資源 部分第三方指令碼是由共用及公開來源提供，並如上圖所示，但也屬於編寫程式碼 而非網站擁有者在考慮如何保護自己的 使用者進而保障隱私這將帶領您思考潛在風險，進而決定該如何使用 所需的第三方資源正如先前的討論重點，這些方法可以幫助您瞭解背景資訊，並 所以瞭解您必須做出哪些取捨，以及這些重點是什麼意思？

談到「第三方資源」時，這並不是什麼一般而言，第一方和 第三方確實是一種關於使用情境。從其他網站載入的指令碼是第三方 資源，載入指令碼的 HTTP 要求可能包含 Cookie，但這些 Cookie 實際上並不是「第三方 Cookie」 就好比 Cookie 以及是否為「第三方」或「第一方」取決於指令碼是否載入 或指令碼擁有者網站上某個網頁

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

第三方機構可為網站增添功能。這可能是因為使用者看不到或隱藏的功能 開發人員函式 (例如錯誤追蹤)，但可降低開發負載，指令碼本身也會保留下來 由其他人提供：您要包含的服務開發團隊這一切運作原理是因為網路的可組合性： 能夠聚集在一起 形成大於總和的

HTTP Archive 的 Web Almanac 如何提供詳盡的說明：

第三方機構提供持續收集的圖片、影片 字型、工具、程式庫、小工具、追蹤程式、廣告，以及其他您想嵌入網頁的內容。這樣一來， 即使是非技術人員也能在網站上建立及發布內容。如果沒有第三方，網路 將會是非常無趣、文字式的學術媒介，而不是資訊豐富、沈浸式複雜的平台，對生活來說至關重要 十分重要

第三方資源可以執行哪些操作？

存取某些資訊

當你在網站上使用第三方資源時 (無論資源為何)，部分資訊都會傳送給該第三方。 舉例來說，如果您加入來自其他網站的圖片，使用者瀏覽器提出的 HTTP 要求將連同參照網址一併傳送 標頭。

跨網站追蹤

再延續上述範例 - 從第三方網站載入圖片時，圖片可能會包含 Cookie，而該 Cookie 會在使用者下次要求該圖片時傳回第三方。也就是說，第三方可知道 服務就會傳回具有該名使用者專屬 ID 的 Cookie。也就是說 使用者下次造訪您的網站，或是其他包含第三方資源的網站， 系統將再次傳送 ID Cookie。如此一來，第三方就能記錄使用者造訪的位置，例如您的網站、其他 在同一個網站上使用同一個第三方資源

這是跨網站追蹤功能：允許第三方收集使用者在許多網站上的活動記錄 網站都會使用來自同一個第三方的資源可以是字型、圖片或樣式表等所有靜態資源。 也可能是動態資源，包括指令碼、社群媒體按鈕或廣告。加入的指令碼可以收集更多 資訊，因為它是動態的，可以檢查使用者的瀏覽器和環境，並將資料傳回其發起者。 任何腳本都可以在某種程度上執行這項作業， 如同指令碼以外的動態資源，例如社群媒體嵌入或 或是分享按鈕當您查看熱門網站上的 Cookie 橫幅詳細資料時， 可以看到許多 可能會為使用者置入追蹤 Cookie，藉此建立其活動圖像，建立該使用者的個人資料。有 也可能是數百個如果第三方提供免費服務，而透過這種方式，他們能夠以經濟實惠的方式 是他們收集這些資料後營利

針對哪些類型的隱私權問題，瀏覽器應該為瀏覽器保護其使用者，這份實用指南就是「目標隱私權威脅模型」。 此文件在撰寫撰寫期間仍在討論中，但僅列舉出部分生成式 AI 模型 存在的隱私威脅。來自第三方資源的風險主要是「不當的跨網站辨識結果」， 網站可以從多個網站上辨識出同一位使用者，以及「機密資訊揭露」，讓網站能夠收集 使用者所認定的敏感資訊

這是主要的區別：即使第三方未收集額外的機密資料，不必要的跨網站辨識技術還是不佳 資訊，因為使用者無法掌控自己的身分。取得使用者的參照網址和 IP 位址存取權 Cookie 本身就是不必要的揭露事項使用第三方資源，並一併規劃使用方法 確保這些平台能保護使用者隱私部分工作是由網站開發人員負責推動，部分工作是由瀏覽器負責 擔任使用者代理程式也就是說，該代理商代表使用者行事，可避免機密資訊外洩， 盡可能進行不需要的跨網站辨識以下會詳細說明瀏覽器適用的因應措施和方法 以及網站開發階段

伺服器端第三方程式碼

我們先前對於第三方的定義已經刻意更改 HTTP Almanac 的用戶端方法 (視情況而定) 並在報告中納入第三方原創性資訊，因為從隱私權的角度而言，第三方是任何已知資訊的人 讓其他部門知道

包括在伺服器上提供服務的第三方和用戶端。來自隱私權 因此，第三方程式庫 (例如 NPM 或 Composer 或 NuGet 所含內容) 也同樣十分重要。 您的依附元件是否會向邊界外傳遞資料？若您將資料傳遞至記錄服務或遠端託管的資料庫， 如果程式庫中同時包含「手機主畫面」這類行為可能會違反您使用者的隱私權 因此必須經過稽核伺服器型第三方通常需要您提供使用者資料， 您更能掌控自己的資料相反地，用戶端式第三方 - 指令碼或 HTTP 資源 網站的一部分，且由使用者的瀏覽器擷取 - 不需要該程序，就能直接向使用者收集部分資料 採用中介服務的集合本單元的大部分內容，都著重於識別用戶端第三方 您已經選擇納入並向使用者顯示廣告，因為這種方法的中介服務有限。但值得一試 考慮保護您的伺服器端程式碼，以便您瞭解從伺服器傳出的通訊內容，並能記錄或封鎖 不在預期內。詳細做法不在我們的討論範圍內 (且實際作業取決於您的伺服器設定)， 保障使用者的安全與隱私。

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

第三方指令碼和功能非常重要，我們希望網頁程式開發人員能整合這類項目 不要離他們！但有可能發生問題。第三方內容可能會造成成效問題，而且 也會產生安全性問題，因為您將外部服務導入信任範圍。但第三方 內容也可能會造成隱私權問題！

談到線上的第三方資源時，可以將安全性問題納入考量 (以及其他事情) 第三方可從貴公司的資料竊取資料，或是與其他隱私權問題不同，這類問題等等 由您納入的第三方竊取或取得使用者存取權未經您 (或對方) 同意就收集任何資料。

舉例來說，安全性問題就是「網頁瀏覽者」竊取信用卡資料 - 這類第三方資源 在使用者輸入信用卡詳細資料的網頁中，或許可以竊取信用卡詳細資料，然後傳送給任何人 惡意第三方製作這些重點腳本的使用者在規劃工地時，會很有創意。 一份摘要說明瞭重點腳本的運作方式 隱藏在第三方內容中，例如用於網站標誌、網站小圖示和社群媒體網路的圖片。 jQuery、Modernizr 和 Google 代碼管理工具等熱門程式庫，以及聊天室視窗等網站小工具和 CSS 檔案。

隱私權問題略有不同。這些第三方參與了你的產品； 維持使用者參與度因此，您必須確保使用者能信任他們。如果您採用的第三方會收集 使用者隨後濫用起來，或者難以刪除或發現資料，或導致資料外洩或違反 使用者可能會認為這是他們信任「您的」服務，而非僅是 儲存的資料而是您在網路上的聲譽和關係。因此請思考這一點 你在網站上使用哪些第三方？

有哪些第三方廠商？

我們正在討論「第三方」但實際上兩者的類型不同，而且可存取的使用者資料數量也有所不同。 例如，將 <img> 元素新增至 HTML 並從不同伺服器載入，可為該伺服器提供不同的資訊 而非新增 <iframe> 或 <script> 元素。這些只是範例，並未涵蓋所有情況 ，瞭解您網站可採用的不同第三方項目之區別。

要求跨網站資源

跨網站資源是指網站上從其他網站載入的任何項目，不是 <iframe> 或 <script>。範例 包括 <img>、<audio>、<video>、CSS 載入的網路字型和 WebGL 紋理。這些項目都是透過 HTTP 要求載入 這些 HTTP 要求將納入其他網站先前設定的所有 Cookie、提出要求的使用者 IP 位址。 和目前網頁做為參照網址在預設情況下，所有第三方要求都會包含這項資料， 我們設法減少或隔離不同瀏覽器傳送給第三方的資料，詳情請參閱「瞭解 第三方瀏覽器防護」繼續往下看

嵌入跨網站 iframe

透過 <iframe> 內嵌在網頁中的完整文件，除了這三者以外，還可要求取得其他瀏覽器 API 的存取權 Cookie、IP 位址和參照網址網頁開放哪些 API<iframe>以及要求存取權的方式會因瀏覽器而異。 目前正在進行變更：請參閱「權限政策」以便目前對內嵌的 API 存取降低或監控 文件。

執行跨網站 JavaScript

納入 <script> 元素後，系統會在網頁的頂層內容載入並執行跨網站 JavaScript。也就是說， 可以完整存取您自家第一方指令碼所做的任何作業。瀏覽器權限仍會管理這類資料 因此，請求使用者的位置資訊 (例如) 仍需取得使用者同意聲明。不過網頁呈現的所有資訊 以 JavaScript 變數的形式可透過這類指令碼讀取，而不只是傳送給第三方的 Cookie 也包含專屬於網站的 Cookie。同樣地，如果您在 網頁可能會發出與您程式碼相同的所有 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 的簡化要求對應，顯示要求其他第三方網站的第三方網站等。

正確做法

以新的使用者設定檔開啟瀏覽器，這樣您就不會登入帳戶，且未儲存任何協議；然後開啟瀏覽器 開發工具網路面板，查看所有傳出要求。新增資料欄來顯示每個要求的網域，然後檢查 「第三方要求」核取方塊，僅顯示第三方 (如果有的話)。然後執行下列步驟：

  • 造訪您的網站。
  • 如果您提供使用者帳戶，可以註冊新的帳戶。
  • 嘗試刪除已建立的帳戶。
  • 在網站上執行一、兩種正常行動 (實際執行取決於網站功能，但請挑選大多數使用者採取的常見動作)。
  • 執行您已知涉及第三方依附元件的一或兩項動作。這可能包括將內容分享給 社群媒體、啟動結帳程序，或是嵌入其他網站的內容。

執行這些工作時，請檢查網路面板，將不屬於您網域要求的資源記錄下來 。這些是來自您的某些第三方。使用瀏覽器網路工具擷取網路 寫入 HAR 檔案中

HAR 檔案和擷取

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

Chrome

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

Chrome 開發人員工具網路面板，其中標示出「下載 HAR」符號。
Firefox

開啟瀏覽器開發人員工具 (依序點選 [選單] > [更多工具] > [Web Developer Tools])，前往網路面板，載入 (或重新整理) 網頁，然後選擇 齒輪圖示 。在選單中選擇「全部儲存為 HAR」**。

Firefox 開發人員工具聯播網面板，其中醒目顯示 [Save All As Har] 選項。
Safari

開啟瀏覽器開發人員工具 (依序點選「Menu」>「Develop」>「Show Web Inspector」；如果沒有「開發」選單，請在選單中啟用) 選單 >Safari >偏好設定 >進階 >在選單列中顯示「開發」選單)，前往「網路」面板，載入 (或重新整理) 頁面。 然後選擇右上角的「Export」(匯出) 至「Preserve Log」右側的「Export」(匯出)，您可能需要放大視窗。

Safari Web Inspector Network 面板，以方框特別標出「HAR 匯出」選項。

如需詳情，您也可以記錄傳送給第三方 (在「要求」部分中) 的內容，不過通常是將資料傳送給第三方 混淆，語意不清。

整合第三方的最佳做法

您可以自行為網站使用的第三方設定相關政策，依據對方的做法變更您使用的廣告供應商。 或讓 Cookie 同意聲明彈出式視窗感到困擾或乾擾，或者您想在網站上使用社群媒體按鈕， 追蹤連結，以便在推文中透過 Google Analytics 追蹤。要考量的重點 開發網站是分析服務的隱私權和安全性設定。部分數據分析服務明確用於交易 保護隱私權一般來說，您也可以運用第三方指令碼來自行增添隱私保護服務： 您不是第一個想要改善使用者以及保護這些資料不受第三方資料收集的侵擾 可能已經是解決方案最後，現在許多第三方供應商比以往更敏感的資料收集問題 您可以新增一些功能或參數，啟用保護使用者防護模式以下是幾個例子。

新增社群媒體分享按鈕時

建議您直接嵌入 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， 影片或嵌入內容的連結會傳回程式輔助詳細資料，包括縮圖和標題。TikTok 支援 oEmbed (詳情請參閱 https://developers.tiktok.com/doc/embed-videos) 使用者可以透過手動或程式輔助方式，將 TikTok 影片 https://www.tiktok.com/@scout2015/video/6718335390845095173 的連結轉換成有關該影片的 JSON 中繼資料： https://www.tiktok.com/oembed?url=https://www.tiktok.com/@scout2015/video/6718335390845095173，因此請擷取縮圖 即可顯示。WordPress 通常會使用這個 API 要求 oEmbed嵌入內容資訊您可以透過程式輔助方式使用這項功能 顯示「門面」這種看起來很互動式，而且當使用者選擇點擊互動式影片時，就會切換至嵌入或連結至互動式影片。

嵌入數據分析指令碼時

Analytics 主要用來收集使用者資訊，以便進行分析，這就是資料用途。數據分析系統基本上 服務來收集和顯示存取與使用者相關資料；這些資料是在 Google Analytics 等第三方伺服器上完成， 這個概念此外，您也可以透過自行代管的分析系統 (例如 https://matomo.org/)，不過這種做法比使用 第三方解決方案的運作方式在自家基礎架構上執行這類系統有助於減少資料收集， 不會離開您的生態系統另一方面，管理、移除資料及設定政策 由您負起責任跨網站追蹤的大部分問題，都源自於 Google 或者是使用完全不需收集資料的服務，此法的副作用是。分析軟體過度 專用，好讓網站擁有者瞭解自己的使用者。

從前，一直以來，有個方法專門收集所有各種事物的資料，例如巨型魚網； 後再分析數據，找出值得注意的模式這種心態在整體上營造出不自在和不尊重的感覺 在本課程第 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，而非 https://web.dev/learn/privacy)。如果沒有 不必採取任何行動但是，您可以指定 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

Content-Security-Policy 標頭 (通常稱為「CSP」) 規定了可載入外部資源的位置。 它主要用來保障安全，其方式為防止跨網站指令碼攻擊和指令碼插入，但於使用時 搭配定期稽核，也能限制您所選第三方將資料傳送給哪些位置。

使用者體驗可能不如預期。在您其中一個第三方指令碼開始從 ，則該要求將會遭到封鎖，指令碼將會失敗，應用程式也會失敗。 或至少降級為無法執行 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、彈出式視窗 權限視窗等)。這項定義由目標隱私權威脅模型定義為「入侵」。

Permissions-Policy 標頭指定為一組 (特徵、允許的起點) 配對清單，因此：

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

這個範例允許來自來源 example.com 的網頁 (「self」) 和 <iframe> 使用 navigator.geolocation API 從 JavaScript 擷取；允許這個網頁和所有子頁框使用全螢幕 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，可能表示其他儲存空間解決方案，例如 window.localStorage 所以不只是 Cookie 而遭到封鎖

Chrome

Edge

  • 根據預設，系統不會封鎖第三方 Cookie，但使用者可以啟用這項功能。
  • Edge 的 Tracking Prevention 功能封鎖條件 系統預設會封鎖未造訪網站的追蹤程式和已知的有害追蹤程式。

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 (全球隱私權控制項) 是用來與使用者網站通訊的標頭 希望不會將任何收集到的個人資料提供給其他網站。其用意與「Do Not Track」類似，但現已停止。

API 提案的狀態

這些 API 提案大多尚未部署，或僅部署在標記後方或受限的環境中，以便進行實驗。

這個公開的育成階段非常重要：瀏覽器廠商和開發人員必須收集討論和經驗，瞭解這些 API 是否在 以及他們是否真正能滿足您的需求開發人員、瀏覽器廠商和其他生態系統操作者都使用這個階段 進行 API 設計疊代作業

如要掌握新提議的 API 最新資訊，建議您查看 GitHub 上的隱私權群組提案清單。

您是否需要使用這些 API？

如果您的產品是以第三方 Cookie 或數位指紋採集等技術直接建構，建議您熟悉這些新的 API 並進行測試，讓大家在討論和 API 設計方面貢獻自己的經驗。 在所有其他情況下，您並不需要在撰寫本文時就瞭解這些新 API 的所有細節，不過也建議您留意日後即將發生的變化。