Báo cáo phản hồi – Quý 2 và Quý 3 năm 2024

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

Trong khuôn khổ cam kết với CMA, Google đã đồng ý công bố báo cáo hằng quý về quy trình tương tác với các bên liên quan đối với các đề xuất về Hộp cát về quyền riêng tư (tham khảo đoạn 12 và 17(c)(ii) của Cam kết). Vào ngày 22 tháng 7 năm 2024, Google thông báo rằng họ sẽ không ngừng sử dụng cookie của bên thứ ba (3PC) trên Chrome. Thay vào đó, họ đề xuất giới thiệu một phương pháp mới để nâng cao quyền lựa chọn của người dùng. Do đó, theo thoả thuận với CMA, Google đã không gửi báo cáo công khai quý 2 năm 2024 cho CMA để có đủ thời gian cho Google và CMA xem xét các tác động của thông báo của Google.

Các báo cáo tóm tắt phản hồi về Hộp cát về quyền riêng tư này được tạo bằng cách tổng hợp phản hồi mà Chrome nhận được từ nhiều nguồn như được liệt kê trong phần tổng quan về phản hồi, bao gồm nhưng không giới hạn ở: Vấn đề trên GitHub, biểu mẫu phản hồi được cung cấp trên privacysandbox.com, các cuộc họp với các bên liên quan trong ngành và diễn đàn về tiêu chuẩn web. Chrome hoan nghênh ý kiến phản hồi nhận được từ hệ sinh thái và đang tích cực tìm hiểu cách tích hợp những điều đã học được vào các quyết định thiết kế.

Các chủ đề phản hồi được xếp hạng theo mức độ phổ biến trên mỗi API. Việc này được thực hiện bằng cách tổng hợp số lượng ý kiến phản hồi mà nhóm Chrome đã nhận được về một chủ đề nhất định và sắp xếp theo thứ tự giảm dần về số lượng. Các chủ đề phản hồi phổ biến được xác định bằng cách xem xét các chủ đề thảo luận từ các cuộc họp công khai (W3C, PatCG, IETF), phản hồi trực tiếp, GitHub và các câu hỏi thường gặp xuất hiện thông qua các nhóm nội bộ và biểu mẫu công khai của Google.

Cụ thể hơn, chúng tôi đã xem xét biên bản họp của các cơ quan tiêu chuẩn trên web và để lấy ý kiến phản hồi trực tiếp, chúng tôi đã xem xét hồ sơ của Google về các cuộc họp 1:1 với các bên liên quan, email mà từng kỹ sư nhận được, danh sách gửi thư API và biểu mẫu phản hồi công khai. Sau đó, Google đã điều phối giữa các nhóm tham gia vào nhiều hoạt động tiếp cận này để xác định mức độ phổ biến tương đối của các chủ đề mới nổi liên quan đến từng API.

Nội dung giải thích về phản hồi của Chrome đối với ý kiến phản hồi được phát triển từ các câu hỏi thường gặp đã xuất bản, phản hồi thực tế đối với các vấn đề do các bên liên quan nêu ra và xác định một quan điểm cụ thể cho mục đích của bài tập báo cáo công khai này. Phản ánh trọng tâm hiện tại của hoạt động phát triển và thử nghiệm, chúng tôi nhận được các câu hỏi và ý kiến phản hồi cụ thể liên quan đến API Chủ đề, Protected Audience và Attribution Reporting.

Phản hồi nhận được sau khi kết thúc khoảng thời gian báo cáo hiện tại có thể chưa có phản hồi được xem xét của Chrome.

Bảng chú giải thuật ngữ 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

Khung hình/giây

Nhóm bên thứ nhấ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

API PAT

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

Nhóm tin cậy

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

TEE (Môi trường thực thi đáng tin cậy)

