รายงานรายไตรมาสสำหรับไตรมาสที่ 2 ปี 2022 สรุปความคิดเห็นของระบบนิเวศที่ได้รับเกี่ยวกับข้อเสนอ Privacy Sandbox และคำตอบของ Chrome
ในฐานะที่เป็นส่วนหนึ่งของความมุ่งมั่นต่อ CMA ทาง Google ได้ตกลงที่จะจัดทำรายงานรายไตรมาสเกี่ยวกับกระบวนการมีส่วนร่วมของผู้มีส่วนเกี่ยวข้องสำหรับข้อเสนอ Privacy Sandbox (ดูวรรคที่ 12 และ 17(c)(ii) ของ สัญญาผูกมัด) รายงานสรุปความคิดเห็นเกี่ยวกับ Privacy Sandbox เหล่านี้สร้างขึ้นโดยการรวบรวมความคิดเห็นที่ Chrome ได้รับจากแหล่งที่มาต่างๆ ตามที่ระบุไว้ในภาพรวมความคิดเห็น ซึ่งรวมถึงแต่ไม่จำกัดเพียงปัญหาเกี่ยวกับ GitHub, แบบฟอร์มความคิดเห็นที่มีให้ใน privacysandbox.com, การประชุมกับผู้มีส่วนเกี่ยวข้องในอุตสาหกรรม และฟอรัมมาตรฐานเว็บ Chrome ยินดีรับฟังความคิดเห็นที่ได้รับจากระบบนิเวศและกำลังดำเนินการสำรวจวิธีการต่างๆ ในการผสานรวมสิ่งที่เรียนรู้เข้ากับการตัดสินใจด้านการออกแบบ
ธีมความคิดเห็นจะจัดอันดับตามความแพร่หลายต่อ API ซึ่งทำได้โดยรวบรวมความคิดเห็นที่ทีม Chrome ได้รับจากธีมที่กำหนด และจัดระเบียบปริมาณจากมากไปหาน้อย ธีมความคิดเห็นที่พบบ่อยมาจากการตรวจสอบหัวข้อการพูดคุยจากการประชุมสาธารณะ (W3C, PatCG, IETF), ความคิดเห็นโดยตรง, GitHub และคำถามที่พบบ่อยซึ่งนำเสนอผ่านทีมภายในของ Google และแบบฟอร์มสาธารณะ
กล่าวอย่างเจาะจงก็คือ รายงานการประชุมของหน่วยงานมาตรฐานในเว็บได้รับการตรวจสอบ และสำหรับความคิดเห็นโดยตรง Google มีการพิจารณาบันทึกการประชุมของผู้มีส่วนเกี่ยวข้องแบบ 1:1, อีเมลที่วิศวกรแต่ละคนได้รับ, รายชื่ออีเมล API และแบบฟอร์ม แสดงความคิดเห็นสาธารณะ จากนั้น Google ได้ประสานงานระหว่างทีมที่เกี่ยวข้องกับกิจกรรมช่วยเหลือต่างๆ เหล่านี้เพื่อระบุความแพร่หลายของธีมที่เกิดขึ้นโดยเทียบกับ API แต่ละรายการ
คำอธิบายคำตอบของ Chrome ที่มีต่อความคิดเห็นของ Chrome นั้นพัฒนาขึ้นจากคำถามที่พบบ่อยที่มีการเผยแพร่ คำตอบที่เกิดขึ้นจริงต่อปัญหาที่ผู้มีส่วนเกี่ยวข้องเป็นผู้หยิบยกขึ้นมา และการกำหนดจุดยืนโดยเฉพาะเพื่อวัตถุประสงค์ในการจัดทำรายงานต่อสาธารณะนี้ ปัจจุบันเราได้รับคำถามและความคิดเห็นเกี่ยวกับ Topics, Fledge และ Attribution Reporting API เพื่อแสดงให้เห็นจุดมุ่งเน้นในการพัฒนาและทดสอบ
ความคิดเห็นที่ได้รับหลังจากสิ้นสุดระยะเวลาการรายงานปัจจุบันอาจยังไม่ได้รับคำตอบจาก Chrome
อภิธานศัพท์ของตัวย่อ
- ชิป
- คุกกี้ที่มีสถานะแบ่งพาร์ติชันอิสระ
- DSP
- แพลตฟอร์มฝั่งดีมานด์
- FedCM
- การจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์
- FPS
- ชุดบุคคลที่หนึ่ง
- IAB
- สมาคมโฆษณาอินเทอร์แอกทีฟ (Interactive Advertising Bureau)
- IdP
- ผู้ให้บริการข้อมูลประจำตัว
- IETF
- คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต
- อินนิ่ง
- ที่อยู่ Internet Protocol
- openRTB
- การเสนอราคาแบบเรียลไทม์
- OT
- ช่วงทดลองใช้จากต้นทาง
- PatCG
- กลุ่มชุมชนเทคโนโลยีการโฆษณาส่วนตัว
- RP
- ฝ่ายพึ่งพา
- SSP
- แพลตฟอร์มฝั่งซัพพลาย
- TEE
- สภาพแวดล้อมการดำเนินการที่เชื่อถือได้
- UA
- สตริง User Agent
- UA-CH
- คำแนะนำไคลเอ็นต์ User Agent
- W3C
- World Wide Web Consortium
- อยู่ระหว่างดำเนินการ
- การตาบอด IP แบบจงใจ
ความคิดเห็นทั่วไป ไม่มี API/เทคโนโลยีที่เฉพาะเจาะจง
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| ไทม์ไลน์ที่ชัดเจนขึ้น | กำหนดการเผยแพร่ที่ชัดเจนและละเอียดยิ่งขึ้นสำหรับเทคโนโลยี Privacy Sandbox | เราได้จัดทำแผนปัจจุบันสำหรับกำหนดการทำให้ใช้งานได้บน privacysandbox.com และอัปเดตทุกเดือน สิ่งเหล่านี้คำนึงถึงเวลาในการพัฒนาของทั้ง Chrome และนักพัฒนาเว็บ รวมทั้งความคิดเห็นที่เราได้รับจากระบบนิเวศในวงกว้าง ตามเวลาที่ต้องใช้ในการทดสอบและใช้เทคโนโลยีใหม่ เทคโนโลยีแต่ละอย่างผ่านขั้นตอนหลายขั้นตอน ตั้งแต่การทดสอบไปจนถึงการเผยแพร่ (การเปิดตัว) และช่วงเวลาของแต่ละขั้นตอนจะใช้ข้อมูลจากสิ่งที่เราเรียนรู้และค้นพบในขั้นตอนก่อนหน้า และแม้ว่าจะยังไม่ได้เปิดตัวแอปเวอร์ชันใดเวอร์ชันหนึ่งในขณะนี้ แต่เราก็จะอัปเดตไทม์ไลน์สาธารณะใน privacysandbox.com |
| ความมีประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ | ข้อกังวลว่าเทคโนโลยี Privacy Sandbox ชื่นชอบนักพัฒนาซอฟต์แวร์รายใหญ่ และเว็บไซต์เฉพาะกลุ่ม (ขนาดเล็ก) นั้นมีส่วนมากกว่าเว็บไซต์ทั่วไป (ขนาดใหญ่) | เราเข้าใจดีว่านักพัฒนาซอฟต์แวร์บางรายกังวลเกี่ยวกับผลกระทบของเทคโนโลยี Privacy Sandbox Google มุ่งมั่นที่จะไม่ให้ CMA ออกแบบหรือปรับใช้ข้อเสนอ Privacy Sandbox ในลักษณะที่บิดเบือนการแข่งขันด้วยการพิจารณาตนเองเทียบกับธุรกิจของ Google และคำนึงถึงผลกระทบที่มีต่อการแข่งขันในการโฆษณาดิจิทัลและต่อผู้เผยแพร่โฆษณาและผู้ลงโฆษณา รวมถึงผลกระทบต่อผลลัพธ์ด้านความเป็นส่วนตัวและประสบการณ์ของผู้ใช้ เราทำงานอย่างใกล้ชิดกับ CMA อย่างต่อเนื่องเพื่อให้มั่นใจว่างานของเราสอดคล้องกับความมุ่งมั่นเหล่านี้
ขณะที่การทดสอบ Privacy Sandbox คืบหน้าไป หนึ่งในคำถามสำคัญที่เราจะประเมินคือประสิทธิภาพของเทคโนโลยีใหม่สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ ความคิดเห็นสำคัญในเรื่องนี้ โดยเฉพาะความคิดเห็นที่เฉพาะเจาะจงและนำไปใช้ได้จริงซึ่งช่วยให้เราปรับปรุงการออกแบบทางเทคนิคเพิ่มเติมได้ |
| ลำดับเวลาการเลิกใช้งานคุกกี้ของบุคคลที่สาม | คำขอเพื่อหลีกเลี่ยงความล่าช้าในการเลิกใช้งานคุกกี้ของบุคคลที่สาม | เราทราบมาว่าผู้มีส่วนเกี่ยวข้องบางส่วนต้องการให้ Chrome เลิกใช้งานคุกกี้ของบุคคลที่สามอย่างรวดเร็ว และเราได้รับความคิดเห็นจากผู้อื่นที่เชื่อว่าต้องใช้เวลามากขึ้นในการทดสอบและนำเทคโนโลยี Privacy Sandbox ไปปรับใช้ เรามุ่งมั่นดำเนินการต่อด้วยความรับผิดชอบเนื่องจากเทคโนโลยีมีความซับซ้อนและความสำคัญต่อระบบนิเวศของการทำให้สิ่งต่างๆ ถูกต้อง ความคิดเห็นจากอุตสาหกรรมและจากหน่วยงานกำกับดูแลเป็นสิ่งที่สำคัญอย่างยิ่งสำหรับกระบวนการนี้ |
| ลำดับเวลาการเลิกใช้งานคุกกี้ของบุคคลที่สาม | คำขอชะลอการเลิกใช้งานคุกกี้ของบุคคลที่สามและให้เวลาเพิ่มเติมในการทดสอบ API | เราทราบมาว่าผู้มีส่วนเกี่ยวข้องบางส่วนต้องการให้ Chrome เลิกใช้งานคุกกี้ของบุคคลที่สามอย่างรวดเร็ว และเราได้รับความคิดเห็นจากผู้อื่นที่เชื่อว่าต้องใช้เวลามากขึ้นในการทดสอบและนำเทคโนโลยี Privacy Sandbox ไปปรับใช้ เรามุ่งมั่นดำเนินการต่อด้วยความรับผิดชอบเนื่องจากเทคโนโลยีมีความซับซ้อนและความสำคัญต่อระบบนิเวศของการทำให้สิ่งต่างๆ ถูกต้อง ความคิดเห็นจากอุตสาหกรรมและจากหน่วยงานกำกับดูแลเป็นสิ่งที่สำคัญอย่างยิ่งสำหรับกระบวนการนี้ |
| คำขอเอกสาร | คำขอแหล่งข้อมูลเพิ่มเติมซึ่งมีรายละเอียดเกี่ยวกับวิธีจัดการการทดสอบ การวิเคราะห์ และการใช้งาน | ขอขอบคุณที่นักพัฒนาแอปพบว่าเนื้อหาปัจจุบันของเรามีประโยชน์ และเรามุ่งมั่นที่จะเพิ่มข้อมูลเพิ่มเติม ซึ่งรวมถึงเวลาทำการสำหรับนักพัฒนาซอฟต์แวร์และเอกสารด้านเทคนิคในช่วงไม่กี่สัปดาห์และไม่กี่เดือนข้างหน้า เพื่อให้นักพัฒนาแอปได้ทำความเข้าใจต่อไปว่าเทคโนโลยีใหม่นี้จะมีประโยชน์ต่อตนเองอย่างไร
นอกจากนี้ เรายังได้จัดเซสชัน Office Hours สำหรับนักพัฒนาซอฟต์แวร์ภายนอกสู่สาธารณะเพื่อแชร์แนวทางปฏิบัติที่ดีที่สุดและการสาธิต รวมถึงเซสชันถามและตอบกับหัวหน้าทีมผลิตภัณฑ์และวิศวกร เพื่อเปิดโอกาสพูดคุย/แลกเปลี่ยนความคิดเห็นแบบสดๆ |
| ความเชี่ยวชาญในอุตสาหกรรม | ทีม Chrome ที่มีส่วนร่วมกับหน่วยงานมาตรฐานขาดความเชี่ยวชาญในระบบนิเวศโฆษณาที่จำเป็นต่อการรักษาสมดุลระหว่างความเป็นส่วนตัวกับประโยชน์ใช้สอยอย่างเหมาะสม | เราตระหนักดีว่าเรามีหน้าที่รับผิดชอบที่ยิ่งใหญ่และอาศัยความคิดเห็นที่เจาะจงเพื่อแก้ปัญหานี้ นอกจากนี้ เรายังถือว่าทั้งความเป็นส่วนตัวและประสิทธิภาพเป็นเกณฑ์การออกแบบที่สำคัญและจำเป็น ในทีมที่ทำงานเกี่ยวกับ Privacy Sandbox สำหรับเว็บมียอดรวมปีทั้งหมดในระบบนิเวศของโฆษณาอยู่ในหลักร้อย |
แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง
หัวข้อ
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| ความมีประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ | มีผู้หยิบยกข้อกังวลเกี่ยวกับมูลค่าที่สร้างขึ้นและการกระจายค่านั้นสำหรับเว็บไซต์โดยขึ้นอยู่กับระดับการเข้าชมหรือความชำนาญเฉพาะทางของเนื้อหา | เราจะสำรวจประโยชน์ของ API ผ่านการทดสอบ Chrome คาดหวังว่าการจัดหมวดหมู่และพารามิเตอร์อื่นๆ จะเปลี่ยนแปลงไปตามผลการทดสอบ วิวัฒนาการของการจัดหมวดหมู่หรือพารามิเตอร์อาจไม่จำเป็นต้องมีการเปลี่ยนแปลงที่เข้ากันไม่ได้แบบย้อนหลัง นอกจากนี้ Chrome คาดว่าผลตอบรับจะยังคงมีผลต่อวิวัฒนาการของ Topics API ต่อไปหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
| การจัดหมวดหมู่ | ผู้มีส่วนเกี่ยวข้องในอุตสาหกรรมต้องการมีเสียงในการโน้มน้าวการจัดหมวดหมู่ | Chrome จะยังคงเปิดไว้เพื่อป้อนในการจัดหมวดหมู่ Chrome สนใจฟังความคิดเห็นเรื่องโมเดลการกำกับดูแลในการแก้ไขการจัดหมวดหมู่นี้ และพูดคุยถึงวิธีที่องค์กรอื่นๆ ในอุตสาหกรรมจะมีบทบาทสำคัญในการพัฒนาและดูแลรักษาการจัดหมวดหมู่ในระยะยาว |
| ประวัติการท่องเว็บไม่เพียงพอ | ข้อเสนอเพื่อแสดงหัวข้อที่ผู้โทรเห็นในสัปดาห์ก่อนหน้าหากผู้ใช้มีประวัติการท่องเว็บไม่เพียงพอที่จะสร้าง 5 หัวข้อสำหรับสัปดาห์ล่าสุด | สำหรับดีไซน์ปัจจุบันของเรา เราเลือกแบบสุ่ม เราจะตรวจสอบความสัมพันธ์กับหัวข้อที่ผ่านมาและพิจารณาว่าจะเป็นไปได้หรือไม่ที่จะรวมสิ่งเหล่านี้ไว้ด้วย อย่างไรก็ตาม ความสัมพันธ์อาจต้องมีข้อควรพิจารณาด้านความเป็นส่วนตัวที่เป็นลบ |
| เรียกใช้ Topics ในนามของผู้เผยแพร่โฆษณา | ผู้ให้บริการบุคคลที่สามแชร์ Topics กับผู้เผยแพร่โฆษณาได้ไหม | ใช่ นี่คือวิธีที่เราคาดว่าจะมีการใช้ Topics |
| เวกเตอร์การโจมตีที่เป็นไปได้ | ระบุหัวข้อที่มีเสียงดัง | จากความคิดเห็นมากมายในระบบนิเวศ Chrome จึงเลือกที่จะกรองหัวข้อและแทรกข้อมูลรบกวน เราตัดสินใจเหล่านี้โดยคำนึงถึงความเป็นส่วนตัว เพื่อจำกัดการเข้าถึงข้อมูลให้แก่ผู้ที่ไม่มีสิทธิ์เข้าถึงข้อมูลดังกล่าว และทำให้เกิดการปฏิเสธที่เป็นไปได้สำหรับผู้ใช้ตามลำดับ เราตระหนักดีว่าการตัดสินใจดังกล่าวมีข้อด้อย เช่น เวกเตอร์การโจมตีที่แสดงที่นี่ อย่างไรก็ตาม เราประเมินได้ว่าประโยชน์ด้านความเป็นส่วนตัวมีน้ำหนักมากกว่าความเสี่ยงที่อาจเกิดขึ้น เรายินดีรับฟังความคิดเห็นสาธารณะเกี่ยวกับการตัดสินใจนี้ |
| การมีสิทธิ์รับช่วงทดลองใช้จากต้นทาง | มีวิธีตรวจสอบว่าผู้ใช้มีสิทธิ์ทดลองใช้จากต้นทางหรือไม่ | ฟีเจอร์ช่วงทดลองใช้จากต้นทางอาจใช้ไม่ได้สำหรับผู้ใช้ เนื่องจากการตั้งค่าเบราว์เซอร์หรือปัจจัยอื่นๆ แม้ว่าผู้ใช้จะเข้าชมหน้าเว็บที่ให้โทเค็นช่วงทดลองใช้ที่ถูกต้อง และเบราว์เซอร์ของผู้ใช้จะรวมอยู่ในกลุ่มที่เปิดใช้ช่วงทดลองใช้
ด้วยเหตุนี้ คุณจึงควรใช้การตรวจหาฟีเจอร์เพื่อตรวจสอบว่าฟีเจอร์ช่วงทดลองใช้จากต้นทางพร้อมใช้งานเสมอหรือไม่ ก่อนที่จะลองใช้ |
| ผลกระทบต่อประสิทธิภาพ | ข้อกังวลเกี่ยวกับค่าใช้จ่ายและเวลาในการตอบสนองของ Topics | เราขอความคิดเห็นเกี่ยวกับแนวทางในการหลีกเลี่ยง iframe แบบ x-Origin ที่มีราคาแพงและเสนอที่จะแก้ไขความแตกต่างกับ Topics API โดยการทำให้หัวข้อไม่เปลี่ยนสถานะการท่องเว็บ |
| ฟังก์ชันการทำงานของ Split Topics API | ช่วยให้ควบคุม API ทั้ง 3 ด้านได้มากขึ้น | เราเข้าใจกรณีการใช้งานและได้เสนอวิธีแก้ปัญหานี้ที่เป็นไปได้ใน GitHub ขณะนี้เรากำลังรอความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าจะสร้างฟังก์ชันการทำงานดังกล่าวหรือไม่ ดูการสนทนาที่กำลังดำเนินอยู่ที่นี่ |
| ไทม์ไลน์และเอกสารประกอบของตัวแยกประเภท | นักพัฒนาซอฟต์แวร์ได้ขอข้อมูลเพิ่มเติมเกี่ยวกับตัวแยกประเภท | เราได้ให้ข้อมูลเพิ่มเติมเกี่ยวกับตัวแยกประเภทต่อสาธารณะที่นี่
รวมถึงที่นี่ และที่นี่ |
| การควบคุมและความปลอดภัยของผู้ใช้ | บางหัวข้ออาจส่งผลดีต่อกลุ่มที่ไวต่อมลพิษทางอากาศและผู้ใช้ต้องการการควบคุมเพิ่มเติมเพื่อป้องกันผลลัพธ์เชิงลบ | หัวข้อแสดงถึงความก้าวหน้าที่สำคัญสำหรับการควบคุมของผู้ใช้และความโปร่งใส ผู้ใช้สามารถเลือกไม่ใช้หัวข้อ ตรวจสอบหัวข้อที่ได้รับมอบหมาย นำหัวข้อออก และทำความเข้าใจว่าบริษัทใดที่โต้ตอบกับหัวข้อของตนในหน้าเว็บหนึ่งๆ นอกจากนี้ ผู้ใช้ยังสร้างผลกระทบต่อ Topics ของตนได้โดยการลบประวัติการท่องเว็บ เรายินดีพูดคุยกับคุณอย่างต่อเนื่องเกี่ยวกับการควบคุมของผู้ใช้ขั้นสูง เช่น การควบคุมที่นักพัฒนาซอฟต์แวร์แนะนำ อย่างไรก็ตาม เราจำเป็นต้องตรวจสอบว่าสำหรับข้อกังวลที่แจ้งในข้อบกพร่องนี้ เป็นการขจัดความเสี่ยงออกไปจริงๆ (เช่น การลบเฉพาะหัวข้อ "การศึกษาภาษาต่างประเทศ" ออก แต่ไม่รวมเว็บไซต์ที่สร้างหัวข้อจากประวัติการท่องเว็บไม่ได้ปกป้องผู้ใช้อย่างเต็มที่) |
| การใช้หัวข้อในเว็บไซต์ที่มี prebid.js | Topics API สามารถใช้ในเว็บไซต์ที่มี prebid.js ได้ไหม | คำตอบสั้นๆ คือ "ได้" มีการเผยแพร่ข้อมูลเพิ่มเติมที่นี่ |
| การใช้ Topics API ในวิดเจ็ตคำแนะนำ | เราใช้ Topics API ในวิดเจ็ตแนะนำได้ไหม (เช่น Outbrain) | เราไม่จำกัด Use Case ของ Topics ที่ดึงข้อมูลหลังจากมีการเรียก API (ซึ่งขึ้นอยู่กับนโยบายข้อมูลของนักพัฒนาซอฟต์แวร์แต่ละราย) |
| ความเป็นส่วนตัว / นโยบาย | คำถามที่ใช้กรองคำตอบตามผู้โทร ในกรณีที่บุคคลที่สามบางรายจะแชร์หัวข้อของตนกับทุกคนที่โทรมา | ตามความคิดเห็นจากหลายคนในระบบนิเวศ Chrome เลือกการออกแบบนี้เพื่อจำกัดการเข้าถึงข้อมูลไว้เฉพาะผู้ที่ไม่มีสิทธิ์เข้าถึงข้อมูลดังกล่าว แน่นอนว่าผู้เผยแพร่และบุคคลที่สามที่ได้รับ Topics สามารถตัดสินใจได้เองว่าจะเปิดเผยข้อมูลใดในเว็บไซต์ของตน หากผู้ใช้ทำการแชร์ประเภทนี้ Chrome สนับสนุนอย่างยิ่งให้แจ้งให้ผู้ใช้ทราบเกี่ยวกับการแชร์ดังกล่าวอย่างโปร่งใสและเสนอการควบคุม |
| สัญญาณเสียงดัง | การส่งหัวข้อแบบสุ่ม 5% จากทั้งหมดอาจสร้างสัญญาณรบกวน / สัญญาณผิดมากเกินไป | เสียงรบกวนเป็นวิธีสำคัญในการปกป้องความเป็นส่วนตัวของผู้ใช้ โดยจะทดสอบระดับเสียงรบกวนเทียบกับความมีประโยชน์ของหัวข้อ |
FLEDGE
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| การประสานงานการทดสอบ | การทดสอบผลกระทบด้านประสิทธิภาพและรายได้ | ประสิทธิภาพของ FLEDGE และวิธีที่เราสามารถสนับสนุนการทดสอบระบบนิเวศได้อย่างดีที่สุดระหว่างช่วงทดลองใช้จากต้นทางรวมถึงความพร้อมให้บริการทั่วไป กําลังมีการหารือกันอย่างจริงจังในการประชุม WICG สาธารณะ |
| เซิร์ฟเวอร์ที่เชื่อถือได้สำหรับ FLEDGE | เซิร์ฟเวอร์ที่เชื่อถือได้จะพร้อมสำหรับการทดสอบเมื่อใด | เราขอขอบคุณสำหรับความคิดเห็นนี้ และกำลังดำเนินการกับแผนที่มีรายละเอียดเพิ่มเติมซึ่งเราสามารถแชร์ได้สำหรับการใช้เซิร์ฟเวอร์ที่เชื่อถือได้ใน FLEDGE |
| การกำหนดมาตรฐานโปรโตคอล | จะมีโปรโตคอลทั่วไปสำหรับการส่งผ่านข้อมูลระหว่าง SSP กับ DSP เช่น ป้ายกำกับทั่วไปสำหรับกลุ่มความสนใจไหม | เรายินดีรับฟังความคิดเห็นจาก DSP, SSP และระบบนิเวศโฆษณาที่กว้างขึ้นเกี่ยวกับความเป็นไปได้ของการกำหนดมาตรฐานสำหรับข้อกำหนด สำหรับวัตถุประสงค์ของการทดสอบเบื้องต้นในขณะนี้ เราขอแนะนำให้คุณทำงานร่วมกับพาร์ทเนอร์การทดสอบโดยตรงเนื่องจากอยู่ในระหว่างการทดสอบกับแนวทางที่แตกต่างกัน นอกจากนี้ เรายังสนับสนุนและวางแผนที่จะทำงานร่วมกับองค์กรการค้า Google Ads เพื่อชั่งน้ำหนักในการสร้างมาตรฐานด้วย ในกรณีที่องค์กรดังกล่าวมีประโยชน์ต่อบริษัทสมาชิก |
| การกำหนดความถี่สูงสุด | การควบคุมความถี่ต่อผู้ใช้ภายในแคมเปญและกลุ่มโฆษณา | FLEDGE จะรองรับการกำหนดความถี่สูงสุดสำหรับการประมูลในอุปกรณ์และแคมเปญตามบริบท / การสร้างแบรนด์ด้วยเช่นกัน นอกจากนี้ พื้นที่เก็บข้อมูลที่ใช้ร่วมกันและความถี่สูงสุดเฉพาะเว็บไซต์ยังใช้สำหรับการควบคุมการกำหนดความถี่สูงสุดเพิ่มเติมได้ |
| ผลกระทบของ FLEDGE ต่อประสิทธิภาพ | ผู้เสนอราคาที่ใช้การคำนวณอย่างหนักในการประมูล FLEDGE | Chrome อยู่ระหว่างการหารือกับนักพัฒนาซอฟต์แวร์อยู่เสมอเกี่ยวกับผลกระทบที่อาจเกิดขึ้นกับประสิทธิภาพของเว็บไซต์ Chrome เปิดโอกาสให้คุณได้เรียนรู้เพิ่มเติมในระหว่างการทดสอบ |
| การทดสอบ FLEDGE กับฟีเจอร์อื่นๆ | รายงานระดับเหตุการณ์จาก Attribution Reporting API และ FLEDGE จะเข้ากันได้อย่างไร | ซึ่งมีการพูดคุยกันในการโทร WICG/conversion-measurement-api ล่าสุด พร้อมลิงก์ไปยังนาทีโดยละเอียดที่นี่
ข้อมูลสรุปการประชุมคือ การออกแบบการรายงานโฆษณาเฟรมที่มีการปิดกั้นในปัจจุบันทำให้เชื่อมโยงรหัสที่สร้างขึ้นภายในเฟรมที่ล้อมรอบกับข้อมูลตามบริบทได้ ดังนั้นรายงานระดับเหตุการณ์ที่สร้างขึ้นภายใน Fenced Frame จะสามารถผนวกเข้ากับข้อมูลตามบริบทเดียวกันบนเซิร์ฟเวอร์ (โดยใช้การผนวกฝั่งเซิร์ฟเวอร์ 2 รายการแทน 1) |
| การนับจำนวนการแสดงผล | ควรหรือสามารถใช้วิธีนับการแสดงผลใดระหว่างผู้ซื้อและผู้ขาย | FLEDGE API รองรับการตรวจสอบวิธีการที่สอดคล้องกันระหว่างผู้ขายและผู้ซื้อระหว่างการประมูลอยู่แล้ว เราได้รับคำแนะนำเกี่ยวกับการติดตั้งใช้งานอื่นๆ โดยไม่มีความคิดเห็นเกี่ยวกับเหตุผลที่การออกแบบปัจจุบันของเราใช้งานไม่ได้กับระบบนิเวศ |
| การแสดงโฆษณาหลายรายการ | กำหนดว่าโฆษณาหนึ่งๆ จะแสดงโฆษณาหลายรายการในการประมูลครั้งเดียวในเฟรมที่มีการปิดกั้นได้หรือไม่ | ซึ่งปัจจุบันทำได้ผ่านโฆษณาคอมโพเนนต์ (อย่าสับสนกับการประมูลแบบคอมโพเนนต์) โดยโฆษณาทั้งหมดต้องอยู่ในกลุ่มความสนใจเดียวกัน |
| ข้อกำหนด "กลุ่มเป้าหมายที่กำหนดโดยผู้ขาย (SDA)" และ FLEDGE | FLEDGE จะกลายเป็นกลไกในการป้องกันไม่ให้ผู้ซื้อสร้างโปรไฟล์จาก SDA ในคำขอโฆษณาได้ไหม | FLEDGE ออกแบบมาเพื่อหลีกเลี่ยงการรั่วไหลของข้อมูลที่ไม่เกี่ยวข้องเมื่อผู้เผยแพร่โฆษณารู้อยู่แล้วว่า SDA ใดอยู่ในเว็บไซต์ และการกำหนดเป้าหมายเป็นเว็บไซต์เดียวกัน หากการสนับสนุนการซื้อบน SDA ภายใต้การป้องกันทั้งหมดที่สร้างขึ้นใน FLEDGE เป็นสิ่งสำคัญ โซลูชันหนึ่งอาจเป็นสำหรับผู้ขายในการส่งป้ายกำกับ SDA ไปยังการประมูลในอุปกรณ์ และเทคโนโลยีโฆษณาฝั่งซื้อเพื่อสร้างกลุ่มความสนใจของตนเอง ซึ่งมีตรรกะการเสนอราคาระบุว่า "ฉันต้องการซื้อกลุ่มเป้าหมาย X" |
| การรองรับสกุลเงินที่ไม่ใช่ USD | การรองรับการทดสอบ FLEDGE กับสกุลเงินที่นอกเหนือจาก USD | เราให้ความสำคัญกับข้อความไฮไลต์นี้ และเราได้เพิ่มการสร้างเพื่อรองรับสกุลเงินอื่นๆ ใน Backlog ของคำขอฟีเจอร์ เราหวังว่าฟีเจอร์ดังกล่าวจะพร้อมใช้งานเร็วๆ นี้ |
| การรองรับการกำหนดเป้าหมายกลุ่มความสนใจเชิงลบ | API เพื่อรองรับการกำหนดเป้าหมาย IG เชิงลบ: แสดงโฆษณาเฉพาะในกรณีที่ผู้ใช้ไม่ได้อยู่ใน IG | การสนทนาที่กำลังดำเนินอยู่ ซึ่งรวมถึงตัวเลือกที่มีให้รับการสนับสนุนในปัญหาเกี่ยวกับ GitHub |
| SSP หลายรายการใน FLEDGE | ความเสี่ยงที่จะสนับสนุน Google เมื่อใช้การประมูลหลายระดับใน FLEDGE | เพิ่มการรองรับ SSP หลายรายการใน FLEDGE เพื่อสร้างวงการเกมที่ยุติธรรมและเสมอภาค Google ได้ให้สัญญาภายใต้สัญญาผูกมัดที่จะไม่ออกแบบ พัฒนา หรือปรับใช้ข้อเสนอ Privacy Sandbox ในลักษณะที่จะบิดเบือนการแข่งขันโดยการแนะนำผลิตภัณฑ์และบริการโฆษณาของตนด้วยตัวเอง Google ให้ความสำคัญกับเรื่องนี้อย่างมาก และเปิดกว้างที่จะพูดคุยถึงข้อกังวลใดๆ ที่ผู้มีส่วนเกี่ยวข้องอาจมีเกี่ยวกับแง่มุมเฉพาะของเทคโนโลยี Chrome ได้จัดทำข้อมูลกลไกการประมูลคอมโพเนนต์ไว้สู่สาธารณะที่นี่เพื่อดูข้อมูล |
การวัดผลโฆษณาดิจิทัล
Attribution Reporting (และ API อื่นๆ)
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| การระบุแหล่งที่มาแบบมัลติทัช | ผู้เผยแพร่โฆษณาที่ขอการสนับสนุนสำหรับการระบุแหล่งที่มาแบบมัลติทัช | วิธีการระบุแหล่งที่มาแบบมัลติทัชในปัจจุบันจำเป็นต้องมีการเชื่อมโยงการแสดงผลของผู้ใช้ (และข้อมูลระบุตัวตน) ในเว็บไซต์ต่างๆ เข้าด้วยกัน ดังนั้น ฟังก์ชันการทำงานนี้ในรูปแบบปัจจุบันไม่สอดคล้องกับเป้าหมายของ Privacy Sandbox ซึ่งมีจุดประสงค์เพื่อสนับสนุนกรณีการใช้งานโฆษณาหลักโดยไม่ต้องมีการติดตามข้ามเว็บไซต์ ในบางกรณี การประเมินมูลค่าเครดิตโดยประมาณ (เช่น การใช้ลำดับความสำคัญแบบสุ่มแบบถ่วงน้ำหนัก) สามารถทำได้โดยไม่ต้องติดตามผู้ใช้แต่ละราย |
| การสร้างเสียงรบกวน | คำถามเกี่ยวกับระดับสัญญาณรบกวนภายในรายงาน | การทดสอบในช่วงแรกให้นักพัฒนาซอฟต์แวร์ตั้งค่า epsilon ของตนเองเพื่อให้ทราบถึงการเปลี่ยนแปลงของรายงานตามระดับสัญญาณรบกวน ขณะนี้ นักพัฒนาซอฟต์แวร์สามารถเลือกค่า epsilon ได้สูงสุด epsilon=64 เราทำเช่นนี้โดยเฉพาะเพื่อให้นักพัฒนาซอฟต์แวร์ทดสอบ API และให้ความคิดเห็นเกี่ยวกับค่า epsilon ที่เหมาะสมได้ง่ายขึ้น
และยังได้ยื่นคำขอแบบสาธารณะสำหรับความคิดเห็นดังกล่าวด้วย |
| การประสานงานการทดสอบ | ใช้เครื่องมือทดสอบในเครื่องสำหรับ OT ได้ไหม | ได้ คุณใช้เครื่องมือทดสอบในเครื่องได้ในช่วงที่มีเวลา OT สามารถใช้เครื่องมือทดสอบในเครื่องกับรายงานการแก้ไขข้อบกพร่องได้ตราบใดที่คุกกี้ของบุคคลที่สามพร้อมใช้งาน |
| การค้นหาตามหลักการยศาสตร์ | เปิดใช้การค้นหาการรวมคีย์ | เรายอมรับว่าสิ่งนี้ดูเหมือนจะช่วยปรับปรุงหลักการยศาสตร์ของ API โดยมีค่าใช้จ่ายด้านความเป็นส่วนตัวน้อยมากหรือไม่มีเลย เราจะจัดทำข้อเสนอและพิจารณาความเห็นพ้องกันในวงกว้างว่าควรสนับสนุนไหม |
| ข้อมูลที่แม่นยำน้อยลงสำหรับเว็บไซต์ขนาดเล็ก | เว็บไซต์หรือแคมเปญขนาดเล็กอาจได้รับข้อมูลที่มีความแม่นยำน้อย | Chrome ตระหนักดีว่าการคุ้มครองความเป็นส่วนตัวแบบใช้เสียงรบกวนจะส่งผลกระทบมากกว่าต่อชิ้นส่วนข้อมูลที่มีขนาดเล็กกว่า อย่างไรก็ตาม เป็นไปได้ว่าวิธีการต่างๆ อย่างเช่นการรวมข้อมูลในช่วงเวลาที่นานขึ้นจะแก้ไขปัญหานี้ได้ และเรายังไม่ชัดเจนว่าข้อสรุปที่อิงตามชิ้นส่วนข้อมูลขนาดเล็กมากๆ (เช่น การซื้อ 1-2 รายการ) มีความหมายต่อผู้ลงโฆษณาหรือไม่ ระหว่างช่วงทดลองใช้จากต้นทาง Chrome สนับสนุนให้ผู้ทดสอบใช้ประโยชน์จากความสามารถในการทดสอบกับพารามิเตอร์ความเป็นส่วนตัวและพารามิเตอร์เสียงรบกวนที่หลากหลายเพื่อให้ความคิดเห็นที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับปัญหานี้ |
จำกัดการติดตามแบบไม่เปิดเผย
การลด User Agent
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| การป้องกันบ็อต | ผลกระทบของ UA-R ที่มีต่อการปกป้องบ็อต | เราขอขอบคุณสำหรับความคิดเห็นนี้ และขณะนี้เรากำลังรวบรวมข้อมูลเกี่ยวกับแนวทางการป้องกันบ็อตเพื่อเป็นแนวทางในการออกแบบในอนาคต |
| ทรัพยากร Dependency ของการติดตั้งใช้งาน | การจัดการทรัพยากร Dependency ของการทำให้ใช้งานได้ของ Structured User Agent (SUA) | เราได้เปิดตัว "ระยะที่ 4" ซึ่งเป็นการลดเวอร์ชันย่อยให้เหลือ 100% ของผู้ใช้ Chrome ในเวอร์ชัน 101 ขึ้นไป ดูข้อมูลอัปเดตที่นี่ |
คำแนะนำไคลเอ็นต์ User Agent
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| แจกแจงคำแนะนำที่รองรับทั้งหมด | สนใจใช้วิธีแบบเป็นโปรแกรมเพื่อให้ทราบคำแนะนำทั้งหมดที่รองรับสำหรับเบราว์เซอร์ | ขอขอบคุณเป็นอย่างยิ่งสำหรับความคิดเห็นดังกล่าว และขณะนี้อยู่ระหว่างการประเมินคำขอฟีเจอร์ เราต้องการทำความเข้าใจว่ากรณีเช่นนี้เป็นกรณีทั่วไปหรือไม่ |
| ความยืดหยุ่นของส่วนหัว UA-CH เทียบกับ User-Agent | UA-CH มีการกำหนดไว้มากเกินไปเมื่อเทียบกับความยืดหยุ่นที่ส่วนหัว User-Agent มีให้ ตามที่กำหนดไว้ใน rfc7231 | Chrome มองว่าลักษณะของส่วนหัว UA-CH ที่กำหนดไว้เป็นการปรับปรุงที่สำคัญเหนือความยืดหยุ่นของสตริง UA ทั้งจากมุมมองของความสามารถในการทำงานร่วมกันข้ามเบราว์เซอร์และการปกป้องความเป็นส่วนตัวของผู้ใช้ในท้ายที่สุด (โดยการป้องกันการเพิ่มตัวระบุเอนโทรปีสูงโดยอิสระ)
ปัญหานี้ยังคงดำเนินต่อไปในกรณีที่มีผู้อื่นแชร์ข้อกังวลนี้และต้องการแสดงความคิดเห็น |
| UA-CH: ข้อกังวลเกี่ยวกับการต่อต้านการฉ้อโกง / ต่อต้านการละเมิด | ฟีเจอร์บางอย่างที่อาจสูญหายผ่านทาง UA-CH ได้แก่ เครื่องมือติดตามการเปลี่ยนเส้นทางคลิก และการคลิกที่เป็นการฉ้อโกง | ทีมของเรากำลังตรวจสอบปัญหาที่อาจเกิดขึ้นกับผู้มีส่วนเกี่ยวข้องในการต่อต้านการประพฤติมิชอบและการวัดผล |
| การแสดง | มีความกังวลเกี่ยวกับเวลาในการตอบสนองของการได้รับคำแนะนำผ่าน Critical-CH (ในการโหลดหน้าเว็บแรก) | Chrome กำลังหาวิธีปรับปรุงประสิทธิภาพ |
กแนตแคตเชอร์ (WIP)
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| ข้อกังวลเกี่ยวกับเวลาในการตอบสนอง | การเพิ่มการ Hop เพิ่มเติมอาจส่งผลต่อเวลาในการตอบสนอง | เรากำลังพิจารณา Hop Proxy แบบ 2 แบบและสำรวจหาวิธีในการหาจุดสมดุลระหว่างความเป็นส่วนตัวของผู้ใช้และเวลาในการตอบสนอง เรายินดีรับฟังความคิดเห็นและอยากพูดคุยเพิ่มเติมในฟอรัม W3C |
| การป้องกันการประพฤติมิชอบและบ็อต | ผลกระทบต่อการประพฤติมิชอบและการปกป้องบ็อต ซึ่งรวมถึงในประเทศที่พัฒนาไปไม่มากนัก | ความปลอดภัยเป็นข้อกำหนดหลักเนื่องจากเรามองหาวิธีปรับปรุงความเป็นส่วนตัวของผู้ใช้ในลักษณะที่มีความหมาย เช่น การใช้ที่อยู่ IP ผ่านพร็อกซี พร็อกซี 2 ฮอพที่เป็นพาร์ทเนอร์กับบริษัทชื่อดังมอบความเป็นส่วนตัวของผู้ใช้ที่ยืนยันได้ นอกจากนี้ เรายังกำลังบ่มเพาะแนวคิดสำหรับสัญญาณใหม่ๆ เพื่อถ่ายทอดความไว้วางใจของผู้ใช้อีกด้วย |
| การปฏิบัติตามกฎหมายท้องถิ่นด้านความเป็นส่วนตัว | การรายงานข้อมูลทางภูมิศาสตร์ระดับประเทศทำให้การปฏิบัติตามกฎระเบียบท้องถิ่นที่ละเอียดยิ่งขึ้นทำได้ยาก | เราได้โพสต์หลักการที่เราเสนอต่อสาธารณะ ซึ่งรวมถึงแนวทางที่เป็นไปได้ที่จะช่วยให้เว็บไซต์ยังคงปฏิบัติตามข้อกำหนดในพื้นที่ |
ขยายขอบเขตความเป็นส่วนตัวแบบข้ามเว็บไซต์
ชุดโดเมนของบุคคลที่หนึ่ง
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| ความมีประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ | ผลกระทบของ FPS สำหรับผู้เผยแพร่โฆษณารายเล็กเทียบกับรายใหญ่ | เป้าหมายหลักของ Privacy Sandbox คือปรับปรุงความเป็นส่วนตัวของผู้ใช้โดยการแทนที่แนวทางปฏิบัติปัจจุบันด้วยโซลูชันที่ไม่ได้อาศัยกลไกการติดตามข้ามเว็บไซต์ เราต้องการให้โซลูชันเหล่านี้มีประโยชน์ในวงกว้างที่สุดเท่าที่จะเป็นไปได้สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ และทุกขนาด เรายินดีรับฟังข้อมูลที่เจาะจงและนำไปปฏิบัติได้เกี่ยวกับวิธีปรับปรุงโซลูชันเหล่านี้ และเราหวังว่าโซลูชันจะพัฒนาต่อไปตามการสนทนาและการทดสอบของชุมชน |
| การปรับปรุงความเป็นส่วนตัว | การมีเว็บไซต์ในชุดเดียวกันมากเกินไปอาจทำให้เกิดผลลัพธ์คล้ายกับคุกกี้ของบุคคลที่สาม | เราขอขอบคุณสำหรับความคิดเห็นนี้ และขณะนี้เรากำลังประเมินว่าขีดจำกัดที่เหมาะสมจะเป็นอย่างไร ขณะเดียวกันก็พยายามให้การดูแลแก่ผู้ใช้และนักพัฒนาซอฟต์แวร์ทราบเมื่อมีการดำเนินการถึงขีดจำกัดดังกล่าว เรายังไม่มีข้อเสนอแบบเจาะจงที่จะแจ้งให้ทราบ แต่หวังว่าจะได้พูดคุยกันเร็วๆ นี้ |
| การรองรับ FPS ในระบบนิเวศ | การสนับสนุนและข้อกังวลสำหรับการพัฒนา FPS ภายนอก CG ด้านความเป็นส่วนตัวอย่างต่อเนื่อง | แม้ว่าเราจะอยากให้ข้อเสนอชุดโดเมนของบุคคลที่หนึ่งยังคงอยู่ใน PrivacyCG แต่เราหวังเป็นอย่างยิ่งว่าจะดำเนินการตามข้อเสนอใน WICG ต่อไป เรายังได้รับการสนับสนุนจากข้อความสนับสนุนจำนวนมากให้พูดคุยเกี่ยวกับชุดโดเมนของบุคคลที่หนึ่งอย่างต่อเนื่อง รวมถึงกรณีการใช้งานที่มีจุดประสงค์เพื่อแก้ไขปัญหานี้ Google ยังคงมุ่งมั่นค้นหาโซลูชันที่ช่วยให้เว็บเติบโตและเติบโตอย่างต่อเนื่องด้วยวิธีที่ปกป้องและเคารพความเป็นส่วนตัวของผู้ใช้ |
| ความสามารถในการทำงานร่วมกันของเบราว์เซอร์ | การใช้งานโดยเบราว์เซอร์อื่นๆ | เราตระหนักถึงความสำคัญของความสามารถในการทำงานร่วมกันของเบราว์เซอร์สำหรับนักพัฒนาซอฟต์แวร์ และจะทำงานร่วมกับเบราว์เซอร์อื่นๆ ต่อไปเพื่อกำหนด FPS มาตรฐาน |
| ข้อกำหนดทั่วไปของนโยบายความเป็นส่วนตัว | เป็นไปไม่ได้ที่จะคงไว้ซึ่งนโยบายความเป็นส่วนตัวที่เหมือนกันสำหรับผลิตภัณฑ์ทั้งหมดและเขตอำนาจศาลที่ต้องอยู่ในชุดเดียวกัน | Chrome ยังคงกำหนดข้อกําหนดของนโยบายของเราและคํานึงถึงความคิดเห็นนี้ |
Fenced Frames API
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| คำขอเอกสาร | ความแตกต่างกับ iframe ที่ทำแซนด์บ็อกซ์ | ขอขอบคุณสำหรับความคิดเห็นและคำแนะนำ ตอนนี้มีการพูดคุยถึงเรื่องนี้ใน GitHub ซึ่งเราหวังว่าจะได้รับความชัดเจนขั้นสุดท้ายเกี่ยวกับคำขอเพื่อให้ประเมินได้อย่างสมบูรณ์ สามารถอ่านการสนทนาแบบสาธารณะได้ที่นี่ |
| ความสามารถข้าม API | การรองรับเริ่มต้นของการรายงานการระบุแหล่งที่มาใน Fenced Frame | เรากำลังขอความคิดเห็นเกี่ยวกับข้อเสนอเพื่ออนุญาต Attribution Reporting API ใน "โหมดโฆษณาแบบทึบ" ในเฟรมที่มีการปิดกั้นโดยค่าเริ่มต้น เราขอแนะนำให้นักพัฒนาซอฟต์แวร์ที่เห็นว่าสิ่งนี้มีประโยชน์มาแสดงความคิดเห็น |
API พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| ขีดจำกัดของข้อมูล | จะมีข้อจำกัดไหมว่าสามารถจัดเก็บข้อมูลได้เท่าใดต่อพาร์ติชัน | มี จะมีขีดจำกัด ดูรายละเอียดเพิ่มเติมได้ที่ปัญหาเกี่ยวกับ GitHub เราต้องการโควต้าพื้นที่เก็บข้อมูล ข้อเสนอปัจจุบันของเราคือกำหนดขีดจำกัดสูงสุดต่อรายการไว้ที่ 4 KB ทั้งคีย์และค่าจะจำกัดอยู่ที่ 1,024 char16_t อักขระต่อครั้ง และจำกัดรายการข้อมูลต่อต้นทางที่ 10,000 รายการ โดยมีกลไกที่ป้องกันไม่ให้มีการดำเนินการป้อนรายการเพิ่มเติมเมื่อความจุของต้นทางเต็ม เราต้องการความคิดเห็นเกี่ยวกับขีดจำกัดเฉพาะที่เสนอมาที่นี่ |
| ความโปร่งใสสำหรับผู้ใช้ | ความโปร่งใสของผู้ใช้เกี่ยวกับแหล่งข้อมูลและการใช้ข้อมูล | เราขอขอบคุณสำหรับความคิดเห็นของคุณ และเราคิดว่านี่เป็นวิธีการที่น่าสนใจที่ควรค่าแก่การสำรวจ โดยเฉพาะอย่างยิ่ง เรากำลังประเมินว่าจะสามารถทำได้โดยให้มีความโปร่งใสเพียงพอต่อผู้ใช้หรือไม่ |
ชิป
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| อุปสรรคในการรับบุตรบุญธรรม | CHIPS ควรเชื่อมโยงกับชื่อโฮสต์หรือไม่ (ข้อกำหนด "ไม่มีโดเมน) | เราจะนำข้อกำหนดนี้ออกจาก OT ตามความคิดเห็นจากผู้เข้าร่วม OT ว่าข้อกำหนดนี้เพิ่มความซับซ้อนเพิ่มเติมและเป็นอุปสรรคต่อการนำ CHIPS ไปใช้
เราจะพูดคุยถึงข้อกำหนดนี้ในกลุ่มชุมชนความเป็นส่วนตัวในฐานะส่วนหนึ่งของการบ่มเพาะมาตรฐานที่นี่ |
| กรณีการใช้งานโฆษณาสำหรับ CHIPS | CHIPS จะใช้กับ Use Case ของโฆษณาในเว็บไซต์เดียวได้ไหม | กรณีการใช้งานที่อนุญาตการติดตามผู้ใช้ภายในเว็บไซต์เดียว เราได้ อัปเดตบทความสำหรับนักพัฒนาซอฟต์แวร์เพื่อไฮไลต์กรณีการใช้งานนี้ |
| การฝังที่ตรวจสอบสิทธิ์แล้ว | CHIPS มีการเก็บรักษาสถานะการลงชื่อเข้าใช้ไว้ด้วย CHIPS ไหม | ขณะนี้ระบบไม่ได้เก็บรักษาสถานะที่ลงชื่อเข้าใช้ไว้ แต่ไม่ใช่ Use Case ที่ตั้งใจสำหรับ CHIPS เราทราบกรณีการใช้งานแบบฝังที่ตรวจสอบสิทธิ์แล้วและกำลังดำเนินการสำรวจโซลูชัน |
| การประสานงานการทดสอบ | ผู้ใช้ต้องดำเนินการเพิ่มเติมเพื่อทดสอบการแบ่งพาร์ติชันไหม | ตราบใดที่โทเค็น OT ถูกต้องและแสดงในส่วนหัวของหน้าที่เข้าชม ฟีเจอร์ดังกล่าวควรพร้อมใช้งานสำหรับผู้ใช้ โดยที่ผู้ใช้ไม่ต้องดำเนินการใดๆ เพิ่มเติม |
| ความเข้ากันได้กับเบราว์เซอร์ | ความสนใจในการทำความเข้าใจว่าเบราว์เซอร์อื่นๆ จัดการแอตทริบิวต์คุกกี้ที่แบ่งพาร์ติชันอย่างไร | Chrome ทำงานอย่างต่อเนื่องในกลุ่มมาตรฐานสาธารณะ เช่น W3C เพื่อระบุการออกแบบและการใช้งานที่สามารถทำงานในเบราว์เซอร์ต่างๆ |
FedCM
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| เวกเตอร์การโจมตีที่เป็นไปได้ | เวกเตอร์การโจมตีที่อาจเกิดขึ้นผ่านการตกแต่งลิงก์และการโจมตีแบบเวลา | เรากำลังรวบรวมข้อมูลจากสาธารณะอย่างต่อเนื่องและพยายามหาวิธีการที่เป็นไปได้เพื่อจัดการปัญหานี้ |
| UX ที่จะอนุญาต IdP หลายรายการ | แสดง IdP ได้ครั้งละ 1 รายการเท่านั้น | เราเชื่อมั่นในการสนับสนุน IdP จำนวนมาก และกำลังดำเนินการอย่างเต็มที่เพื่อสนับสนุน |
| การแสดงความรู้สึก | กังวลว่าเนื่องจากเบราว์เซอร์แสดงผลขั้นตอนของข้อมูลประจำตัวแบบรวมศูนย์ จึงยากที่จะจับความแตกต่างเล็กๆ น้อยๆ ทั้งหมดที่ IdP ต้องการนำเสนอให้กับผู้ใช้ของตน | Chrome กำลังสำรวจ รวมถึงการปรับแต่งแบรนด์ (เช่น โลโก้ สี) และการปรับแต่งสตริง (เช่น "เข้าถึงบทความนี้" ซึ่งตรงข้ามกับ "เข้าสู่ระบบด้วย")
Chrome ตระหนักถึงข้อดีข้อเสียและจะยังคงทำงานกับระบบนิเวศนี้ต่อไปเพื่อให้ครอบคลุมมากที่สุดและเพื่อให้สะท้อนความเป็นมาได้มากที่สุด |
| ความเกี่ยวข้องและการทำงานร่วมกัน | มีความกังวลว่าเบราว์เซอร์อื่นๆ จะไม่ปรับใช้หรือใช้งาน FedCM | Chrome ยังทำงานร่วมกับผู้ให้บริการเบราว์เซอร์รายอื่นๆ เพื่อหาวิธีแก้ปัญหาทั่วไปสำหรับการรวมศูนย์ที่ FedID Community Group |
| คำแนะนำในการนำข้อกำหนดของข้อมูลส่วนตัวออกในขั้นตอนการลงชื่อสมัครใช้ | (1) UX ที่แจ้งผู้ใช้ว่าจะเลือก IdP ใด โดยไม่ส่งสัญญาณว่าระบบจะแชร์อีเมล รูปภาพ และชื่อของผู้ใช้จะเคารพความเป็นส่วนตัวมากกว่า
(2) การลงชื่อสมัครใช้ Use-cases-up มีเพียงเล็กน้อยในประสบการณ์การใช้งานของผู้ใช้และการเลือกการอ้างสิทธิ์จาก IdP |
เราเห็นด้วยและกำลังหาวิธีนำความคิดเห็นไปใช้เพื่อให้ผู้ใช้จำนวนมากขึ้นใช้งาน และมีความเป็นมิตรต่อผู้ใช้มากขึ้น |
| การโต้ตอบของผู้ใช้กับ IdP | ความจำเป็นในการโต้ตอบโดยตรงระหว่างผู้ใช้และ IdP หากมีการใช้งานเกินเกณฑ์ความเสี่ยง | เรากำลังตรวจสอบความคิดเห็นนี้อย่างเต็มที่ |
การแบ่งพาร์ติชันสถานะเครือข่าย
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| การแสดง | การแบ่งพาร์ติชันสถานะของเครือข่ายอาจทำให้มีการเชื่อมต่อกับ CDN ที่ใช้ทรัพยากรจำนวนมากเพิ่มขึ้น | เรายังคงตรวจสอบลักษณะด้านประสิทธิภาพของการแบ่งพาร์ติชันสถานะเครือข่าย รวมถึงการวัดแผนการคีย์ในลักษณะต่างๆ ที่เป็นไปได้ เรายังไม่ได้ตัดสินใจระหว่างข้อดีข้อเสียของประสิทธิภาพ ความปลอดภัย และความเป็นส่วนตัว และจำเป็นต้องรวบรวมข้อมูลเพิ่มเติม |
ต่อสู้กับสแปมและการประพฤติมิชอบ
API โทเค็นความน่าเชื่อถือ
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| ความคิดเห็นเกี่ยวกับกฎระเบียบ | ข้อกังวลเกี่ยวกับการลงทุนด้านเวลาและทรัพยากรใน Trust Token โดยไม่มีสัญญาณที่ชัดเจนจากหน่วยงานกำกับดูแลเกี่ยวกับความอยู่รอดในระยะยาว | เป้าหมายของเราคือการสร้างเทคโนโลยีที่เหมาะกับระบบนิเวศ โดยการแสดงความคิดเห็นจากอุตสาหกรรมและหน่วยงานกำกับดูแลที่สำคัญต่อกระบวนการนี้ เราจะปรึกษากับหน่วยงานกำกับดูแลทั่วโลกต่อไประหว่างการพัฒนา Privacy Sandbox และทำให้ข้อเสนอพร้อมใช้งานสำหรับนักพัฒนาซอฟต์แวร์ ซึ่งรวมถึง Trust Token เช่นเดียวกับเทคโนโลยีใหม่ทั้งหมด บริษัทควรตัดสินใจโดยอิงตามการประเมินข้อกำหนดด้านกฎระเบียบของตนเอง |
| ช่วงเวลาเปิดตัว | Trust Token จะเปิดตัวใน GA เมื่อใด | เราแสดงค่าประมาณปัจจุบันสำหรับการนำส่งในไทม์ไลน์สาธารณะบน privacysandbox.com ทันทีที่เราตัดสินใจขั้นสุดท้ายเกี่ยวกับวันที่นำส่งไปยัง GA เราจะโพสต์ข้อมูลสู่สาธารณะผ่านขั้นตอนการเผยแพร่ของ Chrome และอัปเดตลำดับเวลาบนเว็บไซต์ |
| โทเค็นความน่าเชื่อถือเทียบกับโทเค็นอื่นๆ | Trust Token มีบทบาทอย่างไรหากโทเค็นอื่นๆ อยู่ระหว่างการกำหนดมาตรฐาน เช่น โทเค็นเพื่อการเข้าถึงส่วนตัว | เรามีส่วนร่วมในการพูดคุยเกี่ยวกับการกำหนดมาตรฐาน และเป้าหมายของเราคือการปรับให้สอดคล้องกับความพยายามอื่นๆ ให้ได้มากที่สุด ในขณะเดียวกันก็ช่วยให้แต่ละกรณีการใช้งานเทคโนโลยีของคุณมีศักยภาพแตกต่างกันไป เช่น Trust Tokens และ Private Access Token ต่างก็ใช้โปรโตคอล Privacy Pass |
| ขีดจำกัดของข้อมูล | ผู้ออกสูงสุด 2 รายสําหรับการแลกสิทธิ์โทเค็นต่อ 1 หน้าที่อาจจํากัด | เรากำลังมองหาตัวเลือกระยะยาวที่จะช่วยให้บริษัทต่างๆ แลกโทเค็นได้อย่างปลอดภัยโดยไม่ต้องเสี่ยงกับเอนโทรปีของผู้ใช้เพิ่มเติม โดยการแบ่งพาร์ติชันการเข้าถึงการแลกโทเค็น |
| การจำกัดสิทธิ์เข้าถึง | เฉพาะต้นทางที่ได้รับอนุมัติ (และได้รับการยืนยัน/ไม่ได้ปลอมแปลง) เท่านั้นที่จะสามารถยืนยันได้ว่ามีโทเค็นอยู่และแลกสิทธิ์ได้ | เรากำลังค้นหาวิธีการว่าใครจะดูและแลกโทเค็นได้ |
| การรองรับอุปกรณ์ | ทรัพยากร Dependency ของรันไทม์ JavaScript จะจำกัดการใช้งานในอุปกรณ์บางเครื่อง สามารถขยายการสนับสนุน TT เพื่อทำงานกับอุปกรณ์ประเภทอื่นๆ ได้ไหม | นี่คือสิ่งที่เราอาจนำไปพิจารณาเพื่อการพัฒนาในอนาคต และหัวข้อที่เราอยากทราบความคิดเห็นเพิ่มเติมจากนักพัฒนาซอฟต์แวร์ในฟอรัม W3C นอกจากนี้เรายังมีปัญหาที่ยังไม่ได้แก้ไขสำหรับการพูดคุยเกี่ยวกับส่วนหัว HTTP ที่ทำให้เกิดการแลกสิทธิ์โทเค็นซึ่งเราเชิญให้แสดงความคิดเห็น |
| Use Case | ระบุกรณีการใช้งานที่ถูกต้องสำหรับ Trust Token ไม่ได้ ขาดความชัดเจนเกี่ยวกับวัตถุประสงค์การใช้งาน | เป้าหมายของเราคือการอำนวยความสะดวกให้กับการสร้างนวัตกรรมในพื้นที่ป้องกันการฉ้อโกง และเข้าใจว่าแต่ละบริษัทอาจใช้เทคนิคที่เป็นกรรมสิทธิ์เฉพาะร่วมกับโทเค็นความน่าเชื่อถือ เราจึงไม่ได้รับการกำหนดไว้ล่วงหน้าตามจุดประสงค์การใช้งาน อย่างไรก็ตาม เราอาจขยายเอกสารประกอบเพื่อเพิ่มตัวอย่างอื่นๆ เพื่อใช้ในการเริ่มต้นสำหรับพาร์ทเนอร์ที่กำลังพิจารณาทดลองใช้หรือนำมาใช้งาน |
| ความครอบคลุมของโทเค็นความน่าเชื่อถือ | การนำนโยบายฟีเจอร์ "การแลกสิทธิ์โทเค็น" นี้ออกควรเพิ่มการครอบคลุมของโทเค็นความน่าเชื่อถืออย่างมาก | ซึ่งเรื่องนี้จะพิจารณาเมื่อเรารวบรวมความคิดเห็นจาก OT และตัดสินใจเกี่ยวกับขั้นตอนถัดไป |
| ผู้ออกความน่าเชื่อถือ | เหตุใดเราจึงควรเชื่อถือเว็บไซต์ที่ออกโทเค็นความน่าเชื่อถือ | ไม่มีหลักเกณฑ์ในการเป็นผู้ออก ใครๆ ก็ทำได้ ผู้เผยแพร่โฆษณาควรทำงานร่วมกับผู้ออกบัตรที่ตนเองเชื่อถือเท่านั้น นอกจากนี้ ผู้ที่ดำเนินการอย่างถูกกฎหมายอื่นๆ ในระบบนิเวศโฆษณาจะลด (หรือหยุดการซื้อ) การเข้าชมที่เกี่ยวข้องกับผู้ออกบัตรที่น่าสงสัยหรือที่ไม่รู้จักในที่สุด |
| บริการแบบฝังของบุคคลที่สาม | บริการแบบฝังของบุคคลที่สามจะแลกสิทธิ์และ/หรือขอโทเค็นความน่าเชื่อถือได้ไหม | ได้ บริการแบบฝังของบุคคลที่สามสามารถออกและแลกสิทธิ์โทเค็นความน่าเชื่อถือได้ |
| ระบบนิเวศของผู้ออกบัตร | คุณจะได้รับประโยชน์มากขึ้นหากแชร์สัญญาณความน่าเชื่อถือกับบริษัทอื่นๆ ได้ | Trust Token ได้รับการออกแบบมาให้เป็นโทเค็นพื้นฐานระดับต่ำ และสามารถใช้โดยผู้ออก/ผู้แลกสิทธิ์ที่ให้ความร่วมมือเพื่อแชร์สัญญาณความน่าเชื่อถือ/ความน่าเชื่อถือ |
| ค่าใช้จ่ายในการบำรุงรักษา | การติดตั้งใช้งานการเข้ารหัสที่เกี่ยวข้องกับการดำเนินการของ Trust Token อยู่ใน BoringSSL ซึ่ง Google เป็นผู้ดูแลแต่เพียงผู้เดียว จะมีการจัดการการบำรุงรักษาห้องสมุดอย่างไร | โทเค็นความน่าเชื่อถือต้องใช้การดำเนินการเข้ารหัสตามมาตรฐาน (ดูโปรโตคอล Privacy Pass) ซึ่งอาจใช้งานในไลบรารีอื่นๆ ได้ด้วย เราขอแนะนำให้นักพัฒนาซอฟต์แวร์ขอ/พัฒนา/บำรุงรักษาการสนับสนุนสำหรับการดำเนินการเหล่านี้ในไลบรารีที่ต้องการ |
| ค่าใช้จ่ายในการบำรุงรักษา | ไม่ระบุระยะเวลาการสนับสนุนเวอร์ชันโปรโตคอล | เรากำลังพัฒนาและจัดทำเอกสารที่เจาะจงมากขึ้นเกี่ยวกับกรอบเวลาการสนับสนุนที่คาดไว้สำหรับเวอร์ชันโปรโตคอล |
| ข้อจำกัดของผู้ออกบัตร | หากคุณใช้ Trust Token ในเชนต่อไป ก็อาจไม่เปิดโอกาสให้คุณใช้งาน Trust Token | เมื่อองค์กรต่างๆ เริ่มใช้โทเค็นความน่าเชื่อถือมากขึ้น เราก็ได้เห็นการเปลี่ยนแปลงของเวลาเหล่านี้เพิ่มมากขึ้นและกำลังตรวจสอบโซลูชันที่เป็นไปได้ ตามที่ได้อธิบายไว้ก่อนหน้านี้ เรากำลังมองหาตัวเลือกระยะยาวที่จะช่วยให้บริษัทต่างๆ แลกโทเค็นได้อย่างปลอดภัยโดยไม่ต้องเสี่ยงต่อเอนโทรปีของผู้ใช้ ซึ่งจะช่วยลดความสำคัญของตำแหน่งในหน้าหรือคำสั่งซื้อการโหลด |
โซลูชันป้องกันการฉ้อโกงแบบใหม่ในการบ่มเพาะ
| ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
| สัญญาณเอกสารรับรองความสมบูรณ์ของอุปกรณ์ | การสนับสนุนที่แข็งแกร่งโดยทั่วไปสำหรับการทำตามสัญญาณความสมบูรณ์ของอุปกรณ์ที่ได้รับการรับรองจากแพลตฟอร์มและพร้อมใช้งานบนเว็บ | เราจะยังคงรวบรวมความคิดเห็นและดำเนินการตามข้อเสนอผ่านการออกแบบและทำซ้ำในที่สาธารณะ |
| สัญญาณเอกสารรับรองความสมบูรณ์ของอุปกรณ์ | คำถามที่ว่าสามารถถ่ายทอดเอนโทรปีของผู้ใช้ผ่านสัญญาณใหม่ๆ ได้มากน้อยแค่ไหน และกรณีการใช้งานบางกรณี (เช่น ผู้ใช้เข้าสู่ระบบธนาคาร) อาจเป็นเหตุผลให้สัญญาณเอนโทรปีที่สูงขึ้นหรือไม่ | เราให้ความสำคัญกับการให้สัญญาณที่มีคุณค่าสูงซึ่งมีเอนโทรปีของผู้ใช้ให้น้อยที่สุดเท่าที่จะทำได้เพื่อรักษาความเป็นส่วนตัวของผู้ใช้ |
| สัญญาณเอกสารรับรองความสมบูรณ์ของอุปกรณ์ | สัญญาณนี้จะจำกัดการเข้าถึงสำหรับอุปกรณ์รุ่นเก่าหรือแพลตฟอร์มโอเพนซอร์ส/ที่แก้ไขไหม | หากสัญญาณใหม่ๆ ควรถือว่าการเข้าถึงแบบสากลเป็นหลักสำคัญของการพัฒนา และสิ่งเหล่านี้จะเป็นคำถามสำคัญที่ต้องตอบอย่างตรงไปตรงมาระหว่างที่เราพัฒนาระบบต่อไป |
| สัญญาณเอกสารรับรองความสมบูรณ์ของอุปกรณ์ | มีความกังวลหากมีสัญญาณใหม่ๆ ที่ทำให้บริษัทด้านความปลอดภัยและบริษัทต่อต้านการฉ้อโกงอาศัยเบราว์เซอร์และแพลตฟอร์มมากเกินไป
|
สัญญาณใหม่ควรถือเป็นข้อมูลเสริม ไม่ใช่ตัวบ่งชี้ถึง "ความน่าเชื่อถือ" จากเบราว์เซอร์ เราคาดหวังอย่างเต็มที่ให้บริษัทด้านความปลอดภัยจะยังคงพึ่งพาข้อมูล โมเดล และเครื่องมือการตัดสินใจที่เป็นกรรมสิทธิ์ของตนเองต่อไป พร้อมเอกสารรับรองของอุปกรณ์เป็นข้อมูลเพิ่มเติม เราหวังว่าสัญญาณใหม่ๆ จะปรับปรุงความพยายามในการตรวจจับทั่วทั้งระบบนิเวศและทำให้การประพฤติมิชอบเป็นไปได้ยากขึ้น |
| สัญญาณอายุคุกกี้ | แนวคิดที่น่าสนใจแต่น่าจะต้องตรวจสอบกรณีการใช้งานที่เกี่ยวข้องเพิ่มเติม | Chrome อาจคิดหาไอเดียเพิ่มเติมเกี่ยวกับแนวคิดนี้ และเรียบเรียงให้เป็นคำอธิบายสำหรับความคิดเห็นเกี่ยวกับระบบนิเวศในอนาคต ทั้งนี้ขึ้นอยู่กับระดับความสนใจ |
| เซิร์ฟเวอร์ป้องกันการฉ้อโกงที่วางใจได้ | แนวคิดที่น่าสนใจแต่น่าจะต้องตรวจสอบกรณีการใช้งานที่เกี่ยวข้องเพิ่มเติม | Chrome อาจคิดหาไอเดียเพิ่มเติมเกี่ยวกับแนวคิดนี้ และเรียบเรียงให้เป็นคำอธิบายสำหรับความคิดเห็นเกี่ยวกับระบบนิเวศในอนาคต ทั้งนี้ขึ้นอยู่กับระดับความสนใจ |