Báo cáo phản hồi – Quý 1 năm 2025

Báo cáo hằng quý cho quý 1 năm 2025 tóm tắt ý kiến phản hồi của hệ sinh thái về các đề xuất liên quan đến Hộp cát về quyền riêng tư và phản hồi của Chrome.

Google đã chuẩn bị báo cáo hằng quý này theo cam kết với Cơ quan Cạnh tranh và Thị trường ('CMA') theo các đoạn 12, 17(c)(ii) và 32(a). Báo cáo này trình bày tiến trình của Google đối với các đề xuất về Hộp cát về quyền riêng tư; thời gian dự kiến mới nhất; nội dung giải thích chi tiết về cách Google xem xét các quan sát của bên thứ ba; cũng như bản tóm tắt về các hoạt động tương tác giữa Google và CMA, bao gồm cả ý kiến phản hồi của CMA và phương pháp của Google để giải quyết ý kiến phản hồi đó.

Google đã cập nhật cho CMA về tiến trình của các đề xuất về Hộp cát về quyền riêng tư trong các Cuộc họp thường xuyên về trạng thái theo lịch theo mục 17(b) của Cam kết. Ngoài ra, nhóm này còn duy trì tài liệu dành cho nhà phát triển, cung cấp thông tin tổng quan về các tính năng quảng cáo riêng tư cốt lõi và các thay đổi về cookie, cùng với việc triển khai API và thông tin trạng thái. Thông tin cập nhật chính được chia sẻ trên blog dành cho nhà phát triển cùng với thông tin cập nhật theo mục tiêu được chia sẻ cho danh sách gửi thư của từng nhà phát triển.

Bảng chú giải từ viết tắt

ARA
Attribution Reporting API
Cookie có trạng thái được phân vùng độc lập (CHIPS)
Cookie có trạng thái được phân vùng độc lập
DSP (Bộ xử lý tín hiệu kỹ thuật số)
Nền tảng bên cầu
FedCM
Federated Credential Management
(Quản lý thông tin xác thực liên kết)
IAB (Cục Quảng cáo tương tác)
Cục Quảng cáo tương tác
IDP
Nhà cung cấp danh tính
IETF (Lực lượng chuyên trách kỹ thuật Internet)
Lực lượng chuyên trách kỹ thuật Internet
IP
Địa chỉ giao thức Internet
openRTB
Đặt giá thầu theo thời gian thực
QUÁ GIỜ
Bản dùng thử Origin
PA API
Protected Audience API (trước đây là FLEDGE)
PatCG
Nhóm cộng đồng về công nghệ quảng cáo riêng tư
RP
Bên phụ thuộc
RWS
Bộ trang web có liên quan (trước đây là Nhóm bên thứ nhất)
SSP
Nền tảng bên cung
UA
Chuỗi tác nhân người dùng
UA-CH
Thông tin mô tả của ứng dụng tác nhân người dùng
W3C
World Wide Web Consortium
WIPB
Cố tình làm ngơ địa chỉ IP

Ý kiến phản hồi chung, không có API/Công nghệ cụ thể

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Lựa chọn của người dùng Hiện chưa rõ phương pháp mới của Google để nâng cao quyền lựa chọn của người dùng sẽ như thế nào, cách trình bày phương pháp đó cho người dùng và tỷ lệ chọn/không chọn dự kiến. Bạn cần cung cấp thêm thông tin để phân biệt trường hợp này với việc ngừng sử dụng cookie của bên thứ ba. Vào tháng 4 năm 2025, Google đã xuất bản một bài đăng trên blog về Các bước tiếp theo cho Hộp cát về quyền riêng tư và biện pháp chống theo dõi trên Chrome, thông báo rằng Google đã quyết định duy trì phương pháp hiện tại để cung cấp cho người dùng cookie của bên thứ ba trong Chrome và sẽ không triển khai lời nhắc độc lập mới cho cookie của bên thứ ba.
Chúng tôi sẽ cung cấp thêm thông tin cập nhật khi có.
Tạo vân tay số Google chưa chia sẻ với nhà xuất bản hoặc nhà tiếp thị bất kỳ thông tin nào về cách họ có thể dựa vào bất kỳ giải pháp thay thế nào cho Hệ thống quảng cáo của Google mà không sử dụng danh tính người tiêu dùng có nhiều rủi ro hơn làm khoá khớp chung (tức là vân tay số). Chúng tôi đã nêu bật một số Hệ thống quảng cáo không phải của Google đang cung cấp các giải pháp cho nhà xuất bản và nhà tiếp thị, một phần được xây dựng dựa trên API Hộp cát về quyền riêng tư. Trong đó có cả các Hệ thống quảng cáo không phải của Google trên các thị trường và kênh. Bạn có thể xem thêm thông tin chi tiết và nghiên cứu điển hình trong phần Tài nguyên dành cho doanh nghiệp trên privacysandbox.com tại đây.
Hộp cát về quyền riêng tư API Hộp cát về quyền riêng tư sẽ thay thế các thành phần dữ liệu trên Internet bằng các sản phẩm hoàn chỉnh của riêng Google. Vì giải pháp thay thế của Google là một API, nên Google đang cung cấp quyền truy cập vào một sản phẩm mà Google sở hữu và kiểm soát, đồng thời sản phẩm này phải tuân theo các điều khoản và điều kiện mà Google có toàn quyền quyết định. Đó không phải là thành phần thay thế cho các thành phần mà người khác sử dụng để tạo ra sản phẩm hoàn chỉnh của riêng họ. Các API Hộp cát về quyền riêng tư được phát triển và triển khai sau khi tham gia tích cực với các cơ quan quản lý và nhiều bên liên quan trong hệ sinh thái. Cũng như các công nghệ nền tảng khác, API Hộp cát về quyền riêng tư phải được xem xét để sử dụng làm thành phần trong sản phẩm hoàn chỉnh của người khác. Chúng tôi hoan nghênh những nỗ lực của hệ sinh thái để phát triển các công nghệ bổ sung hoạt động cùng với API Hộp cát về quyền riêng tư.
Lựa chọn của người dùng Yêu cầu cung cấp thông tin về việc liệu phương pháp mới của Google đối với 3PC trên Chrome có đáp ứng một số yêu cầu theo quy định hay không. Điều này có thể ảnh hưởng đến trải nghiệm của các bên liên quan trên nền tảng quản lý sự đồng ý. Vào tháng 4 năm 2025, Google đã xuất bản một bài đăng trên blog về Các bước tiếp theo cho Hộp cát về quyền riêng tư và biện pháp chống theo dõi trên Chrome, thông báo rằng Google đã quyết định duy trì phương pháp hiện tại để cung cấp cho người dùng cookie của bên thứ ba trong Chrome và sẽ không triển khai lời nhắc độc lập mới cho cookie của bên thứ ba.
Chúng tôi sẽ cung cấp thêm thông tin cập nhật khi có.
Tiến trình và việc áp dụng Hộp cát về quyền riêng tư Các công nghệ quảng cáo đã tạm dừng thử nghiệm API Hộp cát về quyền riêng tư và đang tìm kiếm những lý do thuyết phục hơn để đầu tư lại vào các công nghệ này cho các hoạt động tiếp thị và sản phẩm. Quyết định tái đầu tư của họ chịu ảnh hưởng lớn bởi nhu cầu hiểu rõ hơn về tiến trình triển khai Lựa chọn của người dùng, cũng như những lo ngại về độ trễ của Protected Audience API (PA API) và lộ trình B&A. Ngoài ra, chúng tôi còn lo ngại về việc CMA sắp xem xét các cam kết, đặc biệt là vai trò của Google trong việc thúc đẩy các công nghệ Hộp cát về quyền riêng tư mà không dựa vào giá trị nhận dạng của bên thứ ba, cũng như định hướng tổng thể trong tương lai của sáng kiến này để thông báo cho các chiến lược đầu tư. Vào tháng 4 năm 2025, Google đã xuất bản một bài đăng trên blog về Các bước tiếp theo cho Hộp cát về quyền riêng tư và biện pháp chống theo dõi trên Chrome, thông báo rằng Google đã quyết định duy trì phương pháp hiện tại để cung cấp cho người dùng cookie của bên thứ ba trong Chrome và sẽ không triển khai lời nhắc độc lập mới cho cookie của bên thứ ba. Chúng tôi sẽ cung cấp thêm thông tin cập nhật khi có.

Các phiên đấu giá API PA của Chrome nhanh hơn 35% so với năm trước. Ngoài ra, chúng tôi nhận thấy mức sử dụng phiên đấu giá song song đã tăng lên đáng kể, giúp các phiên đấu giá đó mang lại lợi ích lớn hơn nữa.

Bạn có thể xem lộ trình hiện tại của chúng tôi về B&A tại đây.
Tiến trình triển khai Hộp cát về quyền riêng tư Nội dung nào được cập nhật trong trang Dòng thời gian của Hộp cát về quyền riêng tư? Gần đây, chúng tôi đã thêm thông tin tổng quan về Topics API vào trang Tiến trình của Hộp cát về quyền riêng tư.
Hộp cát về quyền riêng tư Có tài liệu nghiên cứu nào về Quyền riêng tư so với Lợi ích để giúp hiểu được tác động của Hộp cát về quyền riêng tư đối với doanh thu không? Bạn có thể xem các nghiên cứu điển hình có liên quan về thị trường để giải đáp những câu hỏi này tại đây và xem kết quả thử nghiệm API Hộp cát về quyền riêng tư tại đây.
Sử dụng Hộp cát về quyền riêng tư Một người dùng sớm đã báo cáo những thách thức ban đầu với API Hộp cát về quyền riêng tư do các công ty lớn áp dụng chậm, ảnh hưởng đến việc ra mắt thử nghiệm. Tuy nhiên, chúng tôi rất cảm kích cách tiếp cận cộng tác và khả năng phản hồi ý kiến phản hồi của nhóm Hộp cát về quyền riêng tư. Chúng tôi cảm ơn ý kiến phản hồi của những người dùng sớm. Chúng tôi cam kết cộng tác với những người dùng sớm, đồng thời sẽ tiếp tục tham gia vào hệ sinh thái và thu thập ý kiến phản hồi khi đánh giá vai trò của các công nghệ Hộp cát về quyền riêng tư trong việc hỗ trợ hệ sinh thái.
Kiểm thử Chrome Lo ngại về khả năng tiếp tục thử nghiệm Hộp cát về quyền riêng tư một cách hiệu quả sau khi xoá các nhãn thử nghiệm cho thấy sự khác biệt đáng kể về chất lượng lưu lượng truy cập giữa Chrome đã tắt 3PC (Chế độ B) và những người dùng đã tự tắt 3PC trong phần cài đặt Chrome. Chúng tôi trả lời tương tự như các quý trước:

