Hướng dẫn kiểm thử Nhóm bên thứ nhất

Phiên bản lặp lại mới nhất của First-Party Sets đã sẵn sàng để thử nghiệm cờ tính năng dành cho nhà phát triển từ Chrome 108. Chúng tôi đang tích cực làm việc trên Nhóm bên thứ nhất với mục tiêu là phát hành. Vì vậy, chúng tôi sẽ xem xét ý kiến phản hồi cho giai đoạn thử nghiệm dành cho nhà phát triển này cho đến khi phát hành Chrome 111 vào đầu tháng 3 (ngày 7 tháng 3 năm 2023).

Ý kiến phản hồi về hệ sinh thái đã nêu bật các trường hợp sử dụng trên nhiều trang web sẽ bị ảnh hưởng khi cookie của bên thứ ba không còn được hỗ trợ trong Chrome. Đề xuất về Nhóm bên thứ nhất kiểm tra và giải quyết một loại trường hợp sử dụng trên nhiều trang web, trong đó các trang web phụ thuộc lẫn nhau có mối quan hệ có thể được thể hiện cho trình duyệt để trình duyệt có thể thay mặt người dùng thực hiện hành động thích hợp và/hoặc trình bày hiệu quả thông tin đó cho người dùng.

Đề xuất mới cập nhật sử dụng hai API (API Truy cập bộ nhớ và một API mới có tên tạm thời là requestStorageAccessForOrigin) để cung cấp cho các trang web một phương thức chủ động yêu cầu quyền truy cập trên nhiều trang web cho cookie của họ trong một Nhóm bên thứ nhất. Hướng dẫn bên dưới sẽ giúp bạn kiểm thử và xác thực những tập hợp mà bạn có thể muốn tạo cho trang web của mình cũng như các điểm phù hợp để gọi hai API khác nhau.

Tổng quan về Nhóm bên thứ nhất

Nhóm bên thứ nhất (FPS) là một cơ chế nền tảng web để nhà phát triển khai báo mối quan hệ giữa các trang web, nhờ đó, trình duyệt có thể sử dụng thông tin này để cho phép quyền truy cập cookie có giới hạn trên nhiều trang web cho các mục đích cụ thể dành cho người dùng. Chrome sẽ sử dụng các mối quan hệ đã khai báo này để quyết định thời điểm cho phép hoặc từ chối quyền truy cập của một trang web vào cookie của họ khi ở trong ngữ cảnh của bên thứ ba.

Nói chung, Nhóm bên thứ nhất là một tập hợp các miền, trong đó có một "miền chính" và có thể có nhiều "thành viên của nhóm". Chỉ tác giả trang web mới có thể gửi miền của họ vào một tập hợp và họ sẽ phải khai báo mối quan hệ giữa mỗi "thành phần của tập hợp" với "thành phần chính của tập hợp". Thành phần của tập hợp có thể bao gồm nhiều loại miền khác nhau với các tập hợp con dựa trên trường hợp sử dụng.

Để hỗ trợ trình duyệt xử lý từng tập hợp con theo các tác động về quyền riêng tư của từng tập hợp con, chúng tôi đề xuất tận dụng API truy cập bộ nhớ (SAA) và requestStorageAccessForOrigin để bật quyền truy cập cookie trong một FPS.

Với SAA, các trang web có thể chủ động yêu cầu quyền truy cập cookie trên nhiều trang web. Chrome sẽ tự động cấp yêu cầu nếu trang web yêu cầu và trang web cấp cao nhất có cùng FPS. Vui lòng xem tài liệu về API Truy cập bộ nhớ (SAA) để biết thông tin về cách các trình duyệt khác xử lý lệnh gọi đến SAA.

SAA hiện yêu cầu tài liệu phải được người dùng kích hoạt trước khi gọi các phương thức của API.

Điều này có thể khiến việc áp dụng FPS trở nên khó khăn đối với các trang web cấp cao nhất sử dụng hình ảnh trên nhiều trang web hoặc thẻ tập lệnh yêu cầu cookie. Để giải quyết một số thách thức này, chúng tôi đã đề xuất một API mới, requestStorageAccessForOrigin, để giúp nhà phát triển dễ dàng áp dụng thay đổi này. Bạn cũng có thể dùng API này để kiểm thử.