Môi trường thực thi đáng tin cậy

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
Ngừng sử dụng cookie của bên thứ ba (3PCD)	Kế hoạch của Google về 3PCD là gì và có tác động lâu dài đến ngành quảng cáo kỹ thuật số không?	Chúng tôi đề xuất một phương pháp mới giúp nâng cao lựa chọn của người dùng. Như đã nêu tại đây, thay vì ngừng sử dụng 3PC, chúng tôi sẽ ra mắt một trải nghiệm mới trong Chrome để giúp mọi người đưa ra lựa chọn sáng suốt áp dụng cho hoạt động duyệt web của họ. Họ cũng có thể điều chỉnh lựa chọn đó bất cứ lúc nào. Chúng tôi đang thảo luận về lộ trình mới này với các cơ quan quản lý, đồng thời sẽ trao đổi với ngành trước khi triển khai quy trình này.
Lựa chọn của người dùng	Thông báo về lựa chọn của người dùng đã tác động đến mối quan tâm của hệ sinh thái trong việc áp dụng các giải pháp Hộp cát về quyền riêng tư. Có nhiều ý kiến phản hồi liên quan đến thông báo về lựa chọn của người dùng, trong đó có yêu cầu về các tính năng như khả năng giám sát.	Với phương pháp mới giúp nâng cao quyền lựa chọn của người dùng, nhà phát triển vẫn cần có các giải pháp thay thế giúp tăng cường quyền riêng tư cho giá trị nhận dạng trên nhiều trang web. Mặc dù chưa có thông tin chi tiết để chia sẻ về trải nghiệm mới này, nhưng chúng tôi dự kiến lưu lượng truy cập không có cookie trong Chrome sẽ tăng lên đáng kể. Điều này có nghĩa là API Hộp cát về quyền riêng tư vẫn rất quan trọng đối với doanh nghiệp. Chúng tôi sẽ tiếp tục đầu tư vào các công nghệ Hộp cát về quyền riêng tư để ngày càng nâng cao quyền riêng tư và sự tiện dụng.
Giao diện người dùng Lựa chọn của người dùng	Các câu hỏi về tiến trình triển khai tính năng chọn không tham gia/đồng ý, loại lựa chọn của người dùng đang được xem xét và mức độ ảnh hưởng của giao diện người dùng đối với môi trường kiểm thử tự động.	Hiện tại, chúng tôi chưa có thông tin cập nhật về tiến trình. Sau khi quyết định không tiếp tục phát triển 3PCD, chúng tôi muốn cập nhật thông tin cho hệ sinh thái sớm nhất có thể. Chúng tôi sẽ chia sẻ thông tin cập nhật về tiến trình lựa chọn của người dùng ngay khi có lựa chọn.
Kiểm thử Chrome	Yêu cầu tiếp tục cung cấp Nhãn thử nghiệm do Chrome hỗ trợ để đo lường mức độ sử dụng của thị trường và tác động kinh tế của 3PCD sau nửa đầu năm 2024.	Chúng tôi hiểu rằng các nhà kiểm thử sẽ muốn tiếp tục sử dụng các nhóm trình duyệt được gắn nhãn để kiểm thử và điều phối ngay cả khi quá trình kiểm thử do Chrome hỗ trợ kết thúc vào nửa đầu năm 2024. Chúng tôi đang đánh giá các bước tiếp theo đối với nhãn dựa trên thông báo về lựa chọn của người dùng. Trong thời gian chờ đợi, nhóm Chrome đã công bố ý định mở rộng dịch vụ hỗ trợ cho các nhóm trình duyệt được gắn nhãn thông qua Chrome Milestone 132, chạy đến hết tháng 1 năm 2025.
Hộp cát về quyền riêng tư trên Android	Hộp cát về quyền riêng tư trên Android và Hộp cát về quyền riêng tư trên Chrome có mối liên kết chặt chẽ với nhau và chúng tôi không thể đánh giá đúng Hộp cát về quyền riêng tư nếu không có Android. Hành trình điển hình của khách hàng, bao gồm các khía cạnh trên nhiều thiết bị và nhiều thao tác chạm, là yếu tố quan trọng đối với cả Hộp cát về quyền riêng tư trên Chrome và Hộp cát về quyền riêng tư trên Android.	Xin lưu ý rằng Hộp cát về quyền riêng tư trên Android không thuộc phạm vi Cam kết của Google đối với CMA. Nếu ý kiến phản hồi của bạn liên quan đến tiến trình và thời gian ra mắt của Android, thì hiện tại, chúng tôi chưa có thông tin cập nhật nào để chia sẻ, ngoài việc chúng tôi sẽ tiếp tục phát triển Android. Chúng tôi coi Android là một luồng công việc độc lập để cải thiện quyền riêng tư. Như chúng tôi đã lưu ý trước đây, khả năng sử dụng API Hộp cát về quyền riêng tư trên Android cũng sẽ được xác định theo tốc độ người dùng cập nhật thiết bị của họ. Điều này không thuộc quyền kiểm soát của Google.
Lưu lượng truy cập ở chế độ B bị giới hạn	Lưu lượng truy cập đấu giá quảng cáo có sẵn từ Chế độ B thấp hơn dự kiến.	Có nhiều lý do khiến số lượng phiên đấu giá cho Protected Audience API (PA API) có thể thấp hơn dự kiến, ví dụ: – Những công ty mà chúng tôi biết đã tích hợp PA API chỉ bao gồm các định dạng biểu ngữ. – Nền tảng bên bán không phải lúc nào cũng kích hoạt phiên đấu giá. – Một trình duyệt có thể không có Nhóm mối quan tâm (IG). – Có thể không có giá thầu nào. Tuy nhiên, chúng tôi không biết bất kỳ ai đã cố gắng thử nghiệm API PA nhưng không nhận được lưu lượng truy cập nào.
Chế độ hiển thị thời gian ngừng hoạt động	Thông tin về các sự cố ngừng hoạt động và vấn đề ảnh hưởng đến API Hộp cát về quyền riêng tư.	Các API Hộp cát về quyền riêng tư có các dịch vụ bên ngoài trình duyệt có trang trạng thái công khai. Nhóm Chrome đặt ưu tiên cao nhất vào độ tin cậy của nền tảng và tất cả các API quan trọng mà các trang web và dịch vụ lớn trên web sử dụng, bao gồm cả các công nghệ Hộp cát về quyền riêng tư. Cho đến nay, chỉ có một lần ngừng hoạt động. Vấn đề này liên quan đến cấu hình tạm thời để kiểm thử ở mức 1%. Cấu hình thử nghiệm liên quan đến sự cố ngừng hoạt động này sẽ sớm không còn cần thiết nữa. Vì vậy, chúng tôi tin tưởng rằng vấn đề này sẽ không xảy ra sau khi các API được bật theo cách thông thường trong Chrome.
Nghiên cứu biểu đồ cookie	Quan điểm của Chrome về phương thức CookieGraph như được mô tả trong bài viết này trong khung Hộp cát về quyền riêng tư là gì?	Bài báo nêu một số điểm thú vị liên quan đến việc phát hiện và mức độ phổ biến của cookie của bên thứ nhất (1P) do các miền khác với miền mà người dùng truy cập đặt. Như bài báo đã chỉ ra, những cookie này cực kỳ hữu ích trong việc thu thập thông tin phân tích và thông tin về cách người dùng tương tác với một trang web. Dữ liệu này rất quan trọng để nhà phát triển có thể mang đến trải nghiệm duyệt web tốt hơn cho người dùng. Luận điểm chính của bài báo này có khiếm khuyết vì coi cookie của bên thứ nhất là một vectơ theo dõi trên nhiều trang web. Tuy nhiên, điều này chỉ đúng trong các giả định rất táo bạo được nêu trong bài báo: Người dùng sẵn sàng chia sẻ PII của họ với trang web. Thiết bị có vân tay ổn định có thể dùng để theo dõi người dùng trên các trang web. Xin lưu ý rằng đây là những vectơ nhận dạng lại có thể bị khai thác mà không cần dùng cookie của bên thứ nhất (ví dụ: thông qua việc chia sẻ dữ liệu phía máy chủ) và cần được xử lý riêng biệt với nỗ lực hiện tại của chúng tôi là tập trung vào cơ chế theo dõi dựa trên trạng thái như 3PC. Cuối cùng, chúng tôi muốn chỉ ra rằng tài liệu này đồng nhất cookie phân tích và cookie quảng cáo với cookie theo dõi và cookie cần thiết nghiêm ngặt với cookie không theo dõi, điều này không nhất thiết phải đúng. Thật vậy, số liệu phân tích của bên thứ nhất hoặc các dịch vụ của nhà cung cấp được phân vùng theo trang web như tiện ích định vị cửa hàng, tiện ích trò chuyện hoặc cookie bộ cân bằng tải thường chỉ được giới hạn ở một miền. Ngược lại, một số cookie cần thiết nghiêm ngặt có thể theo dõi trên nhiều trang web cho mục đích chống gian lận.
Thay đổi về trải nghiệm người dùng	Những thay đổi về trải nghiệm người dùng trong Chrome 112 đặt các chế độ kiểm soát cookie của bên thứ nhất trong phần "dữ liệu trang web trên thiết bị" của phần cài đặt Chrome có thể khiến người dùng khó chặn tất cả cookie hơn.	Thay đổi này được thực hiện nhằm tách biệt và nâng cao các chế độ kiểm soát cho 3PC (hoặc bộ nhớ chưa phân vùng) khỏi tất cả các loại dữ liệu trang web khác. Các chế độ kiểm soát 3PC được nâng cao trong bảng Quyền riêng tư và bảo mật; trong khi các chế độ kiểm soát đối với cookie của bên thứ nhất và mọi loại dữ liệu trang web khác (mà chức năng quan trọng của trang web thường phụ thuộc) được nhóm trong phần "Dữ liệu trang web trên thiết bị". Chúng tôi sẽ tiếp tục theo dõi ý kiến phản hồi về chủ đề này, nhưng tin rằng việc tách biệt hiện tại đã tạo ra sự cân bằng tốt giữa khả năng tìm thấy các chế độ kiểm soát quyền riêng tư có ý nghĩa và việc duy trì trải nghiệm duyệt web hiệu quả.
Hoá đơn và thanh toán	Hoạt động thanh toán và lập hoá đơn chưa được thử nghiệm đầy đủ vì các nhân viên kiểm thử đang tập trung nhiều hơn vào việc thử nghiệm các khía cạnh khác của API Hộp cát về quyền riêng tư.	Họ là người quyết định thời điểm và nội dung mà nhà phát triển cũng như công ty chọn thử nghiệm. Các API này được cung cấp rộng rãi để thử nghiệm kể từ tháng 9 năm 2023.
Thử nghiệm	Không phải tất cả lưu lượng truy cập thử nghiệm mà DSP nhận được từ SSP đều được gắn nhãn. Một số DSP đã gửi thông tin cho biết tỷ lệ phần trăm lượt hiển thị thử nghiệm chưa được gắn nhãn có thể khác nhau giữa nhóm đối chứng và nhóm thử nghiệm.	Chrome không thể kiểm soát việc công ty có chuyển tiếp nhãn trong yêu cầu giá thầu hay không. Chúng tôi cung cấp một phương thức để lấy nhãn từ trình duyệt. Sau đó, hệ sinh thái sẽ chuyển nhãn cho các đối tác nếu các đối tác không thể đọc trực tiếp các nhãn đó.
3PCD trên Android WebView	Yêu cầu hướng dẫn về cách bật cờ "Kiểm thử việc loại bỏ cookie của bên thứ ba" trong Android WebView để kiểm thử việc ngừng sử dụng.	Theo mặc định, 3PC sẽ bị chặn trong Android WebView.
Sự riêng tư biệt lập để giảm thiểu rủi ro trong quá trình Huấn luyện mô hình	Tại sao giải pháp Sự riêng tư biệt lập được sử dụng trong quá trình huấn luyện mô hình?	Tính năng Sự riêng tư biệt lập kết hợp với Môi trường thực thi đáng tin cậy (TEE) là yếu tố thiết yếu trong quá trình huấn luyện mô hình để ngăn chặn rò rỉ dữ liệu và bảo vệ thông tin nhạy cảm khỏi các mối đe doạ. Phương pháp này đảm bảo trọng số của mô hình không thể tiết lộ dữ liệu người dùng cá nhân.

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

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Đăng ký	Yêu cầu làm rõ cách hoạt động của quy trình đăng ký chứng thực giữa máy chủ gốc đã đăng ký và máy chủ gốc của công nghệ quảng cáo có miền con www.	Công nghệ quảng cáo sẽ chỉ cần tham gia trên https://example.com. Khi họ đặt chứng thực trong https://example.com/.well-known/privacy-sandbox-attestations.json, https://www.example.com sẽ được bao gồm vì đó là miền con.
Thông số kỹ thuật API	Đề xuất thêm giản đồ JSON cho tệp chứng thực vào kho lưu trữ.	Chúng tôi đang đánh giá đề xuất này và hoan nghênh ý kiến phản hồi bổ sung tại đâ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
Trọng số chủ đề	Điều quan trọng nhất cần hiểu trong chủ đề là mức độ hiếm của một tín hiệu nhất định. Thiết kế hiện tại cần phát triển để cho phép thêm giá trị trọng số bên cạnh mỗi chủ đề được quan sát. Trọng số sẽ là trọng số tương đối của một chủ đề nhất định cho một trình duyệt so với tất cả các trình duyệt sử dụng chủ đề này.	Chúng tôi muốn tìm hiểu thêm về lý do khiến độ hiếm của tín hiệu là tín hiệu quan trọng nhất. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung của hệ sinh thái về tiện ích của trường hợp sử dụng này tại đây.
Độ tin cậy của chủ đề	Google cần đảm bảo chắc chắn hơn về độ tin cậy của Chủ đề theo thời gian.	Chúng tôi sẽ tiếp tục điều chỉnh API dựa trên ý kiến phản hồi về hệ sinh thái và sẽ thảo luận công khai trước khi áp dụng các thay đổi. Đề xuất của chúng tôi về cấu trúc quản trị đã sửa đổi sẽ mang lại thêm sự đảm bảo.
Thuật toán phân loại	Trang web của nhà xuất bản thường bị phân loại sai hoặc được chỉ định Chủ đề quá tổng quát để phục vụ bất kỳ mục đích có ý nghĩa nào.	Như đã nêu trong nội dung giải thích về việc phân loại Chủ đề, các trang web được phân loại thông qua sự kết hợp giữa danh sách ghi đè do con người tuyển chọn (chứa các trang web phổ biến nhất) và mô hình học máy trên thiết bị. Chrome tiếp tục đánh giá các lựa chọn cho các trang web để đóng góp vào việc phân loại Chủ đề. Mọi cải tiến về tiện ích đều phải được xem xét trước rủi ro về quyền riêng tư và hành vi sử dụng sai mục đích. Ví dụ: một số rủi ro bao gồm: – các trang web sử dụng tính năng tự gắn nhãn làm phương thức mã hoá các ý nghĩa khác nhau (và có thể nhạy cảm) vào chủ đề; và – các trang web tấn công chủ đề để làm giảm tính hữu ích của chủ đề đó đối với người khác (ví dụ: gửi thư rác vào chủ đề của người dùng bằng nội dung vô nghĩa). Mọi người có thể kiểm tra các thành phần này bằng các công cụ có sẵn thông qua chrome://topics-internals hoặc công cụ cộng tác này. Thông qua thử nghiệm, chúng tôi hy vọng việc phân loại sẽ cải thiện theo thời gian. Đồng thời, chúng tôi hoan nghênh ý kiến phản hồi về các ví dụ về trang web có thể bị phân loại sai.
Câu hỏi về API	Lo ngại rằng Topics API mang lại lợi ích liên tục và chống cạnh tranh cho các SSP kiếm tiền từ nội dung xấu.	Giống như 3PC, trình duyệt không quan tâm đến việc trả về Chủ đề cho ai, miễn là thực thể đó được đăng ký và chứng thực.
(Cũng được báo cáo trong những quý trước) Tính hữu ích của các loại bên liên quan khác nhau	Vì bộ phân loại Chủ đề hiện chỉ sử dụng tên máy chủ của trang để xác định các chủ đề tương ứng, nên các trang web lớn có nội dung đa dạng đang đóng góp các chủ đề chung chung, trong khi các trang web nhỏ đang đóng góp các chủ đề chuyên biệt có giá trị quảng cáo cao hơn.	Câu trả lời của chúng tôi tương tự như các quý trước: Giống như 3PC, giá trị của thông tin do các trang web đóng góp có sự khác biệt. Các trang web về chủ đề hẹp không nhất quán trong việc đóng góp giá trị: không phải tất cả trang web về chủ đề hẹp đều có bối cảnh có giá trị thương mại, do đó đóng góp ít giá trị hơn. Đây là những trang web sẽ được hưởng lợi từ Topics API. Chúng tôi đã cân nhắc khả năng phân loại ở cấp trang thay vì cấp trang web. Tuy nhiên, việc phân loại như vậy có một số vấn đề đáng quan ngại về quyền riêng tư và bảo mật.
Công cụ phân loại	Các trang web nhỏ thường được chỉ định một cách phân loại không chính xác hoặc không được phân loại nên không thể tham gia trao đổi giá trị.	Về việc bị cáo buộc gây hại, các trang web cụ thể có thể bị phân loại sai sẽ không bị ảnh hưởng nhiều hơn so với các trang web khác, vì thông tin theo bối cảnh của trang web sẽ luôn có sẵn cho các phiên đấu giá trên trang web của họ, từ đó cung cấp thông tin tương đương với chủ đề chính xác, ngay cả trong trường hợp phân loại sai. Chủ đề thường được dùng để thu thập thông tin quảng cáo có thể hữu ích từ các trang web bên ngoài, thay vì trang web của chính họ.
Phiên bản phân loại	Làm cách nào để truy cập vào phiên bản phân loại để đảm bảo khả năng tương thích ngược?	Phiên bản phân loại là một phần của tiêu đề yêu cầu được gửi cùng với yêu cầu tìm nạp có hỗ trợ chủ đề. Ví dụ: nếu tiêu đề là "(1 2);v=chrome.1:2:5, ();p=P000000000" thì phiên bản là chrome.1:1:2. Trong đó, chrome.1 là phiên bản cấu hình, 2 là phiên bản phân loại và 5 là phiên bản mô hình. Thông tin này được mô tả trong thông số kỹ thuật và cũng đã được thêm vào nội dung giải thích.
Dữ liệu về chủ đề	Yêu cầu giải thích về cách cập nhật dữ liệu Chủ đề.	Bạn chưa chỉ định nội dung cập nhật về cách phân loại. Điều này mang lại cho nhà cung cấp trình duyệt sự linh hoạt trong việc triển khai. Như vậy, dưới đây là các suy đoán về quá trình cập nhật hệ thống phân loại của Chrome từ phiên bản 1 lên phiên bản 2: – Một cây phân loại duy nhất được duy trì cho các chủ đề từ cả phiên bản 1 và phiên bản 2. – Mã chủ đề giống nhau và có cùng ý nghĩa. – Cây chỉ phát triển – thêm các chủ đề hoặc mối liên kết mới, không bao giờ thu hẹp. – Tuy nhiên, một số chủ đề hoặc đường liên kết có thể ở trạng thái "không hoạt động" trong một phiên bản, khiến người dùng có cảm giác như bị xoá hoặc sắp xếp lại. Ví dụ: – Nhóm "Xe bán tải" hiện có vai trò trung gian là "Xe tải, xe van và xe SUV". – "Foreign Language Study" (Học ngoại ngữ) hiện có "Education" (Giáo dục) làm thành phần mẹ thứ hai và thành phần mẹ ban đầu "Reference" (Tài liệu tham khảo) sẽ không hoạt động. Mức tác động của các chủ đề "không hoạt động": Những chủ đề này sẽ không được dùng để phân loại mới. Tuy nhiên, các chủ đề con vẫn được xem xét khi thực thi lệnh chặn của người dùng: nếu người dùng chặn một chủ đề trong V1, thì các chủ đề con của chủ đề đó vẫn bị chặn trong V2 (ngay cả khi chủ đề con xuất hiện trong một chủ đề mẹ khác trong V2).
Thuật toán phân loại	Tìm hiểu nguyên nhân và các phương án khắc phục hiện có liên quan đến việc phân loại không chính xác.	Trước tiên, chúng tôi muốn chỉ ra rằng việc Chrome xác định chủ đề của một trang web chỉ để dùng làm dữ liệu đầu vào cho thuật toán Chủ đề nhằm xác định mối quan tâm của người dùng cho mục đích quảng cáo. Dữ liệu này không được phát triển cho các mục đích phân loại khác, chung chung hơn. Chúng tôi quan tâm đến độ chính xác tổng thể của mô hình phân loại và cố gắng cải thiện độ chính xác/khả năng gợi nhắc của mô hình này nếu có thể, nhưng ở cấp toàn cầu thay vì cấp phân loại trang web riêng lẻ. Lý do là việc phân loại sai (nếu có) không gây hại cho trang web riêng lẻ đã bị phân loại sai, mà chỉ làm giảm chất lượng của tín hiệu Chủ đề khi chọn quảng cáo trên các trang web khác. Khi chọn quảng cáo trên trang web bị phân loại sai, trang web đó đã biết các chủ đề thực sự của trang web và có thể dùng các chủ đề đó làm dữ liệu đầu vào cho các truy vấn quảng cáo. 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.
Kiểm thử API	Có thể kiểm thử Topics và nói chung là các API Hộp cát về quyền riêng tư bằng Chromium không?	Topics API không được phân phối cùng với Chromium mà được phân phối cùng với Chrome.
Topics Caller	Yêu cầu cải thiện giá trị gia tăng của Chủ đề để tận dụng dịch vụ TEE cho các công nghệ quảng cáo nhằm hỗ trợ chi phí cho hoạt động phân tích nâng cao theo cách tuân thủ quyền riêng tư.	Chúng tôi đã phản hồi ý kiến phản hồi tương tự tại đây. Chúng tôi đã xem xét tần suất nghịch đảo và cuối cùng, sau khi lập mô hình tần suất nghịch đảo, chúng tôi nhận thấy tần suất nghịch đảo không tương quan tốt với giá trị chủ đề theo giá trị do người mua và người bán cung cấp. 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.
Thông số kỹ thuật của API	Chế độ cài đặt nhóm mối quan tâm của trình duyệt có thể chặn Topics API không?	Chúng tôi đã trả lời ý kiến phản hồi này tại đây. Topics API là một bản phát triển của FLoC và tuân thủ chính sách về quyền của FLoC. Như đã nêu trong nội dung giải thích: "Lưu ý: Chính sách quyền cũ: interest-cohort=() từ FLoC cũng sẽ cấm tính toán chủ đề."
Thứ hạng theo chủ đề	Khi nhận được "5 chủ đề hàng đầu", chúng ta có tính tần suất truy cập trang web dựa trên từng lệnh gọi đủ điều kiện hay luôn tính dựa trên toàn bộ nhật ký truy cập của trình duyệt? Hơn nữa, các chủ đề có được xếp hạng riêng cho từng người gọi không?	Chỉ số này dựa trên tần suất của một số trang trong nhật ký duyệt web. Một mục trong nhật ký duyệt web (một trang) chỉ đủ điều kiện tham gia nếu trang đó có ít nhất một lệnh gọi Chủ đề. Bạn có thể xem thêm thông tin chi tiết về tính năng lưu trữ nhật ký của các chủ đề tại đây. Như đã nêu trong thông báo về các tính năng nâng cao của Topics API, thứ hạng phụ thuộc vào tần suất và cũng phụ thuộc vào mức độ ưu tiên nhị phân (xem tại đây và tại đây để biết thêm thông tin chi tiết). Tuy nhiên, điều này không phụ thuộc vào tần suất của phương thức gọi. Xin lưu ý rằng điều này không có nghĩa là tất cả phương thức gọi đều có thể nhận được cả 5 chủ đề hàng đầu trong thời gian bắt đầu tiếp theo của hệ thống. Như đã nêu trong phần giải thích, "Chỉ những phương thức gọi quan sát thấy người dùng truy cập vào một trang web về chủ đề được đề cập trong vòng 3 tuần qua mới có thể nhận được chủ đề đó". Trình duyệt cần theo dõi xem lệnh gọi nào đã quan sát 5 chủ đề hàng đầu (tương ứng với 5 chủ đề hàng đầu có miền của lệnh gọi trong thông số kỹ thuật). Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn về vấn đề này tại đây.

