網路隱私

定義隱私術語和概念

在我們探討網路上各種可用的隱私和安全特性之前，讓我們先定義一些重要的術語。

隱私及其與安全的關係

談論隱私很難不涉及安全——它們密切相關，沒有良好的安全性，你就無法真正建立尊重隱私的網站。因此，我們將對兩者都進行定義。

• 隱私是指賦予使用者控制其資料如何被收集、儲存和使用的權利，並且不被不負責任地使用。例如，你應該清楚地告知使用者你正在收集哪些資料、這些資料將與誰共享以及將如何使用。使用者必須有機會同意你的資料使用條款，能夠訪問你儲存的他們所有的資料，並且如果他們不再希望你擁有這些資料，可以將其刪除。你也必須遵守自己的條款：沒有什麼比使用者資料在未經他們同意的情況下被使用和共享更能侵蝕使用者信任了。這不僅在道德上是錯誤的，還可能違法。世界上許多地區現在都有保護消費者隱私權的法律（例如歐盟的 GDPR）。

• 安全是指保護私人資料和系統免受未經授權的訪問。這包括公司（內部）資料，以及使用者和合作夥伴（外部）資料。如果你的安全性很弱，惡意方仍然可以竊取使用者資料，那麼擁有一個讓使用者信任你的健全的隱私政策也毫無用處。

個人資訊和私密資訊

個人資訊是任何描述使用者的資訊。例如：

• 郵政地址、電子郵件地址、電話號碼或其他聯絡資訊
• 護照號碼、銀行賬戶、信用卡、社會安全號碼或其他官方識別符號
• 身高、性別表達、體重、髮色或年齡等身體特徵
• 病史、過敏或現有疾病等健康資訊
• 可以關聯到個人的使用者名稱
• 愛好、興趣或其他個人偏好
• 指紋或面部識別資料等生物特徵資料

私密資訊是使用者不希望公開分享且必須保密的任何資訊（即，只有某一組授權使用者才能訪問的資訊）。一些私密資料是法律規定的私密資訊（例如醫療資料），而另一些則更多是出於個人偏好。

個人可識別資訊

承接上一節，個人可識別資訊（PII）是指可以全部或部分用於追蹤和/或識別特定個人的資訊。例如，如果一個網站線上洩露了使用者的姓名和郵政編碼列表，不法分子幾乎肯定可以利用這些資訊找到他們的完整地址。即使沒有發生大規模洩露，仍然有可能透過一些不那麼明顯的方式來識別使用者，比如他們使用的瀏覽器、裝置、安裝的特定字型等等。

跟蹤

跟蹤指的是記錄使用者在多個不同網站上的活動的過程。這可以透過多種方式實現，例如：

• 檢視在嵌入了第三方內容的不同網站上設定的多個第三方 Cookie，以獲取關於使用者的各種資訊點。
• 檢視 Referer 標頭，以瞭解使用者從哪裡導航而來。
• 在入站連結的 URL 中包含引數（例如，在連結到產品頁面的嵌入式廣告或營銷郵件中），這些引數可以向連結到的網站揭示連結的來源、所屬的營銷活動、點選連結的使用者的電子郵件地址或其他識別符號等。這個過程被稱為連結裝飾，產生的連結 URL 如下所示：https://example.com/article/?id=62yhgt1a&campaign=902。
• 重定向跟蹤，即跟蹤器短暫地（且不易察覺地）將使用者重定向到其網站，以利用第一方儲存來跨網站跟蹤該使用者。這使得跟蹤器能夠繞過第三方 Cookie 被阻止的情況。例如，如果你讀完一篇產品評測並想點選購買，你可能會在不知不覺中先導航到重定向跟蹤器，然後再到零售商。這意味著跟蹤器作為第一方被載入，可以在將你轉發到零售商之前，將跟蹤資料與其儲存在第一方 Cookie 中的識別符號關聯起來。

跟蹤資料可用於構建使用者的畫像以及他們的興趣和偏好，這通常是不好的，並且會在不同程度上令人煩惱。例如：

• 定向廣告：每個人都有過這樣的不安經歷：在一臺裝置上研究了一些要購買的商品，然後突然在所有其他裝置上被同樣產品的廣告轟炸。
• 出售或共享資料：一些第三方被發現會彙編跟蹤資料，然後將其出售/分享給他人用於各種目的，如定向廣告。這顯然是極不道德的，並且根據發生地點的不同，也可能是非法的。
• 透過資料產生偏見：在最壞的情況下，共享資料可能導致使用者受到不公平的對待。例如，想象一家保險公司發現了某個潛在客戶未同意分享的資料點，並以此為理由提高其保險費。