Nhóm Hộp cát về quyền riêng tư hiểu rằng các công ty muốn tiếp tục sử dụng nhãn ngừng sử dụng cookie. Quy trình gia hạn phạm vi cung cấp nhãn tương tự như quy trình gia hạn bản dùng thử theo nguyên gốc. Chúng tôi đã nhiều lần gia hạn việc hỗ trợ các nhãn này. Chúng tôi dự kiến sẽ đề xuất mở rộng thêm tính năng hỗ trợ cho các nhãn ngừng sử dụng cookie và sẽ chia sẻ thông tin cập nhật trên blink-dev khi có.

Đăng ký và chứng thực

Chúng tôi không nhận được ý kiến phản hồi nào trong quý này.

Hiển thị nội dung và quảng cáo phù hợp

Chủ đề

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Chọn sử dụng/không sử dụng Việc Google xác nhận rằng Google Tìm kiếm sẽ không sử dụng quyết định của một trang web về việc chọn không sử dụng Topics API làm tín hiệu xếp hạng có hạn chế Google sử dụng quyết định của một trang web về việc chọn sử dụng Topics API làm tín hiệu xếp hạng không? Phản hồi của chúng tôi tương tự như các quý trước:

Nhóm Hộp cát về quyền riêng tư chưa điều phối hoặc yêu cầu tổ chức Tìm kiếm sử dụng thứ hạng trang làm phần thưởng để các trang web sử dụng Topics API. Google Tìm kiếm sẽ không sử dụng quyết định của một trang web về việc hỗ trợ (hoặc không hỗ trợ) Topics API làm tín hiệu xếp hạng.
Khả năng quan sát mức sử dụng Yêu cầu cơ chế quan sát cho một SSP hoặc công nghệ quảng cáo chung để có thể xem liệu cách triển khai Topics API của họ có đang được sử dụng trên web hay không. Chúng tôi đang đánh giá khả năng hỗ trợ chức năng này và rất mong nhận được ý kiến phản hồi bổ sung từ hệ sinh thái nếu tính năng này là ưu tiên hàng đầu.
Quyền riêng tư Câu hỏi về sự đồng ý và khả năng nhận dạng lại. Chúng tôi hiện đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn.

Protected Audience API

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
PA API và GAM/AdX Google sẽ không gửi bất kỳ nhu cầu nào của GAM/AdX cho một nhà xuất bản muốn dựa vào máy chủ quảng cáo của nhà xuất bản đối thủ. Google nên cho phép các nhà xuất bản đối thủ chọn người bán đấu giá API PA cấp cao thay thế để kiểm soát phiên đấu giá cuối cùng. GAM sẽ có thông tin từ API PA nhưng các SSP đối thủ sẽ bị hạn chế. Do đó, nhà xuất bản không thể so sánh hiệu suất của nhu cầu được cung cấp từ API PA trong GAM, chẳng hạn như từ AdX hoặc từ các SSP được tích hợp vào API PA. Phản hồi của Chrome:
Tiêu chuẩn API PA được thiết kế linh hoạt và cho phép nhiều bên chạy phiên đấu giá cấp cao nhất. Lựa chọn này phụ thuộc vào các phương thức triển khai và chức năng cụ thể mà máy chủ quảng cáo của nhà xuất bản (cho dù là GAM hay một máy chủ khác) và các công ty tham gia khác trong hệ sinh thái cung cấp.
Thiết kế tập trung vào quyền riêng tư của PA API giới hạn báo cáo chi tiết cho tất cả người tham gia một cách nhất quán. Dữ liệu cụ thể được báo cáo từ phiên đấu giá API PA phải tuân theo các quy tắc và giới hạn bảo vệ quyền riêng tư do API xác định cho tất cả người tham gia, bao gồm cả mọi SSP.
Nhà xuất bản sử dụng các báo cáo tổng hợp, bảo đảm quyền riêng tư của API PA để đánh giá hiệu suất. Điều này cho phép đánh giá mức đóng góp tổng thể của nhu cầu được lấy qua API PA và cho phép so sánh với các kênh nhu cầu khác, nhất quán với các nguyên tắc về quyền riêng tư ngay từ khi thiết kế của API.

Phản hồi do Google Ad Manager cung cấp:
Nhà xuất bản không bắt buộc phải sử dụng chức năng máy chủ quảng cáo của GAM để truy cập vào nhu cầu của AdX. Ngoài ra, PA API không phân biệt người bắt đầu phiên đấu giá trong cả thiết kế một người bán và nhiều người bán.
Người bán cấp cao Người bán cấp cao nhất (TLS) có quyền truy cập vào thông tin mà không có người bán thành phần nào khác có quyền truy cập, gây ra mối lo ngại về quyền truy cập không đồng đều vào thông tin. Mặc dù bất kỳ thực thể nào cũng có thể là TLS, nhưng để truy cập vào nhu cầu của AdX, nhà xuất bản phải sử dụng GAM làm máy chủ quảng cáo của nhà xuất bản. Điều này tạo ra động lực để sử dụng GAM làm máy chủ quảng cáo của nhà xuất bản, tạo ra lợi thế cạnh tranh cho Google. Phản hồi của Chrome:
Thiết kế của API PA không chỉ định thực thể nào có thể đóng vai trò là TLS. Vai trò TLS yêu cầu điều phối phiên đấu giá và truy cập thông tin phiên đấu giá có liên quan theo cấu trúc của API.

Phản hồi của Google Ad Manager:
Chúng tôi luôn chú trọng đến tính công bằng của phiên đấu giá trong nhiều năm, bao gồm cả lời hứa rằng chúng tôi sẽ không chia sẻ giá của bất kỳ nguồn quảng cáo không được đảm bảo nào của nhà xuất bản (bao gồm cả giá mục hàng không được đảm bảo) với người mua khác trước khi họ đặt giá thầu trong phiên đấu giá. Sau đó, chúng tôi đã tái khẳng định lời hứa này trong cam kết của chúng tôi với Cơ quan Cạnh tranh của Pháp.
Đối với các phiên đấu giá qua API PA, chúng tôi dự định giữ lời hứa và không chia sẻ giá thầu của người tham gia phiên đấu giá với bất kỳ người tham gia phiên đấu giá nào khác trước khi phiên đấu giá kết thúc trong các phiên đấu giá nhiều người bán. Xin lưu ý rằng chúng tôi sẽ không chia sẻ giá của phiên đấu giá theo bối cảnh với bất kỳ phiên đấu giá thành phần nào, kể cả phiên đấu giá của chính chúng tôi, như giải thích trong nội dung cập nhật này. Hơn nữa, chúng tôi không sử dụng thông tin về cấu hình phiên đấu giá thành phần, bao gồm cả các tín hiệu do người mua cung cấp cho SSP, trong phiên đấu giá của riêng chúng tôi.
Ngoài ra, như đã nêu ở trên, GAM không yêu cầu nhà xuất bản sử dụng chức năng máy chủ quảng cáo để truy cập vào nhu cầu của AdX.

Cuối cùng, như đã lưu ý trước đó trong báo cáo của Google về quý 2 / quý 3 năm 2024, các nền tảng bên mua của Google – Google Ads (trước đây là AdWords) và DV360 – có mua lượt hiển thị từ các nền tảng trao đổi không phải của Google, bao gồm cả thông qua API PA.
PA API và GAM/AdX Nhà xuất bản khó hiểu được việc kích hoạt API PA trên 100% khoảng không quảng cáo vì nhãn của tuỳ chọn này không nêu rõ mục đích. Đối với các SSP, phương thức chính để truy cập khoảng không quảng cáo thường là thông qua phiên đấu giá nhiều cấp, trong đó GAM đóng vai trò là TLS, thì không có cách nào hiệu quả để tiến hành thử nghiệm hoặc kiếm tiền thông qua API PA mà không phải tuân theo GAM. Phản hồi của Chrome:
Tiêu chuẩn API PA xác định các vai trò kỹ thuật (như TLS và người bán thành phần) cũng như quy trình đấu giá, cho phép các nền tảng linh hoạt thực hiện các vai trò này.

Các hoạt động vận hành (chẳng hạn như cấu hình, điều phối và thoả thuận) do các bên triển khai (nhà xuất bản, SSP, nhà cung cấp TLS) quản lý để hỗ trợ việc tham gia bằng khung API PA.

Phản hồi của Google Ad Manager:
Như mô tả trong Trung tâm trợ giúp của chúng tôi, Ad Manager cung cấp cho nhà xuất bản một chế độ kiểm soát để bật tính năng thử nghiệm với những bên bán thành phần không phải của Google, chẳng hạn như các SSP khác, trên 100% khoảng không quảng cáo của nhà xuất bản có thể sử dụng API (ghi đè mọi hoạt động lấy mẫu hoặc điều tiết mà GAM có thể áp dụng).

Nếu nhà xuất bản bật chế độ kiểm soát này, thì bất cứ khi nào người bán thành phần không phải Google cung cấp cấu hình phiên đấu giá, GAM sẽ cố gắng chạy phiên đấu giá cấp cao nhất bao gồm cả phiên đấu giá thành phần được cung cấp, miễn là nhà xuất bản đã có được sự đồng ý cần thiết của người dùng để thực hiện việc này. GAM sẽ thông báo rõ ràng cho nhà xuất bản rằng chế độ kiểm soát này có thể ảnh hưởng đến hiệu suất để nhà xuất bản có thể đưa ra quyết định sáng suốt.
Phía máy chủ so với trên thiết bị Các giải pháp phía máy chủ, chẳng hạn như Đặt giá thầu và Phiên đấu giá (B&A), có thể giải quyết vấn đề định hình lưu lượng truy cập trong khi vẫn duy trì quyền riêng tư. Giải pháp phía máy chủ là cách duy nhất khả thi và Google nên từ bỏ các giải pháp trên thiết bị. Mục đích của Hộp cát về quyền riêng tư là hỗ trợ cả giải pháp đấu giá phía máy chủ (dịch vụ B&A) và giải pháp đấu giá trên thiết bị, cung cấp các lựa chọn để đáp ứng nhiều nhu cầu và trường hợp sử dụng công nghệ quảng cáo.
Bảo mật phiên đấu giá Các cuộc tấn công vào giá thầu API PA về cơ bản sẽ khiến bạn không đủ điều kiện tham gia đặt giá thầu và đấu giá trên thiết bị. Các bên liên quan vẫn coi vấn đề này chưa được giải quyết và họ tiếp tục yêu cầu đảm bảo kỹ thuật để đảm bảo giá thầu API PA không bị can thiệp cũng như chế độ gỡ lỗi đầy đủ để phát hiện sự cố theo thời gian thực và gỡ lỗi hiệu quả. Đảm bảo tính toàn vẹn của phiên đấu giá API PA, bao gồm cả việc giảm thiểu các cuộc tấn công tiềm ẩn, là một trọng tâm chính của Hộp cát về quyền riêng tư. Thiết kế của API này kết hợp các biện pháp về tính toàn vẹn và chúng tôi hoan nghênh thảo luận thêm về các vấn đề kỹ thuật cụ thể.