Protected Audience API (trước đây là FLEDGE)

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
(Cũng được báo cáo trong các quý trước) Chi phí	Chi phí chạy TEE trong đám mây công khai có đắt hơn so với trung tâm dữ liệu công nghệ quảng cáo tại chỗ không?	Mô hình bảo mật TEE hiện tại của chúng tôi được hưởng lợi từ các phương pháp triển khai đám mây công khai (xem thêm thông tin chi tiết trong nội dung giải thích về các yêu cầu đối với TEE trên đám mây công khai). Ví dụ: TEE dựa trên phần cứng hiện tại không bảo vệ được trước mọi cuộc tấn công vật lý. Các nhà cung cấp dịch vụ đám mây công cộng hiện được hỗ trợ của chúng tôi, bao gồm AWS và GCP, đã thiết kế và triển khai các biện pháp giảm thiểu rủi ro truy cập thực tế, bao gồm cả rủi ro từ nhân viên. Mặc dù một số công nghệ quảng cáo đã đề cập với chúng tôi rằng việc chạy dịch vụ trên đám mây tốn kém hơn so với các trung tâm dữ liệu công nghệ quảng cáo tại chỗ, nhưng các công nghệ quảng cáo khác lại chạy trên đám mây công khai, cho dù đó là vì chi phí hay các lợi ích khác. Chúng tôi sẽ tiếp tục đánh giá các phương án để mở rộng khả năng hỗ trợ TEE, kể cả bên ngoài nền tảng đám mây công khai. Trong đó, chúng tôi đang nghiên cứu các trung tâm dữ liệu tại chỗ và đang tham gia vào hệ sinh thái để khám phá các giải pháp tiềm năng nhằm cung cấp dịch vụ hỗ trợ như vậy. Ở giai đoạn nghiên cứu hiện tại này, chúng tôi không thể đảm bảo rằng việc này sẽ mang lại một giải pháp khả thi cho hệ sinh thái.
PA API và Google Ad Manager (GAM)	GAM không thể đạt được kết quả công bằng trên thị trường. GAM không phân phát quảng cáo kịp thời, báo cáo số lượng quảng cáo đã phân phát bằng PA API và không cung cấp khả năng định cấu hình về phương thức mà GAM sẽ chọn để phân phát quảng cáo, ví dụ: bằng cách tắt PA API cho một số vị trí nhất định.	Phản hồi của Google Ad Manager: GAM đã và đang tiếp tục nỗ lực tối ưu hoá độ trễ khi phân phát quảng cáo thông qua API PA sao cho doanh thu bổ sung mà nhà xuất bản nhận được từ nhu cầu API PA cao hơn mọi chi phí phát sinh do độ trễ bổ sung của phiên đấu giá API PA. Thử nghiệm ban đầu của chúng tôi chỉ ra rằng nhà xuất bản đạt được doanh thu ròng nhờ PA API trên lưu lượng truy cập không có 3PC. Điều này cho thấy rằng nhu cầu bổ sung từ PA API lớn hơn mọi chi phí do độ trễ. Bạn có thể xem thêm thông tin về phương pháp của chúng tôi trong phần Câu hỏi thường gặp. Ngoài ra, GAM cung cấp cho nhà xuất bản báo cáo về quảng cáo được phân phát thông qua API PA. Điều này bao gồm quảng cáo được phân phát khi GAM là người bán thành phần và quảng cáo được phân phát thông qua những người bán thành phần khác khi GAM là người bán cấp cao nhất. Bạn có thể xem thêm thông tin chi tiết về việc báo cáo trong Trung tâm trợ giúp của chúng tôi. Cuối cùng, GAM cho phép nhà xuất bản bật hoặc tắt việc sử dụng API PA trên lưu lượng truy cập của họ thông qua một chế độ kiểm soát trong giao diện người dùng (xem Trung tâm trợ giúp của chúng tôi để biết thông tin chi tiết). Chúng tôi sẵn sàng xem xét ý kiến phản hồi về những quyền kiểm soát khác mà nhà xuất bản có thể mong muốn và sẽ ưu tiên mọi yêu cầu về tính năng theo quy trình ưu tiên tính năng tiêu chuẩn của chúng tôi.
PA API và GAM/AdX	Có vẻ như Google đã đảm nhận vị thế, đơn giản là họ sẽ không mua bất kỳ lần hiển thị PA API nào mà GAM không đưa ra quyết định bán cuối cùng, giống như AdWords chỉ mua từ bên nhà. Đây có vẻ như là hành vi lợi dụng vị trí trên thị trường, vì GAM/AdX có thể gửi cấu hình phiên đấu giá thành phần cho một người bán cấp cao thay thế như bất kỳ nền tảng trao đổi nào khác.	Phản hồi của người quản lý Nền tảng Google Ads: Đây không phải là quan điểm của Google. Các nền tảng bên mua của Google (Google Ads và DV360) có mua lượt hiển thị từ các sàn giao dịch không phải của Google. Điều này đúng cho cả lượt hiển thị qua API PA và lượt hiển thị qua API không phải PA.
Phản hồi của thị trường	Mối lo ngại của Mozilla: Protected Audience của Google bảo vệ nhà quảng cáo (và Google) nhiều hơn là bảo vệ bạn.	Chúng tôi cảm ơn Mozilla đã đánh giá và sẽ tiếp tục trao đổi ý kiến phản hồi của Mozilla trong các diễn đàn tiêu chuẩn công khai. Một chủ đề trong đánh giá của họ là việc triển khai hiện tại của API PA chưa thực thi tất cả biện pháp bảo vệ theo kế hoạch. Phương pháp tiếp thị của chúng tôi với PA API đã tìm cách cân bằng giữa việc khuyến khích sử dụng và triển khai các biện pháp bảo vệ quyền riêng tư sớm nhất có thể. Trong quá trình này, chúng tôi đã thiết lập lộ trình áp dụng các quy định hạn chế về quyền riêng tư theo thời gian để tạo điều kiện tích hợp tốt hơn với các API, cũng như để có thời gian thu thập thêm ý kiến phản hồi mà chúng tôi có thể đưa vào các biện pháp bảo vệ trong tương lai (ví dụ: các tính năng VAST trong Khung có hàng rào). Chúng tôi cũng hoan nghênh những thông tin gần đây của Mozilla về phương pháp của họ đối với quyền riêng tư và quảng cáo kỹ thuật số: "Môi trường Internet mở và không thu phí không được gây tổn hại đến quyền riêng tư" và "Cải thiện quảng cáo trực tuyến thông qua sản phẩm và cơ sở hạ tầng".
(Cũng được báo cáo trong các quý trước) Kết quả phiên đấu giá	Yêu cầu một phiên đấu giá trả về nhiều URL hiển thị cùng với điểm số tương ứng, giúp quảng cáo gốc dễ dàng loại bỏ trùng lặp và tránh các vấn đề về trải nghiệm người dùng cũng như độ trễ.	Phản hồi của chúng tôi tương tự như các quý trước: Chúng tôi đã cân nhắc việc chia sẻ nhiều renderURL và điểm tương ứng của các URL đó từ một phiên đấu giá API PA nhưng không triển khai do lo ngại về quyền riêng tư. Chúng tôi hiểu rằng bạn muốn tránh hiển thị cùng một quảng cáo nhiều lần cho người dùng trên một trang và đang đánh giá yêu cầu này. Chúng tôi hoan nghênh các ý kiến phản hồi bổ sung từ hệ sinh thái tại đây về những việc bạn cần hỗ trợ thêm trong API PA để hỗ trợ tối ưu trường hợp sử dụng Quảng cáo gốc.
Hiệu suất	Mối lo ngại về độ trễ ảnh hưởng đến API PA.	Chúng tôi đã nhận được những mối lo ngại về độ trễ và đây là một trong những lý do khiến chúng tôi phát triển một số tính năng trong API PA để cho phép SSP vừa đặt giới hạn về độ trễ DSP vừa cải thiện để giảm độ trễ. Gần đây, chúng tôi đã cập nhật hướng dẫn về các phương pháp hay nhất về độ trễ, trong đó có thêm thông tin về cách tận dụng các tính năng này. Chúng tôi cũng đang tiếp tục phát triển các điểm cải tiến mới về độ trễ. Bạn có thể xem một vài tính năng trong số đó tại đây.
Người bán cấp cao nhất	Google phải cho phép nhà xuất bản chọn người bán phiên đấu giá PA API cấp cao nhất thay thế.	PA API không phụ thuộc vào việc ai sẽ bắt đầu phiên đấu giá cả trong thiết kế một người bán và nhiều người bán. Các công ty riêng lẻ có thể tự quyết định việc có hỗ trợ phiên đấu giá API PA hay không và cách hỗ trợ.
(Cũng được báo cáo trong các quý trước) Nhắm mục tiêu phủ định	Yêu cầu giải pháp cho trường hợp sử dụng mà nhà quảng cáo không muốn hiển thị quảng cáo cho một đối tượng nhất định.	Chúng tôi hỗ trợ tính năng nhắm mục tiêu phủ định trên Instagram thông qua giá thầu bổ sung (theo bối cảnh). Tính năng này giải quyết nhu cầu của những nhà quảng cáo không muốn hiển thị quảng cáo cho một đối tượng nhất định. Bạn có thể xem thông tin chi tiết trong nội dung giải thích này và vấn đề này trên GitHub. Chúng tôi cũng đang tìm hiểu các giải pháp hỗ trợ tính năng nhắm mục tiêu phủ định trên Instagram cho giá thầu PA API. Chúng tôi cũng đang tìm kiếm thêm ý kiến phản hồi tại đây.
(Cũng được báo cáo trong những quý trước) Quảng cáo gốc	Yêu cầu hỗ trợ Khung bảo vệ cho Quảng cáo gốc.	Chúng tôi đang cân nhắc hỗ trợ trường hợp sử dụng này và thảo luận về các giải pháp và giải pháp có thể áp dụng tại đây.
WebView	Yêu cầu làm rõ về trường hợp IG tham gia tại Chrome không có sẵn cho Phiên đấu giá được thực thi trên WebView.	Chúng tôi muốn hỗ trợ các trường hợp sử dụng này khi có đủ cơ sở hạ tầng bảo mật. Hiện tại, chúng tôi không có thông báo nào khác. Tuy nhiên, chúng tôi rất mong nhận được ý kiến phản hồi bổ sung của bạn tại đây.
IG âm	Yêu cầu xử lý updateURL để hỗ trợ IG phủ định thông qua tính năng tiêu đề mới.	Chúng tôi đang đánh giá yêu cầu này và hoan nghênh thêm ý kiến phản hồi tại đây.
Lọc tính đa dạng	Yêu cầu hướng dẫn về cách triển khai tính năng lọc theo tính đa dạng khi chạy quảng cáo gốc trong API PA với nhiều người bán và nhiều phiên đấu giá.	Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh ý kiến phản hồi bổ sung.
(Cũng được báo cáo trong những quý trước) Bộ lọc chặn	Yêu cầu hướng dẫn về cách thực thi các quy tắc "chặn nhà xuất bản" (bộ lọc) khi chạy quảng cáo gốc trong API PA với nhiều người bán.	Chúng tôi đã chia sẻ hướng dẫn tại đây và rất mong nhận được ý kiến phản hồi bổ sung của bạn.
Quy định hạn chế	Yêu cầu cho phép áp dụng các quy định hạn chế ở cấp miền thay vì ở cấp miền con.	Các hạn chế ở cấp miền con hoặc cấp độ gốc tuân theo mô hình bảo mật cơ bản của web. Vì vậy, đây là thiết kế mặc định của chúng tôi. Chúng tôi đã thảo luận chi tiết hơn về vấn đề này tại đây và tại đây.
Đặt giá thầu đáng tin cậy	Yêu cầu về tác nhân người dùng và gợi ý liên quan đến ứng dụng trong các yêu cầu tín hiệu đặt giá thầu đáng tin cậy.	Chúng tôi đang theo dõi yêu cầu về tính năng này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây.
(Cũng được báo cáo trong các quý trước) Nhiều tài khoản Instagram	Sử dụng nhiều IG trong cùng một giá thầu.	Hiện tại, API PA không hỗ trợ tính năng này vì điều này sẽ dẫn đến thay đổi đối với mô hình quyền riêng tư cơ bản. Chúng tôi rất mong bạn sẽ thảo luận thêm tại đây.
(Cũng được báo cáo trong các quý trước) Hiệu suất	Việc chuyển nhiều logic hơn cho khách hàng có thể gây hại cho hiệu suất và trải nghiệm người dùng của trang, qua đó có khả năng làm ảnh hưởng đến điểm SEO của trang web.	Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn đóng góp ý kiến phản hồi khác tại đây.
Tính linh động của phiên đấu giá	PA API làm giảm thông tin về hoạt động của phiên đấu giá (ví dụ: ai tham gia, ai thắng mỗi thành phần được đấu giá, v.v.), làm giảm khả năng theo dõi của nhà xuất bản và khiến bạn khó biết liệu các giao dịch có được giữ nguyên hay không.	Chúng tôi đã đề xuất một giải pháp để theo dõi các giao dịch tại đây. Chúng tôi dự định sửa đổi một số trường hiện có và tạo một số trường mới trong đối tượng IG để lưu trữ DealID và giấy phép đăng ký nội dung, đồng thời cho phép các trường này truyền từ generateBid sang scoreAd hoặc thoát thông qua tính năng báo cáo ở cấp sự kiện. Điều này sẽ cung cấp sự hỗ trợ đầy đủ cho trường hợp sử dụng của thoả thuận. Chúng tôi hoan nghênh ý kiến phản hồi về các siêu dữ liệu khác mà công nghệ quảng cáo coi là rất quan trọng đối với các động lực trong phiên đấu giá và để nhà xuất bản có thể tiếp tục truy xuất nguồn gốc này. Các công nghệ quảng cáo nên cung cấp ví dụ cụ thể về siêu dữ liệu mà họ đang đề cập và từ bên nào đến bên nào.
Google Ad Manager	Mối lo ngại về yêu cầu sử dụng GAM làm máy chủ quảng cáo của nhà xuất bản để truy cập vào nhu cầu của AdX.	Phản hồi do Google Ad Manager cung cấp: 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 chức năng trao đổi.
(Cũng được báo cáo trong những quý trước) Phiên đấu giá thành phần	Người chiến thắng trong phiên đấu giá thành phần API PA sẽ được hiển thị cho GAM, làm nảy sinh mối lo ngại về việc tiếp cận thông tin một cách không công bằng.	Phản hồi của chúng tôi vẫn không thay đổi so với các quý trước: Phản hồi do Google Ad Manager cung cấp: "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 điều này trong cam kết của chúng tôi với Cơ quan Cạnh tranh Pháp. Đối với các phiên đấu giá 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. Ngoài ra, 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ả 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. Trên thực tế, chúng tôi hoan nghênh những thay đổi đối với API PA cho phép người bán thành phần chỉ định cấu hình phiên đấu giá thành phần của họ theo cách làm rối mã nguồn đối với người bán cấp cao nhất."
Google Ad Manager	GAM có yêu cầu chia sẻ doanh thu để chạy/báo cáo các phiên đấu giá cấp cao nhất không nếu GAM chưa tham gia vào quá trình tạo phiên đấu giá thành phần API IG hoặc PA?	Phản hồi do Google Ad Manager cung cấp: Khi nhà xuất bản chọn sử dụng GAM làm máy chủ quảng cáo, GAM sẽ chạy phiên đấu giá cấp cao nhất và tính phí phân phát quảng cáo cho chức năng máy chủ quảng cáo (tức là cùng một khoản phí phân phát quảng cáo áp dụng bên ngoài phiên đấu giá PA API). Tuy nhiên, nếu quảng cáo giành chiến thắng đến từ một người bán thành phần không phải GAM (tức là GAM chưa tham gia vào quá trình tạo phiên đấu giá thành phần IG hoặc PA API), GAM không xử lý việc thanh toán và không tính phần trăm phí truyền thông.
Độ nhấp	Việc đăng ký các sự kiện nhấp chuột có tuân theo cùng một quy trình đảm bảo sự riêng tư biệt lập không?	Tính năng này hiện không có kế hoạch tuân theo các quy định hạn chế về "k-anon", vì "số lượt nhấp" sẽ chỉ có dưới dạng browserSignal bên trong hàm generateBid(); tính năng này không có dưới dạng thuộc tính mới trong báo cáo cấp sự kiện.
Hiệu suất	Chi phí thoát cao do phản hồi vô điều kiện đối với các yêu cầu giá thầu theo bối cảnh.	Chúng tôi không thể trực tiếp cung cấp thông tin về những DSP có IG do các vấn đề về quyền riêng tư. Tuy nhiên, chúng tôi đang tìm hiểu các giải pháp thay thế có thể cung cấp thông tin chi tiết mà vẫn bảo vệ quyền riêng tư.
Quảng cáo gốc và quảng cáo ngoài luồng phát	Yêu cầu cập nhật về quan điểm của Chrome đối với quảng cáo gốc và quảng cáo ngoài luồng.	Vị trí của Chrome phụ thuộc vào trường hợp sử dụng được đề cập. Về Video, quan điểm của Chrome là chúng tôi cần khuyến khích hệ sinh thái hội tụ vào các giải pháp Video trong luồng phát khả thi bằng cách sử dụng các API của chúng tôi. Cho đến nay, đề xuất cụ thể duy nhất mà chúng tôi biết đến là đề xuất của Google Ad Manager. Đối với quảng cáo gốc, chúng tôi đang tích cực thu thập ý kiến phản hồi tại đây và dự định sớm triển khai các bước khám phá khác cho các công nghệ quảng cáo.
Giám sát theo thời gian thực (RTM)	Lưu lượng truy cập được gắn nhãn sẽ không gửi báo cáo RTM.	Chúng tôi đã nhận thấy vấn đề này và đang nỗ lực tìm giải pháp. Chúng tôi sẽ chia sẻ thông tin cập nhật khi có tại đây.
Hỗ trợ mở rộng đối tượng	Yêu cầu cập nhật về việc hỗ trợ tiện ích đối tượng/đối tượng do người bán tuyển chọn trong PA API.	Chúng tôi đang nỗ lực cung cấp giải pháp cho trường hợp sử dụng này. Chúng tôi đang thu thập ý kiến phản hồi từ hệ sinh thái về những tính năng mà chúng tôi nên xây dựng và hỗ trợ. Chúng tôi sẽ chia sẻ thông tin cập nhật (nếu có) và hoan nghênh thêm ý kiến phản hồi tại đây.
Gỡ lỗi	Trong công cụ dành cho nhà phát triển của Chrome, không có bảng điều khiển nào để theo dõi hiệu suất chi tiết của API PA. Ví dụ: hiệu suất tổng thể có thể chịu ảnh hưởng của số lượng IG hoặc số lượng người mua.	Mặc dù ý kiến phản hồi cụ thể này liên quan đến các chức năng của giao diện người dùng Công cụ dành cho nhà phát triển Chrome để hỗ trợ việc theo dõi, nhưng vào ngày 7 tháng 10, chúng tôi đã ra mắt tính năng cho phép các công nghệ quảng cáo định cấu hình các sự kiện tuỳ chỉnh có thể dùng làm cơ sở để theo dõi và cảnh báo. Bạn có thể xem thêm thông tin chi tiết tại đây. Chúng tôi hy vọng rằng nội dung cập nhật này đã giải quyết được phần lớn ý kiến phản hồi của bạn. Chúng tôi hoan nghênh mọi ý kiến phản hồi khác về tính năng này, cho dù liên quan đến các điểm dữ liệu được hỗ trợ hay trải nghiệm của nhà phát triển trong cuộc thảo luận tương ứng trên GitHub tại đây.
Tín hiệu	Mối lo ngại về việc liệu DSP có thể đảm bảo rằng perBuyerSignals được gửi đến SSP độc lập với kết quả đấu giá theo bối cảnh hay không.	Phiên đấu giá theo bối cảnh được giả định là chỉ có một giá thầu chiến thắng từ một DSP, hoặc nói một cách chính xác hơn là một giá thầu để cố gắng đánh bại trong phiên đấu giá API PA tiếp theo. Đối với quy trình API PA, SSP quyết định mời bất kỳ và tất cả DSP mà họ muốn xem liệu họ có nhu cầu (ở dạng IG trên thiết bị) để gửi hay không. Có thể và rất có thể một DSP đã thua phiên đấu giá theo bối cảnh sẽ được "mời lại" tham gia phiên đấu giá API PA. Trong trường hợp "mời lại" này, nếu quyết định chấp nhận, DSP sẽ chuyển tiếp cho SSP mọi tín hiệu mà Trình xác minh quảng cáo muốn đảm bảo DSP xem xét, nếu có tín hiệu nào đó cho chiến dịch đó. Nói cách khác, trong phiên đấu giá API PA, DSP luôn có cách để DSP gửi mỗi Người muaSignals đến SSP, bất kể những gì đã diễn ra trong phiên đấu giá theo bối cảnh.
Tín hiệu	Yêu cầu thêm prevClicks vào đối tượng browserSignals được chuyển đến generatedBid().	Bạn có thể giải quyết yêu cầu này bằng đề xuất của chúng tôi để hỗ trợ các tín hiệu về mức độ nhấp. Chúng tôi đã công bố tính năng này trong bài đăng gần đây trên blog và bài giải thích tương ứng. Chúng tôi rất mong nhận được ý kiến phản hồi khác về đề xuất này tại đây.
(Cũng được báo cáo trong những quý trước) Tín hiệu lập mô hình	Yêu cầu tăng số bit của tín hiệu lập mô hình từ 12 bit lên 30 bit.	Chúng tôi đã phản hồi ý kiến phản hồi này bằng một đề xuất phản đối tại đây. Chúng tôi đang tích cực làm việc với ngành để hiểu quan điểm của họ về đề xuất của chúng tôi và hiện đang cân nhắc giữa lợi ích dành cho ngành so với tác động đối với người dùng Chrome và các bên liên quan khác.
Tài liệu	Yêu cầu hướng dẫn về cách sử dụng Máy chủ khoá/giá trị (K/V) và TEE.	Bạn có thể xem hướng dẫn về cách sử dụng TEE trong bối cảnh K/V có trong phần thông tin chi tiết về thiết kế của mô hình tin cậy dịch vụ K/V tại đây.
Thời gian hoạt động của IG tiêu cực	Yêu cầu gia hạn thời gian tồn tại của IG phủ định lên 365 ngày.	IG phủ định được dùng để ngăn chặn hiển thị quảng cáo, nhưng đối tượng xấu vẫn có thể dùng IG để tiết lộ thông tin về người dùng, dẫn đến rủi ro nhận dạng lại (ví dụ: một cách để đối tượng xấu tấn công là chỉ đặt giá thầu cao kèm theo IG phủ định trong đó nhiều lần nhằm tìm hiểu xem người dùng đã hay chưa truy cập vào một số trang web nhất định). Nếu chúng tôi giữ TTL là 365 ngày, thì những kẻ xấu sẽ có nhiều dữ liệu hơn về các IG tiêu cực, dẫn đến rủi ro về quyền riêng tư lớn hơn đáng kể. Do đó, chúng tôi không thể hỗ trợ yêu cầu này để bảo vệ quyền riêng tư của người dùng.
Thông số kỹ thuật của API	Bạn có thể chèn giá trị nào dưới dạng giá trị được truyền trong perBuyerSignals? Người bán có thể tự ý xác định giá trị này không?	perBuyerSignals là nơi người bán cung cấp cho người mua bất kỳ thông tin nào họ muốn cung cấp trong phiên đấu giá. Hệ sinh thái sẽ quyết định nội dung họ muốn chèn vào đó, nhưng chúng tôi hoan nghênh thảo luận thêm tại đây.
Thay thế macro kích thước quảng cáo	Tôi muốn được hướng dẫn về việc thay thế macro kích thước quảng cáo không hoạt động.	Chúng tôi sẽ sớm chia sẻ công khai thêm thông tin.
Thay thế macro SSP sau giá thầu: Giả mạo URL cấp cao nhất	Chrome có thể giới thiệu những cơ chế nào để cho phép nhà cung cấp dịch vụ xác minh xác minh URL cấp cao nhất trong khung Hộp cát về quyền riêng tư? Có điểm dữ liệu hoặc tín hiệu thay thế nào có thể dùng trong Khung bảo vệ để đảm bảo độ chính xác của URL cấp cao nhất do SSP cung cấp không?	Chúng tôi hiện đang thảo luận về những ý kiến phản hồi bổ sung mà bạn có thể gửi tại đây.
Yêu cầu tính năng	Yêu cầu cung cấp UACH có mức entropy thấp khi tìm nạp updateURL và trên hệ thống đăng lại trong Báo cáo theo thời gian thực.	Chúng tôi đang thảo luận về các yêu cầu này tại đây. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung tại đây và tại đây.
Yêu cầu tính năng	Yêu cầu kích hoạt thiết kế gỡ lỗi đã được máy chủ đáng tin cậy đồng ý khi một ứng dụng nhất định được kích hoạt để gửi báo cáo cấp sự kiện forDebuggingOnly được lấy mẫu giảm thông qua forDebuggingOnly.reportAdAuctionWin() và forDebuggingOnly.reportAdAuctionLoss().	Đây là một yêu cầu đang được theo dõi và chúng tôi sẽ cập nhật cho hệ sinh thái khi có thông tin mới. 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.
Việc Sử Dụng API	Yêu cầu hướng dẫn về cách tính phạm vi tiếp cận người dùng riêng biệt và phạm vi tiếp cận của lượt hiển thị.	Chúng ta đang thảo luận một đề xuất về cách đọc IG từ trong một worklet bộ nhớ dùng chung. Sau đó, bạn có thể gửi báo cáo tổng hợp riêng tư qua đó. Để biết thêm thông tin chi tiết, hãy xem tại đây và chúng tôi rất mong nhận được ý kiến phản hồi về đề xuất này cũng như tính hữu ích của đề xuất này đối với hệ sinh thái.
Việc Sử Dụng API	Thiếu thông tin rõ ràng về những gì nhà xuất bản nên thử nghiệm, API nào quan trọng, API nào nên được bật và điều gì sẽ xảy ra.	Chúng tôi đang nỗ lực để hỗ trợ nhà xuất bản và vai trò của họ trong hệ sinh thái hiệu quả hơn.
Việc Sử Dụng API	Có thể thêm trình nghe sự kiện vào sự kiện Worklet Phiên đấu giá quảng cáo không?	Bạn không thể thực hiện việc này thông qua các sự kiện thông thường, nhưng các sự kiện Giao thức Chrome Devtools sẽ giải quyết được một phần trường hợp sử dụng này. Xin lưu ý rằng các sự kiện thông thường có khả năng ảnh hưởng đến các thuộc tính tách biệt/quyền riêng tư. Tuy nhiên, bạn có thể xem thông tin chi tiết tại đây.
K-Anonymity	Yêu cầu làm rõ về các yêu cầu hiển thị quảng cáo (ví dụ: ít nhất 50 người đã xem quảng cáo, nếu quảng cáo được phép hiển thị).	Tài liệu dành cho nhà phát triển cung cấp thông tin tổng quan về những kỳ vọng của chúng tôi đối với các hoạt động phát triển trong tương lai. Cụ thể, công cụ này giải thích rằng ngưỡng ẩn danh k ban đầu là k=10 người. Danh sách gửi thư blink-dev cung cấp thông tin cập nhật về những gì đang diễn ra trong Chrome. Như đã nêu trong luồng danh sách gửi thư về tính k-ẩn danh, chúng tôi hiện đang thử nghiệm việc thực thi yêu cầu về tính k-ẩn danh trên khoảng 1% lưu lượng truy cập ổn định của Chrome và không bao giờ thực thi yêu cầu này trên các lát cắt được gắn nhãn rõ ràng ("Chế độ A" và "Chế độ B").
Chà xát	Việc thay đổi cấu trúc TEE K/V có thể tạm thời bị xoá hoặc giảm bớt so với việc phải gọi tất cả phân đoạn N hay không, xuống một số lượng giúp cân bằng giữa biện pháp bảo vệ quyền riêng tư với phần mềm tiện ích (ví dụ: hiệu suất/chi phí K/V)?	Các loại yêu cầu này chỉ được xử lý cho các phiên bản không phải phiên bản chính thức, nơi có thể kiểm soát được tình trạng ma sát. Đối với các phiên bản phát hành công khai, bạn vẫn phải tạo rác. Chúng tôi có thể đánh giá tình huống này sau khi nhận được ý kiến phản hồi về việc sử dụng không phải cho mục đích phát hành công khai.
Chà xát	Yêu cầu thêm cờ để tắt tính năng chaffing từ tệp nhị phân K/V gỡ lỗi/không phải sản phẩm.	Cờ này được cung cấp trong bản phát hành 1.0.0.
Lỗi API	API ngừng hoạt động sau khi nâng cấp lên Chrome 126, mặc dù API đã được bật trong phần cài đặt.	Vấn đề này được phát hiện là liên quan đến cờ Chrome "enable-fenced-frames" (bật khung được phân vùng) mà người dùng đã bật cho mục đích phát triển. Việc đặt lại cờ này về mặc định sẽ giải quyết được vấn đề.
Báo cáo	Yêu cầu người mua chọn sử dụng API báo cáo theo thời gian thực mà không phụ thuộc vào người bán.	Yêu cầu này đang được xem xét tại đây. Gần đây, chúng tôi đã phát hành giải pháp RTM và đặc biệt hoan nghênh ý kiến phản hồi của những công nghệ quảng cáo đã sử dụng tính năng này.
Báo cáo	Yêu cầu báo cáo của bên thứ ba; mặc dù DSP và SSP nhận được thông báo về lượt hiển thị từ Chrome, nhưng theo mặc định, các nhà cung cấp kỹ thuật lớp giữa sẽ không nhận được.	Chúng tôi đang thảo luận về yêu cầu này và hoan nghênh ý kiến phản hồi khác của bạn tại đây.

