許多機構擁有網域名稱不同的相關網站 (例如 brandx.site 和 fly-brandx.site)，或是不同國家/地區的網域，例如 example.com、example.rs、example.co.uk 等。
瀏覽器正逐漸淘汰第三方 Cookie 來改善網路隱私，但這類網站通常會仰賴 Cookie 來提供需要跨網域維護及存取狀態的功能 (例如單一登入和同意聲明管理)。
第一方集合可允許同一實體擁有及營運的相關網域名稱，在第一方和第三方的處理方式不同的情況下視為第一方。第一方集合的網域名稱會被視為「同一方」，並可為哪些 Cookie 標示在相同的第一方情境中進行設定或傳送。目標是在防止第三方跨網站追蹤，同時維持不會破壞有效用途的路徑。
第一方集合提案目前處於測試階段，請繼續閱讀下文，瞭解這項功能的運作方式和試用方法。
第一方和第三方 Cookie 有何不同？
Cookie 通常不是第一方或第三方，取決於加入 Cookie 的目前情境。情況是透過 cookie 標頭中的要求，或是在 JavaScript 中透過 document.cookie 發出。
舉例來說，如果您瀏覽 video.site 且向 video.site 發出要求，video.site 含有 theme=dark Cookie，那麼即屬於同網站結構定義，包含的 Cookie 為第一方。
不過，如果您使用嵌入 video.site 的 iframe 播放器的 my-blog.site，當要求從 my-blog.site 到 video.site 是跨網站結構定義，而 theme Cookie 是第三方 Cookie。
納入 Cookie 取決於 Cookie 的 SameSite 屬性：
- 如果使用
SameSite=Lax、Strict或None的相同網站情境，Cookie 就會成為第一方 Cookie。 - 如果使用
SameSite=None的「跨網站環境」，Cookie 就變成第三方 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 範例顯示第一方可規模大於單一網站。
第一方集合提案中的一個重要環節，是確保跨瀏覽器的政策能防止濫用或濫用。例如，第一方集合不得允許跨不相關網站交換使用者資訊，也不得將非相同實體擁有的網站分門別類。其做法是確保第一方集合對應到使用者認為第一方，而非跨方共用身分的方式。
網站註冊第一方集合的可行方法，可能是讓網站將提議的網域群組提交到公開追蹤程式 (例如專屬的 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" }
第一方集合有一些限制：
- 資源集只能有一位擁有者。
- 一名成員只能屬於一個組合，不能重疊或混用。
- 成員清單旨在保持易讀易懂，且不會過大。
第一方集合對 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 的影響，這項功能就很實用。
如果您有實驗和意見回饋的頻寬，也可以註冊第一方集合和 SameParty 的版本，這項服務適用於 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 (具有獨立分區狀態的 Cookie) 提議的路徑，可讓網站透過 Partitioned 屬性提供選擇加入路徑，讓網站保有這些重要的跨網站嵌入、資源、API 和服務，同時防止網站之間的識別資訊外洩。
以下幾個注意事項代表網站或許不需要經過設定，可能沒有問題：
- 您代管網站，而不是不同的網站，在上述範例中，如果
brandx.site有fly.brandx.site和drive.brandx.site，則這兩個子網域是同一個網站內的不同子網域。Cookie 可以使用SameSite=Lax，您不必進行設定。 - 您提供第三方嵌入至其他網站。在簡介中，從
my-blog.site嵌入的video.site影片範例是明確的第三方分隔。網站由不同的機構經營，對使用者而言，是不同的實體。這兩個網站不應放在一起集中。 - 您提供第三方社群登入服務。使用 OAuth 或 OpenId 連線等功能的識別資訊提供者通常仰賴第三方 Cookie，讓使用者享有更順暢的登入體驗。這是有效的用途，但因為組織上存在明顯差異，因此不適合第一方集合。早期提案 (例如 WebID) 正在探索如何啟用這些用途。