指紋識別

與跟蹤密切相關的一個過程是指紋識別：這特指透過收集一系列關於使用者的資料點來識別使用者，從而將他們與其他使用者區分開來。這可以是任何資訊，從 Cookie 內容到他們使用的瀏覽器以及本地安裝的字型。

現代瀏覽器採取措施幫助防止基於指紋識別的攻擊，要麼不允許訪問資訊，要麼在必須提供資訊時引入變化或“噪聲”，以防止其被用於識別目的。

例如，如果一個網站向用戶的瀏覽器查詢已用時間，將該時間與伺服器報告的時間進行比較可能有助於指紋識別。因此，瀏覽器通常會為計時器引入少量可變性，以降低其在識別使用者系統方面的作用。

瀏覽器提供的隱私特性

瀏覽器供應商意識到保護使用者隱私的必要性，以及跟蹤、指紋識別等對使用者體驗的負面影響。為此，他們實施了各種增強隱私保護和/或減輕威脅的功能。在本節中，我們將探討瀏覽器自動應用的不同類別的隱私保護措施。

預設使用 HTTPS

傳輸層安全性（TLS）透過在網路傳輸過程中加密資料來提供安全和隱私，是 HTTPS 協議背後的技術。TLS 有利於隱私，因為它能阻止第三方截獲傳輸的資料並惡意使用，例如用於跟蹤。

所有瀏覽器都在朝著預設要求 HTTPS 的方向發展；這實際上已經成為現實，因為沒有這個協議，你在網路上能做的事情就很少了。

相關主題如下：

證書透明度

一個用於監控和審計證書的開放標準，建立了一個公共日誌資料庫，可用於幫助識別不正確或惡意的證書。

HTTP 嚴格傳輸安全 (HSTS)

HSTS 被伺服器用來保護自己免受協議降級和 Cookie 劫持攻擊，它允許網站告知客戶端只能使用 HTTPS 與伺服器通訊。

HTTP/2

雖然 HTTP/2 在技術上並不必須使用加密，但大多數瀏覽器開發者僅在與 HTTPS 一起使用時才支援它；因此，從這個角度看，它可以被視為一個增強安全/隱私的特性。

“強大功能”需使用者選擇加入

那些提供對潛在敏感資料和操作訪問許可權的所謂“強大”的 Web API 功能，僅在安全上下文中可用，這基本上意味著僅限 HTTPS。不僅如此，這些 Web 功能還受到使用者許可權系統的限制。使用者必須明確選擇加入諸如允許通知、訪問地理位置資料、使瀏覽器進入全屏模式、訪問網路攝像頭的媒體流、使用 Web 支付等功能。

反跟蹤技術

瀏覽器已經實現了多種反跟蹤功能，自動增強其使用者的隱私保護。其中許多功能會阻止或限制嵌入在 <iframe> 中的第三方網站訪問頂級域名上設定的 Cookie、執行跟蹤指令碼等。

• Set-Cookie 標頭的 SameSite 屬性的預設值已更新為 Lax，以提供更好的保護，防止跟蹤和 CSRF 攻擊。更多資訊請參閱使用 SameSite 控制第三方 Cookie。
• 瀏覽器都已開始預設阻止第三方 Cookie。更多詳情請參閱瀏覽器如何處理第三方 Cookie？
• 瀏覽器正在實施一些技術，只在某些不損害隱私的情況下允許第三方 Cookie，或者以替代方式實現當前需要第三方 Cookie 的常見用例。請參閱從第三方 Cookie 過渡和替代第三方 Cookie。
• 一些瀏覽器會從 URL 中剝離已知的跟蹤引數——這包括 Firefox、Safari 和 Brave。瀏覽器擴充套件程式也有助於實現這一點，例如 ClearURLs。
• 瀏覽器已實現重定向跟蹤保護。

客戶端開發者的隱私注意事項

Web 開發者可以而且應該採取一些措施來改善使用者的隱私。以下章節討論了其中最重要的幾項。其中一些類別並非純粹的技術任務，需要與其他團隊成員合作。

合乎道德地收集資料

公司出於各種原因從使用者那裡收集大量不同的資料：

• 使用者名稱、密碼、電子郵件等，用於身份驗證。
• 電子郵件、郵政地址和電話號碼，用於通訊。
• 年齡、性別、地理位置、最喜歡的消遣以及大量其他個人可識別資訊（PII），用於從網站個性化到客戶滿意度調查等各種目的。
• 在他們自己和其他網站上的瀏覽習慣，用於衡量頁面和功能的成功指標。
• 以及更多。

在向客戶收集資料時，你有機會表現出誠信，向他們展示你的可信賴性，並與他們建立良好的關係，從而提升你的品牌和成功機會。