Dịch vụ Phiên đấu giá được bảo vệ

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
TEEs	Yêu cầu của Google về việc tự làm quen theo các tiêu chuẩn kỹ thuật là một hạn chế nghiêm ngặt đối với việc lựa chọn nhà cung cấp dịch vụ đám mây. Khách hàng có thể tuân thủ các tiêu chuẩn kỹ thuật được áp dụng mà không cần truy cập vào Cục Nhà cung cấp dịch vụ đám mây như Google nghĩ. Việc trì hoãn việc triển khai cho các nhà cung cấp thay thế vào năm 2025 (muộn nhất) là không thể chấp nhận được vì điều này sẽ tạo ra hiệu ứng mạng khuyến khích việc boa cho các giải pháp của Google.	Dịch vụ tổng hợp là dịch vụ duy nhất bắt buộc phải chạy trong dịch vụ TEE để giải quyết một số trường hợp sử dụng công nghệ quảng cáo. Dịch vụ tổng hợp hỗ trợ cả Amazon Web Services (AWS) và Google Cloud Platform (GCP). Dựa trên ý kiến phản hồi của các công nghệ quảng cáo, chúng tôi cho rằng mức độ hỗ trợ như vậy là đủ ở giai đoạn này. Đối với các nhà cung cấp dịch vụ đám mây khác, Google đã công bố các tiêu chí chi tiết dành cho TEE trên các Nhà cung cấp dịch vụ đám mây công cộng. Các biện pháp này nhằm đảm bảo rằng giải pháp TEE đáp ứng các mục tiêu về quyền riêng tư và bảo mật của Hộp cát về quyền riêng tư. Cụ thể, các máy chủ TEE của Hộp cát về quyền riêng tư xử lý dữ liệu chưa mã hoá của người dùng trên nhiều trang web (ví dụ: dữ liệu từ các trang web của nhà xuất bản và nhà quảng cáo cho Dịch vụ tổng hợp). Các API này cần phải bảo mật để đáp ứng các mục tiêu về quyền riêng tư của người dùng. Tương tự, môi trường bảo mật cũng cần thiết để đảm bảo các API tiếp tục bảo vệ thông tin kinh doanh bí mật của các công ty (ví dụ: ngăn những người tham gia phiên đấu giá khác bằng API PA truy cập vào dữ liệu kinh doanh thuộc quyền sở hữu riêng của người mua). Theo hiểu biết của chúng tôi, hiện không có công nghệ TEE nào bảo vệ đầy đủ dữ liệu người dùng khỏi một nhà khai thác có thể là đối thủ. Do đó, chúng tôi đưa ra nhiều yêu cầu để xác thực độ tin cậy của nhà cung cấp dịch vụ đám mây. Chúng tôi không rõ "Bureau of Cloud Providers" (Cục nhà cung cấp dịch vụ đám mây) là gì và đây không phải là một phần của yêu cầu. Chúng tôi luôn hoan nghênh mọi ý kiến phản hồi về các yêu cầu này. Chúng tôi cũng tiếp tục đánh giá việc hỗ trợ các nhà cung cấp mới, bao gồm cả dựa trên các yêu cầu được gửi bằng quy trình được xác định trong nội dung giải thích. Cho đến nay, chúng tôi mới chỉ nhận được một yêu cầu hỗ trợ Azure. Chúng tôi đang đánh giá yêu cầu này.
B&A	Rất khó để đánh giá độ phức tạp về kỹ thuật và khả thi của dịch vụ B&A vì thiết kế này vẫn đang tiếp tục phát triển.	Để giải quyết những mối lo ngại này, chúng tôi đã cung cấp nội dung giải thích chi tiết trên GitHub về thiết kế của B&A, tiến trình phát hành và lộ trình các tính năng hỗ trợ API PA. Chúng tôi đang hỗ trợ các công nghệ quảng cáo muốn triển khai B&A và thu thập ý kiến phản hồi từ hệ sinh thái trên GitHub.
B&A	Đang tìm hướng dẫn và cách hiệu quả hơn để tính toán chi phí sử dụng TEE cho B&A để bắt đầu sử dụng hoặc chuyển sang sử dụng TEE trên thiết bị.	Gần đây, chúng tôi đã xuất bản Hướng dẫn định cỡ thực thể máy chủ K/V, trong đó có các công cụ để đo lường chi phí chính xác hơn.
Máy chủ K/V	Trình xác minh quảng cáo yêu cầu có thể sử dụng URL trang đầy đủ cho máy chủ K/V để thực hiện quy trình xác minh quảng cáo.	Chúng tôi hiện đang đánh giá khả năng cung cấp URL trang đầy đủ cho máy chủ K/V chạy trong TEE cho mục đích xác minh quảng cáo. URL toàn trang sẽ không có trong K/V BYOS.
Mức độ bảo mật của phiên đấu giá	Tìm kiếm các tính năng bảo mật phiên đấu giá để đảm bảo những kẻ xấu không truy cập vào dữ liệu nhạy cảm hoặc hành động mạo danh – những tính năng nào bảo vệ phiên đấu giá khỏi các cuộc tấn công phát lại và làm cách nào để triển khai các biện pháp bảo vệ bảo mật?	Mô hình bảo mật hiện tại của B&A có thể bảo vệ tính toàn vẹn của phiên đấu giá. B&A chạy trong một TEE giúp bảo vệ tính bảo mật của tín hiệu và mã của các công nghệ quảng cáo khỏi các tác nhân độc hại. Trong cấu trúc B&A, tải trọng yêu cầu B&A được mã hoá (bản mật mã yêu cầu) di chuyển từ ứng dụng qua một máy chủ quảng cáo không tin cậy đến dịch vụ SellerFrontEnd (SFE, do SSP trong TEE chạy). Văn bản đã mã hoá của yêu cầu chứa mã nhận dạng tạo dựa trên dấu thời gian. SFE sẽ kiểm tra dấu thời gian của yêu cầu và từ chối mọi yêu cầu phát lại không nằm trong khoảng +/- n giây theo thời gian máy chủ. Ngoài ra, B&A có thể trả về tải trọng phản hồi có kích thước cố định được đệm để giao tiếp giữa máy chủ với máy chủ. Các giải pháp này có thể giúp giảm thiểu các cuộc tấn công phát lại thông qua hệ thống khi một đối tượng xấu cố gắng phát lại cùng một tải trọng yêu cầu để tìm hiểu thêm về nội dung trong đó. B&A đang trong quá trình ghi nhận và cập nhật các mô hình bảo mật trong nội dung giải thích.
Tín hiệu qua máy chủ K/V	Yêu cầu đưa perBuyerSignals được gửi qua dịch vụ K/V vào yêu cầu tín hiệu đặt giá thầu đáng tin cậy từ Chrome.	Chúng tôi đang đánh giá tính khả thi của việc đưa thông tin từ perBuyerSignals, được chuyển sang máy chủ K/V chạy trong TEE, bao gồm cả URL đầy đủ của trang.
Máy chủ K/V	Yêu cầu về tiến trình triển khai theo giai đoạn hơn cho các quy tắc hạn chế về quyền riêng tư trong K/V và B&A.	Chúng tôi hiểu rằng bạn muốn áp dụng TKV theo từng giai đoạn và cảm ơn bạn đã đưa ra các yêu cầu cụ thể về K/V và B&A. Tuy nhiên, sau khi đánh giá kỹ lưỡng, chúng tôi quyết định không nới lỏng các biện pháp bảo vệ quyền riêng tư trong các API này tại thời điểm này. Chúng tôi tin rằng các biện pháp này, chẳng hạn như đánh dấu dữ liệu, đóng vai trò quan trọng trong việc bảo vệ quyền riêng tư của người dùng và duy trì niềm tin vào Hộp cát về quyền riêng tư.
Máy chủ K/V	Tìm hướng dẫn về cách mở rộng cửa hàng K/V thông qua một cấu hình tương thích.	Bạn có thể tham khảo Hướng dẫn định kích thước phiên bản máy chủ K/V mới xuất bản gần đây. Công cụ này sẽ cung cấp QPS (được ghi là "RPS" trong phần giải thích) tại mỗi tổ hợp tham số.
Máy chủ K/V	Thêm Thông tin người bán vào yêu cầu Máy chủ K/V.	Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn đóng góp ý kiến phản hồi bổ sung tại đây.
Dịch vụ K/V + B&A	Yêu cầu làm rõ tiến trình phát hành hoặc lộ trình phát hành cho K/V và B&A.	Đối với cả K/V và B&A, chúng tôi đều có các giai đoạn và tiến trình: Đối với K/V Server cùng với các phiên đấu giá PA API trên thiết bị (so với B&A), tiến trình công khai được cung cấp tại đây. Về cách xác định "Phạm vi cung cấp rộng rãi" cho K/V, vui lòng xem mục Lộ trình xác định nhóm tính năng cho giai đoạn thử nghiệm và GA. Đối với B&A, hãy xem tiến trình công khai tại đây và lộ trình tại đây. Chúng tôi định nghĩa Kiểm thử trên quy mô là "kiểm thử quy mô sản xuất hoàn toàn ổn định" – xem tại đây để biết bộ tính năng cụ thể ở giai đoạn này. B&A cũng có các giai đoạn Alpha và Beta, nên hoạt động Thử nghiệm trên quy mô sẽ bao gồm tập hợp siêu tính năng của các giai đoạn trước. Đối với cả K/V và B&A, hãy cho chúng tôi biết liệu các định nghĩa về giai đoạn này có giúp làm rõ nội dung sẽ có sẵn khi nào hay không. Nếu vẫn còn thiếu thông tin, vui lòng cho chúng tôi biết. Chúng tôi rất sẵn lòng cung cấp thông tin cụ thể hơn để giúp bạn lập kế hoạch.

