Báo cáo hằng quý vào quý 4 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 trong Quý 3) Tính hữu ích cho nhiều kiểu bên liên quan |
Các mối lo ngại rằng 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 nhỏ hơn (nhỏ hơn) đóng góp nhiều hơn so với các trang web chung (lớn hơn) | Phản hồi của chúng tôi không thay đổi so với 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ư theo cách 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 Google, đồng thời có tính đến tác động đến sự cạnh tranh trong quảng cáo kỹ thuật số, cũng như tác động đế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 quả hoạt động 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 trong khía cạnh 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 thiết kế kỹ thuật hơn nữa. Chúng tôi đã làm việ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 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 và có cơ hội đóng góp ý kiến về các phương pháp đề xuất." |
| (Cũng được báo cáo trong Quý 3) Yêu cầu 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ý 4: 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, đồng thời tiếp tục cam kết cung cấp thêm nhiều tài liệu để nhà phát triển có thể nắm bắt được lợi ích của công nghệ mới đối với họ. Trong quý vừa qua, chúng tôi đã thêm phần "Tin tức và thông tin cập nhật" vào privacysandbox.com và xuất bản bài đánh giá mở rộng về cách Hộp cát về quyền riêng tư có thể giúp tăng mức độ liên quan của quảng cáo trong tương lai. Chúng tôi cũng tổ chức các phiên 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 như các phiên hỏi đáp với trưởng nhóm sản phẩm và kỹ thuật để có thể thảo luận/đặt câu hỏi trực tiếp. |
| Các chỉ số quan trọng về trang web | Độ trễ của API Hộp cát về quyền riêng tư ảnh hưởng như thế nào đến Các chỉ số quan trọng về trang web? | Việc giảm thiểu độ trễ là mục tiêu thiết kế chính của API Hộp cát về quyền riêng tư. Theo dự kiến hiện tại của chúng tôi là độ trễ của API sẽ ít ảnh hưởng nhất đến Các chỉ số quan trọng về trang web của trang web, vì phần lớn các API được gọi sau lần kết xuất ban đầu của trang web. Chúng tôi tiếp tục theo dõi và cải tiến để giảm độ trễ hơn nữa cho từng API, đồng thời khuyến khích tiếp tục thử nghiệm và phản hồi. Độ trễ của quá trình đặt giá thầu theo thời gian thực được giải quyết trong phần FLEDGE thuộc phần "Hiệu suất của phiên đấu giá FLEDGE" |
| Khả năng tương thích | Mối lo ngại về khả năng tương tác với các giải pháp tiềm năng khác | Mục tiêu của Hộp cát về quyền riêng tư là bảo vệ người dùng khỏi việc theo dõi trên nhiều trang web, đồng thời hỗ trợ nhu cầu của hệ sinh thái web. Chúng tôi hướng đến mục tiêu này bằng cách ngừng sử dụng những công nghệ trình duyệt cũ cho phép hoạt động theo dõi trên nhiều trang web (như cookie của bên thứ ba) và thay vào đó, cung cấp những công nghệ mới được thiết kế nhằm hỗ trợ các trường hợp sử dụng cụ thể. Đề xuất trong khuôn khổ Hộp cát về quyền riêng tư giúp cải thiện quyền riêng tư bằng cách hạn chế lượng dữ liệu được gửi đi trên thiết bị của người dùng. Đề xuất không đặt ra các hạn chế về kỹ thuật đối với khả năng chia sẻ hoặc xử lý dữ liệu của một trang web sau khi được thu thập từ trình duyệt. Do đó, những công nghệ này không ngăn các công ty ký kết thoả thuận "quản lý dữ liệu" hay bất kỳ mối quan hệ hợp đồng tương tự nào khác. Tương tự như vậy, các chính sách này không hạn chế khả năng người dùng đồng ý chia sẻ dữ liệu của họ qua các phương thức khác. Để làm rõ, Google đã cam kết áp dụng công nghệ Hộp cát về quyền riêng tư theo cách tương tự cho tất cả các trang web, bao gồm cả các sản phẩm và dịch vụ của Google. Sau khi Chrome ngừng hỗ trợ cookie của bên thứ ba, các cam kết này cũng nêu rõ rằng Google sẽ không sử dụng các dữ liệu cá nhân khác, chẳng hạn như nhật ký duyệt web trên Chrome được đồng bộ hoá của người dùng, để theo dõi người dùng nhằm nhắm mục tiêu hoặc đo lường quảng cáo kỹ thuật số. |
Hiển thị nội dung và quảng cáo có liên quan
Chủ đề
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Tác động đối với thứ hạng tìm kiếm trên Google | Hỏi xem tính năng hỗ trợ Topics API của trang web có được dùng làm tín hiệu tiềm năng để xếp hạng kết quả trên Google Tìm kiếm hay không | Một số trang web có thể chọn không sử dụng Topics API. Nhóm Hộp cát về quyền riêng tư chưa phối hợp hoặc yêu cầu tổ chức Tìm kiếm sử dụng thứ hạng trang làm động lực để các trang web sử dụng Topics API. Google đã xác nhận với CMA rằng Google Tìm kiếm sẽ không dùng quyết định chọn không sử dụng Topics API cho một trang web làm tín hiệu xếp hạng. |
| Thuật toán phân loại chủ đề | Thêm URL và nội dung trang ngoài tên máy chủ để xác định Chủ đề của trang web nhằm cải thiện sự hữu ích cho các bên liên quan. | Lịch sử duyệt web của người dùng hiện được phân loại bằng tên máy chủ của trang web. Chrome tiếp tục đánh giá các lựa chọn để xem xét siêu dữ liệu ở cấp trang (chẳng hạn như tất cả hoặc một số thành phần của URL và/hoặc nội dung trên trang) trong quá trình 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ụ: về siêu dữ liệu, một số rủi ro cụ thể bao gồm: – Trang web sửa đổi siêu dữ liệu cấp trang làm phương pháp để mã hoá các ý nghĩa khác nhau (và có thể mang tính nhạy cảm) thành chủ đề; – Trang web sửa đổi siêu dữ liệu cấp trang để trình bày sai chủ đề vì lợi ích tài chính; – Trang web sửa đổi siêu dữ liệu cấp trang một cách linh động làm phương pháp theo dõi nhiều trang web |
| (Cũng được báo cáo trong Quý 3) 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. | Phản hồi của chúng tôi không thay đổi so với Quý 3: "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ả [trong báo cáo Quý 3 của chúng tôi], 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, chúng tôi nỗ lực không ngừng để cải thiện cách phân loại, 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." |
| Cập nhật cách phân loại | Danh sách phân loại sẽ được cập nhật như thế nào? | 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 đối với hệ sinh thái. Cách phân loại trong đề xuất ban đầu của Topics API được thiết kế để cho phép kiểm thử chức năng. Chrome đang tích cực xem xét nhiều phương pháp để cập nhật cách phân loại. Ví dụ: Chrome có thể sử dụng khái niệm giá trị thương mại cho mỗi chủ đề để xác định danh mục nào cần đưa vào các vòng lặp trong tương lai. |
| Hiệu suất của thuật toán phân loại theo khu vực cho chủ đề | Thuật toán phân loại chủ đề hoạt động kém trong các miền khu vực | Chúng tôi không ngừng cải thiện thuật toán phân loại. Dựa trên ý kiến phản hồi mà chúng tôi nhận được, có một khả năng đang được xem xét là mở rộng danh sách ghi đè Chủ đề. Theo phân tích của chúng tôi, danh sách này sẽ giúp tăng mức độ phù hợp trên toàn cầu và cải thiện độ chính xác. Xin giải thích rằng cách phân loại Topics API có 2 thành phần liên quan: (1) Danh sách ghi đè chứa 10 nghìn trang web hàng đầu cùng các chủ đề liên quan và (2) mô hình học máy trên thiết bị giúp phân loại tên máy chủ thành các chủ đề. Bằng cách mở rộng danh sách ghi đè (1), chúng ta có thể cải thiện hiệu suất phân loại cho những khu vực mà thuật toán phân loại có thể hoạt động kém. |
| Thời gian bắt đầu của hệ thống trong một tuần | Thời gian bắt đầu của một tuần là quá dài đối với những người dùng muốn đưa ra các quyết định ngắn hạn. | Chúng tôi đang tích cực xem xét khoảng thời gian bắt đầu phù hợp của hệ thống, đồng thời hoan nghênh thêm ý kiến phản hồi về khoảng thời gian bắt đầu của hệ sinh thái tốt hơn. |
| Truy xuất tiêu đề HTTP | Lo ngại về việc không có đủ thông tin liên quan đến việc truy xuất tiêu đề HTTP của các chủ đề | Các tiêu đề và phương thức tìm nạp() đang diễn ra. Chúng tôi cũng có thông tin tại đây. Chúng tôi cũng đã thêm thông tin ignoreObserver vào nội dung giải thích. |
| Các chủ đề chỉ nhằm mục đích trợ giúp nhà quảng cáo, chứ không phải người dùng | Có vẻ như Chủ đề/Hộp cát về quyền riêng tư là một cách tiếp cận tập trung vào ngành. Lợi ích đối với người dùng không rõ ràng bằng lợi ích đối với ngành. | Chúng tôi tin rằng Chủ đề sẽ mang lại lợi ích cho người dùng là Chủ đề hỗ trợ quảng cáo dựa trên mối quan tâm, giúp môi trường web mở và miễn phí. Chúng tôi cũng tin rằng Chủ đề sẽ cải thiện đáng kể quyền riêng tư so với cookie của bên thứ ba. Việc xoá cookie của bên thứ ba mà không có giải pháp thay thế khả thi có thể ảnh hưởng tiêu cực đến nhà xuất bản và có thể dẫn đến phương pháp kém hơn kém riêng tư, không minh bạch và thực tế là người dùng không thể đặt lại hoặc kiểm soát. Nhiều công ty đang tích cực thử nghiệm Topics API và Sandbox API. Chúng tôi cam kết cung cấp các công cụ giúp cải thiện quyền riêng tư và hỗ trợ web. Gần đây, Nhóm kiến trúc kỹ thuật W3C đã công bố chế độ xem ban đầu về API Chủ đề. Chúng tôi sẽ phản hồi công khai API này. Ở giai đoạn này, vì Google nhận được câu hỏi từ hệ sinh thái về tác động của bài đánh giá này đối với việc phát triển và ra mắt Topics API, nên chúng tôi muốn khẳng định lại kế hoạch cung cấp API Chủ đề trong phiên bản ổn định của Chrome trong năm nay. Mặc dù, Google đánh giá cao ý kiến đóng góp của Nhóm kiến trúc kỹ thuật W3C, nhưng họ cũng coi trọng việc tiếp tục nỗ lực phát triển và thử nghiệm Chủ đề với sự tham khảo ý kiến của CMA và hệ sinh thái. |
| Rò rỉ dữ liệu | Lo ngại rằng Chủ đề có thể bị rò rỉ ra các trang web khác khi chưa được cho phép | Thiết kế của Topics API khiến cho dữ liệu của một nhà xuất bản (và thậm chí một nhóm nhà xuất bản nhỏ hơn) khó có thể bị rò rỉ theo bất kỳ cách nào. Các trang web của nhà xuất bản cũng có toàn quyền kiểm soát Topics API và có thể cấm truy cập vào API này thông qua chính sách về quyền. |
| Thiếu nhà quảng cáo để thử nghiệm | Nhà xuất bản lo ngại rằng họ hiện không thể chứng minh giá trị của Chủ đề cho nhà quảng cáo. | Vào nửa cuối năm 2023, chúng tôi dự định cung cấp tất cả API liên quan đến quảng cáo để thử nghiệm tích hợp và cho phép nhà quảng cáo phân tích hệ sinh thái về giá trị của Chủ đề. CMA sẽ giám sát việc thử nghiệm và công bố kết quả. Họ sẽ xem xét dữ liệu, bản phân tích và phương pháp. Chúng tôi khuyến khích hệ sinh thái chia sẻ ý kiến phản hồi với Google và CMA. |
| Chủ đề và FLEDGE | Yêu cầu thêm thông tin về cách sử dụng Chủ đề trong logic đặt giá thầu của FLEDGE | Bạn có thể sử dụng Chủ đề trong logic đặt giá thầu của FLEDGE. Chúng tôi cũng đang hướng dẫn tích hợp và sẽ bao gồm thêm thông tin chi tiết về cách thức triển khai. |
| Thứ hạng tuỳ chỉnh cho phương thức gọi của chủ đề | Cho phép điều chỉnh thứ hạng theo người gọi | Thách thức đối với giá trị hoặc thứ hạng chủ đề tuỳ chỉnh cho từng công nghệ quảng cáo là việc này có thể trở thành cơ chế mà công nghệ quảng cáo có thể tác động đến các chủ đề được trả về, từ đó trở thành vectơ tạo vân tay. |
| Danh sách ưu tiên người gọi trong các chủ đề | Cho phép phương thức gọi cung cấp danh sách các chủ đề có mức độ ưu tiên theo thứ hạng mà Topics API sẽ trả về nếu đủ điều kiện. | Chúng tôi hiện đang thảo luận thêm về ý tưởng này và hoan nghênh bạn đóng góp thêm thông tin. |
FLEDGE
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Google Ad Manager | Lo ngại rằng Google Ad Manager là người quyết định cuối cùng đối với các phiên đấu giá FLEDGE và sẽ ưu tiên Thẻ nhà xuất bản của Google và Google Ad Manager. | FLEDGE cho phép mỗi nhà xuất bản chọn cấu trúc của phiên đấu giá, bao gồm cả lựa chọn người bán cấp cao nhất và người bán thành phần. Mỗi người mua và người bán trong phiên đấu giá thành phần đều biết ai là người bán cấp cao nhất và có thể chọn đặt giá thầu hoặc không đặt giá thầu. |
| Không đủ người tham gia thử nghiệm FLEDGE | Yêu cầu khuyến khích thêm nhiều công ty thử nghiệm FLEDGE, chẳng hạn như bằng cách cải thiện chức năng của API và ngăn cản các giải pháp thay thế xâm phạm quyền riêng tư như tạo vân tay số | Hộp cát về quyền riêng tư đang được triển khai theo từng giai đoạn, phối hợp chặt chẽ với sự hướng dẫn của CMA và ICO, và quá trình thử nghiệm chức năng của FLEDGE đã cho thấy sự ổn định và khả năng cần thiết. Google tiếp tục khuyến khích hệ sinh thái thử nghiệm các API Hộp cát. Gần đây, chúng tôi đã xuất bản tài liệu "Tối đa hoá mức độ liên quan của quảng cáo" để giới thiệu cách FLEDGE và các API khác có thể giúp hỗ trợ các trường hợp sử dụng quan trọng cho ngành quảng cáo sau khi cookie của bên thứ ba không được dùng nữa. Các phần khác của Hộp cát về quyền riêng tư đã hỗ trợ các biện pháp giảm thiểu để theo dõi (xem UA-CH, Bảo vệ IP và Giảm thiểu hoạt động theo dõi số trang không truy cập) và sẽ tiếp tục cải thiện theo thời gian. Mục tiêu của Google không phải là biến FLEDGE trở thành giải pháp nhắm mục tiêu khả thi duy nhất, mà thay vào đó vẫn cam kết hợp tác với ngành và các cơ quan quản lý để thúc đẩy các công nghệ quảng cáo bảo đảm quyền riêng tư tốt nhất trong trình duyệt Chrome. |
| Các trường hợp sử dụng công nghệ máy học | Hướng dẫn thêm về cách hỗ trợ các trường hợp sử dụng công nghệ học máy để huấn luyện thuật toán đặt giá thầu trong phiên đấu giá trong FLEDGE và Báo cáo phân bổ | Chúng tôi nhận thấy sự cần thiết phải hỗ trợ người thử nghiệm tìm ra những cách hữu ích nhất để áp dụng công nghệ Hộp cát về quyền riêng tư. Chúng tôi đã bắt đầu xuất bản hướng dẫn cụ thể liên quan đến việc sử dụng nhiều khía cạnh của các API Hộp cát về quyền riêng tư làm dữ liệu đầu vào cho công nghệ học máy. Bài viết gần đây nhất, "Tối đa hoá mức độ liên quan của quảng cáo", thảo luận về cách ngành quảng cáo có thể tận dụng các tín hiệu này cho công nghệ học máy và chúng tôi dự định tiếp tục xuất bản hướng dẫn như vậy trong tương lai. |
| Truy vấn máy chủ giá trị khoá FLEDGE (K/V) | Tại sao máy chủ K/V có thể truy vấn công khai? | Máy chủ K/V nhắm đến việc cung cấp tín hiệu theo thời gian thực cho các phiên đấu giá FLEDGE. Do đó, máy chủ K/V cần có thể truy cập được từ nơi các phiên đấu giá FLEDGE thực thi, trên thiết bị của người dùng, yêu cầu máy chủ phải được cung cấp công khai. Chỉ bên đã có khoá mới truy xuất được giá trị được lưu trữ trong máy chủ K/V. Vì vậy, nếu công nghệ quảng cáo chỉ cung cấp khoá cho các trình duyệt thuộc Nhóm mối quan tâm và không sử dụng khoá có thể đoán ngẫu nhiên, thì chỉ những trình duyệt cần Giá trị để chạy phiên đấu giá mới có thể truy xuất giá trị đó. |
| Cách nhắm mục tiêu theo ngày/giờ? | Hỗ trợ các đối tượng ngày trong hàm logic đặt giá thầu. | Có nhiều cách để làm việc này. Người mua có thể yêu cầu người bán cung cấp ngày giờ hiện tại và người bán phải dễ dàng cung cấp thông tin này cho tất cả người mua. Người mua cũng có thể cung cấp ngày và giờ trong phản hồi về khoá-giá trị theo thời gian thực. Cuối cùng, người mua có thể cung cấp ngày và giờ trong phản hồi theo ngữ cảnh của họ trong các tín hiệu trên mỗi người mua mà người bán có thể chuyển đến tập lệnh generateBid của người mua. |
| Lựa chọn của người dùng | Khả năng người dùng chọn chặn mẫu quảng cáo của nhà quảng cáo khi phân phát qua FLEDGE hoặc các giải pháp thay thế. | Người dùng có thể chọn không sử dụng API Google Ads trong Chrome. Đối với các quảng cáo cụ thể, công nghệ quảng cáo phù hợp là bên phù hợp nhất để cung cấp quyền kiểm soát việc mẫu quảng cáo nào xuất hiện hoặc cách lựa chọn những mẫu quảng cáo đó. |
| Tiến trình rõ ràng hơn | Yêu cầu thêm thông tin về phạm vi áp dụng của các biện pháp bảo vệ quyền riêng tư trong FLEDGE, chẳng hạn như yêu cầu Khung bảo vệ. | Chúng tôi dự định công bố tiến trình chi tiết hơn vào Quý 1. |
| Báo cáo nhầm lẫn | Yêu cầu làm rõ hơn về cách báo cáo FLEDGE sẽ hoạt động với các API khác, chẳng hạn như Khung bảo vệ và API Tổng hợp riêng tư. | Chúng tôi dự định sẽ phát hành nội dung giải thích về sự tương tác giữa API Tổng hợp riêng tư, FLEDGE và Khung bảo vệ trong những tuần tới. |
| Tính năng đặt giá thầu theo thời gian thực và FLEDGE | Hướng dẫn về cách tích hợp FLEDGE với tính năng đặt giá thầu chuẩn theo thời gian thực. | Hai vấn đề chính làm phức tạp thêm khả năng đặt giá thầu theo thời gian thực của công nghệ quảng cáo là quyền truy cập vào dữ liệu ở cấp sự kiện và khả năng tích hợp dễ dàng hơn vào ARA. Chúng tôi dự định gửi thông tin cập nhật và giải thích về cả hai vấn đề này trong quý 1. |
| Hiệu suất của phiên đấu giá FLEDGE | Báo cáo của người kiểm thử rằng các phiên đấu giá FLEDGE có độ trễ cao | Chúng tôi rất trân trọng báo cáo của những người kiểm thử chia sẻ kết quả và trường hợp sử dụng, đồng thời đã chia sẻ một số đề xuất về cách cải thiện hiệu suất của FLEDGE. Cùng với đó, chúng tôi cũng đã thêm công cụ vào trình duyệt để giúp các nhà phát triển chẩn đoán chính xác hơn những yếu tố khiến phiên đấu giá bị chậm, đồng thời giải quyết một cách có hệ thống các nguồn gây ra độ trễ quan sát được. Những điểm cải tiến gần đây bao gồm thời gian chờ trong các phiên đấu giá chậm, kỹ thuật lọc bên đặt giá thầu nhanh, cách sử dụng lại các công việc FLEDGE để tránh phải trả chi phí khởi động và công việc liên tục để cho phép yêu cầu quảng cáo theo bối cảnh chạy song song với thời gian khởi động FLEDGE và tìm nạp mạng. Chúng tôi dự kiến tính năng tối ưu hoá độ trễ sẽ tiếp tục diễn ra trong cuộc trò chuyện liên tục giữa nhà phát triển Chrome và người kiểm thử FLEDGE dựa trên trải nghiệm sử dụng API thực tế của họ. |
| Giới hạn kích thước bộ nhớ đối với Nhóm mối quan tâm | Yêu cầu tăng giới hạn về quy mô của một nhóm mối quan tâm từ 50kB. | Chúng tôi đang tích cực xem xét yêu cầu này và mong có ý kiến phản hồi về việc sử dụng giá trị hạn mức nào. |
| Kết hợp dữ liệu do FLEDGE phân phát với cookie của bên thứ nhất | FLEDGE có hỗ trợ việc tích hợp với dữ liệu của bên thứ nhất của nhà quảng cáo không? | FLEDGE được xây dựng để hỗ trợ hoạt động quảng cáo bằng dữ liệu của bên thứ nhất mà nhà quảng cáo đã có. Tuy nhiên, FLEDGE không có ý định hỗ trợ nhà quảng cáo tìm hiểu hành vi duyệt web của người dùng trên bất kỳ trang web nào khác ngoài trang web của chính nhà quảng cáo đó. Việc đính kèm hành vi duyệt web bên ngoài trang web vào dữ liệu của bên thứ nhất là trái với mục tiêu của Hộp cát về quyền riêng tư. Chúng tôi dự định sẽ chia sẻ hướng dẫn tích hợp để cung cấp thêm thông tin về cách FLEDGE hỗ trợ việc tích hợp với dữ liệu của bên thứ nhất trong những tuần tới. |
| Giá trị ẩn danh K | Giá trị "K" thành "k-anon" sẽ được quyết định như thế nào và có được xuất bản không? | Giá trị "K" vẫn đang trong quá trình hoàn thiện và chúng tôi sẽ chia sẻ thêm thông tin khi lập kế hoạch. Chúng tôi muốn tìm hiểu thêm về việc giá trị k không xác định có thể cản trở việc chuẩn bị FLEDGE và xác định phạm vi đào tạo mô hình ML như thế nào. Chúng tôi hoan nghênh thêm ý kiến phản hồi về chủ đề này. |
| Hỗ trợ nhiều SSP | Nhiều SSP được hỗ trợ trong FLEDGE như thế nào? | FLEDGE hỗ trợ phiên đấu giá nhiều người bán như đã nêu trong đề xuất này. |
| Mức độ hiển thị của logic đặt giá thầu | Lo ngại về việc logic đặt giá thầu DSP sẽ hiển thị trong JavaScript | Với logic đặt giá thầu thiết kế hiện tại JavaScript có thể được người khác truy cập, nhưng chúng tôi hoan nghênh thêm ý kiến phản hồi về lý do khiến đây có thể là một vấn đề đáng lo ngại đối với các DSP. |
| prebid.js | Tiến trình hỗ trợ prebid.js trong FLEDGE diễn ra như thế nào? | Chỉ phiên bản 7.14 trở lên của Prebid.js mới hỗ trợ mô-đun FLEDGE. Mọi nhà xuất bản muốn thử nghiệm đều phải thêm mô-đun FLEDGE và nâng cấp bản sao Prebid của họ. |
| Hàm do người dùng xác định trong FLEDGE | Hàm do người dùng xác định (UDF) được hỗ trợ như thế nào trong FLEDGE? Đây là các hàm mà người dùng cuối có thể lập trình để mở rộng chức năng của API. | Bạn có thể xem tài liệu giải thích tại đây. Tính năng này vẫn đang trong quá trình hoàn thiện, vì vậy, chúng tôi hoan nghênh thêm ý kiến phản hồi về các trường hợp sử dụng. |
| Nới lỏng hạn chế về cùng nguồn gốc đối với các tài nguyên của Nhóm mối quan tâm | Yêu cầu nới lỏng quy tắc ràng buộc cùng nguồn gốc trên các tài nguyên Nhóm mối quan tâm để hỗ trợ một số trường hợp sử dụng công nghệ quảng cáo nhất định | Trong quá trình triển khai FLEDGE hiện tại, biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl và trustedBiddingSignalsUrl phải có cùng nguồn gốc với chủ sở hữu nhóm mối quan tâm.Quy tắc ràng buộc này tồn tại nhằm ngăn chặn một số hành vi khai thác nhất định của kẻ tấn công, như được giải thích tại đây. |
| Quyền sở hữu nhóm mối quan tâm | Yêu cầu giới hạn việc một công nghệ quảng cáo có thể sử dụng joininterestGroup cho cùng một Nhóm mối quan tâm trên các trang web hay không | Chúng tôi tập trung vào cách sử dụng độc giả, chứ không phải cách xây dựng nhóm khán giả. Chúng tôi sẽ thảo luận về các phương pháp tiềm năng tại đây và hoan nghênh bạn đóng góp thêm ý kiến. |
| Hết hạn khóa máy chủ giá trị khóa | Nội dung thảo luận về cách xoá khoá máy chủ sau khi các nhóm mối quan tâm tương ứng đã hết hạn | Chúng tôi đang tìm hiểu những cách xử lý khoá hết hạn và đang tìm ý kiến phản hồi 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 |
|---|---|---|
| Lưu lượng truy cập của Bản dùng thử theo nguyên gốc | Lưu lượng truy cập của Bản dùng thử theo nguyên gốc hiện tại không đủ để tiến hành thử nghiệm tiện ích. | Bản dùng thử theo nguyên gốc hiện tại là nơi để người chơi trong hệ sinh thái tiến hành kiểm thử chức năng để đảm bảo API hoạt động như dự kiến. Chúng tôi hiểu rằng sẽ cần có nhiều lưu lượng truy cập hơn để thử nghiệm tiện ích sau khi quá trình phát triển nhiều API Hộp cát về quyền riêng tư đã hoàn thiện hơn. Tiến trình thử nghiệm hiện tại dự kiến việc này sẽ diễn ra trong Giai đoạn phát hành rộng rãi (tức là khi công nghệ cho các trường hợp sử dụng sẽ được ra mắt và được cung cấp cho 100% lưu lượng truy cập Chrome) vào Quý 3 năm 2023 (xem tiến trình mới nhất của chúng tôi trên privacysandbox.com). Chúng tôi hoan nghênh mọi ý kiến phản hồi khác về thử nghiệm trường hợp sử dụng có yêu cầu thêm lưu lượng truy cập. |
| Trùng lặp về chức năng của nhiều API đo lường Hộp cát về quyền riêng tư | Những lo ngại về việc có nhiều phương pháp đo lường trùng lặp thông qua Hộp cát về quyền riêng tư sẽ làm tăng độ phức tạp, chẳng hạn như API Báo cáo phân bổ và API Tổng hợp riêng tư. | Chúng tôi đang nỗ lực xây dựng tài liệu tốt hơn để làm rõ các trường hợp sử dụng của các API này và hoan nghênh thêm ý kiến phản hồi về những lĩnh vực chưa được giải thích. Ví dụ: API Báo cáo phân bổ được thiết kế riêng để hỗ trợ việc đo lường lượt chuyển đổi, trong khi API tổng hợp riêng tư và Bộ nhớ dùng chung là các API có mục đích chung để hỗ trợ nhiều trường hợp sử dụng đo lường trên nhiều trang web hơn. |
| Thử lại yêu cầu báo cáo không thành công | Nêu rõ số lần một yêu cầu báo cáo được gửi đi nếu yêu cầu đó không thành công. | Chúng tôi đã công bố hướng dẫn về việc này. Tóm lại, báo cáo chỉ được gửi khi trình duyệt đang chạy/trực tuyến. Sau lần gửi không thành công đầu tiên, báo cáo sẽ được thử lại sau 5 phút. Sau lỗi thứ hai, báo cáo sẽ được thử lại sau 15 phút. Sau đó, báo cáo sẽ không được gửi. |
| Sự chậm trễ trong việc báo cáo | Độ trễ báo cáo dự kiến là bao nhiêu? | Chúng tôi mong muốn nghe thêm ý kiến phản hồi của hệ sinh thái về mọi sự chậm trễ trong báo cáo mà họ đang gặp phải trong quá trình thu thập dữ liệu để đánh giá song song thêm các trường hợp chậm trễ này. |
| Trang kết xuất trước | Mô hình phân bổ ARA có hoạt động trên các trang kết xuất trước không? | Quá trình đăng ký phân bổ được trì hoãn trên các trang kết xuất trước cho đến khi kích hoạt (lượt nhấp hoặc lượt xem thực tế diễn ra). Điều này có nghĩa là chúng ta sẽ trì hoãn lệnh ping yêu cầu `attributionsrc`. |
| Đo lường mức tăng lượt chuyển đổi | Cách đo lường mức tăng lượt chuyển đổi bằng thử nghiệm AB trên cùng một miền | Các trang web có thể đo lường mức tăng lượt chuyển đổi bằng thử nghiệm A/B trên cùng một miền thông qua báo cáo phân bổ. Họ có thể mã hoá thông số A/B dưới dạng các khoá bằng cách sử dụng API tổng hợp, rồi nhận báo cáo tóm tắt về các giá trị lượt chuyển đổi theo những nhóm chính đó. |
| (Cũng được báo cáo vào Quý 3) Chuyển đổi trên nhiều tên miền | Cách theo dõi các lượt chuyển đổi trên nhiều miền, chẳng hạn như với 2 đích đến trở lên | Thông tin cập nhật về quý 4: Chúng tôi đã phát hành một đề xuất để loại bỏ hạn chế về đích đến của trang đích, cho phép theo dõi các cuộc trò chuyện trên nhiều miền. Đề xuất này đã được triển khai. |
| (Cũng được báo cáo vào Quý 3) 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 dưới 24 giờ | Thông tin cập nhật cho quý 4: Chúng tôi đã chia sẻ yêu cầu lấy dữ liệu này. Yêu cầu này sẽ tách riêng thời hạn báo cáo và khoảng thời gian báo cáo nhằm giảm thiểu sự đánh đổi giữa độ trễ báo cáo và thời hạn chuyển đổi. Tính năng này hiện đã được ra mắt trong M110. |
| Gian lận và sử dụng sai mục đích | Yêu cầu của nhà quảng cáo và nhà tiếp thị để có thể chia nhỏ và tổng hợp dữ liệu dựa trên các trang web của nhà xuất bản nơi quảng cáo của họ được phân phát, cũng sẽ cung cấp thêm thông tin chi tiết về các hoạt động quảng cáo tiềm ẩn | Chúng tôi đang tích cực thảo luận về ý kiến phản hồi này tại đây và chúng tôi hoan nghênh các ý kiến đóng góp khác. |
| (Cũng được báo cáo vào Quý 3) Độ 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. | Báo cáo cấp sự kiện có khoảng thời gian báo cáo mặc định là 2, 7 và 30 ngày. Bạn có thể sửa đổi giá trị này bằng cách sử dụng tham số "expiry" (thời hạn). Công nghệ quảng cáo có thể định cấu hình thời hạn tối thiểu là 1 ngày để nhận được báo cáo tiềm năng trong vòng chưa đầy 2 ngày. Chúng tôi giới hạn độ chi tiết của thời gian hết hạn trong 1 ngày dưới dạng cơ chế bảo vệ quyền riêng tư, vì báo cáo chi tiết hơn có thể dẫn đến các cuộc tấn công về thời gian. Ngoài ra, chúng tôi cho phép đặt thông số "hết hạn" độc lập cho báo cáo tổng hợp và cấp sự kiện. Hãy xem ở đây. Ngoài ra, Google Ads sẽ không nhận được khoảng thời gian báo cáo đặc biệt nào mà các công nghệ quảng cáo khác không có được thông qua Attribution Reporting API. |
| Cùng một yêu cầu đối với nguồn gốc báo cáo | Yêu cầu xoá yêu cầu nguồn gốc đăng ký nguồn phải giống với nguồn gốc đăng ký lượt chuyển đổi | Chúng tôi đề xuất sử dụng lệnh chuyển hướng HTTP để uỷ quyền đăng ký nhằm giải quyết trường hợp sử dụng này. Chúng tôi hoan nghênh mọi ý kiến phản hồi khác về hướng dẫn mới này. |
| Theo dõi lượt chuyển đổi | Cần phân biệt xem lượt chuyển đổi xảy ra trước/sau một số giờ nhất định do nhà quảng cáo đặt | API Báo cáo phân bổ hỗ trợ việc đặt khoảng thời gian hết hạn và mức độ ưu tiên cho hoạt động phân bổ nguồn. Bằng cách sử dụng cả hai, về mặt kỹ thuật, bạn có thể phân bổ một lượt chuyển đổi đã xảy ra trong khoảng thời gian X ngày một cách riêng biệt với một lượt chuyển đổi xảy ra sau X. |
| Mô phỏng tiếng ồn | Yêu cầu mô phỏng nhiều lượt chuyển đổi trên mỗi nhóm để hiểu tác động đối với nhà quảng cáo có ít lượt chuyển đổi hơn | Chúng tôi đang tìm cách thêm nhiều cách để mô phỏng điều này trong các phiên bản sau này của Phòng thí nghiệm độ ồn. Chúng tôi hoan nghênh mọi ý kiến phản hồi khác. |
| Báo cáo trên thiết bị di động | Báo cáo có được gửi đi khi Chrome đang chạy ở chế độ nền trên thiết bị di động không? | Hiện tại, ngay cả trên thiết bị di động, báo cáo sẽ không được gửi khi Chrome chạy trong nền. Điều này có thể thay đổi khi API tích hợp với Hộp cát về quyền riêng tư của Android. Hãy xem ở đây. Xin lưu ý rằng Hộp cát về quyền riêng tư của Android không nằm trong các Cam kết được CMA chấp nhận. |
| Phạm vi cung cấp dữ liệu | Các mối lo ngại về việc Google sẽ có thêm quyền truy cập vào dữ liệu thông qua API Hộp cát về quyền riêng tư | Thứ nhất, Google Ads không nhận được quyền truy cập ưu tiên nào vào dữ liệu từ Attribution Reporting API hoặc các API Hộp cát về quyền riêng tư khác. Vấn đề này cũng được giải quyết trong phần Phản hồi chung, thuộc "Khả năng tương tác", bao gồm thông tin chi tiết hơn về Cam kết của Google. Thứ hai, dựa trên sự khác biệt giữa các trang web lớn và nhỏ, Google nhận thấy rằng các biện pháp bảo vệ quyền riêng tư dựa trên độ nhiễu có thể có tác động lớn hơn đến các phần dữ liệu nhỏ hơn. Tuy nhiên, có một số giải pháp giảm thiểu có thể xảy ra: chẳng hạn như tổng hợp trong khoảng thời gian dài hơn sẽ giải quyết được vấn đề này. Mặc dù vậy, vẫn chưa rõ những kết luận dựa trên các phần dữ liệu rất nhỏ (như một hoặc hai lượt mua hàng) có ý nghĩa đối với nhà quảng cáo hay không. Trong thời gian chạy bản dùng thử theo nguyên gốc, Google đã khuyến khích người thử nghiệm tận dụng khả năng thử nghiệm với nhiều tham số về quyền riêng tư và nhiễu để họ có thể đưa ra ý kiến phản hồi cụ thể hơn về vấn đề 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 |
|---|---|---|
| Hoãn giảm tác nhân người dùng cho đến khi hệ sinh thái web sẵn sàng hơn | Không có đủ thời gian để thích ứng với những thay đổi sắp tới về tính năng Giảm thiểu tác nhân người dùng. | Chúng tôi sẽ giải quyết ý kiến phản hồi này trong báo cáo đầy đủ thuộc mục "Mối quan ngại của các bên liên quan" trong phần có tiêu đề "Quan hệ giữa Google với CMA". |
| Hoãn giảm tác nhân người dùng cho đến khi hệ sinh thái web sẵn sàng hơn | Yêu cầu trì hoãn việc triển khai tính năng Giảm thiểu tác nhân người dùng cho đến khi triển khai Tác nhân người dùng có cấu trúc (SUA) | Vào tháng 10 năm 2021, nhóm Google Ads đã đề xuất việc Bổ sung tác nhân người dùng có cấu trúc (xem quy cách) cho OpenRTB và họ đã được đưa vào bản cập nhật thông số kỹ thuật 2.6 phát hành vào tháng 4 năm 2022. Chúng tôi có một số bằng chứng cho thấy SUA đã được triển khai và đi vào hoạt động ngày hôm nay, như minh hoạ qua bài đăng trên blog của Scientia Mobile minh hoạ cách sử dụng UA-CH và API WURFL để tạo SUA. |
###
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 |
|---|---|---|
| Kiểm tra UA-CH bằng các kỹ thuật theo dõi chống bí mật khác | Hướng dẫn cách kiểm thử tất cả API Hộp cát về quyền riêng tư và các kỹ thuật tạo vân tay số được đề xuất cùng nhau theo phương pháp toàn diện | Kế hoạch thử nghiệm của chúng tôi được thiết kế để phản ánh tiến trình không đồng bộ trong việc phát triển một số biện pháp chống lưu dấu vân tay, trái ngược với các đề xuất còn lại của Hộp cát. Chính sách này giải quyết thực tế rằng một số biện pháp chống lưu dấu vân tay (ví dụ: Ngân sách quyền riêng tư, Bảo vệ IP và Giảm thiểu hoạt động theo dõi số trang không truy cập) sẽ được phát triển đầy đủ và chỉ sẵn sàng cho giai đoạn Phát hành rộng rãi sau khi cookie của bên thứ ba ngừng hoạt động. Mặc dù các biện pháp chống vân tay đó sẽ không được đưa vào các thử nghiệm định lượng, nhưng các biện pháp này sẽ trải qua quy trình đánh giá định tính dựa trên dữ kiện thực tế hiện có tại thời điểm Ngừng cung cấp. |
| (Cũng được báo cáo vào Quý 2) Hiệu suất |
Lo ngại về độ trễ khi nhận gợi ý qua Critical-CH (trong lần tải trang đầu tiên) | Xem phần UA-CH chuyên biệt bên dưới |
| Phản hồi chưa đầy đủ | Phản hồi từ hệ sinh thái về thay đổi UA-CH có thể là chưa đủ, dẫn đến mối lo ngại về việc hệ sinh thái thiếu nhận thức. | Chúng tôi đã chủ động chia sẻ kế hoạch của mình để đảm bảo quá trình phát hành cẩn thận và giảm thiểu tình trạng gián đoạn. Kế hoạch Giảm thiểu tác nhân người dùng và API UA-CH đã được trình bày cho Nhóm cộng đồng chống gian lận W3C vào ngày 18 tháng 3 năm 2022, cũng như cho Nhóm hoạt động thanh toán trên web và Nhóm quan tâm đến việc bảo mật khi thanh toán trên web vào ngày 20 tháng 1 năm 2022. Không có mối lo ngại đáng kể nào được nêu ra trong hoặc sau buổi thuyết trình. Google đã chủ động tương tác với hơn 100 nhà điều hành trang web để thu thập ý kiến phản hồi. Ngoài ra, Google cũng đã sử dụng kênh Blink-Dev để truyền đạt công khai việc giảm thiểu tác nhân người dùng dựa trên ý kiến phản hồi của các bên liên quan trong hệ sinh thái. |
| Thời gian | Mối lo ngại về thời điểm triển khai và sự chuẩn bị của ngành | Xem phần UA-CH chuyên biệt bên dưới |
| Trạng thái nền tảng Chrome | Đã yêu cầu cập nhật trang chromestatus cho UA-CH | Mục chromestatus được cập nhật vào ngày 19 tháng 12 thành "Tín hiệu kết hợp". |
Bảo vệ IP (trước đây là Gnatcatcher)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Bật hoặc tắt tính năng bán vé | Tôi chọn sử dụng hay không sử dụng quyền riêng tư đối với địa chỉ IP? | Mục tiêu của chúng tôi là cung cấp Bảo vệ IP cho tất cả người dùng. Vì mục tiêu đó, chúng tôi hiện đang đánh giá các phương án mà người dùng lựa chọn cho tính năng Bảo vệ IP. |
| Trường hợp sử dụng Địa chỉ IP cho dữ liệu của bên thứ nhất | Tôi có thể sử dụng địa chỉ IP để gắn kết hành trình của người dùng trên các miền của bên thứ nhất sau khi bảo vệ IP không? | Như đã phát hành trước đây, biện pháp Bảo vệ IP ban đầu sẽ tập trung vào việc theo dõi trong ngữ cảnh bên thứ ba, có nghĩa là miền của bên thứ nhất sẽ không bị ảnh hưởng. |
| Các trường hợp sử dụng Công nghệ quảng cáo | Làm cách nào để các công ty có thể thiết lập các biện pháp chống gian lận bằng tính năng Bảo vệ IP? | Chúng tôi công nhận tầm quan trọng của địa chỉ IP như một tín hiệu cho nỗ lực chống gian lận trong web ngày nay. Trong Cam kết của chúng tôi đối với CMA (đoạn 20), chúng tôi đã tuyên bố rằng chúng tôi sẽ không triển khai Bảo vệ sở hữu trí tuệ nếu không có những nỗ lực hợp lý để hỗ trợ khả năng tiến hành nỗ lực chống thư rác và chống gian lận của các trang web. Một trong những ưu tiên hàng đầu của chúng tôi là tìm hiểu cách biện pháp Bảo vệ IP tác động đến các trường hợp sử dụng chống gian lận và khả năng phát hiện để có thể đầu tư hơn nữa vào các công nghệ bảo đảm quyền riêng tư giúp các công ty bảo vệ sự an toàn trên web. Chúng tôi khuyến khích ý kiến phản hồi và thông tin đề xuất mới nhằm hỗ trợ nhu cầu của các công ty về bảo mật và chống gian lận, ngay cả khi tín hiệu thay đổi theo thời gian. |
| Gian lận và sử dụng sai mục đích | Biện pháp bảo vệ IP có bao gồm biện pháp Từ chối dịch vụ (DoS) không? | Chúng tôi cam kết cải thiện quyền riêng tư trong khi vẫn giữ cho web luôn an toàn, và việc bảo vệ chống lại các cuộc tấn công từ chối dịch vụ là một trường hợp sử dụng quan trọng chống lại hành vi sử dụng sai mục đích. Chúng tôi hy vọng sẽ giảm thiểu tác động đến các biện pháp bảo vệ DoS thông qua cả thiết kế của Biện pháp bảo vệ IP và thông qua các giải pháp chống hành vi sử dụng sai mục đích mới. Vì ban đầu, biện pháp Bảo vệ IP chỉ tập trung vào các dịch vụ do bên thứ ba nhúng, nên một số bên liên quan cho biết rằng biện pháp này sẽ hạn chế tác động của biện pháp bảo vệ DoS đối với các trang web của bên thứ nhất. Tuy nhiên, chúng tôi vẫn tiếp tục đề nghị công chúng đưa ra ý kiến phản hồi để đánh giá rủi ro đối với các trường hợp sử dụng DoS, đặc biệt là đối với các dịch vụ được nhúng của bên thứ ba. Đồng thời, chúng tôi cũng đang tìm hiểu các cơ chế chặn ứng dụng và phản hồi sai trái cho phép một trang web hoặc dịch vụ chặn người dùng vi phạm mà không cần xác định danh tính người dùng đó. |
| Lọc nội dung | Lọc nội dung bằng tính năng Bảo vệ IP | Các công ty khác nhau có nhu cầu khác nhau về việc lọc nội dung và tuỳ chỉnh trải nghiệm người dùng. Nhiều trường hợp sử dụng như vậy hiện không dựa vào địa chỉ IP nên sẽ không bị ảnh hưởng bởi tính năng Bảo vệ IP. Ví dụ: một nhà xuất bản đang tìm cách điều chỉnh nội dung của mình để tăng mức độ tương tác có thể sử dụng cookie của bên thứ nhất hoặc cookie được phân vùng của bên thứ ba để tìm hiểu mối quan tâm và hoạt động tương tác trước đó của người dùng với nhà xuất bản. Hoặc một đối tác công nghệ quảng cáo tập trung vào việc phân phát quảng cáo phù hợp cho đúng người dùng có thể kết hợp FLEDGE và Chủ đề, chẳng hạn như để mang lại kết quả quảng cáo tương tự như hiện nay với cookie của bên thứ ba hoặc các công nghệ theo dõi trên nhiều trang web khác. Chúng tôi cũng đang nghiên cứu việc xây dựng các tính năng mới giúp bảo đảm quyền riêng tư cho Biện pháp bảo vệ IP, chẳng hạn như định vị vị trí tương đối, để hỗ trợ thêm cho việc lọc nội dung khi các cơ chế hiện có có thể không đầy đủ. Chúng tôi hoan nghênh thêm ý kiến phản hồi về những trường hợp sử dụng tính năng lọc nội dung có thể chịu ảnh hưởng của biện pháp Bảo vệ IP. |
| (Cũng được báo cáo trong Quý 3) Các trường hợp sử dụng vị trí địa lý |
Biện pháp bảo vệ IP có thể ngăn không cho những trường hợp sử dụng vị trí địa lý hợp pháp trong tương lai, chẳng hạn như cá nhân hoá nội dung dựa trên vị trí địa lý. | Thông tin cập nhật cho quý 4: Chúng tôi đang làm việc với các bên liên quan để đảm bảo Chrome tiếp tục hỗ trợ các trường hợp sử dụng hợp pháp đối với địa chỉ IP. Chúng tôi đang thu thập ý kiến phản hồi về hệ sinh thái về mức độ chi tiết của vị trí địa lý IP tại đây. |
Ngân sách quyền riêng tư
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Tài liệu rõ ràng hơn | Thêm ví dụ để các bên liên quan có thể dự đoán những việc có thể bị hạn chế sau khi triển khai Ngân sách quyền riêng tư | Đề xuất Ngân sách quyền riêng tư vẫn đang trong quá trình thảo luận và chưa được bất kỳ trình duyệt nào triển khai. Ngày sớm nhất mà bạn có thể sử dụng ngân sách theo tỷ lệ là ngày sớm nhất mà Ngân sách quyền riêng tư có thể được thực thi. Điều này sẽ không xảy ra trước khi cookie của bên thứ ba bị xoá vào năm 2024. Hiện chúng tôi không có thêm tài liệu nào để chia sẻ. Chúng tôi sẽ chia sẻ thêm thông tin về đề xuất này khi đề xuất đã được hoàn thiện. Trong thời gian chờ đợi, chúng tôi hoan nghênh các bên liên quan chia sẻ mọi ý kiến phản hồi giúp ích cho quá trình phát triển đề xuất. |
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 |
|---|---|---|
| (Cũng được báo cáo vào Quý 3) Giới hạn miền | Yêu cầu mở rộng số lượng miền được liên kết | Câu hỏi cập nhật cho quý 4: Chúng tôi đã phát hành FPS cho kiểm thử cục bộ, bao gồm cả quy trình gửi bộ mô phỏng trên GitHub và một cờ để kiểm thử rSA và rSAFor cục bộ. Chúng tôi cũng tổ chức 2 cuộc họp mở cho các nhà phát triển về FPS để tiếp tục giải đáp các câu hỏi xung quanh các trường hợp sử dụng cho nhóm nhỏ được liên kết. Các nhà phát triển nên thử nghiệm chức năng FPS để đưa ra ý kiến phản hồi về tác động của giới hạn miền cho tập hợp con được liên kết đối với khả năng hữu dụng của FPS trong các trường hợp sử dụng của họ. Trong các lệnh gọi của WICG, chúng tôi đã làm rõ rằng Chrome cam kết cung cấp một giải pháp hữu dụng và có cân nhắc đến quyền riêng tư của người dùng. Vì vậy, chúng tôi rất trân trọng ý kiến phản hồi của cộng đồng về những trường hợp sử dụng cụ thể có thể bị ảnh hưởng bởi giới hạn miền, để nhóm có thể xem xét cách giải quyết các trường hợp sử dụng này mà vẫn tiếp tục bảo vệ quyền riêng tư của người 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 | Điều gì sẽ xảy ra nếu một miền được thêm vào nhóm mà họ không đồng ý? | Chúng tôi đã phát hành hướng dẫn gửi Nhóm bên thứ nhất tại đây vào ngày 2 tháng 12 năm 2022. Như đã giải thích trong nguyên tắc gửi, mọi quy trình quản lý thay đổi cho nhóm đều sẽ tuân thủ và tôn trọng quy trình xác thực trên GitHub, bao gồm cả việc xác thực quyền sở hữu. Việc này sẽ giúp giảm thiểu rủi ro này. |
| Giảm thiểu hành vi lạm dụng | Lo ngại rằng các nhóm bên thứ nhất có thể bị khai thác | Chúng tôi đang tìm cách mở rộng quy trình kiểm tra kỹ thuật cho các loại tập hợp con và đang tích cực thu thập thêm ý kiến đóng góp của cộng đồng tại đây. |
| Các trường hợp sử dụng quảng cáo | Câu hỏi về việc có nên sử dụng Nhóm bên thứ nhất để hỗ trợ tính năng Nhắm mục tiêu quảng cáo hay không | Chúng tôi không cố gắng hỗ trợ các trường hợp sử dụng tính năng Nhắm mục tiêu quảng cáo cho Nhóm bên thứ nhất, và bạn nên sử dụng các Ads API có sẵn cho những trường hợp sử dụng như vậy. |
| (Cũng được báo cáo trong Quý 3) | Mối lo ngại về việc FPS không nhất quán với Cam kết của 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 trang web | Phản hồi của chúng tôi không thay đổi so với Quý 3: "Google sẽ tiếp tục 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ư theo cách không cản trở sự 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 việc 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." |
| Đề xuất thay thế | Nhóm đã xác thực GDPR | Ngoài ý kiến phản hồi mà hệ sinh thái đưa ra về đề xuất áp dụng "Bộ đã xác thực theo GDPR", Chrome còn lo ngại về những điểm hạn chế sau đây của đề xuất thay thế này:
Kể từ khi thay thế này được đưa ra, Chrome đã cập nhật đề xuất Nhóm bên thứ nhất và phát hành nguyên tắc gửi để tạo nhóm mới. |
API Khung bảo vệ
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Các hạn chế đối với Khung bảo vệ trong khi chế độ OTG | Các hạn chế hiện tại đối với Khung bảo vệ trong Thời gian dùng thử theo nguyên gốc là gì? | Chúng tôi đang chuẩn bị tài liệu về các quy định hạn chế và trạng thái triển khai, đồng thời dự định sẽ chia sẻ tài liệu đó trong quý 1 năm 2023. |
| Nhiều quảng cáo trong một Khung bảo vệ | Yêu cầu hiển thị nhiều nhà quảng cáo trong một Khung bảo vệ trong một phiên đấu giá | Hiện tại, chúng tôi vẫn không tích cực phát triển yêu cầu này. Tuy nhiên, chúng tôi hoan nghênh thêm ý kiến phản hồi nếu những bên trong hệ sinh thái coi tính năng này là quan trọng. |
| Gói web | Có những yêu cầu và hoạt động hỗ trợ nào được lên kế hoạch cho Gói web có khung bảo vệ? | Hiện tại, chúng tôi chưa có thông tin cập nhật về việc liệu đây có phải là yêu cầu bắt buộc trong tương lai hay không. Mọi thay đổi sẽ được thông báo trước và sẽ không được thực thi trước khi cookie của bên thứ ba không được dùng nữa. Vui lòng xem thông tin giải thích này để biết trạng thái hiện tại. |
API Bộ nhớ dùng chung
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Bộ nhớ dùng chung cho công nghệ quảng cáo | Sự không chắc chắn về việc sử dụng bộ nhớ dùng chung cho các trường hợp sử dụng Công nghệ quảng cáo | Bộ nhớ dùng chung và API tổng hợp riêng tư có thể được dùng cho nhiều loại mục đích đo lường cần đo lường bộ nhớ trên nhiều trang web. Bạn có thể xem một số ví dụ tại đây. Chúng tôi dự định rằng các nhà cung cấp giải pháp đo lường và DSP (Bộ xử lý tín hiệu kỹ thuật số) và giải pháp đo lường sẽ trở thành nhà tích hợp chính cho các trường hợp sử dụng quảng cáo. |
KHỐI
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| (Cũng được báo cáo trong Quý 3) 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. | Câu hỏi 4: Nội dung cập nhật cho quý 4: Sau khi thảo luận về các lệnh gọi GitHub và PrivacyCG, hành vi mà chúng tôi đã thống nhất là Cookie phân vùng được đặt trên cookie của bên thứ nhất sẽ sử dụng khoá phân vùng của (A,A) trong đó "A" là trang web cấp cao nhất. Chúng tôi sẽ ghi lại hành vi này dựa trên phần giải thích và thông số kỹ thuật. |
| Quản lý cookie | Có công cụ nào để quản lý/kiểm soát cookie của bên thứ nhất hoặc bên thứ ba không? | Bạn có thể sử dụng Công cụ của Chrome cho nhà phát triển và NetLog để thử nghiệm những trang web có bật tính năng chặn cookie của bên thứ ba. Cả hai công cụ đều báo cáo khi cookie bị chặn do cấu hình của người dùng. Chúng tôi hoan nghênh ý kiến phản hồi về các loại trang web kiểm tra bổ sung mà bạn muốn xem. |
FedCM
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| IdP yêu cầu bạn phải biết về bên bị hạn chế để cho phép một phiên | Vấn đề khi người dùng đang cố đăng nhập vào Feide IdP từ hai RP khác nhau | Chúng tôi đang thảo luận các giải pháp tiềm năng cho vấn đề này tại đây. |
| Khả năng tương thích | Các lo ngại về tác động của FedCM đối với mối quan hệ giữa người dùng và các trang web mà họ đăng nhập bằng FedCM và "khả năng tương tác" giữa các trang web | FedCM hướng đến việc tiếp tục hỗ trợ các dịch vụ nhận dạng liên kết hiện đang dựa vào cookie của bên thứ ba sau khi cookie của bên thứ ba bị xoá khỏi Chrome. Chúng tôi dự kiến rằng FedCM sẽ chỉ là một lựa chọn cho các dịch vụ đó; các nhà cung cấp danh tính (IdP) và các bên phụ thuộc (RP) có thể tự do sử dụng các công nghệ khác có thể phù hợp hơn với nhu cầu của họ. Có vẻ như mối quan hệ giữa người dùng-RP và "khả năng tương tác" là do sự hiểu lầm về đề xuất FedCM. FedCM giao cho IdP quyết định thông tin cần chia sẻ với RP và dưới hình thức nào sau khi người dùng đã chọn đăng nhập vào trang web của RP đó. FedCM không yêu cầu nhà cung cấp danh tính (IdP) "tạo một giá trị nhận dạng riêng biệt có gán biệt danh cho mỗi [RP] mà người dùng xác thực". Thay vào đó, FedCM được mở cho mỗi IdP để chọn chia sẻ giá trị nhận dạng thực tế của người dùng, phiên bản trên từng trang web của giá trị nhận dạng đó hoặc một số phiên bản khác của thông tin này. (Quy cách của FedCM xác định mối tương quan giữa nhiều trang web là một rủi ro về quyền riêng tư liên quan đến API và thảo luận về giá trị nhận dạng có chỉ dẫn (trên mỗi trang web) để giảm thiểu rủi ro có thể xảy ra. Tuy nhiên, quyết định có sử dụng giá trị nhận dạng được định hướng sẽ do IdP thực hiện, không phải do trình duyệt áp đặt.) FedCM cũng đã cung cấp cho người dùng lựa chọn về danh tính. Ví dụ: nếu người dùng có nhiều danh tính có cùng IdP (ví dụ: hồ sơ công việc và hồ sơ cá nhân), thì FedCM sẽ cung cấp cách thức để người dùng chọn danh tính họ muốn sử dụng để đăng nhập vào trang web của bên bị hạn chế. Ngoài ra, mỗi bên bị hạn chế sẽ tự quyết định IdP nào sẽ hỗ trợ trên trang web của mình. Một khía cạnh của quyết định đó là xem xét cơ chế mà IdP dựa vào, cho dù đó là FedCM hay một công nghệ khác. Xin nhắc lại, trình duyệt không quy định những lựa chọn này cho bên bị hạn chế hoặc nhà cung cấp danh tính (IdP). |
Chống nội dung rác và lừa đảo
API Mã thông báo trạng thái riêng tư
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Xử lý bot | Điều gì sẽ xảy ra nếu nhà phát hành phát hiện thấy Mã thông báo trạng thái riêng tư được cấp cho các bot? | Để mã thông báo được cấp cho bot tồn tại trong hệ sinh thái lâu dài, nhà phát hành nên thay đổi khoá dùng để ký mã thông báo thường xuyên để mã thông báo cũ được phát hành theo logic phát hành có thể bị hỏng hết hạn và trang web sử dụng mã thông báo mới hơn theo logic phát hành mới. |
| Gửi biểu mẫu cùng trang web | Có thể sử dụng Mã thông báo trạng thái riêng tư để gửi biểu mẫu trên cùng một trang web có liên quan đến việc điều hướng toàn trang (ví dụ: Content-Type: application/x-www-form-urlcoded) thay vì yêu cầu từ API tìm nạp/XMLHttpRequest không? | Tính năng này hiện không được hỗ trợ trong phiên bản đầu tiên của Mã thông báo trạng thái riêng tư. Chúng tôi hoan nghênh ý kiến phản hồi của hệ sinh thái YouTube nếu khách hàng có nhu cầu cao về trường hợp sử dụng này. |
| Xác minh phía máy chủ | Câu hỏi về việc Mã thông báo trạng thái riêng tư có thể được xác minh ở phía máy chủ hay không | Mã thông báo được sử dụng cho nhà phát hành. Sau đó, nhà phát hành sẽ tạo một hồ sơ sử dụng mã có thể chứa chính mã thông báo đó hoặc một số giá trị đã ký có được từ mã thông báo. Máy chủ có thể sử dụng hồ sơ sử dụng mã đó để xác minh tính xác thực của mã thông báo. Theo dự kiến, các hệ sinh thái của nhà phát hành sẽ đưa ra những tiêu chuẩn riêng về cách diễn giải hồ sơ sử dụng mã. |