Báo cáo hằng quý cho quý 4 năm 2024, tóm tắt ý kiến phản hồi của hệ sinh thái về các đề xuất liên quan đến Hộp cát về quyền riêng tư và phản hồi của Chrome.
Trong khuôn khổ cam kết với CMA, Google đã đồng ý công bố báo cáo hằng quý về quy trình tương tác với các bên liên quan đối với các đề xuất về Hộp cát về quyền riêng tư (xem đoạn 12 và 17(c)(ii) của Cam kết). Các báo cáo tóm tắt phản hồi về Hộp cát về quyền riêng tư này được tạo bằng cách tổng hợp phản hồi mà Chrome nhận được từ nhiều nguồn như được liệt kê trong phần tổng quan về phản hồi, bao gồm nhưng không giới hạn ở: Vấn đề trên GitHub, biểu mẫu phản hồi được cung cấp trên privacysandbox.com, các cuộc họp với các bên liên quan trong ngành và diễn đàn về tiêu chuẩn web. Chrome hoan nghênh ý kiến phản hồi nhận được từ hệ sinh thái và đang tích cực tìm hiểu cách tích hợp những điều học được vào các quyết định thiết kế.
Các chủ đề phản hồi được xếp hạng theo mức độ phổ biến trên mỗi API. Việc này được thực hiện bằng cách tổng hợp số lượng ý kiến phản hồi mà nhóm Chrome nhận được về một chủ đề nhất định và sắp xếp theo thứ tự giảm dần về số lượng. 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 trong các cuộc họp công khai (W3C, PatCG, IETF), phản hồi trực tiếp, GitHub và các câu hỏi thường gặp xuất hiện thông qua các nhóm nội bộ và biểu mẫu công khai của Google.
Cụ thể hơn, chúng tôi đã xem xét biên bản cuộc họp của các tổ chức tiêu chuẩn web và đối với ý kiến phản hồi trực tiếp, chúng tôi đã xem xét bản ghi của Google về các cuộc họp 1:1 với các bên liên quan, email mà các kỹ sư cá nhân nhận được, danh sách gửi thư API và biểu mẫu phản hồi công khai. Sau đó, Google đã điều phối giữa các nhóm tham gia vào nhiều hoạt động tiếp cận này để xác định mức độ phổ biến tương đối của các chủ đề liên quan đến từng API.
Nội dung giải thích về phản hồi của Chrome đối với ý kiến phản hồi được phát triển từ các câu hỏi thường gặp đã xuất bản, phản hồi thực tế đối với các vấn đề do các bên liên quan nêu ra và xác định một quan điểm cụ thể cho mục đích của hoạt động 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ể liên quan đến các chủ đề, API PA và các API Báo cáo phân bổ cũng như công nghệ.
Thông tin phản hồi mà chúng tôi nhận được gần đây có thể chưa được Chrome xem xét và phản hồi.
Bảng thuật ngữ về từ viết tắt
- ARA
- Attribution Reporting API
- Cookie có trạng thái được phân vùng độc lập (CHIPS)
- Cookie có trạng thái được phân vùng độc lập
- DSP (Bộ xử lý tín hiệu kỹ thuật số)
- Nền tảng bên cầu
- FedCM
- Federated Credential Management (Quản lý thông tin xác thực liên kết)
- IAB (Cục Quảng cáo tương tác)
- Cục Quảng cáo tương tác
- IDP
- Nhà cung cấp danh tính
- IETF (Lực lượng chuyên trách kỹ thuật Internet)
- Lực lượng chuyên trách kỹ thuật Internet
- IP
- Địa chỉ giao thức Internet
- openRTB
- Đặt giá thầu theo thời gian thực
- QUÁ GIỜ
- Bản dùng thử Origin
- PA API
- Protected Audience API (trước đây là FLEDGE)
- PatCG
- Nhóm cộng đồng về công nghệ quảng cáo riêng tư
- RP
- Bên phụ thuộc
- RWS
- Bộ trang web có liên quan (trước đây là Nhóm bên thứ nhất)
- SSP
- Nền tảng bên cung
- UA
- Chuỗi tác nhân người dùng
- UA-CH
- Thông tin mô tả của ứng dụng tác nhân người dùng
- W3C
- World Wide Web Consortium
- WIPB
- Cố tình làm ngơ địa chỉ IP
Ý kiến phản hồi chung, không có API/Công nghệ cụ thể
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Cam kết | Mục G trong Bản cam kết là yếu tố bắt buộc để Hộp cát về quyền riêng tư hoạt động hiệu quả. Nếu không có sự đảm bảo rằng hoạt động kinh doanh quảng cáo của chính Google sẽ hoạt động độc quyền trên các công nghệ Hộp cát, thì nguy cơ giảm dần tiện ích sẽ tăng lên, cũng như khả năng Google thoái vốn khỏi công nghệ này. Việc bán hoặc giảm tiện ích như vậy sẽ là mối đe doạ nghiêm trọng đối với khả năng định địa chỉ ưu tiên quyền riêng tư trên web mở. | Các Cam kết này không đảm bảo rằng hoạt động kinh doanh quảng cáo của Google sẽ hoạt động chỉ dựa trên các công nghệ Hộp cát về quyền riêng tư. Google dự định sử dụng phương pháp danh mục đầu tư để xác định khả năng định địa chỉ, bao gồm cả các công nghệ Hộp cát về quyền riêng tư, giống như cách các bên thứ ba có thể và đang sử dụng. Chúng tôi hiểu rằng phương pháp danh mục đầu tư là phương pháp phổ biến trong hệ sinh thái quảng cáo. Chúng tôi vẫn cho rằng các nhà phát triển cần có các công cụ và công nghệ bảo đảm quyền riêng tư. Chúng tôi sẽ tiếp tục cung cấp và đầu tư vào các API Hộp cát về quyền riêng tư để ngày càng nâng cao quyền riêng tư và sự tiện dụng. |
| Quản lý | Mô hình quản trị được đề xuất không bao gồm các cơ chế cụ thể để đảm bảo trách nhiệm giải trình trong quy trình tham vấn chính thức hoặc quy trình khiếu nại. | Thông tin này không chính xác. Cả (i) hệ thống ra quyết định và các ấn phẩm liên quan cũng như (ii) quy trình khiếu nại đều cung cấp các cơ chế cụ thể để đảm bảo trách nhiệm giải trình. Ngoài ra, Người giám sát sẽ giám sát chi tiết hoạt động của các tổ chức này. |
| Quản lý | Ý kiến phản hồi cho biết mô hình không chứa các quy định về việc tạo và duy trì tiêu chuẩn trên nhiều nền tảng. | Không có mô hình quản trị nào có thể buộc các bên khác (trong trường hợp này là trình duyệt) áp dụng một tiêu chuẩn. Do đó, chúng tôi không đề xuất mô hình yêu cầu áp dụng các tiêu chuẩn trên nhiều nền tảng. Google sẽ tiếp tục tham gia các diễn đàn tiêu chuẩn, trong đó việc đưa ra đề xuất và chia sẻ kinh nghiệm triển khai đề xuất là một hoạt động phổ biến trong quá trình này. |
| Quản lý | Bạn nên kéo dài thời gian tư vấn ít nhất là 2 tháng. Mô hình quản trị được đề xuất không cung cấp cho hệ sinh thái đủ thời gian để phân tích tác động của các thay đổi được đề xuất. | Khoảng thời gian 3 tuần không phải là toàn bộ khoảng thời gian phản hồi cho một thay đổi nhất định vì các chu kỳ phản hồi hiện tại (dài hơn nhiều) sẽ tiếp tục. Thay vào đó, quy trình tham vấn sẽ cung cấp một khung thời gian phản hồi mới, chính thức trong quy trình hiện tại để đưa ra quyết định chiến lược. Do đó, các bên thứ ba sẽ tiếp tục có thể đóng góp ý kiến thông qua nhiều diễn đàn (bao gồm cả GitHub, W3C và các tổ chức tiêu chuẩn quảng cáo như IAB Tech Lab) trong quá trình phát triển tính năng. Việc sắp xếp các chu kỳ phản hồi theo cách này giúp hệ sinh thái có cơ hội phân tích và chia sẻ quan điểm của họ về một thay đổi được đề xuất mà không làm chậm trễ đáng kể quá trình phát triển. |
| Quản lý | Yêu cầu cung cấp thông tin chi tiết về các kế hoạch quản trị trong tương lai. | Bản tóm tắt về mô hình quản trị được đề xuất được nêu trong báo cáo Quý 2/Quý 3 năm 2024 của CMA (trang 3-5 tại đây). |
| Yêu cầu về trường hợp ngoại lệ | Yêu cầu một trường hợp ngoại lệ để truy cập vào cookie của bên thứ ba (3PC) cho những người dùng đã đồng ý. | Việc đồng ý cấp quyền truy cập và lưu trữ trên thiết bị cho các mục đích xử lý dữ liệu cụ thể không có nghĩa là người dùng muốn ghi đè chế độ cài đặt 3PC trong Chrome. Việc cho phép ghi đè chế độ cài đặt 3PC của người dùng ở cấp trang web sẽ tạo ra nhiều khả năng bị sử dụng sai mục đích. Ngoài ra, Chrome không thể kiểm tra tất cả hành vi của các trang web có thể dẫn đến yêu cầu ngoại lệ. |
| Hộp cát về quyền riêng tư | Yêu cầu mức giá cho việc chọn sử dụng API Hộp cát về quyền riêng tư. | Chúng tôi không có kế hoạch chia sẻ thông tin này với hệ sinh thái. Nhà phát triển có thể gọi các API mà họ đã triển khai mã hôm nay để ước tính khả năng sử dụng API Hộp cát về quyền riêng tư. |
| Bản dùng thử theo nguyên gốc | Có kế hoạch gia hạn chương trình dùng thử theo nguyên gốc không? | Chúng tôi đã gia hạn thời gian dùng thử theo nguyên gốc đến hết ngày 14 tháng 4 năm 2025. |
| Hộp cát về quyền riêng tư | Yêu cầu giải thích ngắn gọn, không mang tính kỹ thuật về Hộp cát về quyền riêng tư, làm nổi bật giá trị kinh doanh của Hộp cát về quyền riêng tư và đảm bảo ban điều hành ủng hộ. | Gần đây, chúng tôi đã thêm một mục Tài nguyên dành cho doanh nghiệp vào privacysandbox.com tại đây để cung cấp thông tin này. |
| Chế độ B | Khi trình duyệt ở "Chế độ B", hộp cookie hiện tại (1PC, 3PC, bộ nhớ cục bộ) sẽ vẫn còn hay bị xoá? | Hộp bánh quy hiện tại sẽ không bị xoá sạch. Bạn vẫn có thể truy cập vào 3PC trong ngữ cảnh của bên thứ nhất. |
| Cập nhật phương pháp cho 3 máy tính trên Chrome | Trong tương lai, 3PCs có bị xoá hoàn toàn khỏi Chrome không? | Chúng tôi đề xuất một phương pháp mới giúp nâng cao lựa chọn của người dùng. Như đã nêu tại đây, thay vì ngừng sử dụng 3PC, chúng tôi sẽ ra mắt một trải nghiệm mới trong Chrome để giúp mọi người đưa ra lựa chọn sáng suốt áp dụng cho hoạt động duyệt web của họ. Họ cũng có thể điều chỉnh lựa chọn đó bất cứ lúc nào. Chúng tôi đang thảo luận về lộ trình mới này với các cơ quan quản lý và sẽ trao đổi với ngành trước khi triển khai. |
| Kiểm thử Chrome | Yêu cầu tiếp tục sử dụng Nhãn kiểm thử do Chrome hỗ trợ. | Nhóm Hộp cát về quyền riêng tư hiểu rằng các công ty muốn tiếp tục sử dụng nhãn ngừng sử dụng cookie. Quy trình gia hạn phạm vi cung cấp của nhãn tương tự như quy trình gia hạn bản dùng thử theo nguyên gốc. Trong quá trình này, thử nghiệm chỉ có thể được gia hạn cho 3 mốc quan trọng của Chrome cùng một lúc. Ví dụ: Ý định mở rộng thử nghiệm (I2EE) gần đây nhất của Chrome cho nhãn ngừng sử dụng cookie đã được mở rộng cho Chrome M130-M132. Điều này cho phép hỗ trợ các nhãn cho đến khi phát hành phiên bản ổn định M133 vào đầu tháng 2. Các tiện ích bổ sung sẽ chạy theo cùng một quy trình, vì vậy, bạn nên theo dõi trong nhóm email blink-dev để biết thông tin cập nhật. |
Đăng ký và chứng thực
Chúng tôi không nhận được ý kiến phản hồi nào trong quý này.
Hiển thị nội dung và quảng cáo phù hợp
Chủ đề
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Thông số | Mô hình phân loại có được chia sẻ giữa Android (theo tên ứng dụng) và Chrome (theo tên máy chủ lưu trữ) không? | Không, đây là hai mô hình riêng biệt vì có các hệ thống phân loại khác nhau. |
| Độ chi tiết của hệ thống phân loại Chủ đề | Chủ đề quá chung chung nên không hữu ích khi được tận dụng cùng với thông tin của bên thứ nhất. | Hệ thống phân loại Chủ đề hướng đến việc cân bằng giữa tính hữu ích và quyền riêng tư. Mặc dù đã đánh giá các cơ chế có thể áp dụng để giúp Chủ đề trở nên cụ thể hơn, nhưng cuối cùng, chúng tôi quyết định không làm như vậy vì nhiều lý do, trong đó có cả những vấn đề liên quan đến bảo mật và quyền riêng tư. Công nghệ quảng cáo có thể mang lại kết quả tốt nhất bằng cách kết hợp tất cả các công cụ hiện có, chẳng hạn như công nghệ học máy và các tín hiệu đảm bảo quyền riêng tư từ các API bảo đảm quyền riêng tư, cùng với dữ liệu theo bối cảnh, dữ liệu mẫu quảng cáo và dữ liệu của bên thứ nhất. Bạn có thể xem thêm hướng dẫn về vấn đề này tại đây. |
| Việc Sử Dụng API | Topics API có phạm vi áp dụng thấp. | Sau đây là một số lý do thường gặp khiến phạm vi áp dụng thấp: - Chế độ kiểm soát của người dùng/chọn không tham gia - Chế độ kiểm soát của nhà xuất bản/chọn không tham gia - Tiêu chí về trang web (các trang web sau đây không được phê duyệt để so khớp với Chủ đề: trang web không an toàn; WebView; Chrome trên iOS và chế độ ẩn danh) - Giới hạn về người dùng (không thể quan sát và chỉ định Chủ đề cho người dùng Chrome dưới 18 tuổi hoặc đang sử dụng chế độ ẩn danh) - Yêu cầu về hoạt động quan sát của người bán (trình gọi phải từng thấy người dùng trên trang web được liên kết với một chủ đề đủ điều kiện) - Thời gian triển khai gần đây (cần khoảng 4 tuần để tăng cường hoạt động quan sát trình gọi theo quy mô) |
| Việc Sử Dụng API | Yêu cầu thông tin về việc sử dụng Topics API vì thẻ Networking (Mạng) có vẻ cho thấy có một lệnh gọi được gửi và phát hiện nhưng chrome://topics-internals/ không cho thấy trình quan sát được ghi lại. | Khi sử dụng cơ chế tiêu đề HTTP để tương tác với API Chủ đề, các chủ đề sẽ được gửi trong tiêu đề yêu cầu Sec-Browsing-Topics, nhưng chúng chỉ được quan sát nếu máy chủ phản hồi bằng tiêu đề phản hồi Observe-Browsing-Topics: ?1. Bạn có thể xem thêm thông tin chi tiết tại đây. |
| Tham gia Chromium | Đối với máy tính, Chrome có chia sẻ cùng một bối cảnh quan sát và xếp hạng với các trình duyệt khác dựa trên Chromium không? Đối với thiết bị di động, liệu Android Chrome có chia sẻ cùng một bối cảnh quan sát và xếp hạng với các trình duyệt Android khác dựa trên Chromium / Chromium trong ứng dụng không? |
Chrome không chia sẻ dữ liệu Chủ đề với các trình duyệt khác trên thiết bị. |
| Thông số | Topics API quyết định xem một lượt xem trang của người dùng có được coi là "mục nhập nhật ký chủ đề" hay không như thế nào? | Để đủ điều kiện tính toán chủ đề hằng tuần, một lượt truy cập trang phải có lệnh gọi "quan sát" (có thể là từ bất kỳ phương thức gọi nào). Nếu không có lệnh gọi "quan sát", lượt truy cập sẽ không được xem xét cho nhật ký chủ đề. |
| Bảo mật | Topics API ngăn chặn một phương thức gọi nhận được các chủ đề quan sát của các phương thức gọi khác như thế nào? | Chúng tôi đã giải thích về vấn đề này tại đây. |
| Cách phân loại | Hệ thống phân loại cấu trúc cây trong API Chủ đề được sử dụng như thế nào trong quá trình quan sát ở mỗi thời gian bắt đầu? | Khi tính toán 5 chủ đề hàng đầu, hệ thống chỉ xem xét các chủ đề ban đầu do bộ phân loại cung cấp và thứ hạng được xác định theo (i) tần suất truy cập trang và (ii) điểm ưu tiên (xem thông số kỹ thuật). Khi tính toán số người gọi đã quan sát thấy mỗi chủ đề trong số 5 chủ đề hàng đầu, chỉ số này sẽ bao gồm cả những người gọi đã quan sát thấy chủ đề chính hoặc bất kỳ chủ đề con nào của chủ đề chính đó. |
| Thông số | Yêu cầu cung cấp thêm thông tin về 5% tạp âm ngẫu nhiên trên phản hồi. | Mỗi khoảng thời gian bắt đầu của hệ thống luôn có 5 chủ đề hàng đầu. Nếu nhật ký duyệt web không cung cấp 5 chủ đề, thì các chủ đề sẽ được chọn ngẫu nhiên cho đến khi có đủ 5 chủ đề. Chúng tôi gọi đây là chủ đề được thêm vào. Phương thức gọi sẽ không nhận được một trong những chủ đề được thêm vào ngẫu nhiên này trừ phi phương thức gọi đã quan sát thấy (gọi API trên) người dùng trên một trang web có chủ đề đó trong vài tuần qua. Khi API được gọi, hệ thống sẽ tính toán hàm băm trên mỗi người dùng, mỗi trang web, mỗi thời gian bắt đầu. Nếu hàm băm đó nhỏ hơn xác suất trả về một chủ đề bị nhiễu, thì chủ đề ngẫu nhiên trên mỗi người dùng, mỗi trang web, mỗi thời gian bắt đầu của hệ thống sẽ được chọn để trả về. Tuy nhiên, chủ đề bị nhiễu chỉ được trả về (ví dụ: không được lọc) nếu phương thức gọi đã quan sát thấy chủ đề không bị nhiễu tương ứng cho người dùng/trang web/thời gian bắt đầu đó (xem nội dung giải thích). Việc lọc này đảm bảo rằng các chủ đề bị nhiễu sẽ được trả về 5% thời gian cho phương thức gọi nhất định, bất kể khả năng quan sát của phương thức gọi đó. |
| Thông số | Cách hoạt động của các chủ đề trùng lặp giữa các tuần API có chọn độc lập giữa các tuần rồi hợp nhất không? | Các chủ đề của mỗi tuần (thời gian bắt đầu của hệ thống) được tính toán độc lập. Chủ đề cụ thể được chọn để trả về từ mỗi thời gian bắt đầu của hệ thống phụ thuộc vào trang web mà phương thức gọi đang truy cập. Chúng tôi không tính đến việc chủ đề có thể lặp lại trên các thời gian bắt đầu cho một phương thức gọi nhất định (do đó, bạn nên cân nhắc chọn một chủ đề khác), nhưng chúng tôi hoan nghênh ý kiến phản hồi bổ sung về vấn đề này tại đây. |
Protected Audience API
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Thử nghiệm A/B | Giải pháp Bộ nhớ dùng chung được mô tả tại đây làm tăng độ trễ và có tỷ lệ lỗi cao (tức là một tỷ lệ đáng kể lưu lượng truy cập không có mã nhận dạng tập hợp). Mã có độ hỗn loạn thấp (ví dụ: 3 bit) có thể là đủ để thử nghiệm A/B hiệu quả mà không ảnh hưởng đáng kể đến quyền riêng tư. | Chúng tôi tin rằng giải pháp Bộ nhớ dùng chung vẫn là một phương pháp khả thi. Tuy nhiên, chúng tôi đang xem xét yêu cầu này và rất mong nhận được ý kiến phản hồi bổ sung từ hệ sinh thái nếu tính năng này là ưu tiên hàng đầu. |
| Báo cáo | Yêu cầu thêm bit trong reportWin(), đặc biệt là theo hiểu biết thì báo cáo lượt nhấp và hiển thị mới trong PA API sẽ sử dụng 6-8 bit, làm giảm hiệu quả các bit còn lại cho báo cáo PA API khác. |
Chúng tôi không còn cân nhắc việc tăng số bit của modelingSignals ngoài 12 bit hiện tại do lo ngại về quyền riêng tư. Chúng tôi mời hệ sinh thái đưa ra ý kiến phản hồi về Đề xuất đào tạo mô hình riêng tư của chúng tôi. Đề xuất này nhằm hỗ trợ nhu cầu đào tạo học máy trong một môi trường an toàn mà không bị giới hạn về số bit do Hộp cát về quyền riêng tư áp đặt. |
| Nhóm mối quan tâm | Yêu cầu chu kỳ sống 90 ngày cho Nhóm mối quan tâm (IG) vì 30 ngày là không đủ. | Như đã đề cập trong bài đăng trên blog, chúng tôi dự định kéo dài thời hạn lưu trữ video trên Instagram lên 90 ngày. Chúng tôi cũng đã tạo một video giải thích tại đây. Chúng tôi hiện đang triển khai tính năng này và sẽ chia sẻ tiến trình ra mắt khi có. |
| Nhóm mối quan tâm | Yêu cầu cập nhật động cho tính năng uỷ quyền IG. | Chúng tôi đã biết yêu cầu này của nhiều bên liên quan và đang nghiên cứu giải pháp. Chúng tôi sẽ chia sẻ thông tin cập nhật trên GitHub khi dự án này phát triển và hoan nghênh ý kiến phản hồi khác từ hệ sinh thái. |
| Trên thiết bị | Thể hiện thêm giá trị cho hệ sinh thái để tiếp tục đầu tư vào các giải pháp API PA trên thiết bị. | Nhóm Hộp cát về quyền riêng tư tiếp tục phát triển các API dựa trên Công nghệ tăng cường quyền riêng tư (PET), bao gồm cả API PA, để cung cấp cho nhà phát triển nhiều lựa chọn bảo đảm quyền riêng tư hơn trong trình duyệt. Các công nghệ đó hiện đã được cung cấp trên quy mô lớn trên các trình duyệt Chrome (không chỉ 1% như một số nhà phát triển đã hiểu lầm). Cho dù người dùng có bật 3PC hay không, nhà phát triển vẫn có thể chọn tích hợp các giải pháp dựa trên PET vào sản phẩm của họ, giống như nhiều công ty đang chọn áp dụng các giải pháp dựa trên PET khác bên ngoài trình duyệt. Đối với nhiều nhà phát triển, họ đã được hưởng lợi từ việc đầu tư vào các giải pháp API PA trên thiết bị bằng cách mở rộng tín hiệu đối tượng của bên thứ nhất có tính quyết định để cải thiện phạm vi tiếp cận trên các trang web. Chúng tôi hiểu rằng một số nhà phát triển sẽ chỉ chọn sử dụng API Hộp cát về quyền riêng tư hoặc các giải pháp khác dựa trên PET nếu nhiều 3PC bị vô hiệu hoá hơn. Những nhà phát triển này đang chờ thông tin để dự đoán số lượng trình duyệt sẽ giữ lại 3PC. Chúng tôi nhận thấy rằng những nhà phát triển đó sẽ chờ đến khi tìm thấy thông tin họ cần để đưa ra quyết định về sản phẩm. |
| Nhóm mối quan tâm | Cho phép SSP tham gia vào quá trình tạo IG và các vai trò liên quan đến IG. Các SSP coi đây là một phần quan trọng trong giá trị gia tăng của họ và muốn có thể giúp nhà xuất bản bán IG thông qua SSP của họ. | Chúng tôi đã nhận được yêu cầu hỗ trợ các hoạt động uỷ quyền IG nâng cao hơn từ nhiều bên liên quan và chúng tôi nhận thấy giá trị gia tăng của các SSP đóng góp vào quy trình này. Chúng tôi đang nghiên cứu để tìm ra giải pháp tốt nhất cho phép các bên tham gia vào quy trình mở rộng đối tượng. Chúng tôi sẽ chia sẻ thông tin cập nhật trên GitHub khi dự án này phát triển và hoan nghênh ý kiến phản hồi khác từ hệ sinh thái. |
| Báo cáo | Sự khác biệt về số lượng báo cáo "giá thầu khác 0" giữa forDebuggingOnly và API tổng hợp riêng tư. | Chúng tôi dự kiến sẽ có sự khác biệt vì hai lý do: Thứ nhất, chế độ gỡ lỗi API Tổng hợp riêng tư chỉ hoạt động khi có 3PC được phép trên thiết bị, trong khi API forDebuggingOnly luôn có sẵn và không được lấy mẫu (hành vi cuối cùng này cuối cùng sẽ thay đổi như được nêu chi tiết tại đây). Thứ hai, Private Aggregation API có giới hạn đóng góp trong khi forDebuggingOnly thì không. Tuy nhiên, ý kiến phản hồi này cho thấy có thể có một nguyên nhân khác gây ra sự chênh lệch ngoài dự kiến. Chúng tôi đang làm việc với một bên liên quan bên thứ ba để giải quyết vấn đề này. |
| Độ nhấp | Như đã đề cập trong đề xuất cập nhật về tín hiệu mức độ nhấp, lượt xem và lượt nhấp sẽ được đăng ký bằng cách trả về một tiêu đề phản hồi HTTP mới cho các yêu cầu do thuộc tính "attributionsrc" đủ điều kiện khởi tạo", và tiêu đề phản hồi này sẽ bao gồm danh sách các nguồn gốc có thể dùng để cho biết bên nào khác có thể đưa các lượt xem và lượt nhấp này vào số liệu tổng hợp của họ. Điều này có nghĩa là công nghệ quảng cáo có thể đặt nguồn gốc một cách tuỳ ý không? | Trong phần giải thích về mức độ nhấp, chúng tôi đã chỉ định rằng một công nghệ quảng cáo đang đóng góp một sự kiện lượt xem hoặc lượt nhấp vào số lượt xem và số lượt nhấp tổng hợp (một "nguồn gốc cung cấp") có thể bao gồm một tham số không bắt buộc với tiêu đề phản hồi cho phép họ chỉ định "một hoặc nhiều nguồn gốc của chủ sở hữu IG mà sự kiện này có thể được đưa vào số lượt xem và số lượt nhấp được tính toán sẽ được cung cấp cho các lệnh gọi generateBid() của họ trong phiên đấu giá Protected Audience" ("nguồn gốc đủ điều kiện").Tuy nhiên, những lượt xem và lượt nhấp này không tự động được tính vào số lượt xem và số lượt nhấp. Thay vào đó, trong IG, mỗi công nghệ quảng cáo phải chỉ định tập hợp "nguồn gốc cung cấp" mà từ đó các sự kiện xem và nhấp sẽ được đưa vào, đồng thời chỉ dữ liệu từ các nguồn gốc cung cấp này mới đóng góp vào số lượt xem và số lượt nhấp được trình bày cho các lệnh gọi generateBid() của công nghệ quảng cáo đó.Cơ chế này yêu cầu cả hai bên phải thoả thuận và ngăn chặn những bên chơi độc hại ảnh hưởng đến số lượt xem và số lượt nhấp cho các công nghệ quảng cáo khác. Điều này cũng có nghĩa là công nghệ quảng cáo "cung cấp" đặt "nguồn gốc đủ điều kiện" một cách tuỳ ý sẽ không ảnh hưởng đến số lượt xem và số lượt nhấp của những nguồn gốc đủ điều kiện đó, trừ phi những nguồn gốc đủ điều kiện đó cố ý và rõ ràng đưa nguồn gốc cung cấp đó vào IG của họ. |
| Huấn luyện mô hình riêng | Có những trường hợp DP-SGD (Quyền riêng tư vi phân – Độ dốc ngẫu nhiên) sẽ làm chậm đáng kể quá trình huấn luyện vì nó phá huỷ tính thưa thớt của các độ dốc được tính toán trong quá trình hồi quy. Có kỹ thuật nào đang được xem xét để giải quyết vấn đề này không hoặc bạn có ý kiến gì về vấn đề này? | Chúng tôi biết một số kỹ thuật để duy trì tính thưa thớt trong DP-SGD (ví dụ: kỹ thuật này) và chúng tôi đang tìm hiểu cách hỗ trợ các kỹ thuật này trong cơ sở hạ tầng huấn luyện mô hình riêng tư. Chúng tôi sẽ chia sẻ thông tin cập nhật khi dự án này phát triển và rất mong nhận được ý kiến phản hồi khác tại đây. |
| Tiêu chí nhắm mục tiêu phủ định | Yêu cầu thông tin cập nhật về việc triển khai chức năng lọc nội dung tiêu cực trên Instagram như mô tả tại đây. | Như đã nêu trong thư trả lời tại đây, chúng tôi dự định hỗ trợ IG tiêu cực trong giá thầu API PA. Chúng tôi sẽ chia sẻ tiến trình ra mắt khi có thể và rất mong nhận được ý kiến phản hồi bổ sung tại đây. |
| Đặt giá thầu | Có thể kết hợp nhiều IG khi đặt giá thầu không? | Hiện tại, bạn không thể làm việc này với API PA. PA API dựa trên thiết kế mà IG liên quan đến thông tin mà một trang web biết về người dùng. Đây là yếu tố cốt lõi trong các cuộc thảo luận với hệ sinh thái nói chung. Phương pháp này cho phép các công nghệ quảng cáo xây dựng nhiều giải pháp giúp nhà quảng cáo mở rộng đối tượng bên thứ nhất trên web. Chúng tôi biết rằng đề xuất về API Lựa chọn quảng cáo của Microsoft đề xuất một thiết kế khác, trong đó đối tượng dựa trên thông tin trên các trang web. Mặc dù sẽ tiếp tục theo dõi phương pháp của họ, nhưng chúng tôi muốn xem thêm nội dung thảo luận từ hệ sinh thái, bao gồm cả cộng đồng về quyền riêng tư, trước khi cân nhắc những thay đổi tương tự đối với Chrome. |
| Quảng cáo gốc | Mối lo ngại về việc liệu PA API có thể hỗ trợ đầy đủ các định dạng và yêu cầu kết xuất của Quảng cáo gốc hay không, cũng như liệu PA API có cho phép linh hoạt và tối ưu hoá mẫu quảng cáo cần thiết để quảng cáo gốc hoạt động hiệu quả hay không. | Chúng tôi đang tích cực nghiên cứu để hỗ trợ thêm cho Quảng cáo gốc và rất mong nhận được ý kiến phản hồi khác từ hệ sinh thái. |
| Báo cáo | Yêu cầu cải thiện độ mạnh mẽ của các tập lệnh báo cáo cạnh tranh với các tập lệnh đặt giá thầu và có thể bị mất khi khung phiên đấu giá đang chạy bị chuyển đi. | Chúng tôi hy vọng sẽ sớm đăng nội dung phản hồi lên GitHub, nhưng chúng tôi không cho rằng những vấn đề này ảnh hưởng đáng kể đến việc báo cáo hợp lệ trong thực tế |
| Thay thế macro | Cấu hình phiên đấu giá đã chuyển các thay thế macro không hoạt động với một số cấu hình bên thứ ba. | Nguyên nhân cốt lõi là do không phải tất cả lưu lượng truy cập được gắn nhãn Chế độ A/B đều bật tính năng này. Gần đây, chúng tôi đã quyết định bật tính năng này (và các tính năng khác trong cùng trường hợp) trên tất cả lưu lượng truy cập được gắn nhãn Chế độ A/B. Chúng tôi dự kiến sẽ thực hiện thay đổi này trong quý 1 năm 2025. Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn tại đây. |
| Tài liệu | Yêu cầu làm rõ vì có vẻ như có sự khác biệt trong tài liệu liên quan đến đơn vị đo lường cho giá trị gần đây nhất trong đối tượng browserSignals trong generateBid(). |
Chúng tôi đã phản hồi vấn đề này một cách chi tiết hơn tại đây và cập nhật tài liệu của chúng tôi cho phù hợp. Câu trả lời chính xác là đơn vị đo lường là mili giây. |
| Báo cáo | Yêu cầu báo cáo của bên thứ ba; mặc dù DSP và SSP nhận được thông báo về lượt hiển thị từ Chrome, nhưng theo mặc định, các nhà cung cấp kỹ thuật lớp giữa sẽ không nhận được. | Chúng tôi hiện đang thảo luận về yêu cầu tính năng này tại đây và hoan nghênh bạn đóng góp ý kiến phản hồi khác. |
| Nhóm mối quan tâm | Yêu cầu hướng dẫn về cách linh động loại trừ interestGroupBuyers khi sử dụng quy trình đấu giá IG song song. | Chúng tôi đã cung cấp hướng dẫn về việc này tại đây. |
| Quảng cáo gốc | Phiên đấu giá API PA độc lập cho một lượt tải trang nhất định sẽ ngăn việc lọc quảng cáo trên cùng một trang. | Chúng tôi đang tích cực nghiên cứu để hỗ trợ thêm cho Quảng cáo gốc, bao gồm cả các tiện ích đề xuất được gọi là "gốc" và có nhiều quảng cáo trong một đơn vị. Chúng tôi thừa nhận rằng thiết kế hiện tại có thể không hỗ trợ tính năng lọc quảng cáo trên cùng một trang và các biện pháp bảo vệ khác như Khung có hàng rào cũng có thể ngăn chặn việc này. |
| Quảng cáo gốc | Các tính năng hiện có của API PA (như quét mẫu quảng cáo, báo cáo, v.v.) dựa vào các tín hiệu dựa trên URL có thể cần được điều chỉnh để xử lý các đối tượng JSON được dùng trong mẫu quảng cáo gốc. | Chúng tôi đang tích cực nghiên cứu để hỗ trợ thêm cho Quảng cáo gốc và đang đánh giá khả năng điều chỉnh API PA để hỗ trợ hiển thị quảng cáo gốc. |
| Xác minh quảng cáo | Tính năng an toàn thương hiệu của bên thứ ba trong API PA bị ảnh hưởng do độ trễ và các giới hạn về bộ nhớ đệm của perBuyerSignals, gây ra vấn đề cho nội dung động. | Chúng tôi nhận thấy rằng SSP và DSP cần xác định TTL tối ưu để lưu vào bộ nhớ đệm, nhằm cân bằng các mục tiêu định hình lưu lượng truy cập và TTL tối đa về an toàn thương hiệu để đảm bảo rằng dữ liệu được lưu vào bộ nhớ đệm vẫn phù hợp với an toàn thương hiệu. Chúng tôi đang tìm hiểu vấn đề này và sẽ chia sẻ thông tin cập nhật khi có. |
| Xác minh quảng cáo | Các SSP cần thay thế macro FullpageURL để tiến hành đo lường mức độ an toàn cho thương hiệu sau khi đặt giá thầu. | deprecatedReplaceInURN là đề xuất hiện tại cho các SSP để cung cấp tín hiệu này. |
| Xác minh quảng cáo | Việc thiếu tiêu chuẩn hoá trong định dạng macro mà SSP sử dụng để xác minh sau khi đặt giá thầu có thể gây ra sự không nhất quán và lỗi trong quá trình xử lý và phân tích dữ liệu. | SSP và Trình xác minh quảng cáo nên cộng tác trực tiếp để xác định các nguyên tắc và thông số kỹ thuật rõ ràng về việc sử dụng macro nhằm thúc đẩy việc chuẩn hoá định dạng macro trên các SSP để đảm bảo tính nhất quán và ngăn chặn lỗi trong quá trình xử lý và phân tích dữ liệu. Đây là hoạt động phù hợp với các tổ chức tiêu chuẩn quảng cáo như IAB Tech Lab. |
| Xác minh quảng cáo | Nhà quảng cáo và Trình xác minh quảng cáo cần có một cơ chế để liên kết các bước kiểm tra trước và sau khi đặt giá thầu cho cùng một ngữ cảnh của nhà xuất bản để gỡ lỗi và khắc phục sự cố. | Một cách để xác minh sau khi đặt giá thầu là thông qua các tín hiệu dựa trên chiến dịch và phiên đấu giá được đưa vào báo cáo cấp sự kiện. Việc này có thể cho phép các phép nối với nhật ký quyết định đặt giá thầu trước. Chúng tôi đang tìm hiểu các mẫu có thể áp dụng để đạt được điều này và sẽ chia sẻ thông tin cập nhật khi phát triển. |
| Xác minh quảng cáo | Yêu cầu tìm hiểu các giải pháp máy chủ Khoá-giá trị đáng tin cậy (TKV) (thuộc sở hữu của DSP và Trình xác minh quảng cáo) để đặt giá thầu trước và giải quyết các giới hạn về khung được bảo vệ sau khi đặt giá thầu. | Chúng tôi đang đánh giá yêu cầu này và hoan nghênh ý kiến phản hồi bổ sung từ hệ sinh thái tại đây để tìm ra giải pháp có thể hỗ trợ tính năng đảm bảo an toàn cho thương hiệu trước khi đặt giá thầu và giảm bớt các yêu cầu phối hợp giữa các bên. |
| Quảng cáo gốc | Yêu cầu kiểm tra hoạt động hiển thị sau khi đặt giá thầu của bên bán đối với quảng cáo gốc. | Chúng tôi đang tích cực nghiên cứu để hỗ trợ thêm cho Quảng cáo gốc và đang cân nhắc việc điều chỉnh các tính năng hiện có như tính năng này để hỗ trợ việc hiển thị quảng cáo gốc. |
Phiên đấu giá được bảo vệ (Dịch vụ đặt giá thầu và phiên đấu giá)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Độ trễ | Chưa có biện pháp giảm thiểu thích hợp cho độ trễ. Mặc dù Dịch vụ B&A có thể giảm thiểu vấn đề này về lâu dài, nhưng Google chưa cam kết cung cấp rộng rãi dịch vụ này trước khi thay đổi 3PC trên Chrome. | Chúng tôi đã cải thiện một số điểm về độ trễ trên thiết bị trong vài quý qua. Chúng tôi cũng đang xây dựng và mở rộng các dịch vụ B&A nếu cần. Gần đây, chúng tôi đã cập nhật hướng dẫn về các phương pháp hay nhất về độ trễ, trong đó có thêm thông tin về cách tận dụng các tính năng này. Chúng tôi cũng đang tiếp tục phát triển các tính năng cải thiện độ trễ mới, một số tính năng trong số đó có thể xem tại đây. |
| (Cũng được báo cáo trong các quý trước) Bảo mật phiên đấu giá |
Yêu cầu giải thích rõ hơn về các phương pháp ngăn chặn/giảm thiểu các hành vi can thiệp vào phiên đấu giá trên thiết bị (ví dụ: bao gồm cả việc Google có coi đây là một rủi ro đáng kể hay không). | Câu trả lời của chúng tôi không thay đổi so với các quý trước: "Hiện nay, cơ chế báo cáo của quảng cáo PA API vẫn giữ lại thông tin dùng để phân biệt lưu lượng truy cập của con người với lưu lượng truy cập của bot. Ngoài ra, bạn có thể sử dụng các kỹ thuật hiện tại dựa trên miền để đưa vào hoặc loại trừ miền trong API PA. Điều này được mô tả chi tiết hơn trong phản hồi của chúng tôi về báo cáo của IAB Tech Lab về Hộp cát về quyền riêng tư". |
| Giải pháp tại chỗ | Mối lo ngại về việc các nhà cung cấp lớn nhất có thể không áp dụng Hộp cát về quyền riêng tư hoặc B&A do thiếu tính năng hỗ trợ cho đám mây riêng tư, cũng như lộ trình hỗ trợ dài và không rõ ràng. | Chúng tôi cam kết mở rộng cơ sở hạ tầng mà các dịch vụ Hộp cát về quyền riêng tư chạy trên đó; gần đây, chúng tôi đã công bố việc hỗ trợ đám mây Azure và tiếp tục tìm hiểu các giải pháp có thể cung cấp các biện pháp bảo vệ quyền riêng tư và bảo mật tương tự cho các đám mây riêng tư. Kể từ khi thông báo vào tháng 10, chúng tôi đã đạt được tiến bộ khi tiếp tục nghiên cứu các phương pháp tiềm năng để bảo vệ quyền riêng tư của người dùng Chrome trong Môi trường thực thi đáng tin cậy (TEE) tại chỗ. Hiện tại, chúng tôi đang ở giai đoạn nghiên cứu để xác thực các phương pháp khác nhau với các bên liên quan trong hệ sinh thái. Chúng tôi dự định bắt đầu thu thập ý kiến đóng góp trong quý 1. Ý kiến phản hồi và hoạt động cộng tác trong hệ sinh thái sẽ giúp tinh chỉnh mọi giải pháp có thể. |
| Thử nghiệm | Có thể tạo TEE để kiểm thử các giải pháp báo cáo API PA (Báo cáo theo thời gian thực và Tổng hợp riêng tư) không? | Để kiểm thử Dịch vụ tổng hợp, công nghệ quảng cáo có thể sử dụng dữ liệu kiểm thử và công cụ Kiểm thử cục bộ để tạo báo cáo tóm tắt cho hoạt động kiểm thử chức năng. Vui lòng tham khảo Lớp học lập trình về kiểm thử cục bộ tại đây. Để kiểm thử tính năng Tổng hợp trong TEE, các công nghệ quảng cáo cần hoàn tất quy trình đăng ký như đã đề cập trong các điều kiện tiên quyết của Lớp học lập trình ở trên. Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn về yêu cầu này tại đây. |
| Tích hợp K/V của thoả thuận | Yêu cầu khả năng lấy thông tin dựa trên thoả thuận từ KV cho các trường hợp sử dụng kinh doanh. | Chúng tôi đang đánh giá yêu cầu về tính năng này và sẽ cập nhật thông tin trên GitHub. |
| Chỉ số đo lường thoả thuận không có lợi |
Yêu cầu tín hiệu hoặc khả năng hiểu được thời điểm một SSP không thắng thầu và lý do. | Chúng tôi đang đánh giá yêu cầu này và sẽ cung cấp thông tin cập nhật trên GitHub. |
| Yêu cầu tính năng | Yêu cầu Hộp cát về quyền riêng tư cung cấp cấu trúc từ điển để so khớp một nhóm quảng cáo với nhóm Mã giao dịch tương ứng. | Chúng tôi đang đánh giá yêu cầu này cùng với các cách khác để giảm kích thước IG liên quan đến việc lưu trữ mã giao dịch. Chúng tôi sẽ cung cấp thông tin cập nhật trên GitHub. |
| Hiệu suất | Giải pháp để đo lường các cơ hội có thể bị bỏ lỡ trong phiên đấu giá quảng cáo, có thể là do kích thước tập lệnh đặt giá thầu. | Chúng tôi đang đánh giá yêu cầu này và rất mong nhận được ý kiến phản hồi bổ sung tại đây. |
| Thông số | Hiện tại, B&A chỉ đọc trường prevWins thay vì trường mới nhất prevWinMs đã thay thế prevWins trong thông số kỹ thuật. | Đúng là B&A không truyền thời lượng tính bằng mili giây trong prevWins đến generatebid(). Chrome gửi thời lượng tính bằng giây để đảm bảo giảm hao tổn tải trọng. Cách khắc phục ở đây là để B&A thực hiện việc chuyển đổi từ giây sang mili giây. B&A sẽ cung cấp cả prevWins và prevWinsMs trong browserSignals để tương thích với phiên đấu giá trên thiết bị.Lưu ý: ngay cả đối với phiên đấu giá trên thiết bị cho web, prevWins và prevWinsMs cũng tương ứng với cùng một giá trị và prevWinsMs = prevWins * 1000. Chúng tôi đang ưu tiên khắc phục vấn đề này. |
| Tài liệu | Tài liệu không nêu rõ cách kiểm thử Giao diện người dùng của người bán (SFE). Bạn nên có thêm hướng dẫn kiểm thử ngay sau khi hoàn tất quá trình triển khai cũng như cách sử dụng Bazel cho các bản dựng. | Lớp học lập trình này được xuất bản dưới dạng hướng dẫn để giúp hệ sinh thái rộng lớn hơn kiểm thử SFE của họ dễ dàng hơn. |
| Triển khai | Có kế hoạch cung cấp tệp nhị phân tạo sẵn cho B&A không? | Chúng tôi đang cân nhắc việc cung cấp các tệp nhị phân tạo sẵn cho B&A, tuy nhiên, chúng tôi chưa có tiến trình cụ thể cho việc này. Cho đến thời điểm đó, các công nghệ quảng cáo có thể tự tạo tệp nhị phân và xác thực bằng hàm băm được cung cấp. |
| Triển khai | Bạn có nên hỗ trợ tất cả các loại điều phối (máy chủ, ứng dụng, kết hợp) hay có loại nào được ưu tiên hơn các loại khác không? | Chúng tôi không có đề xuất cụ thể nào về chế độ mà công nghệ quảng cáo triển khai. Lựa chọn này phụ thuộc vào nhiều yếu tố, nhưng cuối cùng, tuỳ thuộc vào lợi ích tốt nhất của khách hàng. |
| Thử nghiệm | Cần làm rõ về các lần kiểm thử không thành công trong bản dựng B&A. | Đây có thể là kết quả của một kiểm thử không ổn định. Chúng tôi đã khuyên công nghệ quảng cáo sử dụng cờ --no-tests cho tất cả các lệnh bản dựng build_and_test_all_in_docker để bỏ qua việc chạy kiểm thử. |
| Nhật ký | Cần làm rõ lý do nhật ký trong trình khám phá nhật ký trên GCP được gắn thẻ vào thực thể máy ảo đang chạy SFE khi ở chế độ kiểm thử, nhưng ở chế độ sản xuất, nhật ký không được gắn thẻ vào thực thể máy ảo. | Rất khó để khái quát vì điều này phụ thuộc vào nội dung chính xác đã thấy, nhưng nói chung: – nhật ký từ non_prod có thể là nhật ký stderr do nhà cung cấp dịch vụ đám mây chuyển hướng (trong trường hợp này là GCP) và GCP đã thêm thẻ. – Nhật ký do máy ảo tạo thường được gắn thẻ bằng thực thể máy ảo, trong khi nhật ký do tệp nhị phân tạo không được GCP gắn thẻ. – nhật ký từ sản phẩm được xuất bằng Open Telemetry trong TEE, có các thẻ khác nhau. Dưới đây là một số thông tin chi tiết về những gì có sẵn tại non_prod và prod. |
| B&A | Lỗi 403 khi thiếu thông tin bí mật khi tính năng ghi nhật ký OTEL bị tắt. | Lỗi này hiện đã được khắc phục kể từ bản cập nhật 4.1 và tài liệu đã được chỉnh sửa cho phù hợp. |
| B&A | Thiếu tệp outputs.tf cho cấu hình terraform GCP dẫn đến lỗi. | Vấn đề này hiện đã được khắc phục. |
| Thử nghiệm | Lỗi khi tìm nạp khoá riêng tư ở chế độ thử nghiệm. | Trong những trường hợp này, vui lòng đảm bảo máy chủ đang chạy với TEST_MODE=true. Xem nội dung giải thích tại đây. |
| Lộ trình | Có kế hoạch nào để getInterestGroupAdAuctionData chấp nhận nhiều nguồn gốc người bán và trả về bản đồ nguồn gốc người bán cho văn bản mã hoá tải trọng B&A không? | Có, chúng tôi dự định thêm tính năng hỗ trợ để cho phép navigator.getInterestGroupAdAuctionData() chấp nhận nhiều người bán. |
| Thông số kỹ thuật của KV | URL KV (trustedScoringSignalsURL) có thể được phân phối dưới dạng một lời hứa không? | Xem nội dung giải thích tại đây. |
| B&A | Yêu cầu tạo tiêu đề nền tảng mới để cho bên bán B&A biết những chức năng mà ứng dụng (trình duyệt) yêu cầu để diễn ra phiên đấu giá kín. | Chúng tôi hiện đang thảo luận về yêu cầu tính năng này tại đây và hoan nghênh bạn đóng góp ý kiến phản hồi khác. |
| Định hình lưu lượng truy cập | Đề xuất để giảm chi phí gia tăng từ việc lưu trữ máy chủ B&A, đặc biệt là đối với DSP. | Chúng tôi hiện đang thảo luận về đề xuất này tại đây và hoan nghênh ý kiến phản hồi khác. |
| Mang- -tệp-nhị-phân-của-bạn |
Cân nhắc cập nhật nội dung giải thích để nêu rõ rằng tất cả tệp nhị phân đều được hỗ trợ. | Chúng tôi đã cập nhật thông tin này. Hãy xem nội dung giải thích tại đây. |
| Lệnh gọi KV | generateBid() có chờ tất cả lệnh gọi lưu trữ Khoá-Giá trị (KV) kết thúc hay chạy độc lập không? Việc tạo lô KV ảnh hưởng như thế nào đến thời gian của lô đó? |
Xem nội dung giải thích tại đây. |
| Hiệu suất | Yêu cầu tài liệu bổ sung về việc sử dụng lại tập lệnh đặt giá thầu và đề xuất đặt tiêu đề kiểm soát bộ nhớ đệm trên tập lệnh. | Chúng tôi đã thêm tài liệu tại đây. |
| Hiệu suất | Yêu cầu xem xét và khám phá khả năng tải tài nguyên (ví dụ: tập lệnh đặt giá thầu) không đồng bộ để giảm độ trễ của phiên đấu giá trên thiết bị. | Chúng tôi hiện đang thảo luận về yêu cầu tính năng này tại đây và hoan nghênh bạn đóng góp ý kiến phản hồi khác. |
| Ghi nhật ký về sự đồng ý | Cần làm rõ lỗi xuất hiện khi cố gắng sử dụng tính năng ghi nhật ký sự đồng ý bằng cách đặt CONSENTED_DEBUG_TOKEN. | Trong những trường hợp này, hãy kiểm tra để đảm bảo rằng CONSENTED_DEBUG_TOKEN có trong trình quản lý bí mật, ENABLE_OTEL_BASED_LOGGING được đặt thành true và TELEMETRY_CONFIG được đặt thành mode: PROD. Xem nội dung giải thích tại đây, nội dung này tham chiếu đến nguồn tại đây. |
| Nhật ký | Sự kiện forDebuggingOnly có được cung cấp thông qua B&A không? | forDebuggingOnly cho B&A đã được cung cấp cho các phiên đấu giá của một người bán kể từ tháng 4 năm 2024. Chúng tôi dự định sẽ sớm bật tính năng này cho các phiên đấu giá nhiều người bán. |
| Nhật ký worklet | Yêu cầu để ghi nhật ký worklet tương thích với ChromeDriver. | Chúng tôi đang đánh giá yêu cầu này và rất mong nhận được ý kiến phản hồi bổ sung tại đây. |
Đo lường quảng cáo kỹ thuật số
Báo cáo phân bổ (và các API khác)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Báo cáo gỡ lỗi | Báo cáo gỡ lỗi ARA sẽ được cung cấp cho các công nghệ quảng cáo theo phương pháp cập nhật đối với 3PC trên Chrome như thế nào? Công nghệ quảng cáo có còn quyền truy cập vào Báo cáo gỡ lỗi ARA đối với những người dùng giữ lại 3PC và bật API Hộp cát về quyền riêng tư không? |
Các công nghệ quảng cáo sẽ có quyền truy cập vào các giải pháp gỡ lỗi dựa trên cookie và không dùng cookie đối với những người dùng đã bật cả 3PC và ARA. Khi cookie tắt, các ứng dụng này sẽ chỉ có quyền truy cập vào giải pháp gỡ lỗi tổng hợp. Bạn có thể xem thêm thông tin chi tiết về các giải pháp gỡ lỗi tại đây và tại đây. |
| Phát hiện tính năng | Yêu cầu hướng dẫn về cách phát hiện tính năng cho ARA ở phía máy chủ. | Hiện tại, bạn có thể xác định tính năng hỗ trợ ARA dựa trên việc sử dụng phiên bản Chrome trong chuỗi tác nhân người dùng. Chúng tôi rất mong nhận được ý kiến phản hồi bổ sung của bạn về hệ sinh thái. |
| Yêu cầu tính năng | Yêu cầu source_registration_time được sử dụng trong shared_info tổng hợp ARA phải chi tiết hơn, ví dụ: làm tròn xuống một giờ hoặc một phút (thay vì một ngày) cũng như có thể định cấu hình để xem xét múi giờ (hiện chỉ có UTC). | Làm tròn trường source_registration_time đến ngày gần nhất là một cơ chế bảo vệ quyền riêng tư dùng để giảm khả năng công nghệ quảng cáo có thể liên kết một người dùng cụ thể với một lượt đăng ký nguồn cụ thể. Hiện tại, source_registration_time dựa trên múi giờ UTC và công nghệ quảng cáo có thể điều chỉnh báo cáo quảng cáo của mình để tính đến điều này. Chúng tôi hoan nghênh ý kiến phản hồi khác về hệ sinh thái liên quan đến yêu cầu này tại đây. |
| Thông số | Yêu cầu làm rõ thông số kỹ thuật của "trigger_data" và "priority", đặc biệt là khi các thông số này được sử dụng với giá trị mảng. | Các trường này không chấp nhận giá trị mảng. Dấu ngoặc vuông trong phần giải thích không biểu thị một mảng, mà cho biết rằng văn bản đó không phải là giá trị mẫu mà là phần giữ chỗ có nội dung mô tả. Như văn bản trong dấu ngoặc vuông cho thấy: – trigger_data là int-64 – priority là int-64 đã ký Không có trường nào chấp nhận giá trị mảng. Bạn cũng nên cân nhắc sử dụng công cụ xác thực tiêu đề cho ARA để thử nghiệm với các giá trị khác nhau và gặp lỗi nếu tài liệu gây nhầm lẫn. |
| Hỗ trợ quảng cáo trên Accelerated Mobile Pages (AMP) | ARA có hỗ trợ quảng cáo AMP không? | Bạn có thể xem đề xuất của chúng tôi về cách hỗ trợ AMP tại đây. Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn. |
| Thông số | URL nào sẽ được xem là "trang web nguồn" cho quảng cáo nhúng nhiều lớp cho ARA? | URL của trang web cấp cao nhất. |
| (Cũng được báo cáo trong các quý trước) Yêu cầu về tính năng |
Yêu cầu giảm giá trị tối thiểu của event_report_window từ 3600 giây (1 giờ) xuống còn 1800 giây (30 phút). | Khi xác định khoảng thời gian báo cáo tối thiểu, bạn cần cân bằng giữa tính hữu ích và quyền riêng tư. Khoảng thời gian báo cáo tối thiểu là 1 giờ đối với báo cáo ở cấp sự kiện là điều cần thiết để duy trì quyền riêng tư và giảm thiểu một số loại tấn công tái tạo nhật ký. Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn về yêu cầu này tại đây. |
| Tạp âm | Tìm hiểu sâu hơn về cách độ nhiễu được triển khai trong báo cáo cấp sự kiện ARA để đảm bảo việc diễn giải và sử dụng dữ liệu chính xác. | Bạn có thể xem thêm thông tin chi tiết tại đây và tại đây. |
| Báo cáo | Theo mặc định, shared_info trong Báo cáo tổng hợp không còn chứa source_registration_time nữa. | Điều này là do các thay đổi về API và được nêu chi tiết hơn tại đây. |
| Báo cáo | filtering_id không có trong thẻ "Báo cáo tổng hợp" của giao diện người dùng chrome://attribution-internals/. |
filtering_id hiện xuất hiện trong thông tin chi tiết của thẻ "Kích hoạt lượt đăng ký" khi bạn nhấp vào một hàng. Điều này cho phép bạn xác nhận tính hợp lệ của lượt đăng ký. Chúng tôi nhận thấy tính hữu ích của việc hiển thị chỉ số này trong thẻ "Báo cáo tổng hợp" và đã giải quyết vấn đề này tại đây. |
| Nguồn phân bổ | Yêu cầu làm rõ cách hoạt động của nguồn phân bổ. | Bạn có thể xem nội dung giải thích tại đây. |
| Phân bổ ứng dụng đến web | Yêu cầu hướng dẫn triển khai khi không chắc chắn nguồn sẽ là hệ điều hành hay web. | Bạn có thể xem hướng dẫn tại đây. |
Dịch vụ tổng hợp
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Yêu cầu tính năng | Yêu cầu về thời gian chờ có thể định cấu hình cho AgS và/hoặc khả năng hiển thị trạng thái công việc tốt hơn cho các lần chạy dài hạn. | Chúng tôi đang xem xét các tính năng để hỗ trợ việc giám sát các công việc chạy trong thời gian dài. Chúng tôi rất mong nhận được ý kiến phản hồi bổ sung của bạn về hệ sinh thái. |
| Terraform | Terraform đang cố gắng sửa đổi Chính sách IAM của tài khoản ngay cả khi bạn không đặt service_account_token_creator_list. | Nhà phát triển có thể thêm các quyền đã thêm vào tệp modules/adtech_setup/main.tf cục bộ. |
| Yêu cầu tài liệu | Yêu cầu tài liệu hoặc lớp học lập trình giải thích cách theo dõi tình trạng của dịch vụ tổng hợp. | Bạn có thể xem nội dung mô tả về các chuông báo hiện có có thể dùng để theo dõi tình trạng dịch vụ và công việc trong các tệp terraform của toán tử có liên quan (alarms.tf và monitoring.tf) trong kho lưu trữ coordinator-services-and-shared-libraries. Chúng tôi sẽ phát hành thêm tài liệu và hướng dẫn về cách theo dõi công việc của dịch vụ tổng hợp. |
| Chuyển tỷ lệ | Làm cách nào để theo dõi các vấn đề về việc mở rộng quy mô? | Chúng tôi đã phát hành phiên bản cập nhật của hướng dẫn này để ghi lại quy mô cao hơn của Dịch vụ tổng hợp. Hiện không có tín hiệu trực tiếp nào cho biết đã xảy ra lỗi vì máy không thể hỗ trợ quy mô của công việc. Các tín hiệu gián tiếp bao gồm: 90% mức sử dụng bộ nhớ trước khi xảy ra lỗi, một công việc liên tục gặp lỗi. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung về hệ sinh thái liên quan đến nhu cầu về tín hiệu như vậy. |
| Thông số | Thời gian chạy thông thường của các lô báo cáo AgS là bao lâu? | Vui lòng tham khảo hướng dẫn tại đây. |
Private Aggregation API
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Yêu cầu tính năng | Yêu cầu cho phép đóng góp các giá trị float (bao gồm cả giá trị âm) để đóng góp vào contributeToHistogramOnEvent với độ nhạy là 2^16 | Chúng tôi hiện đang thảo luận về đề xuất này tại đây và hoan nghênh ý kiến phản hồi khác. |
Giới hạn hoạt động theo dõi ẩn
Giảm thiểu tác nhân người dùng/Thông tin mô tả của ứng dụng tác nhân người dùng
Chúng tôi không nhận được ý kiến phản hồi nào trong quý này.
Bảo vệ tài sản trí tuệ (trước đây là Gnatcatcher)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Vị trí địa lý | Yêu cầu tệp vị trí địa lý cho tính năng Bảo vệ địa chỉ IP. | Bạn có thể xem tệp ánh xạ địa chỉ IP đến vị trí gần đúng để Bảo vệ quyền sở hữu trí tuệ tại đây. Xin lưu ý rằng tệp này được cập nhật định kỳ. |
Giảm thiểu hoạt động theo dõi tỷ lệ thoát
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Danh sách cho phép | Quan điểm cập nhật không còn đề cập đến danh sách cho phép hoặc các cơ chế tương tự độc lập với quy trình ra quyết định của Google. | Google không có kế hoạch tạo danh sách cho phép liên kết với biện pháp giảm thiểu tính năng theo dõi lượt thoát (BTM); các biện pháp bảo vệ này được áp dụng đồng nhất cho tất cả các miền. |
| Độ giãn nở | ICO phải có thẩm quyền về việc tuân thủ các quy định liên quan đến quyền riêng tư. | Trạng thái tuân thủ không liên quan đến việc áp dụng BTM và Google không đưa ra quyết định nào liên quan đến việc tuân thủ trong quá trình triển khai BTM. |
| Mức độ cạnh tranh | Có vẻ như Google có thể được phép ngăn chặn các đối thủ cạnh tranh trong lĩnh vực PET bằng BTM (hoặc các biện pháp khác), sau đó quyết định xem có cho phép họ quay lại thị trường hay không. Quy trình khiếu nại hiện tại có thể tạm thời ngăn các đối thủ cạnh tranh trong ngành PET sử dụng BTM hoặc các biện pháp tương tự. | Đề xuất hiện tại về BTM nhắm đến việc theo dõi lượt thoát dưới dạng một kỹ thuật. Mặc dù Google cố gắng tránh vi phạm một số trường hợp sử dụng có thể liên quan đến các kỹ thuật tương tự, nhưng Google không có kế hoạch miễn trừ riêng lẻ cho BTM. Do đó, không có vấn đề nào về việc Google sử dụng quyền tự quyết đối với sự hiện diện của các đối thủ cạnh tranh. |
Tăng cường ranh giới quyền riêng tư trên nhiều trang web
Bộ trang web có liên quan (trước đây là Nhóm bên thứ nhất)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| (Cũng được báo cáo trong các quý trước) Giới hạn miền của Bộ trang web có liên quan (RWS) |
Giới hạn hiện tại là 5 miền được liên kết là chưa đủ để đáp ứng các trường hợp sử dụng tính năng đo lường trên nhiều trang web. | Phản hồi của chúng tôi tương tự như các quý trước: Hiện tại, chúng tôi không dự kiến sẽ tăng hạn mức số. Giới hạn này được thiết lập dựa trên các cân nhắc về quyền riêng tư của người dùng, ý kiến phản hồi của các bên liên quan trong hệ sinh thái trong W3C và việc xem xét các phương thức triển khai tương đương trong các trình duyệt khác. Để biết thêm thông tin, vui lòng xem các bài đăng trên blog của chúng tôi (1, 2). Bạn nên kiểm tra các trường hợp sử dụng yêu cầu quyền truy cập cookie trên nhiều trang web ngoài giới hạn số lượng và cân nhắc việc tận dụng hướng dẫn của chúng tôi về trường hợp sử dụng danh tính, nội dung nhúng đã xác thực và trường hợp sử dụng quảng cáo. Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn về vấn đề này tại đây. |
Fenced Frames API
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Quảng cáo gốc | Việc hiển thị quảng cáo gốc trong Khung có hàng rào gây ra nhiều thách thức vì việc kế thừa kiểu của nhà xuất bản bị hạn chế do các giới hạn về việc giao tiếp giữa iframe và trang của nhà xuất bản. | Chúng tôi đang tích cực nghiên cứu để hỗ trợ thêm cho quảng cáo gốc, bao gồm cả việc hỗ trợ sau khi thực thi quy định về Khung được phân vùng. Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn về vấn đề này tại đây. |
Shared Storage API
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Việc Sử Dụng API | API Bộ nhớ dùng chung không hoạt động trên một số thiết bị khi các API Hộp cát về quyền riêng tư khác hoạt động. | Hành vi này dự kiến sẽ xảy ra với một nhóm nhỏ người dùng (khoảng 1%) tham gia thử nghiệm trì hoãn Bộ nhớ dùng chung. Chế độ thiết lập thử nghiệm này được dùng để đánh giá hiệu suất và mức độ sử dụng API trong nhiều tình huống. |
| Việc Sử Dụng API | Hoạt động ghi vào Bộ nhớ dùng chung có xảy ra ở nguồn gốc của nhà xuất bản hay nguồn gốc của tập lệnh đặt giá thầu không? Kết quả kiểm thử ban đầu cho thấy không có hoạt động ghi nào khi nguồn gốc của nhà xuất bản khác với nguồn gốc của tập lệnh. | Vấn đề này đã được giải quyết và chỉ còn tồn tại trong trường hợp có thể xảy ra lỗi devtools. Bạn có thể xem thêm thông tin chi tiết tại đây. Bộ nhớ dùng chung ghi vào nguồn gốc của người mua trong ngữ cảnh đặt giá thầu của lệnh gọi generateBid. Hoạt động ghi không liên kết với nguồn gốc của nhà xuất bản, ngay cả khi trang nhà xuất bản nằm trên một miền khác. |
| Việc Sử Dụng API | Chúng tôi có biện pháp bảo vệ nào để ngăn chặn kẻ xấu đọc báo cáo Bộ nhớ dùng chung không? | Bộ nhớ dùng chung được phân vùng bằng cách gọi nguồn gốc để kẻ xấu hoặc công nghệ quảng cáo không thể đọc dữ liệu Bộ nhớ dùng chung từ một công nghệ quảng cáo khác. Báo cáo Tổng hợp riêng tư được gửi trực tiếp đến cùng một nguồn gốc thông qua TLS để không thể bị chặn. |
Cookie có trạng thái được phân vùng độc lập (CHIPS)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Cookie được phân vùng | Việc xử lý cookie trên các cổng máy chủ cục bộ khác nhau trong Chrome và Firefox không nhất quán, đặc biệt là khi sử dụng thuộc tính Phân vùng. | Firefox coi localhost với các cổng khác nhau là các khoá phân vùng riêng biệt. Mặc dù hành vi này phù hợp với các nguyên tắc bảo mật, nhưng lại khác với thông số kỹ thuật và phương pháp của Chrome. Chúng tôi dự kiến sẽ thảo luận về vấn đề này với các trình duyệt khác trong một cuộc thảo luận về thông số kỹ thuật HTML và sẽ thông báo cho hệ sinh thái nếu điều này dẫn đến thay đổi trong khoá phân vùng CHIPS. Bạn có thể gửi thêm ý kiến phản hồi về vấn đề này tại đây. |
| Cookie được phân vùng | Bản nháp Clear-Site-Data cho phép xoá không chính xác ngoài phân vùng của trang web phát hành, trái ngược với các cuộc thảo luận trước đó được tham chiếu tại đây. | Đây là lỗi trong tài liệu quy cách tiêu chuẩn và chúng tôi dự định sẽ sớm khắc phục. Hành vi chính xác được chỉ định trong phần này của nội dung giải thích và phù hợp với hành vi của các trình duyệt khác trên kho lưu trữ nội dung giải thích về việc phân vùng bộ nhớ. Cách triển khai của Chrome đã hoạt động chính xác. |
FedCM
Chúng tôi không nhận được ý kiến phản hồi nào trong quý này.
Chống hành vi gian lận và nội dung rác
Private State Tokens API (và các API khác)
Chúng tôi không nhận được ý kiến phản hồi nào trong quý này.