Đ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
Phản hồi của thị trường	Yêu cầu các hệ thống phân bổ cạnh tranh chỉ được sử dụng báo cáo cấp sự kiện và báo cáo tóm tắt/tổng hợp trong giới hạn chặt chẽ là một quy định hạn chế tuỳ ý đối với hoạt động cạnh tranh. Chế độ này ngăn chặn việc nhắm mục tiêu lại và phân bổ theo thiết bị cụ thể theo thời gian thực ở cấp sự kiện, ngay cả khi đã có biện pháp bảo vệ để đảm bảo tuân thủ quy định bảo vệ dữ liệu (ví dụ: loại bỏ thông tin nhận dạng).	Thiết kế được đề cập dựa trên các mục tiêu về quyền riêng tư của API – ví dụ: bảo vệ thông tin trên nhiều trang web được truyền từ trang web này sang trang web khác. Ví dụ: ARA hỗ trợ tính năng phân bổ ở cấp sự kiện thông qua báo cáo sự kiện. Báo cáo sự kiện bị trì hoãn ít nhất một giờ. Điều này là cần thiết để khó có thể liên kết báo cáo cấp sự kiện với danh tính của người dùng trên trang web của nhà quảng cáo, bằng cách sử dụng các cuộc tấn công kênh bên theo thời gian, như được ghi nhận tại đây. Ngoài ARA, còn có các cách khác để phân bổ, chẳng hạn như thu thập trực tiếp thông tin từ những người dùng biết rõ việc cung cấp dữ liệu nhận dạng. Chúng tôi luôn sẵn sàng tiếp nhận ý kiến phản hồi về các trường hợp sử dụng không thể đạt được với các giới hạn về quyền riêng tư hiện tại của API Hộp cát về quyền riêng tư.
Nhiều bề mặt	Yêu cầu xác nhận về việc liệu ARA và API Bộ nhớ dùng chung có hỗ trợ các trường hợp sử dụng đa bề mặt hay không và bằng chứng về điều này.	Hiện tại, ARA và Bộ nhớ dùng chung không hỗ trợ mô hình phân bổ nhiều nền tảng (trên nhiều thiết bị). Mô hình phân bổ trên nhiều ứng dụng và web trên cùng một thiết bị (thông qua ARA) được hỗ trợ.
(Cũng được báo cáo trong các quý trước) Trên nhiều thiết bị	ARA có hỗ trợ lượt chuyển đổi trên nhiều thiết bị không?	Phản hồi của chúng tôi tương tự như các quý trước: Ngoài 3PC, việc phân phối trên nhiều thiết bị còn mang đến những thách thức mới về quyền riêng tư, đồng thời làm tăng thêm thách thức về việc phân phối công nghệ do phạm vi thiết bị và nền tảng mà người dùng có thể sử dụng. Chúng tôi đang tìm hiểu các giải pháp tiềm năng. Tuy nhiên, chúng tôi đang tập trung vào các trường hợp sử dụng quan trọng mà ARA hiện đang hỗ trợ và hiện chưa có lịch trình hỗ trợ trên nhiều thiết bị.
Chuyển tỷ lệ	Mối lo ngại về việc liệu Attribution Report API (ARA) hiện có được định cấu hình và có thể được triển khai và mở rộng một cách đáng tin cậy để phục vụ tất cả người dùng Chrome hay không.	ARA hiện có sẵn cho tất cả người dùng Chrome và đang chạy như dự kiến. Ngoài ra, chúng tôi sẽ tiếp tục thử nghiệm và giám sát độ tin cậy cũng như khả năng mở rộng của ARA khi số lượng công ty công nghệ quảng cáo thử nghiệm ARA tiếp tục tăng lên. Chúng tôi rất mong nhận được ý kiến phản hồi khác về hệ sinh thái liên quan đến vấn đề này tại đây.
(Cũng được báo cáo trong các quý trước) Loại bỏ trùng lặp	Mối lo ngại về cách ARA đề xuất hạn chế cơ chế phân bổ trên các thiết bị khiến nhà xuất bản không thể thực hiện hiệu quả logic sau khi phân bổ cho các báo cáo tóm tắt, bao gồm cả việc loại bỏ trùng lặp nhiều lượt chuyển đổi cùng loại cho cùng một lượt nhấp vào quảng cáo.	Phản hồi của chúng tôi vẫn không thay đổi so với các quý trước: Việc loại bỏ trùng lặp trên các thiết bị và quy trình đo lường là một thách thức đã biết và hiện tại mà các công nghệ quảng cáo cũng đang phải đối mặt với 3PC. Với ARA, các công nghệ quảng cáo có thể quyết định thời điểm đăng ký các lượt chuyển đổi cụ thể và thêm siêu dữ liệu cụ thể để cho biết quy trình đo lường nào họ đã sử dụng để theo dõi các lượt chuyển đổi (tức là một phần của khoá tổng hợp). Bạn có thể so sánh các quy trình đo lường này với các quy trình đo lường khác. Chúng tôi hoan nghênh thêm ý kiến phản hồi về hệ sinh thái tại đây.
Theo dõi chuyển đổi	Yêu cầu về khả năng hoạt động với lượt chuyển đổi từ nhiều miền.	Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh ý kiến phản hồi khác về hệ sinh thái.
Báo cáo	Trình duyệt sẽ chờ ít nhất 2 ngày, nhưng lên đến 30 ngày để gửi lượt chuyển đổi. Điều này có thể gây lo ngại vì phần lớn các nhà quảng cáo liên quan đều là nhà quảng cáo dựa trên hiệu suất, hoạt động gần như theo thời gian thực.	Chế độ cài đặt mặc định cho báo cáo cấp sự kiện có các khoảng thời gian báo cáo mặc định sau: 2 ngày, 7 ngày và 30 ngày. Với báo cáo linh hoạt ở cấp sự kiện, các công nghệ quảng cáo có thể thay đổi số lượng và thời lượng của khoảng thời gian báo cáo so với các giá trị mặc định. Bạn có thể thay đổi khoảng thời gian báo cáo thành tối thiểu 1 giờ để phù hợp với các trường hợp sử dụng của nhà quảng cáo hiệu suất. Chúng tôi rất mong nhận được ý kiến phản hồi khác về hệ sinh thái liên quan đến vấn đề này tại đây.
Mô hình phân bổ trực tuyến đến ngoại tuyến	Có lựa chọn triển khai nào cho quảng cáo trực tuyến đến ngoại tuyến trong ARA không? Hay có đề xuất nào khác để đo lường mô hình phân bổ ngoại tuyến đến trực tuyến không?	Hiện tại, chúng tôi không có kế hoạch hỗ trợ các trường hợp sử dụng đo lường từ trực tuyến đến ngoại tuyến trong ARA. Có những thách thức đáng kể về quyền riêng tư và bảo mật cần được xem xét đối với loại hình hỗ trợ này. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung về hệ sinh thái liên quan đến các trường hợp sử dụng dịch vụ hỗ trợ này tại đây.
Báo cáo gỡ lỗi	Làm cách nào để lưu trữ và/hoặc truy xuất mã nhận dạng cho quảng cáo theo cách có thể truy cập được cho các lượt đăng ký Chrome (nguồn/trình kích hoạt) để phân bổ từ ứng dụng sang web?	Để bật báo cáo gỡ lỗi, công nghệ quảng cáo phải chứng minh với chúng ta rằng họ có thể tham gia cùng người dùng trên ứng dụng và web. Việc này là để đảm bảo không có thông tin mới nào bị tiết lộ trong báo cáo gỡ lỗi. Công nghệ quảng cáo có thể chứng minh việc tham gia bằng cách cung cấp một khoá tham gia riêng biệt cho mỗi người dùng. Khoá kết hợp này có thể là mã nhận dạng cho quảng cáo hoặc khoá kết hợp của bên thứ nhất. Nếu công nghệ quảng cáo sử dụng mã nhận dạng cho quảng cáo, thì Chrome vốn không hỗ trợ việc truy cập mã nhận dạng cho quảng cáo từ trình duyệt mà API dự kiến mỗi công nghệ quảng cáo sẽ có phương thức truyền mã nhận dạng cho quảng cáo riêng trong quá trình đăng ký web.
Độ chi tiết của bộ chứa	Tôi có thể sử dụng nhiều chiến lược nhóm cho mỗi nhà quảng cáo không?	Bạn nên thử nghiệm nhiều phương pháp điều chỉnh ngân sách đóng góp để tìm ra phương pháp phù hợp nhất với các trường hợp sử dụng của mình. ARA được tạo ra với mục đích trở nên linh hoạt và có thể tuỳ chỉnh nhằm đáp ứng nhiều trường hợp sử dụng công nghệ quảng cáo. Do đó, bạn nên thử nghiệm nhiều chiến lược nhóm cho mỗi nhà quảng cáo hoặc cho mỗi ngành dọc. Việc sử dụng nhiều chiến lược nhóm có thể hữu ích khi nhà quảng cáo có sự khác biệt về giá trị đo lường mà họ muốn theo dõi và số lượng giá trị đo lường.
Tài liệu	Yêu cầu cung cấp thêm tài liệu để triển khai app<>web cho ARA.	Chúng tôi đã phát hành tài liệu về App<>Web cho ARA tại đây.
Hiệu suất	Số lượng yêu cầu liên quan đến ARA có thể gây ra tải nặng cho(các) máy chủ của nhà xuất bản so với số lượng yêu cầu duy trì kết nối cần thiết để cung cấp năng lượng cho trang web đó. Việc gộp nhóm các sự kiện nguồn trong một yêu cầu duy nhất có thể giúp giảm tải trên máy chủ. Một ý tưởng tiềm năng là cho phép một mảng các đối tượng được mã hoá JSON	Bạn có thể gộp các sự kiện nguồn dựa trên logic cụ thể ở một mức độ nhất định bằng cách sử dụng logic JavaScript kết hợp với API. Chúng tôi hiện đang đánh giá yêu cầu này và hoan nghênh thêm ý kiến phản hồi từ hệ sinh thái tại đây.
Yêu cầu tính năng	Đề xuất giải pháp đề xuất do không hỗ trợ tích hợp từ máy chủ đến máy chủ.	Hiện tại, chúng tôi không có kế hoạch triển khai dịch vụ hỗ trợ tích hợp máy chủ đến máy chủ trong ARA. Có nhiều thách thức về quyền riêng tư cần được xem xét thêm để cho phép hỗ trợ tích hợp từ máy chủ đến máy chủ. Chúng tôi hoan nghênh ý kiến phản hồi của hệ sinh thái về các trường hợp sử dụng bổ sung để hỗ trợ máy chủ với máy chủ tại đây.
Tài liệu	Yêu cầu hướng dẫn "bắt đầu nhanh" giải thích các phần chính của ARA/cách thiết lập và chạy với một số trường hợp sử dụng đơn giản.	Bạn có thể xem hướng dẫn bắt đầu nhanh về ARA tại đây. Chúng tôi đang nỗ lực cải thiện tài liệu này hơn nữa trong năm nay và rất mong nhận được ý kiến phản hồi bổ sung về các trường hợp sử dụng hoặc tình huống cụ thể cần tài liệu bổ sung tại đây.
Việc Sử Dụng API	Yêu cầu đề xuất về việc điều chỉnh tỷ lệ đóng góp cho nhiều giá trị nhỏ.	Bạn nên thử nghiệm nhiều phương pháp điều chỉnh ngân sách đóng góp để tìm ra phương pháp phù hợp nhất với các trường hợp sử dụng của mình. Đối với trường hợp có nhiều giá trị nhỏ, bạn nên thử nghiệm với các giá trị epsilon khác nhau để xác định các điểm uốn mà tại đó nhiễu từ epsilon có thể chấp nhận được cho trường hợp sử dụng của bạn. Bạn có thể xem thêm thông tin chi tiết trong bài nghiên cứu của chúng tôi về Tối ưu hoá báo cáo tóm tắt trong ARA.
Cấp sự kiện linh hoạt	Khi nào Cấp sự kiện linh hoạt (nhiều thông số kỹ thuật của điều kiện kích hoạt) sẽ được triển khai?	Cấp sự kiện linh hoạt hiện tại hỗ trợ tuỳ chỉnh các khía cạnh cấu hình đăng ký sau đây: số lượng báo cáo có thể được tạo trên mỗi nguồn, số lượng và khoảng thời gian báo cáo, cũng như số lượng giá trị riêng biệt của dữ liệu điều kiện kích hoạt. Chúng tôi hiện đang thu thập thêm ý kiến phản hồi về hệ sinh thái liên quan đến các tính năng nâng cao linh hoạt khác ở cấp sự kiện, nhưng hiện không có kế hoạch triển khai bất kỳ tính năng nào. Chúng tôi rất mong nhận được ý kiến phản hồi bổ sung về các trường hợp sử dụng có thể hưởng lợi từ một số tính năng nâng cao linh hoạt ở cấp sự kiện được liệt kê tại đây.
Xử lý bộ chứa	Yêu cầu xem xét việc giới hạn các đóng góp tổng hợp cho các bộ chứa cũng như khả năng mở rộng và tương thích ngược trong tương lai.	Chúng tôi đang thảo luận về yêu cầu này và hoan nghênh ý kiến phản hồi khác của bạn tại đây.
Epsilon	Điều gì sẽ xảy ra với phạm vi epsilon sau khi ARA thay đổi thành phạm vi cung cấp công khai?	ARA đã ra mắt rộng rãi trên Chrome vào quý 3 năm 2023. Hiện tại, chúng tôi không có kế hoạch sửa đổi cửa sổ giá trị epsilon. Đề xuất của chúng tôi về cơ cấu quản trị sửa đổi sẽ cung cấp thêm yếu tố đảm bảo trong trường hợp có thể có sự điều chỉnh.
Báo cáo	Báo cáo lỗi Trigger-không xác định không chứa thuộc tính nguồn trong nội dung báo cáo.	Như đã nêu trong thông số kỹ thuật, không có yêu cầu nào về việc các trường khác phải xuất hiện trong nội dung báo cáo cho trigger-unknown-error. Chúng tôi nhận thấy rằng bảng mô tả các trường trong nội dung báo cáo có khả năng gây hiểu lầm, vì các trường liên quan đến nguồn có thể xuất hiện hoặc không xuất hiện tuỳ thuộc vào nguyên nhân cơ bản gây ra lỗi. Ví dụ: lỗi nội bộ có thể xảy ra trước khi logic so khớp nguồn diễn ra, tức là không có dữ liệu nguồn nào để điền vào báo cáo gỡ lỗi. Tài liệu này hiện đã được cập nhật để làm rõ vấn đề này.
Việc Sử Dụng API	Khi làm việc với hai mục tiêu đo lường là số lượng và giá trị, có phải chỉ báo để phân chia cả ngân sách đóng góp và epsilon không?	Khi làm việc với hai mục tiêu đo lường, bạn nên chia ngân sách đóng góp giữa hai mục tiêu đó.
Báo cáo	ARA có hỗ trợ tính năng phân bổ nhiều lần chạm hoặc báo cáo hỗ trợ (còn gọi là báo cáo đóng góp) không?	ARA hiện không hỗ trợ báo cáo hỗ trợ hoặc mô hình phân bổ nhiều điểm chạm. Hiện tại, chúng tôi không có kế hoạch triển khai tính năng này. Chúng tôi rất mong nhận được ý kiến phản hồi bổ sung về các trường hợp sử dụng và mức độ ưu tiên của các trường hợp đó tại đây.
Lỗi API	Đối với ARA, tài liệu nêu rõ rằng XOR được dùng để kết hợp các phần khoá tổng hợp nguồn và điều kiện kích hoạt, nhưng trên thực tế thì hàm OR đang được dùng. Sự khác biệt này dẫn đến sự nhầm lẫn và có thể gây ra lỗi trong quá trình triển khai.	Chúng tôi đã cập nhật tài liệu này để phản ánh rằng có sự nhầm lẫn ở đây.

