รายงานรายไตรมาสสำหรับไตรมาสที่ 2 ของปี 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 |
| ไทม์ไลน์ที่ชัดเจนยิ่งขึ้น | กำหนดการเปิดตัวเทคโนโลยี Privacy Sandbox ที่ชัดเจนและละเอียดยิ่งขึ้น | เราได้กำหนดแผนปัจจุบันสำหรับกำหนดการเปิดตัวไว้ใน privacysandbox.com และอัปเดตเป็นรายเดือน โดยพิจารณาจากเวลาในการพัฒนาสำหรับทั้งนักพัฒนา Chrome และนักพัฒนาเว็บ รวมถึงความคิดเห็นที่เราได้รับจากระบบนิเวศโดยรวมเกี่ยวกับเวลาที่จำเป็นในการทดสอบและใช้เทคโนโลยีใหม่ เทคโนโลยีแต่ละอย่างต้องผ่านขั้นตอนต่างๆ ตั้งแต่การทดสอบไปจนถึงการเผยแพร่ (เปิดตัว) และระยะเวลาของแต่ละขั้นตอนจะขึ้นอยู่กับสิ่งที่เราเรียนรู้และค้นพบในขั้นตอนก่อนหน้า แม้ว่าเราจะยังไม่ได้กำหนดเวลาเปิดตัวในตอนนี้ แต่เราจะอัปเดตไทม์ไลน์สาธารณะใน privacysandbox.com อย่างแน่นอน |
| ประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ | ข้อกังวลที่ว่าเทคโนโลยี Privacy Sandbox จะให้ประโยชน์แก่นักพัฒนาแอปรายใหญ่ และเว็บไซต์เฉพาะกลุ่ม (ขนาดเล็ก) จะให้ประโยชน์มากกว่าเว็บไซต์ทั่วไป (ขนาดใหญ่) | เราเข้าใจดีว่านักพัฒนาแอปบางรายมีข้อกังวลเกี่ยวกับผลกระทบของเทคโนโลยี Privacy Sandbox Google มุ่งมั่นที่จะไม่ออกแบบหรือนำข้อเสนอ Privacy Sandbox ไปใช้ในลักษณะที่บิดเบือนการแข่งขันด้วยการเข้าข้างธุรกิจของตนเอง และพิจารณาผลกระทบต่อการแข่งขันในการโฆษณาดิจิทัล รวมถึงผู้เผยแพร่โฆษณาและผู้ลงโฆษณา ตลอดจนผลกระทบต่อผลลัพธ์ด้านความเป็นส่วนตัวและประสบการณ์ของผู้ใช้ เรายังคงทำงานร่วมกับ CMA อย่างใกล้ชิดเพื่อให้มั่นใจว่าการดำเนินการของเราเป็นไปตามความมุ่งมั่นเหล่านี้
ในระหว่างการทดสอบ Privacy Sandbox คำถามสำคัญอย่างหนึ่งที่เราประเมินคือประสิทธิภาพของเทคโนโลยีใหม่สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ ความคิดเห็นมีความสำคัญอย่างยิ่งในเรื่องนี้ โดยเฉพาะความคิดเห็นที่เฉพาะเจาะจงและนำไปใช้ได้จริง ซึ่งจะช่วยให้เราปรับปรุงการออกแบบทางเทคนิคให้ดียิ่งขึ้นได้ |
| ไทม์ไลน์การเลิกใช้งานคุกกี้ของบุคคลที่สาม | คำขอเพื่อหลีกเลี่ยงความล่าช้าเพิ่มเติมสำหรับการเลิกใช้งานคุกกี้ของบุคคลที่สาม | เราได้ยินจากผู้มีส่วนเกี่ยวข้องบางรายที่ต้องการให้ Chrome เลิกใช้งานคุกกี้ของบุคคลที่สามโดยทันที และได้ยินจากผู้มีส่วนเกี่ยวข้องรายอื่นๆ ที่เชื่อว่าต้องใช้เวลาเพิ่มเติมในการทดสอบและนำเทคโนโลยี Privacy Sandbox มาใช้ เรามุ่งมั่นที่จะดำเนินการอย่างมีความรับผิดชอบเนื่องจากความซับซ้อนของเทคโนโลยีและความสำคัญของการทําให้ระบบนิเวศทำงานได้อย่างถูกต้อง ความคิดเห็นจากอุตสาหกรรมและหน่วยงานกำกับดูแลมีความสำคัญอย่างยิ่งต่อกระบวนการนี้ |
| ไทม์ไลน์การเลิกใช้งานคุกกี้ของบุคคลที่สาม | คำขอเลื่อนการเลิกใช้งานคุกกี้ของบุคคลที่สามและขอเวลาเพิ่มเติมในการทดสอบ API | เราได้ยินจากผู้มีส่วนเกี่ยวข้องบางรายที่ต้องการให้ Chrome เลิกใช้งานคุกกี้ของบุคคลที่สามโดยทันที และได้ยินจากผู้มีส่วนเกี่ยวข้องรายอื่นๆ ที่เชื่อว่าต้องใช้เวลาเพิ่มเติมในการทดสอบและนำเทคโนโลยี Privacy Sandbox มาใช้ เรามุ่งมั่นที่จะดำเนินการอย่างมีความรับผิดชอบเนื่องจากความซับซ้อนของเทคโนโลยีและความสำคัญของการทําให้ระบบนิเวศทำงานได้อย่างถูกต้อง ความคิดเห็นจากอุตสาหกรรมและหน่วยงานกำกับดูแลมีความสำคัญอย่างยิ่งต่อกระบวนการนี้ |
| คำขอเอกสารประกอบ | ขอแหล่งข้อมูลเพิ่มเติมที่อธิบายวิธีจัดการการทดสอบ การวิเคราะห์ และการใช้งาน | เรายินดีที่นักพัฒนาแอปพบว่าเนื้อหาปัจจุบันของเรามีประโยชน์ และเรามุ่งมั่นที่จะให้เนื้อหาเพิ่มเติม รวมถึงเวลาทำการของนักพัฒนาแอปและเอกสารทางเทคนิคในอีกไม่กี่สัปดาห์และเดือนข้างหน้า เพื่อให้นักพัฒนาแอปเข้าใจต่อไปว่าเทคโนโลยีใหม่นี้จะช่วยพวกเขาได้อย่างไร
นอกจากนี้ เรายังจัดเซสชัน "เวลาทําการ" สาธารณะสําหรับนักพัฒนาแอปภายนอกเพื่อแชร์แนวทางปฏิบัติแนะนำและการสาธิต รวมถึงจัดเซสชันถามและตอบกับหัวหน้าทีมผลิตภัณฑ์และวิศวกรเพื่อให้สามารถพูดคุย/ถามคำถามได้แบบเรียลไทม์ |
| ความเชี่ยวชาญในอุตสาหกรรม | ทีม Chrome ที่มีส่วนร่วมกับหน่วยงานมาตรฐานขาดความเชี่ยวชาญในระบบนิเวศโฆษณาที่จําเป็นต่อการปรับสมดุลความเป็นส่วนตัวและประโยชน์อย่างเหมาะสม | เราตระหนักดีว่าตนมีหน้าที่รับผิดชอบอันยิ่งใหญ่ และเราต้องการความคิดเห็นที่เฉพาะเจาะจงเพื่อให้ดำเนินการนี้ได้อย่างถูกต้อง นอกจากนี้ เรายังถือว่าทั้งความเป็นส่วนตัวและประสิทธิภาพเป็นเกณฑ์การออกแบบที่สำคัญและจำเป็น ทีมที่ทํางานเกี่ยวกับ Privacy Sandbox สําหรับเว็บมีจํานวนปีรวมในระบบนิเวศโฆษณาหลายร้อยปี |
แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง
หัวข้อ
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| ประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ | มีข้อกังวลเกี่ยวกับคุณค่าที่สร้างขึ้นและการกระจายคุณค่านั้นให้กับเว็บไซต์ต่างๆ โดยขึ้นอยู่กับระดับการเข้าชมหรือความเชี่ยวชาญของเนื้อหา | เราจะทดสอบความเป็นประโยชน์ของ API Chrome คาดว่าการจัดหมวดหมู่และพารามิเตอร์อื่นๆ จะพัฒนาตามผลการทดสอบ การพัฒนาการจัดหมวดหมู่หรือพารามิเตอร์อาจไม่จําเป็นต้องเปลี่ยนแปลงในลักษณะที่ไม่เข้ากันได้แบบย้อนหลัง นอกจากนี้ Chrome ยังคาดหวังว่าความคิดเห็นจะส่งผลต่อการพัฒนา Topics API ต่อไปหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
| การจัดหมวดหมู่ | ผู้มีส่วนเกี่ยวข้องในอุตสาหกรรมต้องการมีสิทธิ์มีเสียงในการกำหนดการจัดหมวดหมู่ | Chrome ยังคงเปิดรับข้อมูลเกี่ยวกับการจัดหมวดหมู่ Chrome ต้องการความคิดเห็นเกี่ยวกับรูปแบบการกํากับดูแลสำหรับการแก้ไขการจัดหมวดหมู่ และต้องการพูดคุยเกี่ยวกับวิธีที่หน่วยงานอื่นๆ ในอุตสาหกรรมสามารถมีบทบาทที่มากขึ้นในการพัฒนาและดูแลการจัดหมวดหมู่ในระยะยาว |
| ประวัติการท่องเว็บไม่เพียงพอ | คำแนะนำในการแสดงหัวข้อที่ผู้โทรเคยเห็นในสัปดาห์ก่อนหน้า หากผู้ใช้มีประวัติการท่องเว็บไม่เพียงพอที่จะสร้างหัวข้อ 5 หัวข้อสำหรับสัปดาห์ล่าสุด | สำหรับการออกแบบปัจจุบัน ระบบจะสุ่มเลือก เราจะตรวจสอบความสัมพันธ์กับหัวข้อที่ผ่านมาและพิจารณาว่ามีความเป็นไปได้ที่จะรวมหัวข้อนี้หรือไม่ อย่างไรก็ตาม ความสัมพันธ์ดังกล่าวอาจต้องพิจารณาถึงผลกระทบด้านความเป็นส่วนตัวที่อาจเกิดขึ้นด้วย |
| การเรียกใช้ Topics ในนามของผู้เผยแพร่โฆษณา | ผู้ให้บริการบุคคลที่สามแชร์ Topics กับผู้เผยแพร่โฆษณาได้ไหม | ใช่ นั่นคือวิธีที่เราคาดหวังให้ใช้ Topics |
| เวกเตอร์การโจมตีที่เป็นไปได้ | การระบุหัวข้อที่มีเสียงรบกวน | Chrome เลือกที่จะกรองหัวข้อและเพิ่มสัญญาณรบกวนตามความคิดเห็นจากผู้ใช้จำนวนมากในระบบนิเวศ การตัดสินใจเหล่านี้เกิดขึ้นโดยคำนึงถึงความเป็นส่วนตัว เพื่อจำกัดการเข้าถึงข้อมูลไว้เฉพาะผู้ที่ไม่ควรมีสิทธิ์เข้าถึงข้อมูลดังกล่าว และเพื่อเปิดโอกาสให้ผู้ใช้ปฏิเสธได้ เราตระหนักดีว่าการตัดสินใจดังกล่าวมีข้อเสีย เช่น เวกเตอร์การโจมตีที่ระบุไว้ที่นี่ อย่างไรก็ตาม เราประเมินว่าประโยชน์ด้านความเป็นส่วนตัวมีมากกว่าความเสี่ยงที่อาจเกิดขึ้น เรายินดีรับฟังความคิดเห็นสาธารณะเกี่ยวกับเรื่องนี้ |
| การมีสิทธิ์ทดลองใช้จากต้นทาง | มีวิธีตรวจสอบว่าผู้ใช้มีสิทธิ์ทดลองใช้ Origin หรือไม่ | ผู้ใช้อาจใช้ฟีเจอร์ช่วงทดลองใช้ของต้นทางไม่ได้เนื่องจากการตั้งค่าเบราว์เซอร์หรือปัจจัยอื่นๆ แม้ว่าผู้ใช้จะเข้าชมหน้าเว็บที่มีโทเค็นช่วงทดลองใช้ที่ถูกต้องและเบราว์เซอร์ของผู้ใช้อยู่ในกลุ่มที่เปิดใช้ช่วงทดลองใช้ก็ตาม
ด้วยเหตุนี้ คุณจึงควรใช้การตรวจหาฟีเจอร์เสมอเพื่อตรวจสอบว่าฟีเจอร์การทดลองใช้เวอร์ชันต้นทางพร้อมใช้งานหรือไม่ก่อนที่จะพยายามใช้ |
| ผลกระทบต่อประสิทธิภาพ | ข้อกังวลเกี่ยวกับเวลาในการตอบสนองและค่าใช้จ่ายเพิ่มเติมของ Topics | เรากำลังขอความคิดเห็นเกี่ยวกับแนวทางในการหลีกเลี่ยงการใช้ iframe ต้นทาง x ที่ช้าและมีค่าใช้จ่ายสูง และเกี่ยวกับข้อเสนอในการแยก Topics API ออกเพื่อให้การเรียกข้อมูล Topics ไม่ได้เปลี่ยนสถานะการท่องเว็บ |
| แยกฟังก์ชันการทํางานของ Topics API | มอบการควบคุมที่มากขึ้นในด้านต่างๆ 3 ด้านของ API | เราเข้าใจกรณีการใช้งานและได้เสนอวิธีแก้ปัญหาที่เป็นไปได้ภายใน GitHub ขณะนี้เรากำลังรอความคิดเห็นเพิ่มเติมจากระบบนิเวศเพื่อพิจารณาว่าจะสร้างฟังก์ชันนี้หรือไม่ ดูการสนทนาที่กำลังดำเนินอยู่ได้ที่นี่ |
| ไทม์ไลน์และเอกสารประกอบเกี่ยวกับตัวจัดประเภท | นักพัฒนาแอปได้ขอข้อมูลเพิ่มเติมเกี่ยวกับตัวจัดประเภท | เราได้เผยแพร่ข้อมูลเพิ่มเติมเกี่ยวกับตัวจัดประเภทที่นี่
และที่นี่ และที่นี่ |
| การควบคุมและความปลอดภัยของผู้ใช้ | หัวข้อบางอย่างอาจเป็นพร็อกซีสําหรับกลุ่มที่มีความละเอียดอ่อน และผู้ใช้จําเป็นต้องมีการควบคุมเพิ่มเติมเพื่อป้องกันผลลัพธ์เชิงลบ | หัวข้อเป็นก้าวสำคัญในการพัฒนาการควบคุมและความโปร่งใสของผู้ใช้ ผู้ใช้จะเลือกไม่ใช้หัวข้อ ตรวจสอบหัวข้อที่กำหนดให้ ลบหัวข้อ และดูว่าบริษัทใดโต้ตอบกับหัวข้อของตนในหน้าหนึ่งๆ ได้ นอกจากนี้ ผู้ใช้ยังส่งผลต่อ Topics ได้ด้วยโดยการลบประวัติการท่องเว็บ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับการควบคุมขั้นสูงของผู้ใช้ เช่น การควบคุมที่นักพัฒนาแอปแนะนำ แต่เราต้องตรวจสอบว่าข้อกังวลที่แจ้งมาเกี่ยวกับข้อบกพร่องนี้ช่วยขจัดความเสี่ยงได้จริง (เช่น การนําหัวข้อ "การศึกษาภาษาต่างประเทศ" ออกเพียงหัวข้อเดียว แต่ไม่ได้นําเว็บไซต์ที่สร้างหัวข้อนั้นจากประวัติการท่องเว็บออก ไม่ได้ช่วยปกป้องผู้ใช้อย่างเต็มรูปแบบ) |
| การใช้หัวข้อในเว็บไซต์ที่มี prebid.js | Topics API ใช้กับเว็บไซต์ที่มี prebid.js ได้ไหม | คำตอบสั้นๆ คือ ได้ ดูข้อมูลเพิ่มเติมได้ที่นี่ |
| การใช้ Topics API ในวิดเจ็ตคําแนะนํา | เราใช้ Topics API ในวิดเจ็ตแนะนําได้ไหม (เช่น Outbrain) | เราไม่จำกัดกรณีการใช้งานของ Topics ที่ดึงข้อมูลมาหลังจากเรียกใช้ API (ซึ่งจะขึ้นอยู่กับนโยบายข้อมูลของนักพัฒนาแอปแต่ละราย) |
| ความเป็นส่วนตัว / นโยบาย | คำถามเกี่ยวกับวัตถุประสงค์ในการกรองคำตอบตามผู้โทร หากบุคคลที่สามบางรายจะแชร์หัวข้อกับทุกคนที่โทรเข้ามา | Chrome เลือกใช้การออกแบบนี้เพื่อจำกัดการเข้าถึงข้อมูลไว้เฉพาะผู้ที่ไม่ควรเข้าถึงข้อมูลดังกล่าว โดยอิงตามความคิดเห็นจากผู้ใช้จำนวนมากในระบบนิเวศ แน่นอนว่าผู้เผยแพร่โฆษณาและบุคคลที่สามที่ได้รับ Topics จะตัดสินใจเองได้ว่าต้องการแชร์ข้อมูลใดกับบุคคลในเว็บไซต์ของตน หากมีการแชร์ประเภทนี้ Chrome ขอแนะนำให้แอปแสดงความโปร่งใสต่อผู้ใช้เกี่ยวกับการแชร์ดังกล่าวและมอบการควบคุมให้แก่ผู้ใช้ |
| สัญญาณที่มีเสียงรบกวน | การแสดงหัวข้อแบบสุ่ม 5% ของเวลาอาจทำให้เกิดสัญญาณรบกวน / สัญญาณที่ไม่ถูกต้องมากเกินไป | ระดับการสร้างความสับสนเป็นวิธีการที่สําคัญในการปกป้องความเป็นส่วนตัวของผู้ใช้ และเราจะทดสอบระดับการสร้างความสับสนเทียบกับประโยชน์ของหัวข้อ |
FLEDGE
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| การประสานงานการทดสอบ | การทดสอบผลกระทบต่อประสิทธิภาพและรายได้ | ประสิทธิภาพของ FLEDGE และวิธีที่เราจะให้การสนับสนุนการทดสอบระบบนิเวศที่ดีที่สุดในระหว่างช่วงทดลองใช้ Origin และช่วงเปิดตัวแก่ผู้ใช้ทั่วไปกำลังได้รับการพูดคุยอย่างสม่ำเสมอในการประชุม WICG แบบสาธารณะ |
| เซิร์ฟเวอร์ที่เชื่อถือสําหรับ FLEDGE | เซิร์ฟเวอร์ที่เชื่อถือได้จะพร้อมให้ทดสอบเมื่อใด | ขอขอบคุณสำหรับความคิดเห็นนี้ เรากําลังดําเนินการตามแผนโดยละเอียดมากขึ้นเพื่อแชร์การใช้งานเซิร์ฟเวอร์ที่เชื่อถือได้ใน FLEDGE |
| มาตรฐานโปรโตคอล | จะมีโปรโตคอลทั่วไปสำหรับการส่งข้อมูลระหว่าง SSP กับ DSP ไหม เช่น ป้ายกำกับทั่วไปสำหรับกลุ่มความสนใจ | เรายินดีรับฟังความคิดเห็นจาก DSP, SSP และระบบนิเวศโฆษณาในวงกว้างเกี่ยวกับความเป็นไปได้ในการทำให้ข้อกําหนดเป็นมาตรฐานเดียวกัน เพื่อการทดสอบขั้นต้นในขณะนี้ เราขอแนะนําให้ทํางานร่วมกับพาร์ทเนอร์การทดสอบโดยตรง เนื่องจากพาร์ทเนอร์เหล่านี้กําลังทดลองแนวทางต่างๆ นอกจากนี้ เรายังสนับสนุนและวางแผนที่จะทำงานร่วมกับองค์กรการค้าโฆษณาต่อไปเพื่อหาทางสร้างมาตรฐานในกรณีที่เป็นประโยชน์ต่อบริษัทสมาชิก |
| การกำหนดความถี่สูงสุด | การควบคุมความถี่ต่อผู้ใช้ภายในแคมเปญและกลุ่มโฆษณา | FLEDGE จะรองรับการกำหนดความถี่สูงสุดสำหรับการประมูลในอุปกรณ์และแคมเปญตามบริบท / การสร้างแบรนด์ด้วย นอกจากนี้ คุณยังใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันและขีดจํากัดเฉพาะเว็บไซต์เพื่อควบคุมการกําหนดความถี่สูงสุดเพิ่มเติมได้ด้วย |
| ผลกระทบของ FLEDGE ต่อประสิทธิภาพ | ผู้เสนอราคาที่ต้องใช้การประมวลผลอย่างหนักในการประมูล FLEDGE | Chrome กำลังหารือกับนักพัฒนาซอฟต์แวร์เกี่ยวกับผลกระทบที่อาจเกิดขึ้นกับประสิทธิภาพของเว็บไซต์ Chrome ยินดีรับฟังความคิดเห็นเพิ่มเติมระหว่างการทดสอบ |
| การทดสอบ FLEDGE กับฟีเจอร์อื่นๆ | รายงานระดับเหตุการณ์จาก Attribution Reporting API และ FLEDGE จะทำงานร่วมกันได้อย่างไร | เรื่องนี้ได้ถูกพูดถึงในการเรียก WICG/conversion-measurement-api เมื่อเร็วๆ นี้ โดยมีลิงก์ไปยังรายงานการประชุมแบบละเอียดที่นี่
สรุปการประชุมคือการออกแบบปัจจุบันสําหรับการรายงานโฆษณาเฟรมที่มีการกำหนดเขตช่วยให้เชื่อมโยงรหัสที่สร้างขึ้นภายในเฟรมที่มีการกำหนดเขตกับข้อมูลตามบริบทได้ ดังนั้นรายงานระดับเหตุการณ์ที่สร้างขึ้นภายในกรอบที่กั้นไว้จะเข้าร่วมกับข้อมูลตามบริบทเดียวกันบนเซิร์ฟเวอร์ได้ (โดยใช้การเข้าร่วมฝั่งเซิร์ฟเวอร์ 2 ครั้งแทน 1 ครั้ง) |
| การนับการแสดงผล | วิธีการนับการแสดงผลที่ควรหรืออาจใช้ระหว่างผู้ซื้อและผู้ขาย | FLEDGE API รองรับการปรับวิธีการระหว่างผู้ขายกับผู้ซื้อระหว่างการประมูลอยู่แล้ว เราได้รับคำแนะนำเกี่ยวกับการใช้งานระบบอื่นโดยไม่มีความคิดเห็นว่าเหตุใดการออกแบบปัจจุบันจึงใช้ไม่ได้กับระบบนิเวศ |
| การแสดงโฆษณาหลายรายการ | ผู้ใช้สามารถแสดงโฆษณาหลายรายการในการประมูลครั้งเดียวในเฟรมที่กำหนดไว้หรือไม่ | ซึ่งปัจจุบันทำได้ผ่านโฆษณาคอมโพเนนต์ (โปรดอย่าสับสนกับการประมูลคอมโพเนนต์) ซึ่งโฆษณาทั้งหมดต้องอยู่ในกลุ่มความสนใจเดียวกัน |
| ข้อกําหนดของ "กลุ่มเป้าหมายที่กําหนดโดยผู้ขาย (SDA)" และ FLEDGE | FLEDGE อาจเป็นกลไกที่ป้องกันไม่ให้ผู้ซื้อสร้างโปรไฟล์จาก SDA ในคําขอโฆษณาได้ไหม | FLEDGE ออกแบบมาเพื่อหลีกเลี่ยงการรั่วไหลของข้อมูลที่ไม่เกี่ยวข้องเมื่อผู้เผยแพร่โฆษณาทราบอยู่แล้วว่าผู้เข้าชมอยู่ใน SDA ใดและการกำหนดเป้าหมายเป็นเว็บไซต์เดียวกัน หากจำเป็นต้องรองรับการซื้อใน SDA ภายในการป้องกันทั้งหมดที่สร้างไว้ใน FLEDGE ทางออกหนึ่งอาจเป็นให้ผู้ขายส่งป้ายกํากับ SDA ไปยังการประมูลในอุปกรณ์ และให้เทคโนโลยีโฆษณาฝั่งซื้อสร้างกลุ่มความสนใจของตนเองซึ่งมีตรรกะการเสนอราคาที่ระบุว่า "ฉันต้องการซื้อกลุ่มเป้าหมาย X" |
| การรองรับสกุลเงินนอกเหนือจาก USD | การรองรับการทดสอบ FLEDGE กับสกุลเงินอื่นๆ นอกเหนือจาก USD | ขอขอบคุณสำหรับข้อความไฮไลต์นี้และเราได้เพิ่มการรองรับสกุลเงินอื่นๆ ไว้ในคิวคำขอฟีเจอร์ที่รอดำเนินการ เราหวังว่าฟีเจอร์นี้จะพร้อมให้บริการในเร็วๆ นี้ |
| การรองรับการกำหนดเป้าหมายกลุ่มความสนใจเชิงลบ | API ที่รองรับการกำหนดเป้าหมาย IG เชิงลบ: แสดงโฆษณาเฉพาะในกรณีที่ผู้ใช้ไม่ได้อยู่ใน IG | การพูดคุยอย่างต่อเนื่อง รวมถึงตัวเลือกที่เสนอเพื่อรองรับในปัญหา GitHub |
| SSP หลายรายการใน FLEDGE | ความเสี่ยงของการเอื้อประโยชน์ให้ Google เมื่อใช้การประมูลหลายระดับใน FLEDGE | เราได้เพิ่มการรองรับ SSP หลายรายการใน FLEDGE เพื่อให้การแข่งขันเป็นไปอย่างยุติธรรม Google ได้สัญญาภายใต้ความมุ่งมั่นว่าจะไม่ออกแบบ พัฒนา หรือใช้งานข้อเสนอ Privacy Sandbox ในลักษณะที่จะบิดเบือนการแข่งขันด้วยการเข้าข้างผลิตภัณฑ์และบริการโฆษณาของตนเอง Google ให้ความสำคัญกับเรื่องนี้เป็นอย่างมาก และพร้อมที่จะพูดคุยเกี่ยวกับข้อกังวลต่างๆ ที่นักลงทุนอาจมีเกี่ยวกับแง่มุมที่เฉพาะเจาะจงของเทคโนโลยี โปรดทราบว่า Chrome ได้เผยแพร่เอกสารประกอบเกี่ยวกับกลไกการประมูลคอมโพเนนต์ไว้ที่นี่ |
การวัดผลโฆษณาดิจิทัล
การรายงานการระบุแหล่งที่มา (และ API อื่นๆ)
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| การระบุแหล่งที่มาแบบมัลติทัช | ผู้เผยแพร่โฆษณาที่ขอรับการสนับสนุนสําหรับการระบุแหล่งที่มาแบบมัลติทัช | วิธีการระบุแหล่งที่มาแบบหลายทัชพอยต์ในปัจจุบันจําเป็นต้องเชื่อมโยงการแสดงผลของผู้ใช้ (และตัวตนของผู้ใช้) ในเว็บไซต์ต่างๆ เข้าด้วยกันอย่างแน่ชัด ด้วยเหตุนี้ ฟังก์ชันการทำงานในรูปแบบปัจจุบันจึงไม่ได้สอดคล้องกับเป้าหมายของ Privacy Sandbox ซึ่งมีไว้เพื่อรองรับกรณีการใช้งานโฆษณาหลักโดยไม่ต้องมีการติดตามข้ามเว็บไซต์ ในบางกรณี การกำหนดเครดิตโดยประมาณ (เช่น โดยใช้ลำดับความสำคัญแบบสุ่มที่มีน้ำหนัก) สามารถทำได้โดยไม่ต้องติดตามผู้ใช้แต่ละราย |
| การสร้างเสียงรบกวน | คําถามเกี่ยวกับระดับของสัญญาณรบกวนภายในรายงาน | การทดสอบครั้งแรกของเราช่วยให้นักพัฒนาแอปสามารถกําหนดค่า epsilon ของตนเองเพื่อให้เห็นการเปลี่ยนแปลงของรายงานตามระดับของสัญญาณรบกวน ปัจจุบันนักพัฒนาแอปสามารถเลือกค่า epsilon ได้สูงสุดที่ epsilon=64 เราทําเช่นนี้โดยเฉพาะเพื่อให้นักพัฒนาแอปทดสอบ API และแสดงความคิดเห็นเกี่ยวกับค่า epsilon ที่เหมาะสมได้ง่ายขึ้น
นอกจากนี้ เรายังได้ส่งคำขอแบบสาธารณะเพื่อขอความคิดเห็นดังกล่าวด้วย |
| การประสานงานการทดสอบ | ใช้เครื่องมือทดสอบในเครื่องสําหรับ OT ได้ไหม | ได้ เครื่องมือทดสอบในเครื่องใช้ได้ตลอดระยะเวลาของ OT เครื่องมือทดสอบในเครื่องสามารถใช้กับรายงานข้อบกพร่องได้ ตราบใดที่มีคุกกี้ของบุคคลที่สาม |
| หลักสรีรศาสตร์ของการค้นหา | เปิดใช้การค้นหาผลรวมของคีย์ | เราเห็นด้วยว่าการดำเนินการนี้ดูเหมือนจะช่วยปรับปรุงการยศาสตร์ของ API โดยแทบไม่เสียค่าใช้จ่ายด้านความเป็นส่วนตัว เราจะเสนอแนวคิดนี้และดูว่ามีความเห็นพ้องกันโดยทั่วไปว่าควรสนับสนุนหรือไม่ |
| ข้อมูลที่มีความแม่นยำน้อยกว่าสําหรับเว็บไซต์ขนาดเล็ก | เว็บไซต์หรือแคมเปญขนาดเล็กอาจได้รับข้อมูลที่แม่นยำน้อยกว่า | Chrome ตระหนักดีว่าการคุ้มครองความเป็นส่วนตัวตามสัญญาณรบกวนจะส่งผลต่อข้อมูลส่วนเล็กๆ มากกว่า อย่างไรก็ตาม วิธีการต่างๆ เช่น การรวบรวมข้อมูลเป็นระยะเวลานานขึ้นอาจช่วยแก้ปัญหานี้ได้ และยังไม่แน่ชัดว่าสรุปที่ได้จากข้อมูลส่วนเล็กๆ (เช่น การซื้อ 1-2 ครั้ง) มีประโยชน์ต่อผู้ลงโฆษณาหรือไม่ ในระหว่างการทดลองเวอร์ชันต้นทาง Chrome สนับสนุนให้ผู้ทดสอบใช้ประโยชน์จากการทดสอบพารามิเตอร์ความเป็นส่วนตัวและสัญญาณรบกวนอันหลากหลาย เพื่อให้สามารถให้ความคิดเห็นที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับปัญหานี้ |
จำกัดการติดตามแอบแฝง
การลด User Agent
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| การป้องกันบ็อต | ผลกระทบของ UA-R ต่อการป้องกันบ็อต | ขอขอบคุณสำหรับความคิดเห็นนี้ เรากําลังรวบรวมข้อมูลเกี่ยวกับแนวทางการป้องกันบ็อตเพื่อใช้เป็นข้อมูลในการออกแบบในอนาคต |
| Dependency ของการติดตั้งใช้งาน | การแก้ไขข้อกําหนดในการทําให้ Structured User Agent (SUA) ใช้งานได้ | เราได้เปิดตัว "ระยะที่ 4" หรือที่เรียกว่าการลดเวอร์ชันย่อยสำหรับผู้ใช้ Chrome 100% ในเวอร์ชัน 101 ขึ้นไป ดูข้อมูลอัปเดตที่นี่ |
คำแนะนำสำหรับไคลเอ็นต์ User Agent
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| แสดงรายการคำแนะนำที่รองรับทั้งหมด | สนใจที่จะใช้วิธีแบบเป็นโปรแกรมเพื่อดูคำแนะนำทั้งหมดที่รองรับสำหรับเบราว์เซอร์ | ขอขอบคุณสำหรับความคิดเห็นนี้ เรากำลังอยู่ระหว่างการประเมินคำขอฟีเจอร์ เราอยากทราบว่ากรณีการใช้งานนี้เป็นกรณีการใช้งานที่พบได้ทั่วไปหรือไม่ |
| ความยืดหยุ่นของ UA-CH เทียบกับส่วนหัว User-Agent | UA-CH มีการกำหนดมากเกินไปเมื่อเทียบกับความยืดหยุ่นที่ส่วนหัว User-Agent มอบให้ตามที่ระบุไว้ใน rfc7231 | Chrome เห็นว่าลักษณะการกําหนดของส่วนหัว UA-CH เป็นการปรับปรุงที่สําคัญเหนือความยืดหยุ่นของสตริง UA ทั้งจากมุมมองของการทํางานร่วมกันข้ามเบราว์เซอร์ในอนาคตและการป้องกันความเป็นส่วนตัวของผู้ใช้ (โดยการป้องกันการเพิ่มตัวระบุความผันผวนสูงโดยไม่ตั้งใจ)
ปัญหานี้จะยังคงเปิดอยู่ในกรณีที่ผู้อื่นมีข้อกังวลนี้เช่นกันและต้องการแสดงความคิดเห็น |
| UA-CH: Anti-Fraud / Anti-Abuse concerns | ฟีเจอร์บางอย่างที่อาจหายไปผ่าน UA-CH ได้แก่ เครื่องมือติดตามการเปลี่ยนเส้นทางคลิกและการคลิกที่เป็นการฉ้อโกง | ทีมกําลังตรวจสอบปัญหาที่อาจเกิดขึ้นเหล่านี้กับผู้มีส่วนเกี่ยวข้องด้านการป้องกันการประพฤติมิชอบและการวัดผล |
| ประสิทธิภาพ | มีข้อกังวลเกี่ยวกับเวลาในการตอบสนองของการรับคำแนะนำผ่าน Critical-CH (ในการโหลดหน้าเว็บครั้งแรก) | Chrome กำลังหาวิธีปรับปรุงประสิทธิภาพ |
นกกินยุง (อยู่ระหว่างดำเนินการ)
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| ข้อกังวลเกี่ยวกับเวลาในการตอบสนอง | การเพิ่ม Hop เพิ่มเติมอาจส่งผลต่อเวลาในการตอบสนอง | เรากำลังพิจารณาพร็อกซีแบบ 2 Hop และหาวิธีหาจุดสมดุลระหว่างความเป็นส่วนตัวของผู้ใช้กับเวลาในการตอบสนอง เรายินดีรับฟังความคิดเห็นและอยากพูดคุยเพิ่มเติมในฟอรัม W3C |
| การป้องกันการประพฤติมิชอบและบ็อต | ผลกระทบต่อการป้องกันการประพฤติมิชอบและบ็อต รวมถึงในประเทศกำลังพัฒนา | ความปลอดภัยเป็นข้อกําหนดหลักเมื่อเรามองหาวิธีปรับปรุงความเป็นส่วนตัวของผู้ใช้อย่างมีความหมาย เช่น การใช้พร็อกซีที่อยู่ IP พร็อกซี 2 Hop ที่ร่วมมือกับบริษัทที่มีชื่อเสียงจะมอบความเป็นส่วนตัวของผู้ใช้ที่ตรวจสอบได้ นอกจากนี้ เรายังพัฒนาแนวคิดสำหรับสัญญาณใหม่ๆ เพื่อช่วยสร้างความน่าเชื่อถือให้แก่ผู้ใช้ด้วย |
| การปฏิบัติตามกฎหมายความเป็นส่วนตัวท้องถิ่น | การรายงานข้อมูลทางภูมิศาสตร์ระดับประเทศทําให้การปฏิบัติตามข้อกําหนดของกฎระเบียบท้องถิ่นที่ละเอียดยิ่งขึ้นเป็นเรื่องยาก | เราได้โพสต์หลักการที่เสนอต่อสาธารณะ ซึ่งรวมถึงแนวทางที่เป็นไปได้ซึ่งจะช่วยให้เว็บไซต์ยังคงเป็นไปตามข้อกำหนดท้องถิ่น |
เพิ่มความเข้มงวดให้กับขอบเขตความเป็นส่วนตัวข้ามเว็บไซต์
ชุดโดเมนของบุคคลที่หนึ่ง
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| ประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ | ผลกระทบของ FPS สําหรับผู้เผยแพร่โฆษณารายเล็กเทียบกับรายใหญ่ | เป้าหมายหลักของ Privacy Sandbox คือปรับปรุงความเป็นส่วนตัวของผู้ใช้ด้วยการเปลี่ยนแนวทางปฏิบัติในปัจจุบันด้วยโซลูชันที่ไม่อาศัยกลไกการติดตามข้ามเว็บไซต์ เราต้องการให้โซลูชันเหล่านี้มีประโยชน์ในวงกว้างที่สุดเท่าที่จะเป็นไปได้สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ และทุกขนาด เรายินดีรับฟังความคิดเห็นที่เฉพาะเจาะจงและนำไปใช้ได้จริงเกี่ยวกับวิธีปรับปรุงโซลูชันเหล่านี้ และคาดว่าโซลูชันเหล่านี้จะพัฒนาต่อไปผ่านการพูดคุยและการทดสอบของชุมชน |
| การปรับปรุงความเป็นส่วนตัว | เว็บไซต์ในชุดเดียวกันมากเกินไปอาจส่งผลให้เกิดผลลัพธ์ที่คล้ายกับคุกกี้ของบุคคลที่สาม | ขอขอบคุณสำหรับความคิดเห็นนี้ เรากำลังประเมินว่าขีดจำกัดที่เหมาะสมควรเป็นเท่าใด และพยายามแจ้งทั้งผู้ใช้และนักพัฒนาแอปเกี่ยวกับวิธีจัดการหรือสัญญาณเพื่อให้เข้าใจเมื่อถึงขีดจำกัดดังกล่าว เรายังไม่มีข้อเสนอที่เจาะจงที่จะแชร์ แต่หวังว่าจะแชร์ได้ในเร็วๆ นี้ |
| การรองรับระบบนิเวศของ FPS | การเก็บรวบรวมการสนับสนุนและความกังวลในการพัฒนา FPS นอก CG ความเป็นส่วนตัวต่อไป | แม้ว่าเราต้องการเสนอชุดข้อมูลจากบุคคลที่หนึ่งใน PrivacyCG แต่เราก็หวังว่าจะเสนอชุดข้อมูลจากบุคคลที่หนึ่งใน WICG ต่อไป นอกจากนี้ เรายังได้รับกำลังใจจากข้อความสนับสนุนจำนวนมากสำหรับการพูดคุยอย่างต่อเนื่องเกี่ยวกับชุดของบุคคลที่หนึ่งและกรณีการใช้งานที่ชุดของบุคคลที่หนึ่งมีไว้เพื่อจัดการ Google ยังคงมุ่งมั่นที่จะค้นหาโซลูชันที่ช่วยให้เว็บเติบโตและประสบความสำเร็จต่อไปในลักษณะที่ปกป้องและเคารพความเป็นส่วนตัวของผู้ใช้ |
| ความสามารถในการทำงานร่วมกันของเบราว์เซอร์ | การใช้งานโดยเบราว์เซอร์อื่นๆ | เราตระหนักดีว่าการทำงานร่วมกันระหว่างเบราว์เซอร์มีความสำคัญต่อนักพัฒนาซอฟต์แวร์ และจะยังคงร่วมมือกับเบราว์เซอร์อื่นๆ เพื่อกำหนดมาตรฐาน FPS ต่อไป |
| ข้อกำหนดทั่วไปของนโยบายความเป็นส่วนตัว | เราไม่อาจรักษานโยบายความเป็นส่วนตัวทั่วไปสำหรับผลิตภัณฑ์และเขตอํานาจศาลทั้งหมดที่ต้องเป็นส่วนหนึ่งของชุดเดียวกัน | Chrome ยังคงกำหนดข้อกำหนดด้านนโยบายอยู่ และจะคำนึงถึงความคิดเห็นนี้ |
Fenced Frames API
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| คำขอเอกสารประกอบ | ความแตกต่างกับ iframe ที่อยู่ในแซนด์บ็อกซ์ | ขอขอบคุณสำหรับความคิดเห็นและคำแนะนำ ขณะนี้เรากำลังพูดคุยเกี่ยวกับเรื่องนี้ใน GitHub ซึ่งหวังว่าจะได้รับความชัดเจนขั้นสุดท้ายเกี่ยวกับคำขอนี้เพื่อประเมินคำขออย่างสมบูรณ์ คุณสามารถดูการสนทนาแบบสาธารณะได้ที่นี่ |
| ความสามารถข้าม API | การรองรับการรายงานการระบุแหล่งที่มาในเฟรมที่มีการกำหนดขอบเขตโดยค่าเริ่มต้น | เรากําลังขอความคิดเห็นเกี่ยวกับข้อเสนอที่จะอนุญาตให้ Attribution Reporting API อยู่ใน "โหมดโฆษณาแบบทึบ" ของเฟรมที่มีการกำหนดเขตโดยค่าเริ่มต้น เราขอแนะนำให้นักพัฒนาแอปที่เห็นว่าข้อมูลนี้มีประโยชน์เข้าร่วมการสนทนา |
Shared Storage API
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| ขีดจำกัดข้อมูล | จะมีการจํากัดปริมาณข้อมูลที่จัดเก็บได้ต่อพาร์ติชันไหม | ใช่ จะมีขีดจำกัด ดูรายละเอียดเพิ่มเติมได้ที่ปัญหาใน GitHub เราจะต้องขอโควต้าพื้นที่เก็บข้อมูล ข้อเสนอปัจจุบันของเราคือกำหนดขีดจำกัดขนาดต่อรายการไว้ที่ 4 KB โดยทั้งคีย์และค่าจะจำกัดไว้ที่ 1024 อักขระ char16_t รายการละ 1 รายการ และกำหนดขีดจำกัดรายการต่อต้นทางไว้ที่ 10,000 รายการ โดยมีกลไกป้องกันไม่ให้บันทึกรายการเพิ่มเติมเมื่อความจุของต้นทางเต็ม เรากำลังมองหาความคิดเห็นเกี่ยวกับขีดจํากัดที่เฉพาะเจาะจงที่เสนอไว้ที่นี่ |
| ความโปร่งใสของการจัดการข้อมูลผู้ใช้ | ความโปร่งใสของผู้ใช้สำหรับแหล่งข้อมูลเทียบกับการใช้ข้อมูล | ขอขอบคุณสำหรับความคิดเห็นนี้ เราคิดว่าแนวทางนี้น่าสนใจและควรนำมาพิจารณา โดยเฉพาะอย่างยิ่ง เรากำลังประเมินว่าจะดำเนินการนี้ในลักษณะที่โปร่งใสต่อผู้ใช้ได้มากน้อยเพียงใด |
CHIPS
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| อุปสรรคในการนำไปใช้ | CHIPS ควรเชื่อมโยงกับชื่อโฮสต์ไหม (ข้อกำหนดที่ไม่มีโดเมน) | เราจะนําข้อกําหนดนี้ออกจาก OT ตามความคิดเห็นจากผู้เข้าร่วม OT ว่าข้อกําหนดนี้ทําให้เกิดความซับซ้อนมากขึ้นและขัดขวางการใช้ CHIPS
เราจะพูดคุยเกี่ยวกับข้อกำหนดนี้ในกลุ่มชุมชนด้านความเป็นส่วนตัวซึ่งเป็นส่วนหนึ่งของการบ่มเพาะมาตรฐานที่นี่ |
| Use Case ของโฆษณาสําหรับ CHIPS | CHIPS ใช้กับกรณีการใช้งาน Google Ads ในเว็บไซต์เดียวได้ไหม | การติดตามผู้ใช้ภายในเว็บไซต์เดียวเป็น Use Case ที่อนุญาต เราได้ อัปเดตบทความสำหรับนักพัฒนาแอปเพื่อไฮไลต์กรณีการใช้งานนี้ |
| การฝังที่ได้รับการตรวจสอบสิทธิ์ | ระบบจะเก็บสถานะการลงชื่อเข้าใช้ไว้กับ CHIPS ไหม | ระบบไม่ได้เก็บสถานะการลงชื่อเข้าใช้ไว้ในปัจจุบัน แต่นี่ไม่ใช่กรณีการใช้งานที่ต้องการสำหรับ CHIPS เราทราบถึงกรณีการใช้งานการฝังที่มีการให้สิทธิ์แล้วและกำลังหาวิธีแก้ปัญหา |
| การประสานงานการทดสอบ | ผู้ใช้ต้องดำเนินการใดๆ เพิ่มเติมเพื่อทดสอบการแบ่งพาร์ติชันหรือไม่ | ตราบใดที่โทเค็น OT ถูกต้องและแสดงอยู่ในส่วนหัวของหน้าเว็บที่เข้าชม ฟีเจอร์นี้ควรพร้อมใช้งานสำหรับผู้ใช้โดยที่ผู้ใช้ไม่ต้องดำเนินการใดๆ เพิ่มเติม |
| ความเข้ากันได้กับเบราว์เซอร์ | สนใจทำความเข้าใจวิธีที่เบราว์เซอร์อื่นๆ จัดการแอตทริบิวต์คุกกี้ที่มีการแบ่งพาร์ติชัน | Chrome ยังคงทำงานร่วมกับกลุ่มมาตรฐานสาธารณะ เช่น W3C เพื่อระบุการออกแบบและการใช้งานที่ทำงานได้กับเบราว์เซอร์ต่างๆ |
FedCM
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| เวกเตอร์การโจมตีที่เป็นไปได้ | เวกเตอร์การโจมตีที่อาจเกิดขึ้นผ่านการตกแต่งลิงก์และการโจมตีตามจังหวะเวลา | เรากําลังรวบรวมความคิดเห็นจากสาธารณะและตรวจสอบวิธีต่างๆ ที่อาจช่วยแก้ปัญหานี้ |
| UX ที่อนุญาตให้ใช้ IDP ได้หลายรายการ | แสดง IDP ได้ครั้งละ 1 รายการเท่านั้น | เราเชื่อว่าการรองรับ IDP หลายรายการเป็นสิ่งจำเป็น และกำลังพยายามอย่างเต็มที่เพื่อหาแนวทางในการรองรับ |
| ความสามารถในการสื่อความหมาย | ข้อกังวลเนื่องจากเบราว์เซอร์แสดงผลบางส่วนของขั้นตอนการรวมข้อมูลประจำตัว ทำให้จับรายละเอียดทั้งหมดที่ IdP ต้องการนำเสนอต่อผู้ใช้ได้ยาก | Chrome กำลังพิจารณาที่จะรวมการปรับแต่งการสร้างแบรนด์ (เช่น โลโก้ สี) และการปรับแต่งสตริง (เช่น "เข้าถึงบทความนี้" แทน "เข้าสู่ระบบด้วย")
Chrome ตระหนักดีถึงข้อเสียที่อาจเกิดขึ้น และจะยังคงทำงานร่วมกับระบบนิเวศต่อไปเพื่อครอบคลุมการใช้งานให้มากที่สุดและเพื่อทำให้การแสดงออกเป็นไปได้มากที่สุด |
| ความสามารถในการทำงานร่วมกันและขอบเขตการบังคับใช้ | ความกังวลว่าเบราว์เซอร์อื่นๆ จะไม่ยอมรับหรือใช้งาน FedCM | Chrome ยังทำงานร่วมกับผู้ให้บริการเบราว์เซอร์รายอื่นๆ เพื่อค้นหาโซลูชันทั่วไปสำหรับการรวมข้อมูลใน FedID Community Group ด้วย |
| คําแนะนําในการนําข้อกําหนดด้านข้อมูลส่วนบุคคลในขั้นตอนการลงชื่อสมัครใช้ออก | (1) UX ที่ระบุให้ผู้ใช้ทราบว่ากำลังเลือกผู้ให้บริการระบุตัวตนรายใด โดยไม่มีการระบุว่าจะมีการแชร์อีเมล รูปภาพ และชื่อของผู้ใช้ จะเป็นการออกแบบที่เคารพความเป็นส่วนตัวมากกว่า
(2) กรณีการใช้งานการลงชื่อสมัครใช้มีน้อยในประสบการณ์ของผู้ใช้และการเลือกการอ้างสิทธิ์จาก IdP |
เราเห็นด้วยและกำลังหาวิธีนำความคิดเห็นนี้ไปใช้ในลักษณะที่คำนึงถึงผู้ใช้และความเป็นส่วนตัวมากขึ้น |
| การโต้ตอบของผู้ใช้กับ IdP | จำเป็นต้องมีการโต้ตอบโดยตรงระหว่างผู้ใช้กับ IdP หากมีความเสี่ยงเกินเกณฑ์ | เรากำลังตรวจสอบความคิดเห็นนี้อย่างละเอียด |
การแบ่งพาร์ติชันสถานะของเครือข่าย
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| ประสิทธิภาพ | การแบ่งพาร์ติชันสถานะเครือข่ายอาจทำให้การเชื่อมต่อกับ CDN ต้องใช้ทรัพยากรมากขึ้น | เรายังคงตรวจสอบลักษณะประสิทธิภาพของการแบ่งพาร์ติชันสถานะเครือข่าย รวมถึงการวัดรูปแบบการกุญแจที่เป็นไปได้ต่างๆ เรายังไม่ได้ตัดสินใจว่าจะเลือกประสิทธิภาพ ความปลอดภัย หรือความเป็นส่วนตัว และจำเป็นต้องรวบรวมข้อมูลเพิ่มเติม |
ต่อสู้กับสแปมและการประพฤติมิชอบ
Trust Tokens API
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| ความคิดเห็นเกี่ยวกับกฎระเบียบ | ความกังวลเกี่ยวกับการใช้เวลาและทรัพยากรไปกับ Trust Token โดยไม่มีสัญญาณที่ชัดเจนจากหน่วยงานกำกับดูแลเกี่ยวกับความยั่งยืนในระยะยาว | เป้าหมายของเราคือการสร้างเทคโนโลยีที่เหมาะกับระบบนิเวศ ซึ่งทำให้ความคิดเห็นจากอุตสาหกรรมและหน่วยงานกำกับดูแลมีความสำคัญอย่างยิ่งต่อกระบวนการนี้ เราจะปรึกษากับหน่วยงานกำกับดูแลทั่วโลกต่อไปขณะพัฒนา Privacy Sandbox และเผยแพร่ข้อเสนอแก่นักพัฒนาแอป ซึ่งรวมถึงโทเค็นความน่าเชื่อถือ บริษัทต่างๆ ควรตัดสินใจตามการประเมินข้อกําหนดด้านกฎระเบียบของตนเอง เช่นเดียวกับเทคโนโลยีใหม่ทั้งหมด |
| ช่วงเวลาที่เปิดตัว | Trust Token จะเปิดตัวใน GA เมื่อใด | เราแสดงเวลานำส่งโดยประมาณในปัจจุบันในไทม์ไลน์สาธารณะที่ privacysandbox.com ทันทีที่เราตัดสินใจขั้นสุดท้ายเกี่ยวกับวันที่นำส่งไปยัง GA เราจะโพสต์ข้อมูลดังกล่าวต่อสาธารณะผ่านกระบวนการเผยแพร่ของ Chrome และอัปเดตไทม์ไลน์ในเว็บไซต์ |
| โทเค็นความน่าเชื่อถือเทียบกับรายการอื่นๆ | โทเค็นความน่าเชื่อถือมีบทบาทอย่างไรเมื่อโทเค็นอื่นๆ อยู่ระหว่างมาตรฐาน เช่น โทเค็นการเข้าถึงส่วนตัว | เรามีส่วนร่วมในการพูดคุยเกี่ยวกับการมาตรฐาน และเป้าหมายของเราคือการปรับให้สอดคล้องกับความพยายามอื่นๆ ให้ได้มากที่สุด ในขณะเดียวกันก็เปิดใช้กรณีการใช้งานต่างๆ ที่เทคโนโลยีแต่ละอย่างมี ตัวอย่างเช่น โทเค็นความน่าเชื่อถือและโทเค็นการเข้าถึงส่วนตัวต่างก็ใช้โปรโตคอล Privacy Pass |
| ขีดจำกัดข้อมูล | ผู้ออกบัตรสูงสุด 2 รายสำหรับการแลกโทเค็นต่อหน้าเว็บที่อาจมีการจำกัด | เรากําลังมองหาตัวเลือกระยะยาวที่จะช่วยให้บริษัทแลกรับโทเค็นได้อย่างปลอดภัยโดยไม่เสี่ยงต่อการเกิดข้อมูลการเข้ารหัสของผู้ใช้เพิ่มขึ้น ซึ่งอาจเป็นการแบ่งพาร์ติชันการเข้าถึงการแลกรับโทเค็น |
| การจำกัดการเข้าถึง | เฉพาะต้นทางที่ได้รับอนุมัติ (และได้รับการยืนยัน/ไม่ได้มีการปลอมแปลงผู้อ้างอิง) เท่านั้นที่จะยืนยันการมีอยู่ของโทเค็นและแลกสิทธิ์ได้ | เรากำลังพิจารณาแนวทางสำหรับผู้ที่เห็นและแลกรับโทเค็นได้ |
| การรองรับอุปกรณ์ | ไลบรารีรันไทม์ของ JavaScript จํากัดการใช้งานในอุปกรณ์บางเครื่อง TT รองรับอุปกรณ์ประเภทอื่นๆ เพิ่มเติมได้ไหม | เราอาจพิจารณาเรื่องนี้เพื่อการพัฒนาในอนาคต และยินดีรับฟังความคิดเห็นเพิ่มเติมจากนักพัฒนาซอฟต์แวร์ในฟอรัม W3C นอกจากนี้ เรายังมีปัญหาที่รอดำเนินการสำหรับการพูดคุยเกี่ยวกับการแลกโทเค็นที่ทริกเกอร์โดยส่วนหัว HTTP ซึ่งเรายินดีรับฟังความคิดเห็น |
| กรณีการใช้งาน | กรณีการใช้งานที่เหมาะสมสำหรับ Trust Token ไม่ชัดเจน ขาดความชัดเจนเกี่ยวกับการใช้งานที่ต้องการ | เป้าหมายของเราคือการส่งเสริมนวัตกรรมในพื้นที่การป้องกันการประพฤติมิชอบ และเข้าใจว่าแต่ละบริษัทอาจใช้เทคนิคที่เป็นกรรมสิทธิ์กับโทเค็นความน่าเชื่อถือ เราจึงไม่ได้กำหนดการใช้ที่ต้องการ อย่างไรก็ตาม เราอาจขยายเอกสารประกอบให้ครอบคลุมตัวอย่างเพิ่มเติมเพื่อเป็นจุดเริ่มต้นสำหรับพาร์ทเนอร์ที่กำลังพิจารณาการทดสอบหรือการนำไปใช้ |
| ความครอบคลุมของโทเค็นความน่าเชื่อถือ | การนํานโยบายฟีเจอร์ "trust-token-redemption" นี้ออกควรเพิ่มการครอบคลุมโทเค็นความน่าเชื่อถือได้อย่างมาก | เราจะพิจารณาเรื่องนี้ขณะรวบรวมความคิดเห็นจาก OT และตัดสินใจเกี่ยวกับขั้นตอนถัดไป |
| ทรัสต์ของผู้ออกบัตร | เหตุใดเราจึงควรเชื่อถือเว็บไซต์ที่ออกโทเค็นความน่าเชื่อถือ | ทุกคนสามารถเป็นผู้ออกบัตรได้ โดยไม่มีหลักเกณฑ์ใดๆ เราคาดหวังว่าผู้เผยแพร่โฆษณาจะทํางานร่วมกับผู้ออกใบอนุญาตที่ตนไว้ใจเท่านั้น นอกจากนี้ ผู้เล่นอื่นๆ ที่ถูกต้องตามกฎหมายในระบบนิเวศโฆษณาก็จะลด (หรือหยุดซื้อ) การเข้าชมที่เชื่อมโยงกับผู้ออกใบอนุญาตที่น่าสงสัยหรือไม่รู้จัก |
| บริการที่ฝังของบุคคลที่สาม | บริการที่ฝังของบุคคลที่สามจะแลกสิทธิ์และ/หรือขอโทเค็นความน่าเชื่อถือได้ไหม | ได้ บริการที่ฝังของบุคคลที่สามสามารถออกและแลกสิทธิ์การใช้โทเค็นความน่าเชื่อถือได้ |
| ระบบนิเวศของผู้ออกบัตร | ประโยชน์จะมากขึ้นหากแชร์สัญญาณความน่าเชื่อถือกับบริษัทอื่นๆ ได้ | โทเค็นความน่าเชื่อถือได้รับการออกแบบให้เป็นองค์ประกอบพื้นฐานระดับล่าง และผู้ออกใบอนุญาต/ผู้แลกสิทธิ์ที่ร่วมมือกันสามารถใช้เพื่อแชร์สัญญาณความน่าเชื่อถือ/ชื่อเสียง |
| ค่าใช้จ่ายในการบำรุงรักษา | การใช้งานการเข้ารหัสลับที่อยู่เบื้องหลังการดำเนินการของโทเค็นความน่าเชื่อถืออยู่ใน BoringSSL ซึ่ง Google เป็นผู้จัดการดูแลเพียงรายเดียว การจัดการการบำรุงรักษาคลังภาพจะเป็นอย่างไร | โทเค็นความน่าเชื่อถืออาศัยการดำเนินการเข้ารหัสตามมาตรฐาน (ดูโปรโตคอล Privacy Pass) ซึ่งอาจนำมาใช้ในไลบรารีอื่นๆ ได้ด้วย เราขอแนะนำให้นักพัฒนาแอปขอ/พัฒนา/ดูแลรักษาการรองรับการดำเนินการเหล่านี้ในไลบรารีที่ตนเลือก |
| ค่าใช้จ่ายในการบำรุงรักษา | ไม่ชัดเจนว่าระบบจะรองรับเวอร์ชันโปรโตคอลได้นานเท่าใด | เรากําลังพิจารณาพัฒนาและจัดทำเอกสารที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับกรอบเวลาการสนับสนุนที่คาดไว้สําหรับเวอร์ชันโปรโตคอล |
| ขีดจํากัดของผู้ออกบัตร | หากคุณอยู่ท้ายสุดของเชน คุณอาจไม่มีสิทธิ์ใช้โทเค็นความน่าเชื่อถือ | เมื่อองค์กรต่างๆ เริ่มใช้โทเค็นความน่าเชื่อถือมากขึ้น เราอาจเห็นการเปลี่ยนแปลงของเวลาประเภทนี้เกิดขึ้นมากขึ้น และกำลังหาวิธีแก้ปัญหาที่เป็นไปได้ ดังที่ได้อธิบายไว้ก่อนหน้านี้ เรากําลังมองหาตัวเลือกระยะยาวที่จะช่วยให้บริษัทแลกโทเค็นได้อย่างปลอดภัยโดยไม่เสี่ยงต่อการเกิดข้อมูลสุ่มของผู้ใช้มากขึ้น ซึ่งจะลดความสําคัญของตําแหน่งในหน้าเว็บหรือลําดับการโหลด |
โซลูชันใหม่ในการป้องกันการประพฤติมิชอบ
| ธีมความคิดเห็น
(จัดอันดับตามความแพร่หลาย) |
สรุปคําถามและความกังวล | การตอบกลับของ Chrome |
| สัญญาณการรับรองความสมบูรณ์ของอุปกรณ์ | โดยทั่วไปแล้ว รองรับการติดตามสัญญาณความสมบูรณ์ของอุปกรณ์ที่แพลตฟอร์มรับรองและเผยแพร่บนเว็บ | เราจะรวบรวมความคิดเห็นและดำเนินการตามข้อเสนอผ่านการออกแบบและการทำซ้ำแบบสาธารณะต่อไป |
| สัญญาณการรับรองความสมบูรณ์ของอุปกรณ์ | คำถามเกี่ยวกับปริมาณข้อมูลการเข้ารหัสของผู้ใช้ที่ส่งผ่านสัญญาณใหม่ได้ และกรณีการใช้งานบางอย่าง (เช่น ผู้ใช้เข้าสู่ระบบธนาคาร) อาจเป็นเหตุผลที่ควรใช้สัญญาณการเข้ารหัสที่สูงขึ้นหรือไม่ | เรามุ่งเน้นที่การให้สัญญาณที่มีคุณค่าสูงโดยมีข้อมูลการเข้ารหัสของผู้ใช้ให้น้อยที่สุดเพื่อรักษาความเป็นส่วนตัวของผู้ใช้ |
| สัญญาณการรับรองความสมบูรณ์ของอุปกรณ์ | สัญญาณนี้จำกัดการเข้าถึงสำหรับอุปกรณ์รุ่นเก่าหรือแพลตฟอร์มโอเพนซอร์ส/ที่แก้ไขแล้วไหม | สัญญาณใหม่ใดๆ ควรพิจารณาการเข้าถึงแบบสากลเป็นหลักการสำคัญในการพัฒนา และคำถามเหล่านี้เป็นคำถามสำคัญที่ต้องจัดการตั้งแต่เนิ่นๆ ขณะที่เราพัฒนาต่อไป |
| สัญญาณการรับรองความสมบูรณ์ของอุปกรณ์ | มีข้อกังวลว่าสัญญาณใหม่อาจทําให้บริษัทรักษาความปลอดภัยและป้องกันการประพฤติมิชอบต้องพึ่งพาเบราว์เซอร์และแพลตฟอร์มมากเกินไป
|
สัญญาณใหม่ควรถือเป็นข้อมูลเสริม ไม่ใช่ตัวบ่งชี้ "ความน่าเชื่อถือ" จากเบราว์เซอร์ เราคาดหวังอย่างเต็มที่ว่าบริษัทรักษาความปลอดภัยจะยังคงใช้ข้อมูล โมเดล และเครื่องมือตัดสินใจที่เป็นกรรมสิทธิ์ของตนเองต่อไป โดยมีการตรวจสอบอุปกรณ์เป็นข้อมูลอินพุตเพิ่มเติม เราหวังว่าสัญญาณใหม่จะช่วยปรับปรุงการตรวจจับในระบบนิเวศและทำให้การดำเนินการที่เป็นการประพฤติมิชอบทำได้ยากขึ้น |
| สัญญาณอายุของคุกกี้ | แนวคิดที่น่าสนใจ แต่อาจต้องตรวจสอบกรณีการใช้งานที่เกี่ยวข้องเพิ่มเติม | Chrome อาจหาแนวคิดเพิ่มเติมเกี่ยวกับแนวคิดนี้และสร้างเป็นคำอธิบายสำหรับความคิดเห็นเกี่ยวกับระบบนิเวศในอนาคต ทั้งนี้ขึ้นอยู่กับระดับความสนใจ |
| เซิร์ฟเวอร์ที่เชื่อถือได้สำหรับการป้องกันการประพฤติมิชอบ | แนวคิดที่น่าสนใจ แต่อาจต้องตรวจสอบกรณีการใช้งานที่เกี่ยวข้องเพิ่มเติม | Chrome อาจหาแนวคิดเพิ่มเติมเกี่ยวกับแนวคิดนี้และสร้างเป็นคำอธิบายสำหรับความคิดเห็นเกี่ยวกับระบบนิเวศในอนาคต ทั้งนี้ขึ้นอยู่กับระดับความสนใจ |