[OUTDATED] First-Party Sets 和 SameParty 屬性

警告：第一方集合提案已更新，本文已過時。如需最新資訊，請參閱說明和測試操作說明。

許多機構都有具有不同網域名稱的相關網站，例如 brandx.site 和 fly-brandx.site，或是不同國家/地區適用的網域，例如 example.com、example.rs、example.co.uk 等。

瀏覽器即將改為提供第三方 Cookie 已過時 旨在強化網路使用者的隱私，但這類網站經常使用 Cookie 來保護使用者 需要跨網域維持及存取狀態的功能 例如單一登入和同意聲明管理。

第一方集合可允許由 如果第一方和「廣告放送」 其他第三方則以不同方式處理。當中的網域名稱 系統會將第一方集合視為同一方，且能標記哪些 Cookie 屬於 是在相同派對情境中設定或傳送。目的在於找出 防止第三方跨網站追蹤，同時 維護一個不會破壞有效用途的路徑。

第一方集合提案目前處於測試中 階段，請繼續閱讀以瞭解其運作方式 以及如何試用

第一方和第三方 Cookie 有何不同？

Cookie 本質上不是第一方或第三方，取決於目前的 若是包含 Cookie 的內容可能是指 在 JavaScript 中透過 cookie 標頭或 document.cookie 傳送。

舉例來說，如果你在瀏覽期間，video.site 有 theme=dark Cookie 並向 video.site 發出 video.site 要求，而該要求是相同網站 背景資訊，以及 且已納入第一方 Cookie。

不過，如果您使用 my-blog.site 嵌入含有 iframe 播放器的 video.site，要求從 my-blog.site 發出至 video.site 時 ，且 theme Cookie 為「第三方」。

是否納入 Cookie 取決於 Cookie 的 SameSite 屬性：

• 同網站 背景資訊，以及 SameSite=Lax、Strict 或 None 會讓 Cookie 成為第一方。
• 使用 SameSite=None 的「跨網站情境」，會將 Cookie 設為第三方。

但有時跳出的手法並非如此。假設brandx.site是旅遊行程 預訂網站且使用 fly-brandx.site 和 drive-brandx.site 區分航班和租車服務在預訂一趟歷程中，訪客 會在這些網站之間選擇不同的選項 - 他們期待 「購物車」和所選 Cookie 的設定brandx.site 以 SameSite=None Cookie 管理使用者的工作階段 跨網站結構定義缺點是 Cookie 缺少跨網站 要求偽造假冒 (CSRF) 防護。如果 evil.site 包含 brandx.site，就會加入該 Cookie！

Cookie 是跨網站 Cookie，但這些網站均由同一個 Cookie 自有自營 並根據貴機構的使命 價值觀和目標進行調整訪客也知道這同一個組織，也希望 也就是相同的身分

注意：第一方集合的用途是定義 跨網站情境仍是第一方。您可以將這個 Cookie 加入 並排除在第三方情境下。

第一方集合政策

First-Party Sets 建議 方法，在多個網站上明確定義此關係的方法 由同一方自有自營這會讓「brandx.site」 定義自身與 fly-brandx.site 的第一方關係。 drive-brandx.site (依此類推)。

驅動的隱私權模型 每項 Privacy Sandbox 提案都是根據分區的概念 因此在網站之間畫出界線，可避免跨網站追蹤。 限制存取任何可用來識別使用者的資訊。

雖然預設選項是按網站劃分，因此可以解決許多第一方問題 brandx.site 範例顯示，第一方 Cookie 規模較小 而非單一網站

第一方集合提案的一大關鍵，就是確保政策 也能防止濫用或濫用舉例來說，第一方集合不得 例如跨不相關的網站交換使用者資訊 。概念就是確保 第一方集合對應了使用者瞭解的第一方第一方區隔 用於在不同方之間分享身分資訊。

網站註冊第一方集合的方法可能是網站 將建議的網域群組提交至公開追蹤程式 (例如 專屬 GitHub 存放區)，以及滿足瀏覽器需求所需的資訊 政策。

注意：新第一方組合的接受程序仍在與 W3C 還有其中一個選項是，由 而非瀏覽器公司