Dịch vụ tổng hợp

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Công việc tổng hợp	Yêu cầu cho phép nhiều tiền tố trong công việc tổng hợp.	Chúng tôi đang điều tra phản hồi này và đã đăng một đề xuất tại đây. Chúng tôi hoan nghênh ý kiến phản hồi về đề xuất này tại đây.
Yêu cầu tính năng	Yêu cầu thay đổi tập lệnh terraform để nếu bạn không đặt service_account_token_creator_list (hoặc để trống), thì việc sửa đổi chính sách IAM của tài khoản sẽ bị bỏ qua.	Chúng tôi đang điều tra vấn đề này tại đây và hoan nghênh thêm ý kiến phản hồi về hệ sinh thái.
Việc Sử Dụng API	Cần làm rõ về việc gói Terraform luôn cho thấy các thay đổi.	Sự cố này đã được khắc phục trong bản phát hành AgS 2.8.
Việc Sử Dụng API	Tìm đề xuất về cách thiết lập chế độ cài đặt tần suất tổng hợp cho từng nhà quảng cáo bằng tính năng lọc mức đóng góp linh hoạt.	Bạn hiện có thể tạo lô theo nhà quảng cáo bằng ARA. Có thể dùng tính năng lọc khoản đóng góp linh hoạt cho các trường hợp nâng cao hơn, trong đó công nghệ quảng cáo muốn phân đoạn thêm các phần đóng góp của một báo cáo theo các tần suất khác nhau. Công nghệ quảng cáo có thể tìm hiểu thêm về việc phân lô tại đây và sử dụng mã nhận dạng lọc bằng ARA tại đây. Chúng tôi cũng đang nỗ lực cung cấp thêm tài liệu về cách lọc giấy tờ tuỳ thân.
Yêu cầu tính năng	Yêu cầu hỗ trợ cho "log_sum_exp" trong Dịch vụ tổng hợp (AgS).	Chúng tôi đã liên hệ với bên liên quan này để biết thêm thông tin chi tiết về trường hợp sử dụng. Chúng tôi sẽ cung cấp thông tin cập nhật khi có thêm thông tin chi tiết.
Yêu cầu tính năng	Yêu cầu xem thêm nhật ký/thông tin chi tiết/các chỉ số khác bất cứ khi nào có vấn đề trên AgS và các vấn đề tiềm ẩn trên AgS đã triển khai.	Chúng tôi đã cập nhật tài liệu để bổ sung thêm các lỗi, biện pháp giảm thiểu và nội dung mô tả tại đây. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung về mọi lỗi/chỉ số/nhật ký, v.v. chưa được ghi nhận hoặc không có sẵn, cũng như những thông tin chi tiết hữu ích tại đây.
Kiểm thử API	Giá trị cuối cùng của epsilon sẽ là bao nhiêu sau khoảng thời gian kiểm thử?	Hiện tại, chúng tôi chưa có kế hoạch sửa đổi khoảng thời gian giá trị epsilon. Người kiểm thử nên thử nghiệm nhiều tham số và đưa ra ý kiến phản hồi.
Báo cáo	Báo cáo đang được tạo, nhưng vẫn nhận được PRIVACY_BUDGET_AUTHORIZATION_ERROR trong mã trả về.	Chúng tôi đã cung cấp hướng dẫn về cách chỉ định nguồn báo cáo và báo cáo tổng hợp chính xác để tránh lỗi này. Chúng tôi rất mong nhận được ý kiến phản hồi bổ sung về vấn đề này, đặc biệt là nếu có lỗi tái diễn.
Khám phá khoá	Bạn có kế hoạch gì cho đề xuất khám phá khoá?	Chúng tôi chưa có tiến trình triển khai đề xuất khám phá khoá, nhưng chúng tôi đang thu thập ý kiến phản hồi của hệ sinh thái về đề xuất này tại đây.
Tuỳ chỉnh	Tìm các tuỳ chọn tuỳ chỉnh có sẵn cho Dịch vụ tổng hợp.	Bạn không thể tuỳ chỉnh Dịch vụ tổng hợp trong TEE nhưng có thể tuỳ chỉnh một số thành phần bên ngoài TEE. Điều này là do các tiêu chuẩn về quyền riêng tư và bảo mật mà chúng tôi cần duy trì trong TEE. Chúng tôi đang nỗ lực cập nhật tài liệu để giúp các công nghệ quảng cáo hiểu được cấu trúc và những thành phần có thể tuỳ chỉnh. Chúng tôi không thể hỗ trợ một số tuỳ chỉnh nhất định, vì vậy, các công nghệ quảng cáo nên sử dụng cấu hình chuẩn của chúng tôi nếu có thể.
Phiên bản Spot so với phiên bản theo yêu cầu	Hệ thống đã được kiểm thử bằng phiên bản cục bộ so với phiên bản theo yêu cầu chưa? Ngoài khả năng tạm thời không có sẵn, việc sử dụng phiên bản cục bộ có bất kỳ hạn chế cụ thể nào không?	Chúng tôi chưa ưu tiên thử nghiệm trên các phiên bản theo yêu cầu vì các công nghệ quảng cáo nên sử dụng các phiên bản theo yêu cầu. Hạn chế của các thực thể nổi bật sẽ là công việc bị gián đoạn trong quá trình sử dụng ngân sách. Nếu ngân sách đã được sử dụng và công việc bị gián đoạn trước khi công nghệ quảng cáo nhận được báo cáo tóm tắt, thì công nghệ quảng cáo sẽ không thể thử lại công việc mà cần phải yêu cầu khôi phục ngân sách. Bạn chỉ nên khôi phục ngân sách cho các sự cố nghiêm trọng để bảo vệ quyền riêng tư. Bạn nên định cấu hình tính năng tự động điều chỉnh quy mô cho công nghệ quảng cáo để giúp giảm thiểu chi phí. Nếu bạn chọn 0 để tự động cấp tài nguyên bổ sung có nghĩa là sẽ không có thực thể nào đang chạy cho đến khi có yêu cầu công việc (lưu ý rằng việc này có thể làm tăng độ trễ vì các thực thể sẽ được quay tại thời điểm có yêu cầu).
Các lỗi đã biết và giải pháp	Cần làm rõ về công việc Dịch vụ tổng hợp hiển thị "Lỗi dịch vụ"	Vấn đề này đã được giải quyết tại đây. Chúng tôi cũng đã cập nhật một số thông báo lỗi để mô tả rõ ràng hơn. Ví dụ: chúng tôi đã bắt đầu gửi các lỗi cấp quyền/xác thực cụ thể hơn trên AWS so với trước đây khi các lỗi này xuất hiện dưới dạng lỗi nội bộ. Chúng tôi đã cập nhật tài liệu về mã lỗi và các bước giảm thiểu tại đây. Chúng tôi rất mong nhận được ý kiến phản hồi bổ sung về các lỗi chưa được ghi nhận hoặc không có trong tài liệu, cũng như những thông tin chi tiết hữu ích tại đây.

