รายงานรายไตรมาสสำหรับไตรมาสที่ 1 ปี 2023 ซึ่งสรุปความคิดเห็นที่ได้รับเกี่ยวกับข้อเสนอ Privacy Sandbox และคำตอบของ Chrome ในระบบนิเวศ
Google ตกลงที่จะเผยแพร่รายงานรายไตรมาสเกี่ยวกับกระบวนการมีส่วนร่วมของผู้มีส่วนเกี่ยวข้องสำหรับข้อเสนอ Privacy Sandbox ของตนต่อสาธารณะ (ดูย่อหน้า 12 และ 17(ค)(ii) ของความมุ่งมั่น) ตามข้อตกลงกับ CMA รายงานสรุปความคิดเห็นเกี่ยวกับ Privacy Sandbox เหล่านี้สร้างขึ้นโดยการรวบรวมความคิดเห็นที่ Chrome ได้รับจากแหล่งที่มาต่างๆ ตามที่ระบุไว้ในภาพรวมความคิดเห็น ซึ่งรวมถึงแต่ไม่จำกัดเพียง GitHub Issues, แบบฟอร์มความคิดเห็นที่มีให้ใช้งานใน privacysandbox.com, การประชุมกับผู้มีส่วนเกี่ยวข้องในอุตสาหกรรม และฟอรัมมาตรฐานเว็บ Chrome ยินดีรับฟังความคิดเห็นที่ได้รับจากระบบนิเวศและกำลังสำรวจวิธีผสานรวมสิ่งที่ได้เรียนรู้เข้ากับการตัดสินใจด้านการออกแบบ
ธีมความคิดเห็นจะจัดอันดับตามความถี่ต่อ API โดยรวบรวมจำนวนความคิดเห็นที่ทีม Chrome ได้รับเกี่ยวกับธีมหนึ่งๆ แล้วจัดเรียงตามลำดับจากมากไปน้อย เราระบุธีมความคิดเห็นที่พบบ่อยโดยการตรวจสอบหัวข้อการสนทนาจากการประชุมสาธารณะ (W3C, PatCG, IETF) ความคิดเห็นโดยตรง, GitHub และคำถามที่พบบ่อยซึ่งปรากฏผ่านทีมภายในของ Google และแบบฟอร์มสาธารณะ
กล่าวโดยละเอียดคือ เราได้ตรวจสอบบันทึกการประชุมขององค์กรมาตรฐานเว็บ และพิจารณาความคิดเห็นโดยตรงจากบันทึกการประชุมแบบ 1:1 ของผู้มีส่วนเกี่ยวข้องของ Google, อีเมลที่ได้รับจากวิศวกรแต่ละคน, รายชื่ออีเมลของ API และแบบฟอร์มความคิดเห็นสาธารณะ จากนั้น Google ได้ประสานงานระหว่างทีมต่างๆ ที่เกี่ยวข้องในกิจกรรมการติดต่อเหล่านี้เพื่อระบุความแพร่หลายของธีมที่ปรากฏขึ้นซึ่งเกี่ยวข้องกับ API แต่ละรายการ
คำอธิบายการตอบสนองของ Chrome ต่อความคิดเห็นพัฒนามาจากคําถามที่พบบ่อยที่เผยแพร่ การตอบกลับจริงสำหรับปัญหาที่ระบุโดยผู้มีส่วนเกี่ยวข้อง และการกำหนดจุดยืนเพื่อวัตถุประสงค์ในการรายงานต่อสาธารณะโดยเฉพาะ เราได้รับคําถามและความคิดเห็นเกี่ยวกับ Topics, FLEDGE และ Attribution Reporting API โดยเฉพาะ ซึ่งสอดคล้องกับจุดเน้นในการพัฒนาและการทดสอบในปัจจุบัน
ความคิดเห็นที่ได้รับหลังจากสิ้นสุดระยะเวลาการรายงานปัจจุบันอาจยังไม่มีคําตอบจาก Chrome
อภิธานศัพท์เกี่ยวกับตัวย่อ
- CHIPS
- คุกกี้ที่มีสถานะการแบ่งพาร์ติชันอิสระ
- DSP
- แพลตฟอร์มฝั่งดีมานด์
- FedCM
- การจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์
- FPS
- ชุดโดเมนของบุคคลที่หนึ่ง
- IAB
- Interactive Advertising Bureau
- IDP
- ผู้ให้บริการข้อมูลประจำตัว
- IETF
- คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต
- IP
- ที่อยู่ Internet Protocol
- openRTB
- การเสนอราคาแบบเรียลไทม์
- OT
- ช่วงทดลองใช้จากต้นทาง
- PatCG
- กลุ่มชุมชนเทคโนโลยีโฆษณาส่วนตัว
- RP
- ผู้เชื่อถือ
- SSP
- แพลตฟอร์มฝั่งขาย
- TEE
- สภาพแวดล้อมการดำเนินการที่เชื่อถือได้
- UA
- สตริง User Agent
- UA-CH
- คำแนะนำสำหรับไคลเอ็นต์ User Agent
- W3C
- World Wide Web Consortium
- WIPB
- การจงใจปิดบัง IP
ความคิดเห็นทั่วไป ไม่มี API/เทคโนโลยีที่เฉพาะเจาะจง
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การทดสอบและการทดลองใช้ | ความเกี่ยวข้องของการทดสอบเพื่อแจ้งการประเมินของ CMA หาก Privacy Sandbox API ยังไม่เสร็จสมบูรณ์เมื่อการทดสอบเริ่มขึ้น | การพัฒนา Privacy Sandbox API กำลังดำเนินไปอย่างรวดเร็ว
ฟีเจอร์เหล่านี้พร้อมให้ทดสอบใน Origin Trial แล้ว และจะพร้อมให้บริการแก่การเข้าชมทั้ง 100% ในช่วงฤดูร้อนนี้ นอกจากนี้ เรายังได้ชี้แจงลำดับเวลาของฟีเจอร์บางอย่าง (เช่น การรายงานระดับเหตุการณ์ของ FLEDGE, การแสดงผล FLEDGE ด้วย iframe) ที่จะยังไม่ได้รับผลกระทบก่อนปี 2026 เราขอแนะนําให้ระบบนิเวศทดสอบ API และแสดงความคิดเห็นต่อ CMA โดยอิงตามสิ่งที่ผู้ทดสอบคาดหวังที่จะใช้เมื่อเลิกใช้งานคุกกี้ของบุคคลที่สาม ซึ่งจะช่วยในการประเมินผลกระทบที่อาจเกิดขึ้นจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
| การควบคุมของผู้ใช้ | แนวทางที่ชัดเจนสำหรับระบบนิเวศเกี่ยวกับผลกระทบของการควบคุมของผู้ใช้ที่มีต่อ Privacy Sandbox API | เราไม่สามารถให้คำแนะนำทางกฎหมายเกี่ยวกับสิ่งที่ระบบนิเวศสามารถใช้จากการควบคุมของผู้ใช้ ในขณะเดียวกัน Chrome กำลังทดสอบการแสดงการควบคุมของผู้ใช้ Privacy Sandbox เวอร์ชันอัปเดต ("ความเป็นส่วนตัวของโฆษณาที่ปรับปรุงแล้ว") แก่ผู้ใช้เพียงไม่กี่เปอร์เซ็นต์ เพื่อเป็นการปรับปรุงเทคโนโลยี Privacy Sandbox อย่างต่อเนื่อง การอัปเดตนี้รวมถึงภาษาและเลย์เอาต์ที่ชัดเจนและเป็นประโยชน์มากขึ้น เมื่อ Chrome ประเมินการปรับแต่งเหล่านี้และตัดสินใจว่าจะขยายการให้บริการไปยังผู้ใช้จํานวนมากขึ้นหรือไม่ ก็จะแชร์ข้อมูลเพิ่มเติมกับระบบนิเวศได้ |
| ข้อมูลรั่วไหล | ความเสี่ยงที่ข้อมูลของบุคคลที่หนึ่งจะรั่วไหลไปยัง Google และบุคคลอื่นๆ ในกรณีที่เบราว์เซอร์ถูกบุกรุก | คำอธิบาย FLEDGE ของเราแสดงให้เห็นอย่างชัดเจนว่าข้อมูลของเทคโนโลยีโฆษณาหนึ่งๆ จะแชร์กับเทคโนโลยีโฆษณาเดียวกันเท่านั้น (กับเวิร์กเลตหรือเซิร์ฟเวอร์ที่เชื่อถือได้) หรือเมื่อเทคโนโลยีโฆษณาดังกล่าวแชร์ข้อมูลอย่างชัดเจน (เช่น ผู้ซื้อแสดง URL โฆษณาที่ต้องการแสดงให้ผู้ขายเห็น) ข้อยกเว้นเพียงอย่างเดียวคือการตรวจสอบการไม่ระบุตัวตนระดับ k ต้องทำโดยเซิร์ฟเวอร์ส่วนกลางทั่วโลก ซึ่งเป็นด้านที่เรายังคงทุ่มเททรัพยากรจำนวนมากอย่างต่อเนื่อง โปรดดูคำอธิบายความเป็นส่วนตัวแบบ K-anonymity เพื่อดูมุมมองโดยละเอียดเกี่ยวกับแนวคิดด้านความเป็นส่วนตัวของเรา นอกจากนี้ เรายังยินดีให้รายละเอียดเพิ่มเติมเกี่ยวกับวิธีการทำงานของการป้องกันเทคโนโลยีโฆษณาที่ใช้ในการออกแบบเซิร์ฟเวอร์แบบ k-anonymity |
| ฟอรัมเพิ่มเติมสำหรับการสนทนา | ขอฟอรัมเพิ่มเติมจาก W3C สําหรับผู้เล่นในระบบนิเวศที่ไม่ใช่ด้านเทคนิคเพื่อแชร์ความคิดเห็น | แบบฟอร์มความคิดเห็นเกี่ยวกับความเป็นส่วนตัวในซานด์บ็อกซ์เหมาะสำหรับความคิดเห็นทั่วไปและเฉพาะเจาะจง ทั้งทางเทคนิคและไม่ใช่ทางเทคนิค กลุ่มธุรกิจการโฆษณาบนเว็บที่ดีขึ้นเป็นฟอรัมสำหรับการพูดคุยผ่านการประชุมทางโทรศัพท์รายสัปดาห์และที่เก็บข้อมูล GitHub หน้าความคิดเห็นของ Privacy Sandbox จะอธิบายกลไกอื่นๆ ในการเสนอความคิดเห็นและการมีส่วนร่วมในการสนทนา นอกจากนี้ Chrome ยังจัดกิจกรรมต่างๆ อย่างต่อเนื่อง เช่น ช่วงเวลาที่เปิดให้สอบถามแบบสาธารณะ เพื่ออำนวยความสะดวกในการตอบคำถามและการแชร์เนื้อหา นอกจากนี้ Chrome ยังเป็นเจ้าภาพหรือเข้าร่วมกิจกรรมในอุตสาหกรรมมากกว่า 12 รายการในไตรมาสที่ผ่านมา |
| การชี้แจงเกี่ยวกับไทม์ไลน์ | คำชี้แจงเกี่ยวกับวันที่ที่แน่นอนของความพร้อมให้บริการแบบทั่วไปในไตรมาสที่ 3 ปี 2023 | ตามลำดับเวลาที่เผยแพร่ใน PrivacySandbox.com เป้าหมายคือจะเริ่มเปิดตัวความพร้อมให้บริการทั่วไปพร้อมกับการเผยแพร่ Chrome เวอร์ชัน 115 |
| reCAPTCHA | ผลกระทบของ Sandbox API สําหรับกรณีการใช้งานการตรวจจับสแปมของ reCAPTCHA | เราได้รับความคิดเห็นจาก reCAPTCHA เป็นระยะๆ เพื่อให้แน่ใจว่าข้อเสนอ Privacy Sandbox จะไม่ส่งผลกระทบต่อความปลอดภัยของเว็บหรือการประพฤติมิชอบอย่างมีนัยสำคัญ ทางบริษัทกำลังพัฒนาแผนของตนเองเพื่อเตรียมพร้อมและปรับตัวสำหรับการเลิกใช้งานคุกกี้ของบุคคลที่สาม ดังนั้นคำถามนี้จึงควรสอบถามกับทางบริษัท |
| ส่วนขยาย Chrome | เทคโนโลยี Privacy Sandbox เช่น มาตรการป้องกันการติดตามแอบแฝง (ACT) จะมีผลกับส่วนขยาย Chrome ไหม | เราไม่ได้มีการประกาศว่า ACT อาจมีผลบังคับใช้กับส่วนขยายของ Chrome หรือไม่ อย่างไรก็ตาม หากเทคโนโลยีรวบรวมข้อมูลของผู้ใช้อย่างลับๆ การดำเนินการดังกล่าวจะไม่สอดคล้องกับหลักการด้านความเป็นส่วนตัวของเรา |
แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง
หัวข้อ
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การตรวจสอบการออกแบบ TAG | TAG เผยแพร่การตรวจสอบการออกแบบขั้นต้นของ Topics | เรายังคงมุ่งมั่นที่จะพัฒนา Topics และได้แชร์ข้อมูลอัปเดตเกี่ยวกับความมุ่งมั่นของเราในหน้าข้อมูลอัปเดตล่าสุด และในฉบับนี้ เราได้ตอบกลับการตรวจสอบของ TAG โดยละเอียดแล้ว และแชร์วิสัยทัศน์ระดับสูงขึ้นที่นี่ Topics API จะยังคงเป็นส่วนหนึ่งของคอลเล็กชัน API ที่ระบบนิเวศโฆษณาควรทดสอบในช่วงปี 2023 และเราหวังว่าความคิดเห็นเกี่ยวกับการทดสอบที่ได้รับและประสบการณ์ของผู้ติดตั้งใช้งานจะเป็นส่วนสําคัญในการทํางานตามมาตรฐานข้ามเบราว์เซอร์ในอนาคต เราหวังว่าจะยังคงมีส่วนร่วมกับระบบนิเวศต่อไปเกี่ยวกับวิธีลดความซับซ้อนของการเปลี่ยนผ่านที่เป็นไปได้ ซึ่ง Topics API อาจกลายเป็นมาตรฐานที่ยอมรับร่วมกันและใช้งานร่วมกันได้ข้ามเบราว์เซอร์ |
| แนวทางการใช้หัวข้อ | การรองรับแนวทางแบบเปิดที่ Chrome มีต่อการพัฒนา Topics API | ขอขอบคุณสำหรับความคิดเห็นและเราหวังว่าจะได้ทำงานร่วมกับกลุ่มอุตสาหกรรมต่อไปเพื่อพัฒนา Topics API ที่เป็นประโยชน์ต่อระบบนิเวศโดยรวม |
| (รายงานในไตรมาสที่ 3 ปี 2022 ด้วย) การจัดหมวดหมู่หัวข้อไม่ละเอียดมากพอ |
การจัดหมวดหมู่หัวข้อแบบกว้างจะไม่รวมหัวข้อที่ละเอียดยิ่งขึ้น รวมถึงหัวข้อเฉพาะภูมิภาค | ข้อมูลอัปเดตประจำไตรมาสที่ 1: เรากําลังปรับปรุงการจัดหมวดหมู่อย่างต่อเนื่อง และเราจะประกาศการจัดหมวดหมู่ที่อัปเดตแล้วสําหรับ Topics API ในไตรมาสที่ 2 เราได้ทำงานร่วมกับบริษัทต่างๆ จากทั่วทั้งระบบนิเวศอย่างใกล้ชิดเพื่อสร้างการจัดหมวดหมู่ใหม่นี้ เรากําลังมองหาความคิดเห็นเกี่ยวกับการจัดหมวดหมู่ที่เป็นประโยชน์ต่อระบบนิเวศมากที่สุด ในการตัดสินว่าจะเพิ่มจำนวนหัวข้อหรือรวมหัวข้อที่ละเอียดยิ่งขึ้น คุณต้องพิจารณาถึง 1) ผลกระทบด้านความเป็นส่วนตัวที่อาจเกิดขึ้น (หัวข้อที่มากขึ้นอาจทำให้เกิดความเสี่ยงในการเก็บข้อมูลลายนิ้วมือ) และ 2) ความสามารถในการดึงหัวข้อที่สังเกตก่อนหน้านี้ (เช่น เมื่อมีหัวข้อมากขึ้น โอกาสที่เทคโนโลยีโฆษณาจะเห็นหัวข้อที่เลือกก่อนหน้านี้อาจลดลง) |
| (รายงานในไตรมาสที่ 4 ปี 2022 ด้วย) ผลกระทบต่อสัญญาณของบุคคลที่หนึ่ง |
สัญญาณหัวข้ออาจมีคุณค่าสูง ซึ่งจะทําให้สัญญาณอื่นๆ ที่อิงตามความสนใจของบุคคลที่หนึ่งมีคุณค่าน้อยลง | เราเชื่อว่าการโฆษณาตามความสนใจเป็นกรณีการใช้งานที่สําคัญสําหรับเว็บ และ Topics ได้รับการออกแบบมาเพื่อรองรับกรณีการใช้งานดังกล่าว เราเข้าใจว่าผู้เผยแพร่โฆษณารายใหญ่บางรายกังวลว่า Topics จะส่งผลเสียต่อกลยุทธ์ข้อมูลจากบุคคลที่หนึ่ง เราหวังว่าการทดสอบระบบนิเวศนี้จะให้ข้อมูลเชิงลึกเกี่ยวกับผลกระทบที่ Topics มีต่อผู้เผยแพร่โฆษณา |
| กรณีการใช้งาน Topics ที่ไม่เกี่ยวข้องกับโฆษณา | การใช้ Topics เพื่อวัตถุประสงค์อื่นนอกเหนือจากการแสดงโฆษณาตามความสนใจ | Topics ออกแบบมาเพื่อจัดการกับ Use Case การโฆษณาตามความสนใจ ซึ่งเราเชื่อว่าเป็น Use Case ที่สําคัญสําหรับเว็บที่เสรีและเปิด ขณะนี้เรากําลังมองหาความคิดเห็นเกี่ยวกับ Use Case อื่นๆ และประเมินอยู่ |
| สถานะการเลือกใช้เริ่มต้น | ผลกระทบของกฎหมายระดับภูมิภาคที่มีต่อค่าเริ่มต้นความยินยอมของ Topics | เราไม่ได้มีหน้าที่ให้ความเห็นเกี่ยวกับความคิดเห็นทางกฎหมาย |
| (รายงานในไตรมาสที่ 3 ปี 2022 ด้วย) เว็บไซต์ที่จัดหมวดหมู่ไม่ถูกต้อง |
การกําหนดเป้าหมายโฆษณาเมื่อหัวข้อได้รับการจัดหมวดหมู่ไม่ถูกต้องสําหรับเว็บไซต์หนึ่งๆ | ข้อมูลอัปเดตสำหรับไตรมาสที่ 1: ในไตรมาสที่ 2 เราจะประกาศตัวแยกประเภทที่อัปเดตแล้วสำหรับ Topics API และหวังว่าจะได้มีส่วนร่วมกับระบบนิเวศนี้ เราจัดประเภทเว็บไซต์โดยรวมจากรายการการลบล้างที่ดูแลจัดการโดยเจ้าหน้าที่ซึ่งมีเว็บไซต์ยอดนิยมและโมเดล ML ในอุปกรณ์ เพื่อตอบสนองต่อความคิดเห็นปัจจุบัน Chrome จะประเมินตัวเลือกสำหรับเว็บไซต์ที่จะมีส่วนร่วมในการจัดประเภท Topics ต่อไป การปรับปรุงยูทิลิตีต้องพิจารณาจากความเสี่ยงด้านความเป็นส่วนตัวและการละเมิด ตัวอย่างเช่น ความเสี่ยงบางส่วน ได้แก่ เว็บไซต์ที่ใช้การติดป้ายกำกับด้วยตนเองเป็นวิธีการเข้ารหัสความหมายที่แตกต่างกัน (และอาจเป็นเรื่องละเอียดอ่อน) ลงในหัวข้อ เว็บไซต์ที่สื่อให้เข้าใจผิดเกี่ยวกับหัวข้อของตนเพื่อผลประโยชน์ทางการเงิน เว็บไซต์ที่โจมตีหัวข้อเพื่อลดความมีประโยชน์ของหัวข้อสำหรับผู้อื่น (เช่น การส่งสแปมหัวข้อของผู้ใช้ด้วยเนื้อหาที่ไม่มีความหมาย) บุคคลทั่วไปสามารถตรวจสอบคอมโพเนนต์เหล่านี้ได้โดยใช้เครื่องมือที่มีให้ผ่าน chrome://topics-internals หรือ colab นี้ เราคาดว่าการจัดประเภทจะดีขึ้นเมื่อเวลาผ่านไปผ่านการทดสอบ และเรายินดีรับฟังความคิดเห็นเกี่ยวกับตัวอย่างเว็บไซต์ที่อาจจัดหมวดหมู่ไม่ถูกต้อง |
| ตัวแยกประเภทหัวข้อ | คำขอแสดงข้อมูลเพิ่มเติมที่แสดงเหตุผลเมื่อระบบแสดง "ไม่มีหัวข้อ" แก่ผู้เรียกใช้เพื่อวัตถุประสงค์ในการแก้ไขข้อบกพร่อง | เราเข้าใจและขอขอบคุณที่เครื่องมือแก้ไขข้อบกพร่องมีประโยชน์ต่อนักพัฒนาแอปขณะที่พยายามผสานรวม Topics API เข้ากับระบบ อย่างไรก็ตาม การเปิดเผยข้อมูลเพิ่มเติม (เช่น สาเหตุที่ระบบไม่แสดง Topics) อาจทำให้เราแชร์ข้อมูลโดยไม่ตั้งใจ ซึ่งทำให้บุคคลที่สามสามารถค้นพบรายละเอียดเพิ่มเติม (เช่น ผู้ใช้อยู่ในโหมดไม่ระบุตัวตน ปิดใช้ API และอื่นๆ) นอกเหนือจากที่ตั้งใจไว้ ซึ่งจะส่งผลเสียต่อความเป็นส่วนตัวของผู้ใช้ แม้ว่าเราจะไม่มีแผนที่จะจัดหาเครื่องมือแก้ไขข้อบกพร่องเพิ่มเติมในขณะนี้ แต่เราก็ยินดีรับฟังความคิดเห็นเกี่ยวกับเครื่องมือที่มีประโยชน์ |
| การดึงข้อมูลส่วนตัว (PIR) | คำขอให้ Topics API ใช้การดึงข้อมูลส่วนตัว | ก่อนหน้านี้เราได้ตรวจสอบการใช้ PIR และแชร์ข้อดีข้อเสียที่นี่ |
| สตรีมราคาเสนอ | ระบบจะแสดงหัวข้อแยกจากกลุ่มเป้าหมายที่กําหนดโดยผู้ขายในกระแสราคาเสนอไหม | Topics API เป็นข้อเสนอ Privacy Sandbox ที่พัฒนาโดย Chrome ซึ่งแตกต่างจากข้อเสนอ กลุ่มเป้าหมายที่กําหนดโดยผู้ขายของ IAB Tech Lab เราคาดว่าทั้ง 2 รายการจะแสดงอย่างชัดเจนภายในบิดสตรีม ดูวิธีที่ระบบจะแสดงหัวข้อในคำขอราคาเสนอ OpenRTB |
Protected Audience API (เดิมเรียกว่า FLEDGE)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ความพร้อมใช้งานของฟีเจอร์ FLEDGE | คำชี้แจงเกี่ยวกับลำดับเวลาในการทดสอบและการใช้งานฟีเจอร์ FLEDGE เช่น การบังคับใช้เฟรมที่มีรั้วล้อม การปกปิดข้อมูลบางส่วน และอื่นๆ | เราได้แชร์สถานะเกี่ยวกับฟีเจอร์ FLEDGE แบบกำหนดขอบเขตต่างๆ และเวลาที่ระบบจะรองรับ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับการประกาศนี้ขณะที่เราพัฒนา FLEDGE อย่างต่อเนื่อง |
| ข้อจำกัดการแสดงผลผลิตภัณฑ์ | คำขอให้ผ่อนคลายข้อจำกัดของโฆษณาที่ประกอบด้วยหลายส่วนสำหรับเฟรมที่มีรั้วของ FLEDGE | ตามที่ได้ประกาศไปเมื่อเดือนกุมภาพันธ์ การใช้เฟรมที่มีรั้วจะยังคงเป็นตัวเลือกอย่างน้อยจนถึงปี 2026 และ urn-iframes จะรองรับลักษณะการทํางานของ iframe เรายินดีให้พูดคุยเพิ่มเติมเกี่ยวกับหัวข้อนี้ |
| ปัญหาความสามารถในการปรับขนาด | ประสิทธิภาพของ FLEDGE เมื่อการใช้งานเพิ่มขึ้น | เรากำลังติดตามผลความคิดเห็นและพยายามทำความเข้าใจบริบทเพิ่มเติมเพื่อให้สามารถเสนอโซลูชันที่นำไปใช้ได้จริง ขั้นตอนแรกคือการแยกความคิดเห็นออกเป็น 2 หมวดหมู่ ดังนี้
|
| (รายงานในไตรมาสที่ 3 ปี 2022 ด้วย) การแสดงตรรกะการเสนอราคา |
ข้อกังวลว่าตรรกะการเสนอราคา DSP จะแสดงใน JavaScript | ข้อมูลอัปเดตประจำไตรมาสที่ 1: เราได้แชร์ข้อเสนอที่จะจำกัดความสามารถของผู้ไม่ประสงค์ดีในการขอข้อมูลจากเซิร์ฟเวอร์ในลักษณะการสํารวจ (การบังคับเรียกดู) และเรายินดีให้ผู้เล่นในระบบนิเวศแชร์ความคิดเห็นหรือสนับสนุนข้อเสนอนี้ |
| ความยากในการทดสอบ | ความสามารถของ DSP ขนาดเล็กในการทดสอบ FLEDGE อย่างเหมาะสม และลดความเสี่ยงที่ผู้ลงโฆษณาจะสนใจทดสอบกับ DSP ขนาดใหญ่เท่านั้น | เรามุ่งมั่นที่จะทํางานร่วมกับ DSP ขนาดเล็ก และขอแนะนําอย่างยิ่งให้ DSP และผู้ลงโฆษณาทุกขนาดขยายการทดสอบเมื่อ FLEDGE เปิดตัวสู่เวอร์ชันที่พร้อมให้บริการแก่ผู้ใช้ทั่วไป เราอยากทราบวิธีที่ดีที่สุดที่จะช่วยนักพัฒนาแอปทดสอบ FLEDGE กับผู้อื่นในระบบนิเวศ และยินดีรับฟังแนวคิดและความพยายามของอุตสาหกรรมในการกระตุ้นให้นักโฆษณาทดสอบกับ DSP ขนาดเล็ก |
| รีมาร์เก็ตติ้งแบบไดนามิก | รีมาร์เก็ตติ้งแบบไดนามิกจะยังทํางานกับ FLEDGE ได้ไหมหลังจากเลิกใช้งานคุกกี้ของบุคคลที่สาม | เรากําลังพิจารณาคําตอบสําหรับคําถามนี้และยินดีให้ผู้เล่นในระบบนิเวศแชร์ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับวิธีที่ตนตั้งใจจะใช้รีมาร์เก็ตติ้งแบบไดนามิก |
| การประพฤติมิชอบ/การละเมิด | ระบบนิเวศจะลดความเสี่ยงและหยุดผู้ไม่ประสงค์ดีหรือผู้ซื้อไม่ให้วางตัวเป็นกลุ่มเป้าหมายที่ต้องการได้อย่างไร | เราหวังว่าจะได้มีส่วนร่วมกับผู้เล่นในระบบนิเวศเพิ่มเติมเกี่ยวกับกลโกงและการละเมิด และยินดีรับฟังความคิดเห็นเพิ่มเติมในเรื่องนี้ |
| ค่ากำหนดของผู้ใช้ | กระบวนการบันทึกค่ากําหนดของผู้ใช้และใช้ในการเลือกโฆษณา | สําหรับโฆษณาที่เฉพาะเจาะจง เทคโนโลยีโฆษณาที่เกี่ยวข้องคือฝ่ายที่มีศักยภาพมากที่สุดในการเสนอการควบคุมครีเอทีฟโฆษณาที่จะแสดงหรือวิธีเลือกครีเอทีฟโฆษณา |
| ข้อเสนอการทดสอบเชิงปริมาณ | ในการทดสอบเชิงปริมาณที่ยุติธรรม การทดสอบควรทำกับการเข้าชมที่ไม่มีคุกกี้ของบุคคลที่สามหรือกับ SSP ที่ใช้ FLEDGE เท่านั้น หลีกเลี่ยงการผสมสัญญาณจากคุกกี้ของบุคคลที่สามได้อย่างไร | ขอขอบคุณสำหรับความคิดเห็นนี้ และเรากำลังทำงานร่วมกับ CMA เพื่อออกแบบการทดสอบที่จะให้ภาพรวมที่เชื่อถือได้เกี่ยวกับผลกระทบของการเลิกใช้งานคุกกี้ของบุคคลที่สามและการนำข้อเสนอ Privacy Sandbox มาใช้ในระบบนิเวศ เราขอแนะนำให้แชร์ความคิดเห็นเพิ่มเติมเกี่ยวกับข้อเสนอการทดสอบเชิงปริมาณของ CMA กับ CMA โดยตรง |
| เอกสารประกอบที่ชัดเจนยิ่งขึ้น | ขอเอกสารประกอบที่ชัดเจนยิ่งขึ้นเกี่ยวกับการกําหนดค่าการประมูล | เราหวังว่าจะแชร์บล็อกโพสต์ที่มีภาพรวมเพิ่มเติมเกี่ยวกับการรายงานการประมูลของ FLEDGE ในอีกไม่กี่สัปดาห์ข้างหน้า |
| การโหลดพร้อมกัน | บริการเสนอราคาและประมูล (B&A) จะรองรับการทํางานแบบขนานไหม | เทคโนโลยีโฆษณาที่ใช้เซิร์ฟเวอร์การเสนอราคา / การประมูลสามารถเริ่มเซิร์ฟเวอร์หลายเครื่องได้ ซึ่งจะแสดงผลลัพธ์ได้พร้อมกัน |
| การลดการละเมิด | เซิร์ฟเวอร์การปกปิดข้อมูลบางส่วนแบบ k ของ FLEDGE ที่ใช้โทเค็นสถานะส่วนตัวเพียงพอที่จะรักษาความเป็นส่วนตัวของผู้ใช้หรือไม่ | แรงจูงใจสําหรับการลบข้อมูลระบุตัวบุคคลตามระดับ k ไม่ได้มุ่งเน้นที่การกําหนดเป้าหมายแบบไมโครมากนัก แต่มุ่งเน้นที่การรองรับในช่วงระยะกลางที่ FLEDGE อนุญาตให้มีการรายงานระดับเหตุการณ์ เราได้แชร์ความคิดเห็นเพิ่มเติมและยินดีรับฟังความคิดเห็นเพิ่มเติม |
| โมดูล ES ขัดแย้งกัน | คำขอยกเลิกการใช้ generateBid เป็นฟังก์ชันส่วนกลางเนื่องจากขัดแย้งกับข้อบังคับของ ES |
เรากำลังพูดคุยเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| การประมูลคอมโพเนนต์ | คำขอให้ผู้เผยแพร่โฆษณาควบคุมการออกแบบการประมูลได้มากขึ้น | การเสนอราคาและแผนการประมูลเพื่อรองรับการประมูลคอมโพเนนต์เช่นเดียวกับ Chrome ในอุปกรณ์ |
| ไทม์ไลน์ของ B&A | ความชัดเจนเกี่ยวกับลำดับเวลาสําหรับเทคโนโลยีโฆษณาที่สนใจทดสอบเซิร์ฟเวอร์ B&A | เราเพิ่งอัปเดตคำอธิบาย B&A และอัปเดตส่วนลำดับเวลาเพื่อระบุคำจำกัดความที่ชัดเจนของลำดับเวลาสำหรับระยะต่างๆ ของการทดสอบ B&A ของ Chrome หลังจากที่ปรับให้สอดคล้องกับ CMA แล้ว |
| รูปแบบการควบคุมระยะหมดเวลา | การปรับปรุงรูปแบบการควบคุมการหมดเวลาที่มีให้ใช้งานใน FLEDGE ในปัจจุบัน | นี่เป็นข้อเสนอที่น่าสนใจ เราจะเพิ่มเรื่องนี้ลงในคิวของข้อเสนอที่จะศึกษาและรายงานความคืบหน้า |
| สตรีมราคาเสนอของครีเอทีฟโฆษณา | ความสามารถในการตรวจสอบและกรองราคาเสนอที่ชนะตามครีเอทีฟโฆษณา | นี่เป็นข้อเสนอที่น่าสนใจ เราจะเพิ่มเรื่องนี้ลงในคิวของข้อเสนอที่จะศึกษาและรายงานความคืบหน้า |
reportWin |
ข้อเสนอในการให้ข้อมูลเพิ่มเติมเกี่ยวกับราคาเสนอที่ได้รับคะแนนสูงสุดจากเจ้าของกลุ่มความสนใจรายอื่นที่ไม่ใช่ผู้ชนะในฟังก์ชันreportWin |
นี่เป็นข้อเสนอที่น่าสนใจ เราจะพิจารณาเพิ่มสัญญาณเพิ่มเติมในการรายงานแบบรวม และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่ |
| ประเภทกิจกรรม | การกำหนดมาตรฐานประเภทเหตุการณ์ใน Measurement API เมื่อผสานรวมกับ FLEDGE | นี่เป็นข้อเสนอที่น่าสนใจ เราจะเพิ่มเรื่องนี้ลงในคิวของข้อเสนอที่จะศึกษาและรายงานความคืบหน้า ซึ่งจะต้องมีการประสานงานกับโครงการอื่นๆ ของเราในสาขานี้ เนื่องจากจะส่งผลต่อ Privacy Sandbox API อื่นๆ นอกเหนือจาก FLEDGE เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่ |
| โซลูชันระยะยาวสําหรับการรายงานระดับเหตุการณ์ | ความต้องการเก็บข้อมูลบางอย่าง เช่น highestScoringOtherBidไว้ให้พร้อมใช้งานแม้ว่าจะเลิกใช้งานคุกกี้ของบุคคลที่สามแล้วก็ตาม |
ตามที่ได้แจ้งไว้ในบล็อกโพสต์เดือนกุมภาพันธ์ เราจะรองรับการรายงานการชนะการประมูลระดับเหตุการณ์จนถึง "อย่างน้อยปี 2026" ขณะนี้เรายังไม่มีรายละเอียดเพิ่มเติมที่จะแชร์ แต่ยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่การเก็บข้อมูลบางอย่างไว้หลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามเป็นเรื่องสำคัญ |
| ขีดจํากัดของกลุ่มความสนใจ | แหล่งที่มาสามารถเพิ่มกลุ่มความสนใจไปยังเบราว์เซอร์เดียวได้สูงสุดกี่กลุ่ม | Chrome อนุญาตให้มีกลุ่มความสนใจได้สูงสุด 1,000 กลุ่มต่อเจ้าของ และเจ้าของกลุ่มความสนใจได้สูงสุด 1,000 คน ข้อมูลเหล่านี้มีไว้เพื่อเป็นขอบเขต ไม่ใช่เพื่อใช้ในการทำงานตามปกติ |
| สัญญาณระดับเหตุการณ์ | รองรับคําเสนอให้มีสัญญาณระดับเหตุการณ์สําหรับ generateBid
และ reportWin ซึ่งอาจนําไปใช้ในการฝึกแมชชีนเลิร์นนิงได้ |
เราได้แชร์ผลการตัดสินสำหรับสัญญาณที่ออกแบบโดยเบราว์เซอร์และสัญญาณที่เทคโนโลยีโฆษณากำหนดไว้ที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| สคริปต์การเสนอราคา | รวมรหัสผู้ใช้ใน URL ไปยังสคริปต์การเสนอราคา | การดำเนินการนี้จะไม่สามารถทำได้เนื่องจาก FLEDGE มีข้อกำหนดเพิ่มเติมว่าทูเปิลของเจ้าของกลุ่มความสนใจ, URL สคริปต์การเสนอราคา และครีเอทีฟโฆษณาที่แสดงผลต้องเป็นแบบไม่ระบุตัวตนระดับ k เพื่อให้โฆษณาแสดง |
| การบังคับใช้ K-anon | มีการใช้ k-anonymity กับคู่ (componentAd, size) หรือไม่ | ใช่ โปรดดู turtledove/issues/312 |
| ข้อกําหนดของบริการเสนอราคาและประมูล | บริการ B&A รองรับผู้เข้าร่วมที่ผสานรวมกับ FLEDGE ในอุปกรณ์และผู้อื่นที่มีบริการ B&A อย่างไร | เรายังอยู่ระหว่างการสรุปการออกแบบและยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่ |
| การระบุแหล่งที่มาหลังดูโฆษณา | ระบบจะรองรับการระบุแหล่งที่มาหลังการดูไหม | ปัจจุบันเราไม่มีคำจำกัดความมาตรฐานใดๆ เกี่ยวกับความสามารถในการแสดงตัวโฆษณาและอาศัยครีเอทีฟโฆษณาเองในการทําเครื่องหมายเหตุการณ์การดู โปรดดู turtledove/issues/452 |
| การกำหนดเป้าหมายตามกลุ่มเป้าหมายที่คล้ายกัน | Privacy Sandbox รองรับ "การกำหนดเป้าหมายตามกลุ่มเป้าหมายที่คล้ายกัน" ไหม | เรากำลังพูดคุยเกี่ยวกับUse Case ที่นี่และยินดีรับความคิดเห็นเพิ่มเติม |
| Real-time monitoring API | ข้อเสนอแนวทางการตรวจสอบ FLEDGE แบบเรียลไทม์ | เรากำลังหารือเกี่ยวกับข้อเสนอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่ |
| การรายงาน FLEDGE | reportWin และ reportResult ควรสร้างแบบสุ่มเพื่อป้องกันการรายงานมากหรือน้อยเกินไป |
ผู้ขายต้องเรียกใช้ reportResult() ก่อนจากนั้นจึงเรียกใช้ reportWin() โดยผู้ซื้อเพื่อให้ระบบรวมสัญญาณของผู้ขายจาก reportResult() ไว้ใน reportWin() ได้ ดูข้อมูลเพิ่มเติมได้ที่คำอธิบาย |
| เซิร์ฟเวอร์คีย์-ค่า (K/V) ที่กําหนดเอง | ในอนาคตระบบจะรองรับเซิร์ฟเวอร์ K/V ที่กําหนดเองไหม | เรากำลังพูดคุยเกี่ยวกับคำถามนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| การประมูลระดับบนสุด | ฉันต้องเป็นเซิร์ฟเวอร์โฆษณาจึงจะใช้กลไกการประมูลระดับบนสุดได้ไหม | FLEDGE API ไม่ได้ระบุว่าใครต้องเรียกใช้ API นี้ ไม่มีข้อกำหนดในการออกแบบ FLEDGE ในเรื่องดังกล่าว ทุกคนสามารถเรียกใช้การประมูล FLEDGE (รวมถึงการประมูลของผู้ขายหลายราย) ตามที่ระบุไว้ในรายงานไตรมาสที่ 4 ปี 2022 FLEDGE ช่วยให้ผู้เผยแพร่โฆษณาแต่ละรายเลือกโครงสร้างของการประมูลได้ รวมถึงเลือกผู้ขายระดับบนสุดและผู้ขายคอมโพเนนต์ |
| ขอบเขต API | FLEDGE มีจุดประสงค์ที่จะทํางานกับข้อมูลจากบุคคลที่หนึ่งหรือไม่ | เราจะเผยแพร่เนื้อหาในไตรมาสที่ 2 ปี 2023 เพื่อชี้แจงว่าข้อมูลจากบุคคลที่หนึ่งสามารถใช้กับ FLEDGE ได้จริง ทั้ง 1) เพื่อใช้เป็นตรรกะในการระบุการเป็นสมาชิกกลุ่มความสนใจ และ 2) เพื่อส่งเป็นสัญญาณการเสนอราคาของผู้ใช้เพื่อใช้ในการสร้างตรรกะการเสนอราคาในภายหลัง |
| กลุ่มความสนใจข้ามโดเมน | ความสามารถในการสร้างกลุ่มความสนใจข้ามโดเมน | ระบบจะใช้ข้อมูลที่มีอยู่ ณ เวลาที่เพิ่มเบราว์เซอร์ลงในกลุ่มความสนใจเพื่อแจ้งกลุ่มเป้าหมายนั้น เมื่อเลิกใช้งานคุกกี้ของบุคคลที่สาม ความพร้อมใช้งานของข้อมูลข้ามเว็บไซต์ที่จะใช้เป็นข้อมูลในการสร้างกลุ่มความสนใจจะจํากัด |
| ตรรกะการเสนอราคาฝั่งไคลเอ็นต์ | การย้ายข้อมูลตรรกะการเสนอราคาฝั่งเซิร์ฟเวอร์ที่มีอยู่ไปยังฝั่งไคลเอ็นต์ | เราต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับส่วนที่ท้าทายหรือยังขาดอยู่ในปัจจุบันในกระบวนการย้ายข้อมูล และยินดีรับฟังความคิดเห็นหรือข้อมูลเชิงลึกเพิ่มเติม |
| ค่าเซิร์ฟเวอร์ K/V | ค่าเซิร์ฟเวอร์ K/V ต้องเป็นแบบสตริงไหม | ค่าต้องเป็นสตริง แต่สามารถจัดเก็บออบเจ็กต์ใน JSON หรือบัฟเฟอร์โปรโตคอล และจัดรูปแบบเป็นสตริงได้ |
| รายการที่บล็อกผู้ลงโฆษณา | สัญญาณใดเหมาะที่จะระบุให้ผู้ซื้อทราบสำหรับรายการบล็อกผู้ลงโฆษณา | ตำแหน่งที่เหมาะสมคือใน auctionSignals หรือใน
perBuyerSignals |
| หน่วยการเสนอราคา | รองรับหน่วยการเสนอราคาต่างๆ เช่น CPI และ CPM | เราต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับเหตุผลที่ต้องมีการเปลี่ยนแปลงนี้เมื่อพิจารณาจากการออกแบบปัจจุบัน และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| ตรรกะการประมูล | เบราว์เซอร์หรือเซิร์ฟเวอร์โฆษณาเป็นผู้ตัดสินผู้ชนะการประมูล | การเลือกผู้ชนะทั้งหมดจะดำเนินการภายในแซนด์บ็อกซ์ และโค้ดของผู้ขายจะเป็นผู้ตัดสินใจทั้งหมด เบราว์เซอร์เป็นเพียงสภาพแวดล้อมส่วนตัวที่ปิดสนิทซึ่งโค้ดของผู้ซื้อและผู้ขายทำงานอยู่ |
| Permissions-Policy | ระบบจะบังคับใช้นโยบายสิทธิ์ของ FLEDGE เวอร์ชันปัจจุบันต่อไปไหมหลังจากช่วงทดลองใช้จากต้นทางสิ้นสุดลง | สำหรับช่วงทดลองใช้ของ Origin รายการที่อนุญาตเริ่มต้นปัจจุบันของทั้ง 2 ฟีเจอร์จะเป็นแบบชั่วคราวและจะมีการเปลี่ยนแปลง เราอยากทราบว่าผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณาจะต้องเตรียมตัวสำหรับการเปลี่ยนแปลงนี้นานเท่าใดก่อนที่เราจะเริ่มบังคับใช้ |
| ข้อจำกัดด้านขนาดสัญญาณ | ระบบจะรวมคําขอสัญญาณการเสนอราคาที่เชื่อถือได้จากกลุ่มความสนใจหลายกลุ่มที่มี trustedBiddingSignalsUrl เดียวกัน แต่มีข้อจํากัดด้านขนาดที่ 2MB |
ข้อจำกัดนี้มีผลกับผู้โทรในอุปกรณ์เพื่อป้องกันไม่ให้ทรัพยากรในอุปกรณ์มีการใช้งานมากเกินไป ผู้โทรจากเซิร์ฟเวอร์ B&A จะมีข้อจำกัดที่ผ่อนปรนมากขึ้น |
| สัญญาณการรายงาน | เพิ่มสัญญาณเพิ่มเติมอย่าง "script-errors" เพื่อดึงข้อมูลจํานวนข้อผิดพลาดฝั่งไคลเอ็นต์ต่อเจ้าของกลุ่มความสนใจและต่อ computeBid หรือ reportWin / reportResult |
เรากำลังพิจารณาข้อกังวลด้านความเป็นส่วนตัวที่อาจเกิดขึ้นจากข้อเสนอนี้ และยินดีให้ผู้เล่นในระบบนิเวศแชร์ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับเหตุผลที่ต้องมีการดำเนินการนี้ |
| ขนาดหน้าต่าง K-Anon | เพิ่มขนาดกรอบเวลา K-Anon จากขีดจํากัด 7 วันในปัจจุบัน | เรากำลังพิจารณาเรื่องนี้และกำลังรอ (และยินดีรับ)ข้อมูลเพิ่มเติมจากระบบนิเวศ |
| ประสิทธิภาพของอุปกรณ์ | FLEDGE จะจัดการประสิทธิภาพของอุปกรณ์อย่างไรหากผู้ใช้อยู่ในกลุ่มความสนใจจํานวนมาก | FLEDGE มีตัวเลือกการหมดเวลา การกำหนดลำดับความสำคัญ และขีดจำกัดหลายรายการใน SSP และ DSP ซึ่งช่วยให้นักเทคโนโลยีโฆษณาควบคุมได้อย่างละเอียดในสถานการณ์ที่ประสิทธิภาพของอุปกรณ์อาจเป็นเหตุผลหนึ่งในการจำกัดการเข้าร่วมการประมูลเมื่ออุปกรณ์อยู่ในกลุ่มความสนใจจํานวนมาก |
| การทดสอบบริการ B&A | ขอให้ผู้เข้าร่วมในระบบนิเวศใช้เซิร์ฟเวอร์ของตนเองในระยะการทดสอบเพื่อให้มีบันทึกเพิ่มเติมสำหรับการแก้ไขข้อบกพร่อง | B&A อนุญาตให้ผู้ใช้เปิดใช้งานและปรับขนาดเซิร์ฟเวอร์จากผู้ให้บริการระบบคลาวด์ที่ได้รับอนุมัติ เราบังคับให้การดำเนินการเกิดขึ้นภายในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) เพื่อรักษาความเป็นส่วนตัวของผู้ใช้ เราจะเผยแพร่คำอธิบายเกี่ยวกับการแก้ไขข้อบกพร่องของ TEE แบบ B&A เร็วๆ นี้และกำลังพัฒนาฟีเจอร์เพื่อรองรับการดำเนินการดังกล่าว เราต้องการความคิดเห็นเพิ่มเติมเกี่ยวกับหัวข้อนี้ |
| ข้อกำหนดด้านการกำกับดูแล | FLEDGE จะทำงานร่วมกับผู้ให้บริการระบบคลาวด์ในประเทศต่างๆ เพื่อรองรับการปฏิบัติตามข้อกำหนดด้านกฎระเบียบท้องถิ่นหรือไม่ | เราเปิดรับคำแนะนำสำหรับผู้ให้บริการระบบคลาวด์รายอื่นๆ เสมอ แต่ปัจจุบันเราวางแผนที่จะรองรับ GCP และ AWS เป็นอย่างน้อยเมื่อมีการบังคับใช้การเลิกใช้งานคุกกี้ของบุคคลที่สาม ดูข้อมูลเพิ่มเติมได้ในคำอธิบายนี้ |
การวัดผลโฆษณาดิจิทัล
การรายงานการระบุแหล่งที่มา (และ API อื่นๆ)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การวิเคราะห์ข้อมูลผลกระทบจากเสียงรบกวน | คำแนะนำเกี่ยวกับวิธีวิเคราะห์ข้อมูลเกี่ยวกับผลกระทบของเสียงรบกวน | เราได้แชร์เอกสารประกอบเพิ่มเติมเกี่ยวกับสัญญาณรบกวน รวมถึงเกี่ยวกับสัญญาณรบกวนและการตัดสินการออกแบบที่สามารถใช้เพื่อเปลี่ยนผลกระทบของสัญญาณรบกวนต่อข้อมูลเทคโนโลยีโฆษณา นอกจากนี้ยังมีคำแนะนำโดยละเอียดให้ด้วย |
| การรายงานค่า Null | ความชัดเจนในการใช้งานรายงาน Null | ขณะนี้เรากําลังดำเนินการกับข้อเสนอในการใช้รายงาน Null และจะมีรายละเอียดเพิ่มเติมให้ทราบในเร็วๆ นี้ การใช้รายงาน Null ช่วยให้เราลดการล่าช้าของรายงานได้โดยไม่ละเมิดความเป็นส่วนตัว |
| ระดับเสียงรบกวน | การปรับระดับสัญญาณรบกวนตามระยะเวลาของกรอบเวลาการระบุแหล่งที่มา | เรายินดีรับข้อเสนอนี้และกำลังพิจารณาที่จะเพิ่มข้อเสนอนี้ลงในข้อกําหนด เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่ |
| ขนาดข้อมูลทริกเกอร์ | เหตุใดขนาดข้อมูลทริกเกอร์จึงจํากัดไว้ที่ 3 บิต | ขนาดถูกจํากัดไว้ที่ 3 บิตและค่าที่แตกต่างกัน 8 ค่าเพื่อให้มั่นใจว่าปริมาณข้อมูลข้ามเว็บไซต์/บริบทเกี่ยวกับผู้ใช้จะจํากัด เรายินดีให้ผู้เล่นในระบบนิเวศส่งความคิดเห็นว่าการกำหนดพารามิเตอร์ปัจจุบันสำหรับการรายงานระดับเหตุการณ์เหมาะสมหรือไม่ |
| ทริกเกอร์การรายงานระดับเหตุการณ์ | อนุญาตให้จัดลําดับความสําคัญภายในคีย์การกรองข้อมูลที่ซ้ำกันออก | เรากำลังหาวิธีแก้ปัญหานี้และยินดีรับความคิดเห็นเพิ่มเติม |
| การสนับสนุนด้านการแก้ไขข้อบกพร่อง | ความชัดเจนเกี่ยวกับการแก้ไขข้อบกพร่องหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม | เราต้องการรองรับการแก้ไขข้อบกพร่องหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามและกำลังพิจารณาตัวเลือกต่างๆ เราต้องการความคิดเห็นและไอเดียเพิ่มเติม |
| ทางเลือก Conversion การคลิกผ่าน | ขอคําแนะนําเพิ่มเติมเกี่ยวกับทางเลือกสําหรับ Conversion การคลิกผ่าน | เราขอแนะนําให้ระบบนิเวศใช้ Attribution Reporting API เป็นระบบการวัดผลส่วนตัวที่ยั่งยืนสําหรับ Use Case การวัด Conversion ที่เกี่ยวข้อง ยังมีทางเลือกอื่นๆ อยู่ และผู้ให้บริการเทคโนโลยีโฆษณาจะต้องตัดสินใจเลือกโซลูชันที่เหมาะสมตามความต้องการด้านความเป็นส่วนตัวและยูทิลิตีที่ต้องการ |
| กรณีการใช้งานการเรียกเก็บเงิน | ความชัดเจนเกี่ยวกับขอบเขตที่การรายงานการระบุแหล่งที่มาจะรองรับกรณีการใช้งานการเรียกเก็บเงินตาม Conversion | เรากําลังดำเนินการโพสต์ข้อมูลแบบสาธารณะเพื่อชี้แจงขอบเขตของ Attribution Reporting API สําหรับการเรียกเก็บเงิน เดิม Attribution Reporting API ไม่ได้กําหนดขอบเขตให้รองรับการเรียกเก็บเงิน CPA โดยตรง แต่รองรับการเรียกเก็บเงิน CPC และ CPM ซึ่งเป็นโครงสร้างการเรียกเก็บเงินที่เทคโนโลยีโฆษณาส่วนใหญ่ใช้ เราอาจรองรับการดำเนินการนี้ในอนาคตหากได้รับความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศ |
| การสนับสนุนกรณีการใช้งาน | เอกสารประกอบเกี่ยวกับกรณีการใช้งานสําหรับ Measurement API | เรากําลังทําความชัดเจนในเอกสารประกอบสําหรับแพลตฟอร์มการรายงาน Privacy Sandbox ทั้งหมด |
| คุณภาพคลิก | คำขอเพิ่มสัญญาณเพื่อแยกคลิกโฆษณาที่ตั้งใจและไม่ตั้งใจ | เรากําลังหารือเกี่ยวกับคําขอและยินดีรับฟังความคิดเห็นเพิ่มเติม |
| โซลูชันการวัดผล | การรองรับโซลูชันการวัดผลใน DSP หลายรายการ | ผู้ให้บริการการวัดผลสามารถใช้ Attribution Reporting API เพื่อกรองข้อมูลที่ซ้ำกันออกระหว่าง DSP หลายรายการ นอกจากนี้ เรากําลังเสนอการรองรับรายการ URL ใน attributionsrc ซึ่งจะช่วยให้ DSP รองรับคําขอ Attribution Reporting API ของผู้ให้บริการการวัดผลได้ง่ายขึ้น เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับข้อเสนอข้างต้น |
| การรายงานระดับเหตุการณ์ | คำขอให้มีจำนวนวันที่สามารถส่งรายงานได้โดยตรง | เทคโนโลยีโฆษณาสามารถคํานวณคําขอนี้ได้โดยใช้ข้อมูลที่พร้อมใช้งานในปัจจุบัน เรายังไม่ได้รับความคิดเห็นอื่นๆ จากระบบนิเวศเกี่ยวกับคำขอนี้ แต่ยินดีรับฟังความคิดเห็นเกี่ยวกับคำขอนี้ |
source_registration_time |
เพิ่ม source_registration_time ในการรายงานการระบุแหล่งที่มาระดับเหตุการณ์ |
เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมว่าผู้เล่นในระบบนิเวศเห็นว่าฟีเจอร์นี้มีประโยชน์หรือไม่ |
| โหมดไม่ระบุตัวตน | โซลูชันการวัดผลจะพร้อมใช้งานเมื่อผู้ใช้อยู่ในโหมดไม่ระบุตัวตนไหม | ไม่ โซลูชันการวัดผลจะใช้ไม่ได้เมื่อผู้ใช้อยู่ในโหมดไม่ระบุตัวตน คุกกี้ของบุคคลที่สามจะปิดอยู่โดยค่าเริ่มต้นในโหมดไม่ระบุตัวตน |
| ห้องทำความสะอาดข้อมูล | Measurement API จะใช้ร่วมกับห้องสะอาดได้ไหม | ห้องข้อมูล Clean Room ทั่วไปคือสภาพแวดล้อมที่ระบบจะอัปโหลดข้อมูลตัวระบุบุคคลจากแหล่งที่มาต่างๆ ลงในฐานข้อมูลเพื่อเรียกใช้การวิเคราะห์โดยอิงตามการผสานข้อมูลพื้นฐานนั้น เฟรมเวิร์กการวัดผล 2 รายการสําหรับ Privacy Sandbox API คือรายงานระดับเหตุการณ์และรายงานสรุป รายงานระดับเหตุการณ์มีรหัสเหตุการณ์ที่ได้จากเทคโนโลยีโฆษณาซึ่งสามารถใช้ในห้องทดลองข้อมูลได้ แต่ข้อมูลฝั่ง Conversion ที่เชื่อมโยงจะจํากัดและมีความซับซ้อน คุณไม่สามารถใช้รายงานที่รวมข้อมูลได้ซึ่งเข้ารหัสแล้วโดยตรงในห้องแชทที่สะอาด แต่สามารถใช้ผลสรุปที่บริการรวบรวมข้อมูลให้เป็นแหล่งข้อมูลในการวิเคราะห์ที่คุณทําหรือเป็นข้อมูลเสริมได้ |
บริการรวมข้อมูล
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| (รายงานในไตรมาสที่ 4 ปี 2022 ด้วย) ความล่าช้าในการรายงาน |
ความล่าช้าในการรายงานที่คาดไว้คือเท่าใด | ข้อมูลอัปเดตสำหรับไตรมาสที่ 1 ปี 2023: เราได้แชร์ข้อเสนอเพื่อลดการล่าช้า และบรรเทาผลกระทบจากการล่าช้าตามความคิดเห็นที่ได้รับจากพาร์ทเนอร์ เทคโนโลยีโฆษณารองรับทั้ง 2 ข้อเสนอในระหว่างการโทรของ WICG |
| กฎไม่มีรายการที่ซ้ำกัน | คุณจัดการ "รายงานแบบรวมที่ล่าช้า" อย่างไรหากมีการประมวลผลรายงานแบบรวมซึ่งมีรหัสที่แชร์เดียวกันแล้ว | เราได้แชร์ข้อเสนอเกี่ยวกับการเพิ่มการเลื่อนเวลารายงานเพิ่มเติมลงในข้อมูลที่แชร์ของรายงานที่รวบรวมได้ รวมถึงคําจํากัดความของรหัสที่แชร์สําหรับบริการรวบรวมข้อมูล เพื่อจัดการกับผลกระทบของการสูญเสียความล่าช้าใน API แบบรวมบางส่วน เรายินดีรับฟังความคิดเห็นเกี่ยวกับข้อเสนอ |
| การประมวลผลข้อมูล | คำขอเปิดใช้การรองรับการส่งข้อมูลหลายครั้งโดยเคารพ Differential Privacy โดยใช้งบประมาณความเป็นส่วนตัว | เรากำลังพิจารณาความเป็นไปได้ในการใช้วิธีใช้งบประมาณความเป็นส่วนตัวที่ยืดหยุ่นมากขึ้นเพื่อเปิดใช้กรณีการใช้งานนี้ และยินดีรับความคิดเห็นเพิ่มเติม |
| (รายงานในไตรมาสที่ 2 ปี 2022 ด้วย) ลักษณะที่ใช้งานง่ายของคําค้นหา | เปิดใช้การค้นหาคีย์แบบรวม | ข้อมูลอัปเดตในไตรมาสที่ 1 ปี 2023: เรายังคงพิจารณาคำขอฟีเจอร์นี้อยู่ แต่ยังไม่มีข้อเสนอที่จะแชร์ในขณะนี้ |
| ข้อจำกัดของช่วงทดลองใช้จากต้นทาง | ชี้แจงขอบเขตของบริการรวบรวมข้อมูล เช่น "กฎไม่ซ้ำ" ซึ่งปัจจุบันไม่ได้นำมาใช้ในช่วงทดลองใช้ของต้นทาง | เรากําลังพิจารณาอัปเดตเอกสารประกอบเพื่อชี้แจงสิ่งที่จะมีให้ใช้งานในเวอร์ชันทดลองใช้เวอร์ชันเดิมเทียบกับเวอร์ชันที่พร้อมให้บริการแก่ผู้ใช้ทุกคน |
Private Aggregation API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| งบประมาณการมีส่วนร่วมในการรวบรวมข้อมูลส่วนตัว | งบประมาณการมีส่วนร่วมระดับ L1 จํากัดเกินไป | การเรียก Private Aggregation API แต่ละครั้งเรียกว่าการมีส่วนร่วม เราจำกัดจำนวนการมีส่วนร่วมที่เก็บรวบรวมจากบุคคลหนึ่งๆ เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้ เมื่อคุณรวมค่าที่รวบรวมได้ทั้งหมดในคีย์การรวมทั้งหมด ผลรวมต้องน้อยกว่างบประมาณการมีส่วนร่วม ในการออกแบบปัจจุบัน เราได้กําหนดขีดจํากัดการมีส่วนร่วมของแหล่งที่มาของการรายงานหนึ่งๆ ในช่วงประมาณ 24 ชั่วโมงที่ผ่านมา (เป็นกรอบเวลาแบบต่อเนื่อง) นั่นคืองบประมาณการมีส่วนร่วมระดับ L1 ที่กล่าวถึงในความคิดเห็น เราขอแนะนำให้นักพัฒนาแอปปรับขนาดค่าที่ตนมีส่วนร่วมตามปริมาณที่คาดไว้ (ไม่ใช่แค่ใช้ค่า 1) ดังนั้น คุณจึงควรใช้มูลค่าที่น้อยลงสําหรับเหตุการณ์ที่พบบ่อยขึ้นเพื่อไม่ให้งบประมาณหมด ขณะนี้เรากําลังมองหาความคิดเห็นเกี่ยวกับงบประมาณการมีส่วนร่วมของ Aggregation API ส่วนตัว ทั้งขอบเขตตัวเลขและขอบเขต เรากำลังพิจารณาที่จะเปลี่ยนขอบเขตจากระดับแหล่งที่มาเป็นระดับเว็บไซต์ และเปลี่ยนขอบเขตที่มีอยู่เป็นกรอบเวลา 10 นาทีที่มีขอบเขตรายวันมากขึ้น |
จำกัดการติดตามแอบแฝง
การลด User Agent/คำแนะนำสำหรับไคลเอ็นต์ User Agent
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การนำ UA-R ไปใช้ | จากเว็บไซต์ยอดนิยม 10,000 อันดับแรกในสหราชอาณาจักร มีเพียง 1% ของเว็บไซต์ที่ใช้การโฆษณาแบบเป็นโปรแกรมเท่านั้นที่ส่งคำแนะนำไคลเอ็นต์ HTTP DSP ที่ไม่ได้ย้ายข้อมูลอาจส่งผลต่อความสามารถในการป้องกันการประพฤติมิชอบ | หลังจากทําการวิเคราะห์ชุดข้อมูลเดียวกัน เราพบว่าหากพิจารณาการใช้งาน UA-CH โดยใช้แท็ก HTML <meta> และ JavaScript API จํานวนเว็บไซต์ที่ใช้ UA-CH จะสูงกว่าตัวเลข 1% ที่ระบุไว้ในความคิดเห็นอย่างมาก จากข้อมูลนี้และข้อเท็จจริงอื่นๆ รวมถึงความคิดเห็นจากระบบนิเวศ เราจึงมั่นใจที่จะเดินหน้าเปิดตัวระยะที่ 6 ของการลดการใช้ UA โดยค่อยเป็นค่อยไปตามลำดับเวลาที่เผยแพร่ไปพร้อมกับแจ้งให้ CMA ทราบ เราทราบว่าเว็บไซต์ต่างๆ มีเวลาเตรียมตัวเกือบ 2 ปีเพื่อเตรียมพร้อมสําหรับการเปลี่ยนผ่าน และช่วงทดลองการเลิกใช้งานยังพร้อมให้บริการสําหรับเว็บไซต์ที่รู้สึกว่ายังไม่พร้อม |
| คำแนะนำสำหรับรูปแบบของอุปกรณ์เพิ่มเติม | คำขอ UA-CH ให้ระบุรูปแบบอุปกรณ์เพิ่มเติม เช่น ทีวี, VR | เรายินดีรับฟังข้อเสนอนี้และกำลังพิจารณาที่จะนำไปใช้กับการออกแบบ เรายินดีรับฟังความคิดเห็นเพิ่มเติม |
| การทดสอบอัตโนมัติ | คำขอแก้ไขข้อบกพร่อง UA-CH ใน Chrome แบบ Headless ก่อนเปิดตัว UAR ระยะที่ 6 | ข้อบกพร่องดังกล่าวได้รับการแก้ไขแล้ว |
| การรองรับ UA-CH ใน iOS | เว็บไซต์ที่อาศัยข้อมูล UA แบบละเอียดสําหรับ Use Case ของโฆษณาจะระบุว่าไม่รองรับ Chrome ใน iOS | สําหรับเบราว์เซอร์ iOS ที่ไม่ใช่ Safari (รวมถึง Chrome ใน iOS) โปรเจ็กต์ WebKit จะต้องเพิ่มการรองรับ UA-CH ก่อนจึงจะเปิดใช้ได้ (เนื่องจากควบคุมสแต็กเครือข่าย) |
การปกป้อง IP (เดิมเรียกว่า Gnatcatcher)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| (รายงานในไตรมาสที่ 4 ด้วย) กรณีการใช้งานตําแหน่งทางภูมิศาสตร์ | การคุ้มครองทรัพย์สินทางปัญญาอาจทำให้ Use Case ตำแหน่งทางภูมิศาสตร์ที่ถูกต้องใช้งานไม่ได้ในอนาคต เช่น การปรับเนื้อหาในแบบของคุณตามตำแหน่งทางภูมิศาสตร์ | คำตอบของเราไม่มีการเปลี่ยนแปลงจากไตรมาสที่ 4 ปี 2022 "เรากำลังทำงานร่วมกับผู้มีส่วนเกี่ยวข้องเพื่อให้มั่นใจว่า Chrome จะยังคงรองรับกรณีการใช้งานที่อยู่ IP ที่ถูกต้องต่อไป เราต้องการความคิดเห็นจากระบบนิเวศเกี่ยวกับความละเอียดของตำแหน่งทางภูมิศาสตร์จาก IP" |
| การปฏิบัติตามข้อบังคับ | หากภูมิภาคหนึ่งมีประชากรไม่ถึง 1 ล้านคน เกณฑ์ปัจจุบันที่ 1 ล้านคนสําหรับการปกป้อง IP จะป้องกันไม่ให้เว็บไซต์ใช้ที่อยู่ IP เพื่อปฏิบัติตามข้อกําหนด | เรากำลังทำงานร่วมกับผู้มีส่วนเกี่ยวข้องเพื่อให้มั่นใจว่า Chrome จะยังคงรองรับกรณีการใช้งานที่อยู่ IP ที่ถูกต้องต่อไป เราต้องการความคิดเห็นจากระบบนิเวศเกี่ยวกับการปฏิบัติตามข้อกำหนดด้านการคุ้มครองทรัพย์สินทางปัญญา |
| การลดการละเมิด | บุคคลที่สามอาจหลบเลี่ยงการปกป้อง IP ได้โดยแชร์ที่อยู่ IP ที่ไม่ได้มาสก์กับผู้อื่น | เราตระหนักถึงความเสี่ยงที่ข้อเสนอการคุ้มครองทรัพย์สินทางปัญญาในปัจจุบันอาจไม่ป้องกันไม่ให้บุคคลที่สามแชร์ที่อยู่ IP ที่ไม่ปกปิดกับผู้อื่นได้ในทางเทคนิค เรากำลังหาวิธีลดความเสี่ยงนี้ เรายินดีรับฟังความคิดเห็นและการพูดคุยเพิ่มเติมขณะที่เราปรับปรุงข้อเสนอนี้ กล่าวโดยละเอียดคือ เราต้องการทราบกรณีการใช้งานที่ฝ่ายต่างๆ เชื่อว่าจำเป็นต้องแชร์ที่อยู่ IP ที่ไม่ได้มาสก์กับบุคคลอื่น |
| การบล็อกเครือข่าย | บุคคลที่สามอาจหลบเลี่ยงการบล็อกเครือข่ายได้โดยใช้พร็อกซีการป้องกัน IP | บุคคลที่ทำการบล็อกจะต้องปิดใช้การปกป้อง IP สำหรับสถานการณ์นี้ เราได้ตอบกลับปัญหาแล้ว และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| รายการบล็อกที่อยู่ IP ที่ได้รับผลกระทบจากข้อเสนอการปกป้อง IP | บริษัทเทคโนโลยีโฆษณาจํานวนมากใช้รายการบล็อกพื้นฐานของที่อยู่ IP เช่น รายการ IP ของศูนย์ข้อมูล TAG เพื่อป้องกันการเสนอราคาในพื้นที่โฆษณาที่มีแนวโน้มสูงว่าเป็นการประพฤติมิชอบ (หรืออย่างน้อยก็ไม่สามารถสร้างรายได้) ในกรณีที่เทคโนโลยีโฆษณาเป็นเครื่องมือติดตามด้วยและอาจอยู่ภายใต้ข้อเสนอการคุ้มครองทรัพย์สินทางปัญญา บริษัทดังกล่าวอาจไม่สามารถดำเนินการตรวจสอบเบื้องต้นกับโฆษณาก่อนซื้อพื้นที่โฆษณาได้ | เราขอเชิญชวนให้ส่งความคิดเห็นเพิ่มเติมและพูดคุยเกี่ยวกับข้อเสนอการปกป้องทรัพย์สินทางปัญญาเกี่ยวกับปัญหาที่อาจเกิดขึ้นและวิธีแก้ปัญหา ตัวเลือกหนึ่งคือการใช้รายการที่คล้ายกันกับการป้องกัน IP เช่น เราจะไม่ใช้พร็อกซีสำหรับไคลเอ็นต์ที่มาจากที่อยู่ IP ที่ได้รับแจ้งก่อนหน้านี้ |
เพิ่มความเข้มงวดให้กับขอบเขตความเป็นส่วนตัวข้ามเว็บไซต์
ชุดโดเมนของบุคคลที่หนึ่ง
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| (รายงานในไตรมาสที่ 4 ด้วย) ขีดจํากัดของโดเมน | คำขอเพิ่มจำนวนโดเมนที่เชื่อมโยง | การตอบกลับของเราไม่มีการเปลี่ยนแปลงจากไตรมาสที่ 4 ปี 2022 "เราได้ชี้แจงในการประชุม WICG ว่า Chrome มุ่งมั่นที่จะให้บริการโซลูชันที่ใช้งานได้ซึ่งคำนึงถึงสิทธิด้านความเป็นส่วนตัวของผู้ใช้ด้วย ด้วยเหตุนี้ เราจึงยินดีรับความคิดเห็นจากชุมชนเกี่ยวกับกรณีการใช้งานที่เฉพาะเจาะจงซึ่งอาจได้รับผลกระทบจากขีดจำกัดของโดเมน เพื่อให้ทีมพิจารณาวิธีจัดการกับกรณีการใช้งานเหล่านี้ไปพร้อมกับปกป้องความเป็นส่วนตัวของผู้ใช้ต่อไป" |
| การส่ง FPS ทางเลือก | ข้อเสนอสำหรับวิธีอื่นในการส่งรายการทั่วโลกสำหรับ FPS | ขณะนี้เรากําลังเตรียมให้บริการชุดโดเมนของบุคคลที่หนึ่ง (FPS) ใน Chrome และได้ตั้งค่าที่เก็บ GitHub แบบรวมศูนย์เพื่อรับชุดที่ส่งเข้ามา เนื่องจากเราหวังว่า FPS จะเข้ามาเติมเต็มช่องว่างของโซลูชันแพลตฟอร์มเว็บที่มีอยู่เพื่อเตรียมพร้อมสำหรับการเลิกใช้งานคุกกี้ของบุคคลที่สาม เราจึงคาดหวังว่าจะได้เรียนรู้จากผู้เขียนเว็บไซต์ว่าพวกเขาใช้ประโยชน์จาก FPS อย่างไร เมื่อรายการชุดต่างๆ เพิ่มขึ้นเรื่อยๆ และระบบนิเวศปรับตัวเข้ากับโลกหลังคุกกี้ของบุคคลที่สาม เราก็สามารถพัฒนากระบวนการให้ก้าวหน้าถึงจุดที่เราพิจารณารูปแบบการกระจายอำนาจแบบอื่นๆ ได้ เช่น รูปแบบที่เสนอ กระบวนการปัจจุบันของเราคาดว่าจะมีการกำหนดอายุการใช้งาน ซึ่งจะช่วยให้เราพัฒนากระบวนการรับเนื้อหาได้เมื่อเวลาผ่านไป เราจะกลับมาดูแนวคิดนี้อีกครั้งเมื่อกระบวนการส่งข้อมูลมีความสมบูรณ์ |
| การดูแลที่เก็บ | กำหนดให้มีการดูแลจัดการของชุมชนในรีโปการส่ง FPS เพื่อป้องกันการละเมิด ผู้ไม่ประสงค์ดีสามารถทำให้กระบวนการเสนอชุดโดยใช้ต้นทางที่ใช้เพียงครั้งเดียวทำงานหนักเกินกว่าที่ควรจะเป็นได้ และคำขอจำนวนมากอาจส่งผลต่อการดำเนินการสำหรับข้อเสนอชุดที่แท้จริง | เราพยายามทำให้การตรวจสอบเป็นกลางมากที่สุดโดยอาศัยการตรวจสอบความถูกต้องทางเทคนิค เราคิดว่านี่เป็นแนวทางที่ปรับขนาดได้มากที่สุดสำหรับกระบวนการส่ง เพื่อให้สอดคล้องกับเป้าหมายนี้ เราจะมุ่งมั่นที่จะทำให้กระบวนการนี้สามารถรับมือกับการส่งสแปม / อีเมลที่ใช้เพียงครั้งเดียวได้ |
| ชุดย่อยที่เกี่ยวข้อง | FPS จะรองรับ Use Case ของเวิร์กโฟลว์ผู้ให้บริการ/SaaS ของบุคคลที่สามผ่านชุดย่อยที่เกี่ยวข้องได้ไหม | เวิร์กโฟลว์ของผู้ให้บริการ / SaaS บุคคลที่สามไม่ใช่ Use Case ที่ปัจจุบันถือว่าอยู่ในขอบเขตของชุดของบุคคลที่หนึ่ง เรายินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับวิธีใช้คุกกี้ข้ามเว็บไซต์สำหรับกรณีการใช้งานเหล่านี้ |
| การผสานรวม FPS + CHIPS | ขอการผสานรวม FPS + CHIPS เพื่อรองรับกรณีการใช้งาน เช่น การทดสอบ A/B | เรากำลังพูดคุยเกี่ยวกับกรณีการใช้งานนี้และกำลังพิจารณาที่จะพูดคุยเรื่องนี้เพิ่มเติมในการโทรของ WICG และยินดีรับความคิดเห็นเพิ่มเติมที่นี่ |
| GDPR | ข้อเสนอสำหรับชุดย่อย FPS ใหม่ที่จะสร้างตามแนวคิด GDPR | เราได้พูดคุยเกี่ยวกับข้อเสนอนี้ภายในและพิจารณาข้อเสนอนี้เทียบกับความคิดเห็นอื่นๆ ที่ได้รับ รวมถึงเป้าหมายด้านความเป็นส่วนตัวของเราแล้ว เราได้ให้คำตอบที่อธิบายสาเหตุที่เราจะไม่ดำเนินการตามข้อเสนอนี้ในขณะนี้ |
| หน่วยความจำ | การเปลี่ยนแปลงขนาดหน่วยความจําของเบราว์เซอร์ที่คาดไว้เมื่อรวมรายการ FPS | เบราว์เซอร์เคยมีมาก่อนแล้วในการเก็บรายการประเภทเหล่านี้โดยส่งผลกระทบต่อหน่วยความจำน้อยที่สุด เช่น รายการการป้องกันการติดตามของ Disconnect แม้ว่าระบบจะคัดลอกรายการชุดของบุคคลที่หนึ่งไปยังไคลเอ็นต์ Chrome แต่ละตัวในเครื่อง แต่เราจะตรวจสอบขนาดไฟล์ต่อไปและมั่นใจว่าจะสามารถเพิ่มประสิทธิภาพการใช้หน่วยความจำได้ |
Fenced Frames API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ข้อจํากัดของเฟรมที่มีการปิดกั้น | ความชัดเจนเกี่ยวกับข้อจำกัดของเฟรมที่มีรั้วล้อม | ในเดือนมีนาคม เราได้อัปเดตคำอธิบายเกี่ยวกับเฟรมที่มีการกำหนดเขต ซึ่งให้ข้อมูลเกี่ยวกับความสามารถของฟีเจอร์นี้ และเรายินดีรับฟังความคิดเห็นเพิ่มเติม |
| ขยายข้อมูลการเข้าถึง | คำขอขยายสิทธิ์เข้าถึงข้อมูลรอบๆ เฟรมใกล้เคียง | เราต้องการทราบเพิ่มเติมว่าเหตุใดระบบนิเวศจึงกำหนดให้ต้องดำเนินการเช่นนี้ และยินดีรับความคิดเห็นเพิ่มเติม |
| เฟรมที่มีการปิดกั้นและ iframe | คำถามเกี่ยวกับการเทียบฟีเจอร์ระหว่างเฟรมรั้วกับ iframe | API และรายงาน Privacy Sandbox ทั้งหมดที่ใช้ได้จะใช้กับ iframe และ FencedFrames ได้เช่นเดียวกัน |
| การปรับขนาดเฟรมที่มีการปิดกั้น | การจํากัดการเปลี่ยนแปลงขนาดเฟรมจะส่งผลต่อบางกรณีการใช้งาน | เราต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับประเภทกรณีการใช้งานที่ได้รับผลกระทบจากข้อจํากัดนี้และยินดีรับความคิดเห็นเพิ่มเติม |
Shared Storage API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ชิ้นงานของบุคคลที่สาม | บุคคลที่สามจะเขียนลงในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันซึ่งแบ่งพาร์ติชันตามต้นทางได้ไหม หรือเรียกใช้เวิร์กเลตอื่นๆ สำหรับการวัดผลโดยบุคคลที่สาม | ต้นทางของบริบทการท่องเว็บที่เรียกใช้โค้ดจะกําหนดพื้นที่เก็บข้อมูลที่แชร์ที่จะเขียนข้อมูลนั้น เมื่อเพิ่มโค้ดของบุคคลที่สามลงในหน้าเว็บ โค้ดของบุคคลที่สามจะฝังเป็น iframe ที่มีบริบทการท่องเว็บของตัวเองได้ ซึ่งช่วยให้โค้ดของบุคคลที่สามเขียนไปยังต้นทางของตัวเองได้ นอกจากนี้ คุณยังฝังโค้ดของบุคคลที่สามเป็นสคริปต์แทนการใช้ iframe ได้ด้วย ซึ่งจะไม่เปลี่ยนบริบทการท่องเว็บ และบุคคลที่สามจะเขียนลงในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันของผู้ฝังได้ โปรดทราบว่ามีเพียงเจ้าของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันเท่านั้นที่อ่านจากพื้นที่เก็บข้อมูลที่ใช้ร่วมกันนั้นได้ |
| การนำออกข้อมูลซ้ำซ้อน | ระบบจะกรองข้อมูลที่ซ้ำกันออกไม่ได้สำหรับการโต้ตอบนอกระบบนิเวศของ Chrome | พื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีไว้เพื่อให้ผลลัพธ์การเข้าถึงที่ไม่ซ้ำกันซึ่งอิงตามเบราว์เซอร์ Chrome ภายใน Chrome เราสนใจที่จะทํางานร่วมกับเทคโนโลยีโฆษณาเพื่อทําความเข้าใจว่าเอาต์พุตเหล่านี้นําไปใช้เป็นส่วนหนึ่งของรูปแบบการเข้าถึงที่กว้างขึ้นได้อย่างไร เราเข้าใจว่าเอาต์พุตอาจอธิบายถึงการโต้ตอบเพียงบางส่วนเท่านั้น และสนใจที่จะทํางานร่วมกับเทคโนโลยีโฆษณาเพื่อสำรวจวิธีการประมาณเพิ่มเติมที่อาจซ้อนทับกันได้ |
| กรอบเวลามองย้อนกลับของ Conversion | ขอให้มีกรอบเวลามองย้อนกลับสําหรับอัตรา Conversion เพื่อดูการเปลี่ยนแปลงของ Conversion เมื่อเวลาผ่านไป | ซึ่งทำได้โดยการประมวลผลเส้นทาง Conversion ต่างๆ ฝั่งไคลเอ็นต์โดยใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน ซึ่งให้ความยืดหยุ่นเพิ่มเติมสําหรับการวิเคราะห์ขั้นสูงผ่านพื้นที่เก็บข้อมูลเบราว์เซอร์ที่ไม่มีการแบ่งพาร์ติชันและปลอดภัย |
| กรอบเวลาหมดอายุของสินค้า | ขอขยายกรอบเวลาหมดอายุเป็น 90 วัน | นโยบายการเก็บรักษาข้อมูลได้รับการปรับปรุงในเดือนพฤศจิกายน 2022 และระบุว่าระบบจะล้างคีย์แต่ละรายการหลังจากการเขียนครั้งล่าสุดผ่านไปแล้ว 30 วัน เรายินดีรับฟังความคิดเห็นเพิ่มเติมเพื่อทําความเข้าใจว่านโยบายใหม่จะเหมาะกับระบบนิเวศหรือไม่ |
| การหมุนเวียนครีเอทีฟโฆษณา | Use Case การหมุนเวียนครีเอทีฟโฆษณาไม่ได้แสดงถึงการกระทำจริงหลังการประมูล | เราอยากทราบความคิดเห็นจากบริษัทเทคโนโลยีโฆษณาฝั่งซื้อเพิ่มเติมว่าเอกสารประกอบเกี่ยวกับการหมุนเวียนครีเอทีฟโฆษณาถูกต้องหรือไม่ |
CHIPs
ไม่ได้รับความคิดเห็นในไตรมาสนี้
FedCM
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ปลายทางการระบุตัวตน | อนุญาตคําขอที่ไม่เจาะจงไปยังปลายทางการยืนยันตัวตนอย่างชัดเจน | เราได้ร่วมมือกับ Mozilla ในคำขอดึงนี้เพื่อจำกัดความสามารถของเว็บไซต์ในการส่งคำขอที่มีข้อมูลเข้าสู่ระบบข้ามแหล่งที่มาโดยอัตโนมัติโดยไม่สร้างความรำคาญให้แก่ผู้ใช้ และจะตรวจสอบและดำเนินการตามความคิดเห็นอื่นๆ ต่อไป |
| ป้อนข้อมูลประจำตัวล่วงหน้า | FedCM ใช้เพื่อป้อนข้อมูลแบบฟอร์มการลงชื่อเข้าใช้ล่วงหน้าด้วยผู้ให้บริการข้อมูลประจำตัวจากรายการ FedCM ได้ไหม | ข้อกังวลเกี่ยวกับกรณีการใช้งานนี้คือ อาจส่งผลให้เกิดการรั่วไหลของข้อมูลเมื่อเว็บไซต์ที่ไม่ได้มีส่วนร่วมกับผู้ใช้สามารถค้นหา IDP รายการล่าสุดที่ผู้ใช้ใช้ เรากำลังหารือเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| การเลือกบัญชีตามบริบท | ข้อเสนอในการเพิ่มสัญญาณตามบริบทใน UI การเลือกบัญชี | เรากำลังพิจารณาข้อเสนอนี้และยินดีรับการพูดคุยเพิ่มเติม |
ต่อสู้กับสแปมและการประพฤติมิชอบ
Private State Tokens API (และ API อื่นๆ)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| แบบสํารวจการเก็บรวบรวมความสามารถ | เมื่อต้นไตรมาสที่ 1 เราได้รวบรวมผลสำรวจเกี่ยวกับความสามารถที่จำเป็นสำหรับกรณีการใช้งานต่างๆ ในการป้องกันการประพฤติมิชอบเสร็จแล้ว และแชร์ผลลัพธ์ดังกล่าวต่อสาธารณะ (นาที, ผลลัพธ์) | เราวางแผนที่จะนําความคิดเห็นนี้ไปใช้ในการพัฒนาข้อเสนอและโปรโตไทป์ใหม่ๆ สําหรับ API ด้านการรักษาความเป็นส่วนตัวที่สร้างขึ้นเพื่อวัตถุประสงค์ในการป้องกันการประพฤติมิชอบ เราคาดว่าจะให้ความสำคัญกับการพัฒนาเมื่อความต้องการมีมากพอและมีเทคโนโลยีที่มีอยู่ซึ่งเรานำมาต่อยอดเพื่อเปิดตัวความสามารถบนเว็บได้ พร้อมกับรักษาความเป็นส่วนตัวของผู้ใช้ ตัวอย่างเช่น อุปกรณ์และการเปิดเครื่องที่สมบูรณ์ได้รับการจัดอันดับสูง และแพลตฟอร์มจำนวนมากมี API ที่มีอยู่ซึ่งแชร์การประเมินความสมบูรณ์ของอุปกรณ์อย่างปลอดภัย จึงเหมาะที่จะลองสำรวจภายในกลุ่มชุมชน |
| ความคิดเห็นเกี่ยวกับความตั้งใจที่จะจัดส่งของ PST | เราได้ข้อกังวลเกี่ยวกับการดำเนินการต่อเนื่องจากเราใช้ Privacy Pass เวอร์ชันเก่า นอกจากนี้ เรายังได้รับความคิดเห็นว่าข้อกําหนดไม่ชัดเจนในบางส่วน และควรปรับปรุงเพื่อให้เบราว์เซอร์ใช้งานร่วมกันได้ | เราวางแผนที่จะใช้การเปลี่ยนแปลงข้อกําหนดหลายรายการที่แนะนําก่อนส่งไปยัง GA รวมถึงการเปลี่ยนแปลง API 2-3 รายการ เราได้รับความคิดเห็นในช่วงสิ้นไตรมาสที่ 1 เราจึงติดตามผลเกี่ยวกับปัญหาใน github พร้อมรายละเอียดที่เฉพาะเจาะจงและข้อมูลอัปเดตเกี่ยวกับแผนเปิดตัว (อยู่ระหว่างดำเนินการ ณ เวลาที่เผยแพร่รายงานความคิดเห็นนี้) สำหรับการเปลี่ยนแปลงที่สำคัญใน API เรายินดีที่จะพิจารณา แต่เราคิดว่าวิธีที่ดีที่สุดคือเปิดตัวเวอร์ชันสำหรับผู้ใช้ทั่วไปและรับความคิดเห็นจากนักพัฒนาซอฟต์แวร์จำนวนมาก เราหวังว่าจะได้พูดคุยเรื่องนี้ต่อและเดินหน้ามาตรฐานเบราว์เซอร์ต่อไป หากมีมาตรฐานใหม่เกิดขึ้น เราจะพิจารณานำมาตรฐานดังกล่าวมาใช้และจัดทำแผนเพื่อเปลี่ยนไปใช้มาตรฐานใหม่อย่างรอบคอบ |