根據政策確認第一方集合斷言後，瀏覽器 然後透過更新程序擷取集合清單。

來源試用已定義政策 (並非最終)，但原則為 可能會保持不變：

• 第一方集合中的網域都必須是相同的自有自營網域 並根據貴機構的使命 價值觀和目標進行調整
• 網域應可供使用者識別為一個群組。
• 網域應共用通用的隱私權政策。

，瞭解如何調查及移除這項存取權。

注意：進一步瞭解第一方建議的第一方政策 組合。

如何定義第一方集合

指定成員和機構第一方擁有者後 然後將您提議的組合送交審核。與 程序仍在討論中。

注意：第一方集合並非完整清單 。您「只」需要建立集合 。 請務必詳閱「第一方集合的適用用途」 來源試用？」。

如要宣告第一方集合，請列出成員和擁有者的靜態 JSON 資源 都應由各叢集的頂層 /.well-known/first-party-set 代管 加入的網域

在 brandx 第一方集合的範例中，擁有者網域會代管 追蹤 https://brandx.site/.well-known/first-party-set:

{
  "owner": "brandx.site",
  "version": 1,
  "members": ["fly-brandx.site", "drive-brandx.site"]
}

集合的每個成員也會代管一個靜態 JSON 資源，指向回頭 集合擁有者。 https://fly-brandx.site/.well-known/first-party-set 的退款金額如下：

{ "owner": "brandx.site" }

並在 https://drive-brandx.site/.well-known/first-party-set：

{ "owner": "brandx.site" }

第一方組合設有以下限制：

• 一組資源集只能有一位擁有者。
• 每個成員只能屬於一個集合，不得重疊或混合。
• 成員清單的用意是相對容易理解， 超過 1000 個物件

，瞭解如何調查及移除這項存取權。

注意：如果您使用「數位數位技術」 連結網站的素材資源連結 共用同一個帳戶管理後端這種做法 代表 Chrome 密碼管理工具 聯盟網站。

第一方集合如何影響 Cookie？

我們提議使用餅乾愛用的食材是提議的SameParty 屬性。指定 SameParty 指示瀏覽器在 Cookie 內容與網址相同時 設為頂層情境

也就是說，如果 brandx.site 設定這個 Cookie：

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

然後，當訪客處於 fly-brandx.site 狀態且要求前往 brandx.site，則 session Cookie 會包含在該項要求中。 舉例來說，如果其他網站並不屬於第一方集合， hotel.xyz，傳送要求給 brandx.site，但系統不會納入這個 Cookie。

在廣泛支援 SameParty 之前，請一併使用 SameSite 屬性和 定義 Cookie 的備用行為您可以把 SameParty 屬性，就是設定 SameSite=Lax 和 SameSite=None。

• SameSite=Lax; SameParty 會擴充 Lax 功能，以便 包含相同方情境 (如果支援)，但改為使用 Lax 以及限制
• SameSite=None; SameParty 會限制「None」功能 就會使用範圍較廣的 None權限。

還有幾項額外規定：

• SameParty 個 Cookie 必須包含 Secure。
• SameParty Cookie 不得包含 SameSite=Strict。

「Secure」仍屬於跨網站性質，因此應採取相應措施 的風險。同樣地，由於這是 跨網站關係，SameSite=Strict 無效，因為仍可 站內緊密的站點式 CSRF 防護

重點：SameParty 屬性只會影響 Cookie 可能會傳送，但不會建立共用 Cookie jar 檔案。Cookie 來源 您只適用以下帳戶的要求或文件：brandx.site brandx.site，Cookie 無法直接供 fly-brandx.site。這可能會令人感到困惑， 但這也表示網站之間的寬鬆界線 讓他們在相同的第三方/跨網站環境中設定或傳送 Cookie，而非 因此 Cookie 是直接分享的

第一方集合適合哪些用途？

如果機構需要 可以在不同的頂層網站共用身分在這個範例中的共同身分 這可以是完整的單一登入解決方案，也可以是只需要 偏好設定。

