Báo cáo hằng quý cho quý 2 năm 2023 tóm tắt ý kiến phản hồi về hệ sinh thái nhận được liên quan đến các đề xuất trong khuôn khổ Hộp cát về quyền riêng tư và phản hồi của Chrome.
Theo cam kết của mình với CMA, Google đã đồng ý cung cấp công khai báo cáo hằng quý về quy trình tương tác của các bên liên quan liên quan đến Hộp cát về quyền riêng tư các đề xuấ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 phản hồi tổng quan, bao gồm nhưng không giới hạn ở: GitHub Vấn đề, biểu mẫu phản hồi đã xuất hiện privacysandbox.com, cuộc họp với các ngành các bên liên quan và diễn đàn về tiêu chuẩn web. Chrome rất trân trọng ý kiến phản hồi mà bạn nhận được từ hệ sinh thái này và đang tích cực tìm hiểu các phương pháp tích hợp các kiến thức đã học vào các quyết định về thiết kế.
Các chủ đề phản hồi được xếp hạng theo mức độ phổ biến của mỗi API. Bạn có thể thực hiện việc này bằng cách lấy tổng hợp số lượng 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ự số lượng giảm dần. Ý kiến phản hồi chung được xác định bằng cách xem xét các chủ đề thảo luận trong các cuộc họp công khai (W3C, PatCG, IETF), phản hồi trực tiếp, GitHub và các câu hỏi thường gặp hiển thị thông qua các nhóm nội bộ và các biểu mẫu công khai của Google.
Cụ thể hơn, biên bản cuộc họp của các cuộc họp cơ quan tiêu chuẩn trên web được đã xem xét và để phản hồi trực tiếp, hồ sơ của Google về các cuộc họp 1:1 với các bên liên quan, email mà từng kỹ sư nhận được, danh sách gửi thư API và công chúng biểu mẫu phản hồi đã được xem xét. Sau đó, Google sẽ phối hợp giữa các nhóm tham gia vào các hoạt động tiếp cận khác nhau này để xác định mối liên hệ mức độ phổ biến của các chủ đề xuất hiện liên quan đến từng API.
Phần giải thích cho các câu trả lời của Chrome cho phản hồi được phát triển từ Câu hỏi thường gặp, câu trả lời thực tế cho những vấn đề mà các bên liên quan đã nêu và việc xác định vị trí cụ thể cho mục đích của bài tập báo cáo công khai này. Đề cập đến trọng tâm hiện tại của việc phát triển và thử nghiệm, câu hỏi và ý kiến phản hồi cụ thể liên quan đến Chủ đề, Đối tượng được bảo vệ và Phân bổ API Báo cáo.
Phản hồi nhận được sau khi kết thúc kỳ báo cáo hiện tại có thể chưa một phản hồi được cân nhắc của Chrome.
Bảng chú giải thuật ngữ 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 đăng nhập liên kết
- FPS
- Nhóm bên thứ nhất
- IAB (Cục Quảng cáo tương tác)
- Cục Quảng cáo tương tác
- IDP
- Nhà cung cấp danh tính
- IETF (Lực lượng chuyên trách kỹ thuật Internet)
- Lực lượng chuyên trách kỹ thuật Internet
- Số hiệp ném bóng
- Địa chỉ Giao thức Internet
- openRTB
- Đặt giá thầu theo thời gian thực
- QUÁ GIỜ
- Dùng thử theo nguyên gốc
- PatCG
- Nhóm cộng đồng công nghệ quảng cáo riêng tư
- bên bị hạn chế
- Nhóm tin cậy
- 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
- Gợi ý về ứng dụng tác nhân người dùng
- W3C
- World Wide Web Consortium
- WIPB
- Tự làm mù đị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 |
|---|---|---|
| Quản trị dữ liệu và Tuân thủ quy định | Hướng dẫn về hệ sinh thái về cách sử dụng Hộp cát về quyền riêng tư sao cho 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 có trách nhiệm đảm bảo rằng việc công ty sử dụng Hộp cát về quyền riêng tư tuân thủ luật pháp; Google không thể tư vấn pháp lý cho những người khác. Tuy nhiên, chúng tôi biết rằng đây là vấn đề chính mà hệ sinh thái cần quan tâm. Đố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ở để đưa ra các đánh giá pháp lý cần thiết và chúng tôi cũng đang nỗ lực cung cấp tài liệu bổ sung nhằm hỗ trợ các công ty nhằm tuân thủ các yêu cầu theo quy định. |
| Đề xuất thử nghiệm định lượng CMA | Thông tin khác về đề xuất thử nghiệm định lượng CMA | Chúng tôi đang làm việc cùng với CMA để thiết kế các thử nghiệm nhằm cung cấp thông tin tổng quan về tác động của việc ngừng sử dụng cookie của bên thứ ba, cũng như giới thiệu các đề xuất về Hộp cát về quyền riêng tư trên 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 sẽ xảy ra trong giai đoạn Kiểm thử và dùng thử, sau đó là hướng dẫn chi tiết vào tháng 6. Bạn nên chia sẻ trực tiếp các câu hỏi hoặc ý kiến phản hồi về đề xuất Thử nghiệm định lượng của CMA. |
| Các chế độ kiểm thử trên nền tảng Chrome | Thông tin khác và nội dung giải thích về lịch kiểm thử | Chúng tôi đã xuất bản một bài đăng trên blog vào ngày 18 tháng 5 để chia sẻ thêm thông tin về hai chế độ thử nghiệm trên nền tảng Chrome. Đây chưa phải là thông tin cuối cùng và chúng tôi sẽ công bố thêm hướng dẫn triển khai trong quá trình triển khai trong quý 3 năm 2023. |
| Bộ nhớ phân vùng | Bộ nhớ được phân vùng có được dùng trong quá trình thử nghiệm trên nền tảng Chrome không? | Tính năng phân vùng bộ nhớ sẽ được vận chuyển cho tất cả người dùng trước khi diễn ra thử nghiệm ngừng sử dụng cookie của bên thứ ba. Do đó, tính năng này sẽ được bật cho tất cả các nhóm thử nghiệm. Các trang web sẽ có thể chọn bật thử nghiệm ngừng sử dụng để lấy lại bộ nhớ không được phân vùng trong khoảng thời gian này. |
| Hỗ trợ sản xuất | Google đang áp dụng quy trình nào để hỗ trợ các vấn đề kỹ thuật và báo cáo lên cấp trên và các vấn đề kỹ thuật của Hộp cát về quyền riêng tư ảnh hưởng đến hệ sinh thái? | Google cung cấp nhiều kênh để cho phép công nghệ quảng cáo báo cáo vấn đề và tạo mọi báo cáo cần thiết. Vui lòng xem bài đăng dành cho nhà phát triển của chúng tôi để biết thêm thông tin về diễn đàn công khai và riêng tư nhằm phản hồi và chuyển lên cấp trên. |
| Tiến trình đăng ký | Khung thời gian đă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 lắng nghe ý kiến của hệ sinh thái về thời hạn phù hợp hơn. |
| Mã số DUNS | Thông tin khác về yêu cầu liên quan đến số D-U-N-S khi đăng ký và chứng thực | Người tham gia có thể xem các yêu cầu để được cấp mã số DUNS trên trang web của Dun và Bradstreet. Các yêu cầu sẽ khác nhau tuỳ thuộc vào thị trường, vì vậy, người tham gia nên kiểm tra trang web để biết thị trường cụ thể mà họ quan tâm. Tuy nhiên, người tham gia sẽ cần cung cấp thông tin cơ bản về doanh nghiệp của mình, chẳng hạn như tên doanh nghiệp, địa chỉ và thông tin liên hệ của chủ doanh nghiệp hoặc người quản lý. Những 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 đơn đăng ký hoàn tất, D&B sẽ xem xét đơn đăng ký đó và cấp một mã số D-U-N-S nếu đơn đăng ký được phê duyệt. |
| Chuyển đổi từ Bả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 giai đoạn phát hành rộng rãi 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, người thử nghiệm sẽ có thể sử dụng các API đo lường và mức độ liên quan nói chung. Điều này sẽ tạo ra sự trùng lặp giữa phạm vi cung cấp bản dùng thử theo nguyên gốc và phạm vi cung cấp rộng rãi. |
| Nghiên cứu về AdExchanger | Thông tin khác về phương pháp khảo sát | Bản khảo sát này 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ọ. Của người trả lời phương pháp để trả lời các câu hỏi riêng lẻ của họ là do họ quyết định. |
| Giá trị thông số | Các giá trị thông số như mức độ nhiễu, ngưỡng ẩn danh và ngân sách quyền riêng tư được xác định như thế nào? | Bài giải thích này trên GitHub trình bày các nguyên tắc chung đằng sau các API Hộp cát về quyền riêng tư. Nhiều giá trị vẫn đang được hoàn thiện và chúng tôi hoan nghênh ý kiến phản hồi về chủ đề này. |
Hiện nội dung có liên quan và Quảng cáo
Chủ đề
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Bảo vệ quyền riêng tư | Nghiên cứu đánh giá Topics API về việc bảo vệ quyền riêng tư | Chúng tôi tích cực tham gia cộng đồng nghiên cứu, trình bày nghiên cứu về các thuộc tính quyền riêng tư của Topics API dưới dạng bài viết, báo cáo và bài thuyết trình tại hội thảo. Chúng tôi rất vui khi thấy ngày càng có thêm nhiều thành viên bên ngoài thuộc cộng đồng nghiên cứu tương tác với 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 vì 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 viết này cho thấy rằng chúng tôi đang áp dụng thành công Topics API. Dữ liệu này có tính bảo mật cao hơn so với cookie của bên thứ ba, đồng thời bảo vệ người dùng trong khi vẫn hỗ trợ các trang web mà họ thích truy cập. |
| Phân loại chủ đề không đủ chi tiết | Cách phân loại chủ đề rộng không bao gồm các chủ đề chi tiết hơn, kể cả theo từng khu vực. | Để trả lời ý kiến phản hồi trước đây 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 một hệ thống phân loại mới 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 từ hệ sinh thái. Là một phần trong nỗ lực cải tiến hệ thống phân loại, chúng tôi đã hợp tác với một số công ty trong hệ sinh thái này, chẳng hạn như Raptive (trước đây là CafeMedia) và Criteo. Cách phân loại được cập nhật sẽ xóa các danh mục mà chúng tôi nghe nói là kém hữu ích hơn, thay vào đó là các danh mục phù hợp hơn với mối quan tâm của nhà quảng cáo, trong khi vẫn duy trì cam kết loại trừ các chủ đề có thể nhạy cảm. Chúng tôi khuyến khích hệ sinh thái xem xét cách phân loại mới nhất và cung cấp ý 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 thêm về hệ thống phân loại Chủ đề và quy trình phát hành thuật toán phân loại, cũng như cách các công ty có thể chuẩn bị cho những thay đổi này. | Như đã chia sẻ trong bài đăng trên blog gần đây, chúng tôi dự kiến cách phân loại này sẽ phát triển theo thời gian và để việc quản trị hệ thống phân loại cuối cùng chuyển đổi thành một bên bên ngoài đại diện cho các bên liên quan trong toàn ngành. Chúng tôi cũng chia sẻ kế hoạch tăng cường trong nhóm thông báo chủ đề. |
| Tác động đến các tín hiệu của bên thứ nhất | Việc gia tăng số lượng Chủ đề trong lần cập nhật Hệ thống phân loại gần đây có thể mang lại giá trị cao, và do đó làm giảm giá trị các tín hiệu dựa trên mối quan tâm khác 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 đang thảo luận về hệ thống phân loại mới được đề xuất với một số bên tham gia thị trường trên 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 rằng lợi ích lớn hơn của các chủ đề 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 sơ bộ của chúng tôi là sự hữu ích lớn hơn sẽ tốt hơn cho cạnh tranh nói chung – đặc biệt là khả năng các nhà xuất bản nhỏ hơn tiếp tục kiếm tiền từ khoảng không quảng cáo của họ sau khi cookie của bên thứ ba không được dùng nữa". Quan điểm của chúng tôi phù hợp với nhận xét này của CMA. |
| Tính hữu ích cho các kiểu bên liên quan khác nhau | Công nghệ quảng cáo hoạt động như 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. | Câu trả lời của chúng tôi không thay đổi so với các quý trước: "Google cam kết với CMA thiết kế và triển khai các đề xuất trong khuôn khổ Hộp cát về quyền riêng tư sao cho không làm méo mó hoạt động cạnh tranh thông qua việc tự ưu tiên hoạt động kinh doanh của Google, đồng thời tính đến tác động đến sự cạnh tranh trong quảng cáo kỹ thuật số cũng như đối với các nhà xuất bản và nhà quảng cáo, bất kể quy mô của họ. Chúng tôi vẫn tiếp tục hợp tác chặt chẽ với CMA để đảm bảo rằng các hoạt động của chúng tôi tuân thủ những 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 quan trọng mà chúng tôi sẽ đánh giá là hiệu quả hoạt động của các công nghệ mới đối với nhiều kiểu bên liên quan. Ý kiến phản hồi là rất quan trọng trong khía cạnh này, đặc biệt là những phản hồi thiết thực và cụ thể có thể giúp chúng tôi cải thiện thêm các 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 tiếp cận thử nghiệm định lượng, đồng thời ủng hộ CMA xuất bản 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 tiếp cận được đề xuất". |
| Chủ đề con cháu | Với tiêu chí lựa chọn Chủ đề là tần suất truy cập trình duyệt, liệu tình trạng rời rạc phân khúc có khiến các chủ đề con không bao giờ xuất hiện lên trên cùng 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 của mình cho hệ sinh thái này kịp thời. |
| Độ nhạy cảm | Mục tiêu của Topics API phải là đảm bảo thông tin người dùng thu được hoặc bắt nguồn từ Topics API phải ít nhạy cảm hơn với thông tin cá nhân so với thông tin có được bằng các phương pháp theo dõi hiện nay. | Chúng tôi cho rằng Topics API có mức độ 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 nhận dạng 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 xác nhận rằng các chủ đề có thể tương quan 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 trong việc bảo vệ quyền riêng tư của người dùng và chúng tôi cam kết không ngừng 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 của API, chúng tôi đang thêm mã phân loại. Khi chuyển sang phương pháp quản trị dài hạn, bạn nên xem lại đối tượng Chủ đề và thêm siêu dữ liệu bổ sung về cách xác định 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 phải có quyền nêu rõ về những Chủ đề mà trang web của họ nên được phân loại. | Việc phân loại sai các trang web có thể làm cho tín hiệu Chủ đề kém hữu ích hơn một chút so với một tín hiệu tổng thể, nhưng các trang web cụ thể bị phân loại sai sẽ không còn hoặc không ít hơn bị tổn hại bởi điều này so với bất kỳ trang web nào khác. Điều này là do thông tin theo bối cảnh của một trang web sẽ luôn có sẵn trong các phiên đấu giá trên trang web đó. Việc 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. Chúng tôi hoan nghênh ý 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 hoạt động phân loại của họ có thể dẫn đến rủi ro. Các trang web có thể cố ý phân loại không chính xác trang web, làm giảm tiện ích cho tất cả mọi người hoặc mã hoá ý nghĩa nhạy cảm trong những 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 của Chrome quản lý và lọc Chủ đề, tương tự như các tiện ích Quản lý cookie hiện có | Điều này có thể đã khả thi, như đã thảo luận trên GitHub, nhưng chúng tôi rất mong nhận được thêm ý kiến phản hồi từ hệ sinh thái. |
| Chuyển sang giai đoạn phát hành rộng rãi | Topics API có bị ảnh hưởng gì khi chuyển từ Bản dùng thử theo nguyên gốc sang giai đoạn phát hành rộng rãi không? | Người dùng sẽ không bị mất dữ liệu khi chuyển từ Bản dùng thử theo nguyên gốc sang giai đoạn phát hành rộng rãi. |
| Quyền riêng tư | Tên máy chủ lưu trữ có thể chứa thông tin riêng tư mà Topics API có thể tiết lộ | Chúng tôi có một số giải pháp giảm thiểu để đảm bảo quyền riêng tư, như trình bày tại đây. |
| Gian lận và lạm dụng | Cách ngăn chặn việc thao túng Chủ đề do các lượt truy cập gian lận | Các biện pháp giảm thiểu được giải thích tại đây. |
| Thuật toán phân loại chủ đề | Các trang web có thể yêu cầu thay đổi cách phân loại Chủ đề không? | Chúng tôi muốn lắng nghe ý kiến của hệ sinh thái về chủ đề này và chào mừng ý kiến phản hồi tại đây. |
| Trang web của nhà cung cấp chủ đề | Chỉ định các 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 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 sẽ thảo luận về đề xuất này tại đây và hoan nghênh các ý kiến phản hồi khác. |
Protected Audience API (trước đây là FLEDGE)
| Chủ đề 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 về hiệu suất của tính năng lọc dựa trên SSP để tối ưu hoá tải truy vấn mỗi giây (QPS) | Chúng tôi đã dành nhiều thời gian để suy nghĩ về việc định hình lưu lượng truy cập và chúng tôi đề xuất SSP nên tận dụng chức năng lưu vào bộ nhớ đệm. |
| Âm lượng thử nghiệm | Khó kiểm thử Protected Audience vì các nền tảng bên bán (SSP) và nền tảng bên cầu (DSP) đang gặp khó khăn trong việc đạt được lưu lượng truy cập lớn. | Chúng tôi liên tục thuê các đối tác SSP và DSP để áp dụng và thử nghiệm Protected Audience. Đã bắt đầu cung cấp rộng rãi và chúng tôi tự tin rằng tỷ lệ phần trăm lưu lượng truy cập có bật tính năng quảng cáo được chứng nhận sẽ giúp các đối tác thử nghiệm dễ dàng hơn. |
| Độ phức tạp | Việc triển khai các giải pháp Protected Audience đòi hỏi chi phí và công sức đáng kể. | Chúng tôi xác nhận rằng các công nghệ mới rất khó áp dụng, trong đó có Hộp cát về quyền riêng tư. 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ợ các nỗ lực của họ, đồng thời liên tục đánh giá các thành phần tham gia 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 các 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 giải pháp trên đám mây, nhưng hiện tại chúng tôi chưa thể hỗ trợ các TEE tại chỗ do các giới hạn về bảo mật tại chỗ đòi hỏi việc đánh giá mất thời gian cho Hộp cát về quyền riêng tư. Do các yêu cầu về bảo mật của Hộp cát về quyền riêng tư và những thách thức lớn khi triển khai tại 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 cùng vớ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 hoan nghênh thêm ý kiến phản hồi về lý do cần có yêu cầu này. |
| Cơ cấu chi phí | Đặt giá thầu và Đề xuất về Dịch vụ đấ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 xây dựng hướng dẫn về việc ước tính chi phí hỗ trợ quy trình đặt giá thầu và đấu giá trong công cụ Đặt giá thầu và Máy chủ đấu giá sẽ tương quan với việc sử dụng công nghệ quảng cáo, nhằm thực hiện một trong các mục tiêu thiết kế của chúng tôi. |
| Lịch trình của K-Anon | Khi nào các quy tắc ràng buộc tính năng ẩn danh theo kế hoạch sẽ được thực thi trên "renderUrl"? | Chúng tôi đang soạn thông tin giải thích về tiến trình thực thi mà chúng tôi sẽ sớm phát hành. |
| Hạn chế trong phiên đấu giá quảng cáo | 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 đủ runAdAuction để gọi được từ trang đầu, nhưng chúng tôi tin rằng sẽ có hại hơn đối với nhà xuất bản nếu hạn chế để chỉ cho phép gọi từ miền cấp cao nhất.Chúng tôi đã nhận được đặc biệt ý kiến của hệ sinh thái rằng Hộp cát về quyền riêng tư cần phải 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 là chủ sở hữu trang web có thể sử dụng các công cụ của bên thứ ba để chạy trang web của mình. 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à người gọi runAdAuction trên trang web của họ, chúng tôi tin rằng chúng tôi sẽ giúp nhà xuất bản linh hoạt tìm ra đường dẫn tốt nhất theo 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 nguồn mở của phiên đấu giá nhiều người bán 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 đảm quyền riêng tư mà 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 phải quy định cách hoạt động của các công nghệ quảng cáo. Chúng tôi đã công bố hướng dẫn về cách thức hoạt động của các API này trên kho lưu trữ GitHub và luôn sẵn sàng tìm hiểu các giải pháp cùng toàn ngành. Chúng tôi không có kế hoạch xây dựng bất kỳ phương pháp triển khai cụ thể nào vì mục tiêu chính của chúng tôi là xây dựng các công nghệ trên nền tảng chứ không áp đặt chiến lược sử dụng các công nghệ đó. Các công nghệ của chúng tôi sẽ giúp các công ty về công nghệ quảng cáo phục vụ khách hàng một cách tốt nhất với những 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 chia sẻ một "ngữ cảnh" không giành chiến thắng với đấu giá thành phần? | Protected Audience API được thiết kế để giúp các bên khởi tạo phiên đấu giá nhiều người bán truyề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 nhận thấy không có cách nào để trình duyệt phân biệt liệu một thông tin có giành chiến thắng theo ngữ cảnh hay không, do đó chúng tôi không thể thực thi việc chặn hoặc yêu cầu thông tin nhất định. |
| Lựa chọn ưu tiên của người dùng để theo dõi sự đồng ý | Công nghệ quảng cáo hỏi PA về cách triển khai chính xác tính năng theo dõi sự đồng ý của người dùng | Câu trả lời của chúng tôi bao gồm những nội dung chúng tôi đã đề cập trong Quý 1: "Đối với các quảng cáo cụ thể, công nghệ quảng cáo phù hợp là bên phù hợp nhất để cung cấp quyền kiểm soát các mẫu quảng cáo được hiển thị hoặc cách các mẫu quảng cáo đó được chọn". Chúng tôi đã thảo luận về một số tình huống liên quan đến vấn đề này tại Cuộc họp bảo vệ người xem của WICG vào tháng 5. Chúng tôi hoan nghênh các ý kiến phản hồi và thảo luận khác về vấn đề này. |
| Đối tượng tùy chỉnh | Các trường hợp sử dụng SSP liên quan đến việc tạo Đối tượng tuỳ chỉnh có được Protected Audience API hỗ trợ 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. Hướng dẫn thêm về cách SSP có thể tích hợp với API PA đang được phát triển và sẽ được cung cấp cho SSP và các nhà cung cấp công nghệ quảng cáo khác để hỗ trợ hoạt động tích hợp của họ. |
| Định dạng | Video có được Protected Audience API hỗ trợ không? | Quảng cáo 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 phát mà cuối cùng cũ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 thông qua một DisplayURL. Thông số kỹ thuật 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 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 của Protected Audience đến trình phát video. Đối với Khung bảo vệ, chúng tôi sẽ nỗ lực giải quyết các nhu cầu về video trước khi yêu cầu sử dụng Khung bảo vệ muộn nhất là năm 2026. |
| Tốc độ | Trường hợp sử dụng Tốc độ 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 xem thêm nhiều trường hợp khác của yêu cầu này, kèm theo thông tin chi tiết hơn từ nhiều đối tác SSP vì từ trước đến nay, vấn đề này chủ yếu là mối lo ngại của DSP. |
| Tần suất cập nhật | Tần suất cuộc gọi từ dailyUpdate (tối đa 1 cuộc gọi cho mỗi nhóm mối quan tâm mỗi ngày) có thể không đủ cho một số trường hợp sử dụng nhất định, chẳng hạn như khi 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ó nhiều giải pháp khác để cho phép công nghệ quảng cáo dùng các tín hiệu được làm mới theo nhiều tần suất khác nhau, chẳng hạn như quá trì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 hoạt động quản lý chất lượng quảng cáo như thế nào? | Hiện nay, Protected Audience API cung cấp chức năng cho nhà xuất bản để thông báo cho SSP của họ về một số chế độ kiểm soát 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ể yêu cầu. |
| Gỡ lỗi | Khi nào chức năng forDebuggingOnly sẽ bị xoá? |
Chúng tôi dự định gỡ bỏ forDebuggingOnly đối với các sự kiện ngừng sử dụng khi cookie của bên thứ ba không được dùng nữa. Chúng tôi dự định sớm gỡ bỏ chế độ forDebuggingOnly để tổ chức các sự kiện giành chiến thắng vào năm 2026. |
| Nhóm đối tượng có cùng mối quan tâm trên nhiều thiết bị | Đề xuất cho phép nhóm mối quan tâm trên nhiều thiết bị đối với 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 việc nhắm mục tiêu trên nhiều thiết bị đặt ra nhiều mối lo ngại đáng kể về quyền riêng tư, như được thảo luận trong Vấn đề này trên GitHub. |
| (Cũng được báo cáo trong Quý 1) Tiếp thị lại động | Liệu tính năng Tái tiếp thị linh động có thể dùng được với Protected Audience API sau khi cookie của bên thứ ba không được dùng nữa hay không? | Chúng tôi tin rằng trường hợp sử dụng này có thể xảy ra khi dùng Protected Audience như giải thích tại đây. |
| Dữ liệu liên quan đến lượt nhấp | 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õ về thời điểm lượt nhấp đó đưa ra vị trí sơ bộ. |
| (Cũng được báo cáo trong Quý 4 năm 2022) Các hàm do người dùng xác định trong Protected Audience | Các hàm do người dùng xác định (UDF) sẽ được hỗ trợ như thế nào trong Protected Audience API? Đâ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 đưa ra vấn đề này cũng đề cập rằng họ vẫn đang đánh giá những việc họ có thể làm với UDF, vì vậy hiện chưa có phản hồi có thể hành động nào ở đây để phản ứng, cho đến ít nhất là cho đến Giai đoạn phát hành rộng rãi. |
| Đơn vị tiền tệ | Không được trình bày số tiền bằng dấu phẩy động. | Chúng tôi đã giải quyết vấn đề này thông tin chi tiết tại đây. |
| Khả năng lựa chọn quảng cáo không phải DSP | Máy chủ quảng cáo có vai trò gì trong các phiên đấu giá Protected Audience API? | Chúng tôi biết các yêu cầu đối với Máy chủ quảng cáo về việc 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 hóa 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ề sự thiếu hụt giữa Protected Audience API hiện tại và các yêu cầu này. |
| GenerateBid | Dịch vụ hỗ trợ cho Google Ads đề xuất trả về nhiều quảng cáo đề xuất cho mỗi nhóm mối quan tâm quảng cáo từ generateBid và để các đề xuất đó được tính trong "scoreAd". |
Chúng tôi đang đánh giá vấn đề này. Chúng tôi hoan nghênh thêm ý kiến phản hồi tại đây. |
| Lệnh đấu giá | Phiên đấu giá Protected Audience API có bắt buộc phải là phiên đấu giá cuối cùng chạy để có thể lấy thông tin 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 để Protected Audience API hoạt động lâu dài. |
| Hoạt độ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 tại đây , đồng thời hoan nghênh các ý kiến phản hồi khác. |
| Lưu vào bộ nhớ đệm | SSP không được xây dựng per BuyerSignals của DSP nhất định từ bộ nhớ đệm nếu trạng thái của 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 hoạt động trong mọi trường hợp sử dụng đối với tín hiệu của mỗi người mua 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 khác 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ể phối hợp hoạt động như thế nào? | Hiện tại, bạn có thể sử dụng các công cụ tích hợp cho Protected Audience API ở cả hai chế độ Attribution Reporting API (báo cáo tóm tắt và báo cáo cấp sự kiện). Chúng tôi đã chia sẻ thêm thông tin về việc cải thiện việc tích hợp Protected Audience API và Attribution Reporting vào ngày 1 tháng 6. Bạn có thể đọc về chúng tại đây. |
| Điểm cuối của 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 bản thiết kế hoàn thiện 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 các Máy chủ tổng hợp đáng tin cậy được 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 cho điểm cuối báo cáo. Thiết kế hiện tại nhằm đả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 làm 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 điều phức tạp 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 phân lô mong muốn. Chúng tôi hoan nghênh thêm ý kiến phản hồi tại đây. |
| WebIDL | Quy cách hiện tại của Protected Audience API không tương thích với quy cách của 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 về sự đồng ý sẽ được xử lý như thế nào trong Protected Audience API? | Thông tin theo bối cảnh không thuộc phạm vi của Protected Audience API. Chúng tôi sẽ thảo luận về vấn đề này và hoan nghênh bạn có thêm ý kiến phản hồi. |
| Tiếp thị dựa trên tài khoản | Trường hợp sử dụng tiếp thị dựa trên tài khoản có khả thi không? | Protected Audience API hỗ trợ nhiều trường hợp sử dụng cho hoạt động tiếp thị dựa trên đối tượng. Chúng tôi vẫn đang tìm hiểu cách Protected Audience API có thể hỗ trợ tốt nhất cho trường hợp sử dụng cụ thể này, đồng thời chúng tôi hoan nghênh các ý kiến phản hồi khác từ hệ sinh thái về vấn đề này. |
| Phiên đấu giá thành phần | Những người tham gia phiên đấu giá theo thành phần tính điểm như thế nào? | Các phiên đấu giá thành phần không tính điểm trực tiếp cho Nhóm mối quan tâm – thay vào đó, chúng tính điểm 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ề giá trị sau khi thực thi generateBid:
return {
'ad': adObject,
'adCost': optionalAdCost,
'bid': bidValue,
'render': renderUrl,
'adComponents':
[adComponent1, adComponent2, ...],
'allowComponentAuction': false,
'modelingSignals': 123};
}
|
| Đóng góp bên ngoài | Yêu cầu hỗ trợ đóng góp bên ngoài trên cơ sở mã GitHub về Key/Value Server. | Chúng tôi đang tìm cách cập nhật các quy trình có liên quan để hỗ trợ đóng góp bên ngoài cho mã GitHub. |
| Quy mô nhóm mối quan tâm | Số lượng khoá tối đa mà IG có thể hỗ trợ là bao nhiêu? | 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 là một phần của kích thước đó. Chúng tôi mong muốn được thảo luận thêm về giới hạn kích thước. |
| Gộp nhóm | 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 đề kiểm soát bộ nhớ đệm HTTP để giảm số lượng lệnh gọi K/V. Ví dụ: tệp này có thể được lưu vào bộ nhớ đệm trong các phiên đấu giá thành phần cũng như trong các vùng 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 | Các 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à Phiên đấu giá, yêu cầu SelectAd có thể chỉ định phiên bản của mã được dùng cho yêu cầu đấu giá (tức là cho việc đặt giá thầu / phiên đấu giá và cho cả việc 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 thêm ý kiến phản hồi về lý do các trường hợp sử dụng này quan trọng đối với hệ sinh thái. |
| Web với ứng dụng | Hỗ trợ chia sẻ từ web đến ứng dụng của các nhóm mối quan tâm. | Web-to-app hiện không thuộc phạm vi của quy trình triển khai Protected Audience API trên Chrome và Android, nhưng chúng tôi muốn lắng 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. |
| Ẩn danh K | Cách xử lý dự phòng cho trường hợp Ẩn danh K | Chúng tôi sẽ thảo luận về vấn đề này và hoan nghênh 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)
| Chủ đề 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ế | 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 về việc cấu hình hiện tại ở cấp sự kiện không tối ưu, do đó, chúng tôi muốn mời bạn chia sẻ ý kiến phản hồi về cấu hình tối ưu trên toàn cầu. Chúng tôi rất mong nhận được thêm ý kiến phản hồi về vấn đề này và nghĩ rằng giải thích linh hoạt ở cấp sự kiện của chúng tôi 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 cấp sự kiện linh hoạt là gì? | Chúng tôi đã chia sẻ tài liệu về cấu hình cấp sự kiện linh hoạt. Tính năng này vẫn đang trong giai đoạn đề xuất và chúng tôi đang chờ thêm ý kiến phản hồi về việc liệu tính năng này có giá trị đối với 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 báo cáo xung đột từ các bên khác nhau? | Hầu hết các tình huống báo cáo đượ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 linh hoạt ở cấp sự kiện được thiết kế riêng để tăng tính linh hoạt cho các báo cáo cấp sự kiện, thường được dùng nhất trong 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/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 việc đăng ký nguồn xảy 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ể phân bổ cho nhau. Đây có vẻ là một tình huống hiếm gặp. Chúng tôi hoan nghênh mọi ý kiến phản hồi bổ sung về vấn đề này và sẽ tìm cách giải quyết nếu đó là tình huống mà nhiều công nghệ quảng cáo dường như phải đối mặt. |
| Làm việc với nhiều Công ty quảng cáo | Các DSP có thể sử dụng Attribution Reporting API làm cách nào khi một 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ợ lệnh chuyển hướng nên có thể được sử dụng ngay cả khi một nhà quảng cáo đang làm việc với nhiều công ty quảng cáo. Ngoài ra, có một số giới hạn liên quan đến các lệnh chuyển hướng để đảm bảo rằng API này 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 là sử dụng API Bộ nhớ dùng chung cho trường hợp cụ thể mà công nghệ quảng cáo đưa ra. Chúng tôi hoan nghênh mọi ý kiến phản hồi bổ sung về 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 đích đến | Trường hợp sử dụng quảng cáo tự động làm mới có thể bị ảnh hưởng do có giới hạn về đích đến. | Chúng tôi đã thảo luận về vấn đề này trong cuộc họp của WICG vào ngày 1 tháng 5 và đang xin ý kiến phản hồi về mức giới hạn hợp lý. Chúng tôi đã thêm phần Báo cáo phân bổ có giải thích về báo cáo cấp sự kiện, trong đó nêu rõ rằng trình duyệt có thể giới hạn số lượng eTLD+1 "đích" xuất hiện do các trang web nguồn đại diện. (Xem phần yêu cầu lấy dữ liệu). |
| Báo cáo phân bổ và Protected Audience | Attribution Reporting API và Protected Audience API có thể phối hợp hoạt động như thế nào? | Hiện tại, bạn có thể sử dụng các công cụ tích hợp cho Protected Audience API ở cả hai chế độ Attribution Reporting API (báo cáo tóm tắt và báo cáo cấp sự kiện). Chúng tôi đã chia sẻ thêm thông tin về việc cải thiện việc tích hợp Protected Audience API và Attribution Reporting vào ngày 1 tháng 6. Bạn có thể đọc về chúng 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 được. | Chúng tôi đã chia sẻ mã trên GitHub mà bất cứ ai cũng có thể sử dụng để đánh giá mức tăng thông tin và tác động của độ nhiễu cho bất kỳ cấu hình linh hoạt ở cấp sự kiện nào mà họ muốn kiểm thử. Chúng tôi rất mong nhận được ý kiến của những người chọn thử nghiệm bằng mã đó và muốn chia sẻ ý kiến phản hồi. |
| Đo lường phân bổ trên web và ứng dụng | Khi nào thì bạn có thể sử dụng tính năng đo lường mô hình phân bổ trên nhiều ứng dụng và web? | Vào ngày 9 tháng 5, chúng tôi đã thông báo về một thử nghiệm cho tính năng Đo lường phân bổ web và ứng dụng trên nhiều ứng dụng thông qua Attribution Reporting API. Mặc dù chúng tôi đã lên kế hoạch phát hành rộng rãi các API đo lường và mức độ liên quan trong Chrome 115, nhưng hiện tại, công cụ Đo lường phân bổ trên web và ứng dụng không có kế hoạch để phát hành rộng rãi trên Chrome 115. |
| Loại bỏ lượt chuyển đổi trùng lặp | Làm cách nào để các giải pháp đo lường độc lập được điều chỉnh so với ARA? | Theo thông lệ tiêu chuẩn hiện tại, nhà quảng cáo sẽ làm việc với nhà cung cấp dịch vụ đo lường độc lập bên thứ ba để loại bỏ báo cáo lượt chuyển đổi trùng lặp. Chúng tôi có cung cấp tài nguyên về cách loại bỏ lượt chuyển đổi trùng lặp 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ổ | Liệu có mất dữ liệu 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ừ phiên bản Chrome ổ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 nhóm người dùng Chrome theo mặc định. Dữ liệu này sẽ được tăng dần trong quá trình chúng tôi theo dõi để phát hiện các vấn đề tiềm ẩn. Mục tiêu là đạt được 100% khả năng hoạt động trong vòng vài tuần, chậm 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 bản dùng thử theo nguyên gốc Mức độ liên quan và số liệu đo lường. Kể từ tháng 7, người thử nghiệm sẽ có thể đăng ký truy cập vào các API này ở giai đoạn phát hành rộng rãi. Điều này sẽ tạo ra sự trùng lặp giữa phạm vi cung cấp bản dùng thử theo nguyên gốc và phạm vi cung cấp rộng rãi trong quá trình đăng ký. Mã thông báo bản dùng thử theo nguyên gốc của bạn sẽ có hiệu lực đến ngày 19 tháng 9. Tuy nhiên, bạn nên đăng ký các API này trước ngày hết hạn để chuyển đổi liền mạch khỏi bản dùng thử theo nguyên gốc mà không làm gián đoạn bất kỳ thử nghiệm đang diễn ra nào. Như đã đề cập trong thông báo này, dữ liệu đã đăng ký từ các phiên bản cũ (M113 trở xuống) 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 xuống 115. |
| Thanh toán | Sử dụng Báo cáo phân bổ để thanh toán 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 lập hoá đơn theo chi phí mỗi lượt chuyển đổi do yếu tố gây nhiễu được thêm vào các báo cáo tóm tắt và cấp sự kiện. Chúng tôi khuyến khích các thành viên trong hệ sinh thái chia sẻ ý kiến phản hồi về tác động đối với nhiều mô hình thanh toán bằng Attribution Reporting API trên GitHub. |
Dịch vụ tổng hợp
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Thay đổi độ trễ của báo cáo tổng hợp | Các 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] sau khi nhận được phản hồi từ hệ sinh thái | Chúng tôi rất vui khi thấy phản ứng tích cực đối với thay đổi được đề xuất và khuyến khích hệ sinh thái tiếp tục cung cấp phản hồi về các đề xuất của chúng tôi. |
| Giải pháp tại chỗ | Tôi 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 giải pháp trên đám mây, nhưng hiện tại chúng tôi chưa thể hỗ trợ các TEE tại chỗ do các giới hạn về bảo mật tại chỗ đòi hỏi việc đánh giá mất thời gian cho Hộp cát về quyền riêng tư. Do các yêu cầu về bảo mật của Hộp cát về quyền riêng tư và những thách thức lớn khi triển khai tại 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 cùng vớ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 hoan nghênh thêm ý kiến phản hồi về lý do cần có yêu cầu này. |
| Xử lý lại báo cáo cho các khoảng thời gian khác nhau | Có thể xử lý lại báo cáo cho nhiều khoảng thời gian | Chúng tôi đã nhận được những yêu cầu tương tự về việc chia các lô cho nhiều phạm vi ngày. Một đề xuất là cho phép khả năng mở rộng mã nhận dạng dùng chung với một nhãn do công nghệ quảng cáo xác định để chia báo cáo thành nhiều lô. Chúng tôi đang trong quá trình đánh giá ban đầu và sẽ cập nhật hệ sinh thái khi đề xuất này thay đổi. |
| Ngụ ý quyền riêng tư của Môi trường thực thi đáng tin cậy | Cảm xúc tích cực đối với ý nghĩa về quyền riêng tư của các Môi trường thực thi đáng tin cậy | Chúng tôi rất vui khi biết được những phản ứng tích cực của hệ sinh thái đối với các đề xuất của chúng tôi. Chúng tôi cũng hoan nghênh thêm ý kiến phản hồi trong quá trình không ngừng thử nghiệm và phát triển. |
| Điều khoản dịch vụ | Hạn chót để chấp nhận các đ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 đ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 điều khoản và điều kiện càng sớm càng tốt để tránh sự chậm trễ trong việc đăng ký. Các công ty nên liên hệ nếu có thắc mắc. |
| Khám phá quan trọng | Tính năng khám phá khoá sẽ cho phép người thử nghiệm truy vấn báo cáo tổng hợp mà không cần danh sách rõ ràng các tổ hợp phím có thể có để 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 nghiên cứu các giải pháp và cách giải quyết khả thi, đồng thời hoan nghênh thêm ý kiến phản hồi của hệ sinh thái. |
Private Aggregation API
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Nguồn gốc 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 | Sự rõ ràng về giới hạn không gian khoá 128 bit | Chúng tôi sẽ làm cho giới hạn không gian phím này rõ ràng hơn và giải quyết sự không thống nhất giữa các trang. Bạn nên sử dụng chiến lược băm để không vượt quá không gian khoá này. |
| Mức đóng góp tối đa cho mỗi báo cáo | Hiện tại, giới hạn 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ẵn sàng cân nhắc việc chia tách báo cáo thay vì cắt bớt trong giới hạn. Chúng tôi sẽ tham gia vào hệ sinh thái khi đề xuất này thay đổi. |
| 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à chỉ số cơ bản của quảng cáo thương hiệu. Để phân tích các chiến dịch của họ và phân bổ mức chi tiêu, nhà quảng cáo sử dụng báo cáo Phạm vi tiếp cận và Tần suất để ước tính trên nhiều nền tảng/nhiều thiết bị. 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 xuất hiện 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 dùng nữa. |
Nhóm Hộp cát về quyền riêng tư đang tìm hiểu 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 cookie của bên thứ ba không được dùng nữa. Chúng tôi hoan nghênh thêm ý kiến phản hồi từ hệ sinh thái. |
Hạn chế theo dõi bí mật
Gợi ý về ứng dụng tác nhân người dùng/giảm tác nhân người dùng
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| (Cũng được báo cáo trong Quý 1 năm 2023) Gợi ý về các hệ số hình dạng khác | Yêu cầu Gợi ý ứng dụng tác nhân người dùng (UA-CH) để cung cấp các hệ số hình dạng bổ sung như TV, VR | Chúng tôi vẫn đang nghiên cứu một số quyết định thiết kế quan trọng (cho dù là cung cấp một giá trị duy nhất như "TV" hay danh sách các tính năng có kiểu dáng thiết bị), nhưng vẫn quan tâm đến việc tạo nguyên mẫu cho ý tưởng này. |
| Hạn mức quyền riêng tư | Các quy định hạn chế theo 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 có quá nhiều yêu cầu được gửi. | Hiện tại, chúng tôi chưa có thông tin cập nhật mới về đề xuất 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 đối với gợi ý về ứng dụng UA trước khi cookie của bên thứ ba không được dùng nữa. |
| Khả năng tương thích với 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 nhất định truy cập vào trang web. | Có những trường hợp sử dụng hợp lệ để có danh sách thương hiệu và một trong số đó là khả năng tương thích chính xác. Một UA có thể miễn phí khi có nhiều thương hiệu cùng giải quyết các vấn đề này. |
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 |
|---|---|---|
| Gian lận và Hành vi sai trái | Các công ty có thể thiết lập các biện pháp chống gian lận bằng tính năng Bảo vệ tài sản trí tuệ bằng cách 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 lừa đảo và tác động có thể xảy ra đố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 lừa đảo vào cuối mùa hè này. Chúng tôi đang thu thập ý kiến phản hồi về hệ sinh thái để có thể hỗ trợ hiệu quả hơn cho các trường hợp sử dụng chống lừa đảo. |
| 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 nêu chi tiết các kế hoạch GeoIP của chúng tôi. Chúng tôi dự định công bố thêm thông tin về tiến trình triển khai vào Quý 3. Chúng tôi dự kiến ban đầu sẽ ra mắt tính năng Bảo vệ địa chỉ IP ở dạng tính năng chọn sử dụng của người dùng trên một tỷ lệ nhỏ lưu lượng truy cập. Lý do là vì chúng tôi nhận thấy rằng đề xuất này có thể liên quan đến một số thay đổi quan trọng cho các công ty, và chúng tôi muốn cho hệ sinh thái này có thời gian để điều chỉnh và đưa ra ý kiến phản hồi trước khi tính năng này được triển khai rộng rãi hơn. |
| Xác thực tài khoản | Tính năng xác thực tài khoản với máy chủ proxy sẽ hoạt động chính xác như thế nào? | Chúng tôi dự định công bố thêm thông tin chi tiết về việc 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ố những điều cần cân nhắc ban đầu. |
Giảm hoạt động theo dõi số trang không truy cập
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Hướng dẫn kiểm tra | Thông tin về cách thử nghiệm việc giảm thiểu hoạt động theo dõi số trang không truy cập | Chúng tôi đã xuất bản một bài đăng trên blog vào tháng 5 để cung cấp thêm thông tin về cách thử nghiệm việc Giảm thiểu hoạt động theo dõi số trang không truy cập. |
| Tài liệu | Sự rõ ràng trong Đề xuất theo dõi số trang không truy cập | Đề xuất hiện tại rất đang trong quá trình hoàn thiện và Chrome đang tiếp tục cập nhật đề xuất này để làm rõ cũng như cung cấp thông tin 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 | Việc giảm hoạt động theo dõi số trang không truy cập có xoá tất cả cookie trong một miền không? | Giảm hoạt động theo dõi số trang không truy cập (BTM) sẽ xoá toàn bộ bộ nhớ và tất cả bộ nhớ đệm, như giải thích tại đây. |
| Tránh né việc giảm hoạt động theo dõi số trang không truy cập | Việc phân loại trình theo dõi số trang không truy cập có thể được bỏ qua bằng cách thực hiện chuyển hướng với cửa sổ bật lên hoặc thẻ mới. | Quy cách Giảm thiểu 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ệnh chuyển hướng trên cùng một thẻ nhưng chúng tôi dự định sẽ xử lý các cửa sổ bật lên trong tương lai. Chúng tôi hoan nghênh thêm ý kiến phản hồi 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 |
|---|---|---|
| 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 vùng lân cận. | Chúng tôi đã nhận được ý kiến phản hồi về vấn đề này và muốn biết thêm thông tin về những tác động tiềm ẩn từ hệ sinh thái. |
Củng cố ranh giới quyền riêng tư giữa 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 những quý trước) Giới hạn miền | Yêu cầu mở rộng số lượng miền đã 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 Associated (Liên kết) để cân bằng giữa quyền riêng tư và sự tiện dụng cho những trường hợp sử dụng đã được xác định. Ngay từ đầu tiên, Chrome đã chia sẻ rằng số liệu chính xác về 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 được nhúng cần đến 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 này đang điều tra và hoan nghênh thêm ý kiến phản hồi. |
| 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à hoan nghênh thêm ý kiến phản hồi. |
| Hướng dẫn người dùng | Chrome cần giúp người dùng nâng cao nhận thức và hiểu biết về Nhóm bên thứ nhất để tăng tỷ lệ sử dụng. | Chrome cam kết cung cấp kiến thức cho người dùng về Nhóm bên thứ nhất, đồng thời đã xuất bản một bài viết trong Trung tâm trợ giúp (đường liên kết từ giao diện người dùng Chrome) về tác động này. Chrome cũng đầu tư vào việc liên tục tìm hiểu cách tốt nhất để giáo dục người dùng trong bối cảnh thích hợp. |
| Đăng 3PCD | Cookie của bên thứ ba sẽ tiếp tục tồn tại trong một Nhóm 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ể và được xác định rõ ràng, nhưng giờ đây, các cookie này yêu cầu trang web gọi chủ động thay vì có sẵn theo mặc định, như đối với trạng thái hiện tại của cookie bên thứ ba (trong Chrome).Mặc dù lệnh gọi này trong một nhóm duy nhất sẽ 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 điều này bằng cách chọn không sử dụng hành vi này trong phần Cài đặt. Bạn có thể xem thêm thông tin trong bài viết này trên Trung tâm trợ giúp (đường liên kết trên Giao diện người dùng của Chrome). Chúng tôi dự định mở rộng dựa trên hướng dẫn hiện tại cho nhà phát triển khi FPS tăng dần 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 một phần mở rộng .json. |
Chúng tôi thực hiện thay đổi này để đảm bảo hỗ trợ một số gói lưu trữ web. |
| Giấy đăng ký của IANA | Bạn phải đăng ký first_party_sets.JSON với IANA |
Chúng tôi đang xem xét đề xuất và hoan nghênh thêm ý kiến phản hồi tại đây. |
API Khung bảo vệ
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Chặn quảng cáo | Khung bảo vệ có thể giúp trình chặn quảng cáo chặn quảng cáo dễ dàng hơn. | Tiện ích có thể tương tác với khung bị bảo vệ tương tự như cách chúng sẽ tương tác với iframe. URL thực tế mà khung bảo vệ sắp được điều hướng đến cũng sẽ hiển thị với các tiện ích. Do đó, các tiện ích có thể áp dụng bất kỳ quy tắc so khớp URL nào để chặn giống như trong iframe. Việc chỉ chặn vô điều kiện tất cả khung được bảo vệ có thể phá vỡ các trường hợp sử dụng không phải quảng cáo của khung bảo vệ. |
Shared Storage API
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Phạm vi áp dụng rộng hơn | Bộ nhớ dùng chung phải là tiêu chuẩn trong toàn ngành và có sẵn 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 đang tiếp tục tích cực tham gia diễn đàn W3C để ủng hộ đề xuất, thu thập ý kiến phản hồi và thúc đẩy việc áp dụng. |
| Cổng đầu ra | Các cổng đầu ra của Bộ nhớ dùng chung quá hạn chế. | Chúng tôi đang xem xét ý kiến phản hồi này và hoan nghênh các ý kiến phản hồi khác của hệ sinh thái về lý do khiến cổng đầu ra quá hạn chế. |
| Tuân thủ quy định | Bộ nhớ dùng chung sẽ xử lý việc tuân thủ quy định, chẳng hạn như chính sách giữ lại dữ liệu như thế nào? | Bộ nhớ dùng chung mang đến cho bạn sự linh hoạt trong việc triển khai và tuỳ chỉnh logic để kiểm soát thời gian tồn tại và thời hạn của bất kỳ dữ liệu nào được lưu trữ. Công nghệ quảng cáo có thể cập nhật hoặc xoá dữ liệu của Bộ nhớ dùng chung trên cơ sở dấu thời gian ghi. |
| Thử nghiệm A/B | Có thể tiến hành thử nghiệm A/B cho Bộ nhớ dùng chung và Protected Audience API như thế nào? | Chúng tôi đang nỗ lực cung cấp 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. |
| Hạn mức 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, dữ liệu đầu vào sẽ không được lưu trữ thêm. |
| Nhiều quyền truy cập trên cùng một lượt tải trang | Điều gì xảy ra khi Bộ nhớ dùng chung được truy cập nhiều lần trong cùng một lần tải trang? | Cách tốt nhất để xử lý việc 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, việc 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ị có sẵn. |
| Chức năng iframe | Bộ nhớ dùng chung có hỗ trợ một số chức năng iframe nhất định nếu chúng không còn hoạt động sau khi cookie của bên thứ ba không được dùng nữa? | Sau khi cookie của bên thứ ba không còn được dùng nữa, bộ nhớ cục bộ trong iframe sẽ được trang web cấp cao nhất phân vùng nhưng bản thân 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 iframe trên nhiều trang web cấp cao nhất nhưng bộ nhớ cục bộ vẫn có thể được sử dụng trong iframe. |
Cookie có trạng thái được phân vùng độc lập (CHIPS)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Giới hạn phân vùng | 10 KiB trên mỗi trang web được phân vùng vẫn đáng kể và họ muốn giảm xuống. | Firefox đã chỉ định một vị trí tích cực trên CHIPS (Cookie có trạng thái dương). Để hỗ trợ Webkit, nhà phát triển nên trực tiếp cung cấp ý 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à cookie được phân vùng được ưu tiên hơn bộ nhớ được phân vùng. |
| Nội dung nhúng được xác thực | CHIP có thể ảnh hưởng đến quy trình đăng nhập SSO hiện tại do phân vùng khác nhau ảnh hưởng đến các nội dung nhúng đã xác thực. | Chúng tôi dự định tận dụng Storage Access API (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. Gần đây, chúng tôi đã gửi một ý định để nguyên mẫu. |
| Chính sách trọn đời | Các chính sách tiềm năng có giá trị lâu dài 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 toàn thời gian đối với cookie của bên thứ nhất. |
FedCM
| Chủ đề 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 việc cấp phép cho các phạm vi OAuth không phải hồ sơ | Chúng tôi đang tích cực thu thập ý kiến đóng góp của cộng đồng Web Identity thông qua FedID CG của W3C về những cách tốt nhất để hỗ trợ việc cho phép 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 cho phù hợp với các yêu cầu về hỗ trợ SAML | Đội ngũ này đang tích cực thu thập ý kiến đóng góp từ các cộng đồng nghiên cứu và giáo dục về các nhu cầu hỗ trợ SAML (ngoài hỗ trợ kết nối bằng OpenID) sau khi cookie của bên thứ ba không được dùng nữa. |
Chống nội dung rác và lừa đảo
Private State Token API (và các API khác)
| Chủ đề 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 đã thể hiện quan điểm tích cực đối với việc khám phá các tín hiệu được 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 xây dựng cho mục đích đủ để duy trì mức độ phát hiện gian lận hiện tại. | Chúng tôi rất hào hứng khi được khám phá các đề xuất mới cùng nhau trong cộng đồng chống lừa đảo và an toàn trên web, đồng thời thừa nhận và chia sẻ mối lo ngại của họ – đây chính là lý do tại sao "chống nội dung rác và gian lận" đã là một luồng công việc cốt lõi của Hộp cát về quyền riêng tư. Lý do chúng tôi tiếp tục ưu tiên đầu tư vào việc bảo vệ an toàn trên web thông qua việc cải thiện quyền riêng tư của người dùng. |
| Phản hồi tích cực về Giờ chuẩn Thái Bình Dương | 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 các trường hợp sử dụng khác nhau nhằm chống lừa đảo hoặc bảo đảm an toàn trên web. | Chúng tôi rất vui khi được hỗ trợ 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 có sẵn trên trang web dành cho nhà phát triển Chrome. Chúng tôi hoan nghênh thêm ý kiến phản hồi. |
| Gian lận và lạm dụng | Hướng dẫn ngăn chặn / phát hiện gian lận trong quảng cáo trong hoạt động đo lường sau khi cookie của bên thứ ba không còn được dùng khi giá trị nhận dạng không còn được sử dụng. | Chúng tôi đã ra mắt một số công cụ như mã thông báo trạng thái riêng tư. Các công cụ này giúp khôi phục một số tín hiệu bị cookie của bên thứ ba mất đi nhằm chống lừa đảo. Tuy nhiên, chúng tôi hiệ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 hành vi gian lận và chống hành vi sai trái nhằm duy trì khả năng thích ứng với những thay đổi khác của Hộp cát về quyền riêng tư. |
| Tỷ lệ thông tin về máy chủ gốc | Tỷ lệ thông tin từ nguồ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 quy cách để trình bày rõ hơn về loại 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ế, tối đa 6 khoá công khai có thể được sử dụng cùng một lúc, có thể đại diện cho một "trạng thái" cho một người dùng cụ thể. Bạn chỉ có thể cập nhật các tập hợp khoá này 60 ngày một lần (ngoại trừ một số ít trường hợp khi cần thay đổi 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. Mọi API web mới đều mang đến sự cân bằng giữa tiện ích được cung cấp và thông tin thực về người dùng mới mà API đó cung cấp. Chúng tôi ước tính rằng PST sẽ 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 trong khi vẫn tạo điều kiện cho các trường hợp sử dụng chính chống lừa đảo 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ó những ưu và nhược điểm. Chúng tôi muốn tiếp tục tiêu chuẩn hoá hơn nữa 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 ta hiểu rõ hơn về tiêu chuẩn. Nếu và khi có một tiêu chuẩn xuất hiện, chúng tôi cũng cam kết chuyển đổi các nhà phát triển web sang tiêu chuẩn đó một cách có trách nhiệm. |
| Vị trí bộ nhớ | Cấu hình khoá của 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 kiểm thử trong Thời gian dùng thử theo nguyên gốc, nhà phát triển cho biết họ muốn có sự linh hoạt khi lưu trữ khoá tại các URL chung thay vì trong thư mục .well-known. Định dạng cam kết chính trong PrivacyPass không quá phù hợp với phiên bản mà bộ khoá được dùng để cho phép "siêu dữ liệu công khai" ngầm ẩn giá trị. Nếu một biến thể của PrivacyPass được chuẩn hoá bằng siêu dữ liệu công khai (dưới dạng POPRF, tính năng làm mờ RSA một phần hoặc bộ khoá), chúng tôi có thể chuyển sang phiên bản PST trong tương lai để hỗ trợ việc đó. |
| 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 đã hoàn thiện, chúng tôi hy vọng có thể hỗ trợ cả phiên bản chuẩn không có tiêu đề của API này và có thể sẽ không dùng phiên bản tiêu đề nữa nếu mức sử dụng chưa đủ hoặc có đủ công cụ/hỗ trợ cho nhà phát triển để liên kết các yêu cầu phát hành/đổi thưởng tiêu chuẩn với dữ liệu khác. Chúng tôi sẽ thảo luận về vấn đề này tại đây. |
| Đăng ký | Việc giúp nhà phát hành đăng ký với nhà cung cấp trình duyệt có hữu ích không? | Chúng tôi đã cập nhật quy cách để mô tả quy trình đăng ký nhà 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ư các kế hoạch đăng ký cho phần còn lại của Hộp cát về quyền riêng tư, trong đó chúng tôi yêu cầu nhà 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 hạn chế về mặt kỹ thuật nhằm bảo vệ quyền riêng tư của người dùng. |