รายงานรายไตรมาสสําหรับไตรมาสที่ 1 ของปี 2022 ซึ่งสรุปความคิดเห็นของระบบนิเวศที่ได้รับเกี่ยวกับข้อเสนอ Privacy Sandbox และการตอบสนองของ Chrome
ในฐานะที่เป็นส่วนหนึ่งของความมุ่งมั่นต่อหน่วยงานด้านการแข่งขันและตลาด Google ได้ตกลงที่จะจัดทำรายงานรายไตรมาสเกี่ยวกับกระบวนการมีส่วนร่วมของผู้มีส่วนเกี่ยวข้องสำหรับข้อเสนอ Privacy Sandbox ของตน (ดูวรรคที่ 12 และ 17(c)(2) ของข้อผูกพัน) รายงานสรุปความคิดเห็นเกี่ยวกับ 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 จึงได้มีการสื่อสารในวงกว้าง และ Chrome จะโพสต์คําถามที่พบบ่อยเพื่อยืนยันถึงเรื่องนี้ เพื่อให้การทดสอบมีให้บริการทั่วโลก นอกจากนี้ Chrome จะอัปเดตไทม์ไลน์สาธารณะหลังจากปรึกษากับ CMA เป็นประจำ
แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง
API / เทคโนโลยี | ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
หัวข้อ | ประโยชน์ของหัวข้อแบบละเอียด | ปัจจุบันผู้ใช้กลุ่มดังกล่าวมีความกังวลว่าการจัดหมวดหมู่หัวข้อแบบละเอียดอาจไม่มีประโยชน์เพียงพอสําหรับการโฆษณาตามความสนใจ | เราจะสำรวจประโยชน์ของ API ผ่านการทดสอบ Chrome คาดว่าการจัดหมวดหมู่จะเปลี่ยนแปลงไปตามผลการทดสอบ |
หัวข้อ | การจัดหมวดหมู่ | ผู้มีส่วนเกี่ยวข้องในอุตสาหกรรมต้องการมีเสียงในการโน้มน้าวการจัดหมวดหมู่ | Chrome จะยังคงเปิดไว้เพื่อป้อนในการจัดหมวดหมู่ Chrome สนใจฟังความคิดเห็นเรื่องโมเดลการกำกับดูแลในการแก้ไขการจัดหมวดหมู่นี้ และพูดคุยถึงวิธีที่องค์กรอื่นๆ ในอุตสาหกรรมจะมีบทบาทสำคัญในการพัฒนาและดูแลรักษาการจัดหมวดหมู่ในระยะยาว |
หัวข้อ | ประโยชน์สำหรับเว็บไซต์ประเภทต่างๆ | มีผู้หยิบยกข้อกังวลเกี่ยวกับความมีประโยชน์สำหรับเว็บไซต์ขึ้นมา โดยจะขึ้นอยู่กับระดับการเข้าชมหรือความชำนาญเฉพาะทางของเนื้อหา | เราจะสำรวจประโยชน์ของ API ผ่านการทดสอบ Chrome คาดหวังว่าการจัดหมวดหมู่และพารามิเตอร์อื่นๆ จะเปลี่ยนแปลงไปตามผลการทดสอบ วิวัฒนาการของการจัดหมวดหมู่หรือพารามิเตอร์อาจไม่จำเป็นต้องมีการเปลี่ยนแปลงที่เข้ากันไม่ได้แบบย้อนหลัง นอกจากนี้ Chrome คาดว่าผลตอบรับจะยังคงมีผลต่อวิวัฒนาการของ Topics API ต่อไปหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
หัวข้อ | วิธีการแยกประเภทไซต์ | ขอให้เว็บไซต์ตัดสินใจหรือมีผลต่อการจัดประเภทหัวข้อของตน | Chrome กำลังสำรวจคำขอนี้ แต่มีข้อกังวล (จากชุมชนเว็บเบราว์เซอร์และจาก DSP) เกี่ยวกับความเสี่ยงที่อาจเกิดขึ้นที่เว็บไซต์สามารถ "หลอกระบบ" เพื่อกำหนดเป้าหมายผู้ใช้ในลักษณะที่รุกล้ำความเป็นส่วนตัว หรือลดความเกี่ยวข้องของโฆษณา Chrome กําลังขอความคิดเห็นและชั่งน้ำหนักการเปลี่ยนแปลงที่อาจเกิดขึ้น |
หัวข้อ | สัญญาณเสียงดัง | การส่งหัวข้อแบบสุ่ม 5% จากทั้งหมดอาจสร้างสัญญาณรบกวน / สัญญาณผิดมากเกินไป | เสียงรบกวนเป็นวิธีสำคัญในการปกป้องความเป็นส่วนตัวของผู้ใช้ โดยจะสำรวจระดับเสียงรบกวนเทียบกับความมีประโยชน์ของหัวข้อนั้นๆ ผ่านการทดสอบ |
หัวข้อ | การให้สิทธิ์จากบุคคลที่สามที่ควบคุมโดยเว็บไซต์ | ขอให้เว็บไซต์เลือกว่าเทคโนโลยีโฆษณาใดบ้างที่เรียกใช้ Topics API จากเว็บไซต์ของตนได้ | ความสามารถตามที่ขอนี้มีการสนับสนุนอยู่แล้วผ่านนโยบายสิทธิ์ "หัวข้อการเรียกดู" ดังที่ระบุไว้ในโปรแกรมอธิบาย |
หัวข้อ | ผลกระทบของ Topics API ต่อประสิทธิภาพของหน้าเว็บ | ข้อกังวลเกี่ยวกับความล่าช้าของเวลาในการแสดงโฆษณาแรกอันเป็นผลจากขึ้นอยู่กับ Topics API | Chrome กำลังพูดคุยเกี่ยวกับการสนับสนุนที่เป็นไปได้สำหรับหัวข้อในส่วนหัวของคำขอ HTTP เพื่อปรับปรุงประสิทธิภาพ เราจะใช้การทดสอบเพื่อดูว่าการเปลี่ยนแปลงดังกล่าวจำเป็นหรือไม่ |
หัวข้อ | ความเป็นส่วนตัว / นโยบาย | คำถามที่ใช้กรองคำตอบตามผู้โทร ในกรณีที่บุคคลที่สามบางรายจะแชร์หัวข้อของตนกับทุกคนที่โทรหา | ตามความคิดเห็นจากหลายคนในระบบนิเวศ Chrome เลือกการออกแบบนี้เพื่อจำกัดการเข้าถึงข้อมูลไว้เฉพาะผู้ที่ไม่มีสิทธิ์เข้าถึงข้อมูลดังกล่าว แน่นอนว่าผู้เผยแพร่และบุคคลที่สามที่ได้รับ Topics สามารถตัดสินใจได้เองว่าจะเปิดเผยข้อมูลใดในเว็บไซต์ของตน หากผู้ใช้ทำการแชร์ประเภทนี้ Chrome สนับสนุนอย่างยิ่งให้แจ้งให้ผู้ใช้ทราบเกี่ยวกับการแชร์ดังกล่าวอย่างโปร่งใสและเสนอการควบคุม |
หัวข้อ | เอกสารประกอบ | ความสนใจในเอกสารประกอบที่ครอบคลุมรายละเอียดของโมเดลตัวแยกประเภทและการจัดหมวดหมู่ที่ Chrome ใช้เหมือนกับที่คุณทำกับ FLoC เช่น ความถี่ในการเปลี่ยนแปลงตัวแยกประเภทและการจัดหมวดหมู่ | Chrome มีการจัดหมวดหมู่ที่ใช้เป็นส่วนหนึ่งของช่วงทดลองใช้จากต้นทางอยู่แล้ว และโมเดลตัวแยกประเภทที่จัดหมวดหมู่เว็บไซต์เป็น Topics จะพร้อมใช้งานภายในฐานของโค้ดของ Chrome โดยเป็นส่วนหนึ่งของโค้ดโอเพนซอร์ส ในช่วงทดลองใช้จากต้นทาง Chrome ขอสงวนสิทธิ์ในการทำการเปลี่ยนแปลงเมื่อมีการแสดงความคิดเห็นและรวบรวมสิ่งที่ได้เรียนรู้เกี่ยวกับการทำงาน |
FLEDGE | การกำหนดความถี่สูงสุด | ต้องการที่จะควบคุมความถี่ต่อผู้ใช้ภายในแคมเปญหรือภายในกลุ่มโฆษณา | FLEDGE จะรองรับการกำหนดความถี่สูงสุดสำหรับการประมูลในอุปกรณ์ ซึ่ง FLEDGE มีปัญหาที่ยังไม่ได้รับการแก้ไขซึ่งครอบคลุมประเด็นนี้สำหรับ FLEDGE เพื่อรองรับแคมเปญตามบริบท/การสร้างแบรนด์ด้วย พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน, API ที่อยู่ระหว่างการพัฒนาอีกตัวหนึ่ง และขีดจำกัดเฉพาะเว็บไซต์ยังใช้สำหรับการควบคุมการกำหนดความถี่สูงสุดเพิ่มเติมได้ |
FLEDGE | ผลกระทบของ FLEDGE ต่อประสิทธิภาพ | มีข้อกังวลเกี่ยวกับผลกระทบที่อาจเกิดขึ้นของผู้เสนอราคาที่ใช้การคำนวณอย่างหนักในการประมูล FLEDGE | Chrome อยู่ระหว่างการอภิปรายอย่างต่อเนื่องกับนักพัฒนาซอฟต์แวร์เกี่ยวกับผลกระทบที่อาจเกิดขึ้นต่อประสิทธิภาพของเว็บไซต์ Chrome เปิดโอกาสให้คุณได้เรียนรู้เพิ่มเติมในระหว่างการทดสอบ |
FLEDGE | การทดสอบ FLEDGE กับฟีเจอร์อื่นๆ | จะมีการทดสอบกับฟีเจอร์อื่นๆ (เช่น เซิร์ฟเวอร์ k-anonymity, เซิร์ฟเวอร์คีย์-ค่า เป็นต้น) เมื่อใดและอย่างไร | Chrome ตั้งใจจะเปิดตัวฟีเจอร์ต่างๆ เป็นช่วงๆ สำหรับช่วงทดลองใช้จากต้นทางแรกเพื่อให้การทดสอบง่ายขึ้น Chrome ทราบดีว่าการให้ความชัดเจนเรื่องลำดับเวลาสำหรับฟีเจอร์อื่นๆ เป็นสิ่งสำคัญและจะชี้แจงอย่างชัดเจนเมื่อทำได้ |
FLEDGE | การประสานงานการทดสอบ | วิธีประสานงานการทดสอบกับเทคโนโลยีโฆษณาต่างๆ | Chrome กำลังตรวจสอบการให้ความช่วยเหลือเพิ่มเติมเพื่อช่วยประสานงานการทดสอบ เพื่อให้เทคโนโลยีโฆษณาที่แตกต่างกันทดสอบกับผู้ใช้รายเดียวกัน นอกจากนั้น องค์กรการค้าในอุตสาหกรรมยังได้แสดงความสนใจที่จะเข้ามามีบทบาทสำคัญในเรื่องนี้ด้วย |
FLEDGE | ขีดจำกัดกลุ่มความสนใจ | แล้วจะมีการจำกัดจำนวนกลุ่มความสนใจที่สามารถเพิ่มผู้ใช้ได้หรือที่สามารถรวมในการประมูลได้หรือไม่ | Chrome พร้อมที่จะปรับขีดจำกัดเหล่านี้สำหรับประสิทธิภาพของหน้าเว็บหรือเหตุผลด้านประสบการณ์ของผู้ใช้ในระหว่างระยะเวลาการทดสอบตามความคิดเห็นและผลกระทบของเวลาในการตอบสนองที่วัด ขณะนี้มีการพูดคุยหารือกับผู้ทดสอบเกี่ยวกับวิธีการอื่นๆ เพิ่มเติมเพื่อช่วยให้ผู้ซื้อและผู้ขายปรับแต่งการใช้ทรัพยากรได้ |
FLEDGE | ความสามารถข้าม API | การรายงานการระบุแหล่งที่มาจะทํางานร่วมกับ FLEDGE อย่างไร | รายละเอียดทั้งหมดยังอยู่ในระหว่างรอประกาศ และ Chrome คาดว่าจะมีการอัปเดตเกี่ยวกับเรื่องนี้ในไตรมาสที่ 2 Chrome คาดว่าจะเสนอการรายงานระดับเหตุการณ์ต่อไปสําหรับผลการประมูล (การชนะและแพ้) ระหว่างช่วงทดลองใช้จากต้นทาง |
การวัดผลโฆษณาดิจิทัล
API / เทคโนโลยี | ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
Attribution Reporting (และ API อื่นๆ) | การทดสอบการเข้าชม | ข้อกังวลว่าจะมีการเข้าชมเพียงพอสำหรับการทดสอบหรือไม่ | Chrome จะเริ่มช่วงทดลองใช้จากต้นทางเมื่อมีปริมาณการเข้าชมต่ำมากเพื่อให้มั่นใจว่าไม่มีข้อบกพร่องหรือปัญหาร้ายแรงกับการควบคุมผู้ใช้ ผู้ทดสอบรายแรกๆ เป็นส่วนสำคัญในการยืนยันว่า API ทำงานได้ตามที่คาดหวังในแง่ของทางเทคนิค ซึ่งจะช่วยเพิ่มปริมาณการรับส่งข้อมูลให้เร็วขึ้น เมื่อมั่นใจว่า API ทำงานได้ตามที่คาดไว้ Chrome จะเพิ่มช่วงทดลองใช้จากต้นทางเพื่อสนับสนุนการทดสอบยูทิลิตี |
การรายงานการระบุแหล่งที่มา | หลักสรีรศาสตร์สำหรับการลงทะเบียนกิจกรรม | คำถามเกี่ยวกับรูปแบบการลงทะเบียนเข้าร่วมกิจกรรมที่รองรับ | Chrome ได้เผยแพร่การตอบสนองใน github เพื่อชี้แจงรูปแบบการลงทะเบียนที่ได้รับการสนับสนุนในปัจจุบัน Chrome กําลังรวบรวมความคิดเห็นจากระบบนิเวศเกี่ยวกับการออกแบบปัจจุบัน เพื่อดูว่าการเปลี่ยนแปลงที่เสนอนี้ช่วยแก้ไขข้อกังวลเหล่านี้ได้อย่างเพียงพอหรือจําเป็นต้องมีการอัปเดตเพิ่มเติมหรือไม่ |
การรายงานการระบุแหล่งที่มา | การสร้างเสียงรบกวน | ต้องการรายละเอียดเพิ่มเติมเกี่ยวกับวิธีสร้างสัญญาณรบกวนสำหรับรายงานเชิงสถิติ | Chrome ได้เผยแพร่การตอบสนองใน GitHub เพื่อให้รายละเอียดเพิ่มเติมเกี่ยวกับวิธีสร้างเสียงรบกวนอย่างเป็นระบบ Chrome มีแผนที่จะให้บริการไลบรารีเพื่อจำลองสัญญาณรบกวนและทดสอบด้วยช่วงของพารามิเตอร์ในระหว่าง OT Chrome ยังมีแผนที่จะจัดทำเอกสารประกอบและคู่มือสำหรับนักพัฒนาซอฟต์แวร์เพิ่มเติมสำหรับโหมดการรายงานรวมอีกด้วย |
การรายงานการระบุแหล่งที่มา | ข้อมูลที่แม่นยำน้อยลงสำหรับเว็บไซต์ขนาดเล็ก | กังวลว่าเว็บไซต์หรือแคมเปญขนาดเล็กจะได้รับข้อมูลที่ถูกต้องแม่นยำน้อยลง | Chrome ตระหนักดีว่าการคุ้มครองความเป็นส่วนตัวแบบใช้เสียงรบกวนจะส่งผลกระทบมากกว่าต่อชิ้นส่วนข้อมูลที่มีขนาดเล็กกว่า อย่างไรก็ตาม เป็นไปได้ว่าวิธีการต่างๆ อย่างเช่นการรวมข้อมูลในช่วงเวลาที่นานขึ้นจะแก้ไขปัญหานี้ได้ และเรายังไม่ชัดเจนว่าข้อสรุปที่อิงตามชิ้นส่วนข้อมูลขนาดเล็กมากๆ (เช่น การซื้อ 1-2 รายการ) มีความหมายต่อผู้ลงโฆษณาหรือไม่ ระหว่างช่วงทดลองใช้จากต้นทาง Chrome สนับสนุนให้ผู้ทดสอบใช้ประโยชน์จากความสามารถในการทดสอบกับพารามิเตอร์ความเป็นส่วนตัวและพารามิเตอร์เสียงรบกวนที่หลากหลายเพื่อให้ความคิดเห็นที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับปัญหานี้ |
การรายงานการระบุแหล่งที่มา | ความล่าช้าของ Conversion ส่งผลต่อยูทิลิตี | เนื่องจากความล่าช้าของ Conversion จะขัดขวางการตั้งค่าและการยืนยันแคมเปญหรือการเพิ่มประสิทธิภาพแคมเปญ | Chrome ได้รับความคิดเห็นที่ขัดแย้งกันเกี่ยวกับผลกระทบจากความล่าช้าของการรายงาน Conversion อย่างไรก็ตาม เนื่องจาก Attribution Reporting API ทำให้การรายงานมีความล่าช้าแบบสุ่มเพื่อปกป้องความเป็นส่วนตัวของผู้ใช้ Chrome จึงคาดว่า Use Case หรือข้อกังวลเฉพาะจะมีความชัดเจนยิ่งขึ้นในช่วงระยะเวลาทดสอบ และอาจแก้ไขได้ด้วยการสนับสนุนการแก้ไขข้อบกพร่องหรือคําแนะนําเพิ่มเติมสำหรับนักพัฒนาซอฟต์แวร์ |
การรายงานการระบุแหล่งที่มา | กรอบเวลาการระบุแหล่งที่มาที่นานขึ้น | คำขอให้ขยายกรอบเวลาการระบุแหล่งที่มา 30 วัน | Chrome ได้เผยแพร่การตอบกลับที่ขอความคิดเห็นเพิ่มเติมเกี่ยวกับความยาวของกรอบเวลาการระบุแหล่งที่มา โดยคำนึงถึงทั้งขอบเขตการใช้ข้อมูลและประโยชน์ใช้สอย |
การรายงานการระบุแหล่งที่มา | การแสดงผลที่มองไม่เห็น | คำถามเกี่ยวกับการนับการแสดงผลที่ไม่ได้แสดงในรายงาน Conversion การดูผ่านหรือไม่ | Chrome ได้เผยแพร่การตอบกลับใน GitHub เพื่อให้ความชัดเจนมากขึ้นเกี่ยวกับการแสดงผลที่ได้แสดง |
จำกัดการติดตามโดยไม่เปิดเผยตัวตน
API / เทคโนโลยี | ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
การลด User Agent | การแสดง | มีความกังวลเกี่ยวกับเวลาในการตอบสนองของการได้รับคำแนะนำผ่าน Critical-CH (ในการโหลดหน้าเว็บแรก) | Chrome กำลังหาวิธีปรับปรุงประสิทธิภาพ |
การลด User-Agent / คำแนะนำไคลเอ็นต์ User-Agent | ข้อกังวลเกี่ยวกับการต่อต้านการประพฤติมิชอบ / การต่อต้านการละเมิด | การมีข้อมูลมากที่สุดเท่าที่เป็นไปได้จะมีความสำคัญเมื่อแก้ไขข้อบกพร่องของการโจมตีบางประเภท รวมถึงการปฏิเสธการให้บริการ การสูญเสียข้อมูลบางอย่างจากสตริง UA อาจก่อให้เกิดปัญหา | Chrome อยู่ระหว่างการหารือและประเมินวิธีรักษาความเป็นส่วนตัวไปพร้อมๆ กับการให้ข้อมูลที่เพียงพอซึ่งจะเป็นประโยชน์ในการแก้ไขข้อบกพร่อง |
การลด User Agent | ความสับสนเกี่ยวกับการตั้งค่า OT | ผู้เข้าร่วมช่วงทดลองใช้จากต้นทางหลายรายแนะนำให้ปรับปรุงเอกสารประกอบพร้อมตัวอย่างวิธีลงทะเบียนทดลองใช้จากต้นทาง | ช่วงทดลองใช้ Reduced UA จากต้นทางกำลังจะสิ้นสุดลง แต่ Chrome มุ่งมั่นที่จะปรับปรุงคำแนะนำสำหรับช่วงทดลองใช้การเลิกใช้งาน (รวมถึงการทำให้การสาธิตตัวอย่างโดดเด่นมากขึ้น) |
การลด User Agent | ข้อกังวลเกี่ยวกับค่าของคำแนะนำที่เฉพาะเจาะจง | คำถามว่า Sec-CH-UA-Model เหมือนกับ <deviceModel> ในสตริง User-Agent ไหม | Sec-CH-UA-Model จะเหมือนกับ <deviceModel> ในสตริง User-Agent Chrome จะพยายามชี้แจงเรื่องนี้ให้ชัดเจนยิ่งขึ้นในเอกสารประกอบในอนาคต |
การลด User Agent | ข้อกังวลเกี่ยวกับการลงทะเบียนในช่วงทดลองใช้การเลิกใช้งาน | คำถามเกี่ยวกับวิธีลงทะเบียนโดเมนจำนวนมากให้เข้าร่วมการทดลองใช้การเลิกใช้งาน | Chrome ได้พิจารณาแนวทางแบบรวมศูนย์เมื่อออกแบบช่วงทดลองใช้การเลิกใช้งาน แต่ Chrome เชื่อว่าช่วงทดลองใช้จากต้นทางที่มีอยู่เป็นตัวเลือกที่ดีที่สุดเนื่องจากจะทำให้นักพัฒนาซอฟต์แวร์เป็นผู้ควบคุมทั้งหมด (เนื่องจากสามารถเลือกส่งส่วนหัวหรือไม่ก็ได้) |
คำแนะนำไคลเอ็นต์ User Agent | ข้อกังวลเกี่ยวกับลักษณะที่กำหนดของ UA-CH | มีความกังวลว่า UA-CH นั้นมีการกำหนดไว้แล้วมากเกินไปเมื่อเทียบกับความยืดหยุ่นที่ส่วนหัว User-Agent มอบให้ตามที่กำหนดโดย rfc7231 | Chrome มองว่าลักษณะของส่วนหัว UA-CH ที่กำหนดไว้เป็นการปรับปรุงที่สำคัญเหนือความยืดหยุ่นของสตริง UA ทั้งจากมุมมองของความสามารถในการทำงานร่วมกันข้ามเบราว์เซอร์และการปกป้องความเป็นส่วนตัวของผู้ใช้ในท้ายที่สุด (โดยการป้องกันการเพิ่มตัวระบุเอนโทรปีสูงโดยอิสระ)
อย่างไรก็ตาม ปัญหานี้ยังคงดำเนินต่อไปในกรณีที่มีผู้อื่นแชร์ข้อกังวลนี้และอยากแสดงความคิดเห็น |
คำแนะนำไคลเอ็นต์ User Agent | ข้อกังวลว่ามีการใช้ API เพื่อบล็อกบางเบราว์เซอร์ | ข้อกังวลว่าเว็บไซต์กำลังใช้ API เพื่อค้นหา "Google Chrome" หรือ "Microsoft Edge" และบล็อกเบราว์เซอร์อื่นๆ ทั้งหมด | แนวคิดของรายการแบรนด์ออกแบบมาเพื่อจัดการกับกรณีนี้ นั่นคือ เบราว์เซอร์สามารถส่งคำว่า "Google Chrome" นอกเหนือไปจากแบรนด์ของตัวเองได้ |
คำแนะนำไคลเอ็นต์ User Agent | ขอวิธีแจกแจงคำแนะนำที่รองรับทั้งหมด | สนใจใช้วิธีแบบเป็นโปรแกรมเพื่อให้ทราบคำแนะนำทั้งหมดที่รองรับสำหรับเบราว์เซอร์ | Chrome กำลังประเมินคำขอฟีเจอร์ |
การลด User-Agent / คำแนะนำไคลเอ็นต์ User-Agent | ข้อกังวลเกี่ยวกับการต่อต้านการประพฤติมิชอบ / การต่อต้านการละเมิด | คำแนะนำสำหรับไคลเอ็นต์ไม่พร้อมใช้งานในการโหลดครั้งแรกสำหรับ HTTP1 | Client Hints Reliability API (ACCEPT_CH) ใช้งานได้ผ่าน HTTP2 และ HTTP3 เท่านั้น สำหรับเซิร์ฟเวอร์ที่ยังคงให้บริการผ่าน HTTP1 เซิร์ฟเวอร์ดังกล่าวจะต้องใช้ Critical-CH เท่านั้น |
การลด User Agent | ผลกระทบต่อ Chrome สำหรับ Android | คำถามโดยเฉพาะเกี่ยวกับผลกระทบที่มีต่อ Chrome บน Android | การลด UA และ UA-CH จะพร้อมให้ใช้งานใน Chrome บน Android นอกเหนือจากในเดสก์ท็อป สำหรับ Chrome บน Android การเปลี่ยนแปลงจะเกิดขึ้นเฉพาะใน "ระยะที่ 6" ซึ่งขณะนี้กำหนดไว้สำหรับ Chrome 110 |
กแนตแคตเชอร์ (WIPB) | การใช้งานและวิธีการที่ไม่เป็นไปตามนโยบาย | ความชัดเจนเกี่ยวกับการใช้งานที่ไม่เป็นไปตามข้อกำหนดและวิธีการที่ไม่เป็นไปตามข้อกำหนด | Chrome จะอัปเดตคำอธิบายเพิ่มเติม |
Gnatcatcher + การลด User-Agent | การลดสัญญาณเพื่อป้องกันการประพฤติมิชอบ | ผลกระทบจากการป้องกันการประพฤติมิชอบจากการลดการเข้าถึง IP และ UA พร้อมกัน | การกำหนดข้อกำหนดของนโยบายต่อต้านการฉ้อโกงแบบ Willful IP Blindness (เพื่ออนุญาตให้ใช้ IP สำหรับ Use Case การป้องกันการประพฤติมิชอบ) จะช่วยแก้ไขข้อกังวลเกี่ยวกับการปกป้องจากการพร็อกซี IP |
การติดตามการนำทาง | ข้อกังวลเกี่ยวกับความเสียหายในอนาคต | ผู้ลงโฆษณากังวลเกี่ยวกับความเสียหายที่อาจเกิดขึ้น นอกจากนี้ผู้ให้บริการข้อมูลประจำตัวยังได้แสดงความสนใจต่อแผนของ Chrome ด้วย | Chrome ไม่ได้ทำการเปลี่ยนแปลงที่ส่งผลกับส่วนอื่นในระบบ และยังคงสำรวจกรณีการใช้งานอยู่ |
คุกกี้ SameSite | ความสามารถในการทำงานร่วมกับเบราว์เซอร์อื่นๆ | คำถามเกี่ยวกับแผนการแก้ไข crbug.com/1221316 ของ Chrome เนื่องจากเป็นพื้นที่ที่การนำของ Chrome ไปใช้งานแตกต่างจากเบราว์เซอร์อื่น | Chrome พบข้อบกพร่องในเมตริก และส่งผลให้มีเมตริกใหม่ๆ Chrome กำลังรวบรวมข้อมูลเพื่อให้เข้าใจผลของการแก้ไขข้อบกพร่องได้ดีขึ้น |
การแบ่งพาร์ติชันพื้นที่เก็บข้อมูล | ข้อกังวลเกี่ยวกับการแบ่งพาร์ติชันช่องทางข้อความ | คำถามว่าช่องทางการรับส่งข้อความ (เช่น SharedWorker และ BroadcastChannel) ควรแบ่งพาร์ติชัน | Chrome กำลังประเมินความคิดเห็นดังกล่าว แต่ Chrome เชื่อว่าการแบ่งพาร์ติชันช่องทางการรับส่งข้อความรวมถึงพื้นที่เก็บข้อมูลเป็นสิ่งจำเป็นในการป้องกันการติดตามโดยไม่เปิดเผย |
ขยายขอบเขตความเป็นส่วนตัวแบบข้ามเว็บไซต์
API / เทคโนโลยี | ธีมความคิดเห็น
(จัดอันดับตามความชุก) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
ชุดบุคคลที่หนึ่ง | ข้อกำหนดทั่วไปของนโยบายความเป็นส่วนตัว | เป็นไปไม่ได้ที่จะคงไว้ซึ่งนโยบายความเป็นส่วนตัวที่เหมือนกันสำหรับผลิตภัณฑ์ทั้งหมดและเขตอำนาจศาลที่ต้องอยู่ในชุดเดียวกัน | Chrome ยังคงกำหนดข้อกําหนดของนโยบายของเราและคํานึงถึงความคิดเห็นนี้ |
ชุดบุคคลที่หนึ่ง | Independent Enforcement Entity (IEE) มีแนวโน้มที่จะต้องเผชิญกับความท้าทายจำนวนมากเกี่ยวกับความถูกต้องของ FPS | ข้อมูลสรุปเกี่ยวกับความท้าทายที่คาดการณ์ได้ในการกำหนดความถูกต้องของ FPS: ข้อความหรือนโยบายความเป็นส่วนตัวไม่ตรงกันกับสมาชิกในเซ็ต, ความชัดเจนเกี่ยวกับวิธีกำหนดการเป็นสมาชิกในชุดที่ผู้ใช้มองเห็นได้, ปัญหาแบนด์วิดท์และช่วงเวลาที่เหมาะสม และความเชี่ยวชาญเฉพาะทางเกี่ยวกับโครงสร้างองค์กร | Chrome ยังคงกำหนดข้อกําหนดของนโยบายของเราและคํานึงถึงความคิดเห็นนี้ |
ชุดบุคคลที่หนึ่ง | กระบวนการดูแลรักษารายการ FPS ของเบราว์เซอร์ | ข้อกังวลเกี่ยวกับอุปสรรคในการเข้าถึงเว็บไซต์ในประเทศที่ไม่ใช่กลุ่มประเทศตะวันตก รายการ FPS ในรูปแบบที่ไม่สอดคล้องกันในเบราว์เซอร์ต่างๆ เนื่องจากอัตราการอัปเดตที่แตกต่างกัน และความสามารถของเบราว์เซอร์ขนาดเล็ก/ใหม่ในการใช้รายการนี้ | Chrome ยังอยู่ระหว่างการกำหนดข้อกำหนดของนโยบาย กระบวนการยอมรับ และสิทธิ์ในการใช้งานรายการนี้ รวมถึงจะนำความคิดเห็นนี้มาพิจารณา
Chrome ยังจะดูข้อมูลจากรายการแบบคงที่อื่นๆ ที่ใช้ในแพลตฟอร์มเว็บด้วย เช่น รายการคำต่อท้ายสาธารณะ |
ชุดบุคคลที่หนึ่ง | การออกแบบการยืนยันต่อเว็บไซต์แบบไดนามิก | การออกแบบแบบไดนามิก (ซึ่งตรงข้ามกับรายการแบบคงที่) อาจมีแนวโน้มที่จะเกิดการยืนยันการเป็นเจ้าของร่วมกันอย่างไม่ถูกต้อง และเวลาในการตอบสนอง/ความล้มเหลวในการโหลดหน้าเว็บ | ขณะนี้ Chrome กำลังใช้แนวทางรายการแบบคงที่และจะคำนึงถึงความคิดเห็นนี้หากมีการประเมินแนวทางการยืนยันที่ลงนามอีกครั้งในอนาคต |
ชุดบุคคลที่หนึ่ง | กรณีการใช้งานที่เป็นไปได้สำหรับชุดบุคคลที่หนึ่ง (หากสร้างรายการ FPS เวอร์ชันที่เชื่อถือได้และมีความเสมอภาคได้) | ใช้การลงชื่อเพียงครั้งเดียว ข้อความแจ้งข้อมูลที่ปรับแต่งได้ ใช้สำหรับการรายงานเพื่อความโปร่งใสที่ได้รับการปรับปรุงให้แก่ผู้ใช้ | Chrome จะพิจารณาความคิดเห็นนี้ขณะพิจารณาขั้นตอนถัดไปสำหรับชุดบุคคลที่หนึ่ง |
ชิป | ความเข้ากันได้กับเบราว์เซอร์ | ความสนใจที่จะทำความเข้าใจวิธีที่เบราว์เซอร์อื่นๆ จัดการแอตทริบิวต์คุกกี้ที่แบ่งพาร์ติชัน | Chrome ทำงานอย่างต่อเนื่องในกลุ่มมาตรฐานสาธารณะ เช่น W3C เพื่อระบุการออกแบบและการใช้งานที่สามารถทำงานในเบราว์เซอร์ต่างๆ |
ชิป | ข้อกำหนดด้านการออกแบบ | ข้อกังวลว่าการใส่คำนำหน้า __Host- อาจเป็นไปไม่ได้ | Chrome ได้นำข้อกำหนดการตั้งชื่อช่วงทดลองใช้จากต้นทางออกแล้ว และพิจารณาว่าจะใช้แบบถาวรหรือไม่เมื่อสิ้นสุดระยะเวลาการทดสอบ |
ชิป | การใช้ CHIPS สำหรับ Use Case ของโฆษณา | คำถามว่าจะใช้ CHIPS สำหรับกรณีการใช้งานโฆษณาได้หรือไม่ | CHIPS ช่วยให้บุคคลที่สามสร้างคุกกี้ฝั่งไคลเอ็นต์ที่แบ่งพาร์ติชันไปยังเว็บไซต์ระดับบนสุด (หรือชุดโดเมนของบุคคลที่หนึ่ง) ได้ หาก Use Case จําเป็นต้องใช้สถานะที่มีการแบ่งพาร์ติชัน ไม่ใช่สถานะข้ามเว็บไซต์ คุณจะใช้ CHIPS สําหรับ Use Case นั้นได้ |
ชิป | การผสานรวม CHIPS กับ FPS | ข้อกังวลว่าการทดสอบกับ CHIPS อาจไม่สามารถควบคู่ไปกับข้อเสนอ Privacy Sandbox อื่นๆ เช่น ชุดบุคคลที่หนึ่ง | Chrome กำลังสำรวจหาวิธีอำนวยความสะดวกให้กับสภาพแวดล้อมการทดสอบซึ่งจะทำให้การทดสอบดังกล่าวเกิดขึ้นได้ Chrome ยังได้เผยแพร่วิธีการทดสอบ FPS และ CHIPS ในเครื่อง ซึ่งสามารถใช้ในระหว่างนี้ได้ |
FedCM | การแสดงความรู้สึก | กังวลว่าเนื่องจากเบราว์เซอร์แสดงผลบางส่วนของขั้นตอนข้อมูลประจำตัวแบบรวมศูนย์ จึงยากที่จะจับความแตกต่างเล็กๆ น้อยๆ ทั้งหมดที่ IdP ต้องการนำเสนอให้กับผู้ใช้ของตน | Chrome ตระหนักถึงข้อดีข้อเสียและจะยังคงทำงานกับระบบนิเวศนี้ต่อไปเพื่อให้ครอบคลุมมากที่สุดและเพื่อให้สะท้อนความเป็นมาได้มากที่สุด แนวคิดบางอย่างที่ Chrome กําลังสํารวจ ได้แก่ การปรับแต่งแบรนด์ (เช่น โลโก้ สี) และการปรับแต่งสตริง (เช่น "เข้าถึงบทความนี้" ซึ่งตรงข้ามกับ "เข้าสู่ระบบด้วย") |
FedCM | การมีส่วนร่วมกับเบราว์เซอร์ | กังวลว่าเบราว์เซอร์มีส่วนร่วมในขั้นตอนการรวมศูนย์ข้อมูลประจำตัวมากกว่าที่เคย ทำให้ทราบอย่างชัดเจนว่าผู้ใช้เข้าสู่ระบบเว็บไซต์ใด (รวมถึง IdP ใด) | Chrome ทราบดีว่าขณะนี้เบราว์เซอร์มีบทบาทสำคัญมากขึ้น แต่การเข้าไปมีบทบาทมากขึ้นนี้เป็นสิ่งจำเป็นสำหรับเบราว์เซอร์ในการแยกและป้องกันการติดตามข้ามเว็บไซต์ในขณะที่ยังคงสนับสนุนการรวมศูนย์ |
FedCM | ความเกี่ยวข้องและการทำงานร่วมกัน | มีความกังวลว่าเบราว์เซอร์อื่นๆ จะไม่ปรับใช้หรือใช้งาน FedCM | Chrome ยังทำงานร่วมกับผู้ให้บริการเบราว์เซอร์รายอื่นๆ เพื่อหาวิธีแก้ปัญหาทั่วไปสำหรับการรวมศูนย์ที่ FedID Community Group |
FedCM | ความท้าทายต่างๆ เกี่ยวกับ API | ข้อกังวลว่า FedCM ยังอยู่ในช่วงเริ่มต้น / ยังไม่เต็มที่ และจะต้องใช้เวลานานในการนำเสนอฟีเจอร์ทั้งหมดที่ระบบนิเวศต้องการ | Chrome จะสำรวจปัญหานี้เพิ่มเติมโดยเป็นส่วนหนึ่งของการทดสอบระบบนิเวศ |
FedCM | นโยบายองค์กรและการควบคุมผู้ใช้ | กังวลว่าจะมีการควบคุมหรือไม่ (เช่น นโยบายขององค์กรและ/หรือการตั้งค่าของผู้ใช้) ที่อนุญาตให้องค์กรใช้งานข้อมูลประจำตัวแบบรวมศูนย์ต่อไปโดยไม่มีการเปลี่ยนแปลงใดๆ มีการใช้งานข้อมูลประจำตัวแบบรวมศูนย์ภายในองค์กรอยู่เป็นจำนวนมาก ซึ่งยากต่อการปรับใช้ / เปลี่ยนแปลงใหม่ จึงมักต่อต้าน API ของเบราว์เซอร์ใหม่ที่จำเป็นต้องใช้ IdP ในการทำให้ใช้งานได้อีกครั้ง | Chrome กำลังสำรวจการควบคุมสำหรับผู้ดูแลระบบขององค์กรและผู้ใช้ ซึ่งเชื่อว่าจะช่วยแก้ไขข้อกังวลเหล่านี้ได้ Chrome ยินดีรับฟังความคิดเห็นจากองค์กรต่างๆ เกี่ยวกับกรณีการใช้งานเฉพาะที่องค์กรต้องการให้เรานำมาพิจารณา |
ต่อสู้กับสแปมและการประพฤติมิชอบ
API / เทคโนโลยี | ธีมความคิดเห็น
(จัดอันดับตามความชุกต่อ API) |
สรุปคําถามและข้อกังวล | การตอบสนองของ Chrome |
API โทเค็นความน่าเชื่อถือ | ขีดจำกัดการแลกใช้ | ข้อกังวลเกี่ยวกับ 2 หน้าต่อหน้ามีข้อจำกัดมากเกินไป โดยเฉพาะในสถานการณ์ที่หน้าเว็บหนึ่งอาจฝังอยู่ในหน้าเว็บเดียวกันหลายครั้ง หรือมีโดเมนผู้ออกบัตรรายที่ 2 ภายในองค์กรของตน ผู้เข้าชมมีแนวโน้มที่จะถึงขีดจำกัดด้วยตนเองโดยไม่พิจารณาผู้เข้าร่วมตลาดคนอื่นๆ | Chrome ยินดีขยายขีดจำกัดการแลกสิทธิ์ต่อหน้าเว็บเล็กน้อยหากจะเพิ่มการใช้งาน แต่ก็ต้องลดขีดจำกัดไว้ให้ต่ำเพื่อให้มีเอนโทรปีมากเกินไป นอกจากนี้ การแคชบันทึกการแลกสิทธิ์อาจลดความจำเป็นที่ผู้ออกบัตรรายหนึ่งจะแลกสิทธิ์โทเค็นหลายรายการสำหรับผู้ใช้รายเดียวในระยะเวลาสั้นๆ |
API โทเค็นความน่าเชื่อถือ | เวลาในการตอบสนอง | โดยทั่วไปต้องตอบคำขอราคาเสนอภายใน 10 มิลลิวินาทีหรือน้อยกว่า ดังนั้นการแลกโทเค็นเมื่อโหลดหน้าเว็บครั้งแรกทำให้ไม่สามารถรวมไว้ในการตัดสินใจเกี่ยวกับการเข้าชมที่ไม่ถูกต้องในการเสนอราคาล่วงหน้าได้ | Chrome กำลังพยายามทำความเข้าใจว่าเวลาในการตอบสนองส่งผลต่อ Use Case ของการเสนอราคาล่วงหน้าอย่างไรผ่านการทดสอบ |
API โทเค็นความน่าเชื่อถือ | การใช้งาน OpenRTB | สำหรับ Use Case ของ Prebid คุณจำเป็นต้องส่งข้อมูลโทเค็นที่แลกสิทธิ์ไปยัง SSP และ DSP เพื่อใช้ในการตัดสินใจเกี่ยวกับโฆษณา | Chrome ยินดีที่จะทำงานร่วมกับ IAB เพื่อช่วยดูแลให้สัญญาณป้องกันการประพฤติมิชอบ/การละเมิดอันเป็นประโยชน์สามารถเผยแพร่ผ่าน OpenRTB แม้จะเป็นมาตรฐานของการเพิ่มช่องเริ่มต้นใหม่ทั้งหมดก็ตาม |
API โทเค็นความน่าเชื่อถือ | ความเป็นส่วนตัว | คำถามเกี่ยวกับการอยู่รอดในระยะยาวของการเผยแพร่ข้อมูลข้ามเว็บไซต์ทุกรูปแบบ แม้ว่าจะมีเอนโทรปีในปริมาณต่ำ (ประมาณ 2.5 บิต) | ด้วยการป้องกันผู้ใช้ที่มีประสิทธิภาพเพื่อหลีกเลี่ยงการระบุตัวตนของผู้ใช้ที่ไม่ซ้ำกัน Chrome เชื่อว่ามีกรณีที่ดีสำหรับการยอมรับในระบบนิเวศ Chrome ทํางานอย่างใกล้ชิดกับผู้มีส่วนเกี่ยวข้องหลักเพื่อให้มั่นใจว่าจะสามารถอยู่รอดได้ในระยะยาว |
สัญญาณเอกสารรับรองของแพลตฟอร์ม | การวัดความสนใจในแนวคิด/ข้อเสนอใหม่ | การสนับสนุนที่เข้มแข็งสำหรับสัญญาณต่างๆ ที่เป็นไปได้ (และเป็นไปได้) เช่น การถ่ายทอดสัญญาณความสมบูรณ์ของอุปกรณ์ที่แพลตฟอร์มทำได้ | Chrome วางแผนที่จะนำแนวคิดนี้ไปใช้กับกลุ่มชุมชนต่อต้านการฉ้อโกง W3C โดยเป็นแนวคิดใหม่สำหรับความคิดเห็น |
เซิร์ฟเวอร์ป้องกันการฉ้อโกงที่วางใจได้ | การวัดความสนใจในแนวคิด/ข้อเสนอใหม่ | แนวคิดที่น่าสนใจแต่น่าจะต้องตรวจสอบกรณีการใช้งานที่เกี่ยวข้องเพิ่มเติม | Chrome อาจคิดหาไอเดียเพิ่มเติมเกี่ยวกับแนวคิดนี้ และเรียบเรียงให้เป็นคำอธิบายสำหรับความคิดเห็นเกี่ยวกับระบบนิเวศในอนาคต ทั้งนี้ขึ้นอยู่กับระดับความสนใจ |