注意：您可以找出適用於這類用途的候選文字，因為 因為您已將 Cookie 標示為 SameSite=None 但僅限於跨網站使用，而你擁有所有參與的網站。

貴機構可能有不同的頂層網域：

• 應用程式網域：office.com、live.com、microsoft.com
• 品牌網域：amazon.com、audible.com / disney.com、pixar.com
• 可啟用本地化功能的國家/地區專屬網域：google.co.in、 google.co.uk
• 使用者從未直接與互動，但提供的服務網域 gstatic.com fbcdn.net 和 githubassets.com
• 使用者從未直接與其中互動的沙箱網域 安全性原因：googleusercontent.com、githubusercontent.com

該如何參與？

如果您的網站一組符合上述條件， 提供各式各樣的選擇最便宜的投資是閱讀並加入 兩個提案的討論：

• 第一方集合隱私權社群群組討論
• SameParty Cookie 屬性討論

在測試階段，您可以使用 --use-first-party-set 指令列標記和提供逗號分隔的清單 。

您可以在示範網站上試用這項功能： 開始後 https://fps-member1.glitch.me/ Chrome 和以下旗標：

--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me

如果您想在開發環境中進行測試，或是想要在開發環境中進行測試，這項功能就能派上用場 請嘗試在實際環境中新增 SameParty 屬性，看看 則會影響 Cookie

如果你有充分的頻寬足以進行實驗和意見回饋，另外也可以提出申請 針對第一方集合的來源試用，以及 SameParty 。

重要詞彙：嚴謹的試用是 Chrome 讓外部開發人員進行測試的方法 在現實生活情境的早期提案中，提供改善方向所需的意見回饋 然後改進符合網路平台需求的學習新知 請參閱 Chrome 來源入門指南 試用期。

如何更新來源試用的 Cookie

如果您要加入來源試用，並在以下位置測試 SameParty 屬性： 以下列出兩種模式供您參考

選項 1

首先，假設您將 Cookie 標示為 SameSite=None，但您 您想要限制在第一方情境下，可以在「群組」欄位加入 SameParty 屬性。在來源試用的瀏覽器中，Cookie 會 跨網站傳送。

然而，對多數 來源試用以外的瀏覽器將持續傳送 Cookie 一樣可追蹤兩個跨網站間的連結不妨將這個方法視為漸進式強化。

變更前： set-cookie: cname=cval; SameSite=None; Secure

變更後： set-cookie: cname=cval; SameSite=None; Secure; SameParty

選項 2

第二個選項比較有效，但可讓您完全分隔來源 並利用現有功能來測試 SameSite=Lax; SameParty 組合。

變更前： set-cookie: cname=cval; SameSite=None; Secure

變更後：

set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty

檢查傳入請求的 Cookie 時，僅應預期會看到 傳送跨網站要求中的 cname-fps Cookie (如果牽涉的網站與 且瀏覽器正在進行來源試用。舉例來說， 同時對更新版功能 版本。

為什麼不需要第一方集合？

大多數網站的網站界線可以用來 分區或隱私邊界此為建議路線 CHIPS (具有獨立分區的 Cookie) 狀態)，表示網站可自行決定是否採用 透過 Partitioned 屬性傳送的路線，仍包含這些重要的跨站點 嵌入、資源、API 和服務，同時防止系統識別 使用者的資訊

還有幾點注意事項： 組合：

• 您透過不同來源代管網站，而非不同網站。在上述範例中 如果brandx.site有 fly.brandx.site，drive.brandx.site，那麼 是同一個網站內的不同子網域Cookie 可以使用 SameSite=Lax，而且不用設定。
• 您為其他網站提供第三方嵌入項目。這次簡介中範例是 內嵌於 my-blog.site 的 video.site 影片是明確的第三方 。網站由不同機構經營，使用者也能看到 視為獨立實體這兩個網站不可同時存在。
• 您提供第三方社交登入服務。識別資訊提供者 OAuth 或 OpenID 連線等項目經常仰賴第三方 Cookie， 為使用者提供更流暢的登入體驗。此用途確實有效 適合第一方集合，因為機構組織有明顯差異。 WebID 等早期提案為 並探索如何實現這些用途