Private Aggregation API

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Thiết kế phím	Yêu cầu hướng dẫn thiết kế khoá Tổng hợp riêng tư	Mặc dù chúng tôi không có hướng dẫn cụ thể về tính năng Tổng hợp riêng tư, nhưng bạn có thể dùng cả khung kiểm tra tải của Dịch vụ tổng hợp và Hướng dẫn quản lý khoá nâng cao làm tài nguyên.
Ngân sách đóng góp	Ngân sách đóng góp được tính toán và giới hạn ở cấp nào?	Ngân sách đóng góp là 2^16 trong khoảng thời gian 10 phút và 2^20 trong khoảng thời gian 24 giờ.

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

Không nhận được phản hồi nào trong quý này.

Bảo vệ địa chỉ IP (trước đây là Gnatcatcher)

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Android	Google có kế hoạch triển khai tính năng Bảo vệ địa chỉ IP cho Android không?	Mặc dù đang tìm cách đưa các tính năng chống theo dõi lén lút vào Android, bao gồm cả tính năng Bảo vệ địa chỉ IP, nhưng hiện tại, chúng tôi chưa có kế hoạch chính thức để chia sẻ.
Việc Sử Dụng API	Câu hỏi về việc liệu có hay sẽ có ngoại lệ chống gian lận cho tính năng Bảo vệ địa chỉ IP không?	Chúng tôi luôn cố gắng cân bằng giữa việc bảo vệ người dùng khỏi bị theo dõi trên web dựa trên địa chỉ IP của họ, đồng thời giảm thiểu sự gián đoạn hoạt động bình thường của máy chủ, bao gồm cả việc sử dụng địa chỉ IP để chống hành vi sai trái. Mặc dù hiện chưa thể cung cấp thêm thông tin chi tiết, nhưng chúng tôi dự kiến sẽ cung cấp thông tin trong tương lai gần và rất mong tiếp tục thảo luận với bạn.
Nhận dạng đối tượng xấu	Lo ngại về hiệu quả của các biện pháp bảo mật truyền thống đối với địa chỉ IP độc hại.	Tính năng Bảo vệ IP sẽ không proxy các yêu cầu của bên thứ nhất, vì vậy, chúng tôi dự kiến hầu hết các Hệ thống phát hiện xâm nhập sẽ không bị ảnh hưởng. Chúng tôi dự định sẽ cung cấp thêm thông tin chi tiết trong tương lai để giải quyết các vấn đề về chống gian lận và hỏng trang web đối với người dùng ẩn danh.
Ẩn giấu địa chỉ IP	Nếu trang web của nhà xuất bản tin tức (1P) sử dụng cùng một miền với trang web quảng cáo (3P), địa chỉ IP có được che giấu cho cả hai không? Nếu không, làm cách nào để phân biệt hai điều này?	Tính năng Bảo vệ IP hiện đề xuất phương pháp dựa trên danh sách để xác định lưu lượng truy cập của bên thứ ba nào đi qua proxy. Tuy nhiên, ngay cả khi một nguồn gốc có trong danh sách đó, nguồn gốc đó sẽ không được chuyển tiếp nếu được truy cập trong ngữ cảnh của bên thứ nhất. Chúng tôi đang hoàn tất thông tin chi tiết về những miền cụ thể của bên thứ ba sẽ được ưu tiên ban đầu cũng như cách chúng tôi xác định chính xác bối cảnh của bên thứ nhất và bên thứ ba để bảo vệ địa chỉ IP.
Ẩn giấu địa chỉ IP	Mối lo ngại về việc bảo vệ quyền sở hữu trí tuệ và tác động của việc này đối với hệ thống chống gian lận.	Các bên thứ nhất không bị ảnh hưởng bởi các gói Bảo vệ quyền sở hữu trí tuệ của chúng tôi, vì vậy, các trang web như diễn đàn phải có quyền truy cập vào địa chỉ IP để giải quyết tranh chấp. Chúng tôi dự định sẽ cung cấp thêm thông tin chi tiết trong tương lai để giải quyết các mối lo ngại về gian lận quảng cáo.
Ẩn giấu địa chỉ IP	IP có bị ẩn trong tiêu đề của các miền bị ảnh hưởng không?	Người dùng sẽ được chỉ định cho một khu vực địa lý dựa trên địa chỉ IP trước khi sử dụng proxy đại diện cho vị trí hiện tại của họ. Bạn có thể xem thêm chi tiết tại đây.

Giảm hoạt động theo dõi số trang không truy cập

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Quy cách API	Cần làm rõ hành vi xử lý thao tác điều hướng mở rộng của Chrome khi một thẻ bị đóng.	Chúng tôi đã giải quyết vấn đề này tại đây và cập nhật quy cách cho phù hợp.
Theo dõi điều hướng	Nội dung thảo luận về phương pháp giảm thiểu hoạt động theo dõi liên quan đến một tập hợp hữu hạn các đường liên kết để giảm entropy trong các yêu cầu trên nhiều trang web.	Chúng tôi đang tiếp tục thảo luận về chủ đề này với các nhà cung cấp trình duyệt khác tại đây. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung và mọi đề xuất cụ thể về vấn đề này từ hệ sinh thái.

Hạn mức quyền riêng tư

Như đã nêu trong nội dung giải thích trên GitHub và trang web dành cho nhà phát triển, chúng tôi không còn chủ động
xem xét Ngân sách quyền riêng tư trong các đề xuất về Hộp cát về quyền riêng tư.

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

