Báo cáo hằng quý cho quý 2 năm 2025, tóm tắt ý kiến phản hồi của hệ sinh thái nhận được về các đề xuất trong 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 trong khuôn khổ Cam kết của mình 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 về các đề xuất trong Hộp cát về quyền riêng tư; kỳ vọng mới về thời gian; giải thích thoả đáng về cách Google đã xem xét những nhận xét của bên thứ ba; và bản tóm tắt về 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à cách Google giải quyết ý kiến phản hồi đó.
Google đã thường xuyên thông báo cho CMA về tiến trình liên quan đến các đề xuất về Hộp cát về quyền riêng tư trong các Cuộc họp định kỳ về tình trạng theo lịch trình theo đoạn 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, trong đó 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 thông tin triển khai API và thông tin về trạng thái. Các 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 các thông tin cập nhật nhắm đến từng danh sách gửi thư dành cho nhà phát triển.
Có tính đến những nhận xét của bên thứ ba
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
- 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 đặc 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ử theo nguyên gốc
- PA API
- Protected Audience API (trước đây là FLEDGE)
- PatCG
- Nhóm cộng đồng công nghệ quảng cáo riêng tư
- RP
- Bên 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
- 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
- Hiệp hội World Wide Web
- WIPB
- Cố tình không nhận biết IP
Ý kiến phản hồi chung, không liên quan đến API/Công nghệ cụ thể
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Tương lai của Hộp cát về quyền riêng tư | Do thông báo về việc không tiếp tục giới thiệu cơ chế lựa chọn của người dùng cho cookie của bên thứ ba, một số API sẽ hữu ích hơn những API khác khi có cookie của bên thứ ba và những API khác sẽ cần phát triển để hữu ích. Ngoài các API Hộp cát về quyền riêng tư, Chrome còn có những lĩnh vực tiềm năng khác để đầu tư. | Chúng tôi trân trọng ý kiến phản hồi của bạn và sẽ tiếp tục trao đổi với các bên liên quan để đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, cũng như khám phá các lĩnh vực mới để đầu tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, chúng tôi sẽ duy trì phương pháp hiện tại để cung cấp cho người dùng lựa chọn về cookie của bên thứ ba trong Chrome. |
| Hộp cát về quyền riêng tư | Một số thành phần trong hệ sinh thái thất vọng vì thông báo không tiếp tục giới thiệu cơ chế lựa chọn của người dùng cho cookie của bên thứ ba, nhưng tự hào về những việc đã hoàn thành, họ đánh giá cao những thách thức về kỹ thuật trong Hộp cát về quyền riêng tư và nhấn mạnh giá trị của mối quan hệ hợp tác với Chrome cũng như tính hữu ích của Khoản tài trợ kiểm thử thị trường. | Chúng tôi trân trọng ý kiến phản hồi của bạn và đồng ý rằng Chrome có thể và nên hợp tác với các nhà phát triển để tạo ra những công nghệ giúp cải thiện quyền riêng tư trực tuyến trong khi vẫn duy trì một môi trường internet có chứa quảng cáo. |
| Chia sẻ dữ liệu trình duyệt | Tính năng chia sẻ dữ liệu qua trình duyệt là một công nghệ hấp dẫn có khả năng giải quyết các vấn đề về sự thiếu hiệu quả của thị trường và lòng tin. Trình duyệt có giá trị là một bối cảnh thực thi của bên thứ ba để cộng tác. | Chúng tôi đánh giá cao ý kiến phản hồi của bạn và đồng ý rằng Chrome có thể và nên đóng vai trò giúp các nhà phát triển tạo ra những công nghệ giúp tăng cường niềm tin giữa các nhà phát triển và người dùng cộng tác. |
| Lưu lượng truy cập trên Chrome | Tỷ lệ lưu lượng truy cập không có cookie trên Chrome và tỷ lệ lưu lượng truy cập ở Chế độ ẩn danh là bao nhiêu? | Như CMA đã lưu ý trong "Thông báo về ý định đưa ra cam kết", Chế độ ẩn danh chỉ ảnh hưởng đến một phần rất nhỏ trong hoạt động duyệt web. Ở Vương quốc Anh và Khu vực kinh tế Châu Âu (EEA), Chế độ ẩn danh của Chrome chiếm: dưới 10% số lượt điều hướng trên các thiết bị chạy hệ điều hành Android; và dưới 10% số lượt điều hướng trên các thiết bị chạy hệ điều hành Windows.
Các chỉ số này chỉ đề cập đến hoạt động điều hướng trên Chrome dựa trên Chromium ở Vương quốc Anh và Khu vực kinh tế Châu Âu (EEA). Chúng tôi không chia sẻ dữ liệu về những trình duyệt chặn cookie của bên thứ ba. Nhà phát triển có thể xác định thời điểm phân vùng cookie bằng cách sử dụng Tiêu đề truy cập bộ nhớ và sử dụng các biện pháp giảm thiểu hiện có cho phù hợp. |
| Nhãn kiểm thử Chrome | Kế hoạch của Chrome đối với 1% lưu lượng truy cập không dùng cookie được bật để thử nghiệm vào năm 2024 là gì? | Hiện tại, chúng tôi chưa có kế hoạch chia sẻ, nhưng chúng tôi dự định chia sẻ công khai các kế hoạch này ngay khi có thể. |
| Kiểm thử Chrome | Chế độ thiết lập nhãn thử nghiệm hiện tại có bao gồm một phương pháp xử lý cho các trường hợp mà cả 3PC đều có sẵn và Privacy Sandbox API đều được bật không? | Chế độ thiết lập nhãn thử nghiệm hiện tại bao gồm cả phương pháp xử lý cho cookie của bên thứ ba và Privacy Sandbox API dưới dạng Chế độ A. |
| Hộp cát về quyền riêng tư | Một số nhà quảng cáo nhận thấy Privacy Sandbox API phức tạp và đang cảm thấy thờ ơ do các hoạt động chuẩn bị trước đó, đặt câu hỏi về cách định lượng lợi thế cho những người áp dụng sớm và đang tìm hiểu về tác động của việc nhắm mục tiêu lại, tìm kiếm khách hàng tiềm năng và đo lường. | Chúng tôi trân trọng ý kiến phản hồi của bạn và hiểu được những cảm xúc của bạn về sự phức tạp của công nghệ và các bài tập chuẩn bị. Về việc tìm hiểu hiệu suất của các công nghệ Hộp cát về quyền riêng tư hiện tại, kết quả thử nghiệm của chúng tôi cho thấy sự tham gia của hệ sinh thái là một yếu tố quan trọng trong việc tìm hiểu hiệu suất của các giải pháp Hộp cát về quyền riêng tư. Việc kiểm thử ở khối lượng thấp không thể tái tạo động lực và ưu đãi của thị trường khi sử dụng các công nghệ ở quy mô lớn. |
Đăng ký và chứng thực
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 | Chrome Response |
|---|---|---|
| Hiệu suất và tiện ích của mối quan tâm trong Topics API có các điểm cải tiến | Ý kiến phản hồi của các bên liên quan ở phía người mua cho thấy Topics API là một tín hiệu có giá trị và mang lại dữ liệu Chi phí mỗi lượt hiển thị (CPM) cạnh tranh với dữ liệu cho đối tượng 3P, đối với các chiến dịch của nhà quảng cáo. Một số nhà xuất bản xem tín hiệu của Topics API là tín hiệu có chất lượng cao hơn so với các tín hiệu tiêu chuẩn trên web mở. Dựa trên ý kiến phản hồi này về tính hữu ích của Topics API, các bên liên quan đang yêu cầu cải tiến, chẳng hạn như cải thiện độ trung thực, tính nhất quán của hệ thống phân loại và mở rộng quyền kiểm soát của nhà xuất bản để thúc đẩy việc áp dụng rộng rãi hơn. | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Mức độ hữu ích đối với các loại bên liên quan |
Vì trình phân loại Chủ đề hiện chỉ sử dụng tên máy chủ lưu trữ 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, 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. | Phản hồi của chúng tôi tương tự như các quý trước: Tương tự như 3P, giá trị của thông tin do các trang web khác nhau đóng góp cũng khác nhau. Các trang web có mối quan tâm theo phân khúc thị trường không nhất quán về mức đóng góp giá trị: không phải trang web nào có mối quan tâm theo phân khúc thị trường cũng có nội dung có giá trị thương mại, do đó, mức đóng góp giá trị sẽ thấp 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, có một số lo ngại đáng kể về quyền riêng tư và bảo mật đối với việc phân loại như vậy. |
| Hệ thống phân loại chủ đề không đủ chi tiết | Topics API không cung cấp đủ độ chi tiết cho các nhà xuất bản tin tức có nhiều phần nội dung trong một miền duy nhất, điều này có thể hạn chế tính hữu ích của API cho việc nhắm mục tiêu quảng cáo. | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Cải thiện bộ phân loại | Cho phép nhà xuất bản cấp cho Chrome quyền phân loại chủ đề dựa trên nội dung trang (ví dụ: tiêu đề, nội dung). | Chúng tôi đang xem xét yêu cầu này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây. |
| Chính sách | Yêu cầu làm rõ các nguyên tắc liên quan đến việc sử dụng API Chủ đề kết hợp với thông tin 3PC. | Không có khó khăn gì khi sử dụng cả Topics API và cookie của bên thứ ba, vì Topics API cung cấp một số chức năng của cookie của bên thứ ba. |
| Tiêu đề Observe-Browse-Topics | Yêu cầu làm rõ về việc triển khai tiêu đề Observe-Browse-Topics, cụ thể là liệu việc liên tục trả về tiêu đề có gây ra vấn đề hay không. | Việc liên tục trả về tiêu đề Observe-Browse-Topics: ?1 sẽ không gây ra bất kỳ vấn đề kỹ thuật nào.Trình duyệt xử lý tín hiệu này một cách hiệu quả, chỉ cần lưu ý rằng lượt truy cập trang đủ điều kiện để tính toán chủ đề mà không gây ra tình trạng trùng lặp hoặc lỗi. Mặc dù không bắt buộc trên mọi trang, nhưng việc gửi mã này dưới dạng tiêu đề tiêu chuẩn trên tất cả các tài liệu cấp cao nhất là một chiến lược hợp lệ và đơn giản. |
| Danh mục phân loại | Yêu cầu cập nhật hệ thống phân loại Topics mới nhất bằng các chủ đề mới. | Chúng tôi đang xem xét yêu cầu này và hoan nghênh ý kiến phản hồi khác từ hệ sinh thái tại đây. |
| Giá trị rỗng | Yêu cầu hướng dẫn về cách cải thiện hiệu suất của Topics API và tìm hiểu lý do khiến phản hồi có giá trị rỗng, chẳng hạn như lọc hoặc độ nhạy. | Để cho rõ ràng, null hoặc các phản hồi trống từ Topics API là một tính năng quyền riêng tư dự kiến, chứ không phải là lỗi.Phản hồi null có thể là do:• Quy tắc về quyền riêng tư: 5% cơ hội ngẫu nhiên null hoặc do tập lệnh của bạn chưa "quan sát" người dùng trên các trang web liên quan đến chủ đề đó.• Trạng thái người dùng: Nhật ký duyệt web không đầy đủ, sử dụng Chế độ ẩn danh hoặc người dùng đã chọn không tham gia trong phần cài đặt quyền riêng tư đối với quảng cáo của Chrome. • Lỗi kỹ thuật: Trang web của nhà xuất bản phải gửi tiêu đề Observe-Browse-Topics: ?1 và mọi iframe gọi đều yêu cầu quyền allow="Browse-topics".Để điều tra, hãy sử dụng trang gỡ lỗi chrome://topics-internals để xem trình duyệt của bạn đã tính toán những chủ đề nào và lý do.Mặc dù các tính năng bảo vệ quyền riêng tư ngăn chặn tỷ lệ lấp đầy 100%, nhưng bạn có thể cải thiện hiệu suất bằng cách: • Hợp tác với nhà xuất bản: Đảm bảo rằng các đối tác của bạn gửi tiêu đề Observe-Browse-Topics: ?1 một cách chính xác trên trang web của họ.• Xác minh mã của bạn: Nếu bạn sử dụng iframe, hãy xác nhận rằng chính sách allow="Browse-topics" đã được áp dụng. |
Protected Audience API
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Việc sử dụng PA API bị cản trở do chi phí và độ phức tạp | Những người áp dụng đang giảm mức độ ưu tiên hoặc quay lại các hoạt động tích hợp Protected Audience API (PA API), với lý do là chi phí vận hành, nhu cầu của nhà quảng cáo không đủ và lượng khoảng không quảng cáo thấp từ các nền tảng trao đổi. Một số ý kiến phản hồi cho thấy lợi ích tiềm năng của PA API, chẳng hạn như khả năng cung cấp đối tượng bền vững và phạm vi tiếp cận vượt trội do tỷ lệ khớp cao. |
Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Chức năng trên nhiều nền tảng | Chức năng trên nhiều nền tảng phải được hỗ trợ bằng cách sử dụng PA API trên nhiều nền tảng để mở khoá các khả năng nhắm mục tiêu đến đối tượng và nhắm mục tiêu lại hiệu quả hơn. Google nên cho phép truy cập vào Nhóm lợi ích (IG) đã đăng ký trong Chrome khi phân phát quảng cáo trong môi trường gốc hoặc trong webview, đồng thời các nhóm lợi ích đã đăng ký trong Android sẽ có trong các phiên đấu giá của Chrome. | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| directFromSellerSignals | Bằng cách giới hạn lượng thông tin có sẵn trong phiên đấu giá theo bối cảnh, người tham gia đấu giá luôn được định tuyến thông qua máy chủ quảng cáo của Google. Trước tiên, nhà xuất bản phải gọi tất cả các đối tác trao đổi của mình, sau đó gọi Google Ad Manager (GAM) để chạy phiên đấu giá theo bối cảnh và cuối cùng cho phép GAM gọi các phiên đấu giá IG. Nếu không biết kết quả của phiên đấu giá theo bối cảnh theo thời gian thực, thì không đối thủ cạnh tranh nào có thể điều phối một cách công bằng quyết định cấp cao nhất. Tính năng directFromSellerSignals trong PA API có thể thiếu tính minh bạch về thông tin phiên đấu giá, có khả năng cản trở khả năng truy cập vào dữ liệu cần thiết. Google nên xoá directFromSellerSignals hoặc cập nhật để không thể dùng thuộc tính này nhằm ẩn giá thanh toán trong phiên đấu giá của máy chủ quảng cáo. Ví dụ: giá theo bối cảnh có thể được truyền qua Chrome thông qua một trường trong suốt, bất biến, đã ký mà tất cả những người tham gia đấu giá (và nhà xuất bản) đều có thể truy cập và xác minh. |
Phản hồi của chúng tôi không thay đổi so với các quý trước: Phản hồi của Chrome: Không rõ thông tin được truyền vào runAdAuction() có đến từ người bán hay không, trừ phi người bán gọi runAdAuction() từ iframe của chính mình. Trong phiên đấu giá nhiều người bán, không thể để tất cả người bán tạo khung gọi runAdAuction(). directFromSellerSignals giải quyết vấn đề này bằng cách tải nội dung từ một gói tài nguyên phụ được tải từ nguồn gốc của người bán. Điều này đảm bảo rằng tính xác thực và tính toàn vẹn của thông tin được truyền vào một phiên đấu giá từ các cấu hình seller-auctions không thể bị thao túng. Nếu muốn sử dụng PA API để nắm được thông tin mà nhà cung cấp công nghệ đang truyền vào các phiên đấu giá PA, thì nhà xuất bản có thể yêu cầu nhà cung cấp công nghệ đó cung cấp chức năng này. Phản hồi của Google Ad Manager: Chúng tôi luôn tập trung vào tính công bằng của phiên đấu giá trong nhiều năm, kể 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 (kể cả giá của 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 với Cơ quan Cạnh tranh của Pháp. Đối với các phiên đấu giá sử dụng Protected Audience API, chúng tôi dự định giữ lời hứa bằng cách tận dụng directFromSellerSignals và không chia sẻ giá thầu của bất kỳ người tham gia đấu giá nào với bất kỳ người tham gia đấu giá nào khác trước khi phiên đấu giá kết thúc trong các phiên đấu giá có nhiều người bán. Để cho rõ ràng, chúng tôi cũng sẽ không chia sẻ giá của phiên đấu giá theo bối cảnh với phiên đấu giá thành phần của riêng mình, như đã giải thích trong nội dung cập nhật này. |
| Báo cáo | Yêu cầu thêm một thực thể phân tích/báo cáo để bật tính năng báo cáo tập trung. | Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh mọi ý kiến phản hồi khác. |
| K-Anonymity trên buyerReportingId | Khả năng loại bỏ giá thầu dựa trên tính ẩn danh k của "buyerReportingId" để tạo điều kiện thuận lợi cho việc tuyển chọn đối tượng và thực hiện nghĩa vụ báo cáo với nhà cung cấp dữ liệu bên thứ ba. | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Cải thiện quy trình gỡ lỗi trong tập lệnh generateBid | Yêu cầu một cơ chế để nhanh chóng xác định giai đoạn hoặc "điểm ngắt" cụ thể trong tập lệnh generateBid mà quy trình đang gặp lỗi. | Chúng tôi biết về mục đích sử dụng mong muốn của API Đo lường theo thời gian thực như một cơ chế thiết lập điểm ngắt cho các phiên đấu giá trên thiết bị. Chúng tôi đang cân nhắc ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo vào tháng 4 năm 2025 rằng phương pháp hiện tại để cung cấp cho người dùng lựa chọn về cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Trình nghe sự kiện để theo dõi trạng thái runAdAuction | Đề xuất thêm tính năng hỗ trợ trình nghe sự kiện vào hàm navigator.runAdAuction của PA API để cải thiện khả năng giám sát vòng đời đấu giá quảng cáo. | Chúng tôi đang đánh giá yêu cầu này và mong nhận được thêm ý kiến phản hồi từ hệ sinh thái tại đây. |
| Việc Sử Dụng API | Yêu cầu làm rõ cách PA API và Attribution Reporting API (ARA) có thể hỗ trợ các trường hợp sử dụng quảng cáo trên web khi không có cookie của bên thứ ba, đặc biệt là đối với những người dùng đã chọn không sử dụng cookie của bên thứ ba nhưng không chọn không sử dụng API Hộp cát về quyền riêng tư, cũng như trong các trường hợp liên quan đến việc đồng bộ hoá cookie không thành công và WebView? | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Độ trễ | Độ trễ liên quan đến PA API có thể cản trở việc áp dụng, vì nhà xuất bản có thể chọn tắt PA API nếu độ trễ quá cao. | Chúng tôi đã thực hiện một số điểm cải tiến về độ trễ trên thiết bị trong vài quý qua. Việc xây dựng và mở rộng quy mô dịch vụ Đặt giá thầu và Phiên đấu giá (B&A) sẽ tiếp tục khi cần. Chúng tôi đã cập nhật hướng dẫn về các phương pháp hay nhất để giảm độ trễ để bổ sung 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 tìm hiểu việc phát triển các điểm cải thiện độ trễ mới, một số điểm có thể được tham khảo tại đây. |
| Hành vi ghi nhật ký trong B&A (Thử nghiệm so với Sản xuất) | Thông tin làm rõ về sự khác biệt trong hành vi ghi nhật ký giữa chế độ kiểm thử và chế độ phát hành chính thức cho các dịch vụ B&A. Cụ thể, khả năng cung cấp nhật ký trên đám mây và tác động của chế độ sản xuất đối với việc ghi nhật ký. | Trước tiên, bạn cần phân biệt giữa bản dựng phát hành công khai và bản dựng không phải phát hành công khai cũng như tham số TEST_MODE riêng biệt. Tham số này chỉ đơn giản là cho phép khoá mã hoá kiểm thử được mã hoá cứng. Phần giải thích bên dưới tập trung vào các loại bản dựng. Trong các bản dựng non_prod, máy chủ B&A có cấp độ chi tiết có thể định cấu hình để ghi nhật ký. Những nhật ký chi tiết này được ghi vào các luồng stdout/stderr tiêu chuẩn. Trên Google Cloud, bạn có thể truy cập vào các nhật ký này thông qua giao diện ghi nhật ký gốc. Còn trên Amazon Web Services, bạn có thể tìm thấy các nhật ký này trong nhật ký của bảng điều khiển được đính kèm. Đối với các bản dựng prod, hành vi ghi nhật ký sẽ bị hạn chế hơn. Mức độ chi tiết là cố định và không thể thay đổi. Mặc dù một số nhật ký không liên quan đến quyền riêng tư (chẳng hạn như thông báo khởi động máy chủ và hầu hết các lỗi sự cố) vẫn được in ra stdout/stderr, nhưng không có nhật ký cụ thể nào về yêu cầu thông qua kênh này. Nhật ký duy nhất cho mỗi yêu cầu từ bản dựng phát hành là nhật ký cho các yêu cầu có chứa mã gỡ lỗi đã được đồng ý và các nhật ký này chỉ được xuất thông qua OpenTelemetry. Điều quan trọng là bạn nên hạn chế sử dụng tính năng gỡ lỗi có sự đồng ý, vì lưu lượng truy cập lớn có thể làm giảm hiệu suất máy chủ và dẫn đến lỗi kiểm tra tình trạng. Về chỉ số, tất cả đều được xuất thông qua OpenTelemetry. Các chỉ số không nhạy cảm về quyền riêng tư luôn được xuất nguyên trạng mà không có bất kỳ "nhiễu" nào. Ngược lại, các chỉ số nhạy cảm về quyền riêng tư luôn được "làm nhiễu" khi được xuất từ một máy chủ đang chạy ở chế độ prod. Cấu hình đo từ xa cụ thể sẽ xác định xem những chỉ số nhạy cảm về quyền riêng tư này có được xuất dưới dạng chỉ số có nhiễu, không có nhiễu hay cả hai hay không. |
| Đưa Đường dẫn đầy đủ của trang vào Tín hiệu đặt giá thầu đáng tin cậy để đảm bảo An toàn thương hiệu | Yêu cầu cập nhật PA API để đưa đường dẫn URL đầy đủ của trang cấp cao nhất vào, ngoài tên máy chủ, trong yêu cầu tìm nạp cho trustedBiddingSignals. Trường hợp sử dụng chính là cho phép kiểm soát an toàn thương hiệu chi tiết hơn. Nhà quảng cáo thường cần chặn quảng cáo xuất hiện trên các phần cụ thể của một miền (ví dụ: trang web tin tức.com/chính trị) trong khi vẫn cảm thấy thoải mái với miền đó nói chung. Vì các danh sách chặn này có thể có hàng triệu mục, nên chúng phải được đánh giá ở phía máy chủ. Quy cách hiện tại (chỉ gửi tên máy chủ) khiến máy chủ trustedBiddingSignals không thể thực hiện quy trình đánh giá cần thiết ở cấp đường dẫn này, từ đó hạn chế các chức năng đảm bảo an toàn cho thương hiệu. |
Chúng tôi hiện đang thảo luận về vấn đề này tại đây, sau nhiều cuộc thảo luận trước đó mà bạn có thể tham khảo tại đây. Chúng tôi rất mong nhận được thêm ý kiến phản hồi. Tuy nhiên, chúng tôi muốn làm rõ rằng chúng tôi chỉ cân nhắc việc thêm thông tin này khi lệnh tìm nạp trustedBiddingSignals sẽ chuyển đến một máy chủ đang chạy trong Môi trường thực thi đáng tin cậy (TEE). |
Phiên đấu giá được bảo vệ (Dịch vụ B&A)
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Kiểm tra tình trạng còn hàng | Thông tin về tính sẵn có của Key/Value (KV) phiên bản 2 để thử nghiệm trong cả môi trường Chrome và B&A. | KV phiên bản 2 có trên cả B&A và Chrome. Bạn có thể xem thêm hướng dẫn tại đây. |
| Triển khai máy chủ KV | Yêu cầu làm rõ về việc sử dụng máy chủ KV, cụ thể là về việc ánh xạ URL hiển thị mẫu quảng cáo để yêu cầu dữ liệu, sự cần thiết của việc phối hợp giữa SSP và DSP để xác định các tham số trong URL hiển thị và tính sẵn có của tài liệu nêu rõ việc phối hợp và lưu trữ dữ liệu bắt buộc ở chế độ KV. | Dịch vụ KV sử dụng renderURL làm khoá. Nếu là URL mới, thì URL đó sẽ được lưu trữ. Nếu có, giá trị của tham số này sẽ được trả về để sử dụng trong scoreAd. Định dạng trả về phụ thuộc vào chế độ thiết lập: "Bring Your Own Server" (BYOS) cho phép mọi giá trị, trong khi dịch vụ KV đáng tin cậy yêu cầu một Hàm do người dùng xác định. Mặc dù không phải lúc nào cũng cần thiết, nhưng việc phối hợp với DSP là điều cần thiết đối với các tính năng như thay thế macro (ví dụ: ${AD_WIDTH}) trong renderURL, cho phép tuỳ chỉnh và xác minh quảng cáo động. Bạn nên bắt đầu bằng một thử nghiệm đơn giản với một DSP để xác định mức độ phối hợp cần thiết. Chúng tôi cũng đang trong quá trình cập nhật tài liệu về KV và sẽ chia sẻ công khai tài liệu này khi có thể. |
| BYOS cho B&A | Tại sao B&A không cung cấp chế độ BYOS tương tự như chế độ BYOS của KV? | B&A yêu cầu TEE, ngăn chặn mô hình BYOS, vì mô hình này xử lý các tổ hợp dữ liệu có độ nhạy cao, yêu cầu thực thi các cơ chế bảo đảm quyền riêng tư, như giải thích dưới đây. Đối với DSP: B&A xử lý bối cảnh của nhà xuất bản (có thể là toàn bộ URL nếu được người bán gửi một cách rõ ràng thông qua auctionSignals / perBuyerSignals) kết hợp với dữ liệu chi tiết về người dùng trên Instagram. TEE là thành phần thiết yếu để xử lý an toàn sự kết hợp này và ngăn chặn khả năng người dùng bị nhận dạng lại. Trong KV BYOS, bạn không thể gửi URL đầy đủ. Đối với SSP: Ngay cả khi chỉ biết tổ hợp các IG tham gia (và chủ sở hữu DSP của các IG đó) trong một phiên đấu giá, bạn cũng có thể tạo ra một chữ ký nhận dạng. Đây là lúc giải pháp chaffing (tạo dữ liệu giả) phát huy tác dụng, yêu cầu sử dụng TEE. Do đó, việc xử lý an toàn các tín hiệu nhạy cảm kết hợp này và việc thực thi các cơ chế bảo vệ quyền riêng tư đòi hỏi môi trường được kiểm soát và chứng thực của TEE. |
Đo lường quảng cáo kỹ thuật số
Attribution Reporting (và các API khác)
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Chính sách về tiếng ồn | Việc triển khai ARA mang lại nhiều lợi ích cho một số người tham gia thị trường và Google nên tiếp tục duy trì báo cáo ở cấp sự kiện. Google nên cân nhắc nới lỏng chính sách về tiếng ồn trong trường hợp có cả ARA và 3PC. Các nhà quảng cáo dựa trên hiệu suất ngày càng sử dụng chế độ triển khai trường "giá trị" hiện tại của sự kiện linh hoạt ARA và chính sách ít hạn chế về nhiễu sẽ giúp giảm độ trễ và báo cáo không chính xác. | Cơ chế này là một phần cơ bản trong thiết kế của ARA, nhằm bảo vệ quyền riêng tư của người dùng bằng cách ngăn chặn hoạt động theo dõi riêng lẻ. Chúng tôi đang xem xét ý kiến phản hồi về những thách thức trong việc báo cáo do nhiễu gây ra, vì chúng tôi sẽ tiếp tục đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, cũng như mọi điểm cải tiến tiềm năng trong tương lai, theo thông báo của Google vào tháng 4 năm 2025 rằng phương pháp hiện tại để cung cấp cho người dùng lựa chọn về cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Lộ trình và dịch vụ hỗ trợ dài hạn | Yêu cầu lộ trình sản phẩm cho ARA, cũng như xác nhận về khoản đầu tư và hoạt động hỗ trợ dài hạn dựa trên thông báo không tiếp tục giới thiệu cơ chế lựa chọn của người dùng cho 3PC. | Nhóm Hộp cát về quyền riêng tư đang tương tác với hệ sinh thái để tìm hiểu vai trò của các API Hộp cát về quyền riêng tư trong tương lai và đánh giá mọi khoản đầu tư trong tương lai. |
| Đo lường trên nhiều môi trường (Từ ứng dụng đến web) | Yêu cầu một giải pháp liên quan đến việc sử dụng ARA để hỗ trợ hoạt động đo lường trên nhiều môi trường, cung cấp luồng dữ liệu rõ ràng và đáng tin cậy hơn, đồng thời nâng cao khả năng kết nối các lượt tương tác của người dùng trên nhiều nền tảng. | ARA đã hỗ trợ tính năng App-to-Web trên cùng một thiết bị. Bạn có thể xem thêm thông tin chi tiết về giải pháp đo lường trên nhiều ứng dụng và web tại đây và tại đây. |
| Phân bổ trên nhiều trình duyệt | Một phương pháp thống nhất, trên nhiều trình duyệt đối với ARA sẽ cải thiện đáng kể khả năng đo lường lợi tức đầu tư trên web mở và cung cấp một giải pháp thay thế ổn định trước những thay đổi tiềm ẩn về quy định. Chrome nên hợp tác với nhóm Safari để đưa ra một giải pháp như thế này. | Chúng tôi đang khám phá một API có khả năng tương tác với các nhà cung cấp trình duyệt khác trong các nhóm PATCG và PATWG thuộc W3C. Xin lưu ý rằng đây là công việc ban đầu, các bên liên quan có thể tham khảo tiến trình của chúng tôi tại đây. |
| Đo lường trên nhiều thiết bị/ngoại tuyến | Không thể hỗ trợ đo lường lượt chuyển đổi trên nhiều thiết bị trong ARA là một hạn chế đáng kể. Việc đo lường lượt chuyển đổi từ trực tuyến sang ngoại tuyến cũng rất quan trọng và trình duyệt có thể đóng vai trò trong việc cộng tác với các nhà cung cấp dịch vụ đo lường. | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Phân bổ đa điểm | Yêu cầu cho phép nhà quảng cáo sử dụng dữ liệu Hộp cát về quyền riêng tư làm "sự thật cơ bản" khách quan để xác thực và điều chỉnh các mô hình phân bổ hiện có. Bạn có thể đạt được điều này bằng cách sử dụng dữ liệu do trình duyệt của ARA cung cấp làm tín hiệu hiệu chỉnh đáng tin cậy, tạo ra một đường cơ sở đáng tin cậy. | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Đo lường lưu lượng truy cập không có sự đồng ý/chọn không tham gia | Một giải pháp bảo đảm quyền riêng tư (chẳng hạn như Phân bổ riêng tư có khả năng tương tác) sẽ cho phép đo lường lưu lượng truy cập không có sự đồng ý. Điều này sẽ giúp bạn hiểu rõ hơn về hiệu suất chiến dịch bằng cách đưa dữ liệu của những người dùng đã chọn không tham gia hoạt động theo dõi vào, từ đó giải quyết một khoảng trống lớn trong hoạt động đo lường do các yêu cầu về sự đồng ý tạo ra. | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Phân bổ từ máy chủ đến máy chủ | Yêu cầu cho phép các công nghệ quảng cáo có cơ sở hạ tầng phía máy chủ tinh vi tích hợp với ARA theo cách linh hoạt hơn, đáp ứng những trường hợp sử dụng khó quản lý hoàn toàn ở phía máy khách, đồng thời duy trì quyền riêng tư của người dùng. | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
| Đăng ký nhiều miền | Tìm hiểu rõ hơn về các giới hạn và điều kiện khi đăng ký nhiều miền bằng ARA, đặc biệt là liên quan đến dịch vụ tổng hợp và mô hình phân bổ trên nhiều nguồn. | Dưới đây là những hạn chế chính khi sử dụng ARA với nhiều miền: • Hoạt động phân bổ được giới hạn trong một nguồn gốc duy nhất. Bạn không thể so khớp một lượt nhấp từ một trong các miền của mình với một lượt chuyển đổi trên một miền khác. Hoạt động phân bổ được đưa vào hộp cát cho cùng một nguồn đối với cả nguồn và điều kiện kích hoạt. • Aggregation Service không hỗ trợ tính năng phân lô nhiều nguồn. Các báo cáo từ nhiều nguồn phải được xử lý theo lô và riêng biệt. Chúng tôi đang tìm cách hỗ trợ tính năng này trong tương lai. Nói tóm lại, mặc dù một thực thể có thể đăng ký nhiều miền, nhưng hiện tại, tất cả các chức năng của ARA (chẳng hạn như phân bổ và tổng hợp) đều phải được xử lý theo từng nguồn gốc. |
Dịch vụ tổng hợp
Không nhận được ý kiến phản hồi nào trong quý này.
Private Aggregation API
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Giới hạn và độ ồn | Mối lo ngại về các giới hạn đối với kích thước khoá tổng hợp và giá trị tổng hợp trong Private Aggregation API. | Kích thước khoá và giá trị tổng hợp được chọn để có độ chi tiết cao trong khi vẫn giới hạn chi phí mạng và bộ nhớ. Bạn cũng nên sử dụng băm khi chỉ định khoá để tối đa hoá tính linh hoạt. Mặc dù có những yếu tố khác giúp bảo vệ dữ liệu người dùng, nhưng việc thêm nhiễu là một phần quan trọng trong các biện pháp bảo vệ quyền riêng tư của Private Aggregation API. Chúng tôi đang xem xét ý kiến phản hồi và sẽ tiếp tục đánh giá các lựa chọn tham số phù hợp, đồng thời xem xét vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025 sẽ duy trì phương pháp hiện tại để cung cấp cho người dùng lựa chọn về cookie của bên thứ ba trong Chrome. |
| Quyền riêng tư so với tính hữu ích | Phương pháp của Hộp cát về quyền riêng tư có thể ưu tiên quyền riêng tư hơn là tính hữu ích, điều này có thể cản trở việc áp dụng. Đề xuất cho phép chia sẻ dữ liệu chi tiết hơn khi có sự đồng ý của người dùng để cải thiện hoạt động đo lường và cá nhân hoá quảng cáo. | Kích thước khoá và giá trị tổng hợp được chọn để có độ chi tiết cao trong khi vẫn giới hạn chi phí mạng và bộ nhớ. Bạn cũng nên sử dụng băm khi chỉ định khoá để tối đa hoá tính linh hoạt. Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo vào tháng 4 năm 2025 rằng phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
Hạn chế hành vi ngầm theo dõi
Giảm thông tin trong chuỗi 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 | Chrome Response |
|---|---|---|
| Phát hiện nội dung rác | Nếu yêu cầu đầu tiên từ một trang web sử dụng hệ thống phát hiện nội dung rác dựa vào gợi ý của ứng dụng, thì hệ thống theo dõi hoặc phát hiện có thể không xác định được hoặc phân loại yêu cầu một cách thích hợp. | Các trường hợp sử dụng dựa vào quyền truy cập vào Gợi ý cho ứng dụng tác nhân người dùng (UA-CH) trong yêu cầu đầu tiên nên sử dụng gợi ý quan trọng cho ứng dụng. |
| Ý kiến phản hồi về API | Hãy cân nhắc việc ngừng sử dụng Sec-CH-USA-Wow64 vì tiêu đề này không còn phù hợp với web hiện đại nữa. | Chúng tôi đang xem xét yêu cầu này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây. Chúng tôi cũng nhận được ý kiến phản hồi cho rằng việc mở rộng wow64 ra ngoài Windows sẽ rất hữu ích. |
Bảo vệ địa chỉ IP (trước đây là Gnatcatcher)
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Các chế độ kiểm soát | Yêu cầu bật/tắt tính năng Bảo vệ địa chỉ IP để các trang web sử dụng có chọn lọc bên ngoài chế độ Ẩn danh. | Chúng tôi rất trân trọng ý kiến phản hồi của bạn và mong bạn có thể chia sẻ thêm ý kiến về vấn đề này tại đây. |
| Hành vi sai trái | Liệu Mã thông báo tiết lộ xác suất (PRT) dẫn đến giá trị NULL có ngăn chặn việc xác định thủ phạm khi cảnh sát yêu cầu tiết lộ địa chỉ IP đối với hành vi sai trái trên nền tảng không? | Nếu một miền chỉ được dùng để phát hiện hành vi gian lận và vi phạm, thì miền đó có thể không có trong Danh sách miền được che giấu (MDL) và do đó không bị ảnh hưởng bởi tính năng Bảo vệ địa chỉ IP. Do đó, bạn sẽ không cần PRT cho những miền đó. Nếu một miền có trong MDL, thì PRT hiện là cách duy nhất để tìm hiểu địa chỉ IP ban đầu cho một yêu cầu được uỷ quyền. Vì PRT được thiết kế đặc biệt để hỗ trợ phân tích tổng hợp, chứ không phải nhận dạng cá nhân, nên đúng là PRT sẽ không chứa địa chỉ IP trong hầu hết các trường hợp. Chúng tôi dự kiến điều này sẽ có tác động hạn chế trong trường hợp được mô tả. Tuy nhiên, vì tính năng Bảo vệ địa chỉ IP chỉ áp dụng trong bối cảnh bên thứ ba, nên nhà xuất bản sẽ tiếp tục nhận được địa chỉ IP không qua proxy cho các lượt tương tác của bên thứ nhất, chẳng hạn như khi người dùng truy cập vào trang web của một nền tảng trực tuyến. |
| Chống gian lận | Các biện pháp chống gian lận cụ thể của Google đối với IP Protection là gì, bao gồm cả thông tin chi tiết về việc giới hạn tốc độ truy cập vào các proxy và việc phát hành mã thông báo xác thực, cũng như các trường hợp sử dụng cụ thể cho PRT là gì? | Chúng tôi xác nhận rằng tính năng giới hạn tốc độ và mã thông báo xác thực trong IPProtection được thiết kế để ngăn chặn bot thực hiện hành vi gian lận quảng cáo bằng cách truy cập quá nhiều vào các proxy, như được nêu chi tiết trong chiến lược chống gian lận và chống thư rác. Các trường hợp sử dụng khác cho PRT được trình bày trong tài liệu giải thích về PRT tại đây. |
| Chế độ ẩn danh | Liệu tính năng Bảo vệ địa chỉ IP ở Chế độ ẩn danh vẫn được lên kế hoạch ra mắt vào quý 3 không? | Hiện tại, không có thay đổi nào đối với tiến trình ra mắt tính năng Bảo vệ địa chỉ IP ở Chế độ ẩn danh trong quý 3. |
Giảm hoạt động theo dõi tỷ lệ thoát
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Ý kiến phản hồi về API | Chrome nên chặn quyền truy cập vào cookie/bộ nhớ thay vì phân vùng chúng khi áp dụng các biện pháp giảm thiểu hoạt động theo dõi lượt truy cập gián tiếp (BTM), với lý do là hành vi không mong muốn và sự nhầm lẫn từ phương thức "phân vùng" của Safari. | Chúng tôi rất hoan nghênh đề xuất này. Hiện tại, BTM không liên quan đến việc phân vùng cookie/bộ nhớ mà thay vào đó sẽ xoá cookie/bộ nhớ sau một khoảng thời gian gia hạn. Nếu có bất kỳ thiết kế nào sau này cho BTM liên quan đến hành động tức thì đối với cookie, chúng tôi dự định ưu tiên chặn cookie hơn là phân vùng chúng. |
Tăng cường ranh giới về 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)
Không nhận được ý kiến phản hồi nào trong quý này.
Fenced Frames API
Không nhận được ý kiến phản hồi nào trong quý này.
Shared Storage API
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Yêu cầu về tính năng API | Yêu cầu nối lượt xem quảng cáo và lượt nhấp vào Bộ nhớ dùng chung. | Chúng tôi đang xem xét ý kiến phản hồi này khi đánh giá vai trò của API Hộp cát về quyền riêng tư trong tương lai, trong bối cảnh Google thông báo rằng tháng 4 năm 2025, phương pháp hiện tại để cung cấp cho người dùng lựa chọn sử dụng cookie của bên thứ ba trong Chrome sẽ được duy trì. |
Cookie có trạng thái được phân vùng độc lập (CHIPS)
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Câu hỏi về API | Yêu cầu làm rõ cách các chế độ kiểm soát 3PC của Chrome tương tác với CHIPS, cụ thể là liệu cookie không được phân vùng có được chuyển đổi thành cookie được phân vùng khi 3PC bị vô hiệu hoá hay không và liệu cookie được phân vùng có vẫn hoạt động hay không. | Cookie không được phân vùng sẽ không được lưu trữ, truy xuất hoặc gửi trong bối cảnh của bên thứ ba khi 3PC bị vô hiệu hoá. Tuy nhiên, cookie được phân vùng sẽ tiếp tục được lưu trữ, truy xuất và gửi trong bối cảnh của bên thứ ba, vì chức năng của cookie này không bị ảnh hưởng bởi các chế độ cài đặt trình duyệt vô hiệu hoá cookie của bên thứ ba. |
| Vấn đề về quyền riêng tư | Lo ngại rằng một bên được nhúng có mã nhận dạng liên tục (chẳng hạn như để dùng tính năng Đăng nhập một lần) vẫn có thể cho phép cả bên nhúng và bên được nhúng có được mã nhận dạng kỹ thuật số toàn cầu, ngay cả khi có cookie được phân vùng. | Mặc dù bên được nhúng có thể có một giá trị nhận dạng cố định, nhưng giá trị nhận dạng này chỉ có thể truy cập được trên trang web nơi cookie được đặt bởi thành phần nhúng khi được lưu trữ trong một cookie được phân vùng. Việc kết hợp giá trị nhận dạng này trên nhiều trang web sẽ yêu cầu hành động đăng nhập, vốn đã cho phép trao đổi giá trị nhận dạng dưới dạng mã thông báo xác thực, ngay cả khi không sử dụng cookie được phân vùng. |
FedCM
| Chủ đề phản hồi | Tóm tắt | Chrome Response |
|---|---|---|
| Việc Sử Dụng API | Hoạt động dàn xếp thầm lặng không thành công đối với những người dùng có nhiều tài khoản mà không có lỗi cụ thể. | Hành vi dàn xếp thầm lặng là một tính năng được thiết kế sẵn, vì tính năng này dành cho một trường hợp rất cụ thể chỉ có một tài khoản có sẵn. Bạn nên sử dụng tính năng dàn xếp "không bắt buộc". Trong đó, FedCM sẽ quay lại trình bày cho người dùng một trình chọn tài khoản nếu không thể dàn xếp thầm lặng. |
| Việc Sử Dụng API | navigator.credentials.get trả về các lỗi chung, ngăn chặn việc ghi lại các lý do từ chối cụ thể như người dùng bỏ qua hoặc thời gian chờ. |
Việc nhà phát triển không thể phân biệt giữa trường hợp người dùng đóng hộp thoại FedCM với trường hợp lỗi mạng hoặc FedCM đang trong "khoảng thời gian chờ" do người dùng đã đóng hộp thoại trước đó cũng là một tính năng được thiết kế để bảo vệ quyền riêng tư của người dùng. Mối lo ngại là khả năng này sẽ cho phép các trang web suy luận trạng thái đăng nhập của người dùng trên các Nhà cung cấp danh tính (IdP) khác nhau. |
| Đăng nhập | Đã quan sát thấy hành vi chọn tài khoản không nhất quán khi có nhiều tài khoản đã đăng nhập. | Không rõ liệu việc không thể chọn một tài khoản cụ thể trong trường hợp có nhiều tài khoản đã đăng nhập là một lỗi không liên tục trong FedCM hay một vấn đề nào đó liên quan đến hệ thống thử nghiệm. Chúng tôi đang làm việc với người báo cáo để giải quyết vấn đề này và đã yêu cầu cung cấp thêm thông tin chi tiết để hiểu rõ hơn về vấn đề. |
| Việc Sử Dụng API | Nếu người dùng đóng hộp thoại trong khi uỷ quyền bằng FedCM, thì việc họ đang ở trạng thái tạm ngưng sẽ không được báo cáo thông qua lỗi có thể bắt được. | Có, trường hợp này sẽ xảy ra và hệ thống sẽ tạo mã lỗi chung để bảo vệ quyền riêng tư của người dùng. |
| Việc Sử Dụng API | Tại sao FedCM chuyển sang khoảng thời gian không hoạt động 10 phút sau khi "tự động xác thực lại" thành công? | Vì quá trình xác thực lại tự động diễn ra mà không cần người dùng thực hiện hành động, nên nếu muốn quay lại trang web nhưng đăng nhập bằng một tài khoản khác, người dùng sẽ cần một khoảng thời gian mà FedCM không tự động xác thực lại họ. "Khoảng thời gian không hoạt động" cho phép người dùng đăng nhập theo cách thủ công bằng một tài khoản khác. Bài đăng này trên blog có thêm thông tin chi tiết về "khoảng thời gian không hoạt động" này. |
| FedCM gọn nhẹ | Lo ngại rằng đề xuất FedCM đơn giản sẽ làm tăng thêm độ phức tạp cho IdP do cần hỗ trợ 2 cách triển khai không tương thích (FedCM so với FedCM đơn giản). | FedCM đơn giản tương thích với FedCM truyền thống. IdP có thể chọn phương thức triển khai để sử dụng và không bắt buộc phải hỗ trợ cả hai. FedCM đơn giản là một cơ chế truyền dữ liệu cho FedCM. Nếu chọn sử dụng tính năng này, IdP có thể đẩy thông tin tài khoản vào trình duyệt khi người dùng đăng nhập. Nhờ đó, khi Bên phụ thuộc (RP) gọi FedCM, tài khoản sẽ được truy xuất từ trình duyệt thay vì điểm cuối tài khoản của IdP. |
| FedCM gọn nhẹ | Mối lo ngại về việc để lộ dữ liệu cá nhân của người dùng, chẳng hạn như tên, email và ảnh hồ sơ cho RP trong đề xuất Lightweight FedCM. | Đề xuất về FedCM gọn nhẹ đã được cập nhật kể từ khi nhận được ý kiến phản hồi này, nhằm xoá tên, email và hình ảnh hồ sơ khỏi phản hồi phương thức. |
| FedCM gọn nhẹ | Việc quản lý nhiều tài khoản đã đăng nhập có vẻ quá cứng nhắc trong đề xuất Lightweight FedCM. Đề xuất này hiện không hỗ trợ thời gian tồn tại của từng phiên hoặc trạng thái đăng nhập tinh tế cho mỗi tài khoản. | Thời gian hết hạn hiện được liên kết với IdP trong đối tượng thông tin đăng nhập. Chúng tôi đã ghi nhận vấn đề hết hạn theo từng tài khoản là một câu hỏi mở và sẽ cân nhắc ý kiến phản hồi này cho các hoạt động phát triển trong tương lai. |
| FedCM gọn nhẹ | Sự khác biệt giữa "đã đăng nhập" và "có thể chọn" không được xác định rõ ràng, điều này có thể ảnh hưởng đến trải nghiệm người dùng đối với đề xuất Lightweight FedCM. | Chúng tôi hiện không hỗ trợ khả năng phân biệt xem một tài khoản đã đăng nhập hay chưa đăng nhập trong Giao diện người dùng (UI) FedCM. Không được liệt kê các tài khoản đã đăng xuất. Nếu một tài khoản bị đăng xuất và xuất hiện trong danh sách, đồng thời người dùng chọn tài khoản không được đăng nhập, thì bạn có thể dùng Continuation API để yêu cầu người dùng đăng nhập lại. |
| Việc Sử Dụng API | Sự không nhất quán giữa trường given_name trong getUserInfo và cách sử dụng trường này trong giao diện người dùng FedCM. |
Vấn đề này đã được thảo luận thêm với Mozilla tại đây, để thống nhất cách xử lý given_name trong getUserInfo. |
| Việc Sử Dụng API | Không phải tất cả các trường được dùng trong giao diện người dùng từ IdentityProviderAccount đều được cung cấp cho getUserInfo, cụ thể là tel và username, cho thấy cần phải đồng bộ hoá. |
Cuộc thảo luận với Mozilla và các thành viên khác trong Nhóm cộng đồng FedID đang tiến triển về vấn đề điều chỉnh những trường nào từ IdentityProviderAccount sẽ được gửi đến getUserInfo. |
| FedCM cho doanh nghiệp | Yêu cầu hỗ trợ FedCM cho các trường hợp sử dụng IdP của doanh nghiệp. | Vấn đề chính là nhu cầu về một cơ chế đáng tin cậy để IdP báo hiệu cho trình duyệt rằng quản trị viên đã đồng ý trước để cho phép người dùng truy cập vào các RP cụ thể mà Trình theo dõi trên web không thể bắt chước và/hoặc lợi dụng. Vấn đề này đã được thảo luận trong cuộc họp FedID CG ngày 22 tháng 4 (vui lòng xem ghi chú của cuộc họp tại đây) và các tổ hợp tiện ích trình duyệt và Chính sách doanh nghiệp (đối với thiết bị được quản lý) đã được đưa ra làm giải pháp tiềm năng. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung về vấn đề này tại đây. |
Chống nội dung rác và lừa đảo
Private State Token API (và các API khác)
Không nhận được ý kiến phản hồi nào trong quý này.