Báo cáo hằng quý vào quý 2 năm 2023 tóm tắt những ý kiến phản hồi về hệ sinh thái nhận được liên quan đến các đề xuất của Hộp cát về quyền riêng tư và phản hồi của Chrome.
Theo cam kết với CMA, Google đã đồng ý cung cấp công khai báo cáo hằng quý về quy trình tham gia của các bên liên quan đối với các đề xuất liên quan đến Hộp cát về quyền riêng tư (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 ý kiến phản hồi về Hộp cát về quyền riêng tư này được tạo bằng cách tổng hợp ý kiến phản hồi mà Chrome nhận được từ nhiều nguồn như liệt kê trong phần tổng quan về ý kiến phản hồi, bao gồm nhưng không giới hạn ở: Vấn đề trên GitHub, biểu mẫu phản hồi có trên privacysandbox.com, cuộc họp với các bên liên quan trong ngành và diễn đàn về tiêu chuẩn web. Chrome hoan nghênh ý kiến phản hồi nhận được từ hệ sinh thái và đang tích cực khám phá các cách tích hợp những điều học được vào các quyết định thiết kế.
Các chủ đề phản hồi được xếp hạng theo mức độ phổ biến trên mỗi API. Bạn có thể làm việc này bằng cách tổng hợp số lượng ý kiến phản hồi mà nhóm Chrome đã nhận được liên quan đến một chủ đề nhất định và sắp xếp theo thứ tự số lượng giảm dần. Chúng tôi xác định chủ đề phản hồi thường gặp bằng cách xem xét các chủ đề thảo luận của các cuộc họp công khai (W3C, PatCG, IETF), ý kiến phản hồi trực tiếp, GitHub và các câu hỏi thường gặp được gửi đến các nhóm nội bộ và biểu mẫu công khai của Google.
Cụ thể hơn, biên bản cuộc họp cho các cuộc họp cơ quan tiêu chuẩn web đã được xem xét và để lấy ý kiến phản hồi trực tiếp, chúng tôi đã xem xét hồ sơ của Google về các cuộc họp 1:1 với các bên liên quan, email mà từng kỹ sư nhận được, danh sách gửi thư của API và biểu mẫu phản hồi công khai. Sau đó, Google đã phối hợp với những nhóm có tham gia vào những hoạt động tiếp cận khác nhau này để xác định mức độ phổ biến tương đối của các chủ đề xuất hiện trong từng API.
Nội dung giải thích về các câu trả lời của Chrome cho ý kiến phản hồi được phát triển từ các Câu hỏi thường gặp đã phát hành, câu trả lời thực tế cho những vấn đề do các bên liên quan nêu ra và xác định vị trí cụ thể cho mục đích của bài tập báo cáo công khai này. Phản ánh trọng tâm hiện tại của việc phát triển và kiểm thử, cụ thể là các câu hỏi và ý kiến phản hồi đã nhận được về Chủ đề, Protected Audience API và API Báo cáo phân bổ.
Phản hồi nhận được sau khi kết thúc kỳ báo cáo hiện tại có thể chưa có phản hồi của Chrome được xem xét.
Bảng chú giải thuật ngữ từ viết tắt
- KHỐI
- Cookie có trạng thái được phân vùng độc lập
- DSP (Bộ xử lý tín hiệu kỹ thuật số)
- Nền tảng bên cầu
- FedCM
- Quản lý thông tin xác thực liên kết
- FPS
- Nhóm bên thứ nhất
- IAB (Cục Quảng cáo tương tác)
- Cục quảng cáo tương tác
- IDP (nhà cung cấp danh tính)
- Nhà cung cấp danh tính
- IETF (Lực lượng chuyên trách kỹ thuật Internet)
- Lực lượng chuyên trách kỹ thuật Internet
- Số hiệp ném bóng
- Địa chỉ giao thức Internet
- openRTB
- Đặt giá thầu theo thời gian thực
- QUÁ GIỜ
- Bản dùng thử theo nguyên gốc
- PatCG
- Nhóm cộng đồng công nghệ quảng cáo riêng tư
- RP
- Đảng độc lập
- SSP
- Nền tảng bên cung
- TEE
- Môi trường thực thi đáng tin cậy
- UA
- Chuỗi tác nhân người dùng
- UA-CH
- Gợi ý ứng dụng tác nhân người dùng
- W3C
- Tập đoàn World Wide Web
- BÌNH LUẬN
- Tình trạng mù IP có chủ ý
Ý kiến phản hồi chung, không có API/Công nghệ cụ thể
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Quản lý dữ liệu và tuân thủ quy định | Hướng dẫn hệ sinh thái về cách sử dụng Hộp cát về quyền riêng tư theo các yêu cầu theo quy định. | Giống như với bất kỳ công nghệ mới nào, mỗi công ty 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ủ pháp luật; Google không thể tư vấn pháp lý cho người khác. Tuy nhiên, chúng tôi biết rằng đây là khu vực đáng quan tâm chính đố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 để tạo cơ sở cho việc đưa ra các đánh giá pháp lý cần thiết. Đồng thời, chúng tôi đ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 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 phối hợp với CMA để thiết kế các thử nghiệm nhằm cung cấp bức tranh về tác động của việc ngừng sử dụng cookie của bên thứ ba và việc đưa ra các đề xuất trong khuôn khổ Hộp cát về quyền riêng tư trong hệ sinh thái. Vào tháng 4, CMA đã công bố hướng dẫn tổng quan về những điều sẽ xảy ra trong giai đoạn Thử nghiệm 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 với CMA. |
| Chế độ kiểm thử do Chrome hỗ trợ | Cung cấp thêm thông tin và nội dung giải thích về lịch thử nghiệm | 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 do Chrome hỗ trợ. Đây chưa phải là thông tin cuối cùng. Chúng tôi sẽ công bố thêm hướng dẫn triển khai trong quý 3 năm 2023. |
| Bộ nhớ được phân vùng | Bộ nhớ được phân vùng có được sử dụng trong quá trình thử nghiệm có hỗ trợ Chrome không? | Tính năng phân vùng bộ nhớ sẽ được gửi đến tất cả người dùng trước khi thử nghiệm việc ngừng sử dụng cookie của bên thứ ba diễn ra. Do đó, tính năng này sẽ được bật cho tất cả các nhóm của thử nghiệm. Các trang web sẽ có lựa chọn bật bản dùng thử không dùng nữa để nhận 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 hiện có 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 liên quan đến 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ác công nghệ quảng cáo báo cáo vấn đề và cho phép chuyển lên cấp trên nếu cần. Vui lòng xem bài đăng của chúng tôi dành cho nhà phát triển để biết thêm thông tin trên các diễn đàn công khai và riêng tư cũng như ý kiến 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à chúng tôi muốn biết tiến trình nào phù hợp hơn từ hệ sinh thái. |
| Mã số DUNS | Thông tin khác về yêu cầu về số D-U-N-S đối với việc Đăng ký và chứng thực | Người tham gia có thể xem các yêu cầu để lấy 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 nên nhớ kiểm tra trang web cho thị trường cụ thể mà họ quan tâm. Tuy nhiên, nhìn chung, người tham gia cần phải 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ý 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 đơn đăng ký hoàn tất, D&B sẽ xem xét và cấp Mã số D-U-N-S nếu đơn đăng ký đó được phê duyệt. |
| Chuyển từ giai đoạn dùng thử ban đầu 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 kiểm thử Bản dùng thử theo nguyên gốc hiện tại không? | Từ tháng 7, người kiểm thử sẽ có thể truy cập vào các API đo lường và mức độ liên quan trong giai đoạn phát hành rộng rãi. Việc này sẽ làm 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 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ọ. Người trả lời phụ thuộc vào phương pháp trả lời câu hỏi riêng lẻ. |
| Giá trị thông số | Các giá trị thông số như độ nhiễu, ngưỡng ẩn danh và ngân sách quyền riêng tư được xác định bằng cách nào? | Nội dung giải thích này trên GitHub trình bày các nguyên tắc chung hơn đằ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 thị nội dung và quảng cáo có liên quan
Chủ đề
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| 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 vào cộng đồng nghiên cứu, trình bày nghiên cứu của mình về các đặc điểm quyền riêng tư của Topics API qua các 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 nhiều thành viên bên ngoài của cộng đồng nghiên cứu tương tác với lĩnh vực này. API Chủ đề bảo vệ người dùng khỏi hoạt động theo dõi chung trên web bằng cách gây khó khăn cho việc theo dõi người dùng trên quy mô lớn. Các bài viết này cho thấy chúng tôi đang làm việc này thành công nhờ Topics API. Cookie này riêng tư hơn cookie của bên thứ ba và bảo vệ người dùng, đồng thời hỗ trợ các trang web mà họ thích truy cập. |
| Phân loại chủ đề không đủ chi tiết | Hệ thống phân loại chủ đề rộng không bao gồm những chủ đề chi tiết hơn, bao gồm cả những chủ đề cụ thể theo khu vực. | Để đáp lại những ý kiến phản hồi trước đó từ 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 cách 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 từ hệ sinh thái. Trong quá trình cải thiện cách phân loại mới này, 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 mới loại bỏ các danh mục mà chúng tôi hay nghe nói đến là ít 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 của chúng tôi về việc loại trừ các chủ đề có thể mang tính nhạy cảm. Hệ sinh thái nên xem xét cách phân loại mới nhất và đưa ra ý kiến phản hồi về những thay đổi này. |
| 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ề tần suất phát hành thuật toán phân loại và thuật toán phân loại Chủ đề, cũng như cách các công ty có thể chuẩn bị cho những điểm 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 cách phân loại sẽ phát triển theo thời gian và để việc quản trị cách phân loại cuối cùng sẽ 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 ngành. Chúng tôi cũng đã chia sẻ kế hoạch tăng dần số lượng trong nhóm công bố chủ đề. |
| Tác động đến tín hiệu của bên thứ nhất | Việc số lượng Chủ đề tăng lên trong bản cập nhật Hệ thống phân loại gần đây có thể mang lại giá trị cao, do đó làm giảm giá trị của các tín hiệu dựa trên mối quan tâm khác của bên thứ nhất. | 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ề cách phân loại mới mà Google đề xuất với một số thành viên 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 đã nói rằng sự hữu ích 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à tiện ích lớn hơn sẽ mang lại hiệu quả cạnh tranh tổng thể tốt hơn – đặc biệt là đối với 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 nhất quán với nhận xét này của CMA. |
| Tính hữu ích cho nhiều kiểu bên liên quan | Các công nghệ quảng cáo đóng vai trò là SSP và DSP có thể có nhiều lợi thế hơn so với những bên khác trong hệ sinh thái. | Phản hồ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ư theo cách không cản trở sự cạnh tranh bằng cách tự ưu tiên hoạt động kinh doanh của chính Google, đồng thời có tính đến tác động đến sự cạnh tranh trong ngành quảng cáo kỹ thuật số, cũng như đến các nhà xuất bản và nhà quảng cáo, bất kể quy mô. Chúng tôi sẽ tiếp tục phối hợp chặt chẽ với CMA để đảm bảo công việc của chúng tôi tuân thủ các cam kết này. Khi thử nghiệm Hộp cát về quyền riêng tư, một trong những câu hỏi chính mà chúng tôi sẽ đánh giá là hiệu suất của các công nghệ mới đối với nhiều kiểu bên liên quan. Ý kiến phản hồi rất quan trọng trong lĩnh vực này, đặc biệt là những ý kiến phản hồi cụ thể và hữu ích có thể giúp chúng tôi cải thiện thiết kế kỹ thuật hơn nữa. Chúng tôi đã làm việc với CMA để phát triển phương pháp thử nghiệm định lượng và hỗ trợ CMA xuất bản một ghi chú về thiết kế thử nghiệm để cung cấp thêm thông tin cho những người tham gia thị trường và có cơ hội nhận xét về các phương pháp đượ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 vào trình duyệt, việc phân mảnh có phải dẫn đến các chủ đề con không bao giờ tăng lên đầu không? | Chrome hiện đang đánh giá các phương pháp xếp hạng khác và tìm hiểu các tín hiệu khác có thể cải thiện thứ hạng. Chúng tôi sẽ sớm thông báo kế hoạch sửa đổi cho hệ sinh thái. |
| Độ nhạy | Mục tiêu của Topics API phải là đảm bảo thông tin người dùng thu thập được hoặc bắt nguồn từ Topics API phải ít nhạy cảm hơn về cá nhân so với thông tin có thể lấy được bằng các phương pháp theo dõi hiện nay. | Chúng tôi tin rằng Topics API có tính 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 ra các danh mục nhạy cảm. Tuy nhiên, chúng tôi tin rằng API Chủ đề 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 API, chúng tôi đang đưa mã nhận dạng phân loại. Trong quá trình chuyển sang mô hình quản trị dài hạn, bạn nên xem xét đối tượng Chủ đề và bổ sung siêu dữ liệu về việc lập phiên bản (nếu cần). |
| Kiểm soát của nhà xuất bản | Nhà xuất bản phải cho biết loại Chủ đề nên phân loại trang web của họ. | 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 nói chung, nhưng các trang web cụ thể bị phân loại sai không bị tác động nhiều hơn và không bị thiệt 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 ngữ 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 đối chiếu 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 cách phân loại của họ có thể gây ra 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 các chủ đề ít phổ biến hơ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 tại | Điều này có thể đã xảy ra, như đã thảo luận trên GitHub, nhưng chúng tôi hoan nghênh 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 | API Chủ đề có bị ảnh hưởng 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? | Sẽ không có dữ liệu nào bị mất khi người dùng 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. |
| 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ố biện pháp giảm thiểu để đảm bảo quyền riêng tư, như đã nêu tại đây. |
| Gian lận và sử dụng sai mục đích | Cách ngăn chặn hành vi 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ủ đề | Trang web có thể yêu cầu thay đổi phân loại Chủ đề không? | Chúng tôi muốn biết ý kiến của hệ sinh thái về chủ đề này và hoan nghênh ý kiến phản hồi tại đây. |
| Trang web của nhà cung cấp chủ đề | Chỉ định một số trang web nhất định lưu trữ nội dung cho nhiều Chủ đề làm "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ẻ mà chúng tôi cung cấp trên các trang đó. | Chúng tôi đang thảo luận đề xuất tại đây và hoan nghênh thêm ý kiến phản hồi. |
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 | 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 một lượng thời gian đáng kể để xem xét việc định hình lưu lượng truy cập và đề xuất là các SSP nên tận dụng việc lưu vào bộ nhớ đệm. |
| Kiểm tra âm lượng | Khó kiểm thử Protected Audience vì các SSP và DSP gặp nhiều 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 tương tác với các đối tác SSP và DSP để áp dụng và thử nghiệm Đối tượng được bảo vệ. Giai đoạn phát hành rộng rãi đã bắt đầu 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 PA sẽ giúp đố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 công sức và chi phí đáng kể. | Chúng tôi xác nhận rằng rất khó áp dụng các công nghệ mới, 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 phối hợp chặt chẽ với nhiều bên liên quan để hướng dẫn và hỗ trợ cho các hoạt động của họ, đồng thời liên tục đánh giá các thiết bị gia tốc khác nhằm hỗ trợ quá trình á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 những 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 việc hỗ trợ TEE tại chỗ hiện không khả thi do các hạn chế về bảo mật tại chỗ cần đến việc đánh giá 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 quan trọng do việc triển khai tại chỗ gây ra, chúng tôi tin rằng việc tiếp tục mở rộng và cải thiện hoạt động triển khai trên đám mây (ví dụ: hỗ trợ GCP cùng với AWS) là lợi ích nhất đối với 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 bạn cần đáp ứng yêu cầu nà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á. Những máy chủ này sẽ tương quan với việc sử dụng công nghệ quảng cáo, nhằm đạt được một trong các mục tiêu thiết kế của chúng tôi. |
| Tiến trình của K-Anon | Khi nào các quy tắc ràng buộc k-anonymity sẽ được thực thi trên `renderUrl` ? | Chúng tôi đang nghiên cứu nội dung giải thích về tiến trình thực thi mà chúng tôi sẽ sớm đưa ra. |
| Các hạn chế của runAd Auction | Chrome có thể hạn chế để runAdAuction chỉ gọi được từ trang đầu tiên không? |
Mặc dù thiết kế của chúng tôi hỗ trợ đầy đủ cho runAdAuction để có thể gọi từ trang đầu, nhưng chúng tôi cho rằng sẽ có hại hơn cho nhà xuất bản nếu giới hạn rằng runAdAuction chỉ có thể gọi được từ miền cấp cao nhất.Theo hệ sinh thái, chúng tôi đặc biệt biết được 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. Phản hồi đó phù hợp với nguyên tắc chung của quá trình phát triển web rằng 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 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 sẽ mang đến cho nhà xuất bản sự linh hoạt để tìm ra đường dẫn phù hợp nhất với các yêu cầu của họ. |
| Hỗ trợ triển khai | Chrome có thể tạo hoặc đóng góp cho 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 việc phát triển các công nghệ bảo đảm quyền riêng tư không phụ thuộc vào cookie của bên thứ ba hay 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 thức hoạt động của 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 API trên kho lưu trữ GitHub và chúng tôi 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ông nghệ nền tảng chứ không phải quy đị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 của họ một cách hiệu quả nhất với 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á cho nhiều người bán | Chrome có buộc chia sẻ quảng cáo chiến thắng theo "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ế để mang lại khả năng cho các bên khởi tạo phiên đấu giá nhiều người bán 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 thấy rằng trình duyệt không có cách nào để phân biệt một thông tin nào đó có phải là thông tin tốt nhất theo bối cảnh hay không, vì vậy, chúng tôi không thể chặn hoặc đòi hỏi một số thông tin nhất định. |
| Lựa chọn ưu tiên của người dùng cho tính năng theo dõi sự đồng ý | Adtech yêu cầu PA cách triển khai chính xác tính năng theo dõi sự đồng ý của người dùng | Phản hồi của chúng tôi bao gồm những nội dung chúng tôi đã nói 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 những mẫu quảng cáo nào hiển thị hoặc cách lựa chọn các mẫu quảng cáo đó." Chúng tôi đã thảo luận về một số tình huống liên quan đến vấn đề này trong Cuộc họp đối tượng được bảo vệ của WICG vào tháng 5 và hoan nghênh thêm ý kiến phản hồi và thảo luận 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. 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ợ quá trình tích hợp. |
| Dạng thức | Video có được Protected Audience API hỗ trợ 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 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ả lại một trong hai định dạng thông qua một RenderScriptURL. Thông số kỹ thuật của VAST đã được cập nhật gần đây để hỗ trợ API Báo cáo phân bổ. Các trang web phân phát quảng cáo dạng video sẽ cần chuẩn bị cho cách thức 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ể chuyển URL từ iframe Protected Audience sang trình phát video. Đối với Khung bảo vệ, chúng tôi sẽ nỗ lực giải quyết nhu cầu về video trước khi yêu cầu sử dụng Khung bảo vệ không trước năm 2026. |
| Tốc độ | Trường hợp sử dụng Pacing 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 của yêu cầu này và có nhiều thông tin chi tiết hơn từ nhiều đối tác SSP hơn vì từ trước đến nay, đây chủ yếu vẫn là mối quan ngại của DSP. |
| Tần suất cập nhật | Tần suất các 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ư 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ó những giải pháp khác để cho phép các 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 khác nhau, chẳng hạn như tra cứu K/V. |
| Quản lý chất lượng quảng cáo | Nhà xuất bản làm cách nào để triển khai quy trình quản lý chất lượng quảng cáo? | Hiện nay, Protected Audience API cung cấp chức năng giúp nhà xuất bản thông báo cho SSP 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á, trước khi đặt giá thầu (tức là danh sách từ chối dựa trên các nhãn được liên kết với quảng cáo). Chúng tôi hoan nghênh mọi ý kiến phản hồi về mọi chức năng bổ sung mà hệ sinh thái này 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 ngừng sử dụng forDebuggingOnly đối với các sự kiện mất dữ liệu sau khi ngừng sử dụng cookie của bên thứ ba. Chúng tôi dự định sớm ngừng cung cấp forDebuggingOnly đối với các sự kiện giành chiến thắng vào năm 2026. |
| Nhóm mối quan tâm trên nhiều thiết bị | Đề xuất bật các 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 hiệu cao của việc nhắm mục tiêu trên nhiều thiết bị đặt 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) Tiếp thị lại động | Tôi có thể tiếp tục 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 ngừng hoạt động không? | Chúng tôi tin rằng trường hợp sử dụng này có thể sử dụng được nhờ 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. |
Hiện tại, chúng tôi yêu cầu bạn cung cấp thông tin rõ ràng hơn về thời điểm lượt nhấp xảy ra để đưa ra nhận định sơ bộ. |
| (Cũng đã báo cáo vào 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) được hỗ trợ như thế nào trong Protected Audience API? Đây là các hàm mà người dùng cuối có thể lập trình để mở rộng chức năng của API. | Công nghệ quảng cáo đã nêu ra vấn đề này cũng cho biết rằng họ vẫn đang đánh giá những việc có thể làm với UDF. Vì vậy, vẫn chưa có phản hồi có thể hành động nào để phản hồi, í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 biểu thị số tiền bằng tiền tệ bằng dấu phẩy động. | Chúng tôi đã giải quyết vấn đề này chi tiết tại đây. |
| Các chức 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á Protect Audience API? | Chúng tôi đã biết các yêu cầu để 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. Hiện tại, chúng tôi đang đánh giá bản 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ợ đối với đề 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 quảng cáo từ generateBid và có điểm số của các quảng cáo đó trong "scoreAd". |
Vấn đề này đang được đánh giá. Chúng tôi hoan nghênh thêm ý kiến phản hồi tại đây. |
| Đơn đặt giá đấu giá | Phiên đấu giá Protected Audience API có cần phải là phiên đấu giá cuối cùng được chạy để 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 để Protected Audience API chạy phiên bản cuối cùng. |
| Điều hướng không do người dùng khởi tạo | Hiển thị hoạt động đ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 và hoan nghênh thêm ý kiến phản hồi. |
| Chức năng lưu vào bộ nhớ đệm | SSP không được tạo một DSP nhất định cho mỗi người mua 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 hoạt động cho 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 thêm mọi ý kiến phản hồi 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à Đối tượng được bảo vệ | API Báo cáo phân bổ và Protected Audience API có thể hoạt động cùng nhau bằng cách nào? | Các hoạt động tích hợp hiện có cho Protected Audience API ở cả hai chế độ Attribution Reporting API (báo cáo tóm tắt và cấp sự kiện). Chúng tôi đã chia sẻ thêm thông tin về việc cải tiến Protected Audience API và quá trình tích hợp Báo cáo phân bổ 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 máy chủ có phải là Máy chủ tổng hợp đáng tin cậy trong thiết kế hoàn thiện không? | Điểm cuối máy chủ là đ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 điểm cuối báo cáo nào. Thiết kế hiện tại nhằm đảm bảo rằng bản thân các báo cáo tổng hợp (với tải trọng đã mã hoá) không làm rò rỉ dữ liệu trên nhiều trang web, do đó, bạn không cần phải có một điểm cuối đáng tin cậy. Một chức năng khác là các công nghệ quảng cáo có thể sẽ có các chiến lược tạo lô khác nhau mong muốn. Chúng tôi hoan nghênh thêm ý kiến phản hồi 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ố 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 ý | Protected Audience API sẽ xử lý việc truyền tín hiệu đồng ý 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 đang thảo luận về vấn đề này và hoan nghênh bạn chia sẻ thêm ý kiến phản hồi. |
| Tiếp thị dựa trên tài khoản | Tôi có thể dùng các trường hợp 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 cho hoạt độ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 cho trường hợp sử dụng cụ thể này, và hoan nghênh thêm ý kiến phản hồi 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á thành phần nhận được điểm gì? | Phiên đấu giá thành phần không trực tiếp tính điểm Nhóm mối quan tâm – mà sẽ chấm điểm quảng cáo và giá thầu mà DSP gửi qua hàm generateBid. Hàm generateBid() chạy theo 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};
}
|
| Khoản đó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 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 có liên quan để hỗ trợ các đóng góp bên ngoài cho mã GitHub. |
| Quy mô nhóm đối tượng có cùng 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 như một phần trong đó. Chúng tôi hoan nghênh các cuộc thảo luận thêm về giới hạn kích thước. |
| Lô sản phẩm | Làm cách nào để giảm số lượng cuộc 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ụ: dữ liệu 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ị 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 | 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 mã được dùng cho yêu cầu đấu giá (tức là dành cho chiến lược đặt giá thầu / phiên đấu giá và cả báo cáo). |
| Bộ nhớ dùng chung | Hỗ trợ ghi dữ liệu 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. Tuy nhiên, chúng tôi hoan nghênh thêm ý kiến phản hồi về lý do tại sao các trường hợp sử dụng như vậy lại quan trọng đối với hệ sinh thái. |
| Web với ứng dụng | Hỗ trợ chia sẻ các nhóm mối quan tâm từ web đến ứng dụng. | Web-to-app hiện không thuộc phạm vi triển khai Protected Audience API trên Chrome và Android, 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. |
| Ẩn danh K | Cách xử lý dự phòng theo tính nă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)
| 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ế | Ý 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 biết 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 đề nghị bạn cung cấp ý kiến phản hồi về cấu hình chung tối ưu. Chúng tôi luôn sẵn sàng lắng nghe các ý kiến phản hồi khác về vấn đề này và cho rằng thông tin giải thích linh hoạt ở cấp sự kiện cũng có thể giúp giải quyết vấn đề này. |
| Cấu hình cấp sự kiện linh hoạt | Trạng thái của tính năng linh hoạt cấu hình cấp sự kiện 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 tính năng này có hữu ích đối với hệ sinh thái hay không. |
| Cấu hình cấp sự kiện linh hoạt | Có thể điều chỉnh các báo cáo xung đột từ các bên khác nhau bằng cách nào? | 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 đượ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 cho trường hợp sử dụng tối ưu hoá). Chúng tôi hoan nghênh mọi ý kiến phản hồi/ý kiến phản hồi khác liên quan đến trường hợp này trong hệ sinh thái. |
| Đă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 lượt đă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ể 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 khác về 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 có vẻ gặp phải. |
| Làm việc với nhiều đại lý quảng cáo | DSP có thể sử dụng Attribution Reporting API như thế nào khi nhà quảng cáo đang làm việc với nhiều đại lý quảng cáo? | API này hỗ trợ tính năng chuyển hướng, do đó, bạn có thể dùng API này 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, có một số hạn chế liên quan đến việc chuyển hướng để đảm bảo rằng 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 là sử dụng API Bộ nhớ dùng chung trong trường hợp cụ thể mà công nghệ quảng cáo được đưa ra. Chúng tôi hoan nghênh mọi ý kiến phản hồi khác về trường hợp này và sẽ tiếp tục thử nghiệm dựa trên ý kiến phản hồi đó. |
| Giới hạn đối với đí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 việc áp dụng cá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 WICG 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 Báo cáo phân bổ có giải thích về báo cáo cấp sự kiện cho biết rằng trình duyệt có thể giới hạn số lượng eTLD+1 "đích đến" do trang web nguồn đại diện. (Xem yêu cầu kéo). |
| Báo cáo phân bổ và Đối tượng được bảo vệ | API Báo cáo phân bổ và Protected Audience API có thể hoạt động cùng nhau bằng cách nào? | Các hoạt động tích hợp hiện có cho Protected Audience API ở cả hai chế độ Attribution Reporting API (báo cáo tóm tắt và cấp sự kiện). Chúng tôi đã chia sẻ thêm thông tin về việc cải tiến Protected Audience API và quá trình tích hợp Báo cáo phân bổ vào ngày 1 tháng 6. Bạn có thể đọc về chúng tại đây. |
| Cấu hình cấp sự kiện linh hoạt | Chia sẻ các phương pháp hay nhất để mô phỏng độ nhiễu vì giờ đây bạn có thể định cấu hình các thông số. | Chúng tôi có mã chia sẻ trên GitHub mà bất cứ ai cũng có thể dùng để đánh giá mức thu được thông tin và ảnh hưởng về độ nhiễu đối với bất kỳ cấu hình cấp sự kiện linh hoạt nào mà họ muốn thử nghiệm. Chúng tôi muốn biết ý kiến của bất kỳ ai chọn thử nghiệm bằng mã này và muốn chia sẻ ý kiến phản hồi. |
| Đo lường mô hình phân bổ trên nhiều ứng dụng và web | Khi nào tính năng đo lường mô hình phân bổ trên nhiều ứng dụng và web sẽ được cung cấp? | Vào ngày 9 tháng 5, chúng tôi đã công bố một thử nghiệm cho tính năng Đo lường mô hình phân bổ trên nhiều ứng dụng và web thông qua API Báo cáo phân bổ. 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 tính năng Đo lường phân bổ trên nhiều ứng dụng và web hiện chưa được lên 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 để điều chỉnh các giải pháp đo lường độc lập 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 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 lượt chuyển đổi trùng lặp. Chúng tôi đã cung cấp các 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ừ Bản ổn định Chrome 115, chúng tôi sẽ bắt đầu bật các API Đo lường và Mức độ liên quan cho một nhóm người dùng Chrome theo mặc định. Phạm vi cung cấp rộng rãi này sẽ tăng dần khi chúng tôi theo dõi các vấn đề tiềm ẩn. Mục tiêu sẽ là đạt 100% khả năng sử dụng trong một khoảng thời gian vài tuần, trước quý 3 năm 2023. Quá trình 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à Đo lường. Kể từ tháng 7, người thử nghiệm có thể đăng ký để truy cập vào các API này trong giai đoạn phát hành rộng rãi. Việc này sẽ làm 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 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 hết hạn để có thể 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. Lỗi mất dữ liệu này sẽ không xuất hiện trong báo cáo gỡ lỗi, đồng thời chúng tôi sẽ cố gắng tránh tình trạng mất dữ liệu từ 114 xuống 115. |
| Thanh toán | Sử dụng Báo cáo phân bổ để lập hoá đơ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 lập hoá đơn theo chi phí mỗi lượt chuyển đổi vì độ nhiễu được thêm vào báo cáo tóm tắt và báo cáo cấp sự kiện. Chúng tôi khuyến khích những người chơi 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 API Báo cáo phân bổ 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 về độ trễ đối với báo cáo tổng hợp | Phản ứng tích cực với đề xuất thay đổi độ trễ báo cáo tổng hợp thành từ [10-60 phút] thành [0-10 phút] theo phản hồi từ hệ sinh thái | Chúng tôi rất vui mừng khi thấy phản ứng tích cực với thay đổi được đề xuất, đồng thời khuyến khích hệ sinh thái tiếp tục đưa ra ý kiến 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 riêng không? | Mặc dù chúng tôi đang tìm hiểu những 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 việc hỗ trợ TEE tại chỗ hiện không khả thi do các hạn chế về bảo mật tại chỗ cần đến việc đánh giá 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 quan trọng do việc triển khai tại chỗ gây ra, chúng tôi tin rằng việc tiếp tục mở rộng và cải thiện hoạt động triển khai trên đám mây (ví dụ: hỗ trợ GCP cùng với AWS) là lợi ích nhất đối với 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 bạn cần đáp ứng yêu cầu này. |
| Xử lý lại báo cáo trong các khoảng thời gian khác nhau | Khả năng xử lý lại báo cáo trong các khoảng thời gian khác nhau | Chúng tôi đã nhận được những yêu cầu tương tự về việc chia thành nhiều lô cho các phạm vi ngày khác nhau. Một đề xuất là cho phép khả năng mở rộng mã nhận dạng được chia sẻ với nhãn do công nghệ quảng cáo xác định, nhờ đó, báo cáo có thể được chia thành nhiều lô. Chúng tôi đang bước đầu đánh giá quá trình này và sẽ tiếp tục cập nhật hệ sinh thái khi đề xuất này phát triển. |
| Hệ quả về quyền riêng tư của môi trường thực thi đáng tin cậy | Thái độ tích cực đối với ảnh hưởng 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 nhận được phản ứng tích cực từ hệ sinh thái liên quan đến các đề xuất của mình. Ngoài ra, chúng tôi còn hoan nghênh thêm ý kiến phản hồi để tiếp tục lặp lại và phát triển. |
| Điều khoản dịch vụ | Thời hạn để 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 đưa ra thời hạn phải chấp nhận các điều khoản và điều kiện này, 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 này càng sớm càng tốt để tránh sự chậm trễ trong quá trình đă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. |
| Tìm hiểu phím | Tính năng khám phá khoá sẽ cho phép người thử nghiệm truy vấn các 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ể sử dụng để xử lý báo cáo tóm tắt 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 khả thi, đồng thời hoan nghênh những ý kiến phản hồi khác từ hệ sinh thái. |
API tổng hợp riêng tư
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Nguồn báo cáo | Nguồn gốc báo cáo được xác định như thế nào? | Nguồn 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 | Mức độ rõ ràng về giới hạn không gian khoá 128 bit | Chúng tôi sẽ làm rõ giới hạn không gian khoá này và giải quyết những điểm không thống nhất giữa các trang. Bạn nên sử dụng chiến lược băm để duy trì được vị trí của phím 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ẵn sàng xem xét việc phân tách các báo cáo thay vì cắt bớt ở mức giới hạn. Chúng tôi sẽ phối hợp với hệ sinh thái 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à chỉ số cơ bản của hoạt động 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/nhiều thiết bị cho báo cáo Phạm vi tiếp cận và Tần suất để phân tích các chiến dịch của họ 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 xuất hiện trong môi trường của bên thứ ba. Vì vậy, các công nghệ quảng cáo đã yêu cầu giải pháp thay thế 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 của hệ sinh thái. |
Giới hạn theo dõi bí mật
Giảm thiểu tác nhân người dùng/Gợi ý ứng dụng tác nhân người dùng
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| (Cũng được báo cáo vào Quý 1 năm 2023) Gợi ý cho các kiểu dáng khác | Yêu cầu tính năng 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, thực tế ảo (VR) | Chúng tôi vẫn đang hoàn thiện một số quyết định thiết kế quan trọng (chẳng hạn như cung cấp một giá trị duy nhất như "TV" hay danh sách các chức năng đối với kiểu dáng), nhưng vẫn quan tâm đến việc tạo mẫu ý tưởng này. |
| Ngân sách quyền riêng tư | Các 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 có quá nhiều yêu cầu được gửi. | Hiện tại, chúng tôi không có thông tin cập nhật mới nào về đề xuất Ngân sách quyền riêng tư. Tuy nhiên, chúng tôi đã cam kết không hạn chế các yêu cầu cung cấp gợi ý từ ứ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. | Danh sách thương hiệu có một số trường hợp sử dụng hợp lệ, trong đó có một số trường hợp sử dụng chính xác là khả năng tương thích chính xác. Một UA được phép có nhiều thương hiệu để giải quyết những vấn đề này. |
Bảo vệ IP (trước đây là Gnatcatcher)
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Gian lận và sử dụng sai mục đích | Làm cách nào để các công ty có thể thiết lập các biện pháp chống gian lận bằng tính năng Bảo vệ IP? | Chúng tôi hiểu tầm quan trọng của các trường hợp sử dụng chống gian lận cũng như tác động có thể xảy ra đối với những trường hợp sử dụng đó. Chúng tôi dự định sẽ công bố thêm thông tin về việc hỗ trợ chống gian lận vào cuối mùa hè này. Chúng tôi đang thu thập ý kiến phản hồi của hệ sinh thái về cách hỗ trợ tốt hơn cho các trường hợp sử dụng chống gian lận. |
| GeoIP | Thông tin thêm về tiến trình thử nghiệm và triển khai cho GeoIP | Gần đây, Chrome đã công bố thông tin mới nêu chi tiết các gói GeoIP của chúng tôi. Chúng tôi dự định sẽ 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ệ IP dưới dạng một tính năng mà người dùng chọn sử 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 đề xuất này có thể liên quan đến một số thay đổi quan trọng cho các công ty, nên chúng tôi muốn 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 triển khai tính năng này rộng rãi hơn. |
| Xác thực tài khoản | Quá trình 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 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ố 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 thử | Thông tin về cách thử nghiệm để 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 với thông tin thêm về cách kiểm tra 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 đang trong quá trình hoàn thiện và Chrome đang tiếp tục cập nhật đề xuất này để cung cấp thông tin rõ ràng và rõ ràng cho hệ sinh thái. Chúng tôi đang nỗ lực cung cấp thêm thông tin 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 miền không? | Tính nă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à toàn bộ bộ nhớ đệm, như giải thích ở đây. |
| Tránh né việc theo dõi số trang không truy cập | Trình theo dõi số trang không truy cập có thể 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. | Đặc tả Giảm thiểu 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 chuyển hướng cùng thẻ nhưng chúng tôi dự định thực hiện các luồng 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. |
Ngân sách quyền riêng tư
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Mục tiêu vùng lân cận | Ngân sách quyền riêng tư có thể tác động đến các trường hợp sử dụng nhắm mục tiêu 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à rất muốn tìm hiểu thêm về các tác động có thể xảy ra từ hệ sinh thái. |
Củng cố ranh giới quyền riêng tư trên nhiều trang web
Nhóm bên thứ nhất
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| (Cũng được báo cáo 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ố thích hợp cho Tập hợp con được liên kết. Giới hạn này sẽ cân bằng giữa quyền riêng tư và sự tiện dụng cho các trường hợp sử dụng đã được xác định. Ngay từ đầu tiên, Chrome đã chia sẻ rằng Chrome chưa có số liệu chính xác cho Tập hợp con được liên kế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 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 và nhóm phụ trách đ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ề 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ỏ sót | Chrome đã nhận được ý kiến phản hồi về trường hợp sử dụng này. Nhóm phụ trách đ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 nâng cao nhận thức 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 cung cấp thông tin cho người dùng về Nhóm bên thứ nhất và đã xuất bản 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 được đầu tư vào việc tiếp tục tìm hiểu cách cung cấp thông tin cho người dùng một cách hiệu quả nhất trong những bối cảnh thích hợp. |
| Sau 3PCD | Cookie của bên thứ ba sẽ tiếp tục tồn tại trong 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ể, được xác định rõ ràng, nhưng chúng hiện yêu cầu trang web gọi chủ động thay vì có sẵn theo mặc định như 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 tập hợp sẽ không yêu cầu người dùng phê duyệt, nhưng người dùng có thể ngă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. Người dùng 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 từ giao diện người dùng Chrome). Chúng tôi dự định mở rộng dựa trên hướng dẫn hiện có cho nhà phát triển 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 phần mở rộng .json. |
Chúng tôi đã thực hiện thay đổi này để đảm bảo rằng một số gói lưu trữ web được hỗ trợ. |
| Đăng ký 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 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 dễ dàng chặn quảng cáo hơn. | Tiện ích có thể tương tác với khung 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 được bảo vệ sắp được điều hướng đến cũng sẽ hiển thị cho các tiện ích và do đó, các tiện ích có thể áp dụng mọi quy tắc so khớp URL để chặn giống như trong iframe. Việc chỉ chặn tất cả các khung được bảo vệ vô điều kiện có thể làm hỏng các trường hợp sử dụng khung được bảo vệ không phải quảng cáo. |
API Bộ nhớ dùng chung
| Chủ đề phản hồi | Tóm tắt | Phản hồi của Chrome |
|---|---|---|
| Áp dụng rộng rãi hơn | Bộ nhớ dùng chung phải là một tiêu chuẩn trong toàn ngành và có thể sử dụng 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 này, thu thập ý kiến phản hồi và thúc đẩy việc áp dụng. |
| Cổng đầu ra | 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 thêm ý kiến phản hồi về hệ sinh thái về lý do 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ư các 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 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 dựa trên 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 công bố hướng dẫn bổ sung 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, hệ thống sẽ không lưu trữ thêm dữ liệu đầu vào nào. |
| Nhiều quyền truy cập trong cùng một lượt tải trang | Điều gì sẽ xảy ra khi Bộ nhớ dùng chung được truy cập nhiều lần trong cùng một lượt 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, vì điều này có thể gây ra sự xung đột nếu có nhiều quảng cáo. Hàm thêm sẽ chỉ thêm giá trị mới vào cuối giá trị hiện có trước đó. |
| Chức năng iframe | Bộ nhớ dùng chung có hỗ trợ một số chức năng của iframe 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 ngừng hoạt động không? | Sau khi cookie của bên thứ ba không được dùng nữa, bộ nhớ cục bộ trong iframe sẽ được phân vùng theo trang web cấp cao nhất nhưng bản thân iframe sẽ không bị chặ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ạn vẫn có thể sử dụng bộ nhớ cục bộ trong iframe. |
KHỐI
| 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 cho mỗi trang web được phân vùng vẫn là đáng kể và muốn giảm xuống. | Firefox đã cho thấy một vị trí tích cực trên CHIPS. Để được hỗ trợ Webkit, các 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 đề trên GitHub về những trường hợp sử dụng mà trong đó cookie được phân vùng sẽ được ưu tiên hơn so với bộ nhớ được phân vùng. |
| Nhúng đã xác thực | KHỐI có thể ảnh hưởng đến quy trình đăng nhập SSO hiện tại do sự phân chia khác nhau ảnh hưởng đến các lượt nhúng đã xác thực. | Chúng tôi dự định tận dụng Storage Access API (với lời nhắc của người dùng) để hỗ trợ trường hợp sử dụng nội dung nhúng đã được xác thực. Gần đây, chúng tôi có gửi một ý định để tạo nguyên mẫu. |
| Chính sách vòng đời | Các chính sách có thể áp dụng cho vòng đờ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 đặt 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 | Căn chỉnh việc uỷ quyền các phạm vi Oauth không 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 Web Identity thông qua W3C FedID CG về những cách tốt nhất để hỗ trợ việc uỷ quyền ngoài quy trình xác thực cơ bản sau khi ngừng sử dụng cookie của bên thứ ba. |
| Hỗ trợ SAML | Đáp ứng các yêu cầu hỗ trợ SAML | Nhóm này đang tích cực tìm kiếm ý 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 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
API Mã thông báo trạng thái riêng tư (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 cho biết họ có thiện cảm với việc khám phá các tín hiệu hỗ trợ trình duyệt về tính toàn vẹn của thiết bị hoặc lòng tin của người dùng. Nhìn chung, họ cũng thận trọng về việc những tín hiệu mới được tạo cho mục đích riêng là đủ để 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 được khám phá những đề xuất mới trong cộng đồng chống gian lận và an toàn trên web. Chúng tôi cũng công nhận và chia sẻ mối lo ngại của họ. Đó chính là lý do khiến "chống nội dung rác và lừa đảo" trở thành 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 vệ sự an toàn trên web trong khi cải thiện quyền riêng tư của người dùng. |
| Phản hồi tích cực trên 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 web. | Chúng tôi rất vui khi được nghe sự hỗ trợ và quan tâm đến việc khám phá thêm các giải pháp mới có sử dụng PST. Chúng tôi có tài nguyên và mã mẫu trên trang web dành cho nhà phát triển Chrome và hoan nghênh thêm ý kiến phản hồi của bạn. |
| Gian lận và sử dụng sai mục đích | Hướng dẫn về Ngăn chặn / phát hiện gian lận 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 vì mục đích chống gian lận, đồng thời bổ sung 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 sử dụng sai mục đích để duy trì các chức năng thông qua những thay đổi khác liên quan đến Hộp cát về quyền riêng tư. |
| Tỷ lệ thông tin về nguồn gốc của nhà phát hành | Tỷ lệ thông tin của nhà phát hành so với nguồn gốc đủ cao để xác định từng 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 tải bằng Mã thông báo trạng thái riêng tư. Theo thiết kế, hệ thống có thể sử dụng tối đa 6 khóa công khai cùng một lúc, có thể đại diện cho "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 (trừ một số ít trường hợp cần xoay khoá khẩn cấp). Điều này làm chậm khả năng kết hợp dữ liệu bổ sung của người dùng theo thời gian. Với bất kỳ API web mới nào, đều có sự cân bằng giữa thông tin người dùng mới được cung cấp và thông tin người dùng mới mà API này 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, đồng thời tạo điều kiện cho các trường hợp sử dụng chính chống gian lận chịu ảnh hưởng của 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 rất 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. Tuy nhiên, chúng tôi cho rằng 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 xuất hiện một tiêu chuẩ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í lưu trữ | Bạn nên lưu trữ các cấu hình khoá của Mã thông báo trạng thái riêng tư ở cùng một vị trí với Giao thức PrivacyPass. | Trong quá trình thử nghiệm trong giai đoạn Dùng thử theo nguyên gốc, các nhà phát triển cho biết họ muốn lưu trữ khoá tại các URL chung một cách linh hoạt 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à các tập hợp khoá được dự định 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 được chuẩn hoá với siêu dữ liệu công khai (dưới dạng POPRF, làm mù RSA một phần hoặc bộ khoá), thì chúng tôi có thể chuyển sang phiên bản PST trong tương lai để hỗ trợ điều đó. |
| Triển khai tiêu đề của API | Các 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à hệ sinh thái sử dụng API này hoàn thiện, chúng tôi hy vọng có thể hỗ trợ cả phiên bản tiêu chuẩn không có tiêu đề của API này và có thể cuối cùng sẽ không dùng phiên bản tiêu đề nữa nếu mức sử dụng thấp hoặc có đủ công cụ/hỗ trợ dành cho nhà phát triển để liên kết yêu cầu cấp/sửa đổi với dữ liệu khác theo các cách chuẩn. Chúng tôi sẽ 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ó thiết thực không? | Chúng tôi đã cập nhật quy cách để mô tả quy trình đăng ký công ty phát hành Mã thông báo trạng thái riêng tư. Tuy sử dụng quy trình riêng, nhưng kế hoạch này cũng tương tự như 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. |