資料收集的道德準則可以歸結為三個簡單的原則：

• 不要收集超出需求的資料
• 清晰地說明你將如何使用收集到的資料
• 使用完畢後刪除資料

不要收集超出需求的資料

向用戶索取大量資料是很誘人的，因為你認為將來可能會有用。然而，你收集的每一份額外資料都會增加使用者隱私的風險，並增加他們放棄當前操作（無論是填寫調查問卷還是註冊服務）的可能性。

匿名化資料是個好辦法。你還應該考慮是否可以透過降低資料請求的粒度來獲得所需的資訊。例如，你可以詢問使用者選擇更籠統的類別，而不是詢問他們最喜歡的產品。

不過，保護使用者隱私的最佳方式是最大限度地減少你收集的資料。回到前面的例子，你可以透過檢視使用者的購買歷史來推斷出相同的資料。再舉一個例子，使用者喜歡能夠匿名購買產品。你不應該強迫他們註冊賬戶；如果這對服務執行不是必需的，那麼這應該是他們的選擇。

清晰地說明你將如何使用收集到的資料

一旦你決定了要收集哪些資料，你應該在你的網站上釋出一份隱私政策，清楚地說明：

• 你收集的資料
• 你使用資料的方式
• 你可能與之共享資料的各方（如有），並宣告在共享前會徵求使用者同意
• 你在刪除資料前保留資料的時間
• 使用者檢視你從他們那裡收集的資料以及在需要時刪除資料的方式

在向你提供資料時，你的使用者應該有機會閱讀你的隱私政策並同意它。他們應該能夠控制自己是否滿意並同意你的條款。並且如上所述，他們也應該能夠看到你收集了他們的哪些資料，並可以在需要時刪除它。

當你釋出了你的隱私政策後，你需要確保你遵守它——言行一致對於建立使用者信任非常重要。你應該只收集你宣告會收集的資料，並且只用於你宣告會使用的目的。如果公司裡有人想出了一個巧妙的新方法來使用現有資料，但如果你的政策沒有明確說明你會將其用於該目的，那麼這在你的政策條款下仍然是不允許的。如果使用者同意將其資料用於特定目的，而該目的後來擴大了，你可能需要考慮獲得新的同意。

使用完畢後刪除資料

前面我們提到，要讓使用者能夠檢視你收集了他們的哪些資料，並可以在需要時刪除。你或許可以將其作為他們刪除賬戶體驗的一部分（他們的資料也隨之刪除），或者將它們作為兩個獨立的選項。無論哪種方式，這些選項都應該易於找到。

允許使用者選擇何時刪除大部分資料是非常有賦權的，並且能夠建立信任，但可能有一些資料你會希望自己處理刪除。例如，有些資料可能只使用幾個小時或幾分鐘然後就被刪除，比如使用者登入期間管理會話時使用的資料。

減少跟蹤

前面我們討論了跟蹤，以及它被用於的一些不道德的目的。我們不必詳細說明這種用法如何侵蝕使用者信任；在任何可能的情況下，你都應該只將像第三方 Cookie這樣的潛在跟蹤機制用於合乎道德的用途，例如在網站之間傳遞登入或其他個性化狀態。

還記得前面提到過，瀏覽器都開始預設阻止第三方 Cookie，同時實施替代技術來實現常見的用例。為此做好準備是個好主意，方法是限制你所依賴的跟蹤活動數量，和/或透過其他方式實現所需的資訊持久化。更多資訊請參閱從第三方 Cookie 過渡。

謹慎管理第三方資源

當然，如果你只關心自己建立的資源（程式碼、Cookie、網站等），管理隱私會很容易。真正的挑戰在於你的網站很可能會使用第三方資源。這可能包括嵌入在 <iframe> 中的第三方內容、庫、框架、API、外部託管的資源（如圖片和影片）等。

第三方資源是現代 Web 開發的重要組成部分，它們提供了強大的功能。然而，你允許進入網站的任何第三方資源都可能擁有與你自己的資源相同的許可權；這完全取決於它如何被包含在你的網站中：

• 透過 <iframe> 嵌入到你網站的第三方內容中執行的 JavaScript 受同源策略的隔離，這意味著它無法訪問頂級瀏覽上下文中包含的其他指令碼和資料。
• 然而，透過 <script> 元素直接包含在你頁面中的第三方指令碼，則可以訪問你的其他指令碼和資料，無論它託管在你的網站還是其他網站上。它實際上等同於第一方程式碼。以這種方式包含的惡意指令碼可能會秘密竊取你的使用者資料，例如將其傳送到第三方伺服器。

