Trước đây, cookie của bên thứ ba được dùng để lưu trữ và truyền đạt thông tin về trạng thái của người dùng, chẳng hạn như trạng thái đăng nhập, thông tin về thiết bị họ đang sử dụng hay liệu chúng có được biết đến và đáng tin cậy hay không. Ví dụ: cho dù người dùng đã đăng nhập bằng SSO, cho dù người dùng có thiết bị hoặc liệu người dùng có được biết và đáng tin cậy không. Bằng Ngừng hỗ trợ cookie của bên thứ ba, nhiều trường hợp sử dụng này cần được hỗ trợ bằng các phương tiện khác.
Mã thông báo trạng thái riêng tư cung cấp một cách thức để chia sẻ thông tin trên web, nhưng trong một cách bảo đảm quyền riêng tư thông qua việc kiểm soát lượng dữ liệu có thể được chia sẻ.
Mã thông báo trạng thái riêng tư (trước đây gọi là Mã thông báo tin cậy) cho phép người dùng tin tưởng tính chân thực được truyền tải từ bối cảnh này sang bối cảnh khác đồng thời giúp các trang web chống hành vi gian lận và phân biệt bot với người thật mà không cần theo dõi thụ động.
Tài liệu này trình bày các chi tiết kỹ thuật để triển khai Trạng thái riêng tư Mã thông báo (PST). Để biết thêm về bố cục, hãy xem Tổng quan về PST.
Mã thông báo trạng thái riêng tư hoạt động như thế nào?
Mối quan hệ chính cần hiểu theo giờ PST là giữa bên phát hành và người đổi thưởng. Bên phát hành và bên sử dụng ưu đãi có thể thuộc cùng một công ty.
- Nhà phát hành – Những thực thể này có một số tín hiệu về người dùng (cho ví dụ: liệu người dùng đó có phải là bot hay không) và nhúng tín hiệu đó vào một được lưu trữ trên thiết bị của người dùng (thông tin chi tiết trong các phần tiếp theo).
- Người sử dụng – Những thực thể này có thể không có tín hiệu về người dùng nhưng cần biết thông tin gì đó về họ (ví dụ: liệu người dùng đó có phải là bot không hoặc không) và yêu cầu sử dụng mã thông báo từ tổ chức phát hành để nắm được độ tin cậy của người dùng đó.
Mọi hoạt động tương tác theo giờ PST yêu cầu bên phát hành và bên đổi thưởng phải làm việc cùng nhau để chia sẻ trên web. Đó là những giá trị thô, không được nêu chi tiết đủ để xác định danh tính của các cá nhân.
Mã thông báo trạng thái riêng tư có phù hợp với tôi không?
Những công ty đưa ra quyết định về sự tin cậy và muốn cung cấp thông tin đó có sẵn trong nhiều ngữ cảnh có thể hưởng lợi từ PST. Để biết thêm thông tin về các trường hợp sử dụng tiềm năng của PST, xem tài liệu của chúng tôi về các trường hợp sử dụng PST.
Phát hành và sử dụng mã thông báo
Việc triển khai PST diễn ra theo ba giai đoạn:
- Phát hành mã thông báo
- Đổi mã thông báo
- Chuyển tiếp hồ sơ đổi thưởng
Trong giai đoạn đầu tiên, mã thông báo được phát hành cho trình duyệt (thường là sau khi một số loại mã xác thực). Ở giai đoạn 2, một pháp nhân khác sẽ đưa ra yêu cầu sử dụng mã thông báo đã được phát hành để đọc giá trị trong mã thông báo đó. Trong trận chung kết thì bên sử dụng ưu đãi sẽ nhận được hồ sơ đổi thưởng (RR) với giá trị có trong mã thông báo. Sau đó, bên đổi thưởng đó có thể sử dụng hồ sơ đó làm chứng thực người dùng đó cho nhiều mục đích.
Xác định chiến lược mã thông báo
Để xác định chiến lược mã thông báo, bạn cần hiểu các khái niệm chính về PST (mã thông báo) và hồ sơ sử dụng), các biến, hành vi và giới hạn để có thể hãy suy nghĩ về cách sử dụng tiềm năng trong trường hợp sử dụng của bạn.
Mã thông báo và bản ghi sử dụng ưu đãi: chúng có mối quan hệ gì?
Mỗi thiết bị có thể lưu trữ tối đa 500 mã thông báo cho mỗi trang web và công ty phát hành cấp cao nhất. Ngoài ra, mỗi mã thông báo đều có siêu dữ liệu cho biết khoá nào được nhà phát hành dùng để phát hành khoá đó. Đó thông tin có thể được sử dụng để quyết định có sử dụng hay không sử dụng mã trong quá trình sử dụng của chúng tôi. Dữ liệu PST được trình duyệt lưu trữ nội bộ trên thiết bị của người dùng và chỉ có thể truy cập bằng PST API.
Khi mã thông báo được sử dụng, Hồ sơ đổi thưởng (RR) sẽ được lưu trữ trên thiết bị. Bộ nhớ này đóng vai trò là bộ nhớ đệm cho các lần đổi thưởng trong tương lai. Giới hạn là hai việc sử dụng mã thông báo mỗi 48 giờ, theo từng thiết bị, trang và tổ chức phát hành. Quy trình sử dụng mới khi có thể, các lệnh gọi sẽ sử dụng RR được lưu vào bộ nhớ đệm, thay vì gửi yêu cầu đến nhà phát hành.
- Mã thông báo mới được phát hành (tối đa 500 mã cho mỗi tổ chức phát hành, trang web và thiết bị).
- Tất cả mã thông báo đều được lưu trữ trên kho lưu trữ mã thông báo trên thiết bị (tương tự như cửa hàng cookie).
- Nếu không tìm thấy RR đang hoạt động nào, thì RR mới có thể được tạo sau khi phát hành (tối đa 2 lần mỗi 48 giờ).
- RR được coi là đang hoạt động cho đến khi hết hạn và sẽ được dùng làm mã bộ nhớ đệm.
- Các lệnh gọi sử dụng ưu đãi mới sẽ được nhấn vào bộ nhớ đệm cục bộ (không tạo RR mới).
Sau khi xác định trường hợp sử dụng, bạn phải xác định cẩn thận vòng đời của RR điều này sẽ xác định số lần bạn có thể sử dụng chúng trong trường hợp.
Hãy đảm bảo bạn hiểu rõ các hành vi và biến quan trọng sau đây trước xác định chiến lược của bạn:
| Biến / hành vi | Mô tả | Mức sử dụng tiềm năng |
|---|---|---|
| Siêu dữ liệu về khoá mã thông báo | Mỗi mã thông báo có thể được phát hành bằng cách sử dụng một và chỉ một khoá mã hoá và trong PST, mỗi tổ chức phát hành giới hạn 6 khoá. | Một cách tiềm năng để sử dụng biến này là xác định phạm vi độ tin cậy vào mã thông báo dựa trên khoá mã hoá của bạn (ví dụ: khoá 1 = có độ tin cậy cao trong khi khoá 6 = không có độ tin cậy). |
| Ngày hết hạn của mã thông báo | Ngày hết hạn của mã thông báo giống với ngày hết hạn của khoá. | Bạn có thể xoay vòng khoá ít nhất 60 ngày một lần và mọi mã được cấp bằng khoá không hợp lệ cũng bị coi là không hợp lệ. |
| Giới hạn tỷ lệ sử dụng mã thông báo | Mỗi thiết bị và nhà phát hành chỉ được sử dụng hai mã thông báo 48 giờ. | Phụ thuộc vào số lượt đổi thưởng ước tính theo yêu cầu của bạn mỗi 48 giờ. |
| Số lượng nhà phát hành tối đa trên mỗi điểm khởi hành cấp cao nhất | Số lượng nhà phát hành tối đa trên mỗi nguồn gốc cấp cao nhất hiện là 2. | Hãy xác định kỹ nhà phát hành mỗi trang. |
| Số mã thông báo cho mỗi nhà phát hành trên thiết bị | Số lượng mã thông báo tối đa cho mỗi nhà phát hành trên một thiết bị cụ thể hiện là 500. | Đảm bảo số lượng mã thông báo của mỗi tổ chức phát hành ít hơn 500. Đảm bảo xử lý các lỗi trên trang web của bạn khi cố gắng khắc phục vấn đề mã thông báo. |
| Xoay vòng cam kết chính | Mọi nhà phát hành PST đều phải cung cấp một điểm cuối có khoá cam kết có thể thay đổi 60 ngày một lần và xoay vòng bất kỳ nhanh hơn so với giá trị đó sẽ bị bỏ qua. | Nếu khoá của bạn sẽ hết hạn trong vòng dưới 60 ngày thì bắt buộc để cập nhật các cam kết chính của bạn trước ngày đó nhằm tránh bị gián đoạn (xem chi tiết). |
| Thời gian tồn tại của hồ sơ đổi thưởng | Vòng đời của RR có thể được xác định để xác định thời điểm hết hạn ngày. Vì RR được lưu vào bộ nhớ đệm để tránh các lệnh gọi đổi thưởng mới không cần thiết đối với tổ chức phát hành, điều này rất quan trọng để đảm bảo rằng thông tin đó tín hiệu đổi thưởng. | Vì có giới hạn tỷ lệ sử dụng là hai mã thông báo mỗi 48 giờ, bạn cần xác định vòng đời của RR để có thể thực thi lệnh gọi sử dụng ưu đãi thành công ít nhất trong khoảng thời gian này (RR) tuổi thọ phải được đặt tương ứng). Bạn nên đặt giá trị này tuổi thọ theo thứ tự tuần. |
Trường hợp ví dụ
Trường hợp 1: Thời gian tồn tại của RR dưới 24 giờ (t=t) và việc sử dụng ưu đãi là thực hiện nhiều lần trong khoảng thời gian 48 giờ.
Trường hợp 2: Thời gian tồn tại của RR là 24 giờ và quá trình sử dụng ưu đãi đã được tiến hành nhiều lần trong khung thời gian 48 giờ.
Tình huống 3: Thời gian tồn tại của RR là 48 giờ và quá trình sử dụng ưu đãi đã được tiến hành nhiều lần trong khoảng thời gian 48 giờ.
Chạy bản minh hoạ
Trước khi áp dụng PST, bạn nên thiết lập bản minh hoạ trước. Để dùng thử bản minh hoạ PST , bạn sẽ cần chạy Chrome có cờ để bật trình phát hành bản minh hoạ các cam kết chính (làm theo hướng dẫn có trong bản minh hoạ ).
Bằng cách chạy bản minh hoạ này, trình duyệt của bạn đang sử dụng nhà phát hành bản minh hoạ và người đổi thưởng máy chủ để cung cấp và sử dụng mã thông báo.
Những điểm cần lưu ý về mặt kỹ thuật
Bản minh hoạ sẽ hoạt động hiệu quả nhất nếu bạn triển khai các bước sau:
- Đảm bảo bạn dừng mọi phiên bản Chrome trước khi chạy Chrome bằng cờ.
- Nếu bạn đang chạy trên máy tính chạy Windows, hãy xem vào hướng dẫn này về cách truyền tham số tới tệp nhị phân thực thi của Chrome.
- Mở Công cụ của Chrome cho nhà phát triển trong Ứng dụng > Bộ nhớ > Trạng thái riêng tư Mã thông báo trong khi sử dụng ứng dụng minh hoạ để xem số mã thông báo đã phát hành/đã sử dụng mà nhà phát hành bản minh hoạ đưa ra.
Thiết lập để áp dụng
Trở thành tổ chức phát hành
Tổ chức phát hành đóng vai trò quan trọng trong giờ PST. Chúng chỉ định giá trị cho các mã thông báo để xác định liệu người dùng có phải là bot hay không. Nếu bạn muốn bắt đầu với PST với tư cách là nhà phát hành, bạn cần đăng ký bằng cách hoàn tất Quy trình đăng ký công ty phát hành thẻ.
Để đăng ký trở thành một tổ chức phát hành, nhà cung cấp dịch vụ trên trang web của công ty phát hành phải mở một vấn đề trên GitHub bằng cách sử dụng "PST mới" Tổ chức phát hành" mẫu. Làm theo hướng dẫn trên kho lưu trữ để điền vào vấn đề. Sau khi được xác minh, điểm cuối sẽ được hợp nhất vào kho lưu trữ này và Cơ sở hạ tầng phía máy chủ của Chrome sẽ bắt đầu tìm nạp các khoá đó.
Máy chủ của tổ chức phát hành
Bên phát hành và bên sử dụng ưu đãi là các đối tượng chính của PST; Máy chủ và mã thông báo là chìa khoá cho PST. Mặc dù chúng tôi đã cung cấp một số chi tiết về mã thông báo và trong Tài liệu GitHub, chúng tôi muốn cung cấp thêm chi tiết trên máy chủ PST. Để thiết lập với tư cách là nhà phát hành PST, bạn cần để thiết lập một máy chủ phát hành trước tiên.
Triển khai môi trường: máy chủ của nhà phát hành
Để triển khai máy chủ của nhà phát hành mã thông báo, bạn cần tạo phía máy chủ của riêng mình ứng dụng hiển thị điểm cuối HTTP.
Thành phần nhà phát hành bao gồm hai mô-đun chính: (1) máy chủ của nhà phát hành và (2) bên phát hành mã thông báo.
Giống như mọi ứng dụng giao diện web, chúng tôi đề xuất thêm một lớp bảo vệ đến máy chủ của nhà phát hành.
Máy chủ phát hành: Trong quá trình triển khai mẫu, máy chủ phát hành là Máy chủ Node.js sử dụng khung Express để lưu trữ Điểm cuối HTTP của nhà phát hành. Bạn có thể xem mã mẫu trên GitHub.
Nhà phát hành mã thông báo: Thành phần mật mã của nhà phát hành không yêu cầu bất kỳ ngôn ngữ cụ thể nhưng do yêu cầu về hiệu suất của thành phần này, chúng tôi đưa ra ví dụ về triển khai C, trong đó sử dụng lệnh Nhàm chán SSL để quản lý mã thông báo. Bạn có thể tìm ví dụ về mã phát hành và thông tin khác về cách cài đặt trên GitHub
Khoá: Thành phần tổ chức phát hành mã thông báo sử dụng khoá EC tuỳ chỉnh để mã hoá mã thông báo. Các khoá này phải được bảo vệ và lưu trữ trong bộ nhớ an toàn.
Yêu cầu kỹ thuật đối với máy chủ của nhà phát hành
Theo giao thức, bạn sẽ cần triển khai ít nhất 2 điểm cuối HTTP trong máy chủ của công ty phát hành thẻ:
- Cam kết khoá (ví dụ:
/.well-known/private-state-token/key-commitment): Điểm cuối này là nơi trình duyệt sẽ cung cấp thông tin về khoá công khai được mã hoá của bạn để xác nhận máy chủ của bạn là hợp pháp. - Phát hành mã thông báo (ví dụ:
/.well-known/private-state-token/issuance): Điểm cuối phát mã thông báo, nơi tất cả yêu cầu về mã thông báo sẽ được xử lý. Chiến dịch này điểm cuối sẽ là điểm tích hợp cho thành phần của nhà phát hành mã thông báo.
Như đã đề cập trước đó, do lưu lượng truy cập dự kiến cao, máy chủ này sẽ có thể xử lý được, chúng tôi khuyên bạn nên triển khai nó bằng cách sử dụng cơ sở hạ tầng (ví dụ: trong môi trường đám mây) để có thể điều chỉnh dựa trên nhu cầu thay đổi.
Gửi cuộc gọi đến máy chủ của nhà phát hành
Triển khai lệnh gọi tìm nạp trang web tới ngăn xếp công ty phát hành để phát hành phiên bản mới mã thông báo.
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
Máy chủ của người sử dụng ưu đãi
Bạn sẽ cần triển khai dịch vụ sử dụng mã thông báo bằng cách tự tạo mã thông báo ứng dụng phía máy chủ. Thao tác này sẽ cho phép bạn đọc các mã thông báo mà nhà phát hành gửi. Các bước sau đây trình bày cách sử dụng mã thông báo cũng như cách đọc bản ghi sử dụng ưu đãi được liên kết với các mã thông báo đó.
Bạn có thể chọn chạy công ty phát hành và người đổi thưởng trong cùng một máy chủ (hoặc nhóm máy chủ).
Yêu cầu kỹ thuật đối với máy chủ đổi quà
Theo giao thức, bạn sẽ cần triển khai ít nhất hai điểm cuối HTTP cho máy chủ đổi quà của bạn:
/.well-known/private-state-token/redemption: điểm cuối trong đó tất cả việc sử dụng mã thông báo sẽ được xử lý. Điểm cuối này sẽ là nơi mã thông báo thành phần người đổi thưởng sẽ được tích hợp
Gửi cuộc gọi tới máy chủ đổi quà
Để sử dụng mã thông báo, bạn cần triển khai lệnh gọi tìm nạp trang web để ngăn xếp mã người dùng để đổi các mã thông báo đã phát hành trước đó.
// redemption request
await fetch("/.well-known/private-state-token/redemption", {
method: "POST",
privateToken: {
version: 1,
operation: "token-redemption",
refreshPolicy: "none"
}
});
Xem mã mẫu.
Sau khi sử dụng mã thông báo, bạn có thể gửi bản ghi sử dụng ưu đãi (RR) bằng cách thực hiện lệnh gọi tìm nạp khác:
// attach redemption records from the issuers to the request
await fetch("<DESTINATION_RESOURCE>", {
method: "POST",
privateToken: {
version: 1,
operation: "send-redemption-record",
issuers: [<ISSUER_DOMAIN>]
}
});
Xem mã mẫu.
Triển khai phương thức triển khai
Để kiểm tra việc triển khai của bạn, trước tiên hãy điều hướng đến trang web nơi phát hành được thực hiện và xác nhận rằng(các) mã thông báo được tạo theo logic của bạn. Xác minh trong phần phụ trợ của bạn để đảm bảo các lệnh gọi được thực hiện theo thông số kỹ thuật. Sau đó, hãy chuyển đến trang web thực hiện cuộc gọi sử dụng thẻ rồi xác nhận rằng các RR được tạo theo logic của bạn.
Triển khai thực tế
Chúng tôi khuyên bạn nên chọn các trang web mục tiêu là một phần của việc sử dụng cụ thể của bạn trường hợp:
- Số lượt truy cập hằng tháng nhỏ (~ <1 triệu lượt truy cập/tháng): Bạn nên bắt đầu bằng cách trước tiên là triển khai API cho một nhóm độc giả nhỏ
- Bạn sở hữu và kiểm soát nó: Nếu cần, bạn có thể nhanh chóng tắt triển khai mà không cần phê duyệt phức tạp
- Không có nhiều nhà phát hành: Để giới hạn số lượng mã thông báo để đơn giản hoá quá trình thử nghiệm.
- Không có nhiều hơn 2 người đổi thưởng: Bạn cần đơn giản hoá cách khắc phục sự cố trong trường hợp xảy ra vấn đề.
Chính sách về quyền
Để hoạt động đúng cách, PST API phải được cung cấp cho trang cấp cao nhất và mọi tài nguyên phụ có sử dụng API.
Thao tác yêu cầu mã thông báo được kiểm soát bởi lệnh private-state-token-issuance. Các thao tác token-redemption và send-redemption-record được kiểm soát bởi lệnh private-state-token-redemption. Theo mặc định, danh sách cho phép cho các lệnh này được đặt thành chính. Điều đó có nghĩa là tính năng này chỉ có sẵn cho trang cấp cao nhất (và iframe cùng nguồn gốc) và không khả dụng đối với iframe nhiều nguồn gốc nếu không có trang uỷ quyền rõ ràng.
Bạn có thể chọn không phát hành hoặc sử dụng mã thông báo PST cho các trang cụ thể trên trang web của mình bằng cách thêm private-state-token-issuance=() và private-state-token-redemption=() trong tiêu đề Permissions-Policy cho mỗi trang.
Bạn cũng có thể sử dụng tiêu đề Permissions-Policy để kiểm soát quyền truy cập của bên thứ ba vào PST. Làm tham số cho danh sách nguồn gốc của tiêu đề, hãy dùng self và mọi nguồn mà bạn muốn cho phép truy cập vào API này. Ví dụ: để vô hiệu hoá hoàn toàn việc sử dụng PST trong tất cả ngữ cảnh duyệt web, ngoại trừ nguồn gốc của riêng bạn và https://example.com, hãy đặt các tiêu đề phản hồi HTTP sau đây:
Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")
Để bật API cho tất cả tài nguyên trên nhiều nguồn gốc, hãy đặt danh sách nguồn gốc thành *.
Tìm hiểu cách kiểm soát các tính năng của Hộp cát về quyền riêng tư thông qua Chính sách về quyền hoặc tìm hiểu sâu hơn về Chính sách về quyền.
Khắc phục sự cố
Bạn có thể kiểm tra PST từ các thẻ Mạng và Ứng dụng của Công cụ Chrome cho nhà phát triển.
Trên thẻ Mạng:
Trên thẻ Ứng dụng:
Đọc thêm về thông tin này Tích hợp Công cụ cho nhà phát triển.
Cách khắc phục sự cố và các phương pháp hay nhất dành cho máy chủ
Để công ty phát hành thẻ và máy chủ đổi thưởng của bạn hoạt động hiệu quả, bạn nên triển khai các phương pháp hay nhất sau đây để đảm bảo rằng bạn không gặp phải các thách thức về quyền truy cập, bảo mật, ghi nhật ký hoặc lưu lượng truy cập đối với PST.
- Các thiết bị đầu cuối của bạn phải áp dụng tiêu chuẩn mã hoá mạnh bằng cách sử dụng TLS 1.3 hoặc 1.2.
- Cơ sở hạ tầng của bạn phải sẵn sàng xử lý lưu lượng truy cập thay đổi (bao gồm cả mốc tăng đột biến).
- Đảm bảo các khoá được bảo vệ và an toàn, phù hợp với Quyền truy cập của bạn Chính sách kiểm soát, chiến lược quản lý chính và Kế hoạch duy trì hoạt động kinh doanh liên tục.
- Thêm chỉ số về khả năng quan sát vào hệ thống công nghệ của bạn để đảm bảo bạn có mức độ hiển thị để hiểu rõ mức sử dụng, nút thắt cổ chai và các vấn đề về hiệu suất sau chuyển sang giai đoạn phát hành chính thức.
Thông tin khác
- Xem tài liệu dành cho nhà phát triển:
- Bắt đầu bằng cách đọc tổng quan để tăng tốc nhanh chóng với PST và các tính năng của nó.
- Xem video giới thiệu về PST.
- Xem thử bản minh hoạ PST.
- Đồng thời đọc API Giải thích để hiểu thêm chi tiết về ứng dụng đó.
- Đọc thêm về thông số kỹ thuật của API.
- Đóng góp vào cuộc trò chuyện qua GitHub vấn đề hoặc W3C cuộc gọi.
- Để hiểu rõ hơn về bất kỳ thuật ngữ nào, hãy xem lại Bảng chú giải thuật ngữ Hộp cát về quyền riêng tư.
- Để tìm hiểu thêm về các khái niệm của Chrome, chẳng hạn như "origin dùng thử" hoặc "Cờ Chrome", xem các video ngắn và bài viết hiện có trên goo.gle/cc.