Chúng tôi đã trình bày và thảo luận về danh sách chi tiết các cuộc tấn công tiềm ẩn trên API PA cũng như các biện pháp giảm thiểu của chúng tôi trong cuộc họp của Nhóm cộng đồng chống gian lận của W3C vào tháng 5 năm 2024. Chúng tôi hoan nghênh các cuộc thảo luận và ý kiến phản hồi khác về những "cuộc tấn công tiềm ẩn vào giá thầu API PA" đáng lo ngại.
Lưu lượng truy cập không có cookie Có cách nào để chỉ bật API PA trên lưu lượng truy cập không có cookie cho mục đích kiểm thử hoặc các mục đích khác không? Các công nghệ quảng cáo có thể xác định xem có 3PC hay không. Bạn có thể xem thông tin giải thích chi tiết hơn tại đây.
ID chỗ ngồi Liên quan đến đề xuất Mã chỗ ngồi, kiến thức về mã chỗ ngồi là điều cần thiết đối với hầu hết các yêu cầu đặt giá thầu, điều này gây ra mối lo ngại về việc liên kết mã chỗ ngồi với việc đăng ký mẫu quảng cáo. Hơn nữa, liệu chiến lược này chỉ áp dụng cho "quảng cáo chính" hay cũng áp dụng cho quảng cáo thành phần? Đề xuất BuyerAndSellerReportingId giải quyết mối lo ngại về việc thiếu Mã chỗ ngồi của người mua trong quá trình đăng ký mẫu quảng cáo cho quảng cáo chính. Giá trị nhận dạng này nhằm thông báo cho người bán về Mã chỗ ngồi của người mua. Chúng tôi đang đánh giá việc hỗ trợ quảng cáo thành phần.
Giám sát và báo cáo Yêu cầu về tính năng Giám sát theo thời gian thực (RTM) để (1) gửi báo cáo RTM cho các phiên đấu giá bị huỷ cũng như (2) các bộ chứa mới do trình duyệt điền sẵn để làm rõ loại hình huỷ đã xảy ra. Có vẻ như RTM không phải là giải pháp phù hợp để điều tra tỷ lệ tham gia. RTM được thiết kế dưới dạng một API giám sát có độ trễ thấp để phát hiện các sự cố ngừng hoạt động tạm thời, đột ngột và nghiêm trọng. Ngược lại, tỷ lệ tham gia không yêu cầu báo cáo độ trễ thấp và không phải là sự cố tạm thời nghiêm trọng, đột ngột. Những lo ngại về tỷ lệ tham gia sẽ được giải đáp hiệu quả nhất bởi người bán mà người mua cộng tác, chứ không phải người mua tìm hiểu thông qua trình duyệt.

Hơn nữa, vì các phiên đấu giá bị huỷ là cực kỳ phổ biến, nên nếu trình duyệt tạo báo cáo RTM từ mỗi phiên đấu giá bị huỷ, thì báo cáo RTM cho các sự cố thực tế có thể bị lấn át.
Tài liệu
Làm rõ		 Báo cáo về sự khác biệt về tài liệu trong nội dung giải thích của API PA cho biết số chỉ dùng một lần phải là một chuỗi UUID, nhưng thực tế lại trả về một lời hứa. Bạn có thể xem thông tin giải thích tại đây.
Ngữ cảnh
đã đóng băng		 Khi làm việc với ngữ cảnh đã đóng băng, bạn có những lựa chọn nào để giải quyết các vấn đề và thách thức liên quan đến (1) việc đóng gói, (2) thư viện bên ngoài và (3) các loại dữ liệu không được hỗ trợ? Chúng tôi đã trả lời câu hỏi này tại đây.
Thông số Private Aggregation API đã thêm một thao tác contributeToHistogramOnEvent chung. Do đó, định nghĩa trong API PA đã trở thành một thao tác nạp chồng và các thao tác Web IDL "không được nạp chồng trên giao diện, một phần giao diện [...]", vì vậy, định nghĩa đó hiện không hợp lệ. Vấn đề này cho thấy sự không nhất quán tạm thời giữa API PA và thông số kỹ thuật của tính năng Tổng hợp riêng tư trong khi chúng tôi hợp nhất các thay đổi tương tự trong cả hai. Chúng tôi đã hợp nhất một yêu cầu lấy dữ liệu để giải quyết vấn đề này.
Nhóm mối quan tâm Yêu cầu hướng dẫn về phương pháp được đề xuất và tiết kiệm tài nguyên để chấm dứt việc tham gia đặt giá thầu của một Nhóm đối tượng có cùng mối quan tâm (IG) khi chiến dịch dừng. Sau đây là một số đề xuất mà chúng tôi có thể cung cấp:

Chúng tôi cho rằng cơ chế có độ trễ thấp nhất, ít vĩnh viễn nhất nhưng cũng ít giải phóng tài nguyên nhất là sử dụng các tín hiệu đặt giá thầu theo thời gian thực để thông báo cho generateBid() của họ ngừng đặt giá thầu.

Tuỳ chọn thứ hai sử dụng ít tài nguyên hơn là đặt mức độ ưu tiên âm cho IG đó trong phản hồi tín hiệu đặt giá thầu theo thời gian thực, vì điều này sẽ ngăn generateBid() được gọi.

Lựa chọn thứ ba, sử dụng ít tài nguyên hơn nữa, là xoá quảng cáo khỏi IG. IG không có quảng cáo sẽ không được gọi generateBid().

Tuỳ chọn thứ tư, sử dụng ít tài nguyên hơn nữa, là xoá biddingLogicURL khỏi IG. Tại thời điểm này, bạn vẫn có thể cập nhật/tham gia lại để kích hoạt lại tài khoản Instagram đó.

Các tuỳ chọn khác liên quan đến việc rời khỏi IG, thông qua leaveAdInterestGroup() hoặc clearOriginJoinedAdInterestGroups() hoặc thông qua việc IG hết hạn.

Như đã nêu trên, các tuỳ chọn khác nhau sẽ có mức độ ảnh hưởng đến độ trễ và mức tiêu thụ tài nguyên khác nhau. Các công nghệ quảng cáo có thể chọn phương án có sự đánh đổi phù hợp nhất cho các trường hợp sử dụng cụ thể của chúng.
Đối tượng Yêu cầu về cơ chế để chạy các phép toán logic trên đối tượng đã tạo (ví dụ: khả năng nhắm mục tiêu đến giao điểm của IG A và B) Với PA API, bạn hiện có thể chạy các phép toán logic trên đối tượng từ cùng một trang web. Hiện tại, chúng tôi không hỗ trợ các phép toán logic của đối tượng trên nhiều trang web vì những cân nhắc về quyền riêng tư như đã giải thích trong mô hình quyền riêng tư của chúng tôi. Chúng tôi đang tiếp tục tiến hành nghiên cứu trong lĩnh vực này và sẽ chia sẻ mọi thông tin cập nhật trong quá trình nghiên cứu.
Yêu cầu tính năng Đề xuất xoá quy định hạn chế về giá thầu bổ sung yêu cầu phải biết trước TLS. Chúng tôi đang thảo luận về đề xuất này tại đây và hoan nghênh ý kiến phản hồi khác của bạn.
Cập nhật phương pháp cho 3 máy tính trên Chrome Các API Hộp cát về quyền riêng tư như PA API có tiếp tục được cung cấp rộng rãi cho tất cả người dùng Chrome phiên bản ổn định hay các API (hoặc một nhóm nhỏ API) chỉ được cung cấp cho những người dùng đã từ chối 3PCs? Chúng tôi không muốn quyết định từ chối 3PC của người dùng ảnh hưởng đến khả năng sử dụng API Hộp cát về quyền riêng tư trong Chrome phiên bản ổn định.
Tín hiệu nâng cao Có kế hoạch nào để thêm chức năng cho biết liệu TLS có ý định chạy phiên đấu giá API PA hay không? Chúng tôi đang đánh giá khả năng hỗ trợ chức năng này. Chúng tôi sẽ chia sẻ thêm thông tin chi tiết về tiến trình triển khai khi có thể và rất mong nhận được ý kiến phản hồi bổ sung của bạn về yêu cầu này.
ID thỏa thuận Lo ngại rằng yêu cầu về máy chủ KV trong đề xuất Mã giao dịch có thể là một quy trình tốn kém và mất nhiều thời gian ở phía máy chủ. Đề xuất Mã giao dịch cho phép SSP truy vấn siêu dữ liệu của các mã giao dịch đã chọn từ máy chủ khoá-giá trị trong phiên đấu giá PA để không cần tải trước tất cả siêu dữ liệu liên quan đến giao dịch lên thiết bị. Đề xuất này đang được phát triển theo yêu cầu của các SSP. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung về hệ sinh thái tại đây.

Chúng tôi hiểu rằng bạn cần phải thiết lập máy chủ khoá-giá trị, nhưng nhìn chung, chúng tôi vẫn cho rằng đây là một lợi ích ròng cho các công ty công nghệ quảng cáo. Chúng tôi luôn hoan nghênh ý kiến phản hồi và đề xuất của bạn để giúp quy trình này trở nên dễ dàng hơn.
Giới hạn tần suất trên nhiều nền tảng của Instagram Yêu cầu giới hạn tần suất trên nhiều tài khoản Instagram thông qua API PA. Giới hạn tần suất trên nhiều nền tảng của Instagram có những đặc điểm về quyền riêng tư khó giải quyết.

