รายงานความคิดเห็น - ไตรมาสที่ 1 ปี 2022

รายงานรายไตรมาสสําหรับไตรมาสที่ 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 อาจคิดหาไอเดียเพิ่มเติมเกี่ยวกับแนวคิดนี้ และเรียบเรียงให้เป็นคำอธิบายสำหรับความคิดเห็นเกี่ยวกับระบบนิเวศในอนาคต ทั้งนี้ขึ้นอยู่กับระดับความสนใจ