審計你在網站上使用的所有第三方資源非常重要。確保你瞭解它們收集了哪些資料、它們向誰發出了哪些請求，以及它們的隱私政策是什麼。如果你使用的第三方指令碼違反了你精心設計的隱私政策，那麼你的政策將毫無用處。

在審計了你的第三方資源並瞭解了它們的作用後，你應該權衡它們的負面影響與它們帶來的價值。如果一個第三方指令碼是免費且非常有用，但收集了相當多的使用者資料，你可以：

1. 接受這種權衡，更新你的隱私政策以包含相關細節，並希望這不會對使用者的信任產生太大影響。
2. 尋找一個替代的、資料收集較少的第三方工具。
3. 自己構建一個工具。

以下列表提供了一些關於如何減輕使用第三方資源所固有的隱私風險的技巧：

• 在嵌入第三方資源時，考慮是否有辦法以較小的隱私影響實現相同或相似的效果。例如，在你的網站上嵌入一個社交媒體帖子檢視器可能很有趣，但這真的有必要嗎？一個指向你社交媒體頁面的連結是否足夠？此外，一些第三方服務提供增強隱私的選項。例如，請參閱 YouTube 的嵌入影片和播放列表 > 開啟隱私增強模式。

• 在可能的情況下，當你向第三方發出請求時，應阻止他們接收 Referer 標頭。這可以以相當精細的方式實現，例如在外部連結上包含 rel="noreferrer"。或者，你可以為頁面或網站更全域性地設定，例如使用 Referrer-Policy 標頭。

  注： 另請參閱Referer 標頭：隱私和安全問題。

• 使用 Permissions-Policy HTTP 標頭來控制對 API“強大功能”（如通知、地理位置資料、訪問網路攝像頭媒體流等）的訪問。這對於隱私很有用，因為它能阻止第三方網站對這些功能進行意外操作，而且使用者也不希望被他們可能不理解的許可權提示不必要地轟炸。你還可以透過在 <iframe> 元素自身的 allow 屬性中指定許可權策略來控制嵌入在 <iframe> 元素內的第三方網站中“強大功能”的使用。

  注： 更多資訊和示例，請參閱我們的Permissions-Policy 指南，以及 permissionspolicy.com 上有用的工具，包括一個策略生成器。

• 使用 <iframe> 的 sandbox 屬性來允許或禁止在 <iframe> 中嵌入的內容中使用某些功能——這包括下載、表單提交、模態框和指令碼等。

保護使用者資料

你需要確保使用者資料在收集後能夠安全地傳輸和儲存。這更像是一個安全話題，但在這裡值得一提——如果你的安全性鬆懈，攻擊者可以竊取資料，那麼一個好的隱私政策也毫無用處。

以下提示為保護使用者資料提供了一些指導：

• 安全很難做到萬無一失。在實施涉及資料收集的安全解決方案時——尤其是在涉及登入憑證等敏感資料時——使用來自信譽良好供應商的可靠解決方案是明智的。例如，任何有信譽的伺服器端框架都會有內建功能來防範常見漏洞。你也可以考慮使用專門的產品來滿足你的目的——例如身份提供商解決方案或安全的線上調查提供商。
• 如果你想自己推出一個收集使用者資料的解決方案，確保你瞭解自己在做什麼。聘請一位經驗豐富的伺服器端開發者和/或安全工程師來實施該系統，並確保其經過徹底測試。使用多因素認證（MFA）來提供更好的保護。考慮使用專門的 API，如 Web Authentication 或 Federated Credential Management 來簡化應用程式的客戶端部分。
• 在收集使用者註冊資訊時，強制使用強密碼，這樣使用者的賬戶資訊就不容易被猜到。弱密碼是安全漏洞的主要原因之一。鼓勵你的使用者使用密碼管理器來生成和儲存複雜密碼；這樣他們就不用擔心記住密碼，也不會因為寫下來而造成安全風險。
• 不要在 URL 中包含敏感資料——如果第三方截獲了 URL（例如透過 Referer 標頭），他們可能會竊取該資訊。使用 POST 請求而不是 GET 請求來避免這種情況。
• 考慮使用像內容安全策略和許可權策略這樣的工具，來強制執行網站上的一系列功能使用規則，從而更難引入漏洞。這樣做時要小心——如果你阻止了某個第三方指令碼正常工作所需的功能，你可能會破壞網站的功能。這是你在審計第三方資源時可以研究的問題（參見謹慎管理第三方資源）。

另見

• 網路安全
• 學習隱私（位於 web.dev）
• 隱私沙盒（位於 privacysandbox.google.com）
• 精益資料實踐（位於 mozilla.org）