Chúng tôi rất mong nhận được ý kiến phản hồi khác từ hệ sinh thái nếu tính năng này có mức độ ưu tiên cao.
Báo cáo mã giao dịch và mã giấy phép Yêu cầu có thể đưa mã giao dịch hoặc mã chỗ ngồi vào báo cáo tổng hợp. Các chức năng mã báo cáo mà chúng tôi đang triển khai tại đây sẽ giúp bạn báo cáo mã giao dịch và mã chỗ ngồi.

selectedBuyerAndSellerReportingId được cung cấp cho reportResult(), vì vậy, cách dễ nhất để báo cáo là thông qua báo cáo ở cấp sự kiện (tức là mã hoá Mã giao dịch vào URL được truyền đến sendReportTo()). Nếu bạn muốn sử dụng báo cáo tổng hợp, bạn cũng có thể thực hiện việc này.

Tính năng mã báo cáo hiện đang hoạt động cho 10% lưu lượng truy cập trên kênh Chrome chính thức. Chúng tôi đang đánh giá việc mở rộng phạm vi triển khai lên 100%.
Nhóm mối quan tâm Sử dụng cùng một thứ tự ưu tiên trong cả quá trình lựa chọn và đánh giá IG, đồng thời sử dụng thứ tự ưu tiên đó trong tất cả các chế độ đánh giá. Chúng tôi đang thảo luận về vấn đề này tại đây và rất mong nhận được ý kiến phản hồi khác của bạn.
Nhóm mối quan tâm Đề xuất sử dụng tính năng kích hoạt và uỷ quyền đối tượng để tăng mức độ sử dụng API Hộp cát về quyền riêng tư. Chúng tôi đã biết yêu cầu này của nhiều bên liên quan và đang nghiên cứu giải pháp.

Chúng tôi rất mong nhận được ý kiến phản hồi khác từ hệ sinh thái.
Nhóm mối quan tâm Những thách thức liên quan đến việc tạo IG PA API, cụ thể là về việc uỷ quyền và quyền sở hữu khi hành động cho nhiều giao dịch mua hoặc thay mặt cho nhà xuất bản. Chúng tôi đã nhận được yêu cầu hỗ trợ các hoạt động uỷ quyền IG nâng cao hơn từ nhiều bên liên quan và chúng tôi nhận thấy giá trị gia tăng của các SSP đóng góp vào quy trình này.

Chúng tôi đang tiến hành nghiên cứu để tìm ra giải pháp tốt nhất cho phép các bên tham gia vào quy trình mở rộng đối tượng. Chúng tôi rất mong nhận được ý kiến phản hồi khác từ hệ sinh thái.
Hiệu suất phía máy khách Yêu cầu hướng dẫn về cách giảm thiểu việc lưu vào bộ nhớ đệm phía máy khách của trustedBiddingSignals để tối ưu hoá chi phí cơ sở hạ tầng và độ trễ. Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh ý kiến phản hồi khác của bạn.

Phiên đấu giá được bảo vệ (Dịch vụ đặt giá thầu và phiên đấu giá)

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Dịch vụ khoá-giá trị Yêu cầu từ trình duyệt đến máy chủ KV của người bán được phân lô như thế nào? Đối với người bán, yêu cầu từ trình duyệt sẽ có dạng như thế nào – yêu cầu GET hay POST? Ngoài ra, bạn cần làm rõ một số yêu cầu về tính k-ẩn danh. Đối với phiên bản 1, Chrome sẽ gửi một yêu cầu GET đến dịch vụ KV của Người bán để tìm nạp trustedScoringSignalsURL bằng các tín hiệu trong tham số truy vấn của yêu cầu. Các tham số sẽ bao gồm hostname, renderUrls, adComponentRenderUrls và experimentGroupId. Chúng tôi hiện đang thử nghiệm một số tiện ích để gửi thêm thông tin cho tính năng quét mẫu quảng cáo, nhưng tính năng này chưa được ra mắt.

Khi đặt maxTrustedScoringSignalsURLLength thành 0, Chrome có thể gộp tất cả các tín hiệu vào một yêu cầu (có thể vượt quá mọi giới hạn về độ dài URL trên máy chủ của họ), nhưng điều này không được đảm bảo. Chrome hiện chọn đưa các yêu cầu vào cùng một lô nếu các yêu cầu đó sẵn sàng được gửi trong vòng 10 mili giây kể từ yêu cầu trước đó, mặc dù chúng tôi hiện đang điều tra cách tối ưu hoá việc này.

Khi làm việc với trustedScoringSignals, bạn cần nhớ rằng Chrome tuân thủ các tiêu đề lưu vào bộ nhớ đệm. Các tiêu đề như tiêu đề "Cache-Control" Stale-While-Revalidate có thể làm giảm độ trễ trung bình bằng cách cho phép Chrome sử dụng bản sao đã lưu vào bộ nhớ đệm (và cập nhật bộ nhớ đệm cho phiên đấu giá tiếp theo), giúp loại bỏ hiệu quả việc tìm nạp tín hiệu khỏi đường dẫn quan trọng.

Cuối cùng, về tính k-anonymity, có vẻ như phần cụ thể của nội dung giải thích đã lỗi thời. Ban đầu, chúng tôi sẽ yêu cầu URL của tín hiệu đáng tin cậy phải tuân thủ tính năng k-anonymity, nhưng yêu cầu đó đã bị loại bỏ. Chúng tôi sẽ xoá câu này khỏi phần giải thích.
Dịch vụ B&A Quá trình nâng cấp lên phiên bản B&A mới nhất sẽ mất nhiều thời gian. Thời gian xây dựng nhanh hơn hoặc hình ảnh tạo sẵn sẽ rất hữu ích. Các công nghệ quảng cáo có thể tự tạo tệp nhị phân và xác thực bằng cách sử dụng hàm băm được cung cấp. Chúng tôi sẽ xem xét khả năng cung cấp cấu phần phần mềm tạo sẵn hoặc cải thiện thời gian tạo bản dựng trong tương lai.
Yêu cầu về tính năng API Yêu cầu khả năng tương thích với macOS cho tập lệnh bản dựng, hình ảnh vùng chứa và công cụ gọi của Dịch vụ đặt giá thầu và phiên đấu giá (B&A) để tạo điều kiện cho việc phát triển và kiểm thử cục bộ. Chúng tôi hiện hỗ trợ amd64, đủ để triển khai trên các nền tảng đám mây được hỗ trợ (GCP và AWS). Chúng tôi có thể xem xét việc hỗ trợ các cấu trúc khác trong tương lai.
AWS Việc tạo vai trò IAM có phải là yêu cầu đối với các bản dựng chính thức không? Có, bạn cần có vai trò IAM để có quyền thích hợp và giao tiếp với Điều phối viên. Các khoá này được dùng để giải mã văn bản đã mã hoá ProtectedAudienceInput được tạo trên thiết bị như đã nêu tại đây. Ngoài ra, các vai trò này bắt buộc phải đạt được chứng thực máy chủ/TEE của các bản dựng chính thức với chính những Điều phối viên đó. Bạn có thể xem thêm thông tin chi tiết trong hướng dẫn tự phục vụ của chúng tôi.
Cờ B&A Yêu cầu đưa định nghĩa về các cờ B&A hiện có vào tài liệu vì hiện tại, các định nghĩa này nằm trong mã Terraform, tệp cc và tệp proto, nhưng các công nghệ quảng cáo sẽ được hưởng lợi từ tài liệu về các cờ này, tận dụng tài liệu đó làm nguồn đáng tin cậy để hiểu cách tuỳ chỉnh hoạt động triển khai. Chúng tôi đang xem xét khả năng ghi lại nội dung mô tả cờ Terraform và hoan nghênh ý kiến phản hồi bổ sung tại đây.
Dịch vụ đặt giá thầu
của AWS		 Tìm hướng dẫn về dịch vụ đặt giá thầu trên AWS cũng như hành vi và cấu hình ghi nhật ký mặc định. Để gỡ lỗi các dịch vụ đặt giá thầu trong TEE (chẳng hạn như dịch vụ Đặt giá thầu), bạn nên sử dụng tính năng Gỡ lỗi có sự đồng ý của công nghệ quảng cáo. Điều này cho phép bạn bật tính năng ghi nhật ký chi tiết và thu thập dữ liệu yêu cầu/phản hồi cho các yêu cầu kiểm thử cụ thể ngay từ ứng dụng của bạn để giúp gỡ lỗi.
Tài liệu về TEE K/V
 Yêu cầu làm rõ về thời điểm bắt đầu thực thi TKV như đã nêu trên trang web dành cho nhà phát triển. Chúng tôi sẽ thông báo đầy đủ trước khi yêu cầu sử dụng TEE. Cho đến lúc đó, bạn có thể tiếp tục sử dụng máy chủ của riêng mình cho các tín hiệu khoá/giá trị theo thời gian thực.
Kiểm thử và phân tích B&A Việc phân tích và kiểm thử B&A vẫn tốn kém và có vẻ như chưa sẵn sàng cho hoạt động sản xuất. Chúng tôi cần thêm thông tin về bản phân tích chi phí và các yếu tố dẫn đến việc đánh giá mức độ sẵn sàng phát hành công khai để xem xét thêm.
Tối ưu hoá máy chủ đáng tin cậy Đề xuất hợp nhất các tham số dành riêng cho người bán thành phần vào một tham số inputsPerSeller, sử dụng chuỗi JSON cho giá trị của tham số đó. Chúng tôi đang thảo luận về đề xuất này và hoan nghênh ý kiến phản hồi khác tại đây.
Bảo mật Việc sử dụng B&A giúp giảm thiểu rủi ro bảo mật từ TKV như thế nào? Bạn có thể ngăn các lệnh gọi bên ngoài đến TKV. Hiện tại, bạn có thể định cấu hình và sử dụng tính năng này một cách đầy đủ trên GCP.

