Báo cáo hằng quý vào quý 3 năm 2022 tóm tắt những ý kiến phản hồi về hệ sinh thái nhận được liên quan đến các đề xuất của Hộp cát về quyền riêng tư và phản hồi của Chrome.
Theo cam kết 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 liên quan đến 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 ý 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 ở: Vấn đề trên 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 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 khám phá các 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. Bạn có thể làm việc này 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 thứ tự số lượng giảm dần. Chúng tôi xác định chủ đề phản hồi thường gặp 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 được gửi đến các nhóm nội bộ và biểu mẫu công khai của Google.
Cụ thể hơn, biên bản cuộc họp cho các cuộc họp cơ quan tiêu chuẩn web đã được xem xét và để lấy ý kiến phản hồi trực tiếp, chúng tôi đã xem xét hồ sơ của Google về các cuộc họp 1:1 với các bên liên quan, email mà từng kỹ sư nhận được, danh sách gửi thư của API và biểu mẫu phản hồi công khai. Sau đó, Google đã phối hợp với những nhóm có tham gia vào những hoạt động tiếp cận khác nhau này để xác định mức độ phổ biến tương đối của các chủ đề xuất hiện trong từng API.
Nội dung giải thích về các câu trả lời của Chrome cho ý kiến phản hồi được phát triển từ các Câu hỏi thường gặp đã phát hành, câu trả lời thực tế cho những vấn đề do các bên liên quan nêu ra và xác định vị trí cụ thể cho mục đích của bài tập báo cáo công khai này. Phản ánh trọng tâm hiện tại của quá trình phát triển và kiểm thử, cụ thể là các câu hỏi và ý kiến phản hồi đã nhận được về API Chủ đề, API Fledge và Báo cáo phân bổ.
Phản hồi nhận được sau khi kết thúc kỳ báo cáo hiện tại có thể chưa có phản hồi của Chrome được xem xét.
Bảng chú giải thuật ngữ từ 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
- IDP (nhà cung cấp danh tính)
- 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 độc lập
- 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 ý ứng dụng tác nhân người dùng
- W3C
- Tập đoàn World Wide Web
- BÌNH LUẬN
- Tình trạng mù IP có chủ ý
Ý 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 |
| (Cũng được báo cáo vào Quý 2)
Tính hữu ích cho nhiều kiểu bên liên quan |
Các mối lo ngại về việc công nghệ Hộp cát về quyền riêng tư ưu tiên các nhà phát triển lớn hơn và các trang web đặc thù (nhỏ hơn) đó đóng góp nhiều hơn so với các trang web chung (lớn hơn). | Thông tin cập nhật về quý 3:
Google đã cam kết với CMA để thiết kế và triển khai các đề xuất trong khuôn khổ Hộp cát về quyền riêng tư sao cho không bóp méo sự cạnh tranh bằng cách tự ưu tiên hoạt động kinh doanh của chính Google, đồng thời cân nhắc đến tác động đến sự cạnh tranh trong ngành quảng cáo kỹ thuật số, cũng như đến nhà xuất bản và nhà quảng cáo, bất kể quy mô của họ. Chúng tôi sẽ tiếp tục phối hợp chặt chẽ với CMA để đảm bảo công việc của chúng tôi tuân thủ các cam kết này. Khi thử nghiệm Hộp cát về quyền riêng tư, một trong những câu hỏi chính mà chúng tôi sẽ đánh giá là hiệu suất của các công nghệ mới đối với nhiều kiểu bên liên quan. Ý kiến phản hồi rất quan trọng về mặt này, đặc biệt là những ý kiến phản hồi cụ thể và hữu ích có thể giúp chúng tôi cải thiện hơn nữa thiết kế kỹ thuật. Chúng tôi đã hợp tác với CMA để phát triển phương pháp thử nghiệm định lượng và hỗ trợ CMA xuất bản một ghi chú về thiết kế thử nghiệm để cung cấp thêm thông tin cho những người tham gia thị trường và có cơ hội nhận xét về các phương pháp đề xuất. |
| (Cũng được báo cáo vào Quý 2)
Yêu cầu về tài liệu |
Yêu cầu thêm tài nguyên hướng dẫn chi tiết về cách quản lý hoạt động kiểm thử, phân tích và triển khai | Thông tin cập nhật về quý 3:
Chúng tôi rất trân trọng việc các nhà phát triển thấy tài liệu hiện tại của chúng tôi hữu ích và cam kết cung cấp thêm tài liệu trong những tuần và tháng tới để họ có thể tiếp tục tìm hiểu xem công nghệ mới có thể mang lại lợi ích gì cho họ. Chúng tôi cũng tổ chức các phiên trong giờ hỗ trợ công khai dành cho nhà phát triển để chia sẻ các phương pháp hay nhất và bản minh hoạ, cùng với các phiên hỏi và đáp với các trưởng nhóm về sản phẩm và kỹ thuật để có thể thảo luận/đặt câu hỏi trực tiếp. |
| Hỗ trợ trên nhiều trình duyệt | Các nhà cung cấp trình duyệt khác đang sử dụng API Hộp cát về quyền riêng tư. | Các nhà cung cấp trình duyệt khác (như Apple, Mozilla và Microsoft) là những người tích cực tham gia các diễn đàn công khai, nơi thảo luận về các nguyên tắc về quyền riêng tư và phương pháp tiếp cận dựa trên trình duyệt. Chúng tôi được khuyến khích bằng cách thảo luận cộng tác trong các diễn đàn như cuộc họp TPAC thường niên W3C gần đây và các diễn đàn W3C PATCG đang diễn ra, nơi chúng tôi thấy có dấu hiệu hội tụ. |
| Sự khác biệt về nền tảng | Yêu cầu điều chỉnh nhiều nhất có thể các bộ tính năng trên web và Android để giảm bớt tài nguyên cần thiết cho quá trình chuyển đổi. | Chúng tôi đang nỗ lực điều chỉnh phương pháp tiếp cận của mình trên Chrome và Android để tránh gây nhầm lẫn/phân mảnh trong toàn ngành. Bất kỳ khác biệt nào trong phương pháp tiếp cận của chúng tôi phần lớn sẽ là do những khác biệt kỹ thuật cần thiết giữa nền tảng web và ứng dụng dành cho thiết bị di động mà nhà phát triển đã tính đến. |
| Tài nguyên để kiểm thử API Hộp cát về quyền riêng tư | Khó khăn trong việc phân bổ đủ
tài nguyên để thử nghiệm API Hộp cát về quyền riêng tư trước những khó khăn hiện tại về kinh tế. |
Google liên tục cải thiện tài liệu và dịch vụ hỗ trợ dành cho người kiểm thử để đơn giản hoá và hỗ trợ quá trình sử dụng API. Những nỗ lực này bao gồm: danh sách gửi thư dành riêng cho API, giờ làm việc mở và nội dung cập nhật liên tục trên developers.chrome.com. |
| Tín hiệu chọn không tham gia Sandbox API | Yêu cầu cung cấp tín hiệu "người dùng đã chọn không sử dụng API hộp cát" – loại công nghệ quảng cáo và trang web có thể sử dụng. | Chúng tôi đã từng chứng kiến nhiều trường hợp trong đó các trang web phản ứng với các lựa chọn của người dùng, chẳng hạn như "tắt cookie của bên thứ ba" bằng cách thúc ép người dùng thay đổi chế độ cài đặt của họ, đôi khi bao gồm cả việc chặn quyền truy cập vào trang web trừ phi họ làm vậy. Tín hiệu từ chối cũng có thể được dùng làm tín hiệu bổ sung để tạo vân tay số. Tại thời điểm này, Google không có ý định cung cấp tín hiệu từ chối |
| (Cũng được báo cáo vào Quý 2)
Tiến trình rõ ràng hơn |
Lịch phát hành rõ ràng hơn, chi tiết hơn | Thông tin cập nhật về quý 3:
Như đã giải thích trong phần Các thay đổi để trả lời ý kiến phản hồi bên dưới, Google đã cập nhật tiến trình của Hộp cát về quyền riêng tư vào tháng 7, nhằm giúp thị trường có thêm thời gian cho việc thử nghiệm sơ bộ và đưa ra ý kiến phản hồi, cũng như có thêm thời gian để kiểm tra sau khi API Hộp cát về quyền riêng tư được triển khai đầy đủ trước khi cookie của bên thứ ba ngừng hoạt động. |
| (Cũng được báo cáo vào Quý 2)
Tiến trình ngừng sử dụng cookie của bên thứ ba |
Yêu cầu để tránh bị chậm trễ thêm cho việc ngừng sử dụng cookie của bên thứ ba | Thông tin cập nhật về quý 3:
Vào tháng 7, Chrome đã thông báo tiến trình mới cho việc ngừng sử dụng cookie của bên thứ ba, phản ánh cam kết của chúng tôi về hành động có trách nhiệm dựa trên sự phức tạp của công nghệ và tầm quan trọng của công nghệ đối với hệ sinh thái. Trước khi có sự thay đổi này, chúng tôi đã xem xét ý kiến phản hồi của các cơ quan quản lý và ngành quảng cáo và chúng tôi sẽ tiếp tục hợp tác chặt chẽ với tất cả các bên liên quan. |
| Cookie của bên thứ nhất | Có phải các hạn chế đối với cookie của bên thứ nhất cũng sẽ được đề xuất không? Nếu có, người dùng lo ngại về tính ổn định lâu dài, rủi ro từ những thay đổi không thể đoán trước của trình duyệt, và do đó lãng phí nỗ lực kỹ thuật. | Chúng tôi chưa xem xét bất kỳ quy định hạn chế nào liên quan đến cookie của bên thứ nhất. Hộp cát về quyền riêng tư tập trung vào việc ngừng sử dụng cookie của bên thứ ba. |
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 |
| (Cũng được báo cáo vào Quý 2)
Tính hữu ích cho nhiều kiểu bên liên quan |
Người ta đã lo ngại về tính hữu ích của các trang web, tuỳ thuộc vào mức độ lưu lượng truy cập hoặc mức độ chuyên biệt của nội dung. | Thông tin cập nhật về quý 3:
Bạn sẽ khám phá tính hữu ích của API thông qua việc kiểm thử. Theo yêu cầu trong đoạn 17.c.ii của Cam kết, Google sẽ chia sẻ kết quả của các hoạt động kiểm tra đó với CMA. Chrome dự kiến cách phân loại và các thông số khác sẽ phát triển dựa trên kết quả thử nghiệm. Quá trình phát triển của cách phân loại hoặc các thông số có thể không đòi hỏi những thay đổi không tương thích ngược. Ngoài ra, Chrome dự kiến ý kiến phản hồi sẽ tiếp tục ảnh hưởng đến sự phát triển của Topics API sau khi cookie của bên thứ ba không được dùng nữa. |
| Quyền riêng tư/Chính sách | Yêu cầu xoá yêu cầu lọc theo chủ đề cho mỗi người gọi. | Dựa trên ý kiến phản hồi của KOF về quyền riêng tư, chuyên gia bảo mật, nhóm quyền kỹ thuật số và những người khác trong hệ sinh thái, Chrome đã chọn thiết kế này nhằm chỉ cấp quyền truy cập vào thông tin cho những người có quyền truy cập đó. Lý do bao gồm nhưng không giới hạn ở việc hạn chế tình trạng rò rỉ dữ liệu nhiều phía gia tăng; đảm bảo tính minh bạch và khả năng giải thích; áp dụng phương pháp dễ triển khai và mô tả; và hạn chế rủi ro tạo vân tay số. Những nhà xuất bản và bên thứ ba nhận được Chủ đề có thể tự quyết định thông tin họ sẽ chia sẻ với các bên trên trang web của họ. Nếu các bên thứ ba chia sẻ thông tin này, thì Chrome đặc biệt khuyến khích họ minh bạch với người dùng về những chia sẻ đó, đồng thời cung cấp cho họ các quyền kiểm soát. |
| Trang web bị phân loại sai | Các trang web bị phân loại sai chủ đề, điều này có thể dẫn đến việc nhắm mục tiêu quảng cáo không chính xác. | Các trang web được phân loại bằng cách kết hợp một danh sách ghi đè do con người chọn lọc, chứa các trang web phổ biến nhất và mô hình học máy trên thiết bị. Chrome tiếp tục đánh giá các lựa chọn để trang web đóng góp vào việc phân loại Chủ đề. Bạn phải cân nhắc đến mọi rủi ro về quyền riêng tư và việc sử dụng sai mục đích đối với mọi cải tiến về tiện ích. Ví dụ: một số rủi ro bao gồm:
Người dùng có thể kiểm tra các thành phần này bằng công cụ có sẵn qua chrome://topics-internals hoặc colab này. Qua thử nghiệm, chúng tôi hy vọng khả năng phân loại sẽ cải thiện theo thời gian. Đồng thời, chúng tôi hoan nghênh ý kiến phản hồi về ví dụ về các trang web có thể bị phân loại sai. |
| Yêu cầu về quyền truy cập | Yêu cầu hiện tại về Chủ đề đối với thực thể DOM trên trang dưới dạng tập lệnh hoặc iframe để có quyền truy cập có thể dẫn đến những hành vi không mong muốn của người chơi trong hệ sinh thái quảng cáo. | Chúng tôi đã hợp nhất một thay đổi trong phần giải thích trên GitHub. Chúng tôi dự định hỗ trợ Chủ đề trong tiêu đề HTTP. |
| Phân loại chủ đề không đủ chi tiết | Cách phân loại chủ đề hiện tại quá rộng và không bao gồm những chủ đề chi tiết hơn, chẳng hạn như chủ đề theo khu vực. | Việc cải tiến cách phân loại là một nỗ lực không ngừng và chúng tôi hy vọng cách phân loại này sẽ phát triển cùng với việc thử nghiệm và cung cấp thông tin đầu vào trong hệ sinh thái.
Chúng tôi đang tích cực tìm kiếm ý kiến phản hồi về cách phân loại hữu ích nhất cho hệ sinh thái. Khi đánh giá xem nên mở rộng số lượng chủ đề hay đưa vào các chủ đề chi tiết hơn, bạn nên cân nhắc một số vấn đề như 1) các hệ quả về quyền riêng tư tiềm ẩn (ví dụ: nhiều chủ đề hơn có thể gây ra rủi ro về vân tay số) và 2) khả năng truy xuất các chủ đề đã ghi nhận trước đây (ví dụ: khi có nhiều chủ đề hơn, công nghệ quảng cáo có thể đã nhìn thấy chủ đề được chọn trước đó). Mở rộng phạm vi số 2, Google tìm cách tối đa hoá khả năng truy xuất các chủ đề đã quan sát được trước đó của người gọi theo yêu cầu lọc hiện tại, với mục tiêu đạt được cả sự hữu ích và quyền riêng tư. |
| Giới hạn số chủ đề | 3 chủ đề trên mỗi trang web là quá ít thông tin để nhà quảng cáo phân phát quảng cáo. | Phản hồi từ hệ sinh thái, đặc biệt là kết quả kiểm tra từ Bản dùng thử theo nguyên gốc, sẽ tiếp tục tác động đến sự phát triển của API. Xin lưu ý rằng Chủ đề sẽ bổ sung các tín hiệu khác (như bối cảnh) để giúp tìm thấy quảng cáo thích hợp cho khách truy cập. Vì vậy, nhà quảng cáo có thể cung cấp thêm thông tin ngoài các chủ đề. |
| (Cũng được báo cáo vào Quý 2)
Kiểm soát và an toàn cho người dùng |
Một số chủ đề có thể là proxy cho các nhóm nhạy cảm và người dùng cần có nhiều quyền kiểm soát hơn để ngăn chặn kết quả tiêu cực. | Thông tin cập nhật về quý 3:
Chủ đề là một bước tiến đáng kể trong việc đảm bảo tính minh bạch và quyền kiểm soát của người dùng. Người dùng sẽ có thể chọn không nhận chủ đề, xem xét các chủ đề đã được chỉ định cho họ, xoá chủ đề và tìm hiểu công ty nào đang tương tác với chủ đề của mình trên một trang nhất định. Ngoài ra, người dùng cũng có thể xoá Chủ đề bằng cách xoá nhật ký duyệt web nơi phát sinh chủ đề. Các chế độ kiểm soát này hiện được triển khai trên trình duyệt Chrome ở cấp thiết bị. Chúng tôi hoan nghênh việc tiếp tục thảo luận về các chế độ kiểm soát nâng cao hơn dành cho người dùng, chẳng hạn như những chế độ kiểm soát do nhà phát triển đề xuất. Tuy nhiên, chúng tôi cần đảm bảo rằng các tính năng bổ sung mới được điều chỉnh tốt để giải quyết những mối lo ngại được nêu và không dẫn đến việc thực hiện thay đổi từng phần. |
| Tác động đối với SEO | Các nhà xuất bản điều chỉnh tên máy chủ của trang web để phản ánh chính xác hơn Chủ đề có thể tác động tiêu cực đến SEO. | Bạn không nên thay đổi tên máy chủ chỉ vì Chủ đề cho các trang web. Đúng là một trang web có thể tác động đến chủ đề được chỉ định theo cách này. Tuy nhiên, lợi ích mà việc này đem lại cho nhà xuất bản là chưa rõ ràng nhất. Điều này sẽ làm giảm giá trị của Chủ đề đối với toàn bộ hệ sinh thái nếu các trang web cố gắng "đánh lừa" mô hình phân loại. Bài tập chủ đề cũng không cố định; chúng tôi hy vọng cách phân loại sẽ tiếp tục phát triển cùng với việc kiểm thử và nhập dữ liệu. Đối với thử nghiệm này, chúng tôi khuyến khích ý kiến phản hồi, bao gồm cả mọi ví dụ về trang web có thể bị phân loại sai. |
| Gian lận và sử dụng sai mục đích | Có cách để bên mua xác minh rằng chủ đề mà họ thấy thực sự là do trình duyệt tạo. | Chúng tôi đánh giá cao đề xuất hỗ trợ một cơ chế giúp người mua công nghệ quảng cáo xác minh các chủ đề mà người bán đã chuyển trong phiên đấu giá quảng cáo có lập trình. Chúng tôi khuyến khích hệ sinh thái đóng góp cho các cuộc thảo luận tích cực tại đây. Mặc dù hiện đang tập trung vào các cải tiến khác có mức độ ưu tiên cao hơn, nhưng chúng tôi nhận thấy rằng đây có thể là một điểm bổ sung quan trọng cho thiết kế này trong tương lai. |
| Gian lận và sử dụng sai mục đích | Cho phép đánh giá công khai các bên là người dùng hợp lệ dữ liệu Chủ đề, thông qua cùng hình thức đăng và đánh giá công khai mà nhóm bên thứ nhất sẽ phải tuân theo. | Chúng tôi trân trọng đề xuất này và đồng ý rằng trách nhiệm giải trình công khai là một công cụ quan trọng giúp đạt được các mục tiêu của Hộp cát về quyền riêng tư. Các lệnh gọi API Chủ đề vốn đã công khai, vì bất kỳ ai cũng có thể truy cập vào trang web và theo dõi các lệnh gọi của một miền đến API JavaScript. Do đó, các cá nhân và tổ chức có thể xem hoạt động liên quan và đánh giá những trang web đang sử dụng Chủ đề và cách thức sử dụng. Chúng tôi tin rằng đây là phương pháp phù hợp hơn so với việc đánh giá tính "tính hợp pháp" của một trang web trong chức năng của chính API Chủ đề. |
| Tác động đến tín hiệu của bên thứ nhất | Tín hiệu chủ đề có thể có giá trị cao, do đó sẽ giảm giá trị của các tín hiệu dựa trên mối quan tâm khác của bên thứ nhất. | Chúng tôi tin rằng quảng cáo dựa trên mối quan tâm là một trường hợp sử dụng quan trọng cho web, và Chủ đề được thiết kế để hỗ trợ trường hợp sử dụng đó. Như mô tả ở trên, các bên liên quan khác trong hệ sinh thái đã bày tỏ lo ngại rằng Chủ đề có thể không đủ hữu ích để mang lại giá trị. Trong mọi trường hợp, việc cải thiện cách phân loại luôn được thực hiện và chúng tôi hy vọng cách phân loại này sẽ phát triển cùng với việc thử nghiệm và cung cấp thông tin đầu vào trong hệ sinh thái. |
FLEDGE
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
| Phiên đấu giá FLEDGE | Cách SSP định dạng dữ liệu được gửi đến Google Ads để đặt giá thầu trong phiên đấu giá FLEDGE. | Các công ty tham gia thử nghiệm nên xuất bản tài liệu về kế hoạch thử nghiệm và làm việc với nhau khi thích hợp.
Chúng tôi đã hợp tác với CMA để phát triển phương pháp thử nghiệm định lượng và cũng ủng hộ CMA xuất bản một ghi chú về thiết kế thử nghiệm nhằm cung cấp thêm thông tin cho những người tham gia thị trường có ý định tham gia thử nghiệm và có cơ hội góp ý về các phương pháp đề xuất. Nhóm Ad Manager đã đăng tài liệu cho người bán quan tâm đến việc thử nghiệm FLEDGE với các nhà xuất bản sử dụng Ad Manager làm máy chủ quảng cáo tại đây. Thông tin kỹ thuật chi tiết bổ sung được nêu tại đây. |
| FLEDGE trong Khung bảo vệ lồng nhau | Khung bảo vệ cho phép kiểm thử ít hạn chế hơn, đồng thời hạn chế nhiều hơn trong một tương lai không xác định. Tiến trình không xác định này đặt ra thách thức đối với hệ sinh thái. | Hiện nay, các công ty có thể thử nghiệm FLEDGE với Khung bảo vệ. Để dễ dàng tham gia hơn, các công ty có thể chọn triển khai FLEDGE trước. Sau khi triển khai FLEDGE, họ có thể thử nghiệm Khung bảo vệ bằng thiết kế FLEDGE. |
| Chính sách xử lý dữ liệu | Chính sách xử lý dữ liệu cho nhóm mối quan tâm / FLEDGE là gì? | Trong thiết kế FLEDGE, tất cả dữ liệu được lưu trữ trong các nhóm mối quan tâm hoặc về đặc điểm của người dùng trong các nhóm mối quan tâm vẫn sẽ được lưu trữ trên thiết bị. Không có dữ liệu nào trong số này được gửi đến máy chủ của Google.
Một số biện pháp bảo vệ quyền riêng tư mà Chrome dự định cho FLEDGE có liên quan đến hoạt động tương tác với máy chủ k-anonymity do Google điều hành. Hoạt động tương tác đó đang được thiết kế cẩn thận để tránh việc chia sẻ thông tin về người dùng và diễn ra trong môi trường thực thi đáng tin cậy (TEE) nhằm đảm bảo tính đồng nhất về thông tin trong hệ sinh thái quảng cáo. \ Google đã cam kết với CMA để thiết kế và triển khai các đề xuất trong khuôn khổ Hộp cát về quyền riêng tư sao cho không bóp méo tính cạnh tranh bằng việc tự ưu tiên hoạt động kinh doanh của chính Google, đồng thời cân nhắc đến tác động đến sự cạnh tranh trong ngành quảng cáo kỹ thuật số cũng như tác động đến các nhà xuất bản và nhà quảng cáo. Chúng tôi sẽ tiếp tục phối hợp chặt chẽ với CMA để đảm bảo công việc của chúng tôi tuân thủ các cam kết này. |
| Chính sách về độ tuổi | Chrome đảm bảo rằng các đối tượng do FLEDGE tạo tuân thủ giới hạn về độ tuổi bằng cách nào? | Nhà xuất bản và nhà quảng cáo là những người phù hợp nhất để đánh giá xem đối tượng mà họ tạo bằng FLEDGE có tuân thủ luật hiện hành hay không. Để bảo vệ người dùng tốt hơn, API Hộp cát về quyền riêng tư sẽ không hoạt động cho bất kỳ người dùng nào đã đăng nhập vào Chrome nếu độ tuổi liên kết với tài khoản của họ nhỏ hơn 18 tuổi, ngay cả trong giai đoạn thử nghiệm. (Đối với người dùng đã đăng xuất, Chrome không thu thập các tín hiệu hồ sơ cho phép trình duyệt suy đoán độ tuổi của người dùng.) |
| Dịch vụ khoá/giá trị FLEDGE | Thông tin rõ ràng hơn về những dịch vụ Khoá/Giá trị FLEDGE cho phép, chẳng hạn như số lượng khoá và tần suất cập nhật các khoá. | Các công ty sử dụng FLEDGE có thể dùng số lượng khoá tối đa cho phép trong RAM. Để biết thêm thông tin, vui lòng xem phần giải thích tại đây.
Chúng tôi đang tìm cách cung cấp một đường dẫn nhanh hơn để sửa đổi dữ liệu và hoan nghênh các đề xuất cho mọi yêu cầu. |
| Kiểm thử | Khó thử nghiệm FLEDGE với Google Ads | Hãy tham khảo tài liệu hướng dẫn làm quen của Google Ads để biết cách tốt nhất để tham gia và thử nghiệm trong bản dùng thử theo nguyên gốc. |
| API Dịch vụ đặt giá thầu và đấu giá | Google có định hướng như thế nào đối với API Dịch vụ đặt giá thầu và phiên đấu giá? Liệu quy tắc này sẽ được ưu tiên hơn hay thấp hơn FLEDGE của trình duyệt Chrome trong các phiên đấu giá thiết bị? | Chúng tôi vẫn cam kết thiết kế tính năng đặt giá thầu trên thiết bị FLEDGE hiện tại. Dịch vụ Đặt giá thầu và Phiên đấu giá đã được đề xuất để tìm hiểu các giải pháp khả thi nhằm hỗ trợ một số trường hợp sử dụng mà công suất tính toán hoặc tốc độ mạng của thiết bị có thể bị hạn chế. |
| Báo cáo tổng hợp | Yêu cầu hỗ trợ báo cáo tổng hợp dựa trên tất cả tín hiệu có sẵn để generateBid. | Chúng tôi dự định sẽ sớm chia sẻ công khai thêm về vấn đề này. |
| Quảng cáo theo bối cảnh | Phân phát quảng cáo theo bối cảnh bằng FLEDGE. | Chúng tôi đã cân nhắc lựa chọn này. Vì những lý do được giải thích trong cuộc thảo luận này, chúng tôi hiện không khuyến khích bạn sử dụng FLEDGE cho quảng cáo theo bối cảnh. |
| Thử nghiệm trong thực tế | Hướng dẫn về cách tách riêng FLEDGE với cookie của bên thứ ba để kiểm thử thực tế. | Chúng tôi đang nghiên cứu các cách cung cấp tập hợp thử nghiệm.
Chúng tôi đã hợp tác với CMA để phát triển phương pháp thử nghiệm định lượng và hỗ trợ CMA xuất bản một ghi chú về thiết kế thử nghiệm để cung cấp thêm thông tin cho những người tham gia thị trường và có cơ hội nhận xét về các phương pháp đề xuất. |
| Thử nghiệm FLEDGE và API Báo cáo phân bổ | Đâu là cách tốt nhất để triển khai API Báo cáo phân bổ với FLEDGE? Bạn nên tách riêng FLEDGE và Phân bổ hoặc thử nghiệm cùng nhau? | Cuối cùng, chúng tôi sẽ hỗ trợ thử nghiệm cả FLEDGE và API Báo cáo phân bổ dưới dạng giải pháp tích hợp. Tuy nhiên, các nhà phát triển nên thử nghiệm độc lập API Báo cáo phân bổ trước, rồi sau đó thử nghiệm FLEDGE khi quá trình tích hợp hoàn tất. |
| Chế độ hiển thị giá thầu | Yêu cầu làm rối mã nguồn giá thầu. | Bạn có thể đặt các điểm ngắt trong "generateBid()" hoặc "scoreAd()" để truy cập vào các giá trị giá thầu qua Công cụ cho nhà phát triển. Nhóm Chrome đã xem xét vectơ tấn công hẹp được nêu ra trong phản hồi này về FLEDGE. Tuy nhiên, các mô hình bảo mật và quyền riêng tư của Chrome coi người dùng là đáng tin cậy để làm bất cứ điều gì họ muốn nhờ thông tin trên thiết bị của riêng họ. Do đó, không có cách nào khả thi để ẩn dữ liệu giá thầu theo yêu cầu. |
| Yêu cầu về tài liệu | Tài liệu và ví dụ về cách kiểm thử trong một hệ sinh thái trực tiếp. | Chúng tôi rất trân trọng việc các nhà phát triển thấy tài liệu hiện tại của chúng tôi hữu ích và cam kết cung cấp thêm tài liệu trong những tuần và tháng tới để họ có thể tiếp tục tìm hiểu xem công nghệ mới có thể mang lại lợi ích gì cho họ.
Chúng tôi cũng tổ chức giờ hỗ trợ công khai dành cho nhà phát triển bên ngoài để chia sẻ các phương pháp hay nhất và bản minh hoạ, cùng với các phiên Hỏi và đáp với các trưởng nhóm về sản phẩm và kỹ thuật, qua đó có thể thảo luận/đặt câu hỏi trực tiếp. |
| API tổng hợp riêng tư | Bạn muốn yêu cầu thêm thông tin về API tổng hợp riêng tư? | Chúng tôi có thông tin giải thích công khai chứa những thông tin mới nhất mà chúng tôi có thể chia sẻ tại thời điểm này. Chúng tôi sẽ cung cấp thêm tài liệu khi API này được phát triển và xác định các trường hợp sử dụng. |
| Độ trễ dữ liệu | Việc truy xuất dữ liệu từ máy chủ Khoá/Giá trị FLEDGE có theo thời gian thực không? | Một chút tình trạng lỗi thời theo thứ tự phút, chứ không phải giờ có thể dự kiến trước khi dữ liệu cập nhật có thể được máy chủ trả về cho các truy vấn, như đã giải thích trong một vấn đề mở về GitHub. Chúng tôi cũng đang tìm ý kiến phản hồi của nhà phát triển. |
| Dịch vụ Đặt giá thầu và Phiên đấu giá | Giá thầu có bị ẩn đối với người dùng không nếu bạn sử dụng dịch vụ đặt giá thầu và phiên đấu giá (B&A)? | Đối với phương pháp phía máy chủ B&A, người dùng không thấy được giá thầu riêng vì yêu cầu giá thầu được thực hiện trực tiếp từ dịch vụ đấu giá SSP đến dịch vụ đấu giá DSP, do đó không còn xuất hiện trong trình duyệt nữa.
Tuy nhiên, trình duyệt sẽ vẫn thấy giá thầu giành chiến thắng (đã thảo luận chi tiết hơn ở trên về các yêu cầu làm rối mã nguồn giá thầu). |
| Dịch vụ Đặt giá thầu và Phiên đấu giá | Làm cách nào để tải các dịch vụ đặt giá thầu và phiên đấu giá cân bằng? | Hiện tại, chúng tôi chưa có hướng dẫn nào về việc cân bằng tải, nhưng đây là một vấn đề quan trọng xét theo cả hiệu suất và quyền riêng tư. Chúng tôi sẽ cung cấp thêm thông tin chi tiết trong tương lai. |
| Giới hạn đối với FLEDGE | Yêu cầu tăng giới hạn thời lượng joinAdinterestGroup từ 30 ngày lên 90 ngày. | Chúng tôi cho rằng khung thời gian giữ lại dữ liệu 30 ngày phù hợp với các API quảng cáo khác trên Hộp cát về quyền riêng tư, chẳng hạn như giới hạn 30 ngày trong Báo cáo phân bổ và thời hạn 3 tuần trong Chủ đề. Khung thời gian này giải quyết cả nhu cầu của công nghệ quảng cáo và kỳ vọng về quyền riêng tư của người dùng.
Tuy nhiên, chúng tôi rất mong nhận được thêm ý kiến phản hồi trong lúc tiếp tục thảo luận về vấn đề này tại đây. |
| Bộ nhớ dùng chung trong FLEDGE | Tôi có thể sử dụng API Bộ nhớ dùng chung trong FLEDGE không? | Chúng tôi dự định hỗ trợ API Bộ nhớ dùng chung trong FLEDGE trong tương lai và đang nỗ lực cung cấp tính năng này trong Bản dùng thử theo nguyên gốc sắp tới. |
| Kiểm soát tần suất theo lượt nhấp | Tôi có thể đặt giới hạn tần suất theo số lượt nhấp (không phải chiến thắng) trong FLEDGE không? | FLEDGE chỉ định rằng Khung bảo vệ có thể gọi navigation. Hiện tại, giải pháp này sẽ không dùng được cho việc giới hạn sau nhiều lượt nhấp. |
| FLEDGE trong Khung bảo vệ lồng ghép. | Không thể báo cáo lượt nhấp qua tính năng Báo cáo quảng cáo khung bảo vệ nếu lượt nhấp xảy ra trên Khung bảo vệ lồng ghép. | Chúng tôi đã xuất bản một đề xuất để khắc phục vấn đề này tại đây. |
| Đo lường | Cần hướng dẫn về cách thu thập dữ liệu độ trễ của bên đặt giá thầu trong phiên đấu giá FLEDGE. | Chúng tôi đang nỗ lực để sớm xuất bản tài liệu đo lường hiệu suất. |
| Báo cáo | Báo cáo FLEDGE sẽ được xử lý như thế nào? | Báo cáo FLEDGE về Chiến thắng, Kết quả phiên đấu giá, Sự kiện, ví dụ: lượt nhấp sẽ được cung cấp thông qua các API FLEDGE, chẳng hạn như reportResult(). Khi báo cáo về lượt chuyển đổi quảng cáo, việc tích hợp với API Báo cáo phân bổ sẽ độc lập với FLEDGE, nhưng hệ sinh thái vẫn đang thảo luận về các phương pháp khả thi.
Bạn cũng có thể sử dụng API tổng hợp riêng tư để báo cáo kết quả phiên đấu giá ngay trong các môi trường thực thi riêng biệt. Xem nội dung giải thích tại đây. |
| Quy mô nhóm đối tượng có cùng mối quan tâm | Có cách nào để công nghệ quảng cáo kiểm tra quy mô của một nhóm mối quan tâm (tức là số lượng người dùng trong nhóm) không? | Tư cách thành viên trong nhóm mối quan tâm được trình duyệt lưu trữ trên thiết bị của người dùng và không được chia sẻ với nhà cung cấp trình duyệt hay bất kỳ ai khác.
Tuy nhiên, trên lý thuyết, chủ sở hữu nhóm quan tâm có thể theo dõi mọi lệnh gọi đến navigation.joininterestgroup(...). Việc theo dõi cuộc gọi này không đảm bảo kích thước chính xác của một IG (vì người dùng có thể rời khỏi nhóm bất kỳ lúc nào), nhưng nó cung cấp cho chủ sở hữu giới hạn trên và kích thước gần đúng. |
| Hiệu suất | Mã Đặt giá thầu JS/WebAssembly có được biên dịch tại mọi phiên đấu giá không? | Mã đặt giá thầu JS/WebAssembly được biên dịch một lần trong mỗi phiên đấu giá. |
| Hiệu suất | Phạm vi của BiddingDurationMsec là gì? | BidDurationMsec bao gồm thời gian biên dịch tập lệnh. Dữ liệu này không bao gồm thời gian tải xuống, thời gian biên dịch wasm, thời gian mạng; thời gian tìm nạp từ máy chủ khoá-giá trị hoặc bất kỳ thông tin nào trước khi biên dịch JS. |
| Tuỳ chỉnh | Tôi có thể cập nhật adComponent để tuỳ chỉnh cho người dùng không? | adComponent có thể được cập nhật khi Phương thức gọi cập nhật Nhóm mối quan tâm khi gọi joininterestGroup hoặc khi Chrome thực hiện lệnh gọi tới DailyUpdateURL. Điều này cho phép phương thức gọi cập nhật adComponent dựa trên kiến thức của người dùng từ trang web hiện tại hoặc dựa trên thông tin k-anonymous tương ứng.Bạn có thể tìm thấy đề xuất ban đầu của turtledove cấp sản phẩm tại đây, trong đó bao gồm một số phân tích của RTB House về tác động đến các chỉ số cốt lõi cho trường hợp sử dụng đề xuất. |
| Nhóm đối tượng có cùng mối quan tâm | Chủ sở hữu nhóm mối quan tâm có thể xoá một số người dùng nhất định theo điều kiện không? | Tư cách thành viên trong nhóm mối quan tâm chỉ được lưu trữ trên trình duyệt của người dùng và chỉ có thể bị xoá ở phía người dùng (ví dụ: bằng cách xoá dữ liệu trang web).
Tuy nhiên, chủ sở hữu nhóm mối quan tâm có thể gọi navigation.LeaveAdinterestGroup() (với một số logic có điều kiện xung quanh) nếu người dùng quay lại trang thuộc quyền kiểm soát của chủ sở hữu nhóm mối quan tâm. |
| Hiệu suất | Làm cách nào để đo lường hiệu suất của generateBid? | Bạn có thể đo lường thời gian biên dịch và thực thi bằng BiddingDurationMsec. Bạn có thể đo lường thời gian tải xuống bằng tính năng chrome://net-export. Trong các phiên bản Chrome gần đây, thời gian biên dịch và thực thi sẽ hiển thị trong thẻ Hiệu suất công cụ cho nhà phát triển. |
| Tần suất cập nhật nhóm mối quan tâm | Tần suất cập nhật nhóm quan tâm từ các trình duyệt là bao nhiêu? | Đối với các nhóm mối quan tâm chưa được cập nhật trong 24 giờ qua, Chrome sẽ cố gắng cập nhật các nhóm đó khi navigation.updateAdinterestGroups() được gọi hoặc khi họ có cơ hội tham gia phiên đấu giá. Để biết thêm chi tiết, hãy xem nội dung giải thích tại đây. |
| Nhà cung cấp dịch vụ tổng hợp | Khi nào các nhà cung cấp dịch vụ đám mây khác được hỗ trợ trên Dịch vụ tổng hợp? | Hiện tại, chúng tôi chưa có thông tin cập nhật về thời gian cụ thể nhưng sẽ chia sẻ thêm thông tin khi có thông tin mới. Hiện tại, chỉ AWS đáp ứng được các yêu cầu về bảo mật của dịch vụ tổng hợp. |
| Tiến trình thử nghiệm FLEDGE | FLEDGE sẽ thử nghiệm trong bao lâu trong BYOS? Liệu có đủ thời gian để chuyển đổi từ mô hình BYOS sang mô hình dựa trên TEE không? | Để đảm bảo hệ sinh thái có đủ thời gian để thử nghiệm, chúng tôi dự kiến sẽ không yêu cầu sử dụng TEE vào một thời điểm nào đó sau khi cookie của bên thứ ba không được dùng nữa. Chúng tôi sẽ thông báo rõ ràng để nhà phát triển bắt đầu thử nghiệm và sử dụng trước khi quá trình chuyển đổi này diễn ra. Chúng tôi hiện chưa có thêm thông tin cập nhật nhưng sẽ chia sẻ thêm khi có thông tin mới. Vui lòng tìm thông tin mới nhất tại đây. |
| Hạn mức kích thước dữ liệu | Hạn mức kích thước dữ liệu cho wasm trong hàm đặt giá thầu là bao nhiêu. | Yêu cầu cập nhật nhóm mối quan tâm không được tạo ra một nhóm mối quan tâm vượt quá 50 kb, như đã thảo luận tại đây, nhưng giới hạn kích thước dữ liệu cho wasm chưa được xác định. Vì vậy, chúng tôi rất mong nhận được ý kiến đóng góp về chủ đề này. |
| Tín hiệu đấu giá | Google có xây dựng một cấu trúc dữ liệu chuẩn hoá cho phiên đấu giá không? | Trạng thái này chưa được xác định nhưng chúng tôi sẵn sàng tiếp nhận ý kiến phản hồi. |
| Truy vấn máy chủ công nghệ quảng cáo | Tôi có thể truy vấn dữ liệu máy chủ công nghệ quảng cáo theo thời gian thực từ máy chủ K/V không? | Không, máy chủ K/V chạy trong mô hình tin cậy thực thi "Không có mạng, quyền truy cập ổ đĩa, bộ tính giờ hoặc ghi nhật ký" để tránh rò rỉ dữ liệu người dùng. Vui lòng xem phần giải thích về mô hình tin cậy tại đây để biết thêm chi tiết. |
| Tần suất cập nhật adComponents | Hiện tại, người dùng không thể cập nhật trường adComponents (hiện chỉ có trong chế độ cài đặt IG) theo nhật ký duyệt web của người dùng | Hộp cát về quyền riêng tư hướng đến việc hỗ trợ các nhu cầu của hệ sinh thái web mà không cần theo dõi trên nhiều trang web, tức là ngăn quyền truy cập vào nhật ký duyệt web. Bạn nên sử dụng các lựa chọn thay thế như Chủ đề. |
| Kết quả đấu giá | Có cách nào để công nghệ quảng cáo biết tỷ lệ thắng phiên đấu giá không? | Kết quả phiên đấu giá được báo cáo bằng cách gọi hàm reportResult() và hàm reportWin() trong mã phiên đấu giá do người bán và người mua chiến thắng cung cấp tương ứng, do đó mỗi hàm đều có cơ hội thực hiện ghi nhật ký và báo cáo về kết quả của phiên đấu giá. |
| (Cũng được báo cáo vào Quý 2)
Hỗ trợ cho tiêu chí nhắm mục tiêu phủ định theo Nhóm mối quan tâm |
API hỗ trợ tính năng nhắm mục tiêu theo nhóm mối quan tâm phủ định: chỉ hiển thị quảng cáo khi người dùng không thuộc nhóm mối quan tâm nào. | Thông tin cập nhật về quý 3:
Chúng tôi đã chia sẻ một đề xuất mới và đang thu thập ý kiến phản hồi. |
Đ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 |
| Yêu cầu về OT | Chỉ xoá các quy tắc hạn chế về Chính sách quyền trong / cho thời gian chờ OT. | Vui lòng xem các thay đổi đã được công bố của chúng tôi đối với Chính sách về quyền trong quá trình thử nghiệm. Thay đổi này giải quyết mối lo ngại của các bên liên quan chính là việc cho phép các DSP thử nghiệm API trên số lượng iframe nhiều nguồn gốc cao hơn. Ban đầu, các DSP cần phải phối hợp với Nhà xuất bản/SSP nhằm đảm bảo bạn đã thiết lập chính sách quyền phù hợp để thử nghiệm API trên iframe nhiều nguồn gốc, nhưng với sự thay đổi này, DSP sẽ có thể gọi API theo mặc định và SSP/Nhà xuất bản có thể tắt API nếu cần trong Bản dùng thử theo nguyên gốc. |
| Tạp âm | Ý kiến phản hồi cho biết mức độ nhiễu quá cao và ảnh hưởng đến tính hữu ích của báo cáo. | Chúng tôi hoan nghênh ý kiến phản hồi về độ nhiễu. Chúng tôi sẽ sử dụng thông tin này để xác định cách đặt một số tham số liên quan đến độ nhiễu. Chúng tôi cũng đang tìm cách phát hành thêm tài nguyên, công cụ và tài liệu khác để giúp người kiểm thử giải quyết vấn đề này. |
| Lượt chuyển đổi trên nhiều miền | Cách theo dõi lượt chuyển đổi trên nhiều miền, chẳng hạn như với 2 đích đến trở lên? | Chúng tôi hiện đang thảo luận và thu thập ý kiến phản hồi về câu hỏi này. |
| Yêu cầu gỡ lỗi | Yêu cầu cho phép nhà phát triển kiểm tra ngân sách quyền riêng tư còn lại khi triển khai / thử nghiệm báo cáo tóm tắt? | Bạn có thể theo dõi yêu cầu về tính năng này tại đây. |
| Chính sách sử dụng API | Ý kiến phản hồi đề xuất các chính sách liên quan đến những người có thể sử dụng một API nhất định dựa trên các quy định hạn chế đối với những vấn đề như tạo vân tay số | Đây là một ý tưởng rất thú vị và chúng tôi rất vui được tương tác nhiều hơn với cả các nhà cung cấp trình duyệt khác và hệ sinh thái web rộng lớn hơn. |
| Chế độ cài đặt thời hạn trong báo cáo lượt chuyển đổi | Yêu cầu hỗ trợ bộ lọc báo cáo / thời gian hết hạn trong vòng dưới 24 giờ. | Thời gian hết hạn cấp giờ là một vấn đề đáng lo ngại về quyền riêng tư vì nó cho phép công nghệ quảng cáo biết chính xác người dùng truy cập vào trang web của nhà quảng cáo vào giờ nào. Việc hết hạn cấp ngày sẽ giúp công nghệ quảng cáo lọc ra các lượt hiển thị không hợp lệ mà không cần xác định giờ người dùng truy cập trang web. |
| Thời hạn của mã thông báo OT | Yêu cầu gia hạn hiệu lực của mã thông báo OT (OT) hiện có để giảm chi phí hoạt động. | Chúng tôi hiểu rằng cần phải gia hạn mã thông báo và chúng tôi đang nỗ lực để giúp nhà phát triển dễ dàng hơn cũng như đưa ra thông báo bổ sung. |
| Hỗ trợ theo khu vực | Dịch vụ tổng hợp hiện chỉ hỗ trợ một số khu vực. | Đây là hạn chế hiện tại đối với chương trình thử nghiệm. Chúng tôi hy vọng có thể hỗ trợ thêm các khu vực khác trong quá trình thử nghiệm, nhưng chưa có tiến trình rõ ràng cho việc này. |
| Độ trễ báo cáo ở cấp sự kiện | Độ trễ từ 2 đến 30 ngày đối với báo cáo ở cấp sự kiện có thể là quá dài đối với một số trường hợp sử dụng. | Chúng tôi đã chia sẻ một đề xuất tại đây để cho phép các công nghệ quảng cáo kiểm soát thời điểm gửi báo cáo cấp sự kiện khi hết hạn. Thời gian mặc định là 30 ngày, nhưng bạn có thể đặt thời gian ngắn hơn. |
| (Cũng được báo cáo vào Quý 2)
Mô hình phân bổ đa điểm |
Cho phép mô hình phân bổ đa điểm, chẳng hạn như trên nhiều thiết bị hoặc nhiều ứng dụng. | Thông tin cập nhật về quý 3:
Các phương pháp phân bổ đa điểm hiện tại yêu cầu liên kết quyết định các lượt hiển thị của người dùng (và do đó danh tính) trên các trang web khác nhau. Do đó, chức năng này ở dạng hiện tại không phù hợp với mục tiêu của Hộp cát về quyền riêng tư, vốn hướng đến việc hỗ trợ các trường hợp sử dụng quảng cáo chính mà không cần theo dõi trên nhiều trang web. |
| Tiến trình tích hợp FLEDGE và Báo cáo phân bổ | Tiến trình tích hợp FLEDGE và API Báo cáo phân bổ là gì? | Chúng tôi hiện chưa có thông tin cập nhật nhưng sẽ cung cấp thêm thông tin một cách công khai sau khi chúng tôi có thể cam kết về một lịch trình cụ thể. |
| Nhiều loại trình kích hoạt | Yêu cầu linh hoạt hơn khi đăng ký điều kiện kích hoạt. | Chúng tôi đã đề xuất một hệ thống loại bỏ trùng lặp cho API tổng hợp để giúp các công nghệ quảng cáo linh hoạt hơn trong việc kiểm soát các báo cáo cấp sự kiện và báo cáo tổng hợp. |
| Đo lường | Yêu cầu nhận dữ liệu đo lường về việc khoảng không quảng cáo có đang hoạt động hiệu quả hay không. | Chúng tôi rất trân trọng ý kiến phản hồi của bạn và đang tìm cách giúp bạn hiểu rõ hơn về(các) trường hợp sử dụng yêu cầu này. |
| Ngày hết hạn chuyển đổi | Yêu cầu hỗ trợ thời hạn chuyển đổi trên thẻ kích hoạt thay vì chỉ thẻ nguồn. | Chúng tôi rất trân trọng ý kiến phản hồi của bạn và đang tìm cách giúp bạn hiểu rõ hơn về(các) trường hợp sử dụng yêu cầu này. |
| Báo cáo theo lô | Yêu cầu đo lường bổ sung trong báo cáo hàng loạt. | Chúng tôi rất trân trọng ý kiến phản hồi trong quá trình cân nhắc về tác động đối với dịch vụ tổng hợp. Chúng tôi muốn biết suy nghĩ của công nghệ quảng cáo về việc báo cáo theo lô và tần suất dự kiến báo cáo, cũng như ý kiến phản hồi về sự thay đổi của chiến lược phân lô trong suốt cả năm. |
| Epsilon | Khi nào thì giá trị của epsilon sẽ được xác định? | Chúng tôi đang tích cực làm việc với những người thử nghiệm hệ sinh thái để hoàn thiện giá trị epsilon và cách triển khai giá trị đó trong GA. Giá trị này sẽ được hiển thị công khai, cùng với cuộc thảo luận dẫn đến quyết định về giá trị. Nếu bạn có ý kiến phản hồi, vui lòng đăng trong sự cố GH này. |
Giới hạn theo dõi bí mật
Giảm thiểu tác nhân người dùng
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
| Phần phụ thuộc triển khai | Xử lý các phần phụ thuộc của quá trình triển khai Tác nhân người dùng có cấu trúc (SUA). | Chúng tôi đã triển khai "Giai đoạn 4", tức là giảm số phiên bản nhỏ cho 100% người dùng Chrome ở các phiên bản 101 trở lên. Xem nội dung cập nhật tại đây. |
| Kiểm thử | Yêu cầu gia hạn thời gian dùng thử theo nguyên gốc Giảm tác nhân người dùng từ Meta. | Chúng tôi đã gia hạn Bản dùng thử theo nguyên gốc và đã có được quyền gỡ bỏ giới hạn lưu lượng truy cập cho phù hợp với các trang web lớn hơn. Giới hạn lưu lượng truy cập nới lỏng áp dụng cho mọi trang web, dù lớn hay nhỏ. |
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 |
| (Cũng được báo cáo vào Quý 2)
Vấn đề về Chống gian lận / Chống lạm dụng |
Một số tính năng có thể bị mất qua UA-CH: Trình theo dõi chuyển hướng lượt nhấp và các lượt nhấp gian lận. | Thông tin cập nhật về quý 3:
Chúng tôi đã nhận được phản hồi tích cực từ các công ty báo cáo rằng họ không thấy bất kỳ tác động bất lợi nào trong quy trình chống gian lận của họ (Kết quả tại đây và tại đây). Nhóm này đang tiếp tục điều tra các vấn đề tiềm ẩn này với các bên liên quan về việc đo lường và chống gian lận. |
| Chính sách về quyền | Quyền-Chính sách có được lưu vào bộ nhớ đệm không? | Quyền-Chính sách không được lưu vào bộ nhớ đệm như đã giải thích trong vấn đề này trên GitHub. |
Gnatcatcher (WIP)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
| Các trường hợp sử dụng vị trí địa lý | Gnatcatcher có thể ngăn những trường hợp sử dụng dữ liệu vị trí địa lý hợp pháp không hoạt động trong tương lai, chẳng hạn như cá nhân hoá nội dung dựa trên vị trí địa lý. | Chúng tôi đang làm việc với các bên liên quan để đảm bảo rằng Chrome tiếp tục hỗ trợ các trường hợp sử dụng địa chỉ IP hợp pháp. |
Củng cố ranh giới quyền riêng tư trên nhiều trang web
Nhóm bên thứ nhất
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
| Áp dụng chính sách | Quan ngại rằng FPS không nhất quán với quy định của cam kết CMA về "Luật bảo vệ dữ liệu hiện hành", trên cơ sở GDPR không áp dụng giới hạn về số lượng trang web trong một nhóm, trong khi FPS đặt ra giới hạn là 3. | Google đã cam kết với CMA để thiết kế và triển khai các đề xuất trong khuôn khổ Hộp cát về quyền riêng tư sao cho không bóp méo hoạt động cạnh tranh bằng cách tự ưu tiên hoạt động kinh doanh của chính Google, đồng thời cân nhắc đến tác động đến hoạt động cạnh tranh trong ngành quảng cáo kỹ thuật số, nhà xuất bản và nhà quảng cáo, cũng như tác động đến kết quả của quyền riêng tư và việc tuân thủ các nguyên tắc bảo vệ dữ liệu được nêu trong Luật bảo vệ dữ liệu hiện hành. Mối lo ngại này không tiết lộ bất kỳ sự không tương thích nào với GDPR. Chúng tôi sẽ tiếp tục phối hợp chặt chẽ với CMA để đảm bảo công việc của chúng tôi tuân thủ các cam kết này. Bạn có thể xem thêm thông tin chi tiết trong phần "Thay đổi để phản hồi" bên dưới. |
| Tài liệu | Yêu cầu cung cấp thêm ví dụ và cập nhật nội dung giải thích hiện có. | Các ví dụ trong phần giải thích của chúng tôi đang được xem xét và sẽ làm rõ hoặc xoá mọi ví dụ nếu cần. |
| Chia sẻ lựa chọn ưu tiên | Đề xuất đưa ra lựa chọn ưu tiên trong cùng một nhóm bên. | Chúng tôi hoan nghênh ý kiến phản hồi và tích cực thảo luận về ý tưởng này tại đây. |
| Biện pháp thực thi | Quy trình thực thi minh bạch có nguy cơ bị đối tượng xấu lợi dụng. | Chúng tôi trân trọng ý kiến phản hồi và tích cực trao đổi với các bên liên quan trên GitHub (có cân nhắc những điểm nêu ra trong vấn đề này và tìm cách kết hợp các đề xuất được nêu trong vấn đề này) cũng như các diễn đàn khác để đánh giá rủi ro này và xác định các giải pháp giảm thiểu tiềm năng. |
| Quyền sở hữu chung | Đề xuất bản tuyên bố mà máy có thể đọc được về quyền sở hữu chung. | Chúng tôi hoan nghênh và khuyến khích ý kiến đóng góp về đề xuất của chúng tôi. |
| Quyền sở hữu miền con | Những miền con khác nhau có đơn vị kiểm soát dữ liệu khác nhau, chính sách quyền riêng tư khác nhau hoặc do các pháp nhân khác nhau điều hành có nên thuộc cùng một Nhóm bên thứ nhất không? | Dựa trên ý kiến phản hồi, chúng tôi dự định xoá trường hợp sử dụng eTLD phổ biến. |
| Giảm thiểu hành vi lạm dụng | Yêu cầu cung cấp thêm thông tin chi tiết về các biện pháp giảm thiểu hành vi lạm dụng. | Chúng tôi đang xem xét việc quản lý quy trình này và sẽ cung cấp thêm thông tin chi tiết trong những tháng tới. |
| Vectơ tấn công tiềm ẩn | Một nhóm lừa đảo có liên quan đến các trang dễ tìm thấy có thể được dùng để hướng lưu lượng truy cập đến các trang khác được trình bày độc lập theo cách lừa đảo. | Chúng tôi đang tích cực thu thập ý kiến đóng góp của công chúng và tìm ra các giải pháp có thể giải quyết vấn đề này. |
| Thiết lập phương thức xác thực | Xác thực tập hợp được thông qua các chính sách chung có sự đồng ý của người dùng. | Một số thành viên trong cộng đồng tiêu chuẩn web và hệ sinh thái lớn hơn cho rằng việc này là không khả thi. |
| Giới hạn miền | Yêu cầu mở rộng số lượng miền được liên kết. | Chúng tôi đang tích cực thảo luận về giới hạn miền trong FPS và rất mong nhận được thêm ý kiến phản hồi của cộng đồng về số lượng miền được liên kết mà họ yêu cầu cho các trường hợp sử dụng của họ. |
| Tương tác dịch vụ tập hợp con | Mối lo ngại về dịch vụ và hoạt động tương tác với tập hợp con có liên quan. | Chúng tôi rất trân trọng ý kiến phản hồi này và sẽ xem xét làm rõ hơn về quy cách trong tương lai. |
| (Cũng được báo cáo vào Quý 2)
Cải thiện quyền riêng tư |
Việc quá nhiều trang web trong cùng một nhóm có thể dẫn đến kết quả tương tự với cookie của bên thứ ba. | Thông tin cập nhật về quý 3:
Đề xuất mới nhất đề xuất giới hạn 3 miền cho tập hợp con "được liên kết" (không bao gồm ccTLD và miền dịch vụ). Chrome đang tích cực tham gia vào hệ sinh thái này để xác định xem giới hạn này có phù hợp hay không. |
| (Cũng được báo cáo vào Quý 2)
Yêu cầu phổ biến trong chính sách quyền riêng tư |
Không thể duy trì một chính sách quyền riêng tư chung trên tất cả các sản phẩm và khu vực tài phán cần phải nằm trong cùng một bộ chính sách đó. | Thông tin cập nhật về quý 3:
Không cần phải đưa một chính sách quyền riêng tư chung vào cùng một bộ chính sách đó nữa. |
API Khung bảo vệ
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
| Tại sao phải có một phần tử mới thay vì các thuộc tính trên iframe? | Câu hỏi về đề xuất Khung có giới hạn thay vì các đề xuất iFrame hiện có. | Chúng tôi hoan nghênh các ý kiến phản hồi và sẵn sàng lắng nghe các ý kiến về cách quy tụ tình trạng hiện tại của vấn đề như đã thảo luận tại đây. |
| Người quan sát giao điểm trong khung bảo vệ | Câu hỏi liên quan đến khả năng xem của thông tin bên trong Khung được bảo vệ. | Nội dung này đang trong quá trình thảo luận và nhận xét trong tài liệu này và trên GitHub. Chúng tôi hoan nghênh các đối tác chia sẻ các trường hợp sử dụng với chúng tôi để hiểu rõ hơn về cách hỗ trợ. |
| Hỗ trợ khoảng không quảng cáo video và khoảng không quảng cáo gốc | Khung bảo vệ có hỗ trợ khoảng không quảng cáo video và khoảng không quảng cáo gốc không? | Về khả năng phát video, Khung bảo vệ không khác với iframe và đó là lý do tại sao khung này không được nêu rõ ràng trong bất kỳ tài liệu công khai nào. Nếu thấy bất kỳ vấn đề nào với quảng cáo dạng video, bạn nên gửi phản hồi để chúng tôi có thể điều tra thêm. |
| Gói web | Trong tương lai, việc phân phát / hiển thị quảng cáo theo Gói web có trở thành một yêu cầu đối với Khung bảo vệ x FLEDGE không? | Mục tiêu dài hạn là hỗ trợ Gói web để hiển thị nội dung quảng cáo trong khung được bảo vệ. Tuy nhiên, việc triển khai FLEDGE hiện tại không hỗ trợ việc này, đồng thời yêu cầu hiển thị tài nguyên HTML được truy xuất từ displayUrl. |
| Các thứ nguyên nội dung | Yêu cầu RenderScript_url để hỗ trợ macro cho chiều cao và chiều rộng vùng để chúng tôi có thể phản hồi bằng mẫu quảng cáo có kích thước phù hợp | Vấn đề này sẽ được thảo luận tích cự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 |
| Tích hợp FLEDGE | Bộ nhớ dùng chung và FLEDGE sẽ được tích hợp như thế nào? | Mặc dù hiện không theo đuổi ý tưởng này, nhưng chúng tôi vẫn muốn tìm hiểu ý tưởng này xem có thể đảm bảo được các biện pháp bảo vệ quyền riêng tư hay không. Các bên quan tâm nên gửi đề xuất cho các trường hợp sử dụng tiềm năng mà đề xuất này có thể hỗ trợ trong kho lưu trữ GitHub của Bộ nhớ dùng chung hoặc kho lưu trữ GitHub FLEDGE. . |
| Giữ lại dữ liệu | Việc xoá bộ nhớ dùng chung sẽ giảm tiện ích. Việc kéo dài khoảng thời gian lưu giữ hoặc khả năng xóa khóa/giá trị riêng lẻ có được xem là lựa chọn thay thế không? | Chúng tôi luôn tìm cách cân bằng giữa quyền riêng tư của người dùng và sự đánh đổi về tiện ích. Chúng tôi sẵn sàng lắng nghe ý kiến phản hồi về việc điều chỉnh, đồng thời khuyến khích các đối tác cung cấp thêm ý kiến phản hồi và thông tin chi tiết khi thử nghiệm bộ nhớ dùng chung. |
| Tín hiệu tiêu cực | Tín hiệu tiêu cực từ Mozilla liên quan đến đề xuất Bộ nhớ dùng chung. | Chúng tôi cảm ơn Mozilla đã xem xét cẩn thận đề xuất của chúng tôi. Chúng tôi dự định sẽ trả lời ý kiến phản hồi của họ trong thời gian sắp tới. |
KHỐI
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
| Yêu cầu được phân vùng | Thêm yêu cầu về hành vi rõ ràng cho thuộc tính "Đã phân vùng" trên cookie của bên thứ nhất. | Chúng tôi đã thảo luận về vấn đề này qua một cuộc gọi về PrivacyCG và đã tiếp tục trao đổi về vấn đề trên GitHub . Chúng tôi đang tiếp tục làm việc với các trình duyệt, nhà phát triển và cộng đồng quyền riêng tư để điều chỉnh hành vi cho phù hợp và nêu rõ hành vi. |
| Nhúng đã xác thực | KHỐI có thể ảnh hưởng đến quy trình đăng nhập SSO hiện tại do việc phân vùng khác nhau ảnh hưởng đến các lượt nhúng đã xác thực. | Chúng tôi đã biết về trường hợp sử dụng nội dung nhúng đã được xác thực và đang nỗ lực tìm giải pháp. |
| Giới hạn phân vùng cookie | Lo ngại rằng giới hạn 10 cookie hiện tại có thể không đủ cho một số trường hợp sử dụng nhất định. | Chúng tôi sẽ chuyển từ giới hạn số lượng cookie sang giới hạn bộ nhớ 12 kb. Nhờ đó, chúng tôi có thể giải quyết các mối lo ngại về hạn mức cookie mà vẫn đảm bảo hiệu suất và mức sử dụng bộ nhớ của trình duyệt không bị ảnh hưởng xấu. |
| Tiến trình dùng thử theo nguyên gốc | Mở rộng OT sẽ xoá yêu cầu giới hạn tên máy chủ. | Chúng tôi đã kéo dài thời hạn dùng thử theo nguyên gốc sau khi nhận được ý kiến phản hồi của hệ sinh thái. |
| Giới hạn thử nghiệm trong Chrome | Có thể kiểm tra CHIPS trong Firefox do giới hạn hiện tại trong Chrome. | Cách triển khai Firefox gần đúng, Chrome có giới hạn cookie thấp hơn và CHIPS là cơ chế chọn tham gia, nhưng Firefox được phân vùng theo mặc định. |
| (Cũng được báo cáo vào Quý 2)
Nhúng đã xác thực |
Trạng thái đăng nhập có được giữ nguyên bằng CHIPS không? | Thông tin cập nhật về quý 3:
Trạng thái đã đăng nhập hiện không được giữ nguyên nhưng không phải là trường hợp sử dụng dự kiến của CHIPS. Chúng tôi đã biết về trường hợp sử dụng nội dung nhúng đã được xác thực và đang nỗ lực tìm giải pháp. |
FedCM
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
| (Cũng được báo cáo vào Quý 2)
Vectơ tấn công tiềm ẩn |
Các vectơ tấn công tiềm ẩn thông qua việc trang trí đường liên kết và các cuộc tấn công theo thời gian. | Thông tin cập nhật về quý 3:
Chúng tôi đã hợp tác với Mozilla để nắm được thông tin chung về cách giải quyết vấn đề tấn công theo thời gian. Thông tin chi tiết có tại đây. Chúng tôi hiện đang thử nghiệm thay đổi về mặt cấu trúc này và dự kiến sẽ chạy các thử nghiệm trong vài quý tới. |
| Nhà cung cấp danh tính | Trình chọn tài khoản: nhà cung cấp danh tính duy nhất. Yêu cầu cho phép nhiều nhà cung cấp danh tính. | Chúng tôi đã làm việc với các nhà cung cấp Trình duyệt và CG của FedID để tìm ra cách cho phép nhiều nhà cung cấp danh tính và đã tạo ra một công thức có vẻ đáng để thử. Nội dung mô tả về đề xuất này được trình bày tại đây. Chúng tôi dự kiến sẽ phát triển các nguyên mẫu và chạy thử nghiệm trong vài quý tới. |
| Các vấn đề đã biết với Liên kết | Yêu cầu liệt kê các trường hợp mà liên kết có thể gặp sự cố với việc ngừng sử dụng cookie của bên thứ ba. | CG của FedID có một mục công việc liệt kê những cách thức vi phạm liên kết tại đây và tại đây. Họ cũng đang xây dựng một ma trận quyết định để ánh xạ sự cố với các API Nền tảng web tại đây. |
| Tham số số chỉ dùng một lần | Tham số Số chỉ dùng một lần có ảnh hưởng đến quy trình đăng nhập không? | Hoạt động này có thể được xem là hoạt động theo dõi trên nhiều trang web, nhưng chúng tôi vẫn đang thu thập thông tin đầu vào và phân tích cách xử lý các trường hợp như vậy. |
| Sự đồng ý của người dùng | Liên kết các bên phụ thuộc (RP) và sự đồng ý của người dùng đối với từng nguồn gốc. | Thông số kỹ thuật này không thể kiểm soát cách các nguồn gốc trong cùng một miền chia sẻ cookie. Thông số kỹ thuật cho phép idtoken từ nguồn gốc IDP đến nguồn gốc RP, nhưng RP có quyền chọn lưu trữ trạng thái đăng nhập của người dùng trong cookie được khoá theo nguồn gốc đó hay cookie được chia sẻ với nguồn gốc trong cùng một miền. |
| Tài khoản IDP
khả năng có thể di chuyển |
Lựa chọn dành cho người dùng để di chuyển nhà cung cấp danh tính (IDP) nếu họ chọn khi chuyển giữa hai nhà cung cấp danh tính (IDP). | Có vẻ như người dùng cần làm trực tiếp trên trang đăng ký của nhà cung cấp danh tính (IDP) mới mà họ chọn, chứ không thông qua API FedCM. |
| Xoá tài khoản | Sau khi nhà cung cấp danh tính (IDP) thu hồi quyết định xoá tài khoản, | Yêu cầu về tính năng này đang được xử lý để chúng tôi cung cấp dữ liệu đầu vào và đang được điều tra. |
| Xác nhận quyền sở hữu giao diện người dùng | Tuyên bố về các khía cạnh giao diện dành riêng cho trình duyệt. | Hãy xem yêu cầu kéo để giải quyết vấn đề này. |
| Kiểm tra người được giới thiệu IDP | Nhà cung cấp danh tính (IDP) kiểm tra đường liên kết giới thiệu của RP. | Thêm bước kiểm tra liên kết giới thiệu IDP bắt buộc vào phần đặc tả. Xem yêu cầu lấy dữ liệu. |
| Quy trình đăng nhập | Yêu cầu tuỳ chỉnh quy trình đăng nhập dựa trên lựa chọn ưu tiên của bên bị hạn chế. | Chúng tôi hoan nghênh ý tưởng này và tích cực thảo luận về ý tưởng này. |
Chống nội dung rác và lừa đảo
API Mã thông báo tin cậy
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
| Gian lận và sử dụng sai mục đích | Các công cụ nhằm đảm bảo rằng bot không lừa nhà phát hành cung cấp mã thông báo, bot không tiếp quản mã thông báo được cấp cho người dùng thực và để ngăn bot phát hành mã thông báo độc hại? | Mặc dù bot có thể nhận được mã thông báo từ công ty phát hành, nhưng nhà phát hành nên đặt giới hạn về tần suất phát hành mã thông báo cũng như các phương pháp hiệu quả để phát hành mã thông báo và cập nhật logic phát hành vì những kẻ xấu muốn né tránh chúng. Các nhà phát hành không có đủ logic trong việc cấp mã thông báo có thể sẽ trở nên ít được tin cậy hơn trong hệ sinh thái vì các trang web sẽ ưu tiên phụ thuộc vào những nhà phát hành mạnh mẽ hơn. |
| Gian lận và sử dụng sai mục đích | Có cách nào để người sử dụng Mã thông báo tin cậy có thể chỉ định rằng họ sẽ chỉ chấp nhận Mã thông báo tin cậy từ một số thực thể không? | Có, điều này là có thể. Phần Sử dụng mã thông báo tin cậy trong phần giải thích sẽ mô tả cách hoạt động của quá trình này. |
| Gian lận và sử dụng sai mục đích | Có cách nào để nhà phát hành Mã thông báo tin cậy xác định danh sách người sử dụng và không cho phép người khác sử dụng mã thông báo không? | Hiện tại chưa có, nhưng nhóm đang điều tra trường hợp sử dụng này. |
| Lịch trình | Khi nào Trust Token API được cung cấp rộng rãi? | Ngay khi có thể cam kết tiến trình, chúng tôi sẽ chia sẻ thêm thông tin một cách công khai. |
| (Cũng được báo cáo vào Quý 2)
Chi phí bảo trì |
Không rõ thời gian hỗ trợ phiên bản giao thức. | Thông tin cập nhật về quý 3:
Chúng tôi đang thêm tính năng hỗ trợ bổ sung trong các API để hỗ trợ nhiều phiên bản đồng thời nhằm cho phép chuyển đổi linh hoạt giữa các phiên bản, mặc dù khung thời gian hỗ trợ / ngừng sử dụng vẫn đang được xác định. |