รายงานรายไตรมาสสำหรับไตรมาสที่ 4 ของปี 2022 ซึ่งสรุปความคิดเห็นที่ได้รับจากระบบนิเวศเกี่ยวกับข้อเสนอ 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 |
|---|---|---|
| (รายงานในไตรมาสที่ 3 ด้วย) ประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ |
ข้อกังวลที่ว่าเทคโนโลยี Privacy Sandbox จะให้ประโยชน์แก่นักพัฒนาซอฟต์แวร์รายใหญ่ และเว็บไซต์เฉพาะกลุ่ม (ขนาดเล็ก) จะให้ประโยชน์มากกว่าเว็บไซต์ทั่วไป (ขนาดใหญ่) | คำตอบของเราไม่มีการเปลี่ยนแปลงจากไตรมาสที่ 3 "Google มุ่งมั่นที่จะออกแบบและใช้งานข้อเสนอ Privacy Sandbox กับ CMA ในลักษณะที่ไม่บิดเบือนการแข่งขันด้วยการให้ความสำคัญกับธุรกิจของ Google เอง และพิจารณาผลกระทบต่อการแข่งขันในการโฆษณาดิจิทัล รวมถึงผู้เผยแพร่โฆษณาและผู้ลงโฆษณา ไม่ว่าขนาดจะเล็กหรือใหญ่ เรายังคงทำงานร่วมกับ CMA อย่างใกล้ชิดเพื่อให้มั่นใจว่าการดำเนินการของเราเป็นไปตามความมุ่งมั่นเหล่านี้ เมื่อการทดสอบ Privacy Sandbox ดำเนินไป คำถามสำคัญอย่างหนึ่งที่เราประเมินคือประสิทธิภาพของเทคโนโลยีใหม่สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ ความคิดเห็นของคุณมีความสำคัญอย่างยิ่งในเรื่องนี้ โดยเฉพาะความคิดเห็นที่เฉพาะเจาะจงและนำไปใช้ได้จริง ซึ่งจะช่วยให้เราปรับปรุงการออกแบบทางเทคนิคให้ดียิ่งขึ้นได้ เราได้ทํางานร่วมกับ CMA เพื่อพัฒนาแนวทางการทดสอบเชิงปริมาณ และสนับสนุน CMA ในการเผยแพร่หมายเหตุเกี่ยวกับการออกแบบการทดสอบเพื่อให้ข้อมูลเพิ่มเติมแก่ผู้เข้าร่วมในตลาดและโอกาสในการแสดงความคิดเห็นเกี่ยวกับแนวทางที่เสนอ" |
| (รายงานในไตรมาสที่ 3 ด้วย) คำขอเอกสารประกอบ |
คำขอแหล่งข้อมูลเพิ่มเติมที่อธิบายวิธีจัดการการทดสอบ การวิเคราะห์ และการใช้งาน | ข้อมูลอัปเดตประจำไตรมาสที่ 4: เรายินดีที่นักพัฒนาแอปพบว่าเนื้อหาปัจจุบันของเรามีประโยชน์ และยังคงมุ่งมั่นที่จะให้เนื้อหาเพิ่มเติมเพื่อให้นักพัฒนาแอปเข้าใจว่าเทคโนโลยีใหม่นี้จะช่วยพวกเขาได้อย่างไร ในช่วงไตรมาสที่ผ่านมา เราได้เพิ่มส่วน "ข่าวและการอัปเดต" ลงใน privacysandbox.com และเผยแพร่รีวิวที่ครอบคลุมเกี่ยวกับวิธีที่ Privacy Sandbox ช่วยเพิ่มความเกี่ยวข้องของโฆษณาในอนาคต นอกจากนี้ เรายังจัดเซสชัน "เวลาทำการ" สาธารณะสำหรับนักพัฒนาแอปเพื่อแชร์แนวทางปฏิบัติแนะนำและการสาธิต รวมถึงจัดเซสชันถามและตอบกับหัวหน้าทีมผลิตภัณฑ์และวิศวกรเพื่อให้สามารถพูดคุย/ถามคำถามกันแบบเรียลไทม์ |
| Core Web Vitals | เวลาในการตอบสนองของ Privacy Sandbox API ส่งผลต่อ Core Web Vitals อย่างไร | การลดเวลาในการตอบสนองให้เหลือน้อยที่สุดเป็นเป้าหมายหลักในการออกแบบ Privacy Sandbox API ขณะนี้เราคาดหวังว่าเวลาในการตอบสนองของ API ควรส่งผลกระทบต่อ Core Web Vitals ของเว็บไซต์น้อยที่สุด เนื่องจากมีการเรียก API ส่วนใหญ่หลังจากการแสดงผลครั้งแรกของเว็บไซต์ เรายังคงตรวจสอบและปรับปรุงเพื่อลดเวลาในการตอบสนองของ API แต่ละรายการต่อไป รวมถึงขอแนะนำให้ทำการทดสอบและแสดงความคิดเห็นอย่างต่อเนื่อง เวลาในการตอบสนองในกระบวนการเสนอราคาแบบเรียลไทม์จะได้รับการแก้ไขในส่วน FLEDGE ในส่วน "ประสิทธิภาพของการประมูล FLEDGE" |
| ความสามารถในการทำงานร่วมกัน | ข้อกังวลเกี่ยวกับความสามารถในการทำงานร่วมกันกับโซลูชันอื่นๆ ที่เป็นไปได้ | เป้าหมายของ Privacy Sandbox คือปกป้องผู้ใช้จากการติดตามข้ามเว็บไซต์ไปพร้อมกับรองรับความต้องการของระบบนิเวศเว็บ เรามุ่งมั่นที่จะบรรลุเป้าหมายนี้ด้วยการเลิกใช้เทคโนโลยีเบราว์เซอร์เดิมที่เปิดใช้การติดตามข้ามเว็บไซต์ เช่น คุกกี้ของบุคคลที่สาม และแทนที่ด้วยเทคโนโลยีใหม่ที่ออกแบบมาเพื่อรองรับกรณีการใช้งานที่เฉพาะเจาะจง ข้อเสนอ Privacy Sandbox จะช่วยปรับปรุงความเป็นส่วนตัวโดยจำกัดข้อมูลที่ออกจากอุปกรณ์ของผู้ใช้ ข้อเสนอดังกล่าวไม่ได้จํากัดทางเทคนิคความสามารถของเว็บไซต์ในการแชร์หรือประมวลผลข้อมูลเมื่อรวบรวมจากเบราว์เซอร์ ดังนั้น เทคโนโลยีเหล่านี้จึงไม่ได้ป้องกันไม่ให้บริษัททำข้อตกลง "การจัดการข้อมูล" หรือความสัมพันธ์ตามสัญญาอื่นๆ ที่คล้ายกัน ในทํานองเดียวกัน นโยบายดังกล่าวไม่ได้จํากัดความสามารถของผู้ใช้ในการให้ความยินยอมให้แชร์ข้อมูลของตนผ่านวิธีอื่นๆ เพื่อความชัดเจน Google มุ่งมั่นที่จะใช้เทคโนโลยี Privacy Sandbox ในลักษณะเดียวกันกับเว็บไซต์ทั้งหมด ซึ่งรวมถึงผลิตภัณฑ์และบริการของ Google หลังจาก Chrome หยุดรองรับคุกกี้ของบุคคลที่สามแล้ว ความมุ่งมั่นดังกล่าวยังระบุไว้อย่างชัดเจนว่า Google จะไม่ใช้ข้อมูลส่วนบุคคลอื่นๆ เช่น ประวัติการท่องเว็บของ Chrome ที่ซิงค์ไว้ของผู้ใช้ เพื่อติดตามผู้ใช้สำหรับการกำหนดเป้าหมายหรือวัดผลโฆษณาดิจิทัล |
แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง
หัวข้อ
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ผลกระทบต่อการจัดอันดับการค้นหาของ Google | คำถามว่าระบบจะใช้การรองรับ Topics API ของเว็บไซต์เป็นสัญญาณที่เป็นไปได้สำหรับการจัดอันดับผลการค้นหาของ Google Search หรือไม่ | เว็บไซต์บางแห่งอาจเลือกไม่ใช้ Topics API ทีม Privacy Sandbox ไม่ได้ประสานงานหรือขอให้องค์กร Search ใช้การจัดอันดับหน้าเว็บเป็นสิ่งจูงใจให้เว็บไซต์ใช้ Topics API Google ได้ยืนยันกับ CMA ว่า Google Search จะไม่ใช้การตัดสินใจของเว็บไซต์ในการเลือกไม่ใช้ Topics API เป็นสัญญาณการจัดอันดับ |
| ตัวแยกประเภทหัวข้อ | เพิ่ม URL และเนื้อหาหน้าเว็บนอกเหนือจากชื่อโฮสต์เพื่อระบุหัวข้อของหน้าเว็บเพื่อปรับปรุงประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องต่างๆ | ปัจจุบันระบบจัดหมวดหมู่ประวัติการท่องเว็บของผู้ใช้โดยใช้ชื่อโฮสต์ของเว็บไซต์ Chrome จะยังคงประเมินตัวเลือกต่างๆ ในการพิจารณาข้อมูลเมตาระดับหน้า (เช่น องค์ประกอบทั้งหมดหรือบางส่วนของ URL และ/หรือเนื้อหาของหน้า) ในการแยกประเภทหัวข้อ การปรับปรุงยูทิลิตีต้องพิจารณาจากความเสี่ยงด้านความเป็นส่วนตัวและการละเมิด ตัวอย่างเช่น ความเสี่ยงบางประการที่เกี่ยวข้องกับข้อมูลเมตาโดยเฉพาะ ได้แก่ - เว็บไซต์ที่แก้ไขข้อมูลเมตาระดับหน้าเว็บเพื่อเข้ารหัสความหมายที่แตกต่างกัน (และอาจเป็นเรื่องละเอียดอ่อน) ไว้ในหัวข้อ - เว็บไซต์ที่แก้ไขข้อมูลเมตาระดับหน้าเว็บเพื่อสื่อให้เข้าใจผิดเกี่ยวกับหัวข้อของตนเพื่อผลประโยชน์ทางการเงิน - เว็บไซต์ที่แก้ไขข้อมูลเมตาระดับหน้าเว็บแบบไดนามิกเพื่อใช้ในการติดตามข้ามเว็บไซต์ |
| (รายงานในไตรมาสที่ 3 ด้วย) ผลกระทบต่อสัญญาณของบุคคลที่หนึ่ง |
สัญญาณหัวข้ออาจมีคุณค่าสูง จึงทําให้สัญญาณอื่นๆ ที่อิงตามความสนใจของบุคคลที่หนึ่งมีคุณค่าน้อยลง | คำตอบของเราไม่เปลี่ยนแปลงจากคําถามที่ 3 "เราเชื่อว่าการโฆษณาตามความสนใจเป็น Use Case ที่สําคัญสําหรับเว็บ และ Topics ได้รับการออกแบบมาเพื่อรองรับ Use Case ดังกล่าว ตามที่อธิบายไว้ [ในรายงานไตรมาสที่ 3] ผู้มีส่วนเกี่ยวข้องอื่นๆ ในระบบนิเวศได้แสดงความกังวลว่า Topics อาจไม่เป็นประโยชน์มากพอที่จะให้คุณค่า ไม่ว่าในกรณีใดก็ตาม การปรับปรุงการจัดหมวดหมู่เป็นกระบวนการอย่างต่อเนื่อง และเราคาดหวังว่าการจัดหมวดหมู่จะพัฒนาไปพร้อมกับการทดสอบและข้อมูลที่ได้รับจากระบบนิเวศ" |
| การอัปเดตการจัดหมวดหมู่ | ระบบจะอัปเดตรายการการจัดหมวดหมู่อย่างไร | เรากำลังขอความคิดเห็นเกี่ยวกับการจัดหมวดหมู่ที่มีประโยชน์ต่อระบบนิเวศมากที่สุด การจัดหมวดหมู่ที่รวมอยู่ในข้อเสนอ Topics API ฉบับแรกออกแบบมาเพื่อเปิดใช้การทดสอบฟังก์ชันการทำงาน Chrome กำลังพิจารณาแนวทางต่างๆ ในการอัปเดตการจัดหมวดหมู่ ตัวอย่างเช่น Chrome อาจใช้แนวคิดเรื่องมูลค่าเชิงพาณิชย์สำหรับหัวข้อแต่ละหัวข้อเพื่อพิจารณาว่าควรรวมหมวดหมู่ใดไว้ในเวอร์ชันที่อัปเดตในอนาคต |
| ประสิทธิภาพของคลาสฟิเออร์ระดับภูมิภาคของ Topics | Classifier หัวข้อทํางานได้ไม่ดีในโดเมนระดับภูมิภาค | การปรับปรุงตัวจัดประเภทเป็นกระบวนการอย่างต่อเนื่อง จากความคิดเห็นที่ได้รับ หนึ่งในสิ่งที่เรากำลังพิจารณาคือการเพิ่มรายการการลบล้างของ Topics ซึ่งการวิเคราะห์ของเราแสดงให้เห็นว่าจะเพิ่มความครอบคลุมทั่วโลกและปรับปรุงความแม่นยำ เราขออธิบายเพิ่มเติมว่าการจัดประเภทของ Topics API มีส่วนประกอบที่เกี่ยวข้อง 2 อย่าง ได้แก่ (1) รายการการลบล้างที่มีเว็บไซต์ยอดนิยม 10,000 อันดับแรกและหัวข้อของเว็บไซต์เหล่านั้น และ (2) โมเดล ML ในอุปกรณ์ที่แบ่งประเภทชื่อโฮสต์ออกเป็นหัวข้อ การขยายรายการการลบล้าง (1) จะช่วยปรับปรุงประสิทธิภาพการจัดประเภทสำหรับภูมิภาคที่ตัวแยกประเภทอาจทำงานได้ไม่ดี |
| ช่วงเวลา 1 สัปดาห์ | ช่วงเวลา 1 สัปดาห์นั้นนานเกินไปสําหรับผู้ใช้ที่ต้องการตัดสินใจในระยะสั้น | เรากำลังพิจารณาระยะเวลาที่เหมาะสมของยุคและยินดีรับ ความคิดเห็นเพิ่มเติมเกี่ยวกับยุคที่เหมาะกับระบบนิเวศมากกว่า |
| การดึงข้อมูลส่วนหัว HTTP | ข้อกังวลเรื่องข้อมูลการดึงข้อมูลส่วนหัว HTTP ของหัวข้อไม่เพียงพอ | เรากําลังดําเนินการกับส่วนหัวและ fetch() และยังมีข้อมูลให้ดูที่นี่ด้วย นอกจากนี้ เรายังได้เพิ่มข้อมูล skipObservation ลงในคําอธิบายด้วย |
| Topics มีไว้เพื่อช่วยเหลือผู้ลงโฆษณาเท่านั้น ไม่ใช่ผู้ใช้ | Topics/Privacy Sandbox ดูเหมือนจะเป็นแนวทางที่มุ่งเน้นอุตสาหกรรม ประโยชน์ต่อผู้ใช้ไม่ชัดเจนเท่ากับประโยชน์ต่ออุตสาหกรรม | เราเชื่อว่าประโยชน์ที่ผู้ใช้จะได้รับคือ Topics รองรับโฆษณาตามความสนใจซึ่งช่วยให้เว็บเป็นอิสระและเปิดกว้างอยู่เสมอ และเรายังเชื่อว่า Topics ช่วยปรับปรุงความเป็นส่วนตัวได้อย่างมากเมื่อเทียบกับคุกกี้ของบุคคลที่สาม การนำคุกกี้ของบุคคลที่สามออกโดยไม่มีทางเลือกอื่นที่ใช้งานได้จริงอาจส่งผลเสียต่อผู้เผยแพร่โฆษณา และอาจนำไปสู่แนวทางที่แย่กว่า ซึ่งมีความเป็นส่วนตัวน้อยลง ไม่โปร่งใส และผู้ใช้ไม่สามารถรีเซ็ตหรือควบคุมได้จริง บริษัทจํานวนมากกําลังทดสอบ Topics และ Sandbox API อย่างสม่ำเสมอ และเรามุ่งมั่นที่จะมอบเครื่องมือเพื่อยกระดับความเป็นส่วนตัวและรองรับเว็บ เมื่อเร็วๆ นี้ กลุ่มสถาปัตยกรรมทางเทคนิคของ W3C ได้เผยแพร่มุมมองเบื้องต้นเกี่ยวกับ Topics API ซึ่งเราจะตอบกลับต่อสาธารณะ ในตอนนี้ Google ได้รับคำถามจากระบบนิเวศเกี่ยวกับผลกระทบที่การตรวจสอบนี้อาจมีต่อการพัฒนาและเปิดตัว Topics API เราจึงขอยืนยันอีกครั้งว่าเรามีแผนที่จะให้บริการ Topics API ใน Chrome เวอร์ชันเสถียรในปีนี้ แม้ว่า Google จะขอบคุณข้อมูลจากกลุ่มสถาปัตยกรรมทางเทคนิคของ W3C แต่เราเห็นว่าความพยายามในการพัฒนาและทดสอบ Topics ต่อไปโดยปรึกษากับ CMA และระบบนิเวศนั้นสำคัญอย่างยิ่ง |
| ข้อมูลรั่วไหล | ความกังวลว่า Topics อาจรั่วไหลไปยังเว็บไซต์อื่นๆ โดยไม่ได้รับอนุญาต | การออกแบบ Topics API ทำให้ข้อมูลจากผู้เผยแพร่เนื้อหารายเดียว (หรือแม้แต่กลุ่มผู้เผยแพร่เนื้อหาขนาดเล็ก) มีโอกาสรั่วไหลได้น้อยมาก เว็บไซต์ของผู้เผยแพร่โฆษณายังมีสิทธิ์ควบคุม Topics API อย่างเต็มรูปแบบและสามารถห้ามการเข้าถึง API นี้ผ่านนโยบายสิทธิ์ได้ |
| ไม่มีผู้ลงโฆษณาสําหรับการทดสอบ | ผู้เผยแพร่โฆษณากังวลว่าขณะนี้ไม่สามารถแสดงให้เห็นถึงคุณค่าของ Topics ต่อผู้ลงโฆษณา | ในช่วงครึ่งหลังของปี 2023 เราวางแผนที่จะให้บริการ API ทั้งหมดที่เกี่ยวข้องกับโฆษณาสำหรับการทดสอบการผสานรวมและเปิดใช้การวิเคราะห์ระบบนิเวศเกี่ยวกับคุณค่าของ Topics สําหรับผู้ลงโฆษณา CMA จะเป็นผู้ควบคุมการทดสอบและการเผยแพร่ผลลัพธ์ ซึ่งจะตรวจสอบข้อมูล การวิเคราะห์ และวิธีการ เราขอแนะนําให้ระบบนิเวศแชร์ความคิดเห็นกับ Google และ CMA |
| Topics และ FLEDGE | ขอข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้ Topics ภายในตรรกะการเสนอราคาของ FLEDGE | คุณใช้ Topics ภายในตรรกะการเสนอราคาของ FLEDGE ได้ นอกจากนี้ เรายังอยู่ระหว่างจัดทำคู่มือการผสานรวม ซึ่งจะมีรายละเอียดเพิ่มเติมเกี่ยวกับการใช้งาน |
| การจัดอันดับที่กำหนดเองสำหรับผู้เรียกใช้หัวข้อ | อนุญาตให้ผู้โทรปรับการจัดอันดับ | ปัญหาเกี่ยวกับการจัดอันดับหรือค่าหัวข้อที่กำหนดเองสำหรับเทคโนโลยีโฆษณาแต่ละรายการคือ การดำเนินการนี้อาจกลายเป็นกลไกที่เทคโนโลยีโฆษณาสามารถมีอิทธิพลต่อหัวข้อที่แสดงผลได้ จึงถือเป็นเวกเตอร์การระบุตัวตน |
| รายการลำดับความสำคัญของผู้โทรสำหรับหัวข้อ | อนุญาตให้ผู้เรียกใช้ระบุรายการหัวข้อที่มีลำดับความสำคัญซึ่ง Topics API จะแสดงตามการมีสิทธิ์ | ขณะนี้เรากำลังหารือเกี่ยวกับแนวคิดนี้เพิ่มเติม และยินดีรับฟังความคิดเห็นเพิ่มเติม |
FLEDGE
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| Google Ad Manager | ข้อกังวลที่ว่า Google Ad Manager เป็นฝ่ายตัดสินสุดท้ายสำหรับการประมูล FLEDGE และจะให้ความสําคัญกับแท็กผู้เผยแพร่โฆษณาผ่าน Google และ Google Ad Manager | FLEDGE ช่วยให้ผู้เผยแพร่โฆษณาแต่ละรายเลือกโครงสร้างของการประมูลได้ รวมถึงเลือกผู้ขายระดับบนสุดและผู้ขายคอมโพเนนต์ ผู้ซื้อและผู้ขายแต่ละรายในการประมูลคอมโพเนนต์จะทราบว่าผู้ขายระดับบนสุดคือใคร และเลือกได้ว่าจะเสนอราคาหรือไม่ |
| มีผู้เข้าร่วมการทดสอบ FLEDGE ไม่เพียงพอ | คำขอเพื่อกระตุ้นให้บริษัทต่างๆ ทดสอบ FLEDGE มากขึ้น เช่น โดยการปรับปรุงฟังก์ชันการทำงานของ API และเลิกใช้ทางเลือกที่ละเมิดความเป็นส่วนตัว เช่น การพิมพ์ลายนิ้วมือ | Privacy Sandbox กำลังดำเนินการเป็นระยะๆ โดยทำงานร่วมกับ CMA และ ICO อย่างใกล้ชิด และการทดสอบฟังก์ชันการทำงานของ FLEDGE แสดงให้เห็นถึงความเสถียรและความสามารถที่จำเป็น Google ยังคงสนับสนุนให้ระบบนิเวศทดสอบ Sandbox API โดยเพิ่งเผยแพร่เอกสารประกอบ "เพิ่มประสิทธิภาพความเกี่ยวข้องของโฆษณาให้สูงสุด" เพื่อแสดงให้เห็นว่า FLEDGE และ API อื่นๆ ช่วยสนับสนุนกรณีการใช้งานที่สําคัญสําหรับอุตสาหกรรมโฆษณาได้อย่างไรหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม ส่วนอื่นๆ ของ Privacy Sandbox รองรับการบรรเทาผลกระทบที่ครอบคลุมการติดตามอยู่แล้ว (ดู UA-CH, การปกป้อง IP และการบรรเทาผลกระทบจากการติดตามการตีกลับ) และจะปรับปรุงต่อไปเรื่อยๆ เป้าหมายของ Google ไม่ใช่การทําให้ FLEDGE เป็นโซลูชันการกําหนดเป้าหมายที่ใช้งานได้เพียงอย่างเดียว แต่ยังคงมุ่งมั่นที่จะทํางานร่วมกับอุตสาหกรรมและผู้กํากับดูแลเพื่อขับเคลื่อนเทคโนโลยีโฆษณาที่รักษาความเป็นส่วนตัวที่ดีที่สุดในเบราว์เซอร์ Chrome |
| กรณีการใช้งานแมชชีนเลิร์นนิง | คำแนะนำเพิ่มเติมเกี่ยวกับกรณีการใช้งานแมชชีนเลิร์นนิงเพื่อฝึกอัลกอริทึมการเสนอราคาในการประมูลจะได้รับการรองรับใน FLEDGE และการรายงานการระบุแหล่งที่มา | เราตระหนักถึงความจำเป็นในการช่วยให้ผู้ทดสอบค้นพบวิธีใช้เทคโนโลยี Privacy Sandbox ที่มีประโยชน์มากที่สุด เราเริ่มเผยแพร่คําแนะนําที่เกี่ยวข้องกับการใช้แง่มุมต่างๆ ของ Privacy Sandbox API เป็นอินพุตสําหรับแมชชีนเลิร์นนิงโดยเฉพาะแล้ว บทความล่าสุดเรื่องเพิ่มประสิทธิภาพความเกี่ยวข้องของโฆษณาให้สูงสุดจะอธิบายวิธีที่อุตสาหกรรมโฆษณาสามารถใช้สัญญาณเหล่านี้สําหรับแมชชีนเลิร์นนิง และเราวางแผนที่จะเผยแพร่คําแนะนําดังกล่าวต่อไป |
| การค้นหาเซิร์ฟเวอร์คีย์-ค่า (K/V) ของ FLEDGE | เหตุใดเซิร์ฟเวอร์ K/V จึงค้นหาแบบสาธารณะได้ | เซิร์ฟเวอร์ K/V มีไว้เพื่อส่งสัญญาณแบบเรียลไทม์ไปยังการประมูล FLEDGE ดังนั้น เซิร์ฟเวอร์ K/V จึงต้องเข้าถึงได้จากที่ที่การประมูล FLEDGE เหล่านั้นดำเนินการ ซึ่งอยู่ในอุปกรณ์ของผู้ใช้ จึงต้องเข้าถึงได้แบบสาธารณะ เฉพาะบุคคลที่มีคีย์อยู่แล้วเท่านั้นที่จะดึงข้อมูลค่าที่จัดเก็บไว้ในเซิร์ฟเวอร์ K/V ได้ ดังนั้นหากเทคโนโลยีโฆษณาให้คีย์แก่เบราว์เซอร์ที่อยู่ในกลุ่มความสนใจเท่านั้น และไม่ใช้คีย์ที่คาดเดาได้โดยการสุ่ม เฉพาะเบราว์เซอร์ที่ต้องการค่าเพื่อเรียกใช้การประมูลเท่านั้นที่จะดึงข้อมูลค่าได้ |
| วิธีทําการกําหนดเป้าหมายตามวันที่/เวลา | การรองรับออบเจ็กต์วันที่ในฟังก์ชันตรรกะการเสนอราคา | ซึ่งทำได้หลายวิธี ผู้ซื้อสามารถขอให้ผู้ขายระบุวันที่และเวลาปัจจุบัน และควรให้ผู้ขายระบุข้อมูลนี้แก่ผู้ซื้อทุกคนได้โดยง่าย ผู้ซื้อระบุวันที่และเวลาในการตอบกลับแบบเรียลไทม์ด้วยก็ได้ สุดท้าย ผู้ซื้อสามารถระบุวันที่และเวลาเป็นส่วนหนึ่งของการตอบสนองตามบริบทในสัญญาณต่อผู้ซื้อ ซึ่งผู้ขายสามารถส่งต่อไปยังสคริปต์ generateBid ของผู้ซื้อ |
| ค่ากำหนดของผู้ใช้ | ความสามารถในการเลือกบล็อกครีเอทีฟโฆษณาตามผู้ลงโฆษณาเมื่อแสดงผ่าน FLEDGE หรือโซลูชันอื่นๆ | ผู้ใช้สามารถเลือกไม่ใช้ Ads API ใน Chrome ได้ สําหรับโฆษณาที่เฉพาะเจาะจง เทคโนโลยีโฆษณาที่เกี่ยวข้องคือฝ่ายที่มีศักยภาพมากที่สุดในการควบคุมครีเอทีฟโฆษณาที่จะแสดงหรือวิธีเลือกครีเอทีฟโฆษณา |
| ไทม์ไลน์ที่ชัดเจนยิ่งขึ้น | ขอข้อมูลเพิ่มเติมเกี่ยวกับความพร้อมใช้งานของการป้องกันความเป็นส่วนตัวใน FLEDGE เช่น การกำหนดให้ต้องใช้เฟรมที่มีรั้วล้อม | เราวางแผนที่จะเผยแพร่ลำดับเวลาโดยละเอียดเพิ่มเติมในไตรมาสที่ 1 |
| การรายงานความสับสน | ขอความชัดเจนเพิ่มเติมเกี่ยวกับวิธีการทำงานของการรายงาน FLEDGE กับ API อื่นๆ เช่น เฟรมที่มีการกำหนดขอบเขตและ Private Aggregation API | เรามีแผนที่จะเผยแพร่คำอธิบายเกี่ยวกับการโต้ตอบระหว่าง Private Aggregation API, FLEDGE และ Fenced Frames ในอีกไม่กี่สัปดาห์ข้างหน้า |
| การเสนอราคาแบบเรียลไทม์และ FLEDGE | คําแนะนําเกี่ยวกับวิธีผสานรวม FLEDGE กับการเสนอราคาแบบเรียลไทม์มาตรฐาน | 2 ปัจจัยหลักที่ทำให้ความสามารถของเทคโนโลยีโฆษณาในการเสนอราคาแบบเรียลไทม์มีความซับซ้อนขึ้นคือ การเข้าถึงข้อมูลระดับเหตุการณ์และการผสานรวมกับ ARA ที่ง่ายขึ้น เราวางแผนที่จะส่งข้อมูลอัปเดตและคำอธิบายเกี่ยวกับทั้ง 2 รายการนี้ในไตรมาสที่ 1 |
| ประสิทธิภาพของการประมูล FLEDGE | รายงานจากผู้ทดสอบระบุว่าการประมูล FLEDGE มีเวลาในการตอบสนองสูง | ขอขอบคุณรายงานจากผู้ทดสอบที่แชร์ผลลัพธ์และกรณีการใช้งาน และเราได้แชร์คำแนะนำบางส่วนเกี่ยวกับวิธีปรับปรุงประสิทธิภาพของ FLEDGE ในขณะเดียวกัน เราได้เพิ่มเครื่องมือลงในเบราว์เซอร์เพื่อให้นักพัฒนาซอฟต์แวร์วินิจฉัยสาเหตุที่ทำให้การประมูลช้าได้ดียิ่งขึ้น และจัดการกับแหล่งที่มาหลักของเวลาในการตอบสนองที่สังเกตได้อย่างเป็นระบบ การปรับปรุงล่าสุด ได้แก่ การหมดเวลาสำหรับการประมูลที่ช้า เทคนิคการกรองผู้เสนอราคาที่รวดเร็ว วิธีนําเวิร์กเลต FLEDGE มาใช้ซ้ำเพื่อหลีกเลี่ยงการจ่ายค่าเริ่มต้น และงานอย่างต่อเนื่องเพื่ออนุญาตให้คําขอโฆษณาตามบริบททํางานควบคู่กันกับเวลาเริ่มต้นของ FLEDGE และการดึงข้อมูลเครือข่าย เราคาดว่าการเพิ่มประสิทธิภาพเวลาในการตอบสนองจะยังคงเป็นหัวข้อสนทนาอย่างต่อเนื่องระหว่างนักพัฒนาซอฟต์แวร์ Chrome และผู้ทดสอบ FLEDGE โดยอิงตามประสบการณ์การใช้งาน API ในชีวิตจริง |
| ขีดจํากัดหน่วยความจําของขนาดกลุ่มความสนใจ | คำขอเพิ่มขีดจำกัดขนาดของกลุ่มความสนใจกลุ่มเดียวจาก 50 KB | เรากำลังพิจารณาคำขอนี้และต้องการความคิดเห็นเกี่ยวกับค่าขีดจำกัดที่ได้ผล |
| การรวมข้อมูลที่ FLEDGE แสดงกับคุกกี้ของบุคคลที่หนึ่ง | FLEDGE จะรองรับการผสานรวมกับข้อมูลจากบุคคลที่หนึ่งของผู้ลงโฆษณาไหม | FLEDGE สร้างขึ้นเพื่อรองรับการโฆษณาโดยใช้ข้อมูลจากบุคคลที่หนึ่งที่ผู้ลงโฆษณามีอยู่แล้ว อย่างไรก็ตาม FLEDGE ไม่ได้มีเจตนาที่จะสนับสนุนให้ผู้ลงโฆษณาเรียนรู้พฤติกรรมการท่องเว็บของบุคคลในเว็บไซต์อื่นนอกเหนือจากเว็บไซต์ของผู้ลงโฆษณาเอง การเชื่อมโยงพฤติกรรมการท่องเว็บนอกเว็บไซต์กับข้อมูลจากบุคคลที่หนึ่งขัดต่อเป้าหมายของ Privacy Sandbox เราวางแผนที่จะแชร์คู่มือการผสานรวมพร้อมรายละเอียดเพิ่มเติมเกี่ยวกับวิธีที่ FLEDGE จะรองรับการผสานรวมกับข้อมูลจากบุคคลที่หนึ่งในอีกไม่กี่สัปดาห์ข้างหน้า |
| ค่า k-anonymity | ระบบจะกำหนดค่า "K" เป็น "k-anon" อย่างไร และจะเผยแพร่หรือไม่ | เรากําลังกําหนดค่า "K" ให้เสร็จสมบูรณ์และจะแชร์ข้อมูลเพิ่มเติมเมื่อแผนพัฒนาขึ้น เราต้องการทราบข้อมูลเพิ่มเติมว่าค่า k ที่ไม่รู้จักอาจส่งผลต่อความพร้อมใช้งานของ FLEDGE และการกำหนดขอบเขตการฝึกโมเดล ML อย่างไร และยินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับเรื่องนี้ |
| การรองรับ SSP หลายรายการ | FLEDGE จะรองรับ SSP หลายรายการได้อย่างไร | FLEDGE รองรับการประมูลกับผู้ขายหลายรายตามที่ระบุไว้ในข้อเสนอนี้ |
| ระดับการเข้าถึงตรรกะการเสนอราคา | ข้อกังวลว่าตรรกะการเสนอราคา DSP จะแสดงใน JavaScript | ขณะนี้ผู้อื่นสามารถเข้าถึง JavaScript ของตรรกะการเสนอราคาการออกแบบได้ แต่เรายินดีรับความคิดเห็นเพิ่มเติมว่าเหตุใดเรื่องนี้จึงอาจเป็นสาเหตุของความกังวลสำหรับ DSP |
| prebid.js | ไทม์ไลน์ในการรองรับ prebid.js ใน FLEDGE เป็นอย่างไร | เฉพาะ Prebid.js เวอร์ชัน 7.14 ขึ้นไปเท่านั้นที่รองรับข้อบังคับของ FLEDGE ผู้เผยแพร่โฆษณาที่สนใจการทดสอบต้องเพิ่มโมดูล FLEDGE และอัปเกรดอินสแตนซ์ Prebid |
| ฟังก์ชันที่ผู้ใช้กำหนดใน FLEDGE | FLEDGE จะรองรับฟังก์ชันที่ผู้ใช้กําหนด (UDF) อย่างไร ฟังก์ชันเหล่านี้เป็นฟังก์ชันที่ผู้ใช้ปลายทางสามารถเขียนโปรแกรมเพื่อขยายฟังก์ชันการทำงานของ API ได้ | ดูคำอธิบายได้ที่นี่ เรากําลังพัฒนาฟีเจอร์นี้อยู่ จึงยินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับ Use Case |
| ลดความเข้มงวดของข้อจำกัดต้นทางเดียวกันในทรัพยากรกลุ่มความสนใจ | คำขอผ่อนคลายข้อจำกัดแหล่งที่มาเดียวกันในทรัพยากรกลุ่มความสนใจเพื่อเปิดใช้ Use Case บางอย่างของเทคโนโลยีโฆษณา | ในการใช้งาน FLEDGE ปัจจุบัน biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl และ trustedBiddingSignalsUrl ต้องมีต้นทางเดียวกับเจ้าของกลุ่มความสนใจข้อจำกัดนี้มีไว้เพื่อป้องกันการโจมตีบางอย่างโดยผู้โจมตี ตามที่อธิบายไว้ที่นี่ |
| การเป็นเจ้าของกลุ่มความสนใจ | คำขอจํากัดว่าเทคโนโลยีโฆษณาสามารถใช้ joinInterestGroup สําหรับกลุ่มความสนใจเดียวกันในเว็บไซต์ต่างๆ ได้หรือไม่ | เรามุ่งเน้นที่วิธีใช้กลุ่มเป้าหมาย ไม่ใช่วิธีสร้างกลุ่มเป้าหมาย เรากำลังหารือแนวทางที่เป็นไปได้และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| การหมดอายุของคีย์เซิร์ฟเวอร์คีย์-ค่า | การพูดคุยเกี่ยวกับการนําคีย์เซิร์ฟเวอร์ออกเมื่อกลุ่มความสนใจที่เกี่ยวข้องหมดอายุ | เรากำลังหาวิธีจัดการการหมดอายุของคีย์และกำลังมองหาความคิดเห็น |
การวัดผลโฆษณาดิจิทัล
การรายงานการระบุแหล่งที่มา (และ API อื่นๆ)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การเข้าชมช่วงทดลองใช้จากต้นทาง | การเข้าชมช่วงทดลองใช้ต้นทางปัจจุบันไม่เพียงพอที่จะทำการทดสอบยูทิลิตี | การทดลองใช้ Origin ปัจจุบันมีไว้สำหรับผู้เล่นในระบบนิเวศเพื่อทำการทดสอบฟังก์ชันการทำงานเพื่อให้มั่นใจว่า API ทำงานได้ตามที่ต้องการ เราเข้าใจดีว่าจะต้องมีการเข้าชมจำนวนมากขึ้นเพื่อทำการทดสอบยูทิลิตีเมื่อการพัฒนา Privacy Sandbox API ต่างๆ ก้าวหน้ามากขึ้น ไทม์ไลน์การทดสอบปัจจุบันคาดการณ์ว่ากรณีการใช้งานนี้จะพร้อมใช้งานแบบทั่วไป (กล่าวคือเมื่อเทคโนโลยีสำหรับกรณีการใช้งานจะเปิดตัวและพร้อมให้บริการสำหรับการเข้าชม Chrome 100%) ในไตรมาสที่ 3 ปี 2023 (ดูไทม์ไลน์ล่าสุดใน privacysandbox.com) เรายินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับการทดสอบกรณีการใช้งานที่ต้องใช้การเข้าชมเพิ่มเติม |
| ฟังก์ชันการทำงานที่ทับซ้อนกันของ Privacy Sandbox Measurement API ต่างๆ | ข้อกังวลเกี่ยวกับการใช้วิธีการวัดผลหลายวิธีทับซ้อนกันผ่าน Privacy Sandbox จะทําให้เกิดความซับซ้อนมากขึ้น เช่น Attribution Reporting API และ Private Aggregation API | เรากําลังปรับปรุงเอกสารประกอบให้ดียิ่งขึ้นเพื่อชี้แจง Use Case ต่างๆ สําหรับ API และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับส่วนที่ไม่มีคำอธิบาย ตัวอย่างเช่น Attribution Reporting API มีไว้เพื่อรองรับการวัด Conversion โดยเฉพาะ ส่วน Private Aggregation API และพื้นที่เก็บข้อมูลที่ใช้ร่วมกันเป็น API อเนกประสงค์ที่มีไว้เพื่อรองรับ Use Case การวัดผลข้ามเว็บไซต์ที่หลากหลายมากขึ้น |
| ลองส่งคำขอรายงานที่ล้มเหลวอีกครั้ง | คำชี้แจงเกี่ยวกับจำนวนครั้งที่ระบบจะพยายามส่งคำขอรายงานหากส่งไม่สำเร็จ | เราได้เผยแพร่คําแนะนําเกี่ยวกับเรื่องนี้ กล่าวโดยสรุปคือ ระบบจะส่งรายงานเฉพาะเมื่อเบราว์เซอร์ทำงาน/ออนไลน์เท่านั้น หลังจากส่งไม่สําเร็จครั้งแรก ระบบจะพยายามส่งรายงานอีกครั้งหลังจากผ่านไป 5 นาที หลังจากครั้งที่ 2 ระบบจะพยายามส่งรายงานอีกครั้งหลังจากผ่านไป 15 นาที หลังจากนั้นระบบจะไม่ส่งรายงาน |
| ความล่าช้าในการรายงาน | ความล่าช้าในการรายงานที่คาดไว้คือเท่าใด | เราหวังว่าจะรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับความล่าช้าในการรายงานที่ผู้ใช้พบขณะที่เรารวบรวมข้อมูลเพื่อประเมินความล่าช้าเหล่านี้เพิ่มเติมไปพร้อมๆ กัน |
| แสดงผลหน้าเว็บล่วงหน้า | การระบุแหล่งที่มาของ ARA จะทํางานกับหน้าเว็บที่แสดงผลล่วงหน้าได้ไหม | ระบบจะเลื่อนการลงทะเบียนการระบุแหล่งที่มาในหน้าเว็บที่แสดงผลก่อนการประมวลผลจนกว่าจะเปิดใช้งาน (เกิดการคลิกหรือการดูจริง) ซึ่งหมายความว่าเราจะเลื่อนการ ping คำขอ `attributionsrc` |
| การวัด Conversion Lift | วิธีวัด Conversion Lift ด้วยการทดสอบ AB ในโดเมนเดียวกัน | เว็บไซต์สามารถวัด Conversion ที่เพิ่มขึ้นได้โดยใช้การทดสอบ A/B ในโดเมนเดียวกันผ่านการรายงานการระบุแหล่งที่มา โดยสามารถเข้ารหัสพารามิเตอร์ A/B เป็นคีย์ได้โดยใช้ API การรวมข้อมูล จากนั้นจะได้รับรายงานสรุปสำหรับมูลค่า Conversion ตามกลุ่มคีย์เหล่านั้น |
| (รายงานในไตรมาสที่ 3 ด้วย) Conversion ข้ามโดเมน | วิธีติดตาม Conversion ข้ามโดเมน เช่น มีปลายทาง 2 รายการขึ้นไป | ข้อมูลอัปเดตประจำไตรมาสที่ 4: เราได้เผยแพร่ข้อเสนอเพื่อนำข้อจำกัดปลายทางของหน้า Landing Page ออก ซึ่งจะช่วยให้ติดตามการสนทนาข้ามโดเมนได้ ติดตั้งใช้งานข้อเสนอนี้แล้ว |
| (รายงานในไตรมาสที่ 3 ด้วย) การตั้งค่าวันหมดอายุในรายงาน Conversion |
คำขอรับการสนับสนุนตัวกรองรายงาน / การหมดอายุในระยะเวลาไม่ถึง 24 ชั่วโมง | ข้อมูลอัปเดตประจำไตรมาสที่ 4: เราได้แชร์คำขอดึงข้อมูล นี้ซึ่งจะแยกกรอบเวลาหมดอายุกับการรายงานออกจากกันเพื่อลดการเสียเปรียบจากความล่าช้าในการรายงานเทียบกับกรอบเวลาหมดอายุของ Conversion ฟีเจอร์นี้เปิดตัวแล้วใน M110 |
| การประพฤติมิชอบและการละเมิด | คำขอจากผู้ลงโฆษณาและนักการตลาดที่ต้องการแบ่งกลุ่มและรวบรวมข้อมูลตามเว็บไซต์ของผู้เผยแพร่โฆษณาที่แสดงโฆษณา ซึ่งจะให้ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับแนวทางปฏิบัติด้านโฆษณาที่อาจเป็นการฉ้อโกง | เรากำลังพูดคุยเกี่ยวกับความคิดเห็นนี้อย่างจริงจังที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| (รายงานในไตรมาสที่ 3 ด้วย) ความล่าช้าในการรายงานระดับเหตุการณ์ | ความล่าช้า 2-30 วันในการรายงานระดับเหตุการณ์อาจนานเกินไปสําหรับบางกรณีการใช้งาน | การรายงานระดับเหตุการณ์มีกรอบเวลาการรายงานเริ่มต้น 2, 7 และ 30 วัน ซึ่งสามารถแก้ไขได้โดยใช้พารามิเตอร์ "expiry" เทคโนโลยีโฆษณาสามารถกําหนดค่าวันหมดอายุได้อย่างน้อย 1 วันเพื่อให้ได้รับรายงานที่เป็นไปได้ภายในเวลาไม่ถึง 2 วัน เราจำกัดความละเอียดของวันหมดอายุไว้ที่ 1 วันเพื่อเป็นกลไกการปกป้องความเป็นส่วนตัว เนื่องจากการรายงานที่ละเอียดยิ่งขึ้นอาจส่งผลให้เกิดการโจมตีตามเวลา นอกจากนี้ เรายังอนุญาตให้ตั้งค่าพารามิเตอร์ "วันหมดอายุ" อิสระสําหรับระดับเหตุการณ์และรายงานรวม โปรดดูที่นี่ นอกจากนี้ Google Ads จะไม่ได้รับการรายงานพิเศษที่เทคโนโลยีโฆษณาอื่นๆ ไม่ได้รับผ่าน Attribution Reporting API |
| ข้อกำหนดแหล่งที่มาของการรายงานเดียวกัน | คำขอให้นำข้อกำหนดที่ว่าต้นทางการลงทะเบียนแหล่งที่มาต้องเหมือนกับต้นทางการลงทะเบียน Conversion ออก | เราขอแนะนำให้ใช้การเปลี่ยนเส้นทาง HTTP เพื่อมอบสิทธิ์การลงทะเบียนเพื่อแก้ปัญหากรณีการใช้งานนี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับหลักเกณฑ์ใหม่ |
| เครื่องมือวัด Conversion | ต้องแยกแยะว่า Conversion เกิดขึ้นก่อน/หลังเวลาที่กำหนดโดยผู้ลงโฆษณา | Attribution Reporting API รองรับการตั้งค่ากรอบเวลาหมดอายุและลําดับความสําคัญสําหรับการระบุแหล่งที่มา เมื่อใช้ทั้ง 2 รายการ ในทางเทคนิคแล้ว คุณจะระบุแหล่งที่มาของ Conversion ที่เกิดขึ้นภายในกรอบเวลา X วันแยกจาก Conversion ที่เกิดขึ้นหลังจาก X ได้ |
| การจำลองเสียงรบกวน | ขอความสามารถในการจําลองปริมาณ Conversion ที่ต่างกันต่อกลุ่ม เพื่อทําความเข้าใจผลกระทบที่มีต่อผู้ลงโฆษณาที่มี Conversion น้อยกว่า | เรากำลังหาวิธีจำลองสิ่งนี้ในNoise Lab เวอร์ชันในอนาคต เรายินดีรับฟังความคิดเห็นเพิ่มเติม |
| การรายงานบนอุปกรณ์เคลื่อนที่ | ระบบจะยังคงส่งรายงานเมื่อ Chrome ทำงานอยู่เบื้องหลังบนอุปกรณ์เคลื่อนที่ไหม | ขณะนี้ ระบบจะไม่ส่งรายงานเมื่อ Chrome ทำงานอยู่เบื้องหลังแม้ในอุปกรณ์เคลื่อนที่ ซึ่งอาจเปลี่ยนแปลงเมื่อ API ผสานรวมกับ Privacy Sandbox ของ Android โปรดดูที่นี่ โปรดทราบว่า Privacy Sandbox ของ Android ไม่ได้เป็นส่วนหนึ่งของความมุ่งมั่นที่ CMA ยอมรับ |
| ความพร้อมใช้งานของข้อมูล | ข้อกังวลที่ว่า Google จะมีสิทธิ์เข้าถึงข้อมูลเพิ่มเติมผ่าน Privacy Sandbox API | ประการแรก Google Ads ไม่ได้รับสิทธิ์เข้าถึงข้อมูลจาก Attribution Reporting API หรือ Privacy Sandbox API อื่นๆ เป็นพิเศษ ปัญหานี้ยังได้รับการแก้ไขในส่วนความคิดเห็นทั่วไปในส่วน "ความสามารถในการทำงานร่วมกัน" ซึ่งมีรายละเอียดเพิ่มเติมเกี่ยวกับความมุ่งมั่นของ Google ประการที่ 2 เกี่ยวกับความแตกต่างระหว่างเว็บไซต์ขนาดใหญ่และขนาดเล็ก Google ตระหนักดีว่าการปกป้องความเป็นส่วนตัวตามสัญญาณรบกวนอาจส่งผลกระทบต่อข้อมูลส่วนเล็กๆ มากกว่า อย่างไรก็ตาม ปัญหานี้สามารถบรรเทาได้ เช่น วิธีการรวบรวมข้อมูลในระยะเวลาที่นานขึ้นจะช่วยแก้ปัญหานี้ได้ อย่างไรก็ตาม ยังคงไม่ชัดเจนว่าสรุปที่ได้จากข้อมูลส่วนเล็กๆ (เช่น การซื้อ 1-2 ครั้ง) มีประโยชน์ต่อผู้ลงโฆษณาหรือไม่ ในระหว่างการทดลองใช้เวอร์ชันต้นทาง Google ได้สนับสนุนให้ผู้ทดสอบใช้ประโยชน์จากการทดสอบพารามิเตอร์ความเป็นส่วนตัวและสัญญาณรบกวนอันหลากหลาย เพื่อให้สามารถแสดงความคิดเห็นที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับปัญหานี้ |
จำกัดการติดตามแอบแฝง
การลด User Agent
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| เลื่อนการลด User Agent จนกว่าระบบนิเวศของเว็บจะพร้อมใช้งานมากขึ้น | มีเวลาไม่เพียงพอที่จะปรับตัวให้เข้ากับการเปลี่ยนแปลงการลด User-Agent ที่กําลังจะเกิดขึ้น | เราได้จัดการความคิดเห็นนี้ในรายงานฉบับเต็มในส่วน "ข้อกังวลของผู้มีส่วนเกี่ยวข้อง" ของหัวข้อ "การโต้ตอบของ Google กับ CMA" |
| เลื่อนการลด User Agent ไว้จนกว่าระบบนิเวศของเว็บจะพร้อมใช้งานมากขึ้น | คำขอเลื่อนการเปิดตัวการลด User Agent จนกว่าจะมีการใช้ Structured User Agent (SUA) | ทีม Google Ads ได้เสนอการเพิ่ม User Agent ที่มีโครงสร้าง (ดูข้อกําหนด) ไปยัง OpenRTB ในเดือนตุลาคม 2021 และมีการรวมไว้ในการอัปเดตข้อกําหนด 2.6 ที่เผยแพร่ในเดือนเมษายน 2022 เรามีหลักฐานบางอย่างที่แสดงให้เห็นว่า SUA ใช้งานได้จริงในปัจจุบัน ดังที่แสดงในบล็อกโพสต์ของ Scientia Mobile ซึ่งสาธิตวิธีใช้ UA-CH และ WURFL API เพื่อสร้าง SUA |
###
คำแนะนำสำหรับไคลเอ็นต์ User Agent
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ทดสอบ UA-CH กับเทคนิคอื่นๆ ในการป้องกันการติดตามแบบปกปิด | คําแนะนําเกี่ยวกับวิธีทดสอบ Privacy Sandbox API ทั้งหมดและเทคนิคการระบุตัวตนโดยรวมที่เสนอร่วมกันในแนวทางแบบองค์รวม | แผนการทดสอบของเราออกแบบมาเพื่อแสดงลำดับเวลาที่ไม่ใช่แบบพร้อมกันสำหรับการพัฒนามาตรการป้องกันการจดจำลายนิ้วมือบางส่วน ซึ่งแตกต่างจากข้อเสนอ Sandbox ที่เหลือ แนวทางนี้พิจารณาถึงความเป็นจริงที่ว่ามาตรการป้องกันการติดแท็กผู้ใช้บางรายการ (เช่น งบประมาณความเป็นส่วนตัว การป้องกัน IP และการลดการติดตามการตีกลับ) จะพัฒนาเสร็จสมบูรณ์และพร้อมเปิดตัวสู่เวอร์ชันที่พร้อมให้บริการแก่ผู้ใช้ทั่วไปหลังจากเลิกใช้งานคุกกี้ของบุคคลที่สามเท่านั้น แม้ว่ามาตรการป้องกันการเก็บข้อมูลลายนิ้วมือดังกล่าวจะไม่รวมอยู่ในการทดสอบเชิงปริมาณ แต่มาตรการเหล่านี้จะได้รับการประเมินเชิงคุณภาพตามข้อเท็จจริงที่มีอยู่ ณ เวลาที่หยุดดำเนินการ |
| (รายงานในไตรมาสที่ 2 ด้วย) ประสิทธิภาพ |
ข้อกังวลเกี่ยวกับเวลาในการตอบสนองของการรับคำแนะนำผ่าน Critical-CH (ในการโหลดหน้าเว็บครั้งแรก) | ดูส่วน UA-CH โดยเฉพาะด้านล่าง |
| ความคิดเห็นไม่เพียงพอ | ความคิดเห็นจากระบบนิเวศเกี่ยวกับการเปลี่ยนแปลง UA-CH อาจไม่เพียงพอ จึงทำให้เกิดข้อกังวลเกี่ยวกับความไม่ตระหนักรู้จากระบบนิเวศ | เราแชร์แผนของเราอย่างสม่ำเสมอเพื่อให้แน่ใจว่าการเปิดตัวจะดำเนินอย่างรอบคอบและลดการหยุดชะงักให้น้อยที่สุด เราได้นำเสนอแผนการลด User Agent และ UA-CH API ต่อกลุ่มชุมชนป้องกันการประพฤติมิชอบของ W3C ในวันที่ 18 มีนาคม 2022 และต่อทั้งกลุ่มทำงานด้านการชำระเงินบนเว็บและกลุ่มที่มีความสนใจด้านความปลอดภัยของการชำระเงินบนเว็บในวันที่ 20 มกราคม 2022 ไม่มีการพูดถึงข้อกังวลที่สำคัญระหว่างหรือหลังการนำเสนอ Google ได้มีส่วนร่วมกับผู้ดำเนินการเว็บไซต์มากกว่า 100 รายเพื่อรับความคิดเห็น นอกจากนี้ Google ยังใช้ช่องทาง Blink-Dev เพื่อสื่อสารการเปิดตัวการลด User Agent กับสาธารณะโดยอิงตามความคิดเห็นจากผู้มีส่วนเกี่ยวข้องในระบบนิเวศ |
| ช่วงเวลา | ข้อกังวลเกี่ยวกับเวลาในการเปิดตัวและความพร้อมของอุตสาหกรรม | ดูส่วน UA-CH โดยเฉพาะด้านล่าง |
| สถานะแพลตฟอร์ม Chrome | ขอให้อัปเดตหน้า chromestatus สำหรับ UA-CH | รายการ chromestatus ได้รับการอัปเดตเป็น "สัญญาณที่หลากหลาย" ในวันที่ 19 ธันวาคม |
การปกป้อง IP (เดิมเรียกว่า Gnatcatcher)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| เลือกใช้หรือเลือกไม่ใช้ | ความเป็นส่วนตัวของที่อยู่ IP เป็นตัวเลือกให้เลือกใช้หรือไม่ใช้ | เป้าหมายของเราคือการปกป้องทรัพย์สินทางปัญญาให้แก่ผู้ใช้ทุกคน ด้วยเหตุนี้ เราจึงกำลังประเมินตัวเลือกต่างๆ เกี่ยวกับการคุ้มครองทรัพย์สินทางปัญญาแบบให้ผู้ใช้ตัดสินใจ |
| Use Case ของที่อยู่ IP สําหรับข้อมูลจากบุคคลที่หนึ่ง | สามารถใช้ที่อยู่ IP เพื่อต่อเส้นทางของผู้ใช้ในโดเมนของบุคคลที่หนึ่งหลังการปกป้อง IP ได้ไหม | ตามที่เผยแพร่ไปก่อนหน้านี้ ในช่วงแรกๆ การป้องกันทรัพย์สินทางปัญญาจะมุ่งเน้นที่การติดตามในบริบทของบุคคลที่สาม ซึ่งหมายความว่าโดเมนของบุคคลที่หนึ่งจะไม่ได้รับผลกระทบ |
| กรณีการใช้งานเทคโนโลยีโฆษณา | บริษัทต่างๆ จะตั้งค่ามาตรการป้องกันการประพฤติมิชอบด้วยการป้องกันทรัพย์สินทางปัญญาได้อย่างไร | เราตระหนักดีว่าที่อยู่ IP เป็นสัญญาณสําคัญในการต่อต้านการประพฤติมิชอบบนเว็บในปัจจุบัน ตามความมุ่งมั่นของเราต่อ CMA (ย่อหน้า 20) เราได้กล่าวว่าจะไม่ใช้การคุ้มครองทรัพย์สินทางปัญญาโดยไม่พยายามอย่างสมเหตุสมผลเพื่อสนับสนุนความสามารถของเว็บไซต์ในการดำเนินการต่อต้านสแปมและป้องกันการประพฤติมิชอบ หนึ่งในสิ่งสำคัญที่สุดของเราคือการทําความเข้าใจว่าการป้องกันทรัพย์สินทางปัญญาส่งผลต่อกรณีการใช้งานและความสามารถในการตรวจจับการประพฤติมิชอบอย่างไร เพื่อให้เราลงทุนในเทคโนโลยีการรักษาความเป็นส่วนตัวต่อไปได้ ซึ่งจะช่วยให้บริษัทต่างๆ รักษาความปลอดภัยของเว็บได้ เรายินดีรับฟังความคิดเห็นและข้อเสนอแนะเกี่ยวกับข้อเสนอใหม่ที่มุ่งตอบสนองความต้องการของบริษัทรักษาความปลอดภัยและป้องกันการประพฤติมิชอบ แม้ว่าสัญญาณจะเปลี่ยนแปลงไปเมื่อเวลาผ่านไป |
| การประพฤติมิชอบและการละเมิด | การปกป้อง IP มีการป้องกันการปฏิเสธการให้บริการ (DoS) ไหม | เรามุ่งมั่นที่จะปรับปรุงความเป็นส่วนตัวไปพร้อมกับการรักษาความปลอดภัยของเว็บ และการปกป้องจากการโจมตีแบบการปฏิเสธการให้บริการ (DoS) เป็นกรณีการใช้งานที่สำคัญในการป้องกันการละเมิดที่ควรออกแบบ เราหวังว่าจะลดผลกระทบต่อการป้องกัน DoS ให้ได้มากที่สุด ทั้งผ่านการออกแบบการปกป้อง IP เองและผ่านโซลูชันใหม่ในการป้องกันการละเมิด เนื่องจากในตอนแรก การปกป้องทรัพย์สินทางปัญญามุ่งเน้นที่บริการที่ฝังของบุคคลที่สาม ผู้มีส่วนเกี่ยวข้องบางรายจึงระบุว่าการปกป้องดังกล่าวควรมีผลกระทบเพียงเล็กน้อยต่อการป้องกัน DoS สำหรับเว็บไซต์ของบุคคลที่หนึ่ง อย่างไรก็ตาม เรายังคงขอความคิดเห็นจากสาธารณะเพื่อประเมินความเสี่ยงต่อกรณีการใช้งาน DoS โดยเฉพาะบริการที่ฝังของบุคคลที่สาม ในขณะเดียวกัน เรากำลังสำรวจกลไกการส่งความคิดเห็นเกี่ยวกับการละเมิดและการบล็อกไคลเอ็นต์ ซึ่งจะช่วยให้เว็บไซต์หรือบริการบล็อกผู้ใช้ที่ส่งสแปมได้โดยไม่ต้องระบุตัวตนผู้ใช้ |
| การกรองเนื้อหา | การกรองเนื้อหาด้วยการป้องกัน IP | บริษัทต่างๆ มีความต้องการที่แตกต่างกันเกี่ยวกับการกรองเนื้อหาและการปรับแต่งประสบการณ์ของผู้ใช้ ปัจจุบันกรณีการใช้งานจำนวนมากดังกล่าวไม่ได้ใช้ที่อยู่ IP และไม่ควรได้รับผลกระทบจากการปกป้อง IP ตัวอย่างเช่น ผู้เผยแพร่โฆษณาที่ต้องการปรับแต่งเนื้อหาและเพิ่มการมีส่วนร่วมอาจใช้คุกกี้ของบุคคลที่หนึ่งหรือคุกกี้ที่แบ่งพาร์ติชันของบุคคลที่สาม (CHIP) เพื่อทําความเข้าใจความสนใจของผู้ใช้และการโต้ตอบก่อนหน้านี้กับผู้เผยแพร่โฆษณา หรือพาร์ทเนอร์ด้านเทคโนโลยีโฆษณาที่มุ่งเน้นการแสดงโฆษณาที่เหมาะสมต่อผู้ใช้ที่เหมาะสมอาจใช้ FLEDGE และ Topics เพื่อแสดงผลลัพธ์ของโฆษณาที่คล้ายกับที่ใช้คุกกี้ของบุคคลที่สามหรือเทคโนโลยีการติดตามข้ามเว็บไซต์อื่นๆ ในปัจจุบัน นอกจากนี้ เรายังพยายามสร้างความสามารถใหม่ๆ ในการรักษาความเป็นส่วนตัวไว้ในการคุ้มครอง IP ด้วย เช่น ตำแหน่งทางภูมิศาสตร์แบบหยาบ เพื่อรองรับการกรองเนื้อหาเพิ่มเติมในกรณีที่กลไกที่มีอยู่อาจไม่เพียงพอ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับกรณีการใช้งานการกรองเนื้อหาที่อาจได้รับผลกระทบจากการคุ้มครองทรัพย์สินทางปัญญา |
| (รายงานในไตรมาสที่ 3 ด้วย) กรณีการใช้งานตําแหน่งทางภูมิศาสตร์ |
การคุ้มครอง IP อาจทําให้กรณีการใช้งานตําแหน่งทางภูมิศาสตร์ที่ถูกต้องใช้งานไม่ได้ในอนาคต เช่น การปรับเนื้อหาในแบบของคุณตามตําแหน่งทางภูมิศาสตร์ | ข้อมูลอัปเดตประจำไตรมาสที่ 4: เรากำลังทำงานร่วมกับผู้มีส่วนเกี่ยวข้องเพื่อให้มั่นใจว่า Chrome จะยังคงรองรับกรณีการใช้งานที่อยู่ IP ที่ถูกต้องต่อไป เราต้องการความคิดเห็นเกี่ยวกับระบบนิเวศของความละเอียดของตำแหน่งทางภูมิศาสตร์จาก IP ที่นี่ |
งบประมาณด้านความเป็นส่วนตัว
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| เอกสารประกอบที่ชัดเจนยิ่งขึ้น | ตัวอย่างเพิ่มเติมเพื่อให้ผู้มีส่วนเกี่ยวข้องคาดการณ์ได้ว่าระบบอาจจํากัดสิ่งต่างๆ อย่างไรเมื่อใช้งบประมาณด้านความเป็นส่วนตัว | ข้อเสนองบประมาณความเป็นส่วนตัวยังอยู่ระหว่างการหารือและยังไม่มีเบราว์เซอร์ใดนำมาใช้งาน วันที่เริ่มต้นของความพร้อมให้บริการแบบปรับขนาดแสดงถึงวันที่เริ่มต้นที่บังคับใช้งบประมาณความเป็นส่วนตัวได้ ซึ่งจะไม่เกิดขึ้นก่อนการนําคุกกี้ของบุคคลที่สามออกในปี 2024 เราไม่มีเอกสารประกอบเพิ่มเติมที่จะแชร์ในขณะนี้ เราจะแชร์รายละเอียดเพิ่มเติมเกี่ยวกับข้อเสนอเมื่อมีความชัดเจนมากขึ้น ในระหว่างนี้ เรายินดีให้ผู้มีส่วนเกี่ยวข้องแชร์ความคิดเห็นที่จะช่วยในการพัฒนาข้อเสนอ |
เพิ่มความเข้มงวดให้กับขอบเขตความเป็นส่วนตัวข้ามเว็บไซต์
ชุดโดเมนของบุคคลที่หนึ่ง
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| (รายงานในไตรมาสที่ 3 ด้วย) ขีดจํากัดโดเมน | คำขอเพิ่มจำนวนโดเมนที่เชื่อมโยง | ข้อมูลอัปเดตในไตรมาสที่ 4: เราได้เปิดตัว FPS สำหรับการทดสอบในเครื่อง ซึ่งรวมถึงกระบวนการส่งชุดข้อมูลจำลองใน GitHub และ Flag เพื่อทดสอบ rSA และ rSAFor ในเครื่อง นอกจากนี้ เรายังได้จัดการประชุมแบบเปิด 2 ครั้งสำหรับนักพัฒนาแอปเกี่ยวกับ FPS เพื่อตอบคำถามเกี่ยวกับกรณีการใช้งานของชุดย่อยที่เกี่ยวข้องต่อไป เราขอแนะนำให้นักพัฒนาแอปทดสอบฟังก์ชันการทำงานของ FPS เพื่อแสดงความคิดเห็นว่าขีดจำกัดโดเมนของชุดย่อยที่เกี่ยวข้องจะส่งผลต่อความสามารถในการใช้งาน FPS สำหรับกรณีการใช้งานอย่างไร เราได้ชี้แจงในการประชุม WICG ว่า Chrome มุ่งมั่นที่จะมอบโซลูชันที่ใช้งานได้ซึ่งคำนึงถึงสิทธิด้านความเป็นส่วนตัวของผู้ใช้ด้วย ด้วยเหตุนี้ เราจึงยินดีรับฟังความคิดเห็นจากชุมชนเกี่ยวกับกรณีการใช้งานที่เฉพาะเจาะจงซึ่งอาจได้รับผลกระทบจากขีดจำกัดของโดเมน เพื่อให้ทีมพิจารณาวิธีจัดการกับกรณีการใช้งานเหล่านี้ไปพร้อมกับการปกป้องความเป็นส่วนตัวของผู้ใช้ต่อไป |
| ขอรายละเอียดเพิ่มเติมเกี่ยวกับมาตรการบรรเทาปัญหาการละเมิด | จะเกิดอะไรขึ้นหากมีการเพิ่มโดเมนลงในชุดที่ผู้ใช้ไม่ได้ให้ความยินยอม | เราได้เผยแพร่หลักเกณฑ์การส่งชุดข้อมูลบุคคลที่หนึ่ง ที่นี่แล้วเมื่อวันที่ 2 ธันวาคม 2022 ดังที่อธิบายไว้ในหลักเกณฑ์การส่ง การจัดการการเปลี่ยนแปลงที่กำหนดจะเป็นไปตามและเคารพกระบวนการตรวจสอบใน GitHub ซึ่งรวมถึงการตรวจสอบการเป็นเจ้าของ ซึ่งควรช่วยลดความเสี่ยงนี้ |
| การลดการละเมิด | ข้อกังวลว่าอาจมีการใช้ชุดโดเมนของบุคคลที่หนึ่งในทางที่ผิด | เรากำลังหาวิธีขยายการตรวจสอบทางเทคนิคสำหรับประเภทชุดย่อยและกำลังมองหาข้อมูลจากชุมชนเพิ่มเติมที่นี่ |
| กรณีการใช้งานของโฆษณา | คำถามเกี่ยวกับการใช้ชุดของบุคคลที่หนึ่งเพื่อรองรับการกำหนดเป้าหมายโฆษณา | เราไม่ได้พยายามรองรับกรณีการใช้งานการกําหนดเป้าหมายของ Google Ads สําหรับชุดของบุคคลที่หนึ่ง และขอแนะนําให้ใช้ Ads API ที่มีให้สําหรับกรณีการใช้งานดังกล่าว |
| (รายงานในไตรมาสที่ 3 ด้วย) นโยบาย | ข้อกังวลว่า FPS ไม่สอดคล้องกับความมุ่งมั่นของ CMA เกี่ยวกับ "นิติบัญญัติคุ้มครองข้อมูลที่บังคับใช้" เนื่องจาก GDPR ไม่ได้จำกัดจำนวนเว็บไซต์ในชุด ขณะที่ FPS กำหนดให้จำกัดไว้ที่ 3 | คำตอบของเราไม่มีการเปลี่ยนแปลงจากไตรมาสที่ 3: "Google ยังคงมุ่งมั่นที่จะออกแบบและใช้งานข้อเสนอ Privacy Sandbox กับ CMA ในลักษณะที่ไม่บิดเบือนการแข่งขันด้วยการให้ความสำคัญกับธุรกิจของ Google เอง และพิจารณาผลกระทบต่อการแข่งขันในการโฆษณาดิจิทัล ผู้เผยแพร่โฆษณา และผู้ลงโฆษณา รวมถึงผลกระทบต่อผลลัพธ์ด้านความเป็นส่วนตัวและการปฏิบัติตามหลักการคุ้มครองข้อมูลตามที่ระบุไว้ในนิติบัญญัติคุ้มครองข้อมูลที่เกี่ยวข้อง ข้อกังวลที่แสดงไม่ได้เปิดเผยถึงความไม่เข้ากันได้กับ GDPR เรายังคงทำงานร่วมกับ CMA อย่างใกล้ชิดเพื่อให้มั่นใจว่าการดำเนินการของเราเป็นไปตามความมุ่งมั่นเหล่านี้" |
| ข้อเสนอทางเลือก | ชุดที่ตรวจสอบแล้วตาม GDPR | นอกเหนือจากความคิดเห็นที่ได้รับจากระบบนิเวศเกี่ยวกับข้อเสนอในการใช้ "ชุดที่ผ่านการตรวจสอบ GDPR" แล้ว Chrome ยังมีข้อกังวลเกี่ยวกับข้อจำกัดต่อไปนี้ของข้อเสนอทางเลือกนี้
นับตั้งแต่มีการเสนอทางเลือกนี้ Chrome ได้อัปเดตข้อเสนอชุดของบุคคลที่หนึ่งและเผยแพร่หลักเกณฑ์การส่งสำหรับการสร้างชุดใหม่ |
Fenced Frames API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ข้อจำกัดของเฟรมที่มีรั้วล้อมระหว่างช่วง OT | ข้อจำกัดปัจจุบันเกี่ยวกับเฟรมที่มีรั้วล้อมสำหรับระยะเวลาทดลองใช้ของ Origin คืออะไร | เรากําลังจัดทำเอกสารเกี่ยวกับข้อจํากัดและสถานะการใช้งาน และวางแผนที่จะแชร์เอกสารดังกล่าวในช่วงไตรมาสที่ 1 ปี 2023 |
| โฆษณาหลายรายการในเฟรมที่มีการกำหนดขอบเขตเดียว | คำขอแสดงผู้ลงโฆษณาหลายรายในกรอบที่กําหนดขอบเขตไว้ 1 รายการในการประมูล 1 ครั้ง | ปัจจุบันเราไม่ได้พัฒนาคำขอนี้ แต่ยินดีรับความคิดเห็นเพิ่มเติมหากผู้เข้าร่วมในระบบนิเวศเห็นว่าฟีเจอร์นี้สำคัญ |
| Web Bundle | ข้อกำหนดและการสนับสนุนที่วางแผนไว้สำหรับ Web Bundle ที่มีเฟรมที่มีรั้วล้อมคืออะไร | ขณะนี้เรายังไม่มีข้อมูลอัปเดตว่าข้อกำหนดนี้จะมีผลบังคับใช้ในอนาคตหรือไม่ เราจะประกาศการเปลี่ยนแปลงล่วงหน้าและจะไม่บังคับใช้การเปลี่ยนแปลงดังกล่าวก่อนการเลิกใช้งานคุกกี้ของบุคคลที่สาม โปรดดูสถานะปัจจุบันในคำอธิบายนี้ |
Shared Storage API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| พื้นที่เก็บข้อมูลที่ใช้ร่วมกันสําหรับเทคโนโลยีโฆษณา | ความไม่แน่นอนเกี่ยวกับการใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับ Use Case ของเทคโนโลยีโฆษณา | Shared Storage และ Private Aggregation API สามารถใช้เพื่อวัตถุประสงค์ในการวัดผลประเภทต่างๆ ที่ต้องวัดพื้นที่เก็บข้อมูลข้ามเว็บไซต์ ดูตัวอย่างได้ที่นี่ เราคาดการณ์ว่า DSP และผู้ให้บริการโซลูชันการวัดผลจะเป็นผู้ผสานรวมหลักสำหรับ Use Case ของโฆษณา |
CHIPs
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| (รายงานในไตรมาสที่ 3 ด้วย) ข้อกําหนดการแบ่งพาร์ติชัน | เพิ่มข้อกําหนดด้านลักษณะการทํางานที่ชัดเจนสําหรับแอตทริบิวต์ "แบ่งพาร์ติชัน" ในคุกกี้ของบุคคลที่หนึ่ง | ข้อมูลอัปเดตประจำไตรมาสที่ 4: หลังจากการพูดคุยใน GitHub และการโทรหา PrivacyCG ลักษณะการทำงานที่เราเห็นตรงกันคือคุกกี้ที่มีการแบ่งพาร์ติชันซึ่งตั้งค่าไว้ในคุกกี้ของบุคคลที่หนึ่งจะใช้คีย์พาร์ติชัน (A,A) โดยที่ "A" คือเว็บไซต์ระดับบนสุด เราจะบันทึกลักษณะการทำงานนี้ไว้ในคำอธิบายและข้อกำหนด |
| การจัดการคุกกี้ | มีเครื่องมือสําหรับจัดการ/ควบคุมคุกกี้ของบุคคลที่หนึ่งหรือบุคคลที่สามไหม | คุณใช้เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome และ NetLog เพื่อทดสอบเว็บไซต์ที่เปิดใช้การบล็อกคุกกี้ของบุคคลที่สามได้ เครื่องมือทั้ง 2 รายการจะรายงานเมื่อคุกกี้ถูกบล็อกเนื่องจากการกําหนดค่าของผู้ใช้ เรายินดีรับฟังความคิดเห็นเกี่ยวกับประเภทการตรวจสอบเพิ่มเติมที่เว็บไซต์ต้องการเห็น |
FedCM
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| IdP ต้องมีความรู้เกี่ยวกับ RP เพื่ออนุญาตให้ใช้เซสชัน | ปัญหาเมื่อผู้ใช้พยายามเข้าสู่ระบบ Feide IdP จาก RP 2 แห่งที่แตกต่างกัน | เรากำลังหารือเกี่ยวกับวิธีแก้ปัญหาที่เป็นไปได้สำหรับปัญหานี้ |
| ความสามารถในการทำงานร่วมกัน | ข้อกังวลเกี่ยวกับผลกระทบของ FedCM ต่อความสัมพันธ์ระหว่างผู้ใช้กับเว็บไซต์ที่เข้าสู่ระบบโดยใช้ FedCM และ "ความสามารถในการทำงานร่วมกัน" ของเว็บไซต์ต่างๆ | FedCM มีเป้าหมายที่จะรองรับบริการข้อมูลประจำตัวแบบรวมศูนย์ที่ปัจจุบันใช้คุกกี้ของบุคคลที่สามต่อไปเมื่อนำคุกกี้ของบุคคลที่สามออกจาก Chrome เราคาดว่า FedCM จะเป็นเพียงตัวเลือกเดียวสำหรับบริการดังกล่าว โดยผู้ให้บริการข้อมูลประจำตัว (IdP) และบุคคลที่เชื่อถือ (RP) สามารถใช้เทคโนโลยีอื่นๆ ที่อาจเหมาะกับความต้องการของตนมากกว่าได้ ดูเหมือนว่าข้อกังวลเกี่ยวกับความสัมพันธ์ระหว่างผู้ใช้กับ RP และ "ความสามารถในการทำงานร่วมกัน" นั้นเกิดจากความเข้าใจผิดเกี่ยวกับข้อเสนอ FedCM FedCM ปล่อยให้ IdP เป็นผู้ตัดสินใจว่าจะแชร์ข้อมูลใดกับ RP และแชร์ในรูปแบบใดเมื่อผู้ใช้เลือกลงชื่อเข้าใช้เว็บไซต์ของ RP นั้น FedCM ไม่ได้กำหนดให้ IdP "สร้างตัวระบุที่ไม่ระบุตัวบุคคลที่ไม่ซ้ำกันสำหรับ [RP] แต่ละรายที่ผู้ใช้ตรวจสอบสิทธิ์ด้วย" แต่ FedCM เปิดโอกาสให้ IdP แต่ละรายเลือกว่าจะแชร์ตัวระบุจริงของผู้ใช้ ตัวระบุเวอร์ชันต่อเว็บไซต์ หรือข้อมูลเวอร์ชันอื่นๆ หรือไม่ (ข้อกําหนดของ FedCM ระบุว่าการเชื่อมโยงข้ามเว็บไซต์เป็นความเสี่ยงด้านความเป็นส่วนตัวที่เชื่อมโยงกับ API และกล่าวถึงตัวระบุที่กําหนดเป้าหมาย (ต่อเว็บไซต์) ว่าเป็นวิธีบรรเทาที่เป็นไปได้ อย่างไรก็ตาม การตัดสินใจว่าจะใช้ตัวระบุที่กําหนดเป้าหมายหรือไม่นั้นขึ้นอยู่กับ IdP ไม่ใช่เบราว์เซอร์) นอกจากนี้ FedCM ยังให้ทางเลือกแก่ผู้ใช้เกี่ยวกับข้อมูลประจำตัวด้วย เช่น หากผู้ใช้มีข้อมูลประจำตัวหลายรายการที่มี IdP เดียวกัน (เช่น โปรไฟล์งานและโปรไฟล์ส่วนตัว) FedCM จะให้ผู้ใช้เลือกข้อมูลประจำตัวที่ต้องการใช้เพื่อเข้าสู่ระบบเว็บไซต์ของ RP นอกจากนี้ RP แต่ละรายจะเป็นผู้ตัดสินใจเองว่าจะรองรับ IdP ใดในเว็บไซต์ของตน ปัจจัยหนึ่งในการตัดสินคือการพิจารณากลไกที่ IdP อาศัย ไม่ว่าจะเป็น FedCM หรือเทคโนโลยีอื่น โปรดทราบว่าเบราว์เซอร์ไม่ได้กำหนดตัวเลือกเหล่านี้สำหรับ RP หรือ IdP |
ต่อสู้กับสแปมและการประพฤติมิชอบ
Private State Tokens API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การจัดการบ็อต | จะเกิดอะไรขึ้นหากผู้ออกโทเค็นพบว่ามีการออกโทเค็นสถานะส่วนตัวให้กับบ็อต | ผู้ออกโทเค็นควรหมุนเวียนคีย์ที่ใช้เพื่อลงนามในโทเค็นเป็นประจำเพื่อไม่ให้โทเค็นเก่าซึ่งออกภายใต้ตรรกะการออกโทเค็นที่อาจใช้งานไม่ได้หมดอายุ และเว็บไซต์แลกโทเค็นใหม่ด้วยตรรกะการออกโทเค็นที่อัปเดตแล้ว |
| การส่งแบบฟอร์มในเว็บไซต์เดียวกัน | สามารถใช้โทเค็นสถานะส่วนตัวสำหรับการส่งแบบฟอร์มในเว็บไซต์เดียวกันซึ่งเกี่ยวข้องกับการไปยังส่วนต่างๆ ของหน้าเว็บ (เช่น Content-Type: application/x-www-form-urlencoded) แทนคำขอจาก fetch/XMLHttpRequest API ได้ไหม | ขณะนี้โทเค็นสถานะส่วนตัวเวอร์ชันที่ 1 ไม่รองรับการดำเนินการนี้ เรายินดีรับฟังความคิดเห็นจากระบบนิเวศหากมีดีมานด์สูงสำหรับกรณีการใช้งานนี้ |
| การยืนยันฝั่งเซิร์ฟเวอร์ | คำถามเกี่ยวกับความสามารถในการยืนยันโทเค็นสถานะส่วนตัวฝั่งเซิร์ฟเวอร์ | โทเค็นจะแลกสิทธิ์กับผู้ออกโทเค็น จากนั้นผู้ออกโทเค็นจะสร้างบันทึกการแลกสิทธิ์ที่อาจมีโทเค็นเองหรือค่าที่ลงนามซึ่งมาจากโทเค็น เซิร์ฟเวอร์สามารถใช้บันทึกการแลกสิทธิ์ดังกล่าวเพื่อยืนยันความถูกต้องของโทเค็น และเราคาดว่าระบบนิเวศของผู้ออกโทเค็นแต่ละรายจะมีมาตรฐานที่แตกต่างกันสำหรับวิธีตีความบันทึกการแลกสิทธิ์ |