Báo cáo hằng quý cho quý 2 năm 2023 tóm tắt ý kiến phản hồi của hệ sinh thái về các đề xuất liên quan đến Hộp cát về quyền riêng tư và phản hồi của Chrome.
Trong khuôn khổ cam kết với CMA, Google đã đồng ý công bố báo cáo hằng quý về quy trình tương tác với các bên liên quan đối với các đề xuất về Hộp cát về quyền riêng tư (tham khảo đoạn 12 và 17(c)(ii) của Cam kết). Các báo cáo tóm tắt 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ủ đề, Protected Audience và Attribution Reporting.
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ể
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Quản lý dữ liệu và tuân thủ quy định | Hướng dẫn về hệ sinh thái để sử dụng Hộp cát về quyền riêng tư tuân thủ các yêu cầu theo quy định. | Giống như mọi công nghệ mới, mỗi công ty đều có trách nhiệm đảm bảo rằng việc sử dụng Hộp cát về quyền riêng tư của họ tuân thủ luật pháp; Google không thể tư vấn pháp lý cho các công ty khác. Tuy nhiên, chúng tôi nhận thấy đây là một lĩnh vực quan trọng đối với hệ sinh thái. Đối với mỗi API, chúng tôi đã xuất bản tài liệu kỹ thuật chuyên sâu để cung cấp cơ sở cho việc đánh giá pháp lý cần thiết. Chúng tôi cũng đang nỗ lực cung cấp thêm tài liệu để hỗ trợ các công ty tuân thủ các yêu cầu của quy định. |
| Đề xuất kiểm thử định lượng CMA | Thông tin khác về đề xuất kiểm thử định lượng của CMA | Chúng tôi đang hợp tác với CMA để thiết kế các thử nghiệm nhằm cung cấp thông tin về tác động của việc ngừng sử dụng cookie của bên thứ ba và việc triển khai các đề xuất về Hộp cát về quyền riêng tư đối với hệ sinh thái. Vào tháng 4, CMA đã công bố hướng dẫn cấp cao về những điều cần biết trong giai đoạn Thử nghiệm và Thử nghiệm, sau đó là hướng dẫn chi tiết vào tháng 6. Bạn nên chia sẻ trực tiếp với CMA về các câu hỏi hoặc ý kiến phản hồi liên quan đến đề xuất Thử nghiệm định lượng của CMA. |
| Chế độ kiểm thử do Chrome hỗ trợ | Thông tin và nội dung giải thích thêm về lịch thử nghiệm | Vào ngày 18 tháng 5, chúng tôi đã xuất bản một bài đăng trên blog để chia sẻ thêm thông tin về hai chế độ thử nghiệm do Chrome hỗ trợ. Đây chưa phải là thông tin chính thức và chúng tôi sẽ công bố thêm hướng dẫn triển khai khi tiến hành trong quý 3 năm 2023. |
| Bộ nhớ được phân vùng | Liệu bộ nhớ được phân vùng có được sử dụng trong quá trình kiểm thử do Chrome hỗ trợ không? | Tính năng phân vùng bộ nhớ sẽ được cung cấp cho tất cả người dùng trước khi thử nghiệm ngừng sử dụng cookie của bên thứ ba. Do đó, chiến dịch này sẽ được bật cho tất cả các nhóm thử nghiệm. Các trang web sẽ có thể bật phiên bản dùng thử ngừng sử dụng để lấy lại bộ nhớ chưa phân vùng trong khoảng thời gian này. |
| Hỗ trợ sản xuất | Chrome có quy trình nào để hỗ trợ các vấn đề kỹ thuật và vấn đề cấp cao liên quan đến Hộp cát về quyền riêng tư ảnh hưởng đến hệ sinh thái không? | Google cung cấp nhiều kênh để cho phép các công nghệ quảng cáo báo cáo vấn đề và chuyển lên cấp trên nếu cần. Vui lòng xem tổng quan về ý kiến phản hồi để biết thêm thông tin về các diễn đàn công khai và riêng tư dành cho ý kiến phản hồi và báo cáo lên cấp trên. |
| Tiến trình đăng ký | Thời hạn đăng ký hiện tại quá ngắn | Chúng tôi vẫn đang đánh giá thời hạn thực thi và muốn nghe ý kiến của hệ sinh thái về tiến trình phù hợp hơn. |
| Mã số D-U-N-S | Thông tin khác về yêu cầu về số D-U-N-S để đăng ký và chứng thực | Người tham gia có thể xem các yêu cầu để nhận mã số DUNS trên trang web của Dun và Bradstreet. Các yêu cầu sẽ khác nhau tuỳ theo thị trường, vì vậy, người tham gia cần nhớ kiểm tra trang web của thị trường cụ thể mà họ quan tâm. Tuy nhiên, nhìn chung, người tham gia sẽ cần cung cấp thông tin cơ bản về doanh nghiệp của họ, chẳng hạn như tên doanh nghiệp, địa chỉ và thông tin liên hệ của chủ sở hữu hoặc người quản lý doanh nghiệp. Người tham gia cũng có thể được yêu cầu cung cấp thông tin tài chính, chẳng hạn như doanh thu hằng năm của doanh nghiệp. Sau khi bạn hoàn tất đơn đăng ký, D&B sẽ xem xét đơn đăng ký đó và cấp Số D-U-N-S nếu đơn đăng ký được phê duyệt. |
| Chuyển từ giai đoạn dùng thử theo nguyên gốc sang giai đoạn phát hành rộng rãi | Việc chuyển đổi từ Bản dùng thử theo nguyên gốc sang Bản phát hành công khai có ảnh hưởng đến những người thử nghiệm Bản dùng thử theo nguyên gốc hiện tại không? | Kể từ tháng 7, các nhà kiểm thử sẽ có thể truy cập vào các API đo lường và mức độ liên quan khi chúng được phát hành rộng rãi. Điều này sẽ tạo ra sự trùng lặp giữa thời điểm phát hành thử nghiệm và thời điểm phát hành công khai. |
| Nghiên cứu của AdExchanger | Thông tin khác về phương pháp khảo sát | Bản khảo sát yêu cầu người trả lời ước tính tỷ lệ đồng bộ hoá và doanh thu cho doanh nghiệp của họ. Phương pháp trả lời các câu hỏi riêng lẻ của người trả lời là tuỳ thuộc vào họ. |
| Giá trị tham số | Giá trị của các tham số như độ nhiễu, ngưỡng tính năng ẩn danh và ngân sách quyền riêng tư được xác định như thế nào? | Tài liệu giải thích trên GitHub này nêu ra các nguyên tắc chung hơn đằng sau các API Hộp cát về quyền riêng tư. Chúng tôi vẫn đang hoàn thiện nhiều giá trị và rất mong nhận được ý kiến phản hồi của bạn về chủ đề này. |
Hiển thị nội dung và quảng cáo phù hợp
Chủ đề
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Bảo đảm quyền riêng tư | Nghiên cứu đánh giá Topics API về việc bảo đảm quyền riêng tư | Chúng tôi đang tích cực tham gia cộng đồng nghiên cứu, trình bày nghiên cứu của mình về các thuộc tính quyền riêng tư của Topics API trong các bài báo, báo cáo và bản trình bày hội thảo. Chúng tôi rất vui khi thấy nhiều thành viên bên ngoài cộng đồng nghiên cứu tham gia vào lĩnh vực này. Topics API bảo vệ người dùng khỏi hoạt động theo dõi chung trên web bằng cách khiến việc theo dõi người dùng trên quy mô lớn trở nên quá khó khăn. Những bài báo này cho thấy rằng chúng tôi đang thực hiện thành công việc này bằng Topics API. Cookie này đảm bảo quyền riêng tư hơn cookie của bên thứ ba và bảo vệ người dùng trong khi vẫn hỗ trợ các trang web mà họ thích truy cập. |
| Hệ thống phân loại chủ đề chưa đủ chi tiết | Hệ thống phân loại chủ đề rộng không bao gồm các chủ đề chi tiết hơn, bao gồm cả chủ đề theo khu vực. | Để phản hồi ý kiến phản hồi trước đó của hệ sinh thái, chúng tôi đã xuất bản một bài đăng trên blog vào ngày 15 tháng 6, trong đó nêu chi tiết về một hệ thống phân loại mới được cập nhật, kết hợp nhiều điểm cải tiến dựa trên ý kiến phản hồi của hệ sinh thái. Trong quá trình xây dựng hệ thống phân loại sửa đổi, chúng tôi đã hợp tác với một số công ty trong hệ sinh thái, chẳng hạn như Raptive (trước đây là CafeMedia) và Criteo. Hệ thống phân loại mới cập nhật sẽ xoá những danh mục mà chúng tôi nhận thấy ít hữu ích, thay vào đó là những danh mục phù hợp hơn với mối quan tâm của nhà quảng cáo, đồng thời duy trì cam kết loại trừ những chủ đề có thể nhạy cảm. Chúng tôi khuyến khích hệ sinh thái xem xét hệ thống phân loại mới nhất và đưa ra ý kiến phản hồi về những thay đổi. |
| Quy trình cập nhật hệ thống phân loại và thuật toán phân loại | Thông tin khác về cách phát hành bộ phân loại và cách phân loại chủ đề, cũng như cách các công ty có thể chuẩn bị cho những nội dung cập nhật như vậy. | Như đã chia sẻ trong bài đăng trên blog gần đây, chúng tôi dự kiến hệ thống phân loại này sẽ phát triển theo thời gian và việc quản lý hệ thống phân loại này cuối cùng sẽ chuyển sang một bên bên ngoài đại diện cho các bên liên quan trên toàn ngành. Chúng tôi cũng đã chia sẻ kế hoạch tăng cường trong nhóm topics-announce. |
| Tác động đối với tín hiệu của bên thứ nhất | Việc tăng số lượng Chủ đề trong bản cập nhật gần đây về Hệ thống phân loại có thể rất có giá trị và 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. | Trong báo cáo quý 1 năm 2023, CMA nhận xét rằng: "Chúng tôi hiểu rằng Google đã thảo luận về hệ thống phân loại mới được đề xuất với một số người tham gia thị trường trong chuỗi cung ứng công nghệ quảng cáo. Mặc dù một số nhà xuất bản lớn cho biết rằng việc sử dụng chủ đề hiệu quả hơn sẽ làm tăng áp lực cạnh tranh đối với các giải pháp dựa trên dữ liệu của bên thứ nhất, nhưng quan điểm ban đầu của chúng tôi là việc sử dụng chủ đề hiệu quả hơn sẽ tốt hơn cho khả năng cạnh tranh tổng thể – đặc biệt là khả năng của các nhà xuất bản nhỏ hơn trong việc tiếp tục kiếm tiền từ khoảng không quảng cáo sau khi ngừng sử dụng cookie của bên thứ ba". Quan điểm của chúng tôi phù hợp với nhận xét này của CMA. |
| Mức độ hữu ích đối với các loại bên liên quan | Các công nghệ quảng cáo đóng vai trò là SSP và DSP có thể có lợi thế đáng kể so với các bên khác trong hệ sinh thái. | Chúng tôi vẫn giữ nguyên câu trả lời như các quý trước: "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 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ố 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 hợp tác chặt chẽ với CMA để đảm bảo rằng hoạt động của chúng tôi 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 đã làm việ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à tạo cơ hội để họ nhận xét về các phương pháp đề xuất". |
| Chủ đề con | Khi tiêu chí lựa chọn Chủ đề là tần suất truy cập của trình duyệt, liệu sự phân mảnh phân khúc có khiến các chủ đề con không bao giờ lên đầu không? | Chrome hiện đang đánh giá các phương pháp xếp hạng khác và khám phá các tín hiệu khác có thể cải thiện thứ hạng. Chúng tôi sẽ thông báo kế hoạch sửa đổi cho hệ sinh thái trong thời gian thích hợp. |
| Độ nhạy cảm | Mục tiêu của API Chủ đề là đảm bảo thông tin người dùng thu được hoặc bắt nguồn từ API Chủ đề ít nhạy cảm về cá nhân hơn so với thông tin có thể bắt nguồn bằng các phương pháp theo dõi hiện nay. | Chúng tôi tin rằng API Chủ đề mang lại quyền riêng tư cao hơn đáng kể so với các công nghệ hiện tại, hạn chế đáng kể việc xác định lại người dùng và được thiết kế để loại trừ các chủ đề nhạy cảm. Chúng tôi thừa nhận rằng các chủ đề có thể được liên kết hoặc kết hợp với dữ liệu của bên thứ nhất để tạo các danh mục nhạy cảm. Tuy nhiên, chúng tôi tin rằng Topics API là một bước tiến về quyền riêng tư của người dùng và chúng tôi cam kết tiếp tục cải thiện API này. |
| Cấu trúc phân loại | Thêm mã nhận dạng, Phiên bản và cấu trúc siêu dữ liệu khác vào Hệ thống phân loại chủ đề | Hiện tại, trong phản hồi API, chúng ta sẽ thêm mã nhận dạng hệ thống phân loại. Khi chúng ta chuyển sang quản lý lâu dài, bạn nên xem xét đối tượng Chủ đề và thêm siêu dữ liệu bổ sung về việc tạo phiên bản nếu cần. |
| Quyền kiểm soát của nhà xuất bản | Nhà xuất bản có quyền quyết định Chủ đề mà trang web của họ được phân loại. | Việc phân loại sai trang web có thể khiến tín hiệu Chủ đề kém hữu ích hơn một chút về tổng thể, nhưng những trang web cụ thể bị phân loại sai sẽ không bị ảnh hưởng nhiều hơn hay ít hơn so với bất kỳ trang web nào khác. Lý do là thông tin theo bối cảnh của trang web sẽ luôn có sẵn cho các phiên đấu giá trên trang web của họ. Thông tin này sẽ cung cấp thông tin tương đương với chủ đề chính xác, ngay cả trong trường hợp phân loại sai. Bạn có thể gửi ý kiến phản hồi về chủ đề này tại đây. Việc cho phép nhà xuất bản kiểm soát cách phân loại có những rủi ro. Các trang web có thể cố ý phân loại trang web của mình không chính xác, làm giảm tiện ích cho tất cả mọi người hoặc mã hoá các ý nghĩa nhạy cảm trong các chủ đề ít phổ biến, gây tổn hại đến quyền riêng tư của người dùng. |
| Tiện ích Chrome | Cho phép Tiện ích Chrome quản lý và lọc Chủ đề, tương tự như các tiện ích Quản lý cookie hiện tại | Bạn có thể thực hiện việc này như đã thảo luận trên GitHub, nhưng chúng tôi rất mong nhận được ý kiến phản hồi khác từ hệ sinh thái. |
| Chuyển sang Giai đoạn phát hành rộng rãi | Việc chuyển đổi từ Bản dùng thử theo nguyên gốc sang Bản phát hành công khai có ảnh hưởng gì đến Topics API không? | Người dùng chuyển đổi từ phiên bản dùng thử Origin sang phiên bản phát hành công khai sẽ không bị mất dữ liệu. |
| Quyền riêng tư | Tên máy chủ có thể chứa thông tin riêng tư mà API Chủ đề có thể tiết lộ | Chúng tôi có một số biện pháp giảm thiểu để đảm bảo quyền riêng tư, như đã nêu tại đây. |
| Hành vi gian lận và lạm dụng | Cách ngăn chặn hành vi thao túng Chủ đề bằng các lượt truy cập gian lận | Bạn có thể xem thông tin giải thích về biện pháp giảm thiểu tại đây. |
| Thuật toán phân loại chủ đề | Trang web có thể yêu cầu thay đổi cách phân loại Chủ đề không? | Chúng tôi rất mong nhận được ý kiến phản hồi của hệ sinh thái về chủ đề này và rất mong nhận được ý kiến phản hồi của bạn tại đây. |
| Trang web của nhà cung cấp chủ đề | Chỉ định một số trang web lưu trữ nội dung cho nhiều Chủ đề là "Trang web của nhà cung cấp Chủ đề đặc biệt" và huấn luyện các thuật toán phân loại dựa trên các thẻ được cung cấp trên trang web. | Chúng tôi đang thảo luận về đề xuất này tại đây và hoan nghênh ý kiến phản hồi khác. |
Protected Audience API (trước đây là FLEDGE)
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Định hình lưu lượng truy cập | Tác động của hiệu suất đối với hoạt động lọc do SSP điều khiển để tối ưu hoá tải số truy vấn mỗi giây (QPS) | Chúng tôi đã dành khá nhiều thời gian để suy nghĩ về việc định hình lưu lượng truy cập và đề xuất các SSP tận dụng tính năng lưu vào bộ nhớ đệm. |
| Kiểm thử âm lượng | Khó thử nghiệm Protected Audience vì các SSP và DSP đang gặp khó khăn trong việc thu hút lưu lượng truy cập lớn. | Chúng tôi liên tục thu hút các đối tác SSP và DSP để sử dụng và thử nghiệm Protected Audiences. Chúng tôi đã bắt đầu cung cấp rộng rãi Protected Audience API và tin rằng tỷ lệ phần trăm lưu lượng truy cập được bật Protected Audience API sẽ giúp các đối tác dễ dàng thử nghiệm hơn. |
| Độ phức tạp | Việc triển khai các giải pháp Protected Audience đòi hỏi nhiều nỗ lực và chi phí. | Chúng tôi thừa nhận rằng việc áp dụng các công nghệ mới, bao gồm cả Hộp cát về quyền riêng tư, là rất khó khăn. Nhóm Hộp cát về quyền riêng tư đang hợp tác chặt chẽ với nhiều bên liên quan để hướng dẫn và hỗ trợ họ trong những nỗ lực của họ, đồng thời không ngừng đánh giá các yếu tố thúc đẩy khác để hỗ trợ việc áp dụng hệ sinh thái. |
| Môi trường thực thi đáng tin cậy | Hỗ trợ Môi trường thực thi đáng tin cậy (TEE) trong môi trường đám mây không công khai | Mặc dù chúng tôi đang tìm hiểu các lựa chọn có thể hỗ trợ ngoài các giải pháp dựa trên đám mây, nhưng hiện tại, chúng tôi không thể hỗ trợ TEE tại chỗ do các hạn chế về bảo mật tại chỗ sẽ yêu cầu phải mất nhiều thời gian đánh giá Hộp cát về quyền riêng tư. Do các yêu cầu bảo mật của Hộp cát về quyền riêng tư và những thách thức đáng kể khi triển khai trên máy chủ, chúng tôi tin rằng việc tiếp tục mở rộng và cải thiện các hoạt động triển khai trên đám mây (ví dụ: hỗ trợ GCP ngoài AWS) sẽ mang lại nhiều lợi ích nhất cho hệ sinh thái. Tuy nhiên, chúng tôi rất mong nhận được ý kiến phản hồi bổ sung về lý do cần có yêu cầu như vậy. |
| Cơ cấu chi phí | Đề xuất về Dịch vụ đặt giá thầu và Phiên đấu giá sẽ làm tăng chi phí và độ phức tạp cho Công nghệ quảng cáo so với các mô hình phía máy khách. | Chúng tôi hiện đang phát triển một hướng dẫn để ước tính chi phí hỗ trợ quy trình đặt giá thầu và phiên đấu giá trong máy chủ Đặt giá thầu và Phiên đấu giá. Chi phí này sẽ tương quan với mức sử dụng công nghệ quảng cáo, giúp thực hiện một trong những mục tiêu của thiết kế. |
| Dòng thời gian K-Anon | Khi nào các quy tắc ràng buộc về tính k-ẩn danh theo kế hoạch sẽ được thực thi trên `renderUrl` ? | Chúng tôi đang chuẩn bị nội dung giải thích về tiến trình thực thi và sẽ sớm phát hành. |
| Quy định hạn chế về runAdAuction | Chrome có thể hạn chế runAdAuction chỉ gọi được từ trang trên cùng không? |
Mặc dù thiết kế của chúng tôi hỗ trợ đầy đủ việc gọi runAdAuction từ trang trên cùng, nhưng chúng tôi cho rằng việc hạn chế chỉ gọi được từ miền trên cùng sẽ gây hại nhiều hơn cho nhà xuất bản.Chúng tôi đã nhận được ý kiến cụ thể từ hệ sinh thái rằng Hộp cát về quyền riêng tư cần giảm thiểu gánh nặng cho nhà xuất bản và nhà quảng cáo. Ý kiến phản hồi đó phù hợp với nguyên tắc chung về phát triển web, theo đó, chủ sở hữu trang web có thể sử dụng các công cụ của bên thứ ba để vận hành trang web của họ. Mục tiêu của Hộp cát về quyền riêng tư là khuyến khích một hệ sinh thái lành mạnh mà không cần quy định cách hoạt động của nhà xuất bản và công nghệ quảng cáo. Bằng cách cho phép nhà xuất bản chọn cách thức và đối tượng gọi runAdAuction trên trang web của họ, chúng tôi tin rằng mình đã mang đến cho nhà xuất bản sự linh hoạt để tìm ra lộ trình phù hợp nhất với yêu cầu của họ. |
| Hỗ trợ triển khai | Chrome có thể xây dựng hoặc đóng góp vào việc triển khai phiên đấu giá nhiều người bán theo mô hình nguồn mở không? | Hộp cát về quyền riêng tư hướng đến mục tiêu phát triển các công nghệ bảo vệ quyền riêng tư không dựa vào cookie của bên thứ ba hoặc các giá trị nhận dạng khác trên nhiều trang web. Chúng tôi muốn khuyến khích một hệ sinh thái lành mạnh mà không cần quy định cách hoạt động của các công nghệ quảng cáo. Chúng tôi đã xuất bản hướng dẫn về cách hoạt động của các API trên kho lưu trữ GitHub và sẵn sàng khám phá các giải pháp cùng ngành. Chúng tôi không có kế hoạch xây dựng bất kỳ phương thức triển khai cụ thể nào vì nhiệm vụ cốt lõi của chúng tôi là xây dựng các công nghệ nền tảng, chứ không phải chỉ định chiến lược sử dụng các công nghệ đó. Công nghệ của chúng tôi sẽ giúp các công ty công nghệ quảng cáo phục vụ khách hàng tốt nhất bằng các biện pháp bảo vệ quyền riêng tư phù hợp cho người tiêu dùng. |
| Phiên đấu giá nhiều người bán | Chrome có buộc phải chia sẻ một thành phần chiến thắng "theo ngữ cảnh" với các phiên đấu giá thành phần không? | Protected Audience API được thiết kế để giúp các bên bắt đầu phiên đấu giá nhiều người bán có thể chuyển thông tin đến phiên đấu giá thành phần (lưu ý: chỉ trước khi bắt đầu phiên đấu giá). Tuy nhiên, chúng tôi không thấy cách nào để trình duyệt có thể phân biệt xem một thông tin có phải là thông tin phù hợp theo bối cảnh hay không, vì vậy, chúng tôi không thể thực thi việc chặn hoặc yêu cầu một số thông tin nhất định. |
| Lựa chọn ưu tiên của người dùng về việc theo dõi dựa trên sự đồng ý | Công nghệ quảng cáo hỏi PA cách triển khai đúng cách tính năng theo dõi sự đồng ý của người dùng | Chúng tôi xin trả lời như sau, bao gồm cả nội dung chúng tôi đã nêu trong câu hỏi 1: "Đối với 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 mẫu quảng cáo được chọn." Chúng tôi đã thảo luận một số tình huống liên quan đến vấn đề này trong Hội nghị về Protected Audience của WICG vào tháng 5. Chúng tôi rất mong nhận được ý kiến phản hồi và thảo luận bổ sung về vấn đề này. |
| Đối tượng tùy chỉnh | Protected Audience API có hỗ trợ các trường hợp sử dụng SSP liên quan đến việc tạo Đối tượng tuỳ chỉnh không? | Protected Audience API cho phép SSP và các nhà cung cấp công nghệ quảng cáo khác sở hữu và quản lý Đối tượng tuỳ chỉnh. Chúng tôi đang phát triển hướng dẫn bổ sung về cách một SSP có thể tích hợp với API PA và sẽ cung cấp hướng dẫn này cho các SSP cũng như các nhà cung cấp công nghệ quảng cáo khác để hỗ trợ họ tích hợp. |
| Định dạng | Protected Audience API có hỗ trợ video không? | Quảng cáo dạng video được phân phối theo một trong hai cách: dưới dạng VAST XML hoặc HTML (quảng cáo ngoài luồng có thể tải VAST XML vào trình phát video). Người mua có thể trả về một trong hai định dạng này thông qua renderURL. Quy cách VAST đã được cập nhật gần đây để hỗ trợ Attribution Reporting API. Các trang web phân phát quảng cáo dạng video sẽ cần chuẩn bị cho cách phân phối quảng cáo thông qua Protected Audience API. Điều này có nghĩa là đảm bảo thẻ vị trí có thể truyền URL từ iframe Protected Audience đến trình phát video. Đối với Khung hình khoanh vùng, chúng tôi sẽ nỗ lực giải quyết các nhu cầu về video trước khi bắt buộc phải sử dụng Khung hình khoanh vùng không sớm hơn năm 2026. |
| Tốc độ | Trường hợp sử dụng tính năng Điều tiết hoạt động hoạt động như thế nào với Protected Audience API? | Chúng tôi cảm ơn bạn đã nêu ý kiến. Chúng tôi muốn thấy thêm nhiều trường hợp yêu cầu này với thông tin chi tiết hơn từ nhiều đối tác SSP hơn vì đây chủ yếu là mối lo ngại của DSP cho đến nay. |
| Tần suất cập nhật | Tần suất gọi từ dailyUpdate (tối đa 1 lần/nhóm mối quan tâm/ngày) có thể không đủ cho một số trường hợp sử dụng, chẳng hạn như cập nhật thông tin sản phẩm. |
Chúng tôi cảm ơn bạn đã nêu ý kiến. Có các giải pháp khác cho phép công nghệ quảng cáo sử dụng các tín hiệu được làm mới theo nhiều tần suất, chẳng hạn như tra cứu K/V. |
| Kiểm soát chất lượng quảng cáo | Nhà xuất bản triển khai chế độ kiểm soát chất lượng quảng cáo như thế nào? | Hiện tại, Protected Audience API cung cấp chức năng để nhà xuất bản thông báo cho SSP về một số chế độ kiểm soát nhất định mà họ có thể thiết lập trong cấu hình phiên đấu giá, đặt giá thầu trước (tức là danh sách từ chối dựa trên nhãn liên kết với quảng cáo). Chúng tôi hoan nghênh ý kiến phản hồi về mọi chức năng bổ sung mà hệ sinh thái có thể cần đến. |
| Gỡ lỗi | Khi nào chức năng forDebuggingOnly sẽ bị xoá? |
Chúng tôi dự định ngừng sử dụng forDebuggingOnly cho các sự kiện mất do ngừng sử dụng cookie của bên thứ ba. Chúng tôi dự định sẽ ngừng sử dụng forDebuggingOnly cho các sự kiện thắng cuộc muộn nhất vào năm 2026. |
| Nhóm mối quan tâm trên nhiều thiết bị | Đề xuất bật nhóm mối quan tâm trên nhiều thiết bị cho các tác nhân người dùng đã xác thực | Chúng tôi đang đánh giá đề xuất này, nhưng tính đặc thù cao của tính năng nhắm mục tiêu trên nhiều thiết bị gây ra những mối lo ngại đáng kể về quyền riêng tư, như đã thảo luận trong vấn đề này trên GitHub. |
| (Cũng được báo cáo trong quý 1) Tính năng tái tiếp thị linh động | Tôi có thể sử dụng tính năng Tái tiếp thị linh động với Protected Audience API sau khi cookie của bên thứ ba không còn được sử dụng nữa không? | Chúng tôi tin rằng bạn có thể sử dụng Protected Audience cho trường hợp sử dụng này, như giải thích tại đây. |
| Nhấp vào dữ liệu có liên quan | Thêm dữ liệu liên quan đến lượt nhấp vào browserSignals. |
Chúng tôi hiện đang yêu cầu làm rõ thời điểm xảy ra lượt nhấp để đưa ra vị trí sơ bộ. |
| (Cũng được báo cáo trong quý 4 năm 2022) Hàm do người dùng xác định trong Protected Audience | Protected Audience API 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. | Công nghệ quảng cáo đã nêu vấn đề này cũng đề cập rằng họ vẫn đang đánh giá những việc có thể làm với UDF, vì vậy, chúng tôi chưa có ý kiến phản hồi hữu ích nào để phản hồi, ít nhất là cho đến khi có Bản phát hành công khai. |
| Đơn vị tiền tệ | Không được biểu thị số tiền bằng dấu phẩy động. | Chúng tôi đã giải quyết vấn đề này một cách chi tiết tại đây. |
| Các tính năng lựa chọn quảng cáo không phải DSP | Máy chủ quảng cáo đóng vai trò gì trong phiên đấu giá Protected Audience API? | Chúng tôi nhận thấy có yêu cầu về việc Máy chủ quảng cáo tiếp tục cung cấp dịch vụ lựa chọn quảng cáo sau khi đặt giá thầu / tối ưu hoá mẫu quảng cáo động. Chúng tôi hiện đang đánh giá thông tin phân tích chi tiết về khoảng trống giữa Protected Audience API hiện tại và các yêu cầu này. |
| GenerateBid | Hỗ trợ đề xuất của Google Ads về việc trả về nhiều quảng cáo đề xuất cho mỗi nhóm mối quan tâm về quảng cáo từ generateBid và cho các quảng cáo đề xuất đó điểm trong "scoreAd". |
Chúng tôi đang đánh giá vấn đề này. Chúng tôi rất mong nhận được ý kiến phản hồi khác tại đây. |
| Đơn đặt hàng đấu giá | Phiên đấu giá Protected Audience API có bắt buộc phải là phiên đấu giá chạy sau cùng để có thể lấy dữ liệu đầu vào từ kết quả của tất cả các phiên đấu giá khác không? | Không có yêu cầu kỹ thuật nào về việc Protected Audience API phải chạy sau cùng. |
| Điều hướng không do người dùng khởi tạo | Hiển thị thao tác điều hướng không do người dùng khởi tạo | Chúng tôi đang xem xét yêu cầu này và thảo luận về yêu cầu này tại đây . Chúng tôi rất mong nhận được ý kiến phản hồi khác của bạn. |
| Lưu vào bộ nhớ đệm | SSP không được tạo perBuyerSignals của một DSP nhất định từ bộ nhớ đệm nếu trạng thái người dùng thay đổi. | Chúng tôi hiểu rằng việc lưu vào bộ nhớ đệm không phù hợp với mọi trường hợp sử dụng tín hiệu perBuyer và đang đánh giá các lựa chọn khác. Chúng tôi hoan nghênh mọi ý kiến phản hồi bổ sung từ hệ sinh thái về việc liệu việc lưu vào bộ nhớ đệm có phù hợp với các trường hợp sử dụng của họ hay không. |
| Báo cáo phân bổ và Protected Audience | Attribution Reporting API và Protected Audience API có thể hoạt động cùng nhau như thế nào? | Hiện tại, bạn có thể tích hợp Protected Audience API cho cả hai chế độ của Attribution Reporting API (báo cáo cấp sự kiện và báo cáo tóm tắt). Chúng tôi đã chia sẻ thêm thông tin về việc tích hợp Protected Audience API và Attribution Reporting được cải thiện vào ngày 1 tháng 6. Bạn có thể đọc về các tính năng này tại đây. |
| Điểm cuối máy chủ | Điểm cuối của máy chủ có phải là Máy chủ tổng hợp đáng tin cậy trong thiết kế cuối cùng không? | Điểm cuối của máy chủ là một điểm cuối do công nghệ quảng cáo duy trì, độc lập với Máy chủ tổng hợp đáng tin cậy dùng để xử lý các báo cáo đã thu thập và chuyển đổi. Hiện tại, chúng tôi chưa có kế hoạch thay đổi nào đối với điểm cuối báo cáo. Mục đích của thiết kế hiện tại là đảm bảo rằng chính các báo cáo tổng hợp (có tải trọng được mã hoá) không rò rỉ dữ liệu trên nhiều trang web, vì vậy, bạn không cần phải có điểm cuối đáng tin cậy. Một vấn đề khác là các công nghệ quảng cáo khác nhau có thể sẽ có các chiến lược gộp nhóm mong muốn khác nhau. Chúng tôi rất mong nhận được ý kiến phản hồi khác tại đây. |
| WebIDL | Thông số kỹ thuật hiện tại của Protected Audience API không tương thích với thông số kỹ thuật WebIDL. | Chúng tôi đang đánh giá ý kiến phản hồi này và thảo luận về vấn đề này tại đây. |
| Quản lý sự đồng ý | Việc truyền tín hiệu đồng ý sẽ được xử lý như thế nào trong Protected Audience API? | Thông tin theo bối cảnh không nằm trong phạm vi của Protected Audience API. Chúng tôi đang thảo luận về vấn đề này và rất mong nhận được ý kiến phản hồi khác của bạn. |
| Tiếp thị dựa trên tài khoản | Liệu có thể sử dụng các trường hợp sử dụng tiếp thị dựa trên tài khoản không? | Protected Audience API hỗ trợ nhiều trường hợp sử dụng tiếp thị dựa trên đối tượng. Chúng tôi đang tiếp tục tìm hiểu cách Protected Audience API có thể hỗ trợ tốt nhất trường hợp sử dụng cụ thể này và rất mong nhận được ý kiến phản hồi bổ sung về vấn đề này từ hệ sinh thái. |
| Phiên đấu giá thành phần | Những người tham gia phiên đấu giá thành phần sẽ được tính điểm theo tiêu chí nào? | Phiên đấu giá thành phần không trực tiếp tính điểm cho Nhóm mối quan tâm mà thay vào đó, chúng tính điểm cho quảng cáo và giá thầu mà DSP gửi từ hàm generateBid. Hàm generateBid() chạy theo từng nhóm mối quan tâm và DSP trả về nội dung sau khi thực thi generateBid: return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Nội dung đóng góp bên ngoài | Yêu cầu hỗ trợ nội dung đóng góp bên ngoài trên kho mã GitHub của Máy chủ khoá/giá trị. | Chúng tôi đang tìm cách cập nhật các quy trình liên quan để hỗ trợ các nội dung đóng góp bên ngoài cho mã trên GitHub. |
| Quy mô nhóm đối tượng có cùng mối quan tâm | IG có thể hỗ trợ tối đa bao nhiêu khoá? | Giới hạn hiện tại là 50 kb đối với kích thước của một IG và các khoá được tính vào giới hạn đó. Chúng tôi rất mong được thảo luận thêm về giới hạn kích thước. |
| Tạo lô | Làm cách nào để giảm số lượng lệnh gọi máy chủ K/V? | Bạn có thể sử dụng Tiêu đề HTTP Cache-Control để giảm số lượng lệnh gọi K/V. Ví dụ: giá thầu có thể được lưu vào bộ nhớ đệm trên các phiên đấu giá thành phần và cũng trên các vị trí quảng cáo trên một trang. |
| Quản lý phiên bản | Hỗ trợ nhiều phiên bản mã công nghệ quảng cáo | Dịch vụ Đặt giá thầu và Phiên đấu giá sẽ hỗ trợ nhiều phiên bản mã công nghệ quảng cáo. Trong API Đặt giá thầu và Đấu giá, yêu cầu SelectAd có thể chỉ định phiên bản mã dùng cho yêu cầu đấu giá (tức là để đặt giá thầu / đấu giá và báo cáo). |
| Bộ nhớ dùng chung | Hỗ trợ ghi vào Bộ nhớ dùng chung trong Dịch vụ đặt giá thầu và phiên đấu giá. | Hiện tại, Dịch vụ đặt giá thầu và Phiên đấu giá không hỗ trợ Bộ nhớ dùng chung, nhưng chúng tôi hoan nghênh ý kiến phản hồi bổ sung về lý do các trường hợp sử dụng như vậy quan trọng đối với hệ sinh thái. |
| Web-to-app | Hỗ trợ tính năng chia sẻ nhóm mối quan tâm từ web sang ứng dụng. | Hiện tại, việc triển khai Protected Audience API trên Chrome và Android không bao gồm trường hợp web-to-app, nhưng chúng tôi muốn nghe ý kiến của hệ sinh thái về tầm quan trọng của trường hợp sử dụng này. |
| K-Anonymity | Cách xử lý phương án dự phòng K-Anonymity | Chúng tôi đang thảo luận về vấn đề này và hoan nghênh bạn đóng góp thêm ý 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)
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Cấu hình báo cáo cấp sự kiện VTC thay thế | Ý kiến phản hồi về cấu hình báo cáo cấp sự kiện VTC thay thế | Chúng tôi nhận được một số ý kiến phản hồi cho rằng cấu hình cấp sự kiện hiện tại chưa tối ưu. Vì vậy, chúng tôi muốn nhận ý kiến phản hồi của bạn về cấu hình tối ưu trên toàn cầu. Chúng tôi luôn sẵn sàng tiếp nhận ý kiến phản hồi khác về vấn đề này và cho rằng nội dung giải thích linh hoạt ở cấp sự kiện cũng sẽ giúp giải quyết vấn đề này. |
| Cấu hình linh hoạt ở cấp sự kiện | Trạng thái của tính năng cấu hình linh hoạt ở cấp sự kiện là gì? | Chúng tôi đã chia sẻ tài liệu về cấu hình linh hoạt ở cấp sự kiện. Tính năng này vẫn đang trong giai đoạn đề xuất và chúng tôi đang tìm kiếm thêm ý kiến phản hồi về việc liệu tính năng này có mang lại giá trị cho hệ sinh thái hay không. |
| Cấu hình linh hoạt ở cấp sự kiện | Làm cách nào để điều chỉnh các báo cáo xung đột của các bên? | Hầu hết các trường hợp báo cáo đều được giải quyết thông qua việc sử dụng báo cáo tổng hợp, trong khi đề xuất cấu hình cấp sự kiện linh hoạt là dành riêng cho việc tăng tính linh hoạt cho báo cáo cấp sự kiện, thường được dùng cho các trường hợp sử dụng tối ưu hoá. Chúng tôi hoan nghênh mọi nhận xét/ý kiến phản hồi khác về hệ sinh thái liên quan đến trường hợp này. |
| Đăng ký nguồn | Điều gì sẽ xảy ra nếu quá trình đăng ký nguồn diễn ra sau khi đăng ký điều kiện kích hoạt? | Hiện tại, nếu quá trình đăng ký nguồn diễn ra sau khi đăng ký điều kiện kích hoạt, thì nguồn và điều kiện kích hoạt sẽ không thể được phân bổ cho nhau. Đây có vẻ là một trường hợp đặc biệt. Chúng tôi hoan nghênh mọi ý kiến phản hồi khác liên quan đến vấn đề này và sẽ tìm cách giải quyết nếu đây là tình huống mà nhiều công nghệ quảng cáo đang gặp phải. |
| Làm việc với nhiều Công ty quảng cáo | Làm cách nào để DSP có thể sử dụng API Báo cáo phân bổ khi nhà quảng cáo đang làm việc với nhiều công ty quảng cáo? | API này hỗ trợ tính năng chuyển hướng và do đó có thể được sử dụng ngay cả khi nhà quảng cáo đang làm việc với nhiều công ty quảng cáo. Ngoài ra, chúng tôi cũng áp dụng một số hạn chế đối với lệnh chuyển hướng để đảm bảo API đang cải thiện quyền riêng tư. Chúng tôi cũng đã xác định được một giải pháp tiềm năng sử dụng Shared Storage API cho trường hợp cụ thể mà công nghệ quảng cáo đã nêu. Chúng tôi hoan nghênh mọi ý kiến phản hồi khác liên quan đến trường hợp này và sẽ tiếp tục lặp lại dựa trên ý kiến phản hồi đó. |
| Giới hạn về đích đến | Giới hạn đích đến có thể ảnh hưởng đến trường hợp sử dụng quảng cáo tự động làm mới. | Chúng tôi đã thảo luận về vấn đề này trong buổi họp WICG vào ngày 1 tháng 5 và đang tìm ý kiến phản hồi về giới hạn hợp lý. Chúng tôi đã thêm vào nội dung giải thích về Báo cáo phân bổ bằng báo cáo cấp sự kiện để nêu rõ rằng trình duyệt có thể giới hạn số lượng eTLD+1 "đích đến" do các trang web nguồn đại diện. (Xem yêu cầu kéo). |
| Báo cáo phân bổ và Protected Audience | Attribution Reporting API và Protected Audience API có thể hoạt động cùng nhau như thế nào? | Hiện tại, bạn có thể tích hợp Protected Audience API cho cả hai chế độ của Attribution Reporting API (báo cáo cấp sự kiện và báo cáo tóm tắt). Chúng tôi đã chia sẻ thêm thông tin về việc tích hợp Protected Audience API và Attribution Reporting được cải thiện vào ngày 1 tháng 6. Bạn có thể đọc về các tính năng này tại đây. |
| Cấu hình linh hoạt ở cấp sự kiện | Chia sẻ các phương pháp hay nhất để mô phỏng nhiễu khi các tham số có thể định cấu hình. | Chúng tôi đã chia sẻ mã trên GitHub mà mọi người đều có thể sử dụng để đánh giá mức tăng thông tin và tác động của nhiễu đối với mọi cấu hình cấp sự kiện linh hoạt mà họ muốn kiểm thử. Chúng tôi rất mong nhận được ý kiến phản hồi của những người chọn thử nghiệm bằng mã này. |
| Đo lường phân bổ trên web và ứng dụng | Khi nào thì tính năng đo lường phân bổ trên web và nhiều ứng dụng sẽ ra mắt? | Vào ngày 9 tháng 5, chúng tôi đã công bố một thử nghiệm về tính năng Đo lường phân bổ trên nhiều ứng dụng và web thông qua Attribution Reporting API. Mặc dù API đo lường và mức độ liên quan dự kiến sẽ được cung cấp rộng rãi trong Chrome 115, nhưng tính năng Đo lường phân bổ trên web và ứng dụng chéo hiện không được lên kế hoạch cung cấp rộng rãi trong Chrome 115. |
| Loại bỏ lượt chuyển đổi trùng lặp | Làm cách nào để điều chỉnh các giải pháp đo lường độc lập so với ARA? | Theo phương pháp tiêu chuẩn hiện tại, nhà quảng cáo sẽ hợp tác với một nhà cung cấp dịch vụ đo lường độc lập bên thứ ba để loại bỏ báo cáo trùng lặp về lượt chuyển đổi. Chúng tôi đã cung cấp tài nguyên về cách loại bỏ trùng lặp lượt chuyển đổi cho báo cáo ở cấp sự kiện. |
| Mất dữ liệu trong quá trình cập nhật cơ sở dữ liệu Báo cáo phân bổ | Có mất dữ liệu nào khi Chrome cập nhật Cơ sở dữ liệu báo cáo phân bổ như đã thông báo không? | Kể từ Chrome phiên bản ổn định 115, chúng tôi sẽ bắt đầu bật các API Mức độ liên quan và Đo lường cho một số người dùng Chrome theo mặc định. Chúng tôi sẽ tăng phạm vi cung cấp rộng rãi khi theo dõi các vấn đề tiềm ẩn. Mục tiêu là đạt được 100% khả năng cung cấp trong một khoảng thời gian vài tuần, muộn nhất là vào quý 3 năm 2023. Thời điểm này sẽ trùng với thời điểm kết thúc thử nghiệm về Mức độ liên quan và nguồn gốc đo lường. Kể từ tháng 7, người kiểm thử có thể đăng ký sử dụng các API này khi chúng được phát hành rộng rãi. Điều này sẽ tạo ra sự trùng lặp giữa thời điểm cung cấp bản dùng thử gốc và thời điểm cung cấp công khai thông qua việc đăng ký. Mã thông báo dùng thử phiên bản gốc của bạn sẽ có hiệu lực đến hết ngày 19 tháng 9. Tuy nhiên, bạn nên đăng ký các API trước khi mã thông báo hết hạn để chuyển đổi liền mạch khỏi phiên bản dùng thử phiên bản gốc mà không làm gián đoạn bất kỳ thử nghiệm nào đang diễn ra. Như đã đề cập trong thông báo này, dữ liệu được đăng ký từ các phiên bản cũ (M113 trở về trước) sẽ không được di chuyển sau khi cập nhật, do đó có thể bị mất dữ liệu. Mất dữ liệu này sẽ không xuất hiện trong báo cáo gỡ lỗi và chúng tôi sẽ cố gắng tránh mất dữ liệu từ 114 đến 115. |
| Thanh toán | Sử dụng Báo cáo phân bổ cho phương thức thanh toán theo chi phí mỗi lượt chuyển đổi | Như đã nêu trong bài viết này, Attribution Reporting API có thể không phù hợp với nhu cầu thanh toán theo chi phí mỗi lượt chuyển đổi do có sự cố thêm vào báo cáo cấp sự kiện và báo cáo tóm tắt. Các bên tham gia hệ sinh thái nên chia sẻ ý kiến phản hồi về tác động của Attribution Reporting API đối với nhiều mô hình thanh toán trên GitHub. |
Dịch vụ tổng hợp
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Thay đổi về độ trễ của báo cáo tổng hợp | Phản ứng tích cực đối với đề xuất thay đổi độ trễ của báo cáo Tổng hợp từ [10-60 phút] thành [0-10 phút] theo ý kiến phản hồi từ hệ sinh thái | Chúng tôi rất vui khi nhận được phản hồi tích cực về thay đổi được đề xuất và khuyến khích hệ sinh thái tiếp tục gửi ý kiến phản hồi về các đề xuất của chúng tôi. |
| Giải pháp tại chỗ | Có thể triển khai Dịch vụ tổng hợp trong các trung tâm dữ liệu tại chỗ không? | Mặc dù chúng tôi đang tìm hiểu các lựa chọn có thể hỗ trợ ngoài các giải pháp dựa trên đám mây, nhưng hiện tại, chúng tôi không thể hỗ trợ TEE tại chỗ do các hạn chế về bảo mật tại chỗ sẽ yêu cầu phải mất nhiều thời gian đánh giá Hộp cát về quyền riêng tư. Do các yêu cầu bảo mật của Hộp cát về quyền riêng tư và những thách thức đáng kể khi triển khai trên máy chủ, chúng tôi tin rằng việc tiếp tục mở rộng và cải thiện các hoạt động triển khai trên đám mây (ví dụ: hỗ trợ GCP ngoài AWS) sẽ mang lại nhiều lợi ích nhất cho hệ sinh thái. Tuy nhiên, chúng tôi rất mong nhận được ý kiến phản hồi bổ sung về lý do cần có yêu cầu như vậy. |
| Xử lý lại báo cáo cho nhiều khoảng thời gian | Có thể xử lý lại báo cáo cho nhiều khoảng thời gian | Chúng tôi cũng nhận được các yêu cầu tương tự để có thể chia các lô theo nhiều phạm vi ngày. Một đề xuất là cho phép mở rộng mã nhận dạng dùng chung bằng nhãn do công nghệ quảng cáo xác định để báo cáo có thể được chia thành nhiều lô. Chúng tôi đang ở giai đoạn đầu của quá trình đánh giá quy trình này và sẽ cập nhật hệ sinh thái khi đề xuất này phát triển. |
| Ảnh hưởng của Môi trường thực thi đáng tin cậy đối với quyền riêng tư | Thái độ tích cực đối với các tác động của Môi trường thực thi đáng tin cậy đối với quyền riêng tư | Chúng tôi rất vui khi nhận được phản ứng tích cực từ hệ sinh thái về các đề xuất của mình. Chúng tôi rất mong nhận được thêm ý kiến phản hồi khi tiếp tục lặp lại và phát triển. |
| Điều khoản dịch vụ | Hạn chót để chấp nhận điều khoản dịch vụ của Dịch vụ tổng hợp là khi nào? | Mặc dù chúng tôi chưa chỉ định thời hạn chấp nhận các điều khoản và điều kiện, nhưng các công ty trong hệ sinh thái nên chấp nhận các điều khoản và điều kiện sớm nhất có thể để tránh bị chậm trễ trong việc đăng ký. Các công ty nên liên hệ với chúng tôi nếu có thắc mắc. |
| Khám phá khoá | Tính năng khám phá khoá sẽ cho phép người kiểm thử truy vấn báo cáo tổng hợp mà không cần danh sách rõ ràng về các tổ hợp phím có thể dùng để xử lý báo cáo tóm tắt cho mô hình phân bổ trên nhiều mạng nhằm cải thiện hiệu suất và độ chính xác. | Chúng tôi hiện đang tìm hiểu các giải pháp và giải pháp thay thế có thể áp dụng, đồng thời hoan nghênh ý kiến phản hồi khác từ hệ sinh thái. |
Private Aggregation API
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Nguồn gốc của báo cáo | Nguồn gốc báo cáo được xác định như thế nào? | Nguồn gốc báo cáo luôn là nguồn gốc tập lệnh của phương thức gọi Tổng hợp riêng tư. |
| Không gian khoá 128 bit | Thông tin rõ ràng về giới hạn không gian khoá 128 bit | Chúng tôi sẽ làm rõ hơn giới hạn về không gian khoá này và giải quyết sự không nhất quán trên các trang. Bạn nên sử dụng các chiến lược băm để nằm trong không gian khoá này. |
| Mức đóng góp tối đa cho mỗi báo cáo | Giới hạn hiện tại là 20 nội dung đóng góp cho mỗi báo cáo là quá thấp. | Thay vì tăng số lượng nội dung đóng góp tối đa, chúng tôi sẽ cân nhắc việc tách báo cáo thay vì cắt bớt ở giới hạn. Chúng tôi sẽ tham gia vào hệ sinh thái này khi đề xuất này phát triển. |
| Báo cáo phạm vi tiếp cận | Yêu cầu báo cáo phạm vi tiếp cận trên nhiều nền tảng/nhiều thiết bị. Phạm vi tiếp cận là một chỉ số cơ bản của quảng cáo thương hiệu. Nhà quảng cáo dựa vào số liệu ước tính trên nhiều nền tảng/thiết bị cho báo cáo Phạm vi tiếp cận và Tần suất để phân tích chiến dịch và phân bổ mức chi tiêu. Mô hình phạm vi tiếp cận sử dụng cookie của bên thứ ba làm tín hiệu để đo lường quảng cáo hiển thị trong môi trường của bên thứ ba. Do đó, các công nghệ quảng cáo đã yêu cầu một giải pháp thay thế sau khi cookie của bên thứ ba không còn được dùng nữa. |
Nhóm Hộp cát về quyền riêng tư đang khám phá các tính năng để hỗ trợ các phương pháp tiếp cận trên nhiều miền sau khi ngừng sử dụng cookie của bên thứ ba. Chúng tôi rất mong nhận được ý kiến phản hồi khác từ hệ sinh thái. |
Giới hạn hoạt động theo dõi ẩn
Giảm thiểu tác nhân người dùng/Thông tin mô tả của ứng dụng tác nhân người dùng
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| (Cũng được báo cáo trong quý 1 năm 2023) Gợi ý cho các hệ số hình dạng khác | Yêu cầu Gợi ý ứng dụng của tác nhân người dùng (UA-CH) để cung cấp thêm các hệ số hình dạng như TV, VR | Chúng tôi vẫn đang xử lý một số quyết định thiết kế chính (liệu có cung cấp một giá trị duy nhất như "TV" hay một danh sách các chức năng về kiểu dáng), nhưng vẫn quan tâm đến việc tạo bản minh hoạ ý tưởng này. |
| Hạn mức quyền riêng tư | Các quy định hạn chế về Ngân sách quyền riêng tư có thể khiến các yêu cầu UA-CH trở nên không xác định khi gửi quá nhiều yêu cầu. | Hiện tại, chúng tôi chưa có thông tin cập nhật nào về đề xuất về Ngân sách quyền riêng tư, nhưng chúng tôi cam kết không hạn chế các yêu cầu về gợi ý ứng dụng UA trước khi cookie của bên thứ ba ngừng hoạt động. |
| Khả năng tương thích của trang web | Các trang web đang sử dụng thương hiệu UA-CH để hạn chế một số trình duyệt truy cập vào trang web. | Có những trường hợp sử dụng hợp lệ cho việc có danh sách thương hiệu, và một trong số đó chính là khả năng tương thích. Một UA có thể có nhiều thương hiệu để giải quyết những vấn đề này. |
Bảo vệ địa chỉ IP (trước đây là Gnatcatcher)
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Hành vi gian lận và lạm dụng | 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 hiểu tầm quan trọng của các trường hợp sử dụng chống gian lận và tác động có thể có đối với các trường hợp sử dụng đó. Chúng tôi dự định sẽ công bố thêm thông tin chi tiết về việc hỗ trợ chống gian lận vào cuối mùa hè này. Chúng tôi đang tìm kiếm ý kiến phản hồi của hệ sinh thái về cách chúng tôi có thể hỗ trợ tốt hơn các trường hợp sử dụng chống gian lận. |
| GeoIP | Thông tin khác về tiến trình thử nghiệm và triển khai GeoIP | Gần đây, Chrome đã công bố thông tin mới về kế hoạch triển khai tính năng Địa chỉ IP theo vị trí địa lý. Chúng tôi dự định sẽ công bố thêm thông tin về tiến trình triển khai trong quý 3. Ban đầu, chúng tôi dự kiến sẽ ra mắt tính năng Bảo vệ quyền sở hữu trí tuệ dưới dạng một tính năng mà người dùng có thể chọn sử dụng trên một tỷ lệ nhỏ lưu lượng truy cập. Lý do là chúng tôi nhận thấy đề xuất này có thể liên quan đến một số thay đổi quan trọng đối với các công ty. Chúng tôi muốn hệ sinh thái có thời gian điều chỉnh và đưa ra ý kiến phản hồi trước khi triển khai tính năng này trên diện rộng hơn. |
| Xác thực tài khoản | Quy trình xác thực tài khoản bằng máy chủ proxy sẽ hoạt động như thế nào? | Chúng tôi dự định sẽ công bố thêm thông tin chi tiết về quy trình xác thực tài khoản vào cuối mùa hè này, mặc dù chúng tôi đã chia sẻ một số yếu tố cần cân nhắc ban đầu. |
Giảm thiểu hoạt động theo dõi tỷ lệ thoát
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Hướng dẫn kiểm thử | Thông tin về cách kiểm thử tính năng Giảm thiểu hoạt động theo dõi số trang không truy cập | Vào tháng 5, chúng tôi đã xuất bản một bài đăng trên blog cung cấp thêm thông tin về cách thử nghiệm tính năng Giảm thiểu tính năng Theo dõi lượt thoát. |
| Tài liệu | Nội dung rõ ràng trong Đề xuất theo dõi tỷ lệ thoát | Đề xuất hiện tại vẫn đang trong quá trình hoàn thiện và Chrome sẽ tiếp tục cập nhật đề xuất này để cung cấp thông tin rõ ràng cho hệ sinh thái. Chúng tôi đang nỗ lực cung cấp thêm thông tin chi tiết và hoan nghênh mọi ý kiến phản hồi khác. |
| Xoá cookie | Tính năng Giảm thiểu tính năng Theo dõi lượt thoát có xoá tất cả cookie trong một miền không? | Tính năng giảm thiểu lượt thoát (BTM) sẽ xoá tất cả bộ nhớ và bộ nhớ đệm, như giải thích tại đây. |
| Lách biện pháp giảm thiểu hoạt động theo dõi số trang không truy cập | Bạn có thể bỏ qua việc phân loại trình theo dõi lượt thoát bằng cách thực hiện lệnh chuyển hướng bằng cửa sổ bật lên hoặc thẻ mới. | Thông số kỹ thuật về tính năng Giảm hoạt động theo dõi số trang không truy cập vẫn đang trong quá trình hoàn thiện. Cho đến nay, chúng tôi chủ yếu tập trung vào các lượt chuyển hướng trong cùng một thẻ, nhưng chúng tôi dự định sẽ xử lý các luồng cửa sổ bật lên trong tương lai. Chúng tôi rất mong nhận được ý kiến phản hồi khác tại đây. |
Hạn mức quyền riêng tư
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Mục tiêu vùng lân cận | Ngân sách quyền riêng tư có thể ảnh hưởng đến các trường hợp sử dụng tính năng nhắm mục tiêu theo khoảng cách. | Chúng tôi đã nhận được ý kiến phản hồi về vấn đề này và rất mong được nghe thêm về những tác động tiềm ẩn từ hệ sinh thái. |
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
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| (Cũng được báo cáo trong các quý trước) Giới hạn miền | Yêu cầu mở rộng số lượng miền được liên kết | Chrome đang đánh giá giới hạn số lượng thích hợp cho tập hợp con được liên kết để cân bằng quyền riêng tư và tiện ích cho các trường hợp sử dụng đã xác định. Ngay từ bước đầu, Chrome đã chia sẻ rằng số lượng chính xác của tập hợp con được liên kết vẫn chưa được hoàn tất. |
| Trường hợp sử dụng được nhúng | Hỗ trợ các trường hợp sử dụng Nhúng yêu cầu Nhóm bên thứ nhất, CHIP và bộ nhớ dùng chung | Chrome đã nhận được ý kiến phản hồi về trường hợp sử dụng này. Nhóm Chrome đang điều tra và hoan nghênh ý kiến phản hồi bổ sung. |
| Quản lý kho lưu trữ | Thông tin về các chính sách xoá Nhóm bên thứ nhất khỏi kho lưu trữ GitHub nếu có sự khác biệt hoặc bỏ qua | Chrome đã nhận được ý kiến phản hồi về trường hợp sử dụng này. Nhóm chúng tôi đang điều tra và rất mong nhận được ý kiến phản hồi khác. |
| Hướng dẫn người dùng | Chrome nên tăng mức độ nhận biết và hiểu biết của người dùng về Nhóm bên thứ nhất để thúc đẩy việc sử dụng. | Chrome cam kết hướng dẫn người dùng về Nhóm bên thứ nhất và đã xuất bản một bài viết trong Trung tâm trợ giúp (được liên kết từ giao diện người dùng Chrome) về vấn đề này. Chrome cũng đang đầu tư vào việc tiếp tục tìm hiểu cách hướng dẫn người dùng hiệu quả nhất trong các ngữ cảnh phù hợp. |
| Bài đăng 3PCD | Cookie của bên thứ ba sẽ tiếp tục tồn tại trong một Tập hợp bên thứ nhất sau khi cookie của bên thứ ba không được dùng nữa. | Mặc dù requestStorageAccess và requestStorageAccessFor thực sự cung cấp lại cookie của bên thứ ba cho các trường hợp sử dụng cụ thể, được xác định rõ ràng, nhưng giờ đây, các cookie này yêu cầu trang web gọi một cách chủ động, thay vì có sẵn theo mặc định, như trạng thái hiện tại của cookie của bên thứ ba (trong Chrome).Mặc dù lệnh gọi này trong một nhóm không yêu cầu người dùng phê duyệt, nhưng người dùng có thể ngăn chặn việc này bằng cách chọn không sử dụng hành vi này trong phần Cài đặt. Người dùng có thể xem thêm thông tin trong bài viết trên Trung tâm trợ giúp (được liên kết từ giao diện người dùng Chrome). Chúng tôi dự định mở rộng hướng dẫn dành cho nhà phát triển hiện có khi FPS tăng lên 100%. |
| Gửi Nhóm bên thứ nhất | Đổi tên .well-known/first-party-set bắt buộc để thêm đuôi .json. |
Chúng tôi đã thực hiện thay đổi này để đảm bảo một số gói lưu trữ web nhất định được hỗ trợ. |
| Đăng ký với IANA | first_party_sets.JSON phải được đăng ký với IANA |
Chúng tôi đang xem xét đề xuất này và hoan nghênh bạn gửi thêm ý kiến phản hồi tại đây. |
Fenced Frames API
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Chặn quảng cáo | Khung được khoanh vùng có thể giúp trình chặn quảng cáo dễ dàng chặn quảng cáo hơn. | Tiện ích có thể tương tác với các khung được phân vùng tương tự như cách tương tác với iframe. Tiện ích cũng sẽ thấy URL thực tế mà khung được bảo vệ sắp chuyển đến. Do đó, các tiện ích có thể áp dụng mọi quy tắc so khớp URL để chặn như trong iframe. Việc chỉ chặn tất cả các khung được phân vùng một cách vô điều kiện có thể làm hỏng các trường hợp sử dụng không phải quảng cáo của khung được phân vùng. |
Shared Storage API
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Mức độ sử dụng rộng rãi hơn | Bộ nhớ dùng chung phải là một tiêu chuẩn trên toàn ngành và có trên các trình duyệt. | Chúng tôi hoan nghênh và ghi nhận ý kiến phản hồi này. Chrome tiếp tục tích cực tham gia các diễn đàn của W3C để ủng hộ đề xuất này, thu thập ý kiến phản hồi và thúc đẩy việc sử dụng. |
| Cổng đầu ra | Cổng đầu ra của Bộ nhớ dùng chung bị hạn chế quá mức. | Chúng tôi đang xem xét ý kiến phản hồi này và hoan nghênh ý kiến phản hồi bổ sung về hệ sinh thái về lý do cổng đầu ra bị hạn chế. |
| Tuân thủ quy định | Bộ nhớ dùng chung sẽ xử lý việc tuân thủ quy định như chính sách giữ lại dữ liệu như thế nào? | Bộ nhớ dùng chung giúp bạn linh hoạt triển khai và tuỳ chỉnh logic để kiểm soát thời gian hoạt động và thời gian hết hạn của mọi dữ liệu được lưu trữ. Công nghệ quảng cáo có thể cập nhật hoặc xoá dữ liệu Bộ nhớ dùng chung dựa trên dấu thời gian ghi. |
| Thử nghiệm A/B | Làm cách nào để tiến hành thử nghiệm A/B cho Shared Storage và Protected Audience API? | Chúng tôi đang nỗ lực để phát hành thêm hướng dẫn về vấn đề này và hy vọng có thể chia sẻ thêm thông tin chi tiết trong tương lai. |
| Giới hạn bộ nhớ dùng chung | Điều gì sẽ xảy ra khi đạt đến hạn mức Bộ nhớ dùng chung? | Nếu đạt đến giới hạn, hệ thống sẽ không lưu trữ thêm dữ liệu đầu vào nào nữa. |
| Nhiều lượt truy cập trong cùng một lượt tải trang | Điều gì sẽ xảy ra khi truy cập vào Bộ nhớ dùng chung nhiều lần trong cùng một lượt tải trang? | Cách tốt nhất để xử lý vấn đề này là thông qua hàm window.sharedStorage.append(key, value). Thay vì cập nhật giá trị cho từng quảng cáo, điều này có thể gây ra xung đột nếu có nhiều quảng cáo. Hàm nối sẽ chỉ thêm giá trị mới vào cuối giá trị hiện có. |
| Chức năng iframe | Bộ nhớ dùng chung có hỗ trợ một số chức năng iframe nhất định sau khi các chức năng này không còn hoạt động sau khi cookie của bên thứ ba không được dùng nữa không? | Sau khi ngừng sử dụng cookie của bên thứ ba, bộ nhớ cục bộ trong iframe sẽ được phân vùng theo trang web cấp cao nhất, nhưng chính các iframe sẽ không bị chặn. Bạn không thể sao chép dữ liệu trong bộ nhớ cục bộ của một iframe trên nhiều trang web cấp cao nhất, nhưng vẫn có thể sử dụng bộ nhớ cục bộ trong iframe. |
CHIPs
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Giới hạn phân vùng | 10 KiB cho mỗi trang web được phân vùng vẫn là một con số đáng kể và tôi muốn giảm con số này. | Firefox đã cho biết quan điểm tích cực về CHIPS. Để được hỗ trợ về Webkit, nhà phát triển nên trực tiếp gửi ý kiến phản hồi cho Apple về vấn đề này trên GitHub liên quan đến các trường hợp sử dụng mà họ ưu tiên cookie được phân vùng hơn là bộ nhớ được phân vùng. |
| Nội dung nhúng đã xác thực | CHIP có thể ảnh hưởng đến quy trình đăng nhập SSO hiện tại do các hoạt động phân vùng khác nhau ảnh hưởng đến các phần nhúng đã xác thực. | Chúng tôi dự định tận dụng API Truy cập bộ nhớ (có lời nhắc của người dùng) để hỗ trợ trường hợp sử dụng nội dung nhúng đã xác thực và gần đây đã gửi một ý định tạo nguyên mẫu. |
| Chính sách trọn đời | Các chính sách tiềm năng về thời hạn sử dụng có áp dụng cho cookie của bên thứ nhất không? | Hiện tại, chúng tôi không có kế hoạch áp dụng giới hạn về thời gian tồn tại đối với cookie của bên thứ nhất. |
FedCM
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Hỗ trợ uỷ quyền OAuth | Điều chỉnh để cho phép các phạm vi Oauth không phải hồ sơ | Chúng tôi đang tích cực tìm kiếm ý kiến đóng góp của cộng đồng Danh tính trên web thông qua W3C FedID CG về những cách tốt nhất để hỗ trợ việc uỷ quyền ngoài phương thức xác thực cơ bản sau khi ngừng sử dụng cookie của bên thứ ba. |
| Hỗ trợ SAML | Điều chỉnh theo các yêu cầu để hỗ trợ SAML | Nhóm chúng tôi đang tích cực thu thập ý kiến đóng góp của các cộng đồng nghiên cứu và giáo dục về nhu cầu hỗ trợ SAML (ngoài việc hỗ trợ OpenID-connect) sau khi ngừng sử dụng cookie của bên thứ ba. |
Chống hành vi gian lận và nội dung rác
Private State Tokens API (và các API khác)
| Giao diện phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Khám phá các tín hiệu mới | Một số đối tác đã bày tỏ thái độ tích cực đối với việc khám phá các tín hiệu do trình duyệt hỗ trợ về tính toàn vẹn của thiết bị hoặc sự tin tưởng của người dùng. Nhìn chung, họ cũng thận trọng về việc các tín hiệu mới được tạo ra cho mục đích cụ thể có đủ để duy trì mức độ phát hiện gian lận hiện tại hay không. | Chúng tôi rất vui được cùng cộng đồng chống gian lận và an toàn trên web khám phá các đề xuất mới, đồng thời ghi nhận và chia sẻ những mối lo ngại của họ. Đây chính là lý do "chống nội dung rác và gian lận" trở thành luồng công việc cốt lõi của Hộp cát về quyền riêng tư, cũng như lý do chúng tôi tiếp tục ưu tiên đầu tư vào việc bảo đảm an toàn trên web trong khi cải thiện quyền riêng tư của người dùng. |
| Ý kiến phản hồi tích cực về PST | Một số đối tác đã bày tỏ sự quan tâm đến việc thử nghiệm hoặc sử dụng PST cho nhiều trường hợp sử dụng chống gian lận hoặc an toàn trên web. | Chúng tôi rất vui khi biết bạn ủng hộ và quan tâm đến việc khám phá thêm các giải pháp mới sử dụng PST. Chúng tôi có các tài nguyên và mã mẫu thông qua trang web dành cho nhà phát triển Chrome. Chúng tôi rất mong nhận được ý kiến phản hồi của bạn. |
| Hành vi gian lận và lạm dụng | Hướng dẫn về việc phòng chống / phát hiện hành vi gian lận trong quảng cáo trong hoạt động đo lường sau khi ngừng sử dụng cookie của bên thứ ba khi không còn giá trị nhận dạng. | Chúng tôi đã ra mắt các công cụ như mã thông báo trạng thái riêng tư để giúp khôi phục một số tín hiệu bị mất do cookie của bên thứ ba cho mục đích chống gian lận, nhưng vẫn có các chế độ kiểm soát quyền riêng tư mới. Chúng tôi đang tích cực đầu tư vào các đề xuất mới về chống gian lận và chống hành vi sai trái để duy trì các tính năng này cùng với các thay đổi khác đối với Hộp cát về quyền riêng tư. |
| Tỷ lệ thông tin về nguồn gốc của tổ chức phát hành | Tỷ lệ thông tin từ bên phát hành đến nguồn gốc đủ cao để xác định người dùng riêng biệt. | Chúng tôi đã cập nhật thông số kỹ thuật để làm rõ hơn về dữ liệu người dùng có thể được truyền bằng Mã thông báo trạng thái riêng tư. Theo thiết kế, mỗi lần có thể sử dụng tối đa 6 khoá công khai, đại diện cho một "trạng thái" của một người dùng cụ thể. Bạn chỉ có thể cập nhật các bộ khoá này 60 ngày một lần (ngoại trừ một số ít trường hợp cần phải xoay khoá khẩn cấp). Điều này làm chậm khả năng kết hợp thêm dữ liệu người dùng theo thời gian. Với mọi API web mới, luôn có sự cân bằng giữa tiện ích được cung cấp và thông tin người dùng mới mà API đó cung cấp. Chúng tôi ước tính rằng PST tạo ra sự cân bằng phù hợp trong việc bảo vệ quyền riêng tư của người dùng, đồng thời hỗ trợ các trường hợp sử dụng chính trong hoạt động chống gian lận bị ảnh hưởng do việc ngừng sử dụng cookie của bên thứ ba. |
| Tích hợp tìm nạp | Việc tích hợp fetch phức tạp và không cần thiết. |
Việc sử dụng fetch có ưu và nhược điểm. Chúng tôi muốn tiếp tục chuẩn hoá trong hệ sinh thái web, nhưng chúng tôi cho rằng vẫn còn quá sớm để thực hiện thay đổi này cho đến khi chúng tôi hiểu rõ hơn về tiêu chuẩn này. Nếu và khi một tiêu chuẩn xuất hiện, chúng tôi cũng cam kết chuyển đổi nhà phát triển web sang tiêu chuẩn đó một cách có trách nhiệm. |
| Vị trí lưu trữ | Cấu hình khoá Mã thông báo trạng thái riêng tư phải được lưu trữ ở cùng một vị trí với Giao thức PrivacyPass. | Trong quá trình thử nghiệm trong chương trình Thử nghiệm theo nguồn gốc, các nhà phát triển cho biết họ muốn có thể linh hoạt lưu trữ khoá của mình tại các URL chung thay vì trong thư mục .well-known. Định dạng cam kết khoá trong PrivacyPass không đặc biệt phù hợp với phiên bản mà tập hợp khoá được dùng để cho phép giá trị "siêu dữ liệu công khai" ngầm ẩn. Nếu một biến thể của PrivacyPass cuối cùng được chuẩn hoá bằng siêu dữ liệu công khai (dưới dạng POPRF, làm mờ một phần RSA hoặc bộ khoá), chúng tôi có thể chuyển sang phiên bản PST trong tương lai để hỗ trợ biến thể đó. |
| Triển khai tiêu đề của API | Câu hỏi liên quan đến việc triển khai tiêu đề của API | Khi API được chuẩn hoá và việc sử dụng hệ sinh thái của API này phát triển, chúng tôi hy vọng có thể hỗ trợ cả phiên bản không có tiêu đề tiêu chuẩn của API này và cuối cùng có thể ngừng sử dụng phiên bản có tiêu đề nếu mức sử dụng đủ thấp hoặc có đủ công cụ/hỗ trợ cho nhà phát triển cho các cách tiêu chuẩn để liên kết các yêu cầu phát hành/sử dụng với dữ liệu khác. Chúng tôi đang thảo luận về vấn đề này tại đây. |
| Đăng ký | Việc yêu cầu nhà phát hành đăng ký với nhà cung cấp trình duyệt có thực tế không? | Chúng tôi đã cập nhật quy cách để mô tả quy trình đăng ký của tổ chức phát hành cho Mã thông báo trạng thái riêng tư. Mặc dù sử dụng quy trình riêng, nhưng quy trình này cũng tương tự như kế hoạch đăng ký cho các hoạt động còn lại trong Hộp cát về quyền riêng tư. Trong đó, chúng tôi yêu cầu bên phát hành đưa ra tuyên bố công khai về cách họ dự định sử dụng PST và xác nhận các quy định hạn chế về kỹ thuật để bảo vệ quyền riêng tư của người dùng. |