Đối với AWS, cần phát triển thêm tính năng hỗ trợ do AWS App Mesh (trước đây hỗ trợ tính năng này) không còn được dùng nữa. Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn tại đây.
Dịch vụ B&A Yêu cầu làm rõ nội dung tường thuật/thông tin liên quan đến giá trị của tính năng Truyền phát HTTP để tối ưu hoá B&A. Hộp cát về quyền riêng tư hỗ trợ các tính năng truyền trực tuyến trong việc chuyển dữ liệu B&A để cải thiện độ trễ cho những công nghệ quảng cáo chọn sử dụng tính năng này. Đây là tính năng tối ưu hoá hiệu suất không bắt buộc trong trường hợp chế độ kết hợp.
Đặt giá thầu trước Yêu cầu cập nhật về việc đóng góp cho thư viện Đặt giá thầu trước nguồn mở để bật các tính năng B&A của API PA cho hệ sinh thái. Vào tháng 3 năm 2025, Chrome đã ra mắt tính năng tối ưu hoá ưu tiên đặt giá thầu trước ở phiên bản ổn định như đã nêu trong lộ trình công khai của B&A (xem tháng 3 năm 2025).
Định hình lưu lượng truy cập Yêu cầu về cơ chế ghi lại các tín hiệu theo bối cảnh mà B&A nhận được để hiểu rõ hơn về thời điểm IG được kích hoạt và cải thiện logic "ý định đặt giá thầu" trong phản hồi theo bối cảnh. Điều này giúp sử dụng tài nguyên mạng hiệu quả hơn để tránh "lưu lượng truy cập vô ích" (còn gọi là định hình lưu lượng truy cập). Chúng tôi hiện đang thảo luận về một đề xuất tại đây và hoan nghênh ý kiến phản hồi khác của bạn.
Tài liệu
Làm rõ		 Cần làm rõ về lỗi "Không thể truy cập vào proxy Service/Vsock" phát hiện được trong quá trình thiết lập tích hợp thử nghiệm B&A. Điều này là do yêu cầu về bộ nhớ tối thiểu.Nội dung giải thích về cấu hình AWS đã được cập nhật để phản ánh yêu cầu này.

Đo lường quảng cáo kỹ thuật số

Báo cáo phân bổ (và các API khác)

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Dữ liệu theo thời gian thực Việc thiếu dữ liệu theo thời gian thực ảnh hưởng đến tất cả mọi người trong ngành. Việc chậm trễ dữ liệu theo thời gian thực là vấn đề nghiêm trọng đối với nhà quảng cáo. Người mua chuyển sang các nền tảng có Google Analytics vì đây là nơi duy nhất họ có thể nhận được bằng chứng về việc tiếp cận đối tượng. Độ trễ dữ liệu theo thời gian thực trong Attribution Reporting API (ARA) được triển khai dưới dạng cơ chế bảo vệ quyền riêng tư để giảm khả năng các công nghệ quảng cáo sử dụng báo cáo ở cấp sự kiện nhằm theo dõi người dùng trên các trang web. Tuy nhiên, ARA mang lại sự linh hoạt trong cách phân phối báo cáo phân bổ, bằng cách cho phép báo cáo cấp sự kiện có khoảng thời gian báo cáo tối thiểu là 1 giờ và cho phép Báo cáo tổng hợp có lựa chọn gửi ngay lập tức đến các công nghệ quảng cáo mà không bị chậm trễ.
Việc Sử Dụng API Yêu cầu xác nhận về cấu hình chính xác cho quy trình phân bổ Ứng dụng trên nhiều web, cụ thể là khi chạy song song mô hình phân bổ web-to-web và web-to-app. Khi chạy song song chiến dịch web-to-web và web-to-app, công nghệ quảng cáo chỉ nên chọn một nền tảng để đăng ký từng nguồn hoặc điều kiện kích hoạt để tránh tính hai lần. Bạn nên sử dụng Hệ điều hành (OS) nếu có thể, vì OS có thể thực hiện cả mô hình phân bổ web-to-web và web-to-app, miễn là các nguồn web và trình kích hoạt đã được uỷ quyền chính xác. Điều này có nghĩa là phản hồi bằng tiêu đề Attribution-Reporting-Register-OS-Source cho nguồn và tiêu đề Attribution-Reporting-Register-OS-Trigger cho điều kiện kích hoạt.

Bạn có thể sử dụng Tiêu đề hỗ trợ báo cáo phân bổ để xác định xem có hỗ trợ cấp Chrome và/hoặc Android hay không. Tiêu đề Attribution-Reporting-Info sẽ hữu ích khi không có tiêu đề Attribution-Reporting-Support trong yêu cầu. Trong trường hợp này, trình duyệt sẽ đưa ra quyết định đăng ký nền tảng dựa trên khả năng hỗ trợ nền tảng trên thiết bị của người dùng.
Quy cách API Yêu cầu làm rõ về tiêu đề yêu cầu HTTP Attribution-Reporting-Support do Attribution Reporting API đặt ra và liệu tiêu đề này có chứa cả khoá web và khoá hệ điều hành, bất kể nền tảng hay không. Tiêu đề Hỗ trợ báo cáo phân bổ phải tuân theo trình duyệt thêm các tham số "GREASE" để đảm bảo rằng máy chủ sử dụng trình phân tích cú pháp tiêu đề có cấu trúc tuân thủ thông số kỹ thuật. Đối với tiêu đề này, chỉ nên diễn giải các khoá từ điển có cấu trúc. Các giá trị và tham số này hiện không được sử dụng. Hãy xem ví dụ tại đây.
Báo cáo dựa trên 3PC Yêu cầu hướng dẫn về cách khắc phục sự khác biệt trong kết quả đo lường giữa ARA và 3PC trong chiến dịch quảng cáo. ARA hỗ trợ hai loại báo cáo gỡ lỗi có thể dùng để khắc phục sự cố và gỡ lỗi các điểm khác biệt. Bạn có thể sử dụng báo cáo gỡ lỗi phân bổ thành công để dễ dàng so sánh kết quả ARA với kết quả của các công nghệ đo lường khác, đồng thời sử dụng báo cáo gỡ lỗi chi tiết để nhận thêm thông tin và khắc phục các vấn đề tiềm ẩn trong quá trình đăng ký mô hình phân bổ.
Việc Sử Dụng API Trong quá trình thử nghiệm ARA, chúng tôi đã phát hiện một số vấn đề: báo cáo không đủ chi tiết dẫn đến dữ liệu nhiễu và hoạt động tối ưu hoá chiến dịch không linh hoạt, ngưỡng cao loại trừ các nhà quảng cáo nhỏ hơn và khó so sánh các chiến dịch do các Chỉ số hiệu suất chính không nhất quán. ARA mang lại sự linh hoạt bằng cách cung cấp nhiều thông số mà các công nghệ quảng cáo có thể tuỳ chỉnh để đạt được các trường hợp sử dụng cụ thể về hoạt động đo lường. Báo cáo cấp sự kiện hỗ trợ báo cáo linh hoạt ở cấp sự kiện, cho phép các công nghệ quảng cáo tuỳ chỉnh khoảng thời gian báo cáo, số lượng báo cáo mà họ có thể nhận được và dữ liệu điều kiện kích hoạt mà họ muốn đo lường. Điều này có thể thay đổi tác động của sự nhiễu đến dữ liệu của họ và cho phép họ đạt được nhiều trường hợp sử dụng. Tương tự, Báo cáo tổng hợp có nhiều cách để các công nghệ quảng cáo có thể tuỳ chỉnh cấu hình của mình, chẳng hạn như số lượng phương diện mà chúng theo dõi, tần suất tạo lô và cách sử dụng ngân sách đóng góp để thay đổi mức tác động của nhiễu cũng như đạt được nhiều trường hợp sử dụng.
Quy cách API Câu hỏi về phần phụ thuộc của ARA trên 3PC, cụ thể là liệu phần phụ thuộc này có còn ở giai đoạn thử nghiệm yêu cầu các 3PC này hay không. ARA được bật độc lập với 3PC, nhưng bạn cần bật 3PC để cho phép báo cáo gỡ lỗi chuyển đổi ARA so sánh kết quả ARA với kết quả phân bổ dựa trên cookie.
Việc Sử Dụng API Yêu cầu về việc đăng ký nguồn cho mô hình phân bổ từ ứng dụng đến web trên các phiên bản Android cũ (11, 12 và 13) bằng ARA. ARA hiện được hỗ trợ trên Android S trở lên (12 trở lên).
Việc Sử Dụng API Yêu cầu về mức giá và thông tin phân phối khi chọn tham gia ARA. Câu trả lời của chúng tôi không thay đổi so với các quý trước:

"Chúng tôi không có kế hoạch chia sẻ thông tin này với hệ sinh thái. Nhà phát triển có thể gọi các API mà họ đã triển khai mã hôm nay để ước tính khả năng sử dụng API Hộp cát về quyền riêng tư"
Khả năng sử dụng API Khi ARA được bật, 3PCs được bật hay tắt? Khi ARA được bật trên trình duyệt của người dùng, chế độ này sẽ không ảnh hưởng đến chế độ cài đặt cookie của người dùng. Bạn có thể bật ARA và người dùng có thể bật hoặc tắt cookie.
Báo cáo Có danh sách giá trị được xác định trước nào mà chúng tôi có thể nhận được trong tiêu đề "Attribution-reporting-support" không? Như đã nêu trong hướng dẫn của chúng tôi, giá trị này là một từ điển tiêu đề có cấu trúc, trong đó ngữ nghĩa hiện chỉ được xác định là có hay không có khoá web và hệ điều hành. Bạn nên bỏ qua tất cả các phần khác của tiêu đề. Nói cách khác, việc phân tích cú pháp yêu cầu sử dụng trình phân tích cú pháp tiêu đề có cấu trúc, chứ không phải so khớp chuỗi đơn giản.

Dịch vụ tổng hợp

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Yêu cầu tính năng Yêu cầu về tính năng cho Dịch vụ tổng hợp:

Tích hợp máy chủ với máy chủ, Đo lường trên nhiều thiết bị, Dễ dàng báo cáo đóng góp và phân bổ nhiều lượt chạm, phân bổ trên nhiều kênh và hỗ trợ các vòng lặp tối ưu hoá nâng cao bằng công nghệ học máy (ví dụ: Huấn luyện mô hình riêng).		 Chúng tôi đang đánh giá các yêu cầu này và sẽ chia sẻ thêm thông tin khi có.

Chúng tôi hoan nghênh ý kiến phản hồi bổ sung từ hệ sinh thái về việc liệu những yêu cầu này có phải là ưu tiên hay không.
Yêu cầu tính năng Yêu cầu đặt tham số delete_on_termination của EBS thành True trong môi trường terraform để giảm bớt mối lo ngại về việc đặt lại khi cập nhật tập hợp dịch vụ tổng hợp. Chúng tôi đang đánh giá yêu cầu này và sẽ chia sẻ thêm thông tin khi có.

