First-Party Sets 測試操作說明

最新版第一方集合已可執行 Chrome 108 的開發人員功能旗標測試。我們正積極研擬第一方集合，希望日後能繼續推出產品。因此，在 Chrome 111 於 3 月初 (2023 年 3 月 7 日) 上推出之前，我們會考慮針對這個階段的開發人員測試提供意見回饋。

生態系統意見回饋指出，Chrome 不再支援第三方 Cookie 後，這些跨網站的用途將受到影響。第一方集合提案會檢查並解決跨站不同用途的類別，其中跨網站使用可向瀏覽器表達的關係，並讓瀏覽器能代表使用者採取適當行動，並/或有效地將該項資訊提供給使用者。

更新後的提案會使用兩個 API (儲存空間存取 API 和名為 requestStorageAccessForOrigin 的新 API)，在第一方集合中主動為網站要求跨網站存取權。不妨按照以下操作說明進行，確認想要為網站建立哪個組合，以及呼叫這兩種不同 API 的正確要點。

第一方集合總覽

第一方集合 (FPS) 是一種網路平台機制，可讓開發人員宣告網站間的關係，讓瀏覽器能根據這項資訊，針對面向使用者的特定用途，使用有限的跨網站 Cookie 存取功能。Chrome 會根據這些聲明的關係，決定何時允許或拒絕網站在第三方環境中存取 Cookie。

概括而言，第一方集合是網域集合，其中只有一個「設定主要」，且可能包含多個「設定成員」。只有網站作者能夠將網域提交至集合，且必須宣告每個「設定成員」與「設定主要項目」之間的關係。設定成員可以包含各種不同的網域類型，並根據用途進行子集。

為了協助瀏覽器根據每個子集的隱私權影響處理每個子集，我們建議利用 Storage Access API (SAA) 和 requestStorageAccessForOrigin 等每秒擷取 Cookie 存取。

使用 SAA 時，網站可能會主動要求跨網站 Cookie 存取權。如果提出要求的網站和頂層網站每秒影格數相同，Chrome 就會自動核准這項要求。如要瞭解其他瀏覽器如何處理 SAA 呼叫，請參閱 Storage Access API (SAA) 說明文件。

SAA 目前要求文件必須先取得使用者啟動，才能呼叫 API 的方法。

因此，如果頂層網站使用跨網站圖片或需要 Cookie 的指令碼代碼，就可能會難以採用 FPS。為了解決部分挑戰，我們提議推出新的 API requestStorageAccessForOrigin，方便開發人員輕鬆採用這項變更。這個 API 也可用於測試。

設定提交內容

標準 FPS 清單是採用 JSON 檔案格式的公開清單，儲存在新的 FPS GitHub 存放區中，可做為所有集合的可靠資料來源。Chrome 會使用這個檔案來套用行為。

如要進一步瞭解提議的提交程序和提交組合的相關規定，請參閱提交規範。您也可以嘗試提交組合，測試各種技術檢查來驗證提交內容。請注意，在 Chrome 穩定版提供 FPS 之前，所有提交的內容都會遭到清除。

由於組合提交程序仍處於開發階段，因此如要在本機測試中，您只能透過指令列建立集合，再將其直接傳遞至瀏覽器。針對本機測試，您無須提交集到 GitHub 存放區，就能測試功能旗標。

如何在本機測試

必備條件

如要在本機測試每秒影格數，請使用從指令列啟動的 Chrome 108 以上版本。

如要在 Chrome 新功能發布前搶先體驗，請下載 Chrome 的 Beta 版或初期測試版本版本。

範例

google-chrome \
--enable-features="FirstPartySets,StorageAccessAPI,StorageAccessAPIForOriginExtension,PageInfoCookiesSubpage,PrivacySandboxFirstPartySetsUI" \
--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}" \

進一步瞭解如何使用旗標執行 Chromium。

操作步驟

如要在本機啟用每秒影格數，您必須使用 Chrome 的 --enable-features 選項，並搭配本節中說明的旗標清單使用，並宣告一組相關網站做為 JSON 物件，再傳遞至 --use-first-party-set。

啟用每秒影格數

