Báo cáo hằng quý cho quý 4 năm 2023 tóm tắt ý kiến phản hồi của hệ sinh thái nhận được đối với các đề xuất liên quan đến Hộp cát về quyền riêng tư và phản hồi của Chrome.
Theo cam kết của Google với CMA, Google đã đồng ý cung cấp công khai báo cáo hằng quý về quy trình tham gia của các bên liên quan đối với các đề xuất của 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). Các báo cáo tóm tắt ý kiến 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 ý kiến phản hồi mà Chrome nhận được từ nhiều nguồn như liệt kê trong phần tổng quan về ý kiến phản hồi, bao gồm nhưng không giới hạn ở các vấn đề về GitHub, biểu mẫu phản hồi có trên privacysandbox.com, cuộc họp với các bên liên quan trong ngành và diễn đàn tiêu chuẩn web. Chrome hoan nghênh ý kiến phản hồi từ hệ sinh thái và đang tích cực tìm hiểu những cách thức để tích hợp những kiến thức 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 của 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 liên quan đến một chủ đề nhất định và sắp xếp theo số lượng giảm dần. Chúng tôi xác định các chủ đề phản hồi phổ biến bằng cách xem xét các chủ đề thảo luận của các cuộc họp công khai (W3C, PatCG, IETF), ý kiến phản hồi trực tiếp, GitHub và các câu hỏi thường gặp mà các nhóm nội bộ và biểu mẫu công khai của Google gửi đến.
Cụ thể hơn, biên bản cuộc họp cho các cuộc họp của các cơ quan tiêu chuẩn web đã được xem xét và để lấy ý kiến phản hồi trực tiếp, hồ sơ của Google về các cuộc họp bên liên quan 1:1, email mà từng kỹ sư nhận được, danh sách gửi thư của API và biểu mẫu phản hồi công khai đã được xem xét. Sau đó, Google đã phối hợp các nhóm tham gia vào nhiều hoạt động tiếp cận khác nhau để xác định mức độ phổ biến tương đối của các chủ đề xuất hiện liên quan đến từng API.
Phần giải thích về các câu trả lời của Chrome được phát triển dựa trên các Câu hỏi thường gặp đã phát hành, câu trả lời thực tế cho các vấn đề mà các bên liên quan nêu ra và xác định vị trí dành riêng 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à kiểm thử, chúng tôi đã nhận được các câu hỏi và ý kiến phản hồi cụ thể về API Chủ đề, Protected Audience và Attribution Reporting API.
Chrome có thể chưa xem xét phản hồi nhận được sau khi kỳ báo cáo hiện tại kết thúc.
Bảng chú giải thuật ngữ viết tắt
- KHỐI
- 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
- Quản lý thông tin xác thực liên kết
- FPS
- 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
- Nhà cung cấp danh tính (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
- Số hiệp ném bóng
- Đị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
- PatCG
- Nhóm cộng đồng công nghệ quảng cáo riêng tư
- RP
- Đảng trung thành
- Nền tảng bên bán (SSP)
- Nền tảng bên cung
- TEE
- Môi trường thực thi đáng tin cậy
- UA
- Chuỗi tác nhân người dùng
- UA-CH
- Gợi ý của ứng dụng tác nhân người dùng
- W3C
- World Wide Web Consortium
- WIPB (Danh sách mở rộng)
- Khiếm thị IP có ý định
Phản hồi chung, không có API hoặc công nghệ cụ thể
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Tiến trình triển khai mô hình 3PCD | Chia sẻ thêm thông tin về tiến trình 3PCD. | Để hỗ trợ việc thử nghiệm, theo mặc định, Chrome đã hạn chế 3 máy tính đối với 1% người dùng, kể từ ngày 4 tháng 1 năm 2024. Để giải quyết mọi mối lo ngại còn lại của CMA, Chrome dự định từng bước ngừng hỗ trợ 3 máy tính kể từ quý 3 năm 2024 và tiếp tục tiếp tục đến hết năm 2024. |
| Tiến trình triển khai mô hình 3PCD | Thời điểm triển khai 3PCD vào quý 4 năm 2024 trùng với mùa lễ và có thể tác động tiêu cực đến các nhà xuất bản. | Không có thời điểm nào là thích hợp để ngừng sử dụng 3 máy tính. Hơn một năm qua, chúng tôi đã xác định rõ ý định của mình là sẽ ngừng sử dụng 3PC vào nửa cuối năm 2024. Cam kết của chúng tôi với CMA, bao gồm cả thời gian dự kiến cho một Giai đoạn tạm ngừng, không thay đổi. Mặc dù chúng tôi hiểu mối lo ngại về thời gian trong Quý 4, nhưng việc thực hiện các thay đổi về tiến trình đã khiến toàn ngành chuẩn bị ít hơn (chứ không phải nhiều hơn). |
| Thử nghiệm Chrome (chế độ a/b) | Quy trình thiết lập thử nghiệm cho Chế độ A và Chế độ B theo từng thực thể hay cho mỗi hồ sơ Chrome? | Chúng tôi đã công bố nội dung làm rõ trong tài liệu tại đây, trong đó nêu rõ trình duyệt Chrome trong ngữ cảnh này đề cập đến ứng dụng Chrome: một lượt cài đặt Chrome trên một thiết bị. Mỗi thư mục dữ liệu người dùng riêng lẻ tạo thành một khách hàng riêng biệt. |
| Bản dùng thử không dùng nữa | Chia sẻ thêm thông tin về Bản dùng thử 3PCD. | Chúng tôi đã chia sẻ thêm thông tin về bản dùng thử 3PCD tại đây. |
| Bản dùng thử không dùng nữa | Không đủ thời gian để cung cấp mã thông báo Dùng thử không dùng nữa trên tất cả trang web trước tháng 1 năm 2024. | Chúng tôi xác nhận rằng có một khoảng thời gian ngắn kể từ khi mở đăng ký dùng thử ngừng hoạt động cho đến khi giai đoạn thử nghiệm hỗ trợ Chrome bắt đầu chặn 1% cookie. Để giải quyết những hạn chế về thời gian này, Chrome sẽ cung cấp thời gian ân hạn cho các nguồn gốc tham gia trong khi triển khai mã thông báo dùng thử không dùng nữa. Trong thời gian ân hạn kéo dài đến ngày 1 tháng 4 năm 2024, các nguồn đã đăng ký bản dùng thử việc ngừng sử dụng sẽ có quyền truy cập vào 3 máy tính trong Chrome ngay cả khi chưa triển khai mã thông báo. Mục đích của thời gian ân hạn này là để ngăn chặn các vấn đề về khả năng tương thích với web trong giai đoạn chuyển đổi. Các nguồn gốc tham gia phải triển khai mã thông báo dùng thử không dùng nữa trước khi kết thúc thời gian ân hạn để tiếp tục có quyền truy cập vào 3 máy tính sau khi kết thúc thời gian ân hạn. |
| Thử nghiệm Chrome (chế độ a/b) | Chế độ B là một mẫu quá nhỏ nên không thể đo lường chính xác mức giảm hiệu suất. | Bạn cần cân nhắc cẩn thận giữa tỷ lệ lưu lượng truy cập và nguy cơ tác động đến người dùng và chức năng trên web. |
| Chế độ điều khiển kiểm thử | Chỉ những nhà xuất bản lớn nhất có nguồn lực phát triển đáng kể mới có thể hiểu được hiệu suất trong quá trình thử nghiệm và chuyển thông tin này cho CMA. | Chúng tôi thấy các nhà cung cấp dịch vụ dành cho nhà xuất bản đã chia sẻ công khai thông tin chi tiết với hệ sinh thái lớn hơn và hy vọng tình trạng này sẽ tiếp tục khi hoạt động thử nghiệm Hộp cát về quyền riêng tư ngày càng tăng. Chúng tôi cũng kỳ vọng rằng các công ty về công nghệ quảng cáo xây dựng dựa trên API Hộp cát về quyền riêng tư sẽ tiếp tục phát triển các tính năng mà khách hàng của họ yêu cầu, chẳng hạn như báo cáo dựa trên nhãn. |
| Dữ liệu của bên thứ ba | Lo ngại về các công ty dữ liệu của bên thứ ba. | Có nhiều phiên bản của các công ty dữ liệu bên thứ ba. Một số trang web có thể tăng gấp đôi, chuyển sang sử dụng các phương pháp theo dõi trên nhiều trang web mờ ám hơn bao giờ hết. Những doanh nghiệp khác có thể khai thác các công nghệ nâng cao quyền riêng tư và đưa ra tuyên bố giá trị mới với khách hàng. Chúng tôi hy vọng sẽ có nhiều lựa chọn hơn cho người dùng và đi theo hướng mà cả người dùng và cơ quan quản lý đang ngày càng đòi hỏi nhiều hơn. Sự thay đổi sẽ mang đến cơ hội phát triển và đổi mới. |
| Google Ad Manager | Cần thêm hướng dẫn của Google Ad Manager về cách nhà xuất bản có thể thử nghiệm Hộp cát về quyền riêng tư. Báo cáo không đủ để nhà xuất bản hiểu được tác động. | Phản hồi do Google Ad Manager đưa ra: Google Ad Manager đã giải thích cách tiến hành thử nghiệm bằng nhãn thử nghiệm hỗ trợ Chrome trong trung tâm trợ giúp. Ad Manager hiện cung cấp cho nhà xuất bản báo cáo về cả Topics và Protected Audience. Kể từ thời điểm tạo Báo cáo phản hồi này, Ad Manager có thể báo cáo về các lượt hiển thị được phân phát qua Protected Audience API và có thể cho biết liệu dữ liệu từ Topics API có xuất hiện trên một lượt hiển thị nhất định hay không. Nhà xuất bản quan tâm đến việc báo cáo tinh vi hơn, chẳng hạn như phân đoạn báo cáo dựa trên nhãn hỗ trợ của Chrome, bằng cách đọc các nhãn trực tiếp trên Chrome (sử dụng tài liệu về Chrome) và chuyển chúng dưới dạng khoá-giá trị trong yêu cầu quảng cáo đến Ad Manager và báo cáo khoá-giá trị để báo cáo về nhãn. |
| Ưu đãi thử nghiệm | Nhà quảng cáo lo ngại về việc có đủ thời gian để thử nghiệm Hộp cát về quyền riêng tư và khả năng xảy ra những thay đổi quan trọng về API. | Chúng tôi hiểu rằng một số người muốn có thêm thời gian, nhưng chúng tôi đã nhiều lần nhận được ý kiến của toàn ngành rằng việc thay đổi tiến trình có thể sẽ làm giảm sự chuẩn bị cho hệ sinh thái, chứ không phải hơn. Mặc dù tiến trình ngừng sử dụng 3PCD còn phải giải quyết mọi mối lo ngại về cạnh tranh còn lại của CMA, nhưng chúng tôi khuyến khích mọi người chuẩn bị cho 3PCD vào năm 2024. Giống như mọi công nghệ, API Hộp cát về quyền riêng tư sẽ không ngừng phát triển. Quá trình phát triển này bắt nguồn từ những tiến bộ về công nghệ và dữ liệu đầu vào trong hệ sinh thái. Chúng tôi sẽ tiếp tục chịu trách nhiệm khi thực hiện các thay đổi và không cho rằng những thay đổi về công nghệ sẽ hạn chế vô thời hạn việc sử dụng. |
| CTV (TV kết nối Internet) | Không có đường dẫn để hỗ trợ video tuyến tính hoặc video CTV. | Chúng tôi mong muốn khám phá thêm về các trường hợp sử dụng CTV, nhưng không cho rằng API dành cho thiết bị CTV lại cản trở 3PCD trong Chrome. |
| Máy chủ quảng cáo của nhà quảng cáo | Có vẻ như Google đang chuyển tiêu chí nhắm mục tiêu quảng cáo sang DV360. Chúng tôi sẽ cung cấp dịch vụ hỗ trợ nào cho máy chủ quảng cáo của nhà quảng cáo? | Phản hồi do Chrome cung cấp: API PA được thiết kế để các máy chủ quảng cáo của nhà quảng cáo có thể phân phát và đo lường quảng cáo mà người dùng nhìn thấy thông qua tính năng báo cáo Báo hiệu và Khung nội tuyến / Khung bảo vệ. Ngoài ra, họ sẽ làm việc với các bên cấp trên và dưới cấp để tích hợp vào quy trình phân phát như hiện nay. |
| Trình quản lý dữ liệu Google Ads | "Công cụ quản lý dữ liệu của Google Ads" vừa được công bố gần đây được xây dựng dựa trên tính năng So khớp khách hàng và Lượt chuyển đổi nâng cao, cho phép nhà quảng cáo chia sẻ dữ liệu khách hàng của bên thứ nhất với Google để duy trì tất cả các chức năng tiếp thị do 3PC thực hiện. Tính năng mới này phù hợp với cam kết của Google đối với CMA như thế nào? | Phản hồi do Google Ads cung cấp: Công cụ quản lý dữ liệu của Google Ads chỉ đơn giản là hỗ trợ việc tải dữ liệu của bên thứ nhất lên từ các hệ thống lưu trữ dữ liệu của nhà quảng cáo (hệ thống đám mây) để nhà quảng cáo sử dụng cho tính năng So khớp khách hàng (CM) và Lượt chuyển đổi nâng cao (EC). Nhờ đó, các doanh nghiệp vừa và nhỏ có thể dễ dàng tải dữ liệu của bên thứ nhất lên với ít nguồn lực kỹ thuật hơn. Công cụ quản lý dữ liệu của Google Ads không cung cấp bất kỳ tính năng hoàn toàn mới nào cho Quản trị viên diễn đàn hoặc EC về khả năng xử lý và khả năng đo lường quảng cáo trên Google O&O HOẶC nhà xuất bản bên thứ ba. Các nền tảng quảng cáo của Google có quyền sử dụng các tính năng trong công nghệ Hộp cát về quyền riêng tư giống như các công ty khác về Công nghệ quảng cáo. |
| Cài đặt Chrome | Trang cài đặt nội bộ của Chrome sẽ cung cấp thêm thông tin về kích thước của cookie. | Chức năng được yêu cầu đã có trong Công cụ cho nhà phát triển Chrome. Chúng tôi hoan nghênh các ý kiến phản hồi bổ sung về lý do nên ưu tiên tính năng này trong trang cài đặt. |
| Liệu pháp luận | Chrome đang triển khai những phương pháp phỏng đoán nào để duy trì trải nghiệm người dùng quan trọng trong quá trình 3PCD? | Hãy xem câu trả lời của chúng tôi cho câu hỏi này trên GitHub. |
| Phiên bản trình duyệt | Phân biệt trình duyệt Chrome ổn định với trình duyệt Chrome không ổn định? | Sẽ có thể kết hợp được sơ bộ phiên bản lớn của Chrome với chu kỳ phát hành chính thức. |
| Độ giãn nở | Chrome có thể cung cấp các báo cáo liên quan đến SOX không? | Chrome sẽ không cung cấp các báo cáo liên quan đến SOX. API Hộp cát về quyền riêng tư là một trong nhiều API web mà Chrome cung cấp cho các trang web mà người dùng truy cập. Giống như tất cả các API web, phương thức gọi API không ký kết thoả thuận với Chrome để sử dụng API Hộp cát về quyền riêng tư; quyền truy cập chỉ phụ thuộc vào việc phương thức gọi API có đáp ứng bất kỳ yêu cầu kỹ thuật nào và người dùng đã bật chế độ cài đặt phù hợp hay không. Nếu có, chỉ phương thức gọi API sẽ xác định cách sử dụng API, bao gồm dữ liệu cần lưu trữ, giá thầu cần đặt, báo cáo nào cần yêu cầu, v.v. |
| Độ giãn nở | Mở rộng phần Câu hỏi thường gặp về việc tuân thủ Hộp cát về quyền riêng tư để giải đáp thêm nhiều câu hỏi. | Chúng tôi rất trân trọng ý kiến phản hồi của bạn và dự định sẽ tiếp tục xây dựng phần Câu hỏi thường gặp. |
| Câu hỏi về Chrome | Việc ngừng sử dụng 3PC trên Chrome có ảnh hưởng đến khả năng sử dụng 3PC trên Android WebView (trình duyệt được nhúng) không? | Hiện tại, chúng tôi không đưa WebView vào giai đoạn này trong quá trình triển khai và thử nghiệm API Hộp cát về quyền riêng tư hoặc 3PCD, ngoài việc cho phép Đo lường mô hình phân bổ trên nhiều ứng dụng và web. |
| Câu hỏi về API | Làm cách nào để theo dõi số lượt nhấp và số lượt hiển thị của các sản phẩm được tài trợ? | Trường hợp sử dụng này thuộc phạm vi của Attribution Reporting API. |
| Lịch trình | Tại sao tiến trình của mô hình 3PCD lại thay đổi? | Chúng tôi đã thảo luận về lý do tại đây. |
| SSO của tiện ích của Chrome | Cho phép trường hợp sử dụng đăng nhập một lần giữa trang web và tiện ích của Chrome sau khi có 3PCD. | Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn chia sẻ ý kiến phản hồi về các trường hợp sử dụng bổ sung. |
| Sử dụng API | Google có thể xác nhận danh sách đối tác để thử nghiệm API không? | Thông tin chi tiết về những người kiểm thử đã tự nhận dạng công khai có sẵn trên GitHub cho các API sau: – Topics API – Protected Audience API – Attribution Reporting API – Bộ nhớ dùng chung – CHIP |
| Sáng kiến Utiq | Quan điểm của Chrome về sáng kiến Utiq là gì? | Chúng tôi đang thảo luận về vấn đề này tại đây. |
| Câu hỏi về Chrome | Làm cách nào để phát hiện người dùng duyệt web mà không có 3PC? | Không có chế độ cài đặt rõ ràng nào để phát hiện việc chặn 3 máy tính. Đối với phương pháp "phát hiện tính năng" chung, bạn nên tạo yêu cầu iframe / nhiều trang web và cố gắng đặt cookie tương tự cho trường hợp sử dụng bắt buộc sẽ là giải pháp phù hợp nhất. |
| Câu hỏi về Chrome | Việc duyệt web ở chế độ ẩn danh có giống như chạy thử nghiệm gắn cờ không (chạy Chrome bằng cờ hiệu dòng lệnh --test-third-party-cookie-giai đoạnout)? | Chế độ ẩn danh khác với chế độ cờ. Cờ không chỉ chặn 3PC mà còn cho phép phân vùng bộ nhớ FedCM và bên thứ ba. |
| Câu hỏi về Chrome | Thông tin chi tiết về tác động dự kiến của công nghệ 3PCD đối với từng khu vực/quốc gia khi tỷ lệ này là 1%. | Khách hàng được đưa vào 1% một cách ngẫu nhiên trên toàn cầu, mặc dù có thể có sự khác biệt theo khu vực. Ví dụ: việc phân phối thiết bị và phiên bản Chrome có thể khác nhau. |
| Các công nghệ cải tiến công nghệ cải thiện quyền riêng tư thay thế | Bạn nên cho phép các công nghệ tăng cường quyền riêng tư thay thế trên nhiều miền tiến hành hoạt động theo dõi trên nhiều miền nhằm bảo đảm quyền riêng tư để tránh tình trạng độc quyền dữ liệu trên Chrome và Android. | Có rất nhiều cơ hội để nhà phát triển xây dựng các sản phẩm công nghệ giúp tăng cường quyền riêng tư dựa trên các thành phần chúng tôi đang cung cấp cũng như các thành phần không liên quan đến Hộp cát về quyền riêng tư. |
| Nghiên cứu CookieGraph | Quan điểm của Chrome về phương thức CookieGraph như thế nào như được mô tả trong bài viết này trong khung Hộp cát về quyền riêng tư? | Chúng tôi đang xem xét tài liệu này và chào mừng bạn có thêm ý kiến phản hồi. |
Đăng ký và chứng thực
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Quy trình đăng ký bị hạn chế | Google đã giới thiệu các điều khoản sử dụng cụ thể cho API Hộp cát về quyền riêng tư. Điều khoản ngăn chặn một cách hiệu quả những công ty chuyên giúp nhà xuất bản nhận biết sự đồng ý của khách truy cập để thử nghiệm và/hoặc tích hợp các tính năng của Hộp cát về quyền riêng tư vào giải pháp nhận dạng của họ. Các điều khoản và điều kiện sẽ giới hạn một cách không công bằng khả năng hoạt động trong Hộp cát về quyền riêng tư. | Quy trình đăng ký và chứng thực không liên quan đến việc đồng ý với các điều khoản sử dụng của API. Thay vào đó, việc đăng ký và chứng thực là các cơ chế nhằm cải thiện tính minh bạch về những API mà nhà phát triển gọi API Hộp cát về quyền riêng tư và cách họ sử dụng dữ liệu mà họ truy cập. Cụ thể, chứng thực là một tuyên bố công khai rằng nhà phát triển chứng thực không dùng API để nhận dạng người dùng trên các trang web hoặc ứng dụng, cũng như không né tránh các biện pháp bảo vệ quyền riêng tư của API đó. Chứng thực không yêu cầu đưa ra tuyên bố về việc nhà phát triển sử dụng dữ liệu hoặc công nghệ khác. |
| Đăng ký Hộp cát về quyền riêng tư | Cách cập nhật đầu mối liên hệ / địa chỉ email để chứng thực? | Bạn có thể cập nhật thông tin đăng ký bằng cách sử dụng biểu mẫu đăng ký. Bạn có thể xem thêm thông tin chi tiết tại đây. |
| Đăng ký Hộp cát về quyền riêng tư | Vui lòng làm rõ các trường hợp hạn chế quyền truy cập trong trường hợp không có chứng thực? | Hộp cát về quyền riêng tư sẽ có 3 tuần để nhân viên liên hệ kỹ thuật thiết lập lại tệp chứng thực cho trang web đã đăng ký trước khi từ chối quyền truy cập của một công ty đã đăng ký vào (API về mức độ liên quan và đo lường). |
| Đăng ký Hộp cát về quyền riêng tư | Làm cách nào để kiểm thử API trong môi trường cục bộ bằng các điểm cuối ngoài phiên bản chính thức? | Chúng tôi đã trả lời câu hỏi này tại đây. |
Hiển thị nội dung và quảng cáo có liên quan
Chủ đề
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Tính hữu ích cho các kiểu bên liên quan khác nhau | Các nhà xuất bản lo ngại về tác động của các chủ đề đối với doanh số bán hàng dựa trên dữ liệu. Các trang web lớn hơn được gán một Chủ đề 'tin tức' chung, không có dữ liệu nào liên kết chủ đề đó với nhà xuất bản cụ thể. Nhà xuất bản chuyên biệt cung cấp dữ liệu của họ cho một số thông tin hạn chế để đổi lại. | Chúng tôi xác nhận rằng các trang web có miền có mối quan tâm chung có nhiều khả năng đóng góp chủ đề ít chi tiết hơn so với các trang web có miền có mối quan tâm riêng. Tuy nhiên, không phải tất cả các trang web chuyên biệt đều đóng góp những chủ đề có giá trị thương mại. Ngoài ra, tính linh động này còn phản ánh tình trạng hiện tại - rằng một số trang web cung cấp nhiều giá trị hơn các trang web khác trong hệ thống mức độ liên quan của quảng cáo dựa trên 3PC. Chủ đề (và Hộp cát về quyền riêng tư nói chung) giúp nhà xuất bản có nhiều quyền kiểm soát hơn đối với cách các công ty công nghệ quảng cáo mà họ hợp tác sử dụng thông tin của họ. Ngoài ra, thông tin có sẵn thông qua Chủ đề sẽ thô hơn nhiều so với các tín hiệu hiện có. |
| Máy chủ Quảng cáo của nhà xuất bản | Máy chủ quảng cáo của nhà xuất bản sử dụng máy chủ quảng cáo chuyên dụng có thể không trực tiếp theo dõi được Topics API. | Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi. |
| Chứng thực | Mở rộng yêu cầu về chứng thực để giải quyết các hậu quả không mong muốn đã biết của việc chuyển thông tin theo ngữ cảnh. | Hiện tại, việc chứng thực không nhằm mục đích bao gồm loại rủi ro rộng này mà là để giải quyết hành vi sử dụng API sai mục đích. |
| Lượng lưu lượng truy cập Chủ đề | Số lượt hiển thị hiện tại không đủ để thử nghiệm. | Chrome đã biết được ý kiến phản hồi về số lượng Chủ đề hiện có trong hệ sinh thái có lập trình. Chúng tôi đang điều tra những nguyên nhân có thể xảy ra, cả trong trình duyệt và trong số những người kiểm thử có liên quan. Nếu thấy cần thiết, Chrome sẽ đánh giá những thay đổi có thể có về thiết kế API để tăng mức độ phù hợp và cho phép thử nghiệm trên quy mô đủ lớn trong khi vẫn đảm bảo quyền riêng tư của người dùng. |
| Sử dụng API | Có giới hạn về tỷ lệ của Topics API không? | Chúng tôi áp dụng một số giới hạn số lượng yêu cầu Chủ đề để ngăn chặn hành vi sai trái và bảo vệ trải nghiệm của người dùng trên web. Bạn có thể xem thêm một số thông tin chi tiết tại đây. |
| Phân loại phiên bản 2 | Nguyên tắc của IAB về việc đưa thông tin chi tiết về chủ đề vào giao thức RTB mở? | Có, bạn có thể xem các nguyên tắc của IAB về việc đưa Chủ đề vào giao thức Open RTB tại đây. |
| Tác động đến tín hiệu của bên thứ nhất | Phân loại Chủ đề chi tiết phiên bản 2 kết hợp với quy trình trả về giá trị cao nhất của phân đoạn chi tiết này (các chủ đề hàng đầu) sẽ làm méo mó thị trường cho dữ liệu trong quảng cáo. | Phản hồi của chúng tôi vẫn không thay đổi so với Quý 3: "Mặc dù cách phân loại Chủ đề chi tiết hơn có thể gián tiếp làm giảm sức hấp dẫn của các giải pháp khác, chẳng hạn như những giải pháp dựa trên dữ liệu bên thứ nhất của nhà xuất bản hoặc những giải pháp dựa vào giao dịch trực tiếp, vì chúng tôi phát triển Topics API, mục tiêu chính của chúng tôi là đảm bảo việc hỗ trợ các trường hợp sử dụng quảng cáo dựa trên mối quan tâm sau 3PCD hiệu quả nhất có thể, cho tất cả các bên liên quan. Chúng tôi tin rằng việc dùng Chủ đề hữu ích hơn sẽ giúp cải thiện khả năng cạnh tranh nói chung và mang lại lợi ích cho toàn bộ hệ sinh thái." |
| Danh sách người thử nghiệm | Các nhà xuất bản của bạn sử dụng Topics và PA API như thế nào? | Chúng tôi không thể chia sẻ những thông tin như vậy. Bạn có thể tham khảo danh sách người kiểm thử, nơi nhà xuất bản có thể chọn chia sẻ trạng thái thử nghiệm của họ. |
| Lựa chọn chủ đề | Cho phép người dùng chủ động chọn các chủ đề mà họ quan tâm? | Chắc chắn là chúng tôi đã cân nhắc việc cho phép người dùng chủ động thêm chủ đề. Chúng tôi không có ý định giải quyết vấn đề này trong thời gian ngắn, nhưng chúng tôi sẵn sàng khám phá thêm về vấn đề này trong dài hạn. |
| Lựa chọn chủ đề | Nếu một công nghệ quảng cáo có mã trên trang web để quan sát các chủ đề, thì công nghệ quảng cáo đó có thể biết chủ đề đó có thể được quan sát là gì không? | Một công ty công nghệ quảng cáo có thể xác định các chủ đề liên kết với một trang web. API này không chia sẻ thông tin này theo thời gian thực vì có thể gây ra chi phí cho độ trễ. |
| Phân loại phiên bản 2 | Vì Chủ đề có thể trả về tối đa 3 Chủ đề, nên hành vi dự kiến khi Phân loại phiên bản 2 ra mắt là gì? | API sẽ vẫn trả về tối đa 3 Chủ đề và sẽ đưa phiên bản phân loại có liên quan cho từng Chủ đề vào phản hồi. |
| (Cũng được báo cáo trong các quý trước) Quan sát chủ đề |
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 đề hoặc nội dung). | Phản hồi của chúng tôi vẫn không thay đổi so với Quý 3: "Trước đây, chúng tôi đã cân nhắc việc cung cấp chức năng phân loại các trang web thành chủ đề dựa trên nội dung trang. Chúng tôi quyết định không tiếp tục vì các lo ngại về quyền riêng tư và bảo mật. Đề xuất này có thể giảm thiểu một số mối lo ngại đó, nhưng không rõ ở mức độ nào. Do giai đoạn thử nghiệm CMA sắp tới, chúng tôi dự kiến thay đổi này sẽ không xảy ra trước khi triển khai tính năng 3PCD. Chúng tôi mong nhận được thêm ý kiến phản hồi tại đây." |
| Lựa chọn chủ đề | Dựa trên thực tế là các miền đó chung chung, các miền được phân loại với Chủ đề được phân loại như thế nào? | Chúng tôi chỉ sử dụng tên máy chủ để phân loại các trang web vào Chủ đề. Một trang web đang được phân loại rộng không bị tổn hại do điều này. Lý do là thông tin theo bối cảnh của một trang web sẽ luôn có sẵn cho các phiên đấu giá trên trang web đó. Việc này sẽ cung cấp thông tin cụ thể hơn về Chủ đề rộng. |
| Phân loại phiên bản 2 | Mong muốn các chủ đề phù hợp hơn với các tiêu chuẩn khác (ví dụ: IAB). | Chúng tôi muốn tìm hiểu thêm về lý do họ muốn có sự liên kết chặt chẽ hơn giữa IAB và hệ thống phân loại Chủ đề. Người này cần thực hiện những bước nào để sử dụng Topics API và cách phân loại khác biệt hơn ảnh hưởng đến những bước đó như thế nào? Chúng tôi đang xem xét việc liên kết giữa hệ thống phân loại Chủ đề và hệ thống phân loại nội dung của IAB. Sẽ rất hữu ích nếu bạn tìm hiểu xem làm như vậy có giải quyết được những thách thức mà nhà xuất bản gặp phải hay không. |
| Lưu trữ và sử dụng dữ liệu | Bạn có thêm thông tin về cách dữ liệu được lưu trữ và nơi dữ liệu được chuyển không? | Thông tin về chủ đề được tạo và lưu trữ trên thiết bị của người dùng. Theo yêu cầu, API sẽ trả về tối đa 3 Chủ đề cho phương thức gọi. Theo chế độ xem của Google, phương thức gọi có trách nhiệm tuân thủ các quy định của địa phương khi xử lý và lưu trữ thông tin về Chủ đề. Ngoài ra, tất cả phương thức gọi phải xác nhận rằng họ không sử dụng Chủ đề để nhận dạng lại người dùng trên các trang web. Vui lòng tham khảo bài viết Câu hỏi thường gặp về việc tuân thủ liên quan đến quyền riêng tư để biết thêm chi tiết. |
| Phân loại phiên bản 2 | Ảnh hưởng của Bản nâng cấp phân loại chủ đề và trạng thái của trình duyệt khi chuyển đổi từ phiên bản 1 sang phiên bản 2. | Các Chủ đề được dự đoán bằng Hệ thống phân loại trước đó vẫn có sẵn và cuối cùng có thể được công nghệ quảng cáo tìm nạp cho đến khi hết hạn (4 tuần tuổi). |
| Mô tả API | Trải nghiệm người dùng của Topics API gây hiểu lầm. | Chúng tôi đã chia sẻ ý kiến phản hồi này với nhóm trải nghiệm người dùng. |
| Câu hỏi về API | Các miền Yahoo được phân loại với Chủ đề vì chúng là chủ đề chung chung như thế nào? | Chúng tôi chỉ sử dụng tên máy chủ để phân loại các trang web vào Chủ đề. Bạn cần hiểu rằng một trang web đang được phân loại rộng sẽ không bị tổn hại do điều này. |
| Tỷ lệ sử dụng chủ đề thấp | Người thử nghiệm đang nhận được khối lượng nhỏ Chủ đề từ Google Ad Manager. | Google Ad Manager đã triển khai một số biện pháp tối ưu hoá để cải thiện mức độ phù hợp – người mua chắc hẳn đã thấy mức độ phù hợp cao hơn. Có một số yếu tố dự kiến có thể giới hạn phạm vi (ví dụ: lựa chọn ưu tiên của người dùng, yêu cầu quan sát của phương thức gọi, có thể là độ trễ/thời gian chờ). |
Protected Audience API (trước đây là FLEDGE)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Phân biệt | Thiếu thông tin rõ ràng về cách các SSP tạo ra sự khác biệt cho phiên đấu giá mới. | Chúng tôi đã nghe nói về nhiều kế hoạch chiến lược tập trung vào Protected Audience API và/hoặc các API Hộp cát về quyền riêng tư khác. Bối cảnh bao quát hơn, việc giảm các giá trị nhận dạng phổ biến trên nhiều trang web thường được bên bán trong hệ sinh thái xem là một bước tích cực, không chỉ xét về quyền riêng tư mà còn về mặt thương mại. Các doanh nghiệp lớn và nhỏ, những người thích ứng với thay đổi này có khả năng tìm thấy cơ hội. |
| Hiển thị quảng cáo | Chrome là con đường duy nhất để hiển thị quảng cáo cản trở sự đổi mới. Hiển thị trong Protected Audience làm giảm khả năng tồn tại của các tiêu chuẩn hiện nay về quảng cáo gốc. | Quảng cáo hiển thị trong trình duyệt luôn sử dụng công nghệ trình duyệt để hiển thị. Điều đó sẽ không thay đổi. Có lẽ, mối lo ngại này dành riêng cho các kế hoạch yêu cầu sử dụng Khung bảo vệ cùng với Protected Audience trong tương lai. Một phần lý do khiến các kế hoạch đó là "trong tương lai" chính xác là vì chúng tôi muốn công nghệ Khung bảo vệ hỗ trợ đổi mới và tạo ra sự khác biệt cho hệ sinh thái khi nói đến hiển thị quảng cáo. Có thời gian để các nhà phát triển và công ty quan tâm cân nhắc hướng đến Khung bảo vệ, bao gồm cách hỗ trợ các phương pháp quảng cáo gốc. |
| Đầu vào | Protected Audience API (API API) có liên quan đã được phân phối vào thời điểm nhiều công nghệ quảng cáo bắt đầu khám phá API Hộp cát về quyền riêng tư. | API sẽ tiếp tục phát triển dựa trên những gì chúng tôi học được từ việc sử dụng cũng như các ý tưởng mới của cả bên trong lẫn bên ngoài Chrome. Các API đo lường và mức độ liên quan được cung cấp rộng rãi hiện nay đều ổn định, nhưng điều đó không có nghĩa là hoạt động phát triển đã dừng lại và chúng tôi hoan nghênh các ý kiến phản hồi bổ sung. |
| Thiết kế phiên đấu giá | Thiết kế Protected Audience đặt toàn bộ logic tạo đối tượng và lựa chọn quảng cáo vào nền tảng bên mua, loại bỏ khả năng SSP cung cấp logic tạo đối tượng và lựa chọn quảng cáo cho các chiến dịch được thực thi trên nền tảng đó. | Protected Audience không phân biệt người tạo đối tượng và người đặt giá thầu cho đối tượng. SSP có thể tạo một Nhóm mối quan tâm (IG) để đặt giá thầu. SSP cũng có thể cung cấp logic đặt giá thầu phù hợp với định hướng mà nhiều SSP đang triển khai trực tiếp cho công ty quảng cáo. Mặc dù luôn có thể sử dụng thêm các trường hợp khác, nhưng nền tảng của Protected Audience đủ linh hoạt để hỗ trợ nhiều phương pháp tạo và kích hoạt đối tượng. Đặc điểm về quyền riêng tư của những nền tảng đó cũng có nghĩa là dữ liệu chưa qua xử lý ở cấp người dùng không được chia sẻ giữa các trang web. |
| Thiết kế phiên đấu giá | Phiên đấu giá trong Protected Audience có hoạt động ngược lại các nỗ lực Tối ưu hoá lộ trình cung ứng (SPO) của hệ sinh thái nhằm giảm tổng số bên trung gian giữa nhà quảng cáo và nhà xuất bản và/hoặc sao chép một cơ hội quảng cáo nhất định không? | Không. Một quảng cáo giành chiến thắng trong Protected Audience sẽ chuyển qua tối đa 2 thực thể của người bán (ví dụ: SSP và máy chủ quảng cáo của nhà xuất bản) và chỉ một số lượng là không, nếu người mua xây dựng chế độ tích hợp trực tiếp với nhà xuất bản. Nhà xuất bản vẫn có quyền chọn sao chép cùng một yêu cầu thông qua nhiều bên trung gian. Protected Audience không được tác động theo cách này hay cách khác. Phiên đấu giá trong Protected Audience diễn ra bên ngoài hệ thống theo thời gian thực giữa các máy chủ hiện nay để không làm rò rỉ dữ liệu người dùng trên nhiều trang web. Một số người có thể nói rằng điều này trùng lặp một yêu cầu quảng cáo. Để có thể chứng minh được quyền riêng tư về mặt kỹ thuật, bạn sẽ phải đánh đổi một số điểm. Tuy nhiên, về lâu dài có thể hệ sinh thái sẽ quyết định sử dụng Protected Audience mà không cần các phiên đấu giá phía máy chủ truyền thống. Lựa chọn này có thể dẫn đến các đường dẫn cung ứng được tối ưu hoá hơn nữa. |
| Thiết kế phiên đấu giá | Protected Audience chuyển sang mô hình mà SSP hiếm khi là phiên đấu giá "gần đây nhất" chạy trên trang nhưng bị thiết kế API buộc phải đưa vào mô hình này. | Chúng tôi không đồng ý. Các phương pháp triển khai dành cho người sử dụng sớm mà chúng tôi thấy thực sự giúp SSP tham gia phiên đấu giá thành phần có thể đánh bại kết quả của phiên đấu giá theo bối cảnh, diễn ra trước khi phiên đấu giá Protected Audience chạy. Kết quả đầu ra của phiên đấu giá thành phần SSP trong Protected Audience được xem là kết quả cuối cùng, sau khi chạy phiên đấu giá theo bối cảnh đầy đủ. |
| Thiết kế phiên đấu giá | Phiên đấu giá theo bối cảnh chỉ có thể phù hợp để cung cấp các tín hiệu dữ liệu về cơ hội đấu giá để cung cấp thông tin cho phiên đấu giá trong Protected Audience. | Chúng tôi dự kiến rằng phiên đấu giá theo bối cảnh sẽ vẫn phù hợp vì nhiều lý do như giao dịch, chiến dịch nhắm mục tiêu theo đối tượng không phải bên thứ nhất và nhiều tình huống theo bối cảnh. Giá trị này cũng có giá trị khi không có IG nào hoặc giá thầu trong Protected Audience không đạt đến giá sàn hoặc không tuân thủ các quy tắc về chất lượng quảng cáo. |
| Mô hình lưu lượng truy cập | DSP đang hoạt động với QPS cố định. Việc điều chỉnh phiên đấu giá trong Protected Audience sẽ làm giảm tiện ích của cơ sở hạ tầng cũ. | Theo như chúng ta đã hiểu, có một điều đang thay đổi liên quan đến truy vấn mỗi giây là nhiều SSP sử dụng mã nhận dạng nhiều trang web làm tính năng để xác định xem có gửi yêu cầu DSP hay không. Điều này luôn đúng cho dù nhà xuất bản có muốn chạy phiên đấu giá Protected Audience hay không. Chúng tôi đã khám phá việc định hình lưu lượng truy cập với nhiều SSP và tìm thấy các giải pháp như lưu vào bộ nhớ đệm và lọc theo ngữ cảnh. Theo thời gian, chúng tôi hy vọng các nhà phát triển sẽ tận dụng được tính năng Tổng hợp riêng tư để hỗ trợ thêm cho việc hiểu rõ các lựa chọn ưu tiên về đặt giá thầu DSP và lọc ra những dữ liệu phù hợp. Sau cùng, một số cơ sở hạ tầng cũ được xây dựng dựa trên giá trị nhận dạng trên nhiều trang web sẽ không còn hữu ích nữa. |
| Tín hiệu có sẵn | Việc không nắm rõ đầy đủ các tín hiệu có sẵn khi phiên đấu giá diễn ra và cách sắp xếp trình tự với phiên đấu giá theo bối cảnh sẽ gây bất lợi cho điều đó. | Nói chung, đối với bên đặt giá thầu, thông tin có thể được cung cấp khi IG được tạo, từ phiên đấu giá theo bối cảnh và từ quá trình tra cứu khoá-giá trị theo thời gian thực. Đối với trình tính điểm, thông tin có thể được cung cấp khi phiên đấu giá được định cấu hình, bao gồm thông tin theo ngữ cảnh về trang và phiên đấu giá theo ngữ cảnh, cũng như từ việc tra cứu khoá-giá trị theo thời gian thực trên displayUrls quảng cáo. |
| (Được báo cáo trong các quý trước) Hiển thị video |
Hỗ trợ kết xuất video bằng Đối tượng được bảo vệ và Khung bảo vệ. | Câu trả lời của chúng tôi không thay đổi so với các quý trước: "Protected Audience API hỗ trợ tính năng hiển thị video bằng cơ chế dựa trên iframe. Tuy nhiên, chúng tôi chưa thiết kế giải pháp tương thích với Khung bảo vệ và đây là một trong những lý do khiến chúng tôi quyết định đẩy lùi việc thực thi Khung bảo vệ sang năm 2026. Điều đó có nghĩa là nếu một đối tác quyết định thực thi Khung bảo vệ ngay bây giờ, thì đối tác đó sẽ thiếu hỗ trợ cho video". |
| Kết xuất video | Hỗ trợ API PA cho video trong iframe bị giới hạn ở video HTML5 và không hỗ trợ tiêu chuẩn VAST được sử dụng rộng rãi. | Bạn có thể triển khai quảng cáo dựa trên VAST bằng cách sử dụng cơ chế hiển thị iframe hiện có trong Protected Audience. Google xác nhận rằng việc này đòi hỏi phải có kỹ thuật mới từ phía người mua, người bán và nền tảng quảng cáo của nhà xuất bản. Chúng tôi sẽ tiếp tục nỗ lực để dễ dàng chuyển đổi từ cách mà VAST đã hoạt động trước đây. |
| (Được báo cáo trong các quý trước) Phiên đấu giá cấp cao nhất |
Khả năng sử dụng máy chủ quảng cáo của nhà xuất bản của Google mà không cần cấp cho Google Ad Manager quyền kiểm soát phiên đấu giá API PA cấp cao nhất. | Phản hồi của chúng tôi không thay đổi so với các quý trước: "Nội dung phản hồi do Google Ad Manager cung cấp: Kế hoạch của Google Ad Manager đối với Protected Audience API không bao gồm việc hỗ trợ máy chủ quảng cáo của nhà xuất bản của Google mà không có quyền kiểm soát phiên đấu giá Protected Audience cấp cao nhất vì những lý do sau. Để phân phát đúng cách cho khách hàng trong thị trường phân phát quảng cáo của nhà xuất bản, máy chủ quảng cáo của nhà xuất bản của Google cần duy trì quyền kiểm soát phiên đấu giá cấp cao nhất trong Protected Audience. Là máy chủ quảng cáo của nhà xuất bản, vai trò của chúng tôi là cung cấp cho nhà xuất bản thông tin dự báo để họ có thể thương lượng các chiến dịch được bán trực tiếp mà không cần đặt trước quá nhiều, đồng thời điều chỉnh tốc độ và phân phối các mục đặt trước trực tiếp một cách tối ưu. Để làm được việc này, bạn phải chạy phiên đấu giá cuối cùng để so sánh tất cả nhu cầu trực tiếp và gián tiếp đủ điều kiện. Tính năng dự báo và tốc độ là các chức năng cốt lõi mà nhà xuất bản yêu cầu ở máy chủ quảng cáo. Nếu không dự báo chính xác, nhà xuất bản có thể sẽ bán quá nhiều khoảng không quảng cáo, điều này gây rủi ro cho uy tín kinh doanh. Tốc độ cũng rất quan trọng, do việc không thể thực hiện hợp đồng đặt trước với nhà quảng cáo cũng có nguy cơ làm hỏng mối quan hệ trực tiếp giữa nhà xuất bản và nhà quảng cáo, do đó có thể ảnh hưởng đáng kể đến hoạt động kinh doanh của nhà xuất bản. Do đó, chúng tôi không thấy hoạt động chạy phiên đấu giá cấp cao nhất của Protected Audience trên máy chủ quảng cáo của nhà xuất bản khác biệt với các hoạt động khác trên máy chủ quảng cáo của nhà xuất bản." |
| (Được báo cáo trong các quý trước) directFrom SellerSignals |
DirectFromSellerSignals cho phép Google Ad Manager ngăn nhà xuất bản xem giá của phiên đấu giá theo bối cảnh. |
Nội dung 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: Chúng tôi không xác định được rằng thông tin được chuyển vào runAdĐấu giá() từ người bán trừ khi người bán gọi runAdauction() từ iframe riêng của họ. Trong phiên đấu giá nhiều người bán, tất cả người bán đều không thể tạo khung gọi runAdBid(). DirectFromSellerSignals đã giải quyết vấn đề này bằng cách tải nội dung 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 giúp đảm bảo rằng tính xác thực và tính toàn vẹn của thông tin được chuyển vào phiên đấu giá từ cấu hình phiên đấu giá của người bán sẽ không bị chỉnh sửa. Nếu muốn sử dụng Protected Audience API để tìm hiểu bất kỳ thông tin nào mà nhà cung cấp công nghệ của họ đang chuyển vào phiên đấu giá trong Protected Audience, thì nhà xuất bản có thể yêu cầu các nhà cung cấp công nghệ đó cung cấp chức năng này. Phản hồi từ Google Ad Manager: Nhiều năm qua, chúng tôi vẫn luôn chú trọng tính công bằng trong phiên đấu giá, bao gồm cả cam kết của chúng tôi rằng không có giá nào từ bất kỳ nguồn quảng cáo không bảo đảm nào của nhà xuất bản, bao gồm cả giá của mục hàng không bảo đảm, sẽ được chia sẻ với một người mua khác trước khi họ đặt giá thầu trong phiên đấu giá. Sau đó, chúng tôi khẳng định lại trong cam kết với Cơ quan cạnh tranh của Pháp. Đối với các phiên đấu giá trong Protected Audience, chúng tôi dự định giữ đúng lời hứa của mình bằng cách tận dụng trực tiếp từ DirectFromSellerSignals và không chia sẻ giá thầu của bất kỳ người tham gia phiên đấu giá nào khác với bất kỳ người tham gia phiên đấu giá nào khác trước khi hoàn tất phiên đấu giá trong phiên đấu giá nhiều người bán. Xin làm rõ, chúng tôi 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 chính mình, như đã giải thích trong bản cập nhật này." |
| (Được báo cáo trong các quý trước) Giá trị K-anonymity |
Giá trị "K" thành "k-anon" sẽ được quyết định như thế nào và khi nào giá trị này sẽ được xuất bản? | Chúng tôi đã công bố giá trị K-anonymity (giá trị K-anonymity) vào tháng 12 năm 2023. Sau khi quá trình 3PCD bắt đầu, chúng tôi sẽ nâng ngưỡng ẩn danh k đến giá trị cuối cùng là 50 (k=50) và đặt khoảng thời gian cập nhật là 1 giờ (p=1). Giá trị K-anonymity (độ ẩn danh K) là 50 được đánh giá là mang lại sự cân bằng tối ưu giữa sự hữu dụng và quyền riêng tư. Giá trị này đủ để đối phó với các cuộc tấn công cơ bản của bot và duy trì sự riêng tư biệt lập, đồng thời cũng đủ thấp để API tiếp tục hữu ích cho các trường hợp sử dụng dự kiến. |
| (Được báo cáo trong các quý trước) forDebuggingOnly |
Có khả năng forDebuggingOnly.reportAdauctionWin bị sử dụng sai mục đích nếu vẫn sau lỗi 3PCD. | Chúng tôi đã chia sẻ đề xuất về cách tiếp tục hỗ trợ các trường hợp sử dụng gỡ lỗi về lâu dài tại đây. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung về đề xuất này. |
| (Được báo cáo trong các quý trước) Chính sách cùng nguồn gốc |
Yêu cầu nới lỏng chính sách yêu cầu cùng nguồn gốc để cho phép miền con. | Yêu cầu này đang được xem xét và chúng ta đã thảo luận về vấn đề này tại đây. |
| (Được báo cáo trong các quý trước) Kích thước thành phần quảng cáo |
Tăng số lượng thành phần quảng cáo từ 20 lên 40. | Chúng tôi đã thảo luận về yêu cầu này trong cuộc gọi từ WICG vào ngày 4 tháng 10 và trong vấn đề này trên GitHub và dự định giải quyết vào cuối Quý 1 năm 2024. |
| (Được báo cáo trong các quý trước) Ngày hết hạn khoá máy chủ khoá giá trị |
Nội dung thảo luận về việc xoá khoá máy chủ sau khi các IG tương ứng đã hết hạn. | Việc quản lý TTL có thể được thực hiện tốt hơn bên ngoài TEE để giảm sự phức tạp, mặc dù chúng tôi hoan nghênh ý kiến phản hồi bổ sung tại đây. |
| Trình kích hoạt nhóm mối quan tâm | Một IG có thể kích hoạt nhiều generateBid trong một phiên đấu giá (theo thành phần) không? | Mỗi khi trình duyệt gọi hàm generateBid() của IG, IG đó sẽ được phép trả về một giá trị giá thầu. Ví dụ: trong phiên đấu giá nhiều người bán, một IG được gọi nhiều lần, mỗi lần ở một trong các phiên đấu giá thành phần. Bạn không cần chủ sở hữu IG làm gì để kích hoạt/hỗ trợ hành vi này. |
| Câu hỏi về việc tuân thủ | Phạm vi thu thập sự đồng ý thông qua trình duyệt Chrome của người dùng là gì? | Vui lòng tham khảo bài viết "Hộp cát về quyền riêng tư đạt được sự tuân thủ liên quan đến quyền riêng tư trong Chrome như thế nào?" trong phần Câu hỏi thường gặp về việc tuân thủ liên quan đến quyền riêng tư để biết thông tin chi tiết. |
| Phiên đấu giá nhiều thẻ | Làm cách nào để phù hợp với phiên đấu giá nhiều thẻ? | Chúng tôi đang đánh giá yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Khả năng cung cấp biện pháp bảo vệ IP | Việc bảo vệ IP chưa sẵn sàng trước ngày thông báo sẽ ảnh hưởng như thế nào đến dòng thời gian của tính năng Protected Audience? | Như đã đề cập tại đây, chúng tôi tin rằng dòng thời gian của Protected Audience phải được liên kết với lịch trình phát hành của các tính năng bảo vệ quyền riêng tư khác. |
| modelingSignals | Yêu cầu một trường mới ngoài modelSignals chỉ có thể mã hoá thông tin hiển thị và thông tin lượt nhấp. | Chúng tôi hiểu được những lợi ích mà việc này mang lại, do đó chúng tôi đang đánh giá yêu cầu và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| IG âm tính | Có thể cho phép IG bình thường chỉ định tên IG âm không? | Hiện tại, bạn không thể làm việc này theo phần giải thích, nhưng chúng tôi rất mong nhận được ý kiến phản hồi khác về hệ sinh thái về lý do yêu cầu này là cần thiết. |
| Sử dụng API | Tạo báo cáo tổng hợp khi vượt qua cấp generateBid() | Có thể gọi tính năng Tổng hợp riêng tư bên trong generateBid. |
| Macro | Định tuyến tín hiệu từ per BuyerSignals qua macro trong IFrames đến 3P. | Chúng tôi đang thảo luận về trường hợp sử dụng này tại đây và hoan nghênh bạn đóng góp thêm ý kiến phản hồi. |
| Sử dụng API | Nếu tìm nạp Tín hiệu tính điểm đáng tin cậy trả về lỗi thì scoreAd() vẫn được gọi? | ScoreAd() vẫn sẽ chạy nếu lệnh gọi tìm nạp không thành công. |
| Sử dụng API | Ghi siêu dữ liệu.shard_num trong tệp riegeli cho tệp delta/snapshot. | Hiện tại, chúng tôi sẽ hỗ trợ shard_num để bỏ chặn. Riegeli không được áp dụng tốt như Avro nhưng không bị bỏ qua. Vì TEE có nhiều hạn chế và chi phí hơn, nên chúng tôi phải đánh đổi để ưu tiên hiệu suất hơn là trải nghiệm người dùng. Chúng tôi đang cân nhắc việc cung cấp dịch vụ gRPC để tạo tệp theo yêu cầu. Chúng tôi cũng có thể đánh giá mức tác động của các định dạng khác như Avro. |
| Kiểm thử API | API PA và Measurement API sẽ hỗ trợ kiểm thử mức độ gia tăng như thế nào? | Hộp cát về quyền riêng tư không có cách nào để đo lường mức độ gia tăng bằng phiên đấu giá trước đối kháng. Bạn có thể sử dụng Bộ nhớ dùng chung và tính năng Tổng hợp riêng tư, nhưng nội dung phản thực tế chỉ diễn ra sau phiên đấu giá. |
| Sử dụng API | Việc sử dụng | Vì k-anonymity không còn được xem xét cho các bản cập nhật IG, nên bạn có thể cập nhật giá thầu WasmHelperURL mà không ảnh hưởng đến ngưỡng này. |
| Sử dụng API | Chúng tôi có thể nhận được thông báo lỗi về API PA không? | Chúng tôi hoan nghênh ý kiến phản hồi của hệ sinh thái về loại thông báo lỗi mà họ cần để khắc phục các vấn đề về API PA. |
| Kích thước quảng cáo | Kích thước quảng cáo không hiển thị trong phiên đấu giá cũng như trong báo cáo có thể. | Chúng tôi đang giải quyết vấn đề liên quan đến yêu cầu lấy dữ liệu này. |
| Sử dụng API | Điểm cuối IG cập nhật có được gọi cho IG nếu không tham gia phiên đấu giá này không? | Có. UpdateURL được gọi cho tất cả IG của một chủ sở hữu nhất định, ngay cả khi họ không đặt giá thầu trong phiên đấu giá cụ thể đó. Yêu cầu duy nhất là: – chủ sở hữu phải được đưa vào một phiên đấu giá nhất định (tức là được đưa vào với tư cách là người mua trong phiên đấu giáConfig) – sở thích của chủ sở hữu cụ thể không được cập nhật trong vòng 24 giờ qua. |
| Tính năng Đặt giá thầu trước trong API PA | Cần có phiên bản Prebid.js nào cho giai đoạn thử nghiệm? | Theo tài liệu kỹ thuật của chúng tôi, phiên bản phải >= 8.9.0. |
| Kích hoạt dữ liệu của bên thứ nhất trong PA API | Nhà quản lý tiếp thị này có thể kích hoạt dữ liệu của bên thứ nhất của riêng mình bằng cách nào để định nghĩa và sử dụng IG? | Bạn có thể sử dụng tính năng "Uỷ quyền cấp quyền" và "nhóm mối quan tâm phủ định" cho nhiệm vụ này. |
| PA API và tính năng gắn thẻ phía máy chủ | API PA hoạt động như thế nào với tính năng gắn thẻ phía máy chủ? | Thẻ cơ sở trên trình duyệt của người dùng cần chuyển hướng lệnh gọi API đến các thẻ còn lại ở phía máy chủ, nhờ đó, họ cũng có thể đăng ký lệnh gọi. |
| Thử nghiệm Chrome (chế độ a/b) | Kỳ vọng rằng SSP cũng sẽ chuyển những nhãn này trong yêu cầu giá thầu RTB? Nếu có thì làm thế nào? | Có, kỳ vọng là nhãn sẽ được chuyển từ SSP sang DSP. Các thực thể nên truy cập vào nhãn và chia sẻ giá trị chưa sửa đổi với đối tác thông qua Tiện ích thiết bị này. |
| Lưu trữ và sử dụng dữ liệu | Bạn có thêm thông tin về cách dữ liệu được lưu trữ và nơi dữ liệu được chuyển không? | Chúng tôi sẽ không cung cấp hướng dẫn pháp lý mà chỉ cung cấp hướng tiếp cận/suy nghĩ chung của chúng tôi về vấn đề lưu trữ, lưu giữ và các vấn đề khác về quyền riêng tư. Xem các câu hỏi thường gặp hữu ích về việc tuân thủ liên quan đến quyền riêng tư tại đây. |
| Độ an toàn của API | Lo ngại về việc mã phía máy khách độc hại thao túng giá trị trả về của hàm generateBid(). | Chúng tôi đã thảo luận về vấn đề này tại đây và một số ý kiến phản hồi đã được đưa vào đề xuất Tổng hợp riêng tư. |
| Đích đến tuỳ chỉnh | Khi sử dụng các lệnh gọi reportEvent đích tùy chỉnh, bạn có biết liệu nguồn gốc báo cáo tùy chỉnh (không phải cho người mua hay người bán) được đăng ký trước như một phần của IG trong allowedReportingOrigins có cần phải được DSP khai báo trong reportWin bằng registerAdBeacon hay không? | Không. Bạn không cần đăng ký lại sự kiện này trong reportWin và có thể sử dụng trực tiếp trong reportEvent như được nêu tại đây. |
| Các quy định hạn chế đối với API | Kích thước IG trong quá trình tạo và cập nhật. | Kích thước bản cập nhật đã được cập nhật thành 1 MB, phù hợp với giới hạn 1 MB mới (từ 50 KB) để tạo IG. |
| Các hạn chế về K-anon | K-anon cho quảng cáo có chứa nhiều kích thước. | Chúng tôi đã ra mắt giá trị K-anonymity vào tháng 12 năm 2023, trong đó nêu rõ giá trị K-anonymity sẽ bắt đầu kiểm tra kích thước quảng cáo "khoảng sau năm 2025". Không có cách nào để loại trừ kích thước vì đó có thể là vectơ theo dõi trên nhiều trang web, như được mô tả trong lệnh gọi WICG vào ngày 11 tháng 10. |
| Độ an toàn của API | Trình phát độc hại có thể làm giả "tên máy chủ" của một trang không? | API hỗ trợ khoá con được đặt thành tên máy chủ của nhà xuất bản. Vì trình duyệt đang đặt khoá nên có vẻ như khó tránh được cơ chế này. |
| Sử dụng API | Bạn không nên sử dụng các hàm ForDebuggingOnly cho việc sử dụng phát hành công khai. | Chúng tôi sắp khẳng định lại với hệ sinh thái rằng các hàm forDebuggingOnly hoàn toàn không phù hợp ngoài việc khắc phục sự cố sau 3PCD. |
| Cần thêm công cụ gỡ lỗi | ForDebugOnly không đủ để hiểu các vấn đề có thể xảy ra trước scoreAd(). | Chúng tôi đang thu thập thêm ý kiến phản hồi về khoảng thời gian này và rất mong bạn có thể cung cấp thêm thông tin tại đây. |
| Vĩnh viễn chọn không tham gia các nhóm có cùng mối quan tâm | Yêu cầu cho phép người dùng chọn vĩnh viễn không tạo các IG đặc biệt. | Chiến lược của chúng tôi là không cho phép người dùng chọn không tham gia ở cấp độ IG vì người dùng không hiểu được ngữ nghĩa của những tính năng này. |
| Cải thiện tài liệu | Sử dụng cách viết hoa giống nhau cho thông số RenderScriptUrls trong phần thông số kỹ thuật và phần giải thích. | Chúng tôi rất trân trọng ý kiến phản hồi của bạn và sẽ liên hệ lại để cập nhật tài liệu. |
| Hỗ trợ giao dịch bằng Protected Audience | Yêu cầu các lựa chọn bổ sung cho dịch vụ Hỗ trợ giao dịch bằng Protected Audience. | Nhóm Chrome hiện đang đánh giá những việc chúng tôi có thể làm để hỗ trợ vấn đề này bằng 3PCD. |
| Macro | Cần hỗ trợ vĩ mô để giữ kích thước của các IG dưới kích thước tối đa của IG. | Thông tin cập nhật gần đây của thông tin giải thích đã giải quyết một phần yêu cầu này. |
| API Reportloss ở cấp sự kiện | Yêu cầu API ReportThus ở cấp sự kiện. | Mặc dù báo cáo về sự cố mất dữ liệu ở cấp sự kiện có thể gây ra rủi ro nghiêm trọng về quyền riêng tư, nhưng chúng tôi tin rằng các mục tiêu cơ bản của yêu cầu này có thể được đáp ứng bằng cách sửa đổi cho phù hợp API tổng hợp riêng tư. Chúng tôi mong nhận được thêm ý kiến phản hồi tại đây. |
| Sử dụng API | Các phương thức forDebuggingOnly hoạt động như thế nào nếu không có điểm giá thầu > 0? | Nếu điểm số <= 0 thì thua tự động. Do đó, reportAdauctionloss sẽ được gọi. |
| Tiêu chuẩn hoá | Không có sự phù hợp giữa những người dùng của giá trị đầu vào/đầu ra của hàm PA API generateBid(). | Tất cả đối tác nên gửi vấn đề này (hoặc tương tự) lên IAB Tech Lab. Nhóm này đang nghiên cứu riêng các tiêu chuẩn ngành cho những API như Protected Audience. |
| Độ an toàn của API | Google có thể xem dữ liệu nào từ các IG của chúng tôi? | K-anonymity sử dụng các biện pháp bảo vệ quyền riêng tư mạnh mẽ để tránh làm rò rỉ dữ liệu nhạy cảm của người dùng cho bất kỳ bên nào, bao gồm cả Google. Google cũng đang triển khai bên thứ ba (Nhanh chóng) của lớp này để giảm thiểu rủi ro này. |
| Thử nghiệm Chrome (chế độ a/b) | Người dùng bị hạn chế "k-anon" có thể bị loại trừ khỏi thử nghiệm không? | Chúng tôi công bố trạng thái k-anonymity trong báo cáo như giải thích tại đây. |
| Sự an toàn cho thương hiệu | Hỗ trợ các trường hợp sử dụng Sự an toàn thương hiệu mà quảng cáo không được phân phát dựa trên danh sách các trang web hoặc từ khoá bị chặn. | Các trường hợp sử dụng an toàn thương hiệu như vậy đã có thể được thực hiện thông qua API PA. Để một chiến dịch quảng cáo nhắm mục tiêu phủ định đến một số nhóm miền, thì họ có thể lưu trữ danh sách chặn miền trong chính IG, có thể là sử dụng bộ lọc Bloom nếu việc liệt kê từng miền chiếm quá nhiều không gian. Hoặc họ có thể trả về quyết định cho phép hoặc từ chối từ máy chủ Giá trị khoá bằng cách sử dụng UDF để tra cứu câu trả lời dựa trên tổ hợp khoá xác định chiến dịch quảng cáo và tên miền có trong yêu cầu Giá trị khóa. Protected Audience API cũng cho phép cả SSP và DSP truyền vào phiên đấu giá mọi thông tin về ngữ cảnh trang. Chẳng hạn như một danh sách các chủ đề hoặc từ khoá nhạy cảm trên trang. Logic đặt giá thầu của DSP có thể so sánh thông tin này với bất kỳ thông tin nào đã lưu trữ về vị trí quảng cáo không được xuất hiện và chọn không đặt giá thầu khi thích hợp. Chúng tôi hoan nghênh ý kiến phản hồi của hệ sinh thái đối với bất kỳ trường hợp sử dụng cụ thể nào mà họ cho là không khả thi. |
| Uỷ quyền quyền | Tính năng uỷ quyền quyền hoạt động như thế nào? | Chúng tôi đã chia sẻ tài liệu về việc uỷ quyền cấp quyền tại đây. |
| Yêu cầu theo lô | Sử dụng yêu cầu POST cho một số URL API PA để hỗ trợ Yêu cầu hàng loạt. | Chúng tôi hoan nghênh đề xuất này và hoan nghênh các ý kiến phản hồi khác tại đây. |
| Cải thiện API | Các trường có lẽ không nên được sử dụng (chẳng hạn như X-fledge-bidding-signals-format-version). | Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Cải thiện API | Yêu cầu chuyển sự đồng ý theo Quy định chung về việc bảo vệ dữ liệu (GDPR) cho Nhà cung cấp dịch vụ đo lường và phân phát quảng cáo bên thứ ba. | Chức năng này được hỗ trợ bằng cách sử dụng API thay thế macroReplaceInURN không dùng nữa, như đã giải thích tại đây. |
| Tối ưu hoá mẫu quảng cáo động | Protected Audience hỗ trợ tối ưu hoá mẫu quảng cáo động bằng cách nào? | Chúng tôi đang thảo luận về trường hợp sử dụng này và chia sẻ các giải pháp tiềm năng tại đây. |
| Cải thiện API | Yêu cầu URL phân phát quảng cáo của bên thứ ba có thể lấy ngữ cảnh IG (chủ yếu là tên IG) tương ứng với IG đã thắng phiên đấu giá. | Những yêu cầu như vậy có thể làm tăng rủi ro theo dõi cho người dùng. Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn có thêm ý kiến phản hồi tại đây. |
| Độ an toàn của API | Lo ngại rằng kích thước của "IG blob" sẽ làm rò rỉ thông tin về các IG đã được chọn. | Như đã đề cập trong phần những điều cần cân nhắc về quyền riêng tư trong phần giải thích về Chrome B&A API, kích thước blob không phụ thuộc vào bất kỳ dữ liệu đầu vào nào vào navigation.getinterestGroupAdauctionData(). Nó chỉ đóng gói tất cả IG trên thiết bị. Điều này đảm bảo rằng kích thước của blob tương đối nhất quán trên một trang và hạn chế khả năng rò rỉ thông tin trên nhiều trang web. Đây chính là lý do chúng tôi thiết kế bảng điều khiển này theo cách này. |
| Thử nghiệm Chrome (chế độ a/b) | Quan điểm của các SSP khác như thế nào về việc thiếu lượt tải đầu tiên liên quan đến việc cài đặt cookie và Hoạt động kiểm thử hỗ trợ Chrome? | Chúng tôi chưa nhận được phản hồi đáng kể nào (mặc dù những người khác đã thừa nhận trường hợp này), nhưng chúng tôi hoan nghênh ý kiến phản hồi về hệ sinh thái nếu đây là vấn đề nghiêm trọng. |
| Hỗ trợ Thử nghiệm A/B | Yêu cầu hỗ trợ thử nghiệm A/B API PA. | Chúng tôi đã thảo luận về yêu cầu này trong cuộc họp của WICG vào tháng 11 và hoan nghênh các ý kiến phản hồi khác tại đây. |
| Kích thước quảng cáo | Ai chọn kích thước cho phiên đấu giá trong Protected Audience? | Câu hỏi này đã được trả lời trong phần Câu hỏi thường gặp này. |
| Cải thiện API | Yêu cầu định cấu hình dịch vụ khoá-giá trị để chấp nhận đường dẫn /bidding-signals/v1/getvalues. | Chúng tôi đã thêm các tiền tố đường dẫn hỗ trợ vào yêu cầu lấy dữ liệu này. |
| Sử dụng API | Làm cách nào nhà xuất bản có thể tạo IG bằng mã của họ nếu họ đáng ra phải ở trong cơ sở của nhà quảng cáo để nhà quảng cáo có thể đặt giá thầu trên đó? | Câu trả lời phải đến từ một số đối tác công nghệ quảng cáo (một DSP hoặc SSP muốn tham gia các phiên đấu giá trong Protected Audience) và xây dựng cách thức để những đối tượng đó đến từ một nguồn bên ngoài. Chúng ta đã thảo luận thêm về vấn đề này trong vấn đề này trên GitHub. |
| Cải thiện API | Yêu cầu về khả năng liên kết IG phủ định với quảng cáo trong "Nhóm mối quan tâm khẳng định". | Chúng tôi đang xem xét yêu cầu này và đã chia sẻ một đề xuất tiềm năng về cách hỗ trợ đề xuất tại đây. |
| Số lượng phân đoạn | Yêu cầu hỗ trợ về việc truyền "shard_num support" trong siêu dữ liệu. | Theo ý kiến phản hồi này, chúng tôi đã thêm tính năng hỗ trợ cho shard_num. |
| Sử dụng API | Yêu cầu ước tính mức hao tổn của các khoá trong máy chủ K/V. | Chúng tôi đã chia sẻ ý kiến và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây. |
| Ẩn danh K | Yêu cầu làm rõ và cải thiện độ chi tiết của bộ đếm K-Anonymity. | Chúng tôi đã làm rõ thông tin chi tiết về bộ đếm K-Anonymity tại đây. |
| Gỡ lỗi | Yêu cầu cải thiện khả năng gỡ lỗi của API PA theo các thay đổi được đề xuất gần đây đối với forDebuggingOnly. | Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi tại đây. |
| Kích thước quảng cáo | Yêu cầu kích thước Vùng quảng cáo làm tín hiệu bổ sung về BTS. | Chúng tôi đã chia sẻ đề xuất hỗ trợ yêu cầu này và hoan nghênh bạn phản hồi thêm tại đây. |
| Độ an toàn của API | Có thể hạn chế việc sử dụng "runAdBid()" dựa trên nguồn gốc không? | Chúng tôi đã chia sẻ câu trả lời chi tiết tại đây. |
| Thời gian tồn tại của IG | Yêu cầu kéo dài thời gian tồn tại của các IG từ 30 lên 90 ngày. | Chúng tôi đang xem xét yêu cầu của bạn và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Sử dụng API | Tôi có thể triển khai phiên đấu giá Protected Audience song song với tính năng Đặt giá thầu dựa vào tiêu đề và lệnh gọi máy chủ quảng cáo của nhà xuất bản không? | Chúng tôi đang thảo luận về yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Gỡ lỗi | Yêu cầu hỗ trợ tốt hơn cho các tiện ích gỡ lỗi API Chrome PA đang nói chuyện với Công cụ cho nhà phát triển. | Chúng tôi ủng hộ việc cung cấp thêm các công cụ gỡ lỗi và hoan nghênh bạn đề xuất thêm tại đây. |
| Sử dụng API | Thông báo tổn thất không được kích hoạt nếu không có giá thầu nào từ những người bán thành phần xuất hiện để trở thành người bán chạy nhất. | Chúng tôi đã giải thích lý do của việc này tại đây. |
| Cải thiện API | Yêu cầu hỗ trợ TextEncoder trong worklet đặt giá thầu của Protected Audience. | Chúng tôi đang xem xét yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Sử dụng API | Các lệnh gọi mạng và logic chạy trong ứng dụng có thể chặn luồng chính và gây ra những thách thức khi thực thi JS có thể ảnh hưởng đến SEO. | Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn có thêm ý kiến phản hồi tại đây. |
| Sử dụng API | Các DSP có thể sử dụng phễu đặt giá thầu phía máy chủ hiện tại để đánh giá và gửi các đề xuất quảng cáo như một phần của perbuyerSignal để sử dụng cho phiên đấu giá trên thiết bị không? | Chúng tôi đang thảo luận câu hỏi này và hoan nghênh bạn có thêm ý kiến phản hồi tại đây. |
| Mở rộng dữ liệu cơ hội giá thầu | Yêu cầu mở rộng dữ liệu cơ hội giá thầu mà trình duyệt chuyển sang SSP kèm theo danh sách miền gốc riêng biệt của các IG đang hoạt động trong trình duyệt. | Chúng tôi đang thảo luận về yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| ORTB | Yêu cầu hai hook mới cho phiên đấu giá và điều chỉnh phản hồi generateBid trong ORTB. | Chúng tôi đang xem xét vấn đề này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây. |
| Chiến thắng trước | Yêu cầu IG xác định một previousWinsTransformer, lấy các thành tích trước đó của IG và tạo ra một nội dung chuyển đổi tuần tự. | Chúng tôi đang xem xét vấn đề này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây. |
| Các loại nội dung | Chiến lược phát triển các loại nội dung, chẳng hạn như JSON thành CBOR. | Chúng tôi đang xem xét vấn đề này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây. |
| Tính năng Đặt giá thầu trước trong Protected Audience API | Yêu cầu về một trang nhà xuất bản mẫu sử dụng tính năng đặt giá thầu trước để chạy một quy trình toàn diện cho phiên đấu giá trong Protected Audience. | Chúng tôi đang xem xét yêu cầu này và rất mong nhận được thêm ý kiến phản hồi của hệ sinh thái về lý do chúng tôi nên ưu tiên yêu cầu này. Chúng tôi cũng đã thấy những người tham gia hệ sinh thái tạo các trang mẫu của nhà xuất bản mà những người khác trong hệ sinh thái có thể sử dụng để minh hoạ. |
Dịch vụ đấu giá được bảo vệ
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Môi trường thực thi đáng tin cậy (TEE) | Trái với việc chạy các trung tâm dữ liệu công nghệ quảng cáo tại chỗ, việc chạy Môi trường thực thi đáng tin cậy trên đám mây công cộng có tốn kém hơn 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. Cụ thể, các TEE dựa trên phần cứng hiện tại không chống lại đượ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 được hỗ trợ hiện tại của chúng tôi là AWS và GCP, đã thiết kế và triển khai các giải pháp giảm thiểu rủi ro khi truy cập vật lý, bao gồm cả rủi ro của nhân viên. Xem thêm thông tin chi tiết bên dưới về dịch vụ hỗ trợ tại chỗ. Các công nghệ quảng cáo cho chúng tôi biết rằng việc chạy dịch vụ đám mây sẽ 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 tại cơ sở. Mặc dù không có quyền đánh giá những nội dung đó, nhưng chúng tôi hoan nghênh ý kiến phản hồi bổ sung về chi phí và tiếp tục xem xét các phương án mở rộng dịch vụ hỗ trợ TEE. |
| (Được báo cáo trong các quý trước) TEE tại chỗ |
Một người cần đáp ứng những yêu cầu gì để trở thành nhà cung cấp dịch vụ TEE? | Phản hồi của chúng tôi cũng tương tự như các quý trước: "Mặc dù chúng tôi vẫn đang tiếp tục tìm hiểu việc hỗ trợ các lựa chọn khác ngoài các giải pháp dựa trên đám mây công cộng, bao gồm cả việc cân nhắc những phương án triển khai nào có thể chấp nhận được từ góc độ bảo mật, nhưng hiện tại chúng tôi chưa có kế hoạch hỗ trợ các TEE riêng. Ở giai đoạn này, trước các yêu cầu về bảo mật của Hộp cát về quyền riêng tư cũng như những thách thức lớn khi triển khai tại chỗ, chúng tôi tin rằng việc tiếp tục mở rộng và cải thiện các hoạt động triển khai trên đám mây sẽ có lợi nhất cho hệ sinh thái. Tuy nhiên, chúng tôi hoan nghênh ý kiến phản hồi bổ sung về lý do yêu cầu này là cần thiết và khả thi, do có những hạn chế về quyền riêng tư và bảo mật." |
| Giới hạn của máy chủ khoá/giá trị | Giới hạn số khoá trong mỗi phiên đấu giá trên mỗi máy chủ | Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn có thêm ý kiến phản hồi tại đây. |
| Các hạn chế về K-anon | Xác nhận rằng chế độ ẩn danh K sẽ không được thực thi trên các khoá K/V trong tương lai. | Hiện tại, chúng tôi không có kế hoạch thực thi k-anon trên các khoá của yêu cầu máy chủ K/V vì chúng tôi đang hướng tới việc di chuyển các máy chủ K/V sang TEE trong tương lai. |
| Dịch vụ K/V của toà nhà | Google có các cấu phần phần mềm được tạo sẵn cho dịch vụ K/V không? | Hiện tại, chúng tôi chưa có cấu phần phần mềm được tạo sẵn nào cho máy chủ Khoá/Giá trị Protected Audience. Tuy nhiên, chúng tôi có thể cân nhắc cung cấp cấu phần phần mềm này nếu nhận thấy hệ sinh thái có nhu cầu cao về việc sử dụng cấu phần phần mềm này. |
| Hỗ trợ EgId trong B&A | Yêu cầu hỗ trợ trường experimentGroupId trong mã Đặt giá thầu và Phiên đấu giá, đồng thời yêu cầu dịch vụ KeyValue từ BuyerFrontEnd | B&A hiện không hỗ trợ TestingGroupId. Tuy nhiên, B&A sẽ triển khai tính năng này bằng Phiên bản Beta 2 (hiện dự kiến ra mắt vào tháng 2 năm 2024). Chúng tôi đã chia sẻ thêm thông tin tại đây. |
| Sử dụng API | Yêu cầu liên kết trong HTTP có thể giúp chống lại những kẻ tấn công trên đường dẫn, nhưng người vận hành của TEE sẽ học được kích thước. | Chúng tôi đang thảo luận về yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Cải thiện tài liệu | Thông số kỹ thuật không rõ ràng về cách thức địa chỉ 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 có thêm ý kiến phản hồi tại đây. |
| Sử dụng API | Mục đích của "Kết quả đấu giá quảng cáo" và Tiêu đề đấu giá quảng cáo là gì? | Chúng tôi đang thảo luận về vấn đề này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi. |
| Cải thiện tài liệu | Không rõ liệu thiết kế v2 đã được truyền vào FLEDGE.md hay chưa. | FLEDGE.md nói về cách Chrome gửi yêu cầu đến BYOS-KV. Thiết kế giao thức v2 chỉ giới hạn ở TEE-KV và hiện không được Chrome hỗ trợ. |
Đ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 |
|---|---|---|
| Đo lường nhiều môi trường | Chrome dự định hỗ trợ đo lường trên nhiều môi trường trong giai đoạn tạm thời khi 3PC bị loại bỏ khỏi Chrome Mobile nhưng Hộp cát về quyền riêng tư cho Android thì chưa có sẵn như thế nào? | Về phía Android, chúng tôi đang nỗ lực mở rộng phạm vi áp dụng của PSB/ARA – Attribution Reporting API (ARA) có trên Android 13 và 14. Chúng tôi dự định sẽ bắt đầu mở rộng sang Android 11 và 12 vào cuối năm nay, mặc dù điều này có thể thay đổi. Chúng tôi sẽ không thể mở rộng sang Android 10 trở xuống. Tuy nhiên, chúng tôi dự kiến tỷ lệ phần trăm thiết bị Android vẫn chạy Android 10 trở xuống sẽ thấp hơn ở mức 3PCD và tự nhiên giảm theo thời gian khi người dùng nâng cấp. Chúng tôi hoan nghênh thêm ý kiến phản hồi của hệ sinh thái về yêu cầu này. |
| Lọc | Lọc "lượt chuyển đổi" từ quá trình quét mẫu quảng cáo. | Chúng tôi đã liên hệ với bên liên quan này để hiểu rõ hơn về yêu cầu của họ, đồng thời hoan nghênh ý kiến phản hồi khác của hệ sinh thái về vấn đề này. |
| Máy chủ quảng cáo của bên thứ ba | API PA và ARA sẽ hoạt động như thế nào với các thẻ Máy chủ quảng cáo của bên thứ ba? | Tương tự như cách pixel hoạt động với thẻ lượt hiển thị và thẻ nhấp hiện nay, máy chủ quảng cáo có thể tự đặt lượt đăng ký nguồn và lượt đăng ký lệnh kích hoạt cho ARA (bao gồm cả từ các phiên đấu giá trong Protected Audience) hoặc có thể thiết lập lệnh chuyển hướng để truyền và chấp nhận các lượt đăng ký nguồn và lượt đăng ký điều kiện kích hoạt cho ARA. |
| DCM | Sự hỗ trợ của Attributionsrc bởi DCM và các máy chủ quảng cáo khác của bên thứ ba. | Đây là vấn đề liên quan đến DCM và đã được nhóm DCM giải quyết trong vấn đề GitHub này. |
| Khoá tổng hợp phân cấp | Có cần phải chia toàn bộ ngân sách đóng góp thành tất cả các khoá phân cấp này không? | Chúng tôi đã thảo luận và đưa ra câu trả lời cho bên liên quan này. Khi sử dụng cấu trúc khoá phân cấp, công nghệ quảng cáo phải xem xét rằng ngân sách đóng góp được dùng chung cho tất cả đầu ra khoá của một lượt hiển thị. |
| Sử dụng các miền phụ khác nhau | Đặt báo cáo phân bổ sao cho hoạt động với các nguồn và điều kiện kích hoạt được đăng ký trên các miền phụ khác nhau, nhưng cùng một eTLD+1? | Chúng tôi đã thảo luận câu hỏi này với các bên liên quan và đề xuất các giải pháp sau đây. Họ có thể thay đổi chế độ thiết lập URL để có cùng nguồn gốc báo cáo trên nguồn và điều kiện kích hoạt, hoặc chuyển hướng từ URL hiện tại sang một URL chung trước khi thực hiện quá trình đăng ký. Chúng tôi sẵn sàng đón nhận thêm ý kiến phản hồi về hệ sinh thái nếu các giải pháp được đề xuất không phù hợp với trường hợp sử dụng của chúng. |
| (Cũng được báo cáo trong các quý trước) Hỗ trợ sản xuất |
Các cấp dịch vụ nào có sẵn để hỗ trợ đối tác sử dụng ARA? | Câu trả lời của chúng tôi không thay đổi so với các quý trước: "Google cung cấp nhiều kênh để cho phép công nghệ quảng cáo báo cáo vấn đề kỹ thuật và tạo điều kiện chuyển lên cấp trên để giải quyết những vấn đề như vậy. Ngoài ra, Chrome kỳ vọng sẽ xây dựng và mở rộng quy mô của một quy trình nhằm giải quyết các vấn đề kỹ thuật và báo cáo lên cấp cao hơn ảnh hưởng đến sức khoẻ của hệ sinh thái. Chrome cam kết đảm bảo các tài nguyên cho nỗ lực này. Vui lòng xem bài đăng của chúng tôi dành cho nhà phát triển để biết thêm thông tin về việc phản hồi và chuyển lên các diễn đàn công khai và riêng tư." |
| (Cũng được báo cáo trong các quý trước) Tiến trình |
Google có chuẩn bị sẵn sàng "Cấp sự kiện linh hoạt đầy đủ giai đoạn 2" trước khi bắt đầu thử nghiệm định lượng CMA không? | Cấp sự kiện linh hoạt đầy đủ Giai đoạn 2 dự kiến sẽ có trên Chrome vào quý 1 năm 2024. Bạn có thể theo dõi trạng thái tại đây. |
| (Cũng được báo cáo trong các quý trước) Phễu chuyển đổi |
Báo cáo nhiều miền được sử dụng trong lượt chuyển đổi. | Trường hợp sử dụng này có thể áp dụng vì bạn có thể thêm nhiều đích đến. Chúng tôi rất mong nhận được ý kiến phản hồi bổ sung của bạn. |
| Báo cáo nhãn thử nghiệm | Các tính năng báo cáo có cho phép người thử nghiệm báo cáo người dùng (trình duyệt Chrome) thuộc nhóm nào (Chế độ A/B) không? | Chúng tôi đang nỗ lực phát hành hướng dẫn kiểm thử để thu thập nhãn kiểm thử của Chrome trong ARA. |
| Tài liệu | Tài liệu về Attribution-Reporting-Register-Source cho biết ngày hết hạn sẽ được làm tròn đến ngày gần nhất, vậy sẽ được làm tròn như thế nào? | Làm tròn đến ngày gần nhất có nghĩa là 1,5 ngày sẽ được làm tròn thành 2 ngày. |
| Sử dụng các miền phụ khác nhau | Yêu cầu nhận báo cáo Attribution Reporting API trong một miền con khác làm nguồn và lượt đăng ký điều kiện kích hoạt. | Điều này là không thể. Bạn có thể áp dụng lệnh chuyển hướng HTTP, nhưng không cần thiết lập gì để thực hiện việc này. Chúng tôi hoan nghênh thêm ý kiến phản hồi của hệ sinh thái về lý do yêu cầu này hữu ích. |
| Độ trễ báo cáo ở cấp sự kiện | Khoảng thời gian phân bổ và báo cáo là 7 ngày nhưng do độ trễ báo cáo ở cấp sự kiện, nên có thể mất hơn 8 ngày để xử lý tất cả báo cáo. | Chúng tôi ghi nhận ý kiến phản hồi và hoan nghênh dữ liệu đầu vào bổ sung từ hệ sinh thái về việc liệu sự chậm trễ này trong báo cáo cấp sự kiện có phải là vấn đề hay không, đặc biệt là khi chuyển từ khoảng thời gian báo cáo sự kiện cố định sang linh hoạt. |
| Điều kiện kích hoạt lượt chuyển đổi | Các điều kiện kích hoạt lượt chuyển đổi xảy ra trong khoảng thời gian từ khi kết thúc event_report_window đầu tiên (1h) đến thời gian hết hạn (1 ngày) sẽ không tạo báo cáo. | Chúng tôi đã ra mắt cấu hình cấp sự kiện linh hoạt, chuyển từ khoảng thời gian báo cáo sự kiện cố định sang khoảng thời gian báo cáo sự kiện linh hoạt. |
| Tạp âm | Các báo cáo cấp sự kiện có gây nhiễu chuyển đổi giả mạo như mô tả trong phần giải thích trên GitHub không? | Có, độ nhiễu được áp dụng cho các báo cáo cấp sự kiện và đại diện cho tất cả trạng thái đầu ra có thể có, bao gồm cả các dữ liệu kích hoạt khác nhau, không báo cáo bất kỳ thông tin nào khi một điều kiện kích hoạt thực sự xảy ra hoặc có thể báo cáo nhiều báo cáo giả mạo cho sự kiện đó. % độ nhiễu là nguồn mở và có thể được linh hoạt thông qua các cấu hình cấp sự kiện linh hoạt. |
| Lọc | Việc sử dụng tính năng lọc cùng với Attribution Reporting API vẫn sẽ sử dụng ngân sách đóng góp mặc dù không ghi lại khoá tổng hợp. | Cơ chế này hoạt động đúng như dự kiến vì tổng hợp_trigger_data chỉ hỗ trợ lọc trên chính các phần khoá điều kiện kích hoạt chứ không hỗ trợ lọc theo giá trị / khoá. Các bộ lọc cấp cao nhất có thể hỗ trợ lọc chính các khoá đó, nhưng việc này được dùng chung theo sự kiện + tổng hợp nên không áp dụng được ở đây. Chúng tôi hoan nghênh thêm ý kiến phản hồi của hệ sinh thái tại đây nếu cần lọc theo khoá. |
| Giới hạn bộ nhớ | Yêu cầu đưa ra hạn mức bộ nhớ cũng xem xét nguồn gốc báo cáo. | Việc tăng giới hạn này từ 1024 lên 4096 sẽ có hiệu lực từ M120 và 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. |
| Mô hình phân bổ trực tiếp | Làm cách nào để nhận chỉ số cho các trường hợp người dùng truy cập trực tiếp vào nhà quảng cáo mà không thông qua nhà xuất bản, vì quy trình báo cáo phân bổ chuẩn không bao gồm trường hợp này? | ARA chỉ được thiết kế để khôi phục thông tin trên nhiều trang web (tức là kết hợp thông tin giữa các trang web của nhà xuất bản/nhà quảng cáo). Nếu không yêu cầu thông tin trên nhiều trang web, thì ARA sẽ không giúp bạn. Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn có thêm ý kiến phản hồi tại đây. |
| Thời gian báo cáo | Nhận thời gian schedule_report_time từ máy chủ thời gian thay vì sử dụng giờ máy cục bộ. | Hiện tại, chúng tôi chưa có kế hoạch sử dụng máy chủ thời gian và chưa nhận được nhiều yêu cầu từ Công nghệ quảng cáo. Chúng tôi sẽ quan tâm đến việc nghe thêm phản hồi từ hệ sinh thái để biết liệu đây có phải là một tính năng hữu ích hay không. |
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 được báo cáo trong các quý trước) Giải pháp tại chỗ |
Tôi có thể triển khai Dịch vụ tổng hợp trong các trung tâm dữ liệu tại chỗ không? | Mặc dù chúng tôi đang tìm hiểu những phương án có thể hỗ trợ ngoài các giải pháp trên đám mây, nhưng hiện tại chúng tôi không thể hỗ trợ các TEE tại chỗ do những hạn chế về bảo mật tại cơ sở hạ tầng riêng và việc đánh giá Hộp cát về quyền riêng tư rất mất thời gian. Do các yêu cầu về bảo mật của Hộp cát về quyền riêng tư cũng như những thách thức quan trọng khi triển khai tại cơ sở riêng, chúng tôi tin rằng việc tiếp tục mở rộng và cải thiện hoạt động triển khai trên đám mây (ví dụ: hỗ trợ GCP ngoài AWS) sẽ có lợi nhất cho hệ sinh thái. Tuy nhiên, chúng tôi hoan nghênh ý kiến phản hồi bổ sung tại đây về lý do cần có một yêu cầu như vậy. |
| Lớp phủ | Nếu mạng lưới không hoạt động hoặc đột nhiên gặp lỗi, API Dịch vụ tổng hợp sẽ xử lý như thế nào? | Chúng tôi sẽ thử lại nếu mạng lưới bảo mật gặp sự cố khi khởi động và tự động cấp tài nguyên bổ sung để hiển thị các thực thể mới nếu có một thực thể không tốt. Công nghệ quảng cáo cũng có thể điều tra các lỗi bằng cách sử dụng nhật ký. Để gỡ lỗi mạng lưới bảo mật trên AWS, công nghệ quảng cáo có thể kiểm tra trạng thái của thực thể EC2 bằng cách đăng nhập vào Trình quản lý bảng điều khiển AWS của họ. Công nghệ quảng cáo cũng có thể đăng nhập vào thực thể máy chủ Nitro Enclave và kiểm tra trạng thái của mạng lưới bảo mật bằng công cụ nitro-cli. Nếu xảy ra lỗi/không thành công, họ có thể sử dụng giao diện dòng lệnh AWS để xem nhật ký và tìm hiểu thêm. Để gỡ lỗi mạng lưới bảo mật trên GCP, các công nghệ quảng cáo có thể kiểm tra trạng thái của thực thể thông qua Cloud Console. Họ cũng có thể kiểm tra lỗi bằng cách sử dụng list- errors-command. |
| Sử dụng các miền phụ khác nhau | Yêu cầu đăng ký nhiều miền (phụ) để sử dụng nhiều phiên bản của Dịch vụ tổng hợp, cả trong môi trường nhà phát triển và chính thức. | Chúng tôi đã ra mắt tính năng đăng ký trang web để các công nghệ quảng cáo có thể đăng ký nhiều miền con của cùng một trang web trên một tài khoản AWS hoặc dự án GCP. Họ cũng có thể đăng ký cùng một miền trên nhiều tài khoản AWS hoặc dự án GCP. Chúng tôi hoan nghênh ý kiến phản hồi từ hệ sinh thái. |
| Ngân sách quyền riêng tư | Làm cách nào để khắc phục hiệu quả hơn các vấn đề liên quan đến tình trạng cạn kiệt ngân sách quyền riêng tư? | Hiện tại, chúng tôi đang xem xét các giải pháp để cung cấp thêm thông tin chi tiết về phần ngân sách đã cạn, đồng thời cải thiện tài liệu để nêu ra những chiến lược mà các công nghệ quảng cáo có thể sử dụng để giảm thiểu lỗi này. Chúng tôi sẽ cập nhật trang Dịch vụ tổng hợp trên GitHub sau khi có đề xuất. |
| Giá trị Epsilon | Yêu cầu tăng giá trị epsilon. | Giá trị epsilon của Dịch vụ tổng hợp sẽ được duy trì trong phạm vi tối đa là 64 để hỗ trợ việc thử nghiệm và phản hồi về nhiều tham số trong quá trình 3PCD. Chúng tôi sẽ thông báo trước cho hệ sinh thái trước khi cập nhật các giá trị của phạm vi epsilon. |
| Tệp nhị phân | Phát hành một tập hợp tệp nhị phân hoàn chỉnh hơn cho các bản phát hành Dịch vụ tổng hợp. | Chúng tôi đang xem xét yêu cầu này và chúng tôi hoan nghênh ý kiến phản hồi bổ sung. |
| Sử dụng API | Chia sẻ dữ liệu với Điều phối viên theo Điều khoản dịch vụ của Điều phối viên. | Chúng tôi đang tìm cách làm rõ vấn đề này và chúng tôi hoan nghênh ý kiến phản hồi bổ sung. |
API tổng hợp riêng tư
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Gỡ lỗi | Bật các tuỳ chọn bổ sung để gỡ lỗi trong khi kiểm thử Chế độ B. | Như đã chia sẻ trong vấn đề GitHub này, chúng tôi sẽ tiếp tục cho phép chế độ gỡ lỗi ở Chế độ B. Điều kiện này sẽ thay đổi trong M121 Beta ở 50% lưu lượng truy cập Chế độ B bắt đầu từ ngày 31 tháng 1. Chúng tôi sẽ thông báo trước khi tăng dần lên Kênh chính thức. |
Giới hạn hoạt động theo dõi bí mật
Giảm thiểu tác nhân người dùng/Gợi ý ứng dụng tác nhân người dùng
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| ChromeOS | Hỗ trợ Gợi ý của ứng dụng tác nhân người dùng cho bản chất của Chrome OS. | Chúng tôi đã phản hồi yêu cầu này tại đây. |
Bảo vệ IP (trước đây là Gnatcatcher)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Vi phạm | Google có thể xem dữ liệu duyệt web của người dùng thông qua tính năng Bảo vệ IP. | Tính năng Bảo vệ IP phân luồng lưu lượng truy cập qua hai proxy (một máy chủ do Google vận hành và một máy chủ do một công ty khác vận hành). Điều đó đảm bảo rằng Google không thể xem dữ liệu duyệt web. Tất cả lưu lượng truy cập được mã hoá giữa Chrome và các proxy, vì vậy, proxy của Google không có thông tin về trang web đang được duyệt. Ngoài ra, hệ thống sử dụng mã thông báo xác thực ẩn để giảm thiểu quyền truy cập vào giá trị nhận dạng người dùng tại các proxy. Tất cả proxy của Google sẽ thấy là ứng dụng khách không xác định tại IP cụ thể đang sử dụng hệ thống proxy. Không có thông tin nào về các trang web được truy cập hoặc quảng cáo đã tải. |
| Hỗ trợ Chế độ không có giao diện người dùng | Các bot sử dụng trình bổ trợ và chế độ không có giao diện người dùng sẽ được quản lý như thế nào? | Giảm thiểu hành vi lạm dụng Bảo vệ IP là một ưu tiên chính của nhóm. Chúng tôi đã xem xét kỹ lưỡng các tình huống này (cùng với nhiều mối đe doạ tiềm ẩn khác) và đang nghiên cứu các phương án giúp giảm khả năng xảy ra hành vi sai trái hoặc lừa đảo. Mặc dù hiện tại chúng tôi không 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êm thông tin trong thời gian sắp tới và rất mong được tiếp tục thảo luận với bạn. |
| Proxy hiện có | Tính năng Bảo vệ IP sẽ hoạt động như thế nào với các chế độ cài đặt proxy hiện có trên Chrome? | Các cấu hình proxy hiện có sẽ vẫn được hỗ trợ. Người dùng sẽ có thể định cấu hình proxy tuỳ chỉnh của riêng họ như trước đây. |
| Báo cáo vi phạm | Việc báo cáo lạm dụng sẽ được xử lý như thế nào? | Chúng tôi sẽ chia sẻ thêm thông tin chi tiết trong thời gian sắp tới. Tuy nhiên, chúng tôi dự định có cơ chế để các tổ chức và người dùng chia sẻ báo cáo và bằng chứng về hành vi lạm dụng. |
| Quy định | Bảo vệ IP sẽ tuân thủ luật và quy định địa phương như thế nào? | Google cam kết tuân thủ các luật và quy định của địa phương và chúng tôi có thể không được phép né tránh các quy định chặn cấp quốc gia này. Tính năng này không nhằm mục đích lách. |
| Giới hạn khả năng | Bảo vệ IP có chặn phản hồi mạng của chúng tôi 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ọ với việc giảm thiểu sự gián đoạn đến hoạt động thông thường của máy chủ, bao gồm cả việc sử dụng địa chỉ IP để chống hành vi sử dụng sai mục đích. Mặc dù hiện tại chúng tôi không 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êm thông tin trong thời gian sắp tới và rất mong được tiếp tục thảo luận với bạn. |
| Lịch trình | Nếu quy định này được thực thi trước cuối năm 2024, thì gần như chúng tôi gần như không thể chuẩn bị cho việc này. | Ban đầu, Chrome sẽ ra mắt Bảo vệ IP dưới dạng một chế độ cài đặt chọn tham gia cho người dùng ở những khu vực cụ thể. Vì vậy, đây có thể là một thay đổi đáng kể đối với cách một số công ty sử dụng địa chỉ IP và tìm cách giảm thiểu sự gián đoạn khi hệ sinh thái điều chỉnh. Tính năng Bảo vệ IP sẽ chuyển sang chế độ mặc định vào năm 2025. |
| Sử dụng API | Người dùng có được lựa chọn bật/tắt tính năng Bảo vệ IP vào lần đầu tiên mở Chrome không? | Chúng tôi dự định để người dùng lựa chọn có sử dụng tính năng Bảo vệ IP hay không. Cơ chế hiển thị tuỳ chọn này cho người dùng vẫn đang được phát triển. |
| Sử dụng API | Lượng dữ liệu được ghi lại là bao nhiêu và dữ liệu đó được giữ lại trong bao lâu? | Chúng tôi sẽ có thêm thông tin chi tiết để chia sẻ trong tương lai, nhưng chúng tôi dự định ghi lại một lượng dữ liệu tối thiểu. |
| Phản hồi tiêu cực | Người dùng có thể dùng VPN nếu muốn. Không cần API PS. | Mục tiêu của Bảo vệ IP là ngăn chặn việc sử dụng địa chỉ IP vào mục đích theo dõi trên nhiều trang web, không phải là dịch vụ VPN. |
| Độ an toàn của API | Cách ngăn bên thứ nhất truy cập vào địa chỉ IP và chuyển tiếp thông tin qua tham số của tiêu đề? | Ban đầu, chúng tôi tập trung vào các bên thứ ba vì chúng tôi thấy rằng điều này có tác động lớn nhất. Chúng tôi sẽ tiếp tục theo dõi hệ sinh thái này để xác định xem có cần phát triển phương pháp nhằm ngăn chặn hành vi lách luật trên quy mô lớn hay không. |
| Sử dụng API | Bạn cần xác nhận nếu hiểu đúng về việc sử dụng API. | Tính năng Bảo vệ IP sử dụng 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 đi qua các proxy. Các nguồn gốc có trong danh sách nhưng được truy cập trong bối cảnh bên thứ nhất sẽ không được xử lý qua dịch vụ này cho các kết nối đó. Ví dụ: nếu một công ty phân tích có trong danh sách miền và một người dùng truy cập trực tiếp vào trang web, thì trang web đó vẫn có thể ghi nhận địa chỉ IP của người dùng thay vì địa chỉ IP được proxy. Tuy nhiên, nếu miền đó trên danh sách yêu cầu mạng trong bối cảnh của bên thứ ba, thì kết nối sẽ được xử lý qua máy chủ proxy và địa chỉ IP ban đầu của người dùng sẽ không xuất hiện trên trang web. Mục tiêu cuối cùng của chúng tôi là ngăn hoạt động theo dõi người dùng trên web qua nhiều trang web. Chúng tôi đang làm việc với một số thông tin chi tiết trước khi chia sẻ thêm thông tin về các miền của bên thứ ba mà chúng tôi dự định tập trung vào lúc ban đầu. |
| VPN | Lo ngại rằng đề xuất của Google có thể gây bất lợi cho các nhà cung cấp VPN khác. | Mục tiêu của Bảo vệ IP là ngăn chặn việc sử dụng địa chỉ IP vào mục đích theo dõi trên nhiều trang web, không phải là dịch vụ VPN. |
| Lịch trình | Tiến trình Bảo vệ IP là như thế nào? | Ban đầu, chúng tôi sẽ chọn sử dụng tính năng Bảo vệ IP. Điều này sẽ giúp đảm bảo người dùng có quyền kiểm soát các quyết định về quyền riêng tư và Google có thể giám sát các hành vi ở phạm vi nhỏ hơn. Hoạt động Bảo vệ IP sẽ được triển khai theo từng giai đoạn và sẽ chuyển sang chế độ mặc định muộn nhất vào năm 2025. Giống như mọi đề xuất về quyền riêng tư, chúng tôi muốn đảm bảo rằng chúng tôi luôn học hỏi được trong quá trình thực hiện và nhận thấy rằng cũng có thể sẽ có những điểm cần cân nhắc theo khu vực. Chúng tôi đang sử dụng phương pháp dựa trên danh sách và chỉ các miền trên danh sách trong bối cảnh của bên thứ ba mới bị ảnh hưởng. Chúng tôi ý thức rằng các đề xuất này có thể gây ra sự gián đoạn không mong muốn cho các trường hợp sử dụng hợp pháp, vì vậy, chúng tôi chỉ tập trung vào các tập lệnh và miền được coi là đang theo dõi người dùng. |
| Giới hạn khả năng | Không thể tra cứu địa chỉ IP của người dùng trong WHOIS nữa. | Quan điểm của chúng tôi là địa chỉ IP là một giá trị nhận dạng ổn định có thể ảnh hưởng đến quyền riêng tư của người dùng, bao gồm cả việc sử dụng siêu dữ liệu liên kết với địa chỉ đó, chẳng hạn như ASN. Với Bảo vệ IP, chúng tôi đang cố gắng tạo ra sự cân bằng hợp lý giữa quyền riêng tư và việc hỗ trợ trải nghiệm hữu ích cho người dùng trên web, chẳng hạn như với phương pháp tiếp cận vị trí địa lý IP của chúng tôi. Nếu siêu dữ liệu này không đủ cho trường hợp sử dụng của bạn, chúng tôi sẵn lòng thảo luận thêm về vấn đề đó. |
| Trình tham chiếu HTTP | Trình tham chiếu HTTP ban đầu có được giữ nguyên không? | Chúng tôi không có kế hoạch thay đổi tiêu đề Giới thiệu trong phạm vi của biện pháp Bảo vệ IP, như đã thảo luận tại đây. |
| Nguồn mở | Mã nguồn Bảo vệ IP có phải là nguồn mở không? | Phần lớn phần mềm ở đây là nguồn mở như một phần của các dự án Chromium và Envoy Proxy, nhưng một số thành phần là nguồn đóng, như được giải thích 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 |
|---|---|---|
| Xoá bộ nhớ | Tính năng giảm thiểu hoạt động theo dõi số trang không truy cập (BTM) có xoá bộ nhớ dùng chung và bộ nhớ Báo cáo phân bổ không? | Chúng tôi không có ý định xoá BTM xoá bộ nhớ của API Hộp cát về quyền riêng tư (ARA, PA API, Bộ nhớ dùng chung, Tổng hợp riêng tư, Chủ đề). BTM chỉ nên xoá các loại bộ nhớ có rủi ro về quyền riêng tư nếu được truy cập trong bối cảnh của bên thứ ba. Chúng tôi đang khắc phục lỗi. |
| Sử dụng API | BTM sẽ kích hoạt phiên bản Chrome nào? Tính năng theo dõi chuyển hướng/số trang không truy cập sau 10 giây có được coi là tính năng Theo dõi số trang không truy cập của BTM hay không? | Trong M116, BTM đã triển khai cho 100% người dùng bị chặn 3PC. Hiện tại, một lệnh chuyển hướng sau 10 giây không được coi là số trang không truy cập. |
| Trường hợp sử dụng đăng nhập | Tự động đồng bộ hoá/duy trì trạng thái đăng nhập trên nhiều miền mà không bị phạt vì hành vi theo dõi giống như vậy? | Chúng tôi đang thảo luận về yêu cầu này tại đây và hoan nghênh những ý kiến phản hồi khác từ hệ sinh thái. |
| Hành trình của người dùng | Hiện tại, BTM dẫn đến hành trình của người dùng phức tạp. | Chúng tôi đang thảo luận về vấn đề này và đã chia sẻ ý kiến của mình về vấn đề này tại đây. |
| API Truy cập bộ nhớ | BTM trong Chromium sẽ tôn trọng các khoản tài trợ của 3 máy tính từ API quyền truy cập vào bộ nhớ (SAA). | Chúng tôi đã thảo luận về vấn đề này với những người tham gia hệ sinh thái tại TPAC 2023 và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Tác động đến báo cáo quảng cáo | Việc giảm hoạt động theo dõi số trang không truy cập có thể giúp các công ty nhỏ trong hệ sinh thái này dựa vào các API Hộp cát về quyền riêng tư khác như ARA để triển khai các trường hợp sử dụng quảng cáo. | Các biện pháp giảm hoạt động theo dõi số trang không truy cập dùng để ngăn chặn hành vi lách 3PCD. ARA là một trong nhiều giải pháp đo lường thay thế mà các công ty sẽ cung cấp sau khi triển khai 3PCD, nhưng không công ty nào bắt buộc phải sử dụng. |
Ngân sách quyền riêng tư
Chưa có ý kiến phản hồi nào trong quý này.
Củng cố ranh giới quyền riêng tư giữa nhiều trang web
Nhóm 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 tính năng Nhóm trang web có liên quan (RWS) |
Yêu cầu mở rộng số lượng miền liên kết. | Hiện tại, chúng tôi dự kiến sẽ không tăng giới hạn về số lượng. Giới hạn này được đặt ra dựa trên những điểm cần 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à cân nhắc các cách triển khai tương tự 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 vào cookie trên nhiều trang web vượt quá giới hạn số, và cân nhắc tận dụng hướng dẫn của chúng tôi dành cho các trường hợp sử dụng danh tính, các trường hợp nhúng được xác thực và các trường hợp sử dụng cho quảng cáo. |
| Phạm vi truy cập cookie | Lo ngại rằng tất cả các miền trong RWS sẽ cấp quyền đọc và ghi tất cả cookie từ tất cả các miền. | Thành viên trong RWS không có nghĩa là các thành viên có thể truy cập vào cookie của nhau. Thay vào đó, việc này sẽ cho phép các thành viên truy cập vào cookie của riêng họ khi được nhúng trên các trang web cùng RWS khác (sau khi gọi Storage Access API). |
| (Cũng được báo cáo trong các quý trước) Tích hợp RWS và CHIPS |
Yêu cầu tích hợp RWS + CHIPS để hỗ trợ các trường hợp sử dụng như thử nghiệm A/B | Chúng tôi tiếp tục thu thập các trường hợp sử dụng và yêu cầu cho tính năng này tại đây. Hiện tại, chúng tôi đang cân nhắc sự cần thiết của tính năng này đối với các rủi ro về khả năng tương tác trên nhiều trình duyệt. |
| Sử dụng API | Điều gì sẽ xảy ra nếu người dùng xoá các trang web khỏi phần cài đặt của Chrome theo cách thủ công? | Chúng tôi hiện không có cách thức để người dùng xoá trang web khỏi nhóm theo cách thủ công. Thay vào đó, người dùng có thể chọn tắt tính năng "trang web có liên quan" bằng nút bật/tắt bên dưới "Chặn cookie của bên thứ ba"; hoặc "Chặn tất cả cookie của bên thứ ba" trên bảng cài đặt mới về tính năng Chống theo dõi. |
| Giao tiếp trên nhiều miền | RWS có cho phép giao tiếp trên nhiều miền không? | Chúng tôi hiện đang chạy Bản dùng thử Origin để mở rộng quyền truy cập vào một số loại bộ nhớ không phân vùng (bao gồm localStorage và Broadcast Channel) thông qua Storage Access API để hỗ trợ hoạt động giao tiếp này. Tính năng này có trong tất cả các cấu hình được hỗ trợ của Storage Access API, trên cùng một RWS và cả trên các trang web không thuộc RWS. Bài đăng trên blog này có thêm thông tin. |
| requestStorageAccessFor | document.requestStorageAccessFor(origin) có thể trả về một lời hứa sẽ phân giải bằng cookie trên nhiều trang web của nguồn gốc không? | Điều này là không thể. Vì lệnh gọi xảy ra từ nguồn gốc cấp cao nhất (khác với nguồn gốc được truyền vào dưới dạng đối số), nên việc gọi này sẽ vi phạm Chính sách cùng nguồn gốc. |
API Khung bảo vệ
| 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) Quảng cáo gốc |
Hỗ trợ Khung bảo vệ cho Quảng cáo gốc. | Trước đây, chúng tôi đã thông báo rằng bạn sẽ cần sử dụng một số công nghệ Hộp cát về quyền riêng tư trong tương lai để tăng cường các biện pháp bảo vệ quyền riêng tư. Ví dụ: đối với Protected Audience, chúng tôi yêu cầu sử dụng Khung bảo vệ để hiển thị quảng cáo và ngừng sử dụng tính năng báo cáo cấp sự kiện sớm nhất là năm 2026. Chúng tôi đã cung cấp ngày "không sớm hơn" cho từng yêu cầu trong tương lai này, vì vậy, toàn ngành sẽ làm rõ quá trình phát triển dự kiến của các API này. Khoảng thời gian bổ sung này giúp chúng tôi tiếp tục hợp tác với toàn ngành để thiết kế và hỗ trợ cho nhiều trường hợp sử dụng quan trọng hơn. Ví dụ: chúng tôi sẽ phát triển Khung bảo vệ trước yêu cầu vào năm 2026 trở lên để tiếp tục hỗ trợ quảng cáo gốc và quảng cáo dạng video bằng Protected Audience API. Theo Cam kết của chúng tôi, CMA sẽ được tham khảo ý kiến về những thay đổi đó và chúng tôi sẽ tiếp tục trao đổi với hệ sinh thái trước khi triển khai các yêu cầu "không sớm hơn". |
| Sự khác biệt về kích thước giữa các nền tảng | Báo cáo cho thấy kích thước của nội dung hiển thị trong Khung bảo vệ trông khác nhau giữa máy tính và điện thoại thông minh. | Chúng tôi đang xem xét vấn đề này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây. |
| Hiển thị adComponent | Cung cấp mã mẫu về cách hiển thị adComponents trong Khung bảo vệ? | Chúng tôi sẽ tìm cách cung cấp tài liệu về cách sử dụng navigator.adauctionComponents(numComponents) bên trong Khung bảo vệ để hiển thị một quảng cáo gồm nhiều thành phần. |
| Cải thiện API | Cung cấp thêm tín hiệu cho FencedFrames (ví dụ: an toàn thương hiệu). | Chúng tôi hoan nghênh đề xuất này và hoan nghênh các ý kiến phản hồi khác tại đây. |
API Bộ nhớ dùng chung
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Trường hợp sử dụng chống hành vi sai trái / Chống lừa đảo | Khả năng sử dụng Bộ nhớ dùng chung để phát hiện hành vi gian lận hoặc hoạt động bất thường. | Chúng tôi đã thảo luận về khả năng này tại đây và hoan nghênh bạn có thêm ý kiến phản hồi. |
| Giới hạn tần suất | Cung cấp cách giới hạn tần suất trên nhiều trang web bên ngoài API PA. | Chúng tôi đánh giá cao ý kiến phản hồi rằng tính năng giới hạn tần suất trên nhiều trang web bên ngoài API PA là một trường hợp sử dụng có giá trị. Tại thời điểm này, Hộp cát về quyền riêng tư vẫn tập trung vào bộ API hiện tại dành cho 3PCD. Tuy nhiên, chúng tôi hoan nghênh ý kiến phản hồi bổ sung của hệ sinh thái về trường hợp sử dụng này tại đây. |
chiP
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Cửa sổ bật lên/Chuyển hướng | CHIP sẽ hỗ trợ các trường hợp sử dụng phương thức xác thực được nhúng liên quan đến cửa sổ bật lên và đường liên kết chuyển hướng như thế nào? | Gần đây, chúng tôi đã chia sẻ một số hướng dẫn về tác động của việc loại bỏ 3 máy tính đối với quy trình đăng nhập của bạn. Chúng tôi hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Giới hạn phân vùng | Giảm giới hạn tổng thể cho mỗi trang web cho mỗi phân vùng xuống 1 KiB. | Chúng tôi đang xem xét yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. Chúng tôi sẽ tiếp tục theo dõi ý kiến phản hồi trong quá trình ra mắt 3PCD và các nhà phát triển sử dụng CHIP cũng như đưa ra ý kiến phản hồi. |
| Di chuyển cookie | Quy trình đề xuất cho việc di chuyển một ứng dụng web nhằm cấp cookie dưới dạng được phân vùng mà không làm hỏng cookie/phiên đang diễn ra? | Trong phản hồi của chúng tôi, chúng tôi đã đề xuất một lược đồ di chuyển tiềm năng ( tại đây), nhưng nhà phát triển đã tìm được một giải pháp thay thế phù hợp hơn cho cấu hình của họ. |
| Sử dụng API | Quyền truy cập vào bộ nhớ được phân vùng có bị vô hiệu hoá khi người dùng không chọn sử dụng chế độ cài đặt Ad Privacy API không? | Bộ nhớ được phân vùng và cookie được phân vùng (CHIP) được bật ngay cả khi người dùng không chọn sử dụng chế độ cài đặt API quyền riêng tư cho quảng cáo; vì chúng không cho phép chuyển thông tin trên nhiều trang web. Theo nguyên tắc chung, việc chuyển thông tin qua nhiều trang web sẽ phải tuân theo các giới hạn, khả năng kiểm tra hoặc sự chọn tham gia của người dùng; nhưng những điều này hiện không áp dụng cho CHIPS. |
| Sử dụng API | Lý do cuối cùng của việc chặn cookie không được phân vùng là gì, thay vì trình duyệt chỉ "âm thầm" phân vùng chúng là gì? | Bạn không thể làm việc này trong ngắn hạn và trung hạn, như giải thích tại đây. |
FedCM
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Sử dụng API | Không thể phân phát "tệp đã biết" trên eTLD+1 trong môi trường phát triển. | Chúng tôi đã cập nhật Chrome Canary để bỏ qua việc tìm nạp các trình duyệt phổ biến như đã thảo luận tại đây. |
| Sử dụng API | Có yêu cầu cụ thể nào về tương tác với người dùng được xác định để yêu cầu quyền đăng nhập qua bên thứ ba hoặc sử dụng FedCM không? | Không có yêu cầu cụ thể nào về tương tác của người dùng, như đã thảo luận tại đây. |
| Độ an toàn của API | Google có dự định triển khai quy trình nào cho phép khách hàng khởi động FedCM hay không, nhưng về cơ bản, mã thông báo sẽ được chuyển từ IdP sang hệ thống phụ trợ của RP không? | Chúng tôi đang thảo luận và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Chọn sử dụng | Cho phép IDP chọn nhận mã ứng dụng khách của bên bị hạn chế để người dùng có thể quyết định xem họ có tin tưởng IDP đó hay không. | Chúng tôi đang thảo luận về yêu cầu này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi tại đây. |
| Sử dụng API | Yêu cầu thêm tài liệu về FedCM. | Chúng tôi ghi nhận ý kiến phản hồi này và sẽ tiếp tục cải thiện tài liệu để tiếp tục phát triển API này. |
Chống nội dung rác và lừa đảo
API Mã thông báo trạng thái riêng tư (và các API khác)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Tài liệu | Yêu cầu hướng dẫn chi tiết cho nhà phát triển về Mã thông báo trạng thái riêng tư để hỗ trợ quá trình thử nghiệm. | Chúng tôi đã phát hành hướng dẫn cho nhà phát triển về Mã thông báo trạng thái riêng tư trong quý 4 năm 2023. |
| Xác minh độ tuổi/giới tính | Khó thực hiện quy trình xác minh "độ tuổi và giới tính" đối với các đối tượng sau khi dùng công cụ 3PCD. | Mã thông báo trạng thái riêng tư hiện không được thiết kế để xác minh độ tuổi và giới tính. Chúng tôi đang tìm cách hiểu rõ hơn về trường hợp sử dụng này và cách thức hoạt động của chúng tôi hiện thực hiện được, đồng thời hoan nghênh bạn chia sẻ thêm ý kiến phản hồi. |