Thiết lập tính năng gửi

Danh sách FPS chuẩn sẽ là danh sách có thể xem công khai ở định dạng tệp JSON, nằm trong kho lưu trữ GitHub về FPS mới. Danh sách này sẽ đóng vai trò là nguồn đáng tin cậy cho tất cả các bộ. Chrome sẽ sử dụng tệp này để áp dụng cho hành vi của nó.

Để tìm hiểu thêm về quy trình đề xuất và các yêu cầu đối với việc gửi bộ sách, hãy xem nguyên tắc gửi. Bạn cũng có thể thử gửi một tập hợp để kiểm tra các bước kiểm tra kỹ thuật khác nhau sẽ xác thực nội dung gửi. Xin lưu ý rằng tất cả nội dung gửi sẽ bị xoá trước khi FPS có trong các phiên bản Chrome ổn định.

Vì quy trình gửi tập hợp vẫn đang trong quá trình phát triển, nên để kiểm thử cục bộ, bạn chỉ có thể tạo tập hợp trên dòng lệnh và chuyển trực tiếp các tập hợp đó đến trình duyệt. Đối với kiểm thử cục bộ, bạn không cần phải gửi một tập hợp vào kho lưu trữ GitHub để kiểm thử bằng cờ tính năng.

Cách kiểm thử cục bộ

Điều kiện tiên quyết

Để kiểm thử FPS cục bộ, hãy sử dụng Chrome 108 trở lên được chạy từ dòng lệnh.

Để dùng thử các tính năng sắp ra mắt của Chrome trước khi phát hành, hãy tải phiên bản Beta hoặc Canary của Chrome xuống.

Ví dụ:

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\"]}" \

Tìm hiểu thêm về cách chạy Chromium bằng cờ.

Các bước

Để bật FPS cục bộ, bạn cần sử dụng tuỳ chọn --enable-features của Chrome với danh sách cờ được phân tách bằng dấu phẩy được giải thích trong phần này và khai báo một tập hợp các trang web có liên quan dưới dạng đối tượng JSON để truyền đến --use-first-party-set.

Bật FPS

FirstPartySets bật FPS trong Chrome.

FirstPartySets

Bật Storage Access API

StorageAccessAPI

Bật Storage Access API (SAA) trong Chrome. API này cho phép các iframe được nhúng sử dụng requestStorageAccess() để yêu cầu quyền truy cập vào cookie trong ngữ cảnh trên nhiều trang web, ngay cả khi trình duyệt chặn cookie của bên thứ ba.

Xin lưu ý rằng khi được gọi, requestStorageAccess() yêu cầu một cử chỉ của người dùng để phân giải. Các phiên bản Chrome trong tương lai có thể áp đặt nhiều bộ yêu cầu khác nhau, vì thông số kỹ thuật SAA vẫn đang phát triển. Hãy tham khảo tại đây để biết danh sách các điểm cải tiến theo kế hoạch đối với việc triển khai SAA của Chrome.

StorageAccessAPIForOriginExtension

Cho phép các trang web cấp cao nhất sử dụng requestStorageAccessForOrigin() để thay mặt cho các nguồn gốc cụ thể yêu cầu quyền truy cập vào bộ nhớ. Điều này hữu ích cho các trang web cấp cao nhất sử dụng hình ảnh trên nhiều trang web hoặc thẻ tập lệnh yêu cầu cookie và giải quyết một số thách thức khi áp dụng SAA.

Khai báo tập hợp cục bộ

Nhóm bên thứ nhất là một tập hợp các miền, trong đó có một "miền chính" và có thể có nhiều "thành viên của nhóm". Thành phần của tập hợp có thể bao gồm nhiều loại miền khác nhau với các tập hợp con dựa trên trường hợp sử dụng.

Tạo một đối tượng JSON chứa các URL là thành viên của một tập hợp và truyền đối tượng đó đến --use-first-party-set.