FirstPartySets 可在 Chrome 中啟用每秒影格數。

FirstPartySets

啟用 Storage Access API

StorageAccessAPI

在 Chrome 中啟用 Storage Access API (SAA)，讓嵌入的 iframe 使用 requestStorageAccess() 要求在跨網站環境中存取 Cookie (即使瀏覽器封鎖了第三方 Cookie)。

請注意，呼叫 requestStorageAccess() 時，需要使用者手勢才能解析。由於 SAA 規範仍在不斷演變，日後的 Chrome 版本可能會採用不同的規定組合。如要查看 Chrome 導入 SAA 的預計改善項目清單，請參閱這裡。

StorageAccessAPIForOriginExtension

允許頂層網站使用 requestStorageAccessForOrigin() 代表特定來源要求儲存空間存取權。對於使用跨網站圖片或指令碼代碼的頂層網站，這項功能相當實用，並且解決採用 SAA 的部分難題。

在本機宣告集合

第一方集合是一組網域，在此當中只有一個「設定主要組合」，而且可能包含多個「設定成員」。設定成員可以包含各種不同的網域類型，並根據用途進行子集。

建立內含集合中網址的 JSON 物件，並將其傳送至 --use-first-party-set。

在以下範例中，primary 會列出主網域，associatedSites 則會列出符合相關子集規定的網域。

{
     "primary": "https://primary.com",
    "associatedSites": ["https://associate1.com", "https://associate2.com", "https://associate3.com"]
}

示例：

--use-first-party-set="{\"primary\": \"https://first-party-sets.glitch.me\", \"associatedSites\": [\"https://fps-member-1.glitch.me\"]}"

如要進行本機測試，您只能透過指令列建立集合，再將其直接傳遞至瀏覽器。本機測試作業不會設定任何驗證機制，但當 FPS 發布在穩定版時，所有集合都必須提交至 FPS GitHub 存放區，並且符合驗證條件。

啟用 FPS UI

PageInfoCookiesSubpage

啟用從網址列存取的 PageInfo 部分顯示每秒影格數。

PrivacySandboxFirstPartySetsUI

在 Chrome 設定的「隱私權與安全性」→「Cookie 和其他網站資料」(chrome://settings/cookies) 下，啟用 FPS UI 的「允許相關網站查看你在群組中的活動」選項。

確認第三方 Cookie 是否遭到封鎖

  1. 在 Chrome 設定中，依序前往「隱私權與安全性」→「Cookie 和其他網站資料」或 chrome://settings/cookies。
  2. 確認「一般設定」下的「封鎖第三方 Cookie」已啟用。
  3. 確認「允許相關網站查看您在群組中的活動」子選項已啟用。

安全性考量

由於 Storage Access API 允許網站在特定情況下重新取得第三方 Cookie 的存取權，因此可能使網頁應用程式容易遭受跨網站攻擊和資訊外洩。如果網站仰賴跨網站結構定義中的 Cookie，應注意 CSRF 和其他攻擊的風險。

預計改善措施

為了改善這一點，日後的 Chrome 版本將需要額外的安全性控制項，而我們的目標是確保使用者選擇使用明確的嵌入功能。建議的改進措施包括：僅針對每個影格授予存取權、需要 CORS 用於憑證的要求，以及僅保留來源的存取權範圍。詳情請參閱近期安全性分析。

請參閱 Chrome 預計改善項目清單，瞭解 Chrome 對 SAA 的實作方式。

請注意，Chrome 只會在跨網站嵌入式結構定義中傳送標示為 SameSite=None 的 Cookie，而這與 Storage Access API 具有關聯性。在此之前，在所有瀏覽器皆不再對這些 Cookie 的預設存取機制前，您無法針對 Cookie 的使用位置做出假設。假設存取只能在每秒影格數內存取，並不安全，網站應持續採用標準安全性最佳做法。

互動並提供意見

本機測試可讓您試用 Storage Access API 機制來啟用每秒影格數，並提供意見回饋或任何遇到的問題。此外，您可以在 GitHub 上測試組合提交程序，也可以藉此機會和程序和驗證步驟分享經驗。如何參與新版提案並提供意見：