Chúng tôi hoan nghênh ý kiến phản hồi bổ sung của hệ sinh thái về việc yêu cầu này có phải là yêu cầu ưu tiên hay không tại đây.
Tài liệu
Làm rõ		 Yêu cầu hướng dẫn về những nội dung có thể thay đổi (ví dụ: ngưỡng giám sát) và những nội dung không được thay đổi. Chúng tôi đang đánh giá việc phát hành tài liệu và hướng dẫn bổ sung về các tuỳ chọn tuỳ chỉnh hiện có cho dịch vụ tổng hợp.
Triển khai Yêu cầu làm rõ về việc triển khai mới không thành công tại lệnh bazel. Quá trình triển khai có thể không thành công do phiên bản bazel được sử dụng trong môi trường.

Tài liệu sẽ được điều chỉnh để bao gồm cả việc gỡ lỗi trên các lỗi Terraform cũng như cho biết phiên bản bazel bắt buộc.

Private Aggregation API

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Việc Sử Dụng API Yêu cầu hướng dẫn về một số thách thức trong quá trình triển khai, chẳng hạn như khả năng mất dữ liệu do các giới hạn đã báo cáo về Bộ nhớ dùng chung, khó khăn với số lượng giá trị riêng biệt cao đòi hỏi danh sách cho phép phức tạp của Dịch vụ tổng hợp (nên dùng ký tự đại diện) và quá trình kiểm thử bị chậm do quy tắc "không có bản sao" của Dịch vụ tổng hợp. Liên quan đến các giới hạn về Bộ nhớ dùng chung, hạn mức 20 lượt đóng góp (chi tiết tại đây) là cho mỗi lần thực thi, chứ không phải cho mỗi tháng. Ngoài ra, phương thức gọi API có thể ghi đè giới hạn này. Giới hạn này được áp dụng để giúp quản lý chi phí xử lý báo cáo trong dịch vụ tổng hợp chứ không phải để giới hạn tiện ích báo cáo.

Đối với truy vấn ký tự đại diện, chúng tôi đang đánh giá yêu cầu này và sẽ chia sẻ thêm thông tin chi tiết khi có.

Đối với quy tắc "không trùng lặp", để cho phép kiểm thử, chúng tôi tạm thời hỗ trợ chế độ gỡ lỗi nhằm mục đích bỏ qua quy tắc này. Bạn có thể xem thông tin chi tiết hơn tại đây .
Lọc mã nhận dạng và bộ chứa Có thể yêu cầu dịch vụ tổng hợp cùng một bộ chứa có hai mã lọc khác nhau trong hai lần chạy tổng hợp riêng biệt không, tức là mã lọc có thể đóng vai trò là một phân vùng bổ sung của các miền không? Có, tính năng này được hỗ trợ. Khi thực hiện tổng hợp, chỉ những nội dung đóng góp có mã nhận dạng lọc khớp với danh sách trong tham số công việc mới được xử lý, còn lại vẫn có thể được xử lý trong(các) lần chạy riêng biệt.
Mô hình phân bổ đa điểm Yêu cầu giải thích về việc triển khai mô hình Phân bổ nhiều lượt chạm (MTA):

1) Có giới hạn về số lượt đóng góp nếu giá trị tổng hợp không vượt quá 2^16 không?

2) Có giới hạn về số lượng khoá tổng hợp (vùng chứa) riêng biệt có thể được lưu trữ cho một ngữ cảnh nhất định không?

3) Dịch vụ tổng hợp xử lý báo cáo tóm tắt như thế nào khi mỗi tác nhân người dùng (trình duyệt) có một khoá tổng hợp duy nhất, như có thể xảy ra trong MTA?		 1) Chúng tôi đã đặt các giới hạn đóng góp mặc định, nhưng có các tuỳ chọn để phương thức gọi API ghi đè các giới hạn đó như giải thích tại đây. Mục đích của các giới hạn này là giúp phương thức gọi API quản lý chi phí xử lý báo cáo trong dịch vụ tổng hợp.

2) Không có giới hạn nào như vậy, mặc dù các công nghệ quảng cáo nên xem xét mức độ chi tiết của khoá tổng hợp để cải thiện tỷ lệ tín hiệu trên tạp âm, như được giải thích thêm tại đây.

3) Vui lòng xem hướng dẫn này, đặc biệt là hướng dẫn về tỷ lệ tín hiệu/nhiễu được đề cập ở mục 2 ở trên).

Giới hạn hoạt động theo dõi ẩn

Giảm thiểu tác nhân người dùng/Thông tin mô tả của ứng dụng tác nhân người dùng

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Yêu cầu tính năng Yêu cầu thêm Sec-CH-UA-Robot vào Gợi ý ứng dụng khách của User-Agent (UA-CH) vì điều này sẽ cho phép máy chủ xác định lưu lượng truy cập tự động để điều chỉnh nội dung, bảo mật và phân tích. Đây là một trường hợp sử dụng quan trọng đang được thảo luận trong các nhóm tiêu chuẩn khác (xem tại đây để biết thêm thông tin chi tiết). Các bên quan tâm nên tham gia bằng cách đưa ra ý kiến phản hồi. Tuy nhiên, chúng tôi cho rằng UA-CH có thể không phải là giải pháp phù hợp, vì lưu lượng truy cập tự động có thể dễ dàng thao túng các tiêu đề yêu cầu HTTP.

Bảo vệ tài sản trí tuệ (trước đây là Gnatcatcher)

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Quyền riêng tư về địa chỉ IP Việc để Google sử dụng địa chỉ IP trái ngược với các mục tiêu về quyền riêng tư mà Google đã nêu. Mặc dù Google tuyên bố rằng họ sẽ ẩn danh dữ liệu thông qua tính năng Bảo vệ IP, nhưng người dùng phải đăng nhập vào Chrome để sử dụng tính năng này, vì vậy, Google vẫn biết được danh tính của họ. Lý do đăng nhập là để chống gian lận và hành vi sai trái, chủ yếu là giới hạn tốc độ truy cập vào proxy.

Ngoài ra, để bảo vệ quyền riêng tư của người dùng trong bối cảnh yêu cầu xác thực, thiết kế mã thông báo của chúng tôi được ký ẩn, nghĩa là mã thông báo được phát hành trong quá trình đăng nhập khác với mã thông báo được sử dụng trong quá trình ủy quyền, do đó, các mã thông báo được phát hành không thể liên kết với danh tính của người dùng trên Google sau này. Điều này có nghĩa là Google không biết người dùng là ai khi lưu lượng truy cập của người dùng đó được proxy ở chế độ ẩn danh, mặc dù có yêu cầu xác thực vì lý do chống gian lận.
Quyền riêng tư về địa chỉ IP Việc sử dụng địa chỉ IP là một bước đi sai hướng. Bạn không thể xoá các tệp này khỏi trình duyệt như cookie và người dùng không có các chế độ kiểm soát tính minh bạch giống như với cookie. Nếu cookie không còn được dùng nữa, ngành quảng cáo sẽ chuyển sang sử dụng địa chỉ IP làm giải pháp thay thế, ưu tiên việc tự bảo vệ hơn là quyền riêng tư. Là một nền tảng, Chrome hướng đến việc cung cấp cho người dùng các tính năng giúp cải thiện trải nghiệm duyệt web. Đối với những người dùng Chrome chọn duyệt web ở Chế độ ẩn danh, điều đó có nghĩa là cung cấp các biện pháp bảo vệ nâng cao chống lại hành vi theo dõi trên nhiều trang web bằng cách hạn chế việc cung cấp thông tin địa chỉ IP trong ngữ cảnh của bên thứ ba.
Danh sách miền bị che Tiêu chí lựa chọn trên Danh sách miền được che giấu (MDL) là gì? Chrome đã phát triển các tiêu chí để xác định những miền nào nên có trong MDL và do đó nhận được địa chỉ IP bị che trong ngữ cảnh của bên thứ ba. Google đã hợp tác với Disconnect.me, một công ty hàng đầu về quyền riêng tư trên Internet, đồng thời cũng cộng tác với các trình duyệt web khác. Chrome sẽ tận dụng Disconnect.me để xác định những miền phù hợp với các tiêu chí mà Chrome đã thiết lập. Ngoài ra, Chrome đã phát triển một phương pháp để xác định các hàm JavaScript được sử dụng rộng rãi, cung cấp đầu ra nhất quán từ các API web ổn định và có độ hỗn loạn cao. Do đó, các hàm này có thể được dùng để tạo giá trị nhận dạng có xác suất cao và độ hỗn loạn cao. Sau đó, các hàm này được phát hiện khi được tải trên các trang web trong ngữ cảnh của bên thứ ba, dẫn đến danh sách các miền phân phát tập lệnh có các đặc điểm này trở thành một phần của MDL và do đó được proxy. Quy trình phát hiện tìm kiếm những mẫu hành vi sử dụng sai API này sẽ xem xét tất cả các miền, bao gồm cả các miền của chính Google.
Phòng chống gian lận Ý kiến phản hồi về Mã thông báo tiết lộ có xác suất (PRT) cho thấy độ trễ tiết lộ 24 giờ và tỷ lệ tiết lộ được đề xuất sẽ cản trở việc phát hiện gian lận theo thời gian thực. Yêu cầu độ trễ ngắn hơn (độ trễ 1 giờ) và tốc độ cao hơn (ít nhất là hai chữ số). Các đề xuất khác bao gồm việc bật mức giá khác biệt dựa trên các tín hiệu rủi ro (VPN, trình duyệt tự động) và cho phép tiết lộ có mục tiêu các mã thông báo cụ thể. Hầu hết các nhà phát triển mà chúng tôi đã trao đổi đều cung cấp báo cáo hằng giờ cho khách hàng và một số nhà phát triển cập nhật danh sách chặn IP trong suốt cả ngày. Khoảng thời gian trễ ngắn hơn sẽ cho phép cập nhật thường xuyên hơn và dưới một giờ sẽ bật lại tính năng đo lường IVT trong số liệu thống kê hằng giờ, nhưng cũng có thể làm tăng khả năng xác định lại người dùng. Chúng tôi sẵn sàng tìm hiểu cách giảm thời gian trì hoãn và thay đổi tốc độ tiết lộ dựa trên các nghiên cứu về hệ sinh thái cũng như ý kiến phản hồi của các bên liên quan. Bạn có thể gửi ý kiến phản hồi bổ sung tại đây.
Danh sách miền bị che Câu hỏi liên quan đến việc đưa miền vào MDL mặc dù không có trường hợp sử dụng quảng cáo. Lo ngại rằng việc này có thể cho phép "cầu nối IP" tạo hồ sơ dựa trên địa chỉ IP. Chúng tôi nhận thấy tầm quan trọng của việc triển khai quy trình khiếu nại đối với phương pháp dựa trên danh sách. Quy trình khiếu nại cho phép các công ty tuyên bố rằng miền của họ trên MDL không đáp ứng các tiêu chí để được đưa vào và cần phải bị xoá, nhờ đó cho phép miền đó tiếp tục nhận địa chỉ IP ban đầu của người dùng trong bối cảnh bên thứ ba ở chế độ Ẩn danh.

Chúng tôi hiện đã triển khai quy trình khiếu nại để chủ sở hữu miền có đủ thời gian khiếu nại và nhận quyết định trước khi chúng tôi ra mắt tính năng Bảo vệ quyền sở hữu trí tuệ ở chế độ ẩn danh trong Chrome phiên bản ổn định.

Bạn có thể xem thêm thông tin chi tiết về quy trình khiếu nại tại đây.
Danh sách miền bị che Ý kiến phản hồi cho biết nhà xuất bản đang điều tra những tác động của việc đối tác của họ có trong MDL. Họ đã được trấn an bằng các quy định về GeoIP trong phần Giải thích về biện pháp bảo vệ quyền sở hữu trí tuệ. Chrome nhận thấy tầm quan trọng của việc hỗ trợ các trường hợp sử dụng dựa trên vị trí địa lý. Proxy sẽ chỉ định địa chỉ IP đại diện cho vị trí thô của người dùng, bao gồm cả quốc gia. Bạn có thể xem thêm thông tin trong bài viết Giải thích về tính năng xác định vị trí địa lý qua địa chỉ IP.
Danh sách miền bị che Câu hỏi liên quan đến MDL về việc liệu bạn có thể sử dụng tính năng nhắm mục tiêu ở cấp quốc gia hay không. Chrome nhận thấy tầm quan trọng của việc hỗ trợ các trường hợp sử dụng dựa trên vị trí địa lý. Proxy sẽ chỉ định địa chỉ IP đại diện cho vị trí thô của người dùng, bao gồm cả quốc gia. Bạn có thể xem thêm thông tin trong bài viết Giải thích về tính năng xác định vị trí địa lý qua địa chỉ IP.
Phát hiện hành vi gian lận Mối lo ngại về tác động của tính năng Bảo vệ IP đối với hệ thống phát hiện gian lận. Người dùng sẽ thấy địa chỉ IP proxy hay tiêu đề? SSP và DSP có thấy cùng một địa chỉ IP proxy cho một mục đích sử dụng cụ thể không? Sự không nhất quán có thể ảnh hưởng đến tính năng phát hiện gian lận và OpenRTB. Những người dùng duyệt web ở chế độ Ẩn danh và bật tính năng Bảo vệ địa chỉ IP, đồng thời gửi yêu cầu đến các miền trên MDL sẽ nhận được địa chỉ IP proxy dựa trên nguồn cấp dữ liệu địa lý đã xác định. Các tổ chức có thể yêu cầu truyền PRT dưới dạng một tiêu đề bổ sung trên lưu lượng truy cập qua proxy, trong đó một mẫu nhỏ các IP ban đầu có thể được tiết lộ sau một khoảng thời gian trễ. Chúng tôi nghi ngờ nhiều SSP sẽ chuyển địa chỉ IP được proxy trong các yêu cầu giá thầu phía máy chủ cho các đối tác nhu cầu, nhưng không đảm bảo DSP chiến thắng sẽ thấy cùng một địa chỉ IP proxy tại thời điểm hiển thị.
Phát hiện hành vi gian lận Các câu hỏi về tần suất cập nhật tệp vị trí địa lý theo địa chỉ IP, thời gian cập nhật để biết thông tin chi tiết về việc báo cáo hành vi gian lận và PRT, cũng như cách công nghệ quảng cáo phát hiện hoạt động gian lận. Nội dung giải thích về PRT đã có hiệu lực, cũng như danh sách địa chỉ IP proxy và khu vực địa lý được liên kết của các địa chỉ đó. Bạn nên định kỳ kiểm tra tệp này để biết thông tin cập nhật và thay đổi, vì địa chỉ IP sẽ thay đổi theo thời gian. Địa chỉ email công khai để báo cáo hành vi sai trái sẽ được thông báo gần thời điểm ra mắt.
Vị trí địa lý Yêu cầu danh sách công khai các địa chỉ IP dùng cho proxy. Bạn có thể xem tệp liên kết địa chỉ IP với vị trí gần đúng để Bảo vệ quyền sở hữu trí tuệ tại đây. Xin lưu ý rằng tệp này được cập nhật định kỳ.
Việc Sử Dụng API Xác nhận rằng tính năng Bảo vệ địa chỉ IP dường như được bật theo mặc định và người dùng không có lựa chọn chọn không sử dụng. Tính năng Bảo vệ địa chỉ IP sẽ được cung cấp cho người dùng ở chế độ Ẩn danh của Chrome, trên nền tảng Android và máy tính. Người dùng có thể tắt tính năng Bảo vệ địa chỉ IP. Đối với các phiên bản Chrome do doanh nghiệp quản lý, bạn có thể bật tính năng Bảo vệ địa chỉ IP, nhưng tính năng này sẽ tắt theo mặc định.
Việc Sử Dụng API Truy vấn về việc có cờ thử nghiệm để bật và kiểm thử tính năng Bảo vệ quyền sở hữu trí tuệ trong các bản phát hành Chrome Canary và Beta hay không. Hiện tại, chúng tôi không có cờ thử nghiệm để thử nghiệm toàn bộ tính năng Bảo vệ quyền sở hữu trí tuệ. Các thử nghiệm chức năng mà chúng tôi đang tiến hành chỉ áp dụng cho lưu lượng truy cập proxy đến các miền của Google.
Quyền riêng tư về địa chỉ IP Chế độ cài đặt lời nhắc 3PC hoạt động như thế nào khi trình duyệt chuyển sang chế độ ẩn danh? Theo mặc định, 3PC sẽ bị chặn ở chế độ ẩn danh.
Chế độ ẩn danh Yêu cầu làm rõ liệu tính năng Bảo vệ địa chỉ IP có hoạt động ở Chế độ ẩn danh khi người dùng chưa đăng nhập vào Chrome hay không. Tính năng Bảo vệ địa chỉ IP sẽ không hoạt động nếu người dùng chưa đăng nhập vào Chrome trước khi khởi chạy Chế độ ẩn danh. Lý do là để chống gian lận và hành vi sai trái, cụ thể là giới hạn tốc độ truy cập vào proxy. Tính năng Bảo vệ IP sẽ sử dụng phương thức xác thực ứng dụng khách để hạn chế khả năng của các bên xấu trong việc tận dụng proxy để tăng cường các cuộc tấn công vào các dịch vụ trên MDL. Do đó, tính năng Bảo vệ địa chỉ IP sẽ chỉ dành cho những người dùng đã được xác thực bằng Tài khoản Google mà họ đăng nhập vào trình duyệt Chrome trước khi mở một cửa sổ Ẩn danh mới.
Chế độ ẩn danh Yêu cầu đánh giá tác động của tính năng Bảo vệ quyền sở hữu trí tuệ trước khi ra mắt, bao gồm:
(1) Đề xuất sử dụng cờ trạng thái trình duyệt hoặc báo cáo API tổng hợp để định lượng mức sử dụng chế độ ẩn danh;
(2) Gửi tiêu đề Bảo vệ quyền sở hữu trí tuệ trong một khoảng thời gian trước khi bật tính năng này; và
(3) Cung cấp tính năng này cho một tỷ lệ nhỏ lưu lượng truy cập đã biết để ngoại suy.		 Chúng tôi hiểu rằng hệ sinh thái quan tâm đến việc có thể hiểu và đo lường quy mô cũng như tác động của tính năng Bảo vệ quyền sở hữu trí tuệ. Tuy nhiên, Chrome luôn nỗ lực để đảm bảo rằng lựa chọn duyệt web ở Chế độ ẩn danh của người dùng là riêng tư. Chrome không tiết lộ phương thức phát hiện người dùng đang duyệt web ở chế độ Ẩn danh và đã thực hiện các bước để hạn chế các tín hiệu khác có thể tiết lộ chế độ duyệt web của người dùng.

Chúng tôi đang cân nhắc các cách để hỗ trợ việc kiểm thử này mà không ảnh hưởng đến quyền riêng tư của người dùng duyệt web ở chế độ Ẩn danh. Chúng tôi rất mong nhận được ý kiến phản hồi bổ sung từ hệ sinh thái.

Giảm hoạt động theo dõi tỷ lệ thoát

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Độ giãn nở Việc Google không muốn cho phép sử dụng kỹ thuật Giảm thiểu tính năng theo dõi lượt thoát (BTM) tuân thủ luật bảo vệ dữ liệu là không có cơ sở pháp lý và khiến quy trình khiếu nại về Hộp cát về quyền riêng tư trở nên vô nghĩa. Như đã giải thích trong báo cáo phản hồi trước, trạng thái tuân thủ không liên quan đến việc áp dụng BTM và Google không đưa ra quyết định nào liên quan đến việc tuân thủ trong quá trình triển khai BTM. BTM, giống như các biện pháp bảo vệ quyền riêng tư khác của Chrome, tập trung vào việc tăng cường quyền kiểm soát của người dùng đối với việc chia sẻ dữ liệu của họ cũng như cách thức chia sẻ.

Quy trình khiếu nại do bên thứ ba quản lý được đề cập trong Báo cáo quý 2/quý 3 của CMA chỉ dành cho những khu vực mà Google đang đưa ra quyết định về việc đưa hoặc loại trừ từng công ty khỏi danh sách.
Độ giãn nở Thảo luận về cách trình duyệt đảm bảo tuân thủ các hành động được đồng ý hợp pháp trong bối cảnh GDPR, nêu bật các trường hợp trình duyệt có thể ngăn chặn các hành động (như chuyển hướng hoặc đặt cookie) mà người dùng đã đồng ý rõ ràng, tạo ra xung đột giữa sự đồng ý hợp pháp và chế độ cài đặt quyền riêng tư của trình duyệt. Trình duyệt không có thông tin về bản chất mối quan hệ giữa người dùng và trang web. Ngoài ra, với hành vi hiện tại của BTM, đã có các giải pháp để người dùng đồng ý rõ ràng việc theo dõi lượt thoát từ một trang web nhất định.