Trong ví dụ bên dưới, primary liệt kê miền chính và associatedSites liệt kê các miền đáp ứng yêu cầu của nhóm con được liên kết.

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

Ví dụ:

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

Để kiểm thử cục bộ, bạn chỉ có thể tạo các tập hợp trên dòng lệnh và truyền trực tiếp các tập hợp đó đến trình duyệt. Đối với mục đích kiểm thử cục bộ, sẽ không có quy trình xác thực tập hợp, nhưng khi FPS được phân phối trong các phiên bản ổn định, tất cả tập hợp sẽ cần được gửi đến kho lưu trữ GitHub của FPS và tuân theo các tiêu chí xác thực.

Bật giao diện người dùng FPS

PageInfoCookiesSubpage

Cho phép hiển thị FPS trong phần PageInfo có thể truy cập được từ thanh URL.

PrivacySandboxFirstPartySetsUI

Bật tuỳ chọn "Cho phép các trang web liên quan xem hoạt động của bạn trong nhóm" trong giao diện người dùng FPS trong phần Quyền riêng tư và bảo mật → Cookie và các dữ liệu khác của trang web (chrome://settings/cookies) trong phần cài đặt của Chrome.

Xác minh rằng bạn đã chặn cookie của bên thứ ba

  1. Trong phần cài đặt của Chrome, hãy chuyển đến Quyền riêng tư và bảo mật → Cookie và các dữ liệu khác của trang web hoặc chrome://settings/cookies.
  2. Trong phần Cài đặt chung, hãy đảm bảo bạn đã bật chế độ "Chặn cookie của bên thứ ba".
  3. Kiểm tra để đảm bảo bạn cũng đã bật tuỳ chọn phụ "Cho phép các trang web liên quan xem hoạt động của bạn trong nhóm".

Lưu ý về bảo mật

Vì Storage Access API cho phép các trang web lấy lại quyền truy cập vào cookie của bên thứ ba trong một số trường hợp, nên API này có thể khiến các ứng dụng web dễ bị tấn công trên nhiều trang web và rò rỉ thông tin. Các trang web dựa vào cookie trong ngữ cảnh trên nhiều trang web cần lưu ý đến các rủi ro của CSRF và các cuộc tấn công khác.

Các điểm cải tiến theo kế hoạch

Để cải thiện vấn đề này, các bản phát hành Chrome trong tương lai sẽ yêu cầu thêm các biện pháp kiểm soát bảo mật, nhằm đảm bảo người dùng chọn sử dụng tính năng nhúng một cách rõ ràng. Các điểm cải tiến được đề xuất sẽ: chỉ cấp quyền truy cập trên cơ sở mỗi khung, yêu cầu CORS đối với các yêu cầu có thông tin xác thực và chỉ giữ phạm vi truy cập vào nguồn gốc. Bạn có thể đọc thêm trong bài phân tích bảo mật gần đây.

Hãy xem danh sách các điểm cải tiến theo kế hoạch đối với việc triển khai SAA của Chrome.

Xin lưu ý rằng Chrome chỉ gửi các cookie được đánh dấu là SameSite=None trong ngữ cảnh nhúng trên nhiều trang web, đây là nơi Storage Access API có liên quan. Tuy nhiên, cho đến khi tất cả trình duyệt ngừng sử dụng quyền truy cập mặc định vào các cookie đó, bạn không thể giả định về vị trí có thể sử dụng cookie. Bạn không nên giả định rằng quyền truy cập chỉ được cho phép trong một FPS và các trang web nên tiếp tục sử dụng các phương pháp hay nhất về bảo mật tiêu chuẩn.

Tham gia và chia sẻ ý kiến phản hồi

Kiểm thử cục bộ là cơ hội để thử nghiệm cơ chế Storage Access API nhằm bật FPS và chia sẻ ý kiến phản hồi hoặc mọi vấn đề bạn gặp phải. Ngoài ra, việc kiểm thử quy trình gửi bộ trên GitHub là cơ hội để bạn chia sẻ trải nghiệm của mình về quy trình và các bước xác thực. Cách tương tác và chia sẻ ý kiến phản hồi về đề xuất đã cập nhật: