Báo cáo hằng quý cho quý 4 năm 2022 tóm tắt ý kiến phản hồi của hệ sinh thái về các đề xuất liên quan đến Hộp cát về quyền riêng tư và phản hồi của Chrome.
Trong cam kết với CMA, Google đã đồng ý công bố các báo cáo hằng quý về quy trình tương tác với các bên liên quan đối với các đề xuất về Hộp cát về quyền riêng tư (xem đoạn 12 và 17(c)(ii) của Cam kết). Các báo cáo tóm tắt phản hồi về Hộp cát về quyền riêng tư này được tạo bằng cách tổng hợp phản hồi mà Chrome nhận được từ nhiều nguồn như được liệt kê trong phần tổng quan về phản hồi, bao gồm nhưng không giới hạn ở: Vấn đề trên GitHub, biểu mẫu phản hồi được cung cấp trên privacysandbox.com, các cuộc họp với các bên liên quan trong ngành và diễn đàn về tiêu chuẩn web. Chrome hoan nghênh ý kiến phản hồi nhận được từ hệ sinh thái và đang tích cực tìm hiểu cách tích hợp những điều đã học được vào các quyết định thiết kế.
Các chủ đề phản hồi được xếp hạng theo mức độ phổ biến trên mỗi API. Việc này được thực hiện bằng cách tổng hợp số lượng ý kiến phản hồi mà nhóm Chrome đã nhận được về một chủ đề nhất định và sắp xếp theo thứ tự giảm dần về số lượng. Các chủ đề phản hồi phổ biến được xác định bằng cách xem xét các chủ đề thảo luận từ các cuộc họp công khai (W3C, PatCG, IETF), phản hồi trực tiếp, GitHub và các câu hỏi thường gặp xuất hiện thông qua các nhóm nội bộ và biểu mẫu công khai của Google.
Cụ thể hơn, chúng tôi đã xem xét biên bản cuộc họp của các tổ chức tiêu chuẩn web và đối với ý kiến phản hồi trực tiếp, chúng tôi đã xem xét bản ghi của Google về các cuộc họp 1:1 với các bên liên quan, email mà các kỹ sư cá nhân nhận được, danh sách gửi thư API và biểu mẫu phản hồi công khai. Sau đó, Google đã điều phối giữa các nhóm tham gia vào nhiều hoạt động tiếp cận này để xác định mức độ phổ biến tương đối của các chủ đề mới nổi liên quan đến từng API.
Nội dung giải thích về phản hồi của Chrome đối với ý kiến phản hồi được phát triển từ các câu hỏi thường gặp đã xuất bản, phản hồi thực tế đối với các vấn đề do các bên liên quan nêu ra và xác định một quan điểm cụ thể cho mục đích của bài tập báo cáo công khai này. Phản ánh trọng tâm hiện tại của hoạt động phát triển và thử nghiệm, chúng tôi đã nhận được các câu hỏi và ý kiến phản hồi cụ thể liên quan đến API Chủ đề, API Fledge và API Báo cáo phân bổ.
Phản hồi nhận được sau khi kết thúc khoảng thời gian báo cáo hiện tại có thể chưa được Chrome xem xét.
Bảng thuật ngữ về từ viết tắt
- Cookie có trạng thái được phân vùng độc lập (CHIPS)
- Cookie có trạng thái được phân vùng độc lập
- DSP (Bộ xử lý tín hiệu kỹ thuật số)
- Nền tảng bên cầu
- FedCM
- Quản lý thông tin xác thực liên kết
- Khung hình/giây
- 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
- IETF (Lực lượng chuyên trách kỹ thuật Internet)
- Lực lượng chuyên trách kỹ thuật Internet
- IP
- Địa chỉ giao thức Internet
- openRTB
- Đặt giá thầu theo thời gian thực
- QUÁ GIỜ
- Bản dùng thử Origin
- PatCG
- Nhóm cộng đồng về công nghệ quảng cáo riêng tư
- RP
- Bên phụ thuộc
- SSP
- Nền tảng bên cung
- TEE (Môi trường thực thi đáng tin cậy)
- Môi trường thực thi đáng tin cậy
- UA
- Chuỗi tác nhân người dùng
- UA-CH
- Thông tin mô tả của ứng dụng tác nhân người dùng
- W3C
- World Wide Web Consortium
- WIPB
- Cố tình làm ngơ địa chỉ IP
Ý kiến phản hồi chung, không có API/Công nghệ cụ thể
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| (Cũng được báo cáo trong quý 3) Mức độ hữu ích đối với các loại bên liên quan |
Lo ngại rằng các công nghệ Hộp cát về quyền riêng tư sẽ ưu tiên các nhà phát triển lớn hơn và các trang web chuyên biệt (nhỏ hơn) sẽ đóng góp nhiều hơn các trang web chung chung (lớn hơn) | Câu trả lời của chúng tôi không thay đổi so với câu trả lời cho câu hỏi 3: "Google đã cam kết với CMA rằng sẽ thiết kế và triển khai các đề xuất về Hộp cát về quyền riêng tư theo cách không làm méo mó cạnh tranh bằng cách ưu tiên hoạt động kinh doanh của chính Google, đồng thời xem xét tác động đến hoạt động cạnh tranh trong 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 làm việc chặt chẽ với CMA để đảm bảo rằng hoạt động của mình tuân thủ các cam kết này. Trong quá trình 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 loại 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à ý 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 kiểm thử định lượng và ủng hộ CMA phát hành 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ơ hội để nhận xét về các phương pháp được đề xuất." |
| (Cũng được báo cáo trong quý 3) Yêu cầu cung cấp tài liệu |
Yêu cầu cung cấp thêm tài nguyê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 quý 4: Chúng tôi rất vui khi 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à chúng tôi cam kết tiếp tục cung cấp thêm tài liệu để các nhà phát triển có thể hiểu được cách các công nghệ mới có thể giúp ích cho 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 một bài đánh giá chi tiết 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 buổi 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 buổi hỏi đáp với trưởng nhóm sản phẩm và kỹ thuật để 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 Chỉ số quan trọng chính của trang web? | Giảm độ trễ ở mức tối thiểu là mục tiêu thiết kế chính của các API Hộp cát về quyền riêng tư. Hiện tại, chúng tôi dự kiến độ trễ API sẽ tác động tối thiểu đến các Chỉ số quan trọng về trang web của trang web, vì phần lớn API được gọi sau khi hiển thị ban đầu của trang web. Chúng tôi tiếp tục theo dõi và cải thiện để giảm thêm độ trễ cho từng API, đồng thời khuyến khích bạn tiếp tục thử nghiệm và phản hồi. Độ trễ trong quy trình đặt giá thầu theo thời gian thực được đề cập trong phần FLEDGE trong mục "Hiệu suất của phiên đấu giá FLEDGE" |
| Khả năng tương tác | 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 hoạt động theo dõi trên nhiều trang web, đồng thời hỗ trợ các nhu cầu của hệ sinh thái web. Chúng tôi muốn đạt được mục tiêu này bằng cách loại bỏ các công nghệ trình duyệt cũ cho phép hoạt động theo dõi trên nhiều trang web (chẳng hạn như cookie của bên thứ ba) và thay vào đó là các công nghệ mới được thiết kế riêng để hỗ trợ các trường hợp sử dụng cụ thể. Các đề xuất về 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ế dữ liệu rời khỏi thiết bị của người dùng. Các đề xuất này không đặt ra hạn chế kỹ thuật đối với khả năng chia sẻ hoặc xử lý dữ liệu của trang web sau khi thu thập từ trình duyệt. Do đó, các công nghệ này không ngăn cản các công ty ký kết thoả thuận "quản lý dữ liệu" hoặc bất kỳ mối quan hệ hợp đồng tương tự nào khác. Tương tự, 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ọ thông qua các phương tiện khác. Để rõ ràng, Google đã cam kết áp dụng các 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 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 phù hợp
Chủ đề
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Ảnh hưởng đến thứ hạng trên Google Tìm kiếm | Yêu cầu cung cấp thông tin về việc liệu việc hỗ trợ API Chủ đề của một 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ư không điều phối hoặc yêu cầu tổ chức Tìm kiếm sử dụng thứ hạng trang làm phần thưởng để 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 sử dụng quyết định của một trang web về việc chọn không sử dụng API Chủ đề 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 tiện ích cho nhiều bên liên quan. | Nhật ký 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 trang và/hoặc nội dung) trong quá trình phân loại Chủ đề. Mọi điểm cải tiến về tiện ích đều phải được cân nhắc dựa trên rủi ro về quyền riêng tư và hành vi sai trái. Ví dụ: đối với siêu dữ liệu nói riêng, một số rủi ro bao gồm: – Các trang web sửa đổi siêu dữ liệu cấp trang để mã hoá các ý nghĩa khác nhau (và có thể nhạy cảm) thành chủ đề; – Các trang web sửa đổi siêu dữ liệu cấp trang để trình bày sai chủ đề nhằm thu lợi tài chính; – Các trang web tự động sửa đổi siêu dữ liệu cấp trang để theo dõi trên 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ị rất cao, do đó làm giảm giá trị của các tín hiệu khác dựa trên mối quan tâm của bên thứ nhất. | Chúng tôi vẫn giữ nguyên câu trả lời cho câu hỏi 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 đối với 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ể chưa đủ hữu ích để mang lại giá trị. Trong mọi trường hợp, chúng tôi luôn nỗ lực cải thiện hệ thống phân loại. Chúng tôi dự kiến hệ thống phân loại sẽ phát triển theo kết quả thử nghiệm và ý kiến đóng góp của hệ sinh thái." |
| Cập nhật cách phân loại | Danh sách cá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ến phản hồi về hệ thống phân loại hữu ích nhất cho hệ sinh thái. Hệ thống phân loại có trong đề xuất ban đầu về API Chủ đề được thiết kế để hỗ trợ 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 hệ thống phân loại. Ví dụ: Chrome có thể sử dụng khái niệm về giá trị thương mại cho mỗi chủ đề để xác định danh mục nào sẽ được đưa vào các lần lặp lại trong tương lai. |
| Hiệu suất của thuật toán phân loại theo chủ đề theo khu vực | Thuật toán phân loại chủ đề hoạt động kém trong các miền theo khu vực | Chúng tôi luôn nỗ lực cải thiện bộ phân loại. Dựa trên ý kiến phản hồi mà chúng tôi nhận đượ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, việc này sẽ giúp tăng phạm vi trên toàn cầu và cải thiện độ chính xác. Để giải thích, hoạt động phân loại API Chủ đề có hai thành phần liên quan: (1) Danh sách ghi đè chứa 10.000 trang web hàng đầu và chủ đề của các trang web đó, và (2) mô hình học máy trên thiết bị phân loại tên máy chủ thành 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à trình phân loại có thể hoạt động kém. |
| Kỷ nguyên một tuần | Kỷ nguyên một tuần là quá dài đối với những người dùng muốn đưa ra quyết định trong thời gian ngắn hơn. | Chúng tôi đang tích cực xem xét độ dài phù hợp của epoch và rất mong nhận được ý kiến phản hồi khác về epoch phù hợp hơn cho hệ sinh thái. |
| Truy xuất tiêu đề HTTP | Lo ngại rằng không có đủ thông tin về việc truy xuất tiêu đề HTTP của các chủ đề | Chúng tôi đang tiến hành xử lý các tiêu đề và fetch(). Chúng tôi cũng có thông tin tại đây. Chúng tôi cũng đã thêm thông tin về skipObservation vào phần giải thích. |
| Chủ đề chỉ nhằm giúp nhà quảng cáo chứ không phải người dùng | Chủ đề/Hộp cát về quyền riêng tư có vẻ là một phương pháp tập trung vào ngành. Lợi ích cho người dùng không rõ ràng như lợi ích cho ngành. | Chúng tôi tin rằng lợi ích đối với người dùng là Topics hỗ trợ quảng cáo dựa trên mối quan tâm, giúp giữ cho web luôn miễn phí và mở. Chúng tôi cũng tin rằng Topics 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 các phương pháp kém hiệu quả hơn , kém bảo mật, không minh bạch và người dùng không thể đặt lại hoặc kiểm soát một cách thực tế. Nhiều công ty đang tích cực thử nghiệm API Chủ đề và Hộp cát. Chúng tôi cam kết cung cấp các công cụ để nâng cao quyền riêng tư và hỗ trợ web. Gần đây, Nhóm cấu trúc kỹ thuật của W3C đã công bố quan điểm ban đầu về Topics API. Chúng tôi sẽ phản hồi quan điểm này một cách công khai. Ở giai đoạn này, vì Google đã nhận được câu hỏi từ hệ sinh thái về những gì bài đánh giá này có thể ngụ ý đối với việc phát triển và ra mắt Topics API, nên chúng tôi muốn xác nhận lại kế hoạch cung cấp API này trong Chrome phiên bản ổn định trong năm nay. Mặc dù đánh giá cao ý kiến đóng góp của Nhóm cấu trúc kỹ thuật W3C, nhưng Google cho rằng điều quan trọng nhất là tiếp tục nỗ lực phát triển và thử nghiệm Chủ đề sau khi 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ỉ sang các trang web khác mà không được phép | Thiết kế của Topics API khiến dữ liệu của một nhà xuất bản (và thậm chí là một nhóm nhỏ nhà xuất bản) khó có thể bị rò rỉ theo bất kỳ cách nào. 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. | Trong 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 phân tích hệ sinh thái về giá trị của Chủ đề cho nhà quảng cáo. CMA sẽ giám sát quá trình kiểm thử và công bố kết quả. CMA sẽ xem xét dữ liệu, phân tích và phương pháp luận. Hệ sinh thái này nên chia sẻ ý kiến phản hồi với Google và CMA. |
| Chủ đề và FLEDGE | Yêu cầu cung cấp 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 hoàn thiện hướng dẫn tích hợp và sẽ bổ sung thêm thông tin chi tiết về cách triển khai. |
| Xếp hạng tuỳ chỉnh cho phương thức gọi chủ đề | Cho phép người gọi điều chỉnh thứ hạng | Thách thức với thứ hạng chủ đề tuỳ chỉnh hoặc giá trị cho từng công nghệ quảng cáo là đây có thể trở thành cơ chế mà một công nghệ quảng cáo có thể ảnh hưởng đến các chủ đề được trả về, do đó là một vectơ vân tay số. |
| Danh sách mức độ ưu tiên của phương thức gọi chủ đề | Cho phép phương thức gọi cung cấp danh sách chủ đề được xếp hạng theo mức độ ưu tiên mà Topics API sẽ trả về dựa trên điều kiện. | Chúng tôi hiện đang tiếp tục thảo luận về ý tưởng này và hoan nghênh ý kiến đóng góp khác. |
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à bên quyết định cuối cùng cho 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 thành phần và cấp cao nhất. Mỗi người mua và người bán trong phiên đấu giá thành phần đều biết người bán cấp cao nhất và có thể chọn đặt giá thầu hay không. |
| Không đủ người tham gia thử nghiệm FLEDGE | Yêu cầu khuyến khích 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à không khuyến khích các phương pháp thay thế xâm phạm quyền riêng tư như 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, trong mối quan hệ hợp tác chặt chẽ với sự hướng dẫn của CMA và ICO. Ngoài ra, thử nghiệm chức năng FLEDGE đã chứng minh được độ ổ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 đã phát hành 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ể hỗ trợ các trường hợp sử dụng quan trọng cho ngành quảng cáo sau khi ngừng sử dụng cookie của bên thứ ba. 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 để ngăn chặn hoạt động theo dõi (xem UA-CH, Bảo vệ IP và Giảm thiểu hoạt động theo dõi lượt thoát) 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 thành giải pháp nhắm mục tiêu khả thi duy nhất, mà là cam kết hợp tác với các cơ quan quản lý và ngành để 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ệ học máy | Chúng tôi sẽ hỗ trợ thêm hướng dẫn về cách sử dụng các trường hợp 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 cần phải giúp người kiểm thử tìm ra những cách hữu ích nhất để áp dụng các công nghệ Hộp cát về quyền riêng tư. Chúng tôi đã bắt đầu phát hành hướng dẫn liên quan cụ thể đến việc sử dụng nhiều khía cạnh của 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 có tên 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ể sử dụng các tín hiệu này cho công nghệ học máy. Chúng tôi dự định tiếp tục phát hành các hướng dẫn như vậy trong tương lai. |
| Truy vấn máy chủ khoá-giá trị (K/V) FLEDGE | Tại sao máy chủ K/V có thể truy vấn công khai? | Máy chủ K/V nhằm 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 truy cập từ nơi các phiên đấu giá FLEDGE đó thực thi, tức là trên thiết bị của người dùng, yêu cầu máy chủ này phải được cung cấp công khai. Chỉ một bên đã có khoá mới có thể truy xuất giá trị được lưu trữ trong máy chủ K/V. Vì vậy, nếu một công nghệ quảng cáo chỉ 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ị đó. |
| Làm cách nào để nhắm mục tiêu theo ngày/giờ? | Hỗ trợ đối tượng ngày trong hàm logic đặt giá thầu. | Có nhiều cách để thực hiện việc này. Người mua có thể yêu cầu người bán cung cấp ngày và giờ hiện tại. Người bán cần 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 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 bối cảnh trong tín hiệu theo người mua. Người bán có thể truyền tín hiệu này đến tập lệnh generateBid của người mua. |
| Lựa chọn của người dùng | Người dùng có thể chọn chặn mẫu quảng cáo theo nhà quảng cáo khi mẫu quảng cáo được 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 quảng cáo trong Chrome. Đối với các quảng cáo cụ thể, công nghệ quảng cáo có liên quan là bên phù hợp nhất để cung cấp các chế độ kiểm soát về mẫu quảng cáo sẽ hiển thị hoặc cách chọn mẫu quảng cáo. |
| Tiến trình rõ ràng hơn | Yêu cầu cung cấp thêm thông tin về khả năng sử dụng 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 có hàng rào. | Chúng tôi dự định sẽ công bố tiến trình chi tiết hơn trong quý 1. |
| Báo cáo sự nhầm lẫn | Yêu cầu làm rõ hơn về cách hoạt động của báo cáo FLEDGE với các API khác như Khung có hàng rào và API tổng hợp riêng tư. | Chúng tôi dự định sẽ xuất bản một bài viết giải thích về hoạt động tương tác giữa Private Aggregation API, FLEDGE và Khung được phân vùng trong những tuần tới. |
| Đặt giá thầu theo thời gian thực và FLEDGE | Hướng dẫn về cách FLEDGE tích hợp với tính năng đặt giá thầu theo thời gian thực tiêu chuẩn. | Hai yếu tố chính khiến khả năng đặt giá thầu theo thời gian thực của công nghệ quảng cáo trở nên phức tạp 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 sẽ gửi thông tin cập nhật và nội dung 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ử cho thấy phiên đấu giá FLEDGE có độ trễ cao | Chúng tôi rất cảm ơn các báo cáo của người kiểm thử đã chia sẻ kết quả và trường hợp sử dụng của họ, đồng thời đã chia sẻ một số đề xuất về cách cải thiện hiệu suất của FLEDGE. Song song với đó, chúng tôi đã thêm công cụ vào trình duyệt để cho phép nhà phát triển chẩn đoán tốt hơn nguyên nhân khiến phiên đấu giá bị chậm và đã giải quyết một cách có hệ thống các nguồn chính gây ra độ trễ được quan sát. Các điểm cải tiến gần đây bao gồm thời gian chờ cho các phiên đấu giá chậm, công nghệ lọc bên đặt giá thầu nhanh, một cách để sử dụng lại các công việc nhỏ FLEDGE để tránh phải trả chi phí khởi động và công việc đang diễn ra để 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à các lần tìm nạp mạng. Chúng tôi dự kiến việc tối ưu hoá độ trễ sẽ tiếp tục là một cuộc trò chuyện liên tục giữa các nhà phát triển Chrome và người kiểm thử FLEDGE dựa trên trải nghiệm thực tế của họ khi sử dụng API. |
| Giới hạn bộ nhớ về kích thước Nhóm đối tượng có cùng mối quan tâm | Yêu cầu tăng giới hạn kích thước của một nhóm mối quan tâm từ 50 kB. | Chúng tôi đang tích cực xem xét yêu cầu này và mong nhận được ý kiến phản hồi về giá trị giới hạn phù hợp. |
| Kết hợp dữ liệu được phân phát bằng FLEDGE với cookie của bên thứ nhất | FLEDGE có hỗ trợ 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 một người 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 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ư. Trong những tuần tới, chúng tôi dự định sẽ chia sẻ hướng dẫn tích hợp có thêm thông tin chi tiết về cách FLEDGE hỗ trợ tích hợp với dữ liệu của bên thứ nhất. |
| Giá trị k-anonymity | Giá trị "K" đến "k-anon" sẽ được quyết định như thế nào và liệu giá trị này có được xuất bản không? | Giá trị "K" vẫn đang được hoàn thiện và chúng tôi sẽ chia sẻ thêm thông tin khi kế hoạch phát triển. Chúng tôi muốn tìm hiểu thêm về cách giá trị k không xác định có thể cản trở việc chuẩn bị cho FLEDGE và việc xác định phạm vi huấn luyện mô hình học máy. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung về chủ đề này. |
| Hỗ trợ nhiều SSP | FLEDGE sẽ hỗ trợ nhiều SSP như thế nào? | FLEDGE hỗ trợ phiên đấu giá cho 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 rằng logic đặt giá thầu DSP sẽ được 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 nhận thêm ý kiến phản hồi về lý do khiến điều này có thể là mối lo ngại đối với DSP. |
| prebid.js | Tiến trình hỗ trợ prebid.js trong FLEDGE là gì? | Chỉ các 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 thực thể Đặt giá thầu trước. |
| Hàm do người dùng xác định trong FLEDGE | FLEDGE sẽ hỗ trợ hàm do người dùng xác định (UDF) như thế nào? Đây là những 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 nội dung giải thích tại đây. Chúng tôi vẫn đang hoàn thiện tính năng này nên rất mong nhận được ý kiến phản hồi bổ sung về các trường hợp sử dụng. |
| Nới lỏng quy tắc ràng buộc cùng nguồn gốc đối với tài nguyên của Nhóm đối tượng có cùng 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 đối với các tài nguyên Nhóm mối quan tâm để cho phép một số trường hợp sử dụng công nghệ quảng cáo | 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.Hạn chế này tồn tại để ngăn chặn một số hành vi khai thác nhất định của kẻ tấn công, như đã giải thích tại đây. |
| Quyền sở hữu interestGroup | 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 đối tượng, chứ không phải cách tạo đối tượng. Chúng tôi đang thảo luận về các phương pháp tiềm năng và hoan nghênh ý kiến đóng góp khác. |
| Hết hạn khoá máy chủ Key Value | Thảo luận về việc 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 các cách xử lý việc hết hạn khoá và mong nhận được ý 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 |
|---|---|---|
| Lưu lượng truy cập từ Bản dùng thử theo nguyên gốc | Lưu lượng truy cập hiện tại của Phiên bản thử nghiệm theo nguyên gốc không đủ để tiến hành kiểm thử tiện ích. | Chương trình Thử nghiệm nguồn gốc hiện tại dành cho những người chơi trong hệ sinh thái để tiến hành kiểm thử chức năng nhằm đảm bảo API hoạt động như dự kiến. Chúng tôi hiểu rằng sẽ cần nhiều lưu lượng truy cập hơn để kiểm thử 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ư trở nên hoàn thiện hơn. Theo tiến trình thử nghiệm hiện tại, việc này sẽ diễn ra khi chúng tôi ra mắt và cung cấp công nghệ cho 100% lưu lượng truy cập Chrome (tức là khi công nghệ cho các trường hợp sử dụng được cung cấp rộng rãi) vào quý 3 năm 2023 (xem tiến trình cập nhật trên privacysandbox.com). Chúng tôi hoan nghênh mọi ý kiến phản hồi bổ sung về việc thử nghiệm trường hợp sử dụng cần thêm lưu lượng truy cập. |
| Sự trùng lặp về chức năng của các 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, ví dụ: Attribution Reporting API và Private Aggregation API. | Chúng tôi đang nỗ lực cải thiện tài liệu để làm rõ các trường hợp sử dụng khác nhau của các API này và rất mong nhận được ý kiến phản hồi bổ sung về những khía cạnh còn thiếu nội dung giải thích. Ví dụ: Attribution Reporting API dành riêng để hỗ trợ đo lường lượt chuyển đổi, trong khi Private Aggregation API và Shared Storage là các API dùng cho nhiều mục đích nhằm 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 | Thông tin làm rõ về số lần hệ thống thử gửi yêu cầu báo cáo nếu không thành công. | Chúng tôi đã công bố hướng dẫn về vấn đề 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 đầu tiên không thành công, báo cáo sẽ được thử lại sau 5 phút. Sau lần thất bạ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. |
| Độ trễ khi báo cáo | Độ trễ báo cáo dự kiến là bao lâu? | Chúng tôi mong muốn nhận được thêm ý kiến phản hồi từ hệ sinh thái về mọi sự cố chậm trễ trong báo cáo mà họ đang gặp phải trong khi chúng tôi thu thập dữ liệu để đánh giá thêm về những sự cố chậm trễ này. |
| Tải trước trang | Mô hình phân bổ ARA có hoạt động trên các trang kết xuất trước không? | Việc đăng ký phân bổ sẽ bị 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 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 A/B 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á các tham số A/B dưới dạng khoá bằng API tổng hợp, sau đó nhận báo cáo tóm tắt về giá trị lượt chuyển đổi theo các nhóm khoá đó. |
| (Cũng được báo cáo trong quý 3) Lượt chuyển đổi trên nhiều 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ư có 2 đích đến trở lên | Thông tin cập nhật quý 4: Chúng tôi đã phát hành một đề xuất để xoá quy định 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 trong quý 3) Chế độ cài đặt ngày hết 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 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 biệt khoảng thời gian hết hạn và khoảng thời gian báo cáo để giảm thiểu sự đánh đổi giữa độ trễ báo cáo và thời điểm hết hạn lượt chuyển đổi. Tính năng này hiện đã được ra mắt trong phiên bản M110. |
| Hành vi gian lận và lạm dụng | Yêu cầu của nhà quảng cáo và nhà tiếp thị về việc có thể phân đoạn 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, điều này cũng sẽ cung cấp thông tin chi tiết hơn về các phương pháp quảng cáo gian lận tiềm ẩn | Ý kiến phản hồi này đang được tích cực thảo luận tại đây và chúng tôi hoan nghênh những ý kiến đóng góp khác. |
| (Cũng được báo cáo trong Quý 3) Độ trễ báo cáo ở cấp sự kiện | Độ trễ từ 2 đến 30 ngày trong báo cáo cấp sự kiện có thể là quá lâu đối với một số trường hợp sử dụng. | Báo cáo cấp sự kiện có cá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 thông tin này bằng cách sử dụng tham số "expiry". Công nghệ quảng cáo có thể định cấu hình thời gian hết hạn (tối thiểu là 1 ngày) để nhận báo cáo tiềm năng trong vòng chưa đến 2 ngày. Chúng tôi giới hạn độ chi tiết của thời gian hết hạn ở mức 1 ngày để 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 theo thời gian. Ngoài ra, chúng tôi cho phép bạn đặt các thông số "thời gian hết hạn" độc lập cho cấp sự kiện và báo cáo tổng hợp. Hãy xem ở đây. Ngoài ra, Google Ads sẽ không nhận được bất kỳ 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 nhận được thông qua API Báo cáo phân bổ. |
| Yêu cầu về cùng một nguồn gốc báo cáo | Yêu cầu xoá yêu cầu về 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 bổ sung 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 có xảy ra trước/sau một số giờ nhất định do nhà quảng cáo đặt hay không | Attribution Reporting API hỗ trợ việc đặt khoảng thời gian hết hạn và mức độ ưu tiên cho mô hình phân bổ nguồn. Khi 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 riêng biệt với một lượt chuyển đổi xảy ra sau X ngày. |
| Mô phỏng tiếng ồn | Yêu cầu có thể mô phỏng số lượt chuyển đổi khác nhau trên mỗi bộ chứa để hiểu được tác động đối với những nhà quảng cáo có ít lượt chuyển đổi hơn | Chúng tôi đang tìm cách bổ sung các cách mô phỏng điều này trong các phiên bản Noise Lab trong tương lai. Chúng tôi luôn 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ó vẫn được gử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 ở chế độ 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 thuộc phạm vi cam kết mà CMA chấp nhận. |
| Phạm vi cung cấp dữ liệu | Lo ngại rằng 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 đề cập trong phần Ý kiến phản hồi chung trong mục "Khả năng tương tác", trong đó có thêm thông tin chi tiết về Cam kết của Google. Thứ hai, về 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 sự nhiễu có thể tác động nhiều hơn đến các lát cắt dữ liệu nhỏ hơn. Tuy nhiên, có một số biện pháp giảm thiểu có thể áp dụng: ví dụ: các phương pháp 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. Tuy nhiên, vẫn chưa rõ liệu các kết luận dựa trên các lát cắt dữ liệu rất nhỏ (như một hoặc hai giao dịch mua) có ý nghĩa gì đối với nhà quảng cáo hay không. Trong thời gian thử nghiệm theo nguyên gốc, Google đã khuyến khích người kiểm thử 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 để có thể đưa ra ý kiến phản hồi cụ thể hơn về vấn đề này. |
Giới hạn hoạt động theo dõi ẩn
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 |
|---|---|---|
| Tạm hoãn tính năng Giảm thiểu 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ề việc Giảm thiểu tác nhân người dùng. | Chúng tôi đã giải quyết ý kiến phản hồi này trong báo cáo đầy đủ trong phần "Mối lo ngại của các bên liên quan" thuộc mục "Hoạt động tương tác của Google với CMA". |
| Tạm hoãn tính năng Giảm thiểu 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 User-Agent cho đến khi triển khai Tác nhân người dùng có cấu trúc (SUA) | Nhóm Google Ads đã đề xuất thêm Trình đại diện người dùng có cấu trúc (xem thông số kỹ thuật) vào OpenRTB vào tháng 10 năm 2021 và tính năng này đã đượ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à có sẵn hiện nay, như minh hoạ trong bài đăng trên blog của Scientia Mobile về cách sử dụng UA-CH và API WURFL để tạo SUA. |
###
Thông tin mô tả của ứng dụng tác nhân người dùng
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Kiểm thử UA-CH bằng các kỹ thuật chống theo dõi ẩn khác | Hướng dẫn về cách kiểm thử tất cả các API Hộp cát về quyền riêng tư và 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 kiểm thử 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 vân tay kỹ thuật số, thay vì các Đề xuất Hộp cát còn lại. Điều này giải quyết thực tế là một số biện pháp chống tạo vân tay số (tức là Ngân sách quyền riêng tư, Bảo vệ IP và Giảm thiểu tính năng theo dõi lượt thoát) sẽ được phát triển đầy đủ và sẵn sàng ra mắt công khai chỉ sau khi cookie của bên thứ ba không được dùng nữa. Mặc dù các biện pháp chống vân tay số đó sẽ không được đưa vào quy trình kiểm thử định lượng, nhưng chúng sẽ phải chịu sự đánh giá định tính dựa trên các thực tế có sẵn tại thời điểm tạm ngưng. |
| (Cũng được báo cáo trong quý 2) Hiệu suất |
Mối lo ngại về độ trễ khi nhận gợi ý thông qua Critical-CH (trên lần tải trang đầu tiên) | Xem phần dành riêng cho UA-CH ở bên dưới |
| Chưa có đủ ý kiến phản hồi | Phản hồi từ hệ sinh thái về thay đổi đối với UA-CH có thể chưa đủ, dẫn đến lo ngại về việc hệ sinh thái chưa nhận thức được đầy đủ. | Chúng tôi đã chủ động chia sẻ kế hoạch để đảm bảo việc triển khai diễn ra cẩn thận và giảm thiểu sự gián đoạn. Chúng tôi đã trình bày kế hoạch Giảm thông tin trong trường tác nhân người dùng và UA-CH API cho Nhóm cộng đồng chống gian lận của W3C vào ngày 18 tháng 3 năm 2022, cũng như cho cả Nhóm làm việc về thanh toán trên web và Nhóm quan tâm đến bảo mật thanh toán trên web vào ngày 20 tháng 1 năm 2022. Không có vấn đề đáng kể nào được nêu ra trong hoặc sau khi trình bày. Google đã chủ động trao đổi với hơn 100 nhà điều hành trang web để nhận ý kiến phản hồi. Ngoài ra, Google cũng đã sử dụng các kênh Blink-Dev để công bố việc triển khai việc giảm số lượng 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 | Các mối lo ngại được nêu ra liên quan đến thời điểm triển khai và mức độ sẵn sàng của ngành | Xem phần dành riêng cho UA-CH ở bên dưới |
| Trạng thái của 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 "Mixed signals" (Tín hiệu hỗn hợp). |
Bảo vệ địa chỉ IP (trước đây là Gnatcatcher)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Chọn sử dụng hoặc không sử dụng | Quyền riêng tư về địa chỉ IP là chế độ chọn sử dụng hay không sử dụng? | Mục tiêu của chúng tôi là cung cấp dịch vụ Bảo vệ quyền sở hữu trí tuệ cho tất cả người dùng. Với mục tiêu đó, chúng tôi hiện đang đánh giá các lựa chọn bảo vệ quyền sở hữu trí tuệ do người dùng chọn. |
| 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 để kết nối các 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 sử dụng tính năng Bảo vệ IP không? | Như đã phát hành trước đó, ban đầu, tính năng Bảo vệ quyền sở hữu trí tuệ sẽ tập trung vào hoạt động theo dõi trong bối cảnh bên thứ ba, tức là các 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 | Các công ty có thể thiết lập biện pháp chống gian lận bằng tính năng Bảo vệ quyền sở hữu trí tuệ như thế nào? | Chúng tôi nhận thấy tầm quan trọng của địa chỉ IP như một tín hiệu cho các nỗ lực chống gian lận trên web hiện nay. Trong Cam kết của chúng tô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 biện pháp Bảo vệ quyền sở hữu trí tuệ mà không nỗ lực hợp lý để hỗ trợ trang web thực hiện các biện pháp chống thư rác và chống gian lận. Một trong những ưu tiên hàng đầu của chúng tôi là tìm hiểu cách tính năng Bảo vệ tài sản trí tuệ tác động đến các trường hợp sử dụng và khả năng phát hiện hành vi gian lận, để chúng tôi có thể đầu tư thêm vào các công nghệ bảo vệ quyền riêng tư giúp các công ty duy trì sự an toàn trên web. Chúng tôi khuyến khích bạn gửi ý kiến phản hồi và đề xuất ý kiến về các đề xuất mới nhằm hỗ trợ nhu cầu của các công ty bảo mật và chống gian lận, ngay cả khi các tín hiệu thay đổi theo thời gian. |
| Hành vi gian lận và lạm dụng | Tính năng bảo vệ tài sản trí tuệ có bao gồm tính năng Bảo vệ 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 đảm bảo an toàn cho web. 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 trong việc chống hành vi sai trái cần được thiết kế. Chúng tôi hy vọng có thể giảm thiểu tác động đến các biện pháp bảo vệ chống lại các cuộc tấn công từ chối dịch vụ (DoS) thông qua cả thiết kế của chính tính năng Bảo vệ quyền sở hữu trí tuệ và thông qua các giải pháp chống hành vi sai trái mới. Vì tính năng Bảo vệ IP ban đầu tập trung vào các dịch vụ nhúng của bên thứ ba, nên một số bên liên quan đã cho biết rằng tính năng này sẽ có tác động hạn chế đến việc bảo vệ khỏi các cuộc tấn công từ chối dịch vụ cho các trang web của bên thứ nhất. Tuy nhiên, chúng tôi vẫn tiếp tục yêu cầu ý kiến phản hồi công khai để đá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ụ nhúng của bên thứ ba. Song song với đó, chúng tôi đang khám phá các cơ chế phản hồi về hành vi sai trái và chặn ứng dụng để 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 người dùng đó. |
| Lọc nội dung | Lọc nội dung bằng tính năng Bảo vệ địa chỉ IP | Mỗi công ty có nhu cầu riêng 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 và do đó 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 muốn điều chỉnh nội dung và tăng mức độ tương tác có thể sử dụng cookie của bên thứ nhất hoặc cookie phân đoạn của bên thứ ba (CHIP) để tìm hiểu mối quan tâm của người dùng và các lượt 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ối quảng cáo phù hợp cho người dùng phù hợp có thể kết hợp FLEDGE và Chủ đề, chẳng hạn như để phân phối kết quả quảng cáo tương tự như hiện tại bằng 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 tìm hiểu cách xây dựng các tính năng mới giúp bảo đảm quyền riêng tư vào tính năng Bảo vệ IP, chẳng hạn như thông tin vị trí địa lý không chính xác, để hỗ trợ thêm việc lọc nội dung khi các cơ chế hiện có có thể chưa đủ. Chúng tôi hoan nghênh ý kiến phản hồi bổ sung về các 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 tính năng Bảo vệ quyền sở hữu trí tuệ. |
| (Cũng được báo cáo trong quý 3) Các trường hợp sử dụng tính năng vị trí địa lý |
Tính năng Bảo vệ quyền sở hữu trí tuệ có thể ngăn các trường hợp sử dụng thông tin 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 thông tin vị trí địa lý. | Thông tin cập nhật quý 4: 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 hợp pháp cho địa chỉ IP. Chúng tôi đang tìm ý kiến phản hồi của hệ sinh thái về độ chi tiết của tính năng Định vị vị trí qua IP tại đây. |
Hạn mức 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 | Các ví dụ khác để các bên liên quan có thể dự đoán những điều có thể bị giới hạn sau khi triển khai Ngân sách quyền riêng tư | Đề xuất về Ngân sách quyền riêng tư vẫn đang được thảo luận và chưa có trình duyệt nào triển khai. Ngày sớm nhất của phạm vi cung cấp được điều chỉnh theo tỷ lệ thể hiện ngày sớm nhất mà bạn có thể thực thi Ngân sách quyền riêng tư. Điều này sẽ không xảy ra trước khi loại bỏ cookie của bên thứ ba vào năm 2024. Hiện tại, 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 chi tiết về đề xuất này khi đề xuất đó được hoàn thiện hơ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 có thể giúp chúng tôi phát triển đề xuất này. |
Tăng cường 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 trong 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 | Thông tin cập nhật quý 4: Chúng tôi đã phát hành FPS để kiểm thử cục bộ, bao gồm cả quy trình gửi tập hợp 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 hai cuộc họp công khai dành cho nhà phát triển về FPS để tiếp tục giải đáp các câu hỏi liên quan đến trường hợp sử dụng cho tập hợp con được liên kết. Nhà phát triển nên thử nghiệm chức năng FPS để đưa ra ý kiến phản hồi về mức độ ảnh hưởng của giới hạn miền cho tập hợp con được liên kết đến khả năng hữu dụng của FPS cho các trường hợp sử dụng của họ. Chúng tôi đã làm rõ trong các cuộc gọi WICG rằng Chrome cam kết cung cấp một giải pháp hữu ích, đồng thời cân nhắc đến quyền riêng tư của người dùng. Do đó, chúng tôi rất mong nhận được ý kiến phản hồi của cộng đồng về các trường hợp sử dụng cụ thể có thể chịu ảnh hưởng của giới hạn về miền để nhóm có thể xem xét các cách giải quyết những trường hợp sử dụng này trong khi 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 sai trái | Điều gì sẽ xảy ra nếu một miền được thêm vào một nhóm mà họ không đồng ý? | Chúng tôi đã xuất bản hướng dẫn gửi Bộ của 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 hoạt động quản lý thay đổi về tập hợp sẽ tuân theo và tuân thủ 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. Điều này sẽ giúp giảm thiểu rủi ro này. |
| Giảm thiểu hành vi sai trái | Lo ngại về việc có thể lợi dụng cấu trúc Nhóm bên thứ nhất | 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à tích cực thu thập ý kiến đóng góp khác 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 liệu bạn có nên sử dụng Tập hợp 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 nhắm mục tiêu quảng cáo cho Tập hợp bên thứ nhất. Bạn nên sử dụng các API quảng cáo có sẵn cho các trường hợp sử dụng như vậy. |
| (Cũng được báo cáo trong quý 3) Chính sách | Lo ngại rằng FPS không nhất quán với các cam kết của CMA về "Luật hiện hành về việc bảo vệ dữ liệu", dựa trên cơ sở là GDPR không đặt ra giới hạn về số lượng trang web trong một nhóm, trong khi FPS dự kiến giới hạn là 3 | Câu trả lời của chúng tôi không thay đổi so với quý 3: "Google tiếp tục cam kết với CMA về việc thiết kế và triển khai các đề xuất về Hộp cát về quyền riêng tư theo cách không làm méo mó cạnh tranh bằng cách tự ưu tiên hoạt động kinh doanh của chính Google, đồng thời xem xét tác động đến hoạt động cạnh tranh trong 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ả về quyền riêng tư và việc tuân thủ các nguyên tắc bảo vệ dữ liệu như nêu trong Luật hiện hành về việc bảo vệ dữ liệu. Mối lo ngại được nêu không cho thấy bất kỳ sự không tương thích nào với GDPR. Chúng tôi tiếp tục hợp tác chặt chẽ với CMA để đảm bảo rằng hoạt động của mình tuân thủ các cam kết này". |
| Đề xuất thay thế | Nhóm được xác thực theo GDPR | Ngoài ý kiến phản hồi của hệ sinh thái về đề xuất sử dụng "Nhóm được xác thực theo GDPR", Chrome còn lo ngại về những hạn chế sau đây của đề xuất thay thế này:
Kể từ khi đề xuất thay thế này được đưa ra, Chrome đã cập nhật đề xuất về Tập hợp bên thứ nhất và phát hành nguyên tắc gửi để tạo tập hợp mới. |
Fenced Frames API
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Các hạn chế về Khung được phân vùng trong thời gian chờ | Những quy định hạn chế hiện tại đối với Khung được phân vùng trong giai đoạn Thử nghiệm về nguồn gốc là gì? | Chúng tôi đang xây dựng 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 chia sẻ tài liệu này trong quý 1 năm 2023. |
| Nhiều quảng cáo trong một Khung có hàng rào | Yêu cầu hiển thị nhiều nhà quảng cáo trong một Khung được phân vùng trong một phiên đấu giá | Hiện tại, chúng tôi không tích cực phát triển yêu cầu này, nhưng rất mong nhận được ý kiến phản hồi bổ sung nếu các bên tham gia hệ sinh thái coi tính năng này là quan trọng. |
| Gói web | Những yêu cầu và hỗ trợ nào được lên kế hoạch cho Gói web có Khung được phân vùng? | 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 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 chúng tôi ngừng sử dụng cookie của bên thứ ba. Vui lòng xem nội dung giải thích này để biết trạng thái hiện tại. |
Shared Storage API
| 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 xung quanh 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ạn có thể sử dụng API Bộ nhớ dùng chung và API Tổng hợp riêng tư 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ự đoán rằng DSP và nhà cung cấp giải pháp đo lường sẽ là bên tích hợp chính cho các trường hợp sử dụng quảng cáo. |
CHIPs
| 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 về phân vùng | Thêm yêu cầu 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. | Thông tin cập nhật quý 4: Sau khi thảo luận về các lệnh gọi GitHub và PrivacyCG, chúng tôi đã thống nhất rằng cookie được 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 là (A,A), trong đó "A" là trang web cấp cao nhất. Chúng tôi sẽ ghi nhận hành vi này trong 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ể dùng Công cụ dành cho nhà phát triển của Chrome và NetLog để kiểm thử các trang web đã 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 thời điểm 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 của bạn về những loại thông tin kiểm tra bổ sung mà bạn muốn thấy trên các trang web. |
FedCM
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| IdP yêu cầu kiến thức về RP để cho phép một phiên | Vấn đề khi người dùng cố gắng đăng nhập vào IdP Feide từ hai RP khác nhau | Chúng tôi đang thảo luận về các giải pháp tiềm năng cho vấn đề này. |
| Khả năng tương tác | Mối 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, cũng như "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 FedCM sẽ chỉ là một lựa chọn cho các dịch vụ như vậy; nhà cung cấp danh tính (IdP) và bên phụ thuộc (RP) có thể tự do sử dụng các công nghệ khác phù hợp hơn với nhu cầu của họ. Có vẻ như những lo ngại liên quan đến mối quan hệ giữa người dùng và RP và "khả năng tương tác" là do hiểu lầm về đề xuất FedCM. FedCM để cho các IdP quyết định thông tin cần chia sẻ với RP và ở dạng 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 IdP "tạo một giá trị nhận dạng được gán biệt danh duy nhất cho mỗi [RP] mà người dùng xác thực". Thay vào đó, FedCM cho phép mỗi IdP chọn có chia sẻ giá trị nhận dạng thực tế của người dùng, phiên bản giá trị nhận dạng đó trên mỗi trang web hay một số phiên bản khác của thông tin này hay không. (Thông số kỹ thuật của FedCM xác định mối tương quan trên 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ỉ định (cho mỗi trang web) như một biện pháp giảm thiểu có thể áp dụng. Tuy nhiên, quyết định sử dụng giá trị nhận dạng được chỉ định là do IdP quyết định, chứ không phải do trình duyệt áp đặt.) FedCM cũng đã cung cấp lựa chọn cho người dùng liên quan đến danh tính. Ví dụ: nếu người dùng có nhiều danh tính với cùng một IdP (ví dụ: hồ sơ công việc và hồ sơ cá nhân), thì FedCM sẽ cung cấp cách để người dùng chọn danh tính mà họ muốn sử dụng để đăng nhập vào trang web của RP. Ngoài ra, mỗi RP tự quyết định những 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à một IdP dựa vào, cho dù đó là FedCM hay một công nghệ khác. Xin nhắc lại rằng trình duyệt không chỉ định những lựa chọn này cho RP hoặc IdP. |
Chống hành vi gian lận và nội dung rác
Private State Tokens API
| 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 bên 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 bot? | Để tránh việc mã thông báo được cấp cho bot vẫn tồn tại trong hệ sinh thái trong thời gian dài, bên phát hành phải thường xuyên xoay vòng các khoá mà họ dùng để ký mã thông báo để mã thông báo cũ được cấp theo logic phát hành có thể bị hỏng sẽ hết hạn và các trang web sẽ sử dụng mã thông báo mới hơn có logic phát hành mới nhất. |
| Lượt gửi biểu mẫu trên cùng một 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 liên quan đến thao tác điều hướng toàn trang (tức là Content-Type: application/x-www-form-urlencoded) 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 rất mong nhận được ý kiến phản hồi từ hệ sinh thái nếu có nhu cầu cao đối với trường hợp sử dụng này. |
| Xác minh phía máy chủ | Câu hỏi về việc liệu có thể xác minh Mã thông báo trạng thái riêng tư phía máy chủ hay không | Mã thông báo được sử dụng với bên phát hành, sau đó bên phát hành sẽ tạo một bản ghi sử dụng mã thông báo có thể chứa chính mã thông báo đó hoặc một số giá trị đã ký bắt nguồn từ mã thông báo. Máy chủ có thể sử dụng bản ghi sử dụng mã thông báo đó để xác minh tính xác thực của mã thông báo. Chúng tôi dự kiến các hệ sinh thái của bên phát hành sẽ đưa ra các tiêu chuẩn khác nhau về cách diễn giải bản ghi sử dụng mã thông báo. |