Bộ trang web có liên quan (trước đây là Nhóm bên thứ nhất)

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
(Cũng được báo cáo trong các quý trước) Giới hạn miền của Bộ trang web có liên quan (RWS)	Yêu cầu tăng giới hạn cho các miền được liên kết trong RWS	Phản hồi của chúng tôi tương tự như các quý trước: Hiện tại, chúng tôi không dự kiến sẽ tăng hạn mức số. Giới hạn này được thiết lập dựa trên các cân nhắc về quyền riêng tư của người dùng, ý kiến phản hồi của các bên liên quan trong hệ sinh thái trong W3C và việc xem xét các phương thức triển khai tương đương trong các trình duyệt khác. Để biết thêm thông tin, vui lòng xem các bài đăng trên blog của chúng tôi (1, 2). Bạn nên kiểm tra các trường hợp sử dụng yêu cầu quyền truy cập cookie trên nhiều trang web ngoài giới hạn số lượng và cân nhắc việc tận dụng hướng dẫn của chúng tôi về trường hợp sử dụng danh tính, nội dung nhúng đã xác thực và trường hợp sử dụng quảng cáo. Nếu các phiên người dùng được liên kết với các thao tác đăng nhập, bạn nên sử dụng API Quản lý thông tin xác thực liên kết (FedCM) để duy trì chức năng. Chúng tôi hoan nghênh ý kiến phản hồi về các trường hợp sử dụng khác có thể cần đến tại đây.
Xử lý cookie trên nhiều trang web	Cookie trên nhiều trang web do một miền con đặt không được truyền trong các yêu cầu tiếp theo từ miền chính. Sự cố này vẫn tiếp diễn ngay cả khi có cấu hình CORS (Chia sẻ tài nguyên giữa nhiều nguồn gốc) và thông tin đăng nhập đúng cách.	Chúng tôi đã đưa ra hướng dẫn tại đây về cách sử dụng chính xác API requestStorageAccessFor cần chỉ định nguồn gốc đầy đủ (tức là bao gồm cả miền con) để gửi cookie trên nhiều trang web trong các yêu cầu tìm nạp tiếp theo.
Lựa chọn của người dùng	Yêu cầu cung cấp thêm thông tin về requestStorageAccessFor do RWS sử dụng sau khi triển khai lựa chọn của người dùng, cụ thể là cách cử chỉ ngầm ẩn hoặc rõ ràng của người dùng (hiện cho phép truy cập vào 3PC) sẽ hoạt động trong hệ thống mới.	Chúng tôi dự kiến rằng hành vi của RWS ở chế độ do người dùng chọn (tức là bất kể người dùng đã chọn giữ lại hay giới hạn 3PC) sẽ nhất quán với hành vi hiện tại/hành vi gửi trong Chrome khi 3PC được cho phép so với 3PC bị chặn khi bật RWS ("Cho phép các trang web liên quan xem hoạt động của bạn trong nhóm"). Bạn nên gọi hasStorageAccess trước để kiểm tra xem nội dung nhúng đã có quyền truy cập vào cookie chưa phân vùng trên nhiều trang web hay chưa trước khi gọi requestStorageAccess. Phương thức hasStorageAccess sẽ trả về giá trị true nếu người dùng chọn cho phép 3PC. requestStorageAccessFor hiện không yêu cầu cử chỉ của người dùng nếu 3PC được cho phép. Chúng tôi đã mở một vấn đề mới trên GitHub để thảo luận và chỉ định hành vi phù hợp trong trường hợp này, đồng thời hoan nghênh các ý kiến phản hồi bổ sung từ hệ sinh thái.
Việc Sử Dụng API	Mối lo ngại về việc thiếu thông tin rõ ràng về việc sử dụng RWS cho mục đích "thương mại", cản trở việc áp dụng RWS. Bên liên quan cho biết họ quan tâm đến việc nhóm các ấn bản để quảng cáo được nhắm mục tiêu.	Mục đích sử dụng của RWS là hỗ trợ chức năng cốt lõi của trang web và hành trình cốt lõi của người dùng. Bạn nên sử dụng các API quảng cáo được thiết kế riêng cho các trường hợp sử dụng liên quan đến quảng cáo được nhắm mục tiêu.
Việc Sử Dụng API	Báo cáo về vấn đề với requestStorageAccess, trong đó họ có thể đặt dữ liệu localStorage nhưng không đặt được cookie.	Vấn đề này là do lỗi chính tả trong thuộc tính SameSite. Hãy đảm bảo nhập đúng chính tả và đặt rõ ràng tuỳ chọn này là Không có cho 3PC.
Thông số kỹ thuật API	Sự khác biệt trong giản đồ JSON trên kho lưu trữ, chẳng hạn như đặt nhầm trường "contact" (liên hệ) và các đề xuất cải tiến, bao gồm cả việc sử dụng từ khoá "oneOf" để đảm bảo tính nhất quán.	Chúng tôi đang điều tra ý kiến phản hồi này và sẽ xem xét việc cải thiện các điểm này cho giản đồ trong tương lai gần. 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.
Quyền truy cập của bên thứ ba (3P) vào RWS	Khi có sự đồng ý của người dùng, hãy cho phép đại lý chỉ ra những miền của bên thứ ba cũng sẽ có quyền truy cập đó vào dữ liệu API RWS.	Việc cho phép bên thứ ba kết hợp dữ liệu chưa được phân vùng của riêng họ với dữ liệu trang web RWS sẽ làm suy yếu các biện pháp bảo vệ hoạt động theo dõi trên nhiều trang web của Hộp cát về quyền riêng tư. Tuy nhiên, chúng tôi đang cân nhắc khả năng cho phép bên thứ ba duy trì dữ liệu được phân vùng vào một RWS và đang tìm kiếm ý kiến phản hồi về thiết kế cho giải pháp như vậy tại đây.

API Khung bảo vệ

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Câu hỏi về API	Mối lo ngại về việc Khung được bảo vệ không có quyền truy cập mạng có thể làm hỏng tính năng bảo vệ sự an toàn cho thương hiệu và tính năng chống gian lận cho nhà quảng cáo.	Chúng tôi đang theo dõi mối lo ngại này trong kế hoạch thực thi Khung bảo vệ. Chúng tôi sẽ sớm bắt đầu xem xét các giải pháp tương thích với việc thực thi Khung được khoanh vùng. Ngay khi có đề xuất đủ cơ sở, chúng tôi sẽ chia sẻ các đề xuất đó.
Câu hỏi về API	API Khung bảo vệ có còn được lên lịch ra mắt vào năm 2026 không?	Như đã nêu trong thông báo công khai của chúng tôi, chúng tôi sẽ yêu cầu sử dụng tính năng Khung bảo vệ từ năm 2026.
Lỗi API	Khi reportEvent() gửi thành công dữ liệu lượt nhấp từ một khung phụ nhiều nguồn gốc, setReportEventDataForAutomaticBeacons() sẽ không ghi đè dữ liệu của khung trên cùng.	Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây.

Shared Storage API

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Quảng cáo ứng dụng	Không có API tương đương với Shared Storage API trong Hộp cát về quyền riêng tư trên Android.	Chúng tôi đang đánh giá các giải pháp trên Android dựa trên nhu cầu của trường hợp sử dụng và các quy tắc ràng buộc của nền tảng. Hiện tại, chúng tôi chưa có kế hoạch chia sẻ, nhưng chúng tôi rất mong nhận được thêm ý kiến phản hồi của cộng đồng về vấn đề này.
Việc Sử Dụng API	Sự nhầm lẫn liên quan đến việc cần có một worklet javascript bổ sung để triển khai cho Shared Storage API.	Chúng tôi đang xem xét ý kiến phản hồi này và xem xét khả năng cập nhật tài liệu của chúng tôi để giải thích sự cần thiết phải có thêm các tập lệnh worklet cho API Chia sẻ bộ nhớ.
Không đáng tin cậy	API Bộ nhớ dùng chung có thể thay đổi đáng kể hoặc bị loại bỏ do những lời phê bình về quyền riêng tư, khiến API này trở thành một cơ sở không đáng tin cậy để xây dựng.	Chúng tôi không có kế hoạch thay đổi đáng kể hoặc loại bỏ cơ sở hạ tầng Bộ nhớ dùng chung. Những thay đổi chính đã được công bố là đối với cổng đầu ra Chọn URL, trong đó sẽ yêu cầu khung được phân vùng và báo cáo cấp sự kiện sẽ không được dùng nữa. Tuy nhiên, những thay đổi này sẽ không có hiệu lực cho đến ít nhất là năm 2026.

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
Cookie được phân vùng	Không giống như Firefox, Chrome không phân biệt các khoá phân vùng dựa trên các khung gốc, dẫn đến sự không nhất quán.	Chrome đã sử dụng "bit chuỗi gốc" để giải quyết vấn đề bảo mật và sự khác biệt với hành vi của Firefox. Chúng tôi đã trình bày chi tiết về vấn đề này tại đây.
Cookie được phân vùng	Các iframe được nhúng có các cấp truy cập bộ nhớ khác nhau sẽ chia sẻ và ghi đè cùng một cookie được phân vùng, gây ra sự không thống nhất trong trạng thái xác thực.	Đối với cấu hình cụ thể này, bạn nên sử dụng cookie chưa phân vùng bằng lệnh gọi API Truy cập bộ nhớ. Chúng tôi đã thảo luận chi tiết hơn về vấn đề này tại đây.
Cookie được phân vùng	Liệu các lọ cookie được phân vùng có bị xoá khi 3PC bị tắt không? Có cách nào để kiểm thử hành vi này không?	Hiện tại, chúng tôi chưa có kế hoạch chia sẻ. Tuy nhiên, các nhà phát triển có thể kiểm tra chức năng này bằng cách xoá cookie được phân vùng theo cách thủ công thông qua Ứng dụng Chrome cho nhà phát triển > Bảng điều khiển cookie.

FedCM

Chủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Phạm vi đăng ký Nhà cung cấp danh tính (IdP) và Bộ chọn tổ chức	Câu hỏi về việc mở rộng hoạt động đăng ký IdP từ chính sách cùng nguồn gốc hiện tại sang chính sách cùng trang web. Thay đổi này sẽ cho phép quản lý danh tính rộng rãi và linh hoạt hơn, chẳng hạn như cho phép trang chào mừng của một trường đại học đăng ký nhiều nhà cung cấp danh tính dựa trên miền con mà không cần đăng ký riêng cho từng nguồn gốc. Phản hồi về việc cải thiện khả năng gỡ lỗi, xử lý các ứng dụng đã phê duyệt để dàn xếp thầm, làm rõ hành vi của cookie, cho phép tuỳ chỉnh nội dung cửa sổ bật lên và giải quyết các vấn đề về thời gian chờ.	Chúng tôi ghi nhận ý kiến phản hồi này và đang cân nhắc cách tích hợp bộ chọn tổ chức vào FedCM. Chúng tôi rất mong nhận được thêm ý kiến phản hồi từ hệ sinh thái tại đây khi tiếp tục tinh chỉnh phương pháp này.
Cookie của nhà cung cấp danh tính (IdP)	Thảo luận về tác động của việc triển khai cookie phiên có thời gian tồn tại ngắn trong đề xuất Thông tin xác thực phiên được liên kết với thiết bị (DBSC). Có những lo ngại về trải nghiệm người dùng trong FedCM, trong đó cookie IdP đã hết hạn yêu cầu một cửa sổ bật lên hiển thị với người dùng để gia hạn.	DBSC đề xuất phải cho phép gia hạn cookie mà không cần sự tương tác của người dùng, giúp đảm bảo trải nghiệm người dùng được liên tục. 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	Câu hỏi về mức độ phù hợp của việc sử dụng "NetworkError" trong thông số kỹ thuật API FedCM khi kích thước của mảng "providers" không bằng 1.	Chúng tôi đồng ý rằng "TypeError" sẽ phù hợp hơn trong trường hợp này vì nó phản ánh lỗi lập trình chứ không phải là sự cố mạng. Chúng tôi sẽ xem xét thay đổi này và tìm hiểu khả năng xoá quy định hạn chế này trong các bản cập nhật trong tương lai khi chúng tôi tiến tới việc hỗ trợ nhiều IdP. 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.

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ủ đề phản hồi	Tóm tắt	Phản hồi của Chrome
Thử nghiệm ngừng sử dụng và Chế độ B	Mối lo ngại về việc ngừng sử dụng thử nghiệm, thử nghiệm Chế độ B, khả năng ngừng cung cấp Mã thông báo trạng thái riêng tư (PST) và khả năng có một API mới phù hợp hơn cho trường hợp sử dụng chống lừa đảo.	Thử nghiệm ngừng sử dụng và kiểm thử Chế độ B vẫn không thay đổi. Chúng tôi sẽ thông báo mọi nội dung cập nhật thông qua blog dành cho nhà phát triển. Chúng tôi không có kế hoạch ngừng cung cấp PST và đang thảo luận về việc phát triển và cập nhật tính năng liên tục trên GitHub. Chúng tôi chưa công bố API mới nào, nhưng chúng tôi hoan nghênh ý kiến phản hồi về cách PST có thể giải quyết tốt hơn các trường hợp sử dụng chống gian lận.
Ý kiến phản hồi về API	Yêu cầu khả năng thu hồi mã thông báo để giải quyết trường hợp sử dụng chống gian lận.	Mặc dù nhà phát hành có thể thu hồi tất cả mã thông báo bằng cách thay đổi khoá họ sử dụng, nhưng API này không thể thu hồi từng mã thông báo vì quy trình này yêu cầu cho phép nhà phát hành liên kết việc phát hành và sử dụng mã thông báo. Việc này phá vỡ mô hình quyền riêng tư của PST nhằm ngăn chặn việc theo dõi giữa hai sự kiện.