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

Phiên bản mới nhất của Nhóm bên thứ nhất đã sẵn sàng cho việc thử nghiệm cờ tính năng dành cho nhà phát triển trên Chrome 108. Chúng tôi đang tích cực phát triển Nhóm bên thứ nhất nhằm hướng đến mục tiêu chuyển sang giai đoạn thử nghiệm dành cho nhà phát triển. Vì vậy, chúng tôi sẽ xem xét ý kiến phản hồi đối với giai đoạn thử nghiệm này của nhà phát triển 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 những 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 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 có chung mối quan hệ có thể được thể hiện với trình duyệt để trình duyệt có thể thực hiện hành động thích hợp thay cho người dùng và/hoặc trình bày thông tin đó cho người dùng một cách hiệu quả.

Đề xuất mới cập nhật này sử dụng 2 API (API Truy cập bộ nhớ và API mới (dự kiến là requestStorageAccessForOrigin) nhằm cung cấp cho các trang web phương thức đang hoạt động để yêu cầu quyền truy cập trên nhiều trang web đối với cookie thuộc Nhóm bên thứ nhất. Hướng dẫn dưới đây sẽ giúp bạn kiểm tra và xác thực những nhóm nào bạn có thể muốn tạo cho các trang web của mình và 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 dành cho 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 nhằm cho phép giới hạn quyền truy cập vào cookie trên nhiều trang web nhằm phục vụ những mục đích cụ thể mà người dùng có thể thấy được. 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 một trang web truy cập vào cookie khi ở trong bối cảnh của bên thứ ba.

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

Để tạo điều kiện cho trình duyệt xử lý từng tập hợp con theo các hàm ý liên quan đến quyền riêng tư của từng tập hợp con, chúng tôi đề xuất tận dụng Storage Access API (SAA) và requestStorageAccessForOrigin để cho phép truy cập vào cookie trong khung hình trên giây.

Khi sử dụng SAA, các trang web có thể chủ động yêu cầu quyền truy cập vào 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 khung hình trên giây. Vui lòng xem tài liệu về Storage Access API (SAA) để biết thông tin về cách các trình duyệt khác xử lý các lệnh gọi đến SAA.

SAA hiện yêu cầu tài liệu này 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 cần cookie. Để giải quyết một số thách thức này, chúng tôi đề xuấ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ử.

Đặt quy trình gửi

Danh sách FPS chính tắc sẽ là một 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, đóng vai trò là nguồn dữ liệu cho tất cả các nhóm. Chrome sẽ sử dụng tệp này để áp dụng cho hành vi của tệp.

Để 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 các bộ, 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 nhằm 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ó sẵn trong các phiên bản Chrome ổn định.

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

Cách thử nghiệm cục bộ

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

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

Để xem trước 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 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 có cờ.

Các bước

Để bật FPS cục bộ, bạn cần sử dụng lựa chọn --enable-features của Chrome cùng 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 nhóm trang web liên quan dưới dạng đối tượng JSON để truyền tới --use-first-party-set.

Bật FPS

FirstPartySets cho phép khung hình trên giây trong Chrome.

FirstPartySets

Bật Storage Access API

StorageAccessAPI

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

Lưu ý rằng khi được gọi, requestStorageAccess() yêu cầu 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 dụng các bộ yêu cầu khác, vì đặc điểm kỹ thuật của SAA vẫn đang phát triển. Tham khảo tại đây để biết danh sách nội dung 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() để yêu cầu quyền truy cập vào bộ nhớ thay cho những nguồn gốc cụ thể. Đ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 một 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 "nhóm chính" và có thể có nhiều "nhóm thành viên". Thành phần của tập hợp có thể bao gồm nhiều loại miền với các tập hợp con dựa trên trường hợp sử dụng.

Tạo đố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, còn associatedSites liệt kê các miền đáp ứng yêu cầu của tập hợp 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\"]}"

Đối với 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 chúng đế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 nào được áp dụng. Tuy nhiên, khi FPS xuất hiện ở phiên bản ổn định, tất cả các tập hợp đều phải được gửi đến kho lưu trữ GitHub về FPS và phải tuân theo các tiêu chí xác thực.

Bật giao diện người dùng FPS (khung hình/giây)

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" trên giao diện người dùng FPS (Cho phép các trang web liên quan xem hoạt động của bạn trong nhóm) trong phần Quyền riêng tư và bảo mật → Cookie và các dữ liệu trang web khác (chrome://settings/cookies).

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

  1. Trong phần cài đặt Chrome, hãy chuyển đến phần Quyền riêng tư và bảo mật → Cookie và các dữ liệu trang web khác hoặc chrome://settings/cookie.
  2. Trong phần Cài đặt chung, hãy đảm bảo rằng bạn đã bật tuỳ chọn "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 nhiều trang web cần phải nhận thức được nguy cơ của CSRF và các cuộc tấn công khác.

Cải tiến theo kế hoạch

Để cải thiện điều này, các bản phát hành Chrome trong tương lai sẽ yêu cầu phải có các biện pháp kiểm soát bảo mật bổ sung, nhằm đảm bảo người dùng có thể chọn sử dụng nhúng một cách rõ ràng. Những điểm cải tiến được đề xuất sẽ: chỉ cấp quyền truy cập trên mỗi khung hình, yêu cầu CORS cho các yêu cầu đã được 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ản phân tích bảo mật gần đây.

Xem danh sách nội dung 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 cookie được đánh dấu SameSite=None trong ngữ cảnh được nhúng trên nhiều trang web, đây là trường hợp có liên quan đến Storage Access API. Tuy nhiên, cho đến khi tất cả trình duyệt không dùng quyền truy cập mặc định vào các cookie đó nữa, thì vẫn không có giả định nào được đưa ra về nơi có thể sử dụng cookie. Việc cho rằng quyền truy cập sẽ chỉ được cho phép trong một khung hình trên giây và các trang web nên tiếp tục áp dụng các phương pháp bảo mật tiêu chuẩn hay nhất.

Thu hút và chia sẻ ý kiến phản hồi

Thử nghiệm cục bộ là cơ hội để bạn dùng thử cơ chế Storage Access API (API Truy cập bộ nhớ) để 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 thử nghiệm quy trình gửi tập hợp 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 thu hút và chia sẻ ý kiến phản hồi về đề xuất mới: