許多機構都有使用不同網域名稱的相關網站，例如 brandx.site 和 fly-brandx.site，或是不同國家/地區的網域，例如 example.com、example.rs、example.co.uk 等。
瀏覽器正朝著淘汰第三方 Cookie的方向前進，以改善網際網路上的隱私權，但這類網站通常會依賴 Cookie 提供功能，這些功能需要在不同網域之間維持及存取狀態 (例如單一登入和同意聲明管理)。
在第一方和第三方受到不同處理的情況下，First-Party Sets 可讓同一實體擁有及操作的相關網域名稱視為第一方。第一方集合中的網域名稱會視為同一個來源，並可標示要在同一個來源情境中設定或傳送哪些 Cookie。目的是在避免第三方跨網站追蹤的同時，維持不會破壞有效用途的路徑。
第一方集合方案目前處於測試階段，請繼續閱讀本文，瞭解這項功能的運作方式和試用方式。
第一方 Cookie 和第三方 Cookie 有何差異？
Cookie 本身並非第一方或第三方，這取決於 Cookie 所屬的目前情境。您可以透過 cookie 標頭中的要求，或透過 JavaScript 中的 document.cookie 來執行這項操作。
舉例來說，如果 video.site 有 theme=dark Cookie，當您瀏覽 video.site 並向 video.site 提出要求時，就屬於同網站情境，且所包含的 Cookie 為第一方。
不過，如果您使用的是 my-blog.site，而該網站為 video.site 嵌入 iframe 播放器，當請求從 my-blog.site 傳送至 video.site 時，就屬於跨網站內容，而 theme Cookie 則屬於「第三方」。
系統會根據 Cookie 的 SameSite 屬性決定是否納入 Cookie：
- 同網站情境搭配
SameSite=Lax、Strict或None，可將 Cookie 設為第一方。 - 使用
SameSite=None的跨網站內容會使 Cookie 成為第三方。
不過，這並非一成不變的規則。假設 brandx.site 是旅遊預訂網站，且使用 fly-brandx.site 和 drive-brandx.site 來區分航班和租車服務。在預訂行程的過程中，訪客會在這些網站之間切換，選擇不同的選項，因此他們希望「購物車」中的選項會在這些網站之間保留。brandx.site 會使用 SameSite=None Cookie 管理使用者的工作階段，以便在跨網站的情況下使用。不過，現在 Cookie 沒有跨網站要求偽造 (CSRF) 保護機制。如果 evil.site 包含對 brandx.site 的要求，就會包含該 Cookie！
雖然 Cookie 是跨網站，但所有網站均由同一家機構擁有及營運。訪客也瞭解這是同一機構，並希望在兩者之間建立相同的工作階段，也就是共用身分。
「第一方集合」政策
第一方集合建議一種方法，可在同一方擁有及營運的多個網站中明確定義這項關係。這可讓 brandx.site 定義與 fly-brandx.site、drive-brandx.site 等的第一方關係。
推動各種 Privacy Sandbox 提案的隱私權模型，是以分割身分概念為基礎，可防止跨網站追蹤，也就是在網站之間劃出界線，限制存取可用於識別使用者的任何資訊。
雖然預設選項是依網站劃分，這可解決許多第一方用途，但 brandx.site 範例顯示第一方可以是多個網站。
「第一方集合」提案的重要部分，是確保跨瀏覽器的政策可防止濫用或誤用行為。舉例來說，第一方集合不得允許在無關網站之間交換使用者資訊，或將不屬於同一實體的網站分組。這項功能的用意在於確保 First-Party Set 對應至使用者認為是第一方的內容，且不會用於在不同對象之間共用身分。
網站註冊第一方組合的其中一種方法，是將建議的網域群組提交至公開追蹤器 (例如專屬的 GitHub 存放區)，並附上符合瀏覽器政策所需的資訊。
一旦根據政策驗證第一方集合斷言，瀏覽器就能透過更新程序擷取集合清單。
原始測試版有明確的政策，但並非最終政策，但原則可能會維持不變：
- 第一方集合中的網域必須由同一機構擁有及經營。
- 使用者應能將這些網域視為一個群組。
- 這些網域應共用相同的隱私權政策。
如何定義第一方集合
找出貴機構第一方集合的成員和擁有者後，請務必提交所提議的集合以供核准。具體程序仍在討論中。
如要宣告第一方集合，請將列出成員和擁有者的靜態 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" }
第一方集合有幾項限制：
- 一個組合只能有一位擁有者。
- 成員只能屬於一個集合，不得重疊或混合。
- 成員清單應保持相對易於人類閱讀，且不宜過大。
First-Party Sets 對 Cookie 有何影響？
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權限。
還有一些額外規定：
SamePartyCookie 必須包含Secure。SamePartyCookie 不得包含SameSite=Strict。
Secure 是必要屬性，因為這仍是跨網站，您應確保安全 (HTTPS) 連線，以降低這些風險。同樣地，由於這是跨網站關係，SameSite=Strict 無效，因為它仍允許在集合內進行嚴格的網站 CSRF 防護。
第一方集合適合哪些用途？
如果機構需要在不同頂層網站之間共用身分，第一方集合就是最佳選擇。在這種情況下，共用身分識別系統指的是任何內容，從完整的單一登入解決方案，到只需要跨網站共用偏好設定。
貴機構可能會為下列項目使用不同的頂層網域：
- 應用程式網域：
office.com、live.com、microsoft.com - 品牌網域：
amazon.com、audible.com/disney.com、pixar.com - 國家/地區專屬網域 (可啟用本地化功能)：
google.co.in、google.co.uk - 服務網域：使用者從未直接與之互動，但可在同一機構的網站上提供服務：
gstatic.com、githubassets.com、fbcdn.net - 沙箱網域：使用者從未直接與之互動，但出於安全性考量而存在的網域：
googleusercontent.com、githubusercontent.com
如何參與？
如果您擁有符合上述條件的網站，可以透過多種方式參與計畫。最輕鬆的方式是閱讀並參與這兩項提案的討論：
在測試階段，您可以使用 --use-first-party-set 指令列旗標，並提供以半形逗號分隔的網站清單，試用這項功能。
您可以使用下列標記啟動 Chrome，然後在示範網站 https://fps-member1.glitch.me/ 上試試這個方法：
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
如果您想在開發環境中進行測試，或是想在實際環境中嘗試新增 SameParty 屬性，以瞭解第一方集合如何影響 Cookie，這項功能就很實用。
如果您有足夠的頻寬進行實驗和提供意見回饋，也可以註冊第一方集合和同黨來源試用，這個功能在 Chrome 第 89 到 93 版中均可使用。
如何更新原始試驗的 Cookie
如果您要加入原始試用計畫，並測試 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 (Cookies Having Independent Partitioned State) 所建議的路徑，可透過 Partitioned 屬性為網站提供選擇加入路徑，讓網站仍可保留這些重要的跨網站嵌入、資源、API 和服務，同時避免跨網站的識別資訊外洩。
以下是其他幾個考量因素，說明您的網站可能不需要設定：
- 您託管的是不同的來源，而不是不同的網站。在上例中，如果
brandx.site有fly.brandx.site和drive.brandx.site，則這些是同一個網站內的不同子網域。Cookie 可以使用SameSite=Lax，且不需要設定。 - 您提供第三方嵌入內容給其他網站。在前言中，
video.site嵌入my-blog.site的影片範例是明顯的第三方區隔。這些網站由不同的機構營運，使用者會將其視為獨立實體。這兩個網站不應同時出現在同一組中。 - 您提供第三方社群登入服務。使用 OAuth 或 OpenId connect 等技術的 ID 提供者，通常會依賴第三方 Cookie，為使用者提供更順暢的登入體驗。這是有效的用途，但由於兩個機構有明顯差異，因此不太適合使用 First-Party Sets。WebID 等早期提案正在探索如何支援這些用途。