Bạn có thể xem thêm thông tin về việc tuân thủ trong phần Câu hỏi thường gặp về việc tuân thủ liên quan đến quyền riêng tư.
Trang web có mục đích sử dụng kép Xin làm rõ liệu việc chuyển đổi từ WebView hoặc ứng dụng sang web (Chrome) có được coi là "trang web sử dụng kép" theo BTM không? Trình duyệt không biết liệu một chuỗi thoát có bắt đầu thông qua quá trình chuyển đổi từ WebView hay ứng dụng hay không.

Do đó, BTM không áp dụng bất kỳ biện pháp xử lý đặc biệt nào cho những luồng đó. Thay vào đó, Google Analytics sẽ diễn giải luồng này là một lượt thoát trên nhiều trang web bắt đầu từ "about:blank" và tiếp tục với hành vi tiêu chuẩn.

Tăng cường ranh giới quyền riêng tư trên nhiều trang web

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Việc Sử Dụng API Mối lo ngại về khả năng lợi dụng RWS cùng với tính năng Bảo vệ quyền sở hữu trí tuệ. Việc tiết lộ địa chỉ IP cho các tổ chức trong một nhóm RWS có thể khuyến khích các tổ chức tham gia nhiều nhóm RWS để có quyền truy cập vào dữ liệu Địa chỉ IP di động nhằm theo dõi người dùng Chế độ ẩn danh. Các yêu cầu đặt ra cho trang web được liên kết, trang web dịch vụ và toàn bộ bộ, được thực thi bằng quy trình xác thực tự động, giúp giảm thiểu mọi động cơ tiềm ẩn để cố gắng tham gia nhiều bộ.

Để kết hợp hoạt động của người dùng trên các nhóm thông qua địa chỉ IP, bạn cần thêm một miền MDL vào một nhóm. Điều này đòi hỏi sự phối hợp giữa chủ sở hữu nhóm và chủ sở hữu miền. Rủi ro tương tự cũng áp dụng cho các trang web đơn lẻ (tức là không có RWS) phối hợp với các miền MDL.

Chúng tôi đã trả lời câu hỏi này một cách chi tiết hơn tại đây.

Fenced Frames API

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Quảng cáo gốc Ý kiến phản hồi cho biết Khung được khoanh vùng, như được thiết kế hiện tại, không tương thích với mô hình kinh doanh quảng cáo gốc của họ, mô hình này yêu cầu quảng cáo phải linh hoạt thích ứng với nội dung xung quanh. Chúng tôi sẽ tiếp tục đánh giá nhu cầu của hệ sinh thái và dịch vụ Khung có phân vùng hiện tại. Trong mọi trường hợp, như đã nêu trước đó, Khung được phân vùng sẽ bắt buộc không sớm hơn năm 2026.

Shared Storage API

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Lỗi API Báo cáo rằng Chrome ghi lại lỗi khi cơ chế lập ngân sách của Shared Storage API ngăn hoạt động selectURL chạy, mặc dù đây là hành vi dự kiến. Yêu cầu Chrome hạ cấp cấp độ ghi nhật ký từ lỗi xuống cảnh báo hoặc thông tin, vì lỗi này không thể xử lý được đối với phương thức gọi. Thay đổi này đã được triển khai và đưa vào Chrome M134, có sẵn từ ngày 4 tháng 3 năm 2025.

Cookie có trạng thái được phân vùng độc lập (CHIPS)

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Tài liệu API Cần làm rõ về các biện pháp bảo vệ bảo mật mà cookie phân vùng cung cấp so với cookie SameSite=Lax/Strict. Đề xuất rằng tài liệu phải nêu rõ rằng cookie được phân vùng không cung cấp mức độ bảo vệ chống lại các cuộc tấn công XSS và CSRF giống như cookie SameSite=Lax/Strict. Chúng tôi sẽ cập nhật nội dung giải thích và thông số kỹ thuật để làm rõ ngữ nghĩa và biện pháp bảo vệ mà cookie phân vùng cung cấp.

FedCM

Chủ đề phản hồi Tóm tắt Phản hồi của Chrome
Giao diện người dùng và bảo mật Ý kiến phản hồi về giao diện người dùng FedCM quá giống với tính năng đăng nhập một lần trước đây của Google, khó định lượng hiệu suất của FedCM do thiếu tính năng theo dõi bản trình bày thụ động và đề xuất sử dụng ngôn ngữ tài liệu rõ ràng hơn về PKCE. Chúng tôi đang tích cực trao đổi với các bên liên quan để giải quyết ý kiến phản hồi của họ. Các khía cạnh đang được thảo luận bao gồm cách cung cấp các chỉ số tốt hơn cho Nhà cung cấp dịch vụ danh tính để họ có thể theo dõi hiệu suất của FedCM, cũng như các điểm cải tiến có thể áp dụng để giải quyết các trường hợp sử dụng mới của FedCM liên quan đến trường hợp sử dụng gói thuê bao.
Việc Sử Dụng API Khi người dùng làm mới trang và gọi navigator.credentials.get để đăng nhập, một cửa sổ bật lên sẽ xuất hiện, yêu cầu người dùng nhấp để tiếp tục, điều này gây ra độ trễ ảnh hưởng đến trải nghiệm người dùng. Các bên phụ thuộc (RP) có thể lưu mã thông báo do navigator.credentials.get trả về vào bộ nhớ đệm để cải thiện trải nghiệm người dùng không? RP có thể sử dụng cookie của riêng mình để lưu trữ mã thông báo. Sau đó, RP có thể kiểm tra cookie của riêng mình để xác định xem người dùng đã đăng nhập hay chưa trước khi gọi navigator.credentials.get. Chúng tôi đã giải quyết vấn đề này một cách chi tiết hơn tại đây.
Chọn nhiều IDP Trình duyệt sẽ hiển thị các tuỳ chọn đăng nhập cho nhiều nhà cung cấp dịch vụ danh tính (IdP) trong FedCM như thế nào? Tài liệu dành cho nhà phát triển có thông tin về cách hiển thị nhiều IdP. Các bên liên quan có thể thử nghiệm chức năng này bằng cách bật cờ fedcm-multi-idp trong chrome://flags.
Trình duyệt và IdP Một trình duyệt (chẳng hạn như Chrome) có thể tự hoạt động như một IdP không? Trình duyệt có thể sử dụng dữ liệu hồ sơ và tài khoản đã lưu trữ làm nguồn xác thực đáng tin cậy. Do trình duyệt có thể bị sửa đổi (ví dụ: thông qua tiện ích), nên mọi thông báo xác minh email do trình duyệt trực tiếp đưa ra đều không thể tin cậy nếu không có quy trình xác minh bổ sung dựa trên máy chủ. Do đó, bạn không nên sử dụng giải pháp chỉ dựa trên máy khách.

Chúng tôi đã thảo luận chi tiết hơn về vấn đề này tại đây.
Quy cách API Thảo luận về việc tham số cho thuật toán IdentityCredential.disconnect() có bắt buộc hay không. Vấn đề này hiện đã được khắc phục. Bạn có thể tìm thêm thông tin chi tiết tại đây.
Bảo mật API Mối lo ngại về việc rò rỉ mã thông báo trong quy trình đăng nhập FedCM nếu RP có lỗ hổng XSS. Kẻ tấn công có thể thực thi navigator.credentials.get trong mã độc hại để lấy mã thông báo. FedCM không tạo ra các rủi ro XSS mới; những rủi ro này vốn có trong các ứng dụng web và giao thức xác thực hiện có. Để giảm thiểu những rủi ro này, RP phải xác minh thông báo xác nhận aud trong mã thông báo nhận dạng và chỉ chấp nhận các xác nhận được phát hành ở nguồn gốc của chính họ. Như đã thảo luận tại đây, hiện có các phương pháp hay nhất được thiết lập rộng rãi để bảo mật hoạt động trao đổi mã thông báo này và bạn có thể sử dụng các phương pháp này với FedCM.

Ngoài ra, bạn có thể sử dụng API Truy cập bộ nhớ với FedCM và các lệnh gọi API Truy cập bộ nhớ sẽ tự động được cấp khi có lệnh gọi FedCM trước đó. Thao tác này sẽ bật quy trình chuyển hướng được nhúng được thảo luận trong vấn đề trên GitHub.
Quy cách API client_metadata_endpoint là trường bắt buộc trong phản hồi điểm cuối cấu hình cho FedCM. Đối tượng trống là một phản hồi hợp lệ và Chromium sẽ tự động bỏ qua phản hồi 404, cho thấy rằng điểm cuối được coi là không bắt buộc trong thực tế. Chúng tôi đồng ý rằng có thể thay đổi thông số kỹ thuật để phản ánh điều này và đặt client_metadata_endpoint làm trường không bắt buộc.
Việc Sử Dụng API Mối lo ngại về việc khó kiểm thử việc triển khai FedCM do không thể truy cập vào giao diện người dùng do trình duyệt kiểm soát thông qua DOM. Chúng tôi hỗ trợ các API tự động hoá trình duyệt để kiểm thử hồi quy, có thể giải quyết những vấn đề này. Các API này được ghi lại tại đây.
Quy cách API Tham số login_url (là một phần bắt buộc của phản hồi của điểm cuối cấu hình) không được ghi lại trong Mục 3.2 của quy cách. Chúng tôi đã gửi nội dung cập nhật vào tài liệu để thêm tham số login_url vào Mục 3.2.
Quy cách API Mối lo ngại về một vectơ theo dõi tiềm ẩn trong FedCM. Một IdP có thể chèn mã nhận dạng dưới dạng tham số đường dẫn vào các điểm cuối được chỉ định trong phản hồi điểm cuối cấu hình (accounts_endpoint, client_metadata_endpoint) và sử dụng các mã nhận dạng này để liên kết các yêu cầu siêu dữ liệu của tài khoản và ứng dụng. Mặc dù không có bằng chứng về việc IdP chèn mã nhận dạng vào các điểm cuối này, nhưng chúng tôi đang tích cực xem xét các biện pháp giảm thiểu để giải quyết vấn đề này tại đây.

Chống hành vi gian lận và nội dung rác

Private State Tokens API (và các API khác)

Chúng tôi không nhận được ý kiến phản hồi nào trong quý này.