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

จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ

รายงานรายไตรมาสสำหรับไตรมาสที่ 1 ปี 2025 ซึ่งสรุปความคิดเห็นที่ได้รับจากระบบนิเวศเกี่ยวกับข้อเสนอ Privacy Sandbox และการตอบกลับของ Chrome

Google ได้จัดทำรายงานรายไตรมาสนี้ขึ้นเพื่อแสดงความมุ่งมั่นต่อหน่วยงานกำกับดูแลการแข่งขันและตลาด ('CMA') ภายใต้ย่อหน้า 12, 17(ค)(ii) และ 32(ก) รายงานนี้ครอบคลุมความคืบหน้าของ Google ในข้อเสนอ Privacy Sandbox, ข้อมูลอัปเดตเกี่ยวกับลำดับเวลา, คำอธิบายอย่างละเอียดเกี่ยวกับวิธีที่ Google พิจารณาข้อสังเกตของบุคคลที่สาม และสรุปการโต้ตอบระหว่าง Google กับ CMA ซึ่งรวมถึงความคิดเห็นจาก CMA และแนวทางของ Google ในการตอบสนองต่อความคิดเห็น

Google ได้อัปเดตความคืบหน้าเกี่ยวกับข้อเสนอ Privacy Sandbox ให้กับ CMA ในการมีการประชุมเพื่อติดตามผลเป็นประจําตามกำหนดการตามย่อหน้า 17(ข) ของข้อผูกมัด นอกจากนี้ ทีมยังดูแลเอกสารประกอบสําหรับนักพัฒนาซอฟต์แวร์ซึ่งมีภาพรวมของฟีเจอร์หลักของการโฆษณาแบบไม่ระบุตัวบุคคลและการเปลี่ยนแปลงเกี่ยวกับคุกกี้ รวมถึงการติดตั้งใช้งาน API และข้อมูลสถานะ เราจะแชร์ข้อมูลอัปเดตที่สำคัญในบล็อกของนักพัฒนาแอป พร้อมกับการอัปเดตที่กําหนดเป้าหมายไปยังรายชื่ออีเมลของนักพัฒนาแอปแต่ละราย

อภิธานศัพท์เกี่ยวกับตัวย่อ

ARA

Attribution Reporting API

CHIPS

คุกกี้ที่มีสถานะการแบ่งพาร์ติชันอิสระ

DSP

แพลตฟอร์มฝั่งดีมานด์

FedCM

การจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์

IAB

Interactive Advertising Bureau

IDP

ผู้ให้บริการข้อมูลประจำตัว

IETF

คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต

IP

ที่อยู่ Internet Protocol

openRTB

การเสนอราคาแบบเรียลไทม์

OT

ช่วงทดลองใช้จากต้นทาง

PA API

Protected Audience API (เดิมเรียกว่า FLEDGE)

PatCG

กลุ่มชุมชนเทคโนโลยีโฆษณาส่วนตัว

RP

ผู้เชื่อถือ

RWS

ชุดเว็บไซต์ที่เกี่ยวข้อง (เดิมคือชุดโดเมนของบุคคลที่หนึ่ง)

SSP

แพลตฟอร์มฝั่งขาย

UA

สตริง User Agent

UA-CH

คำแนะนำสำหรับไคลเอ็นต์ User Agent

W3C

World Wide Web Consortium

WIPB

การจงใจปิดบัง IP

ความคิดเห็นทั่วไป ไม่มี API/เทคโนโลยีที่เฉพาะเจาะจง

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ตัวเลือกของผู้ใช้	ยังไม่ชัดเจนว่าแนวทางที่อัปเดตแล้วของ Google ในการยกระดับทางเลือกของผู้ใช้จะเป็นอย่างไร ลักษณะที่นำเสนอต่อผู้ใช้ และอัตราการเลือกใช้/เลือกไม่ใช้ที่คาดไว้ ต้องมีข้อมูลเพิ่มเติมเพื่อแยกความแตกต่างระหว่างกรณีนี้กับการเลิกใช้งานคุกกี้ของบุคคลที่สาม	ในเดือนเมษายน 2025 Google ได้เผยแพร่บล็อกโพสต์เกี่ยวกับขั้นตอนถัดไปสำหรับ Privacy Sandbox และการป้องกันการติดตามใน Chrome เพื่อประกาศว่า Google ได้ตัดสินใจที่จะใช้แนวทางปัจจุบันในการเสนอคุกกี้ของบุคคลที่สามใน Chrome ให้แก่ผู้ใช้ต่อไป และจะไม่เปิดตัวข้อความแจ้งแบบสแตนด์อโลนใหม่สำหรับคุกกี้ของบุคคลที่สาม เราจะแจ้งข้อมูลอัปเดตเพิ่มเติมเมื่อพร้อมให้บริการ
เบราว์เซอร์ฟิงเกอร์ปรินต์	Google ไม่ได้แชร์ข้อมูลใดๆ กับผู้เผยแพร่โฆษณาหรือนักการตลาดเกี่ยวกับวิธีใช้ระบบโฆษณาของ Google แทนระบบอื่นๆ โดยไม่ใช้ข้อมูลระบุตัวตนของผู้บริโภคที่มีความเสี่ยงมากขึ้นเป็นคีย์การจับคู่ทั่วไป (เช่น การพิมพ์ลายนิ้วมือ)	เราได้ไฮไลต์ระบบโฆษณาที่ไม่ใช่ของ Google หลายระบบที่เสนอโซลูชันแก่ผู้เผยแพร่โฆษณาและนักการตลาด ซึ่งสร้างขึ้นจาก Privacy Sandbox API บางส่วน ซึ่งรวมถึงระบบโฆษณาที่ไม่ใช่ของ Google ในช่องทางและตลาดต่างๆ ดูรายละเอียดเพิ่มเติมและกรณีศึกษาได้ในส่วนแหล่งข้อมูลทางธุรกิจของ privacysandbox.com ที่นี่
Privacy Sandbox	Privacy Sandbox API จะแทนที่ส่วนผสมของข้อมูลอินเทอร์เน็ตด้วยผลิตภัณฑ์สำเร็จรูปของ Google เนื่องจากทางเลือกของ Google คือ API จึงเป็นการเสนอการเข้าถึงผลิตภัณฑ์ที่ Google เป็นเจ้าของและควบคุม รวมถึงผลิตภัณฑ์ที่อยู่ภายใต้ข้อกำหนดและเงื่อนไขที่ Google มีสิทธิ์พิจารณา ข้อมูลดังกล่าวไม่ได้ใช้แทนคอมโพเนนต์ที่ผู้อื่นใช้เพื่อสร้างผลิตภัณฑ์สำเร็จรูปของตนเอง	Privacy Sandbox API ได้รับการพัฒนาและใช้งานตามการมีส่วนร่วมอย่างกว้างขวางกับหน่วยงานกํากับดูแลและผู้มีส่วนเกี่ยวข้องในระบบนิเวศที่หลากหลาย Privacy Sandbox API ต้องคำนึงถึงว่า API เหล่านี้จะถูกนำไปใช้เป็นคอมโพเนนต์ในผลิตภัณฑ์สำเร็จรูปของผู้อื่นเช่นเดียวกับเทคโนโลยีแพลตฟอร์มอื่นๆ และเรายินดีรับฟังความพยายามของระบบนิเวศในการพัฒนาเทคโนโลยีเพิ่มเติมเพื่อทำงานร่วมกับ Privacy Sandbox API
ตัวเลือกของผู้ใช้	คำขอข้อมูลว่าแนวทางที่อัปเดตแล้วของ Google สำหรับ 3PC ใน Chrome จะเป็นไปตามข้อกำหนดด้านกฎระเบียบบางอย่างหรือไม่ ซึ่งอาจส่งผลต่อประสบการณ์การใช้งานแพลตฟอร์มการจัดการความยินยอมของผู้มีส่วนเกี่ยวข้อง	ในเดือนเมษายน 2025 Google ได้เผยแพร่บล็อกโพสต์เกี่ยวกับขั้นตอนถัดไปสำหรับ Privacy Sandbox และการป้องกันการติดตามใน Chrome เพื่อประกาศว่า Google ได้ตัดสินใจที่จะใช้แนวทางปัจจุบันในการเสนอคุกกี้ของบุคคลที่สามใน Chrome ให้แก่ผู้ใช้ต่อไป และจะไม่เปิดตัวข้อความแจ้งแบบสแตนด์อโลนใหม่สำหรับคุกกี้ของบุคคลที่สาม เราจะแจ้งข้อมูลอัปเดตเพิ่มเติมเมื่อพร้อมให้บริการ
ไทม์ไลน์และการนําไปใช้ Privacy Sandbox	เทคโนโลยีโฆษณาได้หยุดการทดสอบ Privacy Sandbox API ไว้ชั่วคราวและกำลังมองหาเหตุผลที่หนักแน่นยิ่งขึ้นในการกลับมาลงทุนในเทคโนโลยีเหล่านี้สำหรับกิจกรรมด้านผลิตภัณฑ์และการตลาด การตัดสินใจลงทุนอีกครั้งนี้ได้รับอิทธิพลอย่างมากจากความต้องการความชัดเจนมากขึ้นเกี่ยวกับไทม์ไลน์ของตัวเลือกของผู้ใช้ รวมถึงข้อกังวลเกี่ยวกับเวลาในการตอบสนองของ Protected Audience API (PA API) และแผนงานการทดสอบและประเมิน นอกจากนี้ ยังมีความกังวลเกี่ยวกับการทบทวนความมุ่งมั่นของ CMA ที่กําลังจะเกิดขึ้น โดยเฉพาะอย่างยิ่งบทบาทของ Google ในฐานะผู้ขับเคลื่อนหลักของเทคโนโลยี Privacy Sandbox โดยไม่อาศัยตัวระบุของบุคคลที่สาม และทิศทางโดยรวมในอนาคตของโครงการริเริ่มเพื่อใช้เป็นข้อมูลในกลยุทธ์การลงทุน	ในเดือนเมษายน 2025 Google ได้เผยแพร่บล็อกโพสต์เกี่ยวกับขั้นตอนถัดไปสำหรับ Privacy Sandbox และการป้องกันการติดตามใน Chrome เพื่อประกาศว่า Google ได้ตัดสินใจที่จะใช้แนวทางปัจจุบันในการเสนอคุกกี้ของบุคคลที่สามใน Chrome ให้แก่ผู้ใช้ต่อไป และจะไม่เปิดตัวข้อความแจ้งแบบสแตนด์อโลนใหม่สำหรับคุกกี้ของบุคคลที่สาม เราจะแจ้งข้อมูลอัปเดตเพิ่มเติมเมื่อพร้อมให้บริการ การประมูลของ Chrome PA API เร็วขึ้น 35% เมื่อเทียบกับปีก่อน นอกจากนี้ เรายังเห็นว่ามีการใช้การประมูลแบบขนานเพิ่มขึ้นอย่างมาก ซึ่งทำให้การประมูลเหล่านั้นประสบความสําเร็จมากขึ้น ดูแผนกลยุทธ์ปัจจุบันของ B&A ได้ที่นี่
ไทม์ไลน์ของ Privacy Sandbox	มีการอัปเดตอะไรในหน้าไทม์ไลน์ของ Privacy Sandbox	เมื่อเร็วๆ นี้เราได้เพิ่มภาพรวมของ Topics API ลงในหน้าไทม์ไลน์ของ Privacy Sandbox
Privacy Sandbox	มีเอกสารวิจัยเกี่ยวกับความเป็นส่วนตัวเทียบกับประโยชน์ที่จะช่วยทําความเข้าใจผลกระทบของ Privacy Sandbox ต่อรายได้ไหม	กรณีศึกษาทางการตลาดที่เกี่ยวข้องซึ่งตอบคําถามเหล่านี้มีที่นี่ และผลการทดสอบ Privacy Sandbox API มีที่นี่
การนำ Privacy Sandbox ไปใช้	ผู้เริ่มใช้งานตั้งแต่เนิ่นๆ รายงานปัญหาเบื้องต้นเกี่ยวกับ Privacy Sandbox API เนื่องจากบริษัทขนาดใหญ่เริ่มใช้งานช้า ซึ่งส่งผลต่อการเปิดตัวการทดสอบ อย่างไรก็ตาม เราขอขอบคุณแนวทางการทำงานร่วมกันและการตอบกลับความคิดเห็นของทีม Privacy Sandbox	ขอขอบคุณสำหรับความคิดเห็นจากผู้ใช้งานช่วงแรก เรามุ่งมั่นที่จะทำงานร่วมกับผู้ใช้งานกลุ่มแรกๆ และจะมีส่วนร่วมกับระบบนิเวศและรวบรวมความคิดเห็นต่อไปขณะที่เราประเมินบทบาทของเทคโนโลยี Privacy Sandbox ในการสนับสนุนระบบนิเวศ
การทดสอบ Chrome	ข้อกังวลเกี่ยวกับความสามารถในการทดสอบ Privacy Sandbox ต่อไปอย่างมีประสิทธิภาพหลังจากนําป้ายกํากับการทดสอบออก ซึ่งแสดงให้เห็นความแตกต่างอย่างมากในด้านคุณภาพของการเข้าชมระหว่าง Chrome ที่ปิดใช้ 3PC (โหมด B) กับผู้ใช้ที่ปิดใช้ 3PC ในการตั้งค่า Chrome ด้วยตนเอง	การตอบกลับของเราคล้ายกับในไตรมาสก่อน ทีม Privacy Sandbox เข้าใจว่าบริษัทต่างๆ ต้องการใช้ป้ายกํากับการเลิกใช้งานคุกกี้ต่อไป กระบวนการขยายเวลาความพร้อมใช้งานของป้ายกํากับจะคล้ายกับขยายเวลาช่วงทดลองใช้จากต้นทาง เราขยายเวลาการรองรับป้ายกำกับหลายครั้ง เราคาดว่าจะเสนอการขยายการสนับสนุนป้ายกำกับการเลิกใช้งานคุกกี้เพิ่มเติม และจะแชร์ข้อมูลอัปเดตใน blink-dev เมื่อพร้อมใช้งาน

การลงทะเบียนและการรับรอง

ไม่ได้รับความคิดเห็นในไตรมาสนี้

แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง

หัวข้อ

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การเลือกรับ/ไม่รับ	การยืนยันว่า Google Search จะไม่ใช้การตัดสินใจของเว็บไซต์ในการเลือกไม่ใช้ Topics API เป็นสัญญาณการจัดอันดับของ Google จะจำกัด Google ไม่ให้ใช้การตัดสินใจของเว็บไซต์ในการเลือกใช้ Topics API เป็นสัญญาณการจัดอันดับหรือไม่	คำตอบของเราคล้ายกับในไตรมาสก่อน ทีม Privacy Sandbox ไม่ได้ประสานงานหรือขอให้องค์กร Search ใช้การจัดอันดับหน้าเว็บเป็นสิ่งจูงใจให้เว็บไซต์ต่างๆ ใช้ Topics API Google Search จะไม่ใช้การตัดสินใจของเว็บไซต์ในการสนับสนุน (หรือไม่สนับสนุน) Topics API เป็นสัญญาณการจัดอันดับ
ความสามารถในการสังเกตการใช้งาน	การขอกลไกการสังเกตการณ์สําหรับ SSP หรือเทคโนโลยีโฆษณาทั่วไปเพื่อดูว่ามีการใช้การติดตั้งใช้งาน Topics API บนเว็บหรือไม่	เรากำลังประเมินการรองรับฟังก์ชันนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศหากฟีเจอร์นี้เป็นสิ่งสําคัญ
ความเป็นส่วนตัว	คําถามเกี่ยวกับความยินยอมและโอกาสในการระบุตัวตนซ้ำ	ขณะนี้เรากำลังพูดคุยเกี่ยวกับปัญหานี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม

Protected Audience API

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
PA API และ GAM/AdX	Google จะไม่ส่งดีมานด์ GAM/AdX ไปยังผู้เผยแพร่โฆษณาที่ต้องการใช้เซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณารายอื่น Google ควรอนุญาตให้ผู้เผยแพร่โฆษณาคู่แข่งเลือกผู้ขายการประมูล PA API ระดับบนสุดรายอื่นเพื่อควบคุมการประมูลขั้นสุดท้าย ข้อมูลจาก PA API จะพร้อมใช้งานสำหรับ GAM แต่ถูกจํากัดสำหรับ SSP คู่แข่ง ด้วยเหตุนี้ ผู้เผยแพร่โฆษณาจึงไม่สามารถเปรียบเทียบประสิทธิภาพของดีมานด์โฆษณาที่มาจาก PA API ใน GAM เช่น จาก AdX หรือจาก SSP ที่ผสานรวมกับ PA API	คําตอบจาก Chrome: มาตรฐาน PA API ออกแบบมาให้ยืดหยุ่นและอนุญาตให้บุคคลต่างๆ ทำการประมูลระดับบนสุดได้ ตัวเลือกนี้ขึ้นอยู่กับการใช้งานและความสามารถที่เฉพาะเจาะจงซึ่งเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา (ไม่ว่าจะเป็น GAM หรือเซิร์ฟเวอร์โฆษณาอื่น) และบริษัทอื่นๆ ที่เข้าร่วมในระบบนิเวศนำเสนอ การออกแบบที่เน้นความเป็นส่วนตัวของ PA API จะจํากัดการรายงานแบบละเอียดสําหรับผู้เข้าร่วมทุกคนอย่างสม่ำเสมอ ข้อมูลที่เฉพาะเจาะจงที่รายงานจากการประมูล PA API นั้นอยู่ภายใต้กฎและข้อจํากัดด้านการรักษาความเป็นส่วนตัวที่ API กําหนดไว้เหมือนกันสําหรับผู้เข้าร่วมทั้งหมด รวมถึง SSP ผู้เผยแพร่โฆษณาใช้รายงานแบบรวมที่รักษาความเป็นส่วนตัวของ PA API เพื่อประเมินประสิทธิภาพ ซึ่งช่วยให้ประเมินการมีส่วนร่วมโดยรวมของดีมานด์ที่มาจาก PA API และเปรียบเทียบกับช่องทางดีมานด์อื่นๆ ได้ ซึ่งสอดคล้องกับหลักการความเป็นส่วนตัวโดยการออกแบบของ API คําตอบจาก Google Ad Manager: ผู้เผยแพร่โฆษณาไม่จำเป็นต้องใช้ฟังก์ชันเซิร์ฟเวอร์โฆษณาของ GAM เพื่อเข้าถึงดีมานด์ของ AdX นอกจากนี้ PA API จะไม่สนใจว่าใครเป็นผู้เริ่มการประมูลทั้งในการออกแบบสำหรับผู้ขายรายเดียวและผู้ขายหลายราย
ผู้ขายระดับบน	ผู้ขายระดับบนสุด (TLS) มีสิทธิ์เข้าถึงข้อมูลที่ผู้ขายคอมโพเนนต์รายอื่นไม่มีสิทธิ์เข้าถึง ซึ่งทำให้เกิดข้อกังวลเกี่ยวกับการเข้าถึงข้อมูลที่เท่าเทียมกัน แม้ว่าเอนทิตีใดก็ตามจะเป็น TLS ได้ แต่ผู้เผยแพร่โฆษณาต้องใช้ GAM เป็นเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาเพื่อเข้าถึงดีมานด์ของ AdX การดำเนินการนี้สร้างแรงจูงใจให้ใช้ GAM เป็นเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา ซึ่งจะสร้างข้อได้เปรียบในการแข่งขันให้กับ Google	คําตอบของ Chrome: การออกแบบ PA API ไม่ได้กําหนดว่าเอนทิตีใดสามารถทําหน้าที่เป็น TLS ได้ บทบาท TLS กำหนดให้ต้องประสานงานการประมูลและเข้าถึงข้อมูลการประมูลที่เกี่ยวข้องตามโครงสร้างของ API คำตอบจาก Google Ad Manager: เรามุ่งเน้นที่ความเป็นธรรมในการประมูลมาอย่างยาวนาน รวมถึงสัญญาว่าจะไม่มีการแชร์ราคาจากแหล่งโฆษณาที่ไม่รับประกันของผู้เผยแพร่โฆษณา รวมถึงราคารายการโฆษณาที่ไม่รับประกันกับผู้ซื้อรายอื่นก่อนที่จะเสนอราคาในการประมูล ซึ่งเราได้ยืนยันอีกครั้งในความมุ่งมั่นของเราต่อหน่วยงานกำกับดูแลการแข่งขันของฝรั่งเศส สําหรับการประมูล PA API เราตั้งใจที่จะรักษาสัญญาและไม่แชร์ราคาเสนอของผู้เข้าร่วมการประมูลกับผู้เข้าร่วมการประมูลรายอื่นจนกว่าการประมูลจะเสร็จสมบูรณ์ในการประมูลแบบผู้ขายหลายราย เพื่อความชัดเจน เราจะไม่แชร์ราคาของการประมูลตามบริบทกับการประมูลคอมโพเนนต์ใดๆ รวมถึงการประมูลของเราเอง ตามที่อธิบายในการอัปเดตนี้ นอกจากนี้ เราไม่ใช้ข้อมูลเกี่ยวกับการกําหนดค่าการประมูลของคอมโพเนนต์ ซึ่งรวมถึงสัญญาณที่ผู้ซื้อให้ไว้กับ SSP เป็นส่วนหนึ่งของการประมูลของเราเอง นอกจากนี้ GAM ไม่ได้กําหนดให้ผู้เผยแพร่โฆษณาใช้ฟังก์ชันการทํางานของเซิร์ฟเวอร์โฆษณาเพื่อเข้าถึงดีมานด์ของ AdX ดังที่ระบุไว้ข้างต้น สุดท้าย ตามที่ระบุไว้ก่อนหน้านี้ในรายงานไตรมาสที่ 2 / 3 ปี 2024 ของ Google แพลตฟอร์มฝั่งซื้อของ Google ซึ่งได้แก่ Google Ads (เดิมคือ AdWords) และ DV360 จะซื้อการแสดงผลจากพาร์ทเนอร์ Exchange ที่ไม่ใช่ของ Google รวมถึงผ่าน PA API
PA API และ GAM/AdX	ผู้เผยแพร่โฆษณาเข้าใจการเปิดใช้งาน PA API ในพื้นที่โฆษณา 100% ได้ยาก เนื่องจากป้ายกำกับของตัวเลือกไม่ระบุวัตถุประสงค์อย่างชัดเจน สําหรับ SSP ที่ใช้วิธีหลักในการเข้าถึงพื้นที่โฆษณาผ่านการประมูลหลายระดับโดย GAM ทำหน้าที่เป็น TLS แทบจะไม่มีวิธีใดเลยที่จะทำการทดสอบหรือสร้างรายได้ผ่าน PA API โดยไม่อยู่ภายใต้ GAM	คําตอบจาก Chrome: มาตรฐาน PA API กําหนดบทบาททางเทคนิค (เช่น TLS และผู้ขายคอมโพเนนต์) และกระบวนการประมูล ซึ่งช่วยให้แพลตฟอร์มต่างๆ ดําเนินบทบาทเหล่านี้ได้อย่างยืดหยุ่น กิจกรรมการดําเนินการ เช่น การกําหนดค่า การประสานงาน และข้อตกลง จะจัดการโดยฝ่ายที่ใช้งาน (ผู้เผยแพร่โฆษณา SSP ผู้ให้บริการ TLS) เพื่ออำนวยความสะดวกในการเข้าร่วมโดยใช้เฟรมเวิร์ก PA API คําตอบจาก Google Ad Manager: ตามที่อธิบายไว้ในศูนย์ช่วยเหลือ Ad Manager ให้ผู้เผยแพร่โฆษณามีการควบคุมเพื่อเปิดใช้การทดสอบกับผู้ขายคอมโพเนนต์ที่ไม่ใช่ Google เช่น SSP อื่นๆ ในพื้นที่โฆษณาของผู้เผยแพร่โฆษณา 100% ที่มี API พร้อมใช้งาน (ลบล้างการสุ่มตัวอย่างหรือการจำกัดที่ GAM อาจใช้) หากผู้เผยแพร่โฆษณาเปิดใช้การควบคุมนี้ เมื่อใดก็ตามที่ผู้ขายคอมโพเนนต์ที่ไม่ใช่ Google ระบุการกําหนดค่าการประมูล GAM จะพยายามเรียกใช้การประมูลระดับบนสุดโดยรวมการประมูลคอมโพเนนต์ที่ระบุไว้ด้วย ในกรณีที่ผู้เผยแพร่โฆษณาได้รับความยินยอมที่จำเป็นจากผู้ใช้แล้ว GAM จะแจ้งให้ผู้เผยแพร่โฆษณาทราบอย่างชัดเจนว่าการควบคุมนี้อาจส่งผลต่อประสิทธิภาพ เพื่อให้ผู้เผยแพร่โฆษณาตัดสินใจอย่างมีข้อมูล
ฝั่งเซิร์ฟเวอร์กับในอุปกรณ์	โซลูชันฝั่งเซิร์ฟเวอร์ เช่น การเสนอราคาและการประมูล (B&A) มีศักยภาพในการแก้ปัญหาการปรับปริมาณการเข้าชมในขณะที่รักษาความเป็นส่วนตัว โซลูชันฝั่งเซิร์ฟเวอร์เป็นเส้นทางเดียวที่เป็นไปได้และ Google ควรเลิกใช้โซลูชันในอุปกรณ์	Privacy Sandbox มีเป้าหมายเพื่อรองรับทั้งโซลูชันการประมูลฝั่งเซิร์ฟเวอร์ (บริการ B&A) และโซลูชันการประมูลในอุปกรณ์ ซึ่งให้ตัวเลือกที่ตรงกับความต้องการและกรณีการใช้งานด้านเทคโนโลยีโฆษณาที่หลากหลาย
การรักษาความปลอดภัยในการประมูล	การโจมตีราคาเสนอ PA API จะทำให้การเสนอราคาและการประมูลในอุปกรณ์ถูกตัดสิทธิ์โดยพื้นฐาน ผู้มีส่วนเกี่ยวข้องจึงยังคงขอการรับประกันทางเทคนิคเพื่อให้มั่นใจว่าราคาเสนอ PA API จะไม่ถูกแทรกแซง รวมถึงขอโหมดแก้ไขข้อบกพร่องที่ครอบคลุมเพื่อตรวจหาเหตุการณ์แบบเรียลไทม์และการแก้ไขข้อบกพร่องที่มีประสิทธิภาพ	การรักษาความสมบูรณ์ของการประมูล PA API รวมถึงการลดการโจมตีที่อาจเกิดขึ้นเป็นประเด็นหลักของ Privacy Sandbox การออกแบบ API รวมมาตรการความสมบูรณ์ไว้ด้วย และเรายินดีให้พูดคุยเรื่องเทคนิคเพิ่มเติมเกี่ยวกับข้อกังวลที่เฉพาะเจาะจง เราได้นำเสนอและพูดคุยเกี่ยวกับรายการรายละเอียดของการโจมตีที่อาจเกิดขึ้นกับ PA API และการบรรเทาความเสี่ยงของเราในการประชุมกลุ่มชุมชนป้องกันการประพฤติมิชอบของ W3C เมื่อเดือนพฤษภาคม 2024 เรายินดีรับฟังความคิดเห็นและการพูดคุยเพิ่มเติมเกี่ยวกับ "การโจมตีราคาเสนอ PA API" ที่อาจเกิดขึ้น
การเข้าชมที่ไม่มีคุกกี้	จะมีวิธีเปิดใช้ PA API เฉพาะในการเข้าชมที่ไม่มีคุกกี้สําหรับการทดสอบหรือวัตถุประสงค์อื่นๆ ไหม	เทคโนโลยีโฆษณาจะระบุได้ว่ามี 3PC อยู่หรือไม่ ซึ่งอธิบายไว้อย่างละเอียดที่นี่
รหัสที่นั่ง	เกี่ยวกับข้อเสนอรหัสที่นั่ง ความรู้เกี่ยวกับรหัสที่นั่งเป็นสิ่งจําเป็นสําหรับคําขอราคาเสนอส่วนใหญ่ ซึ่งทำให้เกิดข้อกังวลเกี่ยวกับการเชื่อมโยงรหัสที่นั่งกับการลงทะเบียนครีเอทีฟโฆษณา นอกจากนี้ จะใช้กับ "โฆษณาหลัก" เท่านั้น หรือจะใช้กับโฆษณาคอมโพเนนต์ด้วย	ข้อเสนอ BuyerAndSellerReportingId จะช่วยคลายความกังวลเกี่ยวกับไม่มีรหัสที่นั่งของผู้ซื้อระหว่างการลงทะเบียนครีเอทีฟโฆษณาสําหรับโฆษณาหลัก ตัวระบุนี้มีไว้เพื่อสื่อสารรหัสที่นั่งของผู้ซื้อกับผู้ขาย เรากําลังประเมินการรองรับโฆษณาคอมโพเนนต์
การตรวจสอบและการรายงาน	คำขอฟีเจอร์สำหรับการตรวจสอบแบบเรียลไทม์ (RTM) สำหรับ (1) การส่งรายงาน RTM สำหรับการประมูลที่ยกเลิก และ (2) กลุ่มที่สร้างขึ้นใหม่จากเบราว์เซอร์เพื่อให้ทราบได้อย่างชัดเจนว่ามีการยกเลิกประเภทใด	ดูเหมือนว่า RTM จะไม่ได้เป็นโซลูชันที่เหมาะสมสําหรับการตรวจสอบอัตราการมีส่วนร่วม RTM ได้รับการออกแบบให้เป็น API การตรวจสอบที่มีเวลาในการตอบสนองต่ำเพื่อตรวจหาการหยุดทำงานชั่วคราวที่สำคัญและฉับพลัน ในทางตรงกันข้าม อัตราการเข้าร่วมไม่จำเป็นต้องมีการรายงานเวลาในการตอบสนองต่ำและไม่ใช่การหยุดทำงานชั่วคราวอย่างฉับพลันที่สำคัญ ผู้ขายที่ทำงานร่วมกับผู้ซื้อจะตอบข้อกังวลเกี่ยวกับอัตราการเข้าร่วมได้อย่างมีประสิทธิภาพมากที่สุด ไม่ใช่ผู้ซื้อที่ตรวจสอบผ่านเบราว์เซอร์ นอกจากนี้ การประมูลที่ยกเลิกเป็นเรื่องที่เกิดขึ้นบ่อยมาก หากเบราว์เซอร์สร้างรายงาน RTM จากการประมูลที่ยกเลิกแต่ละรายการ รายงาน RTM สำหรับการหยุดทำงานจริงอาจถูกบดบัง
เอกสารประกอบ คําชี้แจง	รายงานความคลาดเคลื่อนของเอกสารประกอบในคำอธิบาย PA API ที่ระบุว่า Nonce ควรเป็นสตริง UUID แต่กลับแสดงผลเป็น Promise	โปรดดูคำชี้แจงที่นี่
แช่แข็ง บริบท	เมื่อทํางานกับบริบทที่หยุดชั่วคราว ตัวเลือกใดบ้างที่พร้อมให้แก้ปัญหาและอุปสรรคที่เกี่ยวข้องกับ (1) การรวมกลุ่ม (2) ไลบรารีภายนอก และ (3) ประเภทข้อมูลที่ระบบไม่รองรับ	เรามีคำตอบสำหรับคำถามนี้ที่นี่
ข้อกำหนด	Private Aggregation API ได้เพิ่มการดำเนินการ contributeToHistogramOnEvent ทั่วไป ด้วยเหตุนี้ คําจํากัดความใน PA API จึงกลายเป็นการดำเนินการที่โอเวอร์โหลด และการดำเนินการ Web IDL "ต้องไม่โอเวอร์โหลดในอินเทอร์เฟซ อินเทอร์เฟซบางส่วน [...]" ดังนั้นคําจํากัดความดังกล่าวจึงใช้งานไม่ได้	ปัญหานี้ชี้ให้เห็นถึงความไม่สอดคล้องกันชั่วคราวระหว่างข้อกําหนดของ PA API กับ Private Aggregation ขณะที่เราผสานการเปลี่ยนแปลงที่คล้ายกันในทั้ง 2 อย่าง เราได้ผสานคำขอดึงข้อมูลเพื่อแก้ไขปัญหานี้แล้ว
กลุ่มความสนใจ	ขอคําแนะนําเกี่ยวกับวิธีการที่แนะนำและประหยัดทรัพยากรสำหรับการสิ้นสุดการเข้าร่วมการเสนอราคาของกลุ่มความสนใจ (IG) เมื่อแคมเปญหยุดลง	คำแนะนำบางส่วนที่เรามอบให้ได้มีดังนี้ เราเชื่อว่ากลไกที่มีเวลาในการตอบสนองต่ำที่สุด ถาวรน้อยที่สุด และปล่อยทรัพยากรน้อยที่สุดคือการใช้สัญญาณการเสนอราคาแบบเรียลไทม์เพื่อแจ้งให้ generateBid() หยุดเสนอราคา ตัวเลือกที่ 2 ที่ใช้ทรัพยากรน้อยลงคือการกําหนดลําดับความสําคัญเป็นลบสําหรับ IG นั้นในการตอบกลับสัญญาณการเสนอราคาแบบเรียลไทม์ เนื่องจากวิธีนี้จะทำให้generateBid()ไม่ได้รับการเรียกใช้ ตัวเลือกที่ 3 ซึ่งใช้ทรัพยากรน้อยลงอีกคือการนําโฆษณาออกจาก IG IG ที่ไม่มีโฆษณาจะไม่เรียกใช้ generateBid() ตัวเลือกที่ 4 ซึ่งใช้ทรัพยากรน้อยลงอีกคือการนำ biddingLogicURL ออกจาก IG ในตอนนี้ IG จะยังคงอัปเดต/เข้าร่วมอีกครั้งเพื่อเปิดใช้งานอีกครั้งได้ ตัวเลือกเพิ่มเติมเกี่ยวข้องกับการออกจาก IG ซึ่งทำได้ผ่าน leaveAdInterestGroup() หรือ clearOriginJoinedAdInterestGroups() หรือเมื่อ IG หมดอายุ ดังที่ไฮไลต์ไว้ข้างต้น ตัวเลือกต่างๆ จะมีผลต่อเวลาในการตอบสนองและการบริโภคทรัพยากรแตกต่างกัน เทคโนโลยีโฆษณาสามารถเลือกตัวเลือกที่มีการแลกเปลี่ยนที่ดีที่สุดสำหรับกรณีการใช้งานที่เฉพาะเจาะจงได้
กลุ่มเป้าหมาย	ขอกลไกในการเรียกใช้การดำเนินการเชิงตรรกะกับกลุ่มเป้าหมายที่สร้าง (เช่น ความสามารถในการกําหนดเป้าหมายที่ตัดกันของ IG A และ B)	PA API ช่วยให้คุณดําเนินการเชิงตรรกะกับกลุ่มเป้าหมายจากเว็บไซต์เดียวกันได้ ปัจจุบันระบบยังไม่รองรับการดำเนินการเชิงตรรกะของกลุ่มเป้าหมายในเว็บไซต์ต่างๆ เพื่อพิจารณาความเป็นส่วนตัวตามที่อธิบายไว้ในรูปแบบความเป็นส่วนตัวของเรา เรากําลังดําเนินการวิจัยในเรื่องนี้อย่างต่อเนื่อง และจะแชร์ข้อมูลอัปเดตตลอดกระบวนการ
คำขอฟีเจอร์	ข้อเสนอในการยกเลิกข้อจํากัดราคาเสนอเพิ่มเติมที่กําหนดให้ต้องทราบ TLS ล่วงหน้า	ขณะนี้เรากำลังพูดคุยเกี่ยวกับข้อเสนอนี้ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
แนวทางที่อัปเดตสำหรับ 3PC ใน Chrome	Privacy Sandbox API เช่น PA API จะยังคงพร้อมให้บริการแก่ผู้ใช้ Chrome Stable ทุกคนต่อไปไหม หรือ API (หรือ API บางรายการ) จะพร้อมให้บริการแก่ผู้ใช้ที่ปฏิเสธ 3PC เท่านั้น	เราไม่ได้ตั้งใจให้การตัดสินใจของผู้ใช้ในการปฏิเสธ 3PC ส่งผลต่อความพร้อมให้บริการของ Privacy Sandbox API ใน Chrome เวอร์ชันเสถียร
การส่งสัญญาณที่ปรับปรุงแล้ว	มีแผนที่จะเพิ่มฟังก์ชันการทำงานที่ระบุว่า TLS ตั้งใจที่จะทำการประมูล PA API หรือไม่	เรากำลังประเมินการรองรับฟังก์ชันนี้ เราจะแชร์รายละเอียดเพิ่มเติมเกี่ยวกับกำหนดการเมื่อพร้อมใช้งาน และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับคำขอนี้
รหัสดีล	ข้อกังวลที่ว่าข้อกำหนดของเซิร์ฟเวอร์ KV ในข้อเสนอรหัสดีลอาจเป็นกระบวนการฝั่งเซิร์ฟเวอร์ที่มีค่าใช้จ่ายสูงและใช้เวลานาน	ข้อเสนอรหัสดีลช่วยให้ SSP ค้นหาข้อมูลเมตาของรหัสดีลที่เลือกจากเซิร์ฟเวอร์คีย์-ค่าระหว่างการประมูล PA ได้ เพื่อที่จะไม่ต้องโหลดข้อมูลเมตาทั้งหมดที่เกี่ยวข้องกับดีลลงในอุปกรณ์ล่วงหน้า เราพัฒนาข้อเสนอนี้ตามคําขอจาก SSP และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศที่นี่ เราเข้าใจว่าการตั้งค่าเซิร์ฟเวอร์คีย์-ค่านั้นต้องอาศัยความพยายาม แต่โดยรวมแล้วเรายังคงคิดว่านี่เป็นข้อดีสุทธิสําหรับบริษัทเทคโนโลยีโฆษณา เรายินดีรับฟังความคิดเห็นและคำแนะนำเกี่ยวกับการทำให้กระบวนการนี้ง่ายขึ้น
การกำหนดความถี่สูงสุดข้าม IG	คำขอการกำหนดความถี่สูงสุดข้าม IG ผ่าน PA API	การจำกัดความถี่สูงสุดข้าม IG มีลักษณะความเป็นส่วนตัวที่ท้าทายซึ่งเรายังไม่พบวิธีแก้ปัญหา เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศหากฟีเจอร์นี้เป็นฟีเจอร์ที่มีลำดับความสำคัญสูง
การรายงานรหัสดีลและรหัสที่นั่ง	ขอรับสิทธิ์ในการรับรหัสดีลหรือรหัสที่นั่งในการรายงานแบบรวม	ฟังก์ชันการทํางานของรหัสการรายงานที่เรากําลังพัฒนาที่นี่ จะช่วยให้การรายงานรหัสดีลและรหัสที่นั่งเป็นไปได้ มีการกำหนด selectedBuyerAndSellerReportingId ให้กับ reportResult() ดังนั้นวิธีที่ง่ายที่สุดในการรายงานคือผ่านการรายงานระดับเหตุการณ์ (เช่น การเข้ารหัสรหัสดีลลงใน URL ที่ส่งไปยัง sendReportTo()) หากต้องการใช้การรายงานแบบรวม ก็สามารถทำได้เช่นกัน ปัจจุบันฟีเจอร์รหัสการรายงานใช้งานได้กับ 10% ของการเข้าชมในช่องทาง Chrome เวอร์ชันเสถียร เรากำลังประเมินการขยายการเปิดตัวเป็น 100%
กลุ่มความสนใจ	ใช้ลําดับความสําคัญเดียวกันทั้งในการเลือกและการประเมิน IG และใช้ลําดับความสําคัญนั้นในโหมดการประเมินทั้งหมด	เรากำลังพูดคุยเรื่องนี้อยู่ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
กลุ่มความสนใจ	คําแนะนําให้ใช้การเปิดใช้งานและการมอบสิทธิ์กลุ่มเป้าหมายเพื่อเพิ่มการใช้งาน Privacy Sandbox API	เราทราบถึงคำขอนี้จากผู้มีส่วนเกี่ยวข้องหลายรายและกำลังหาวิธีแก้ปัญหา เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
กลุ่มความสนใจ	ปัญหาเกี่ยวกับการสร้าง IG ของ PA API โดยเฉพาะการมอบสิทธิ์และการเป็นเจ้าของเมื่อดำเนินการซื้อหลายรายการหรือในนามของผู้เผยแพร่โฆษณา	เราได้รับคําขอให้รองรับการมอบสิทธิ์ IG ขั้นสูงมากขึ้นจากผู้มีส่วนเกี่ยวข้องหลายราย และเราเห็นคุณค่าที่เพิ่มขึ้นของ SSP ที่มีส่วนร่วมในกระบวนการนี้ เรากําลังดําเนินการวิจัยเพื่อหาวิธีที่ดีที่สุดที่จะช่วยให้บุคคลต่างๆ มีส่วนร่วมในกระบวนการขยายกลุ่มเป้าหมาย เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
ประสิทธิภาพฝั่งไคลเอ็นต์	ขอคําแนะนําเกี่ยวกับการแคช trustedBiddingSignals ฝั่งไคลเอ็นต์เพื่อเพิ่มประสิทธิภาพต้นทุนโครงสร้างพื้นฐานและเวลาในการตอบสนอง	เรากำลังพูดคุยเรื่องนี้อยู่ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม

การประมูลที่มีการป้องกัน (บริการ B&A)

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
บริการ K/V	คำขอจากเบราว์เซอร์ไปยังเซิร์ฟเวอร์ KV ของผู้ขายจะจัดกลุ่มอย่างไร สําหรับผู้ขาย คําขอจากเบราว์เซอร์จะมีลักษณะเป็นคําขอ GET หรือ POST นอกจากนี้ เราต้องการคำชี้แจงเพิ่มเติมเกี่ยวกับข้อกำหนดด้าน k-anonymity	สำหรับ v1 นั้น Chrome จะส่งคำขอ GET ไปยังบริการ KV ของผู้ขายเพื่อดึงข้อมูล trustedScoringSignalsURL ที่มีสัญญาณในพารามิเตอร์การค้นหาของคำขอ พารามิเตอร์จะประกอบด้วย hostname, renderUrls, adComponentRenderUrls และ experimentGroupId ขณะนี้เรากําลังทดสอบส่วนขยายบางอย่างสําหรับการส่งข้อมูลเพิ่มเติมสําหรับการสแกนครีเอทีฟโฆษณา แต่ยังไม่ได้เปิดตัว เมื่อตั้งค่า maxTrustedScoringSignalsURLLength เป็น 0 แล้ว Chrome อาจรวมสัญญาณทั้งหมดไว้ในคําขอเดียว (อาจเกินขีดจํากัดความยาว URL ในเซิร์ฟเวอร์) แต่ไม่มีการรับประกัน ปัจจุบัน Chrome จะเลือกรวมคำขอไว้ในกลุ่มเดียวกันหากพร้อมที่จะส่งภายใน 10 มิลลิวินาที แต่เรากำลังหาวิธีเพิ่มประสิทธิภาพอยู่ เมื่อใช้ trustedScoringSignals โปรดทราบว่า Chrome จะเคารพส่วนหัวการแคช ส่วนหัว เช่น ส่วนหัว Stale-While-Revalidate "Cache-Control" อาจลดเวลาในการตอบสนองโดยเฉลี่ยด้วยการอนุญาตให้ Chrome ใช้สำเนาที่แคชไว้ (และอัปเดตแคชสำหรับการประมูลครั้งถัดไป) ซึ่งจะนําการดึงข้อมูลสัญญาณออกจากเส้นทางที่วิกฤตได้อย่างมีประสิทธิภาพ สุดท้ายนี้ ในส่วน k-anonymity ดูเหมือนว่าส่วนหนึ่งของคำอธิบายจะล้าสมัย เดิมทีเรากำหนดให้ URL ของสัญญาณที่เชื่อถือต้องเป็นแบบ K-Anonymous แต่เราได้ยกเลิกข้อกำหนดดังกล่าวแล้ว เราจะนำประโยคนี้ออกจากคำอธิบาย
บริการ B&A	การอัปเกรดเป็น B&A เวอร์ชันล่าสุดใช้เวลานาน การมีเวลาบิลด์ที่เร็วขึ้นหรือภาพที่สร้างไว้ล่วงหน้าจะเป็นประโยชน์	เทคโนโลยีโฆษณาสามารถสร้างไบนารีด้วยตนเองและตรวจสอบโดยใช้แฮชที่ระบุ เราจะพิจารณาหาวิธีให้บริการอาร์ติแฟกต์ที่สร้างไว้ล่วงหน้าหรือปรับปรุงเวลาในการสร้างในอนาคต
คำขอฟีเจอร์ API	คำขอความเข้ากันได้กับ macOS สำหรับสคริปต์การสร้าง การเรียกใช้เครื่องมือ และอิมเมจคอนเทนเนอร์ของบริการเสนอราคาและบริการประมูล (B&A) เพื่ออำนวยความสะดวกในการพัฒนาและการทดสอบในเครื่อง	ปัจจุบันเรารองรับ amd64 ซึ่งเพียงพอสำหรับการนำไปใช้งานในแพลตฟอร์มระบบคลาวด์ที่รองรับ (GCP และ AWS) เราอาจพิจารณารองรับสถาปัตยกรรมอื่นๆ ในอนาคต
AWS	การสร้างบทบาท IAM เป็นข้อกำหนดสำหรับบิลด์เวอร์ชันที่ใช้งานจริงหรือไม่	ใช่ คุณต้องมีบทบาท IAM เพื่อรับสิทธิ์ที่เหมาะสมและเพื่อสื่อสารกับผู้ประสานงาน คีย์ดังกล่าวจะใช้เพื่อถอดรหัสข้อความที่เข้ารหัส ProtectedAudienceInput ซึ่งสร้างขึ้นในอุปกรณ์ตามที่ระบุไว้ที่นี่ นอกจากนี้ บทบาทเหล่านี้ยังต้องผ่านการตรวจสอบสิทธิ์เซิร์ฟเวอร์/TEE ของบิลด์เวอร์ชันที่ใช้งานจริงกับผู้ประสานงานคนเดียวกันด้วย โปรดดูรายละเอียดเพิ่มเติมในคู่มือแบบดำเนินการด้วยตนเอง
การแจ้งเตือน B&A	ขอให้ระบุคำจำกัดความของ Flag B&A ที่มีให้แสดงในเอกสารประกอบ เนื่องจากปัจจุบันคำจำกัดความเหล่านี้อยู่ในโค้ด Terraform, ไฟล์ cc และไฟล์ proto แต่เทคโนโลยีโฆษณาจะมีประโยชน์จากเอกสารประกอบเกี่ยวกับ Flag เหล่านี้ ซึ่งใช้ประโยชน์จากเอกสารประกอบดังกล่าวเป็นแหล่งข้อมูลที่เชื่อถือได้เพื่อทำความเข้าใจวิธีปรับแต่งการใช้งาน	เรากำลังตรวจสอบความเป็นไปได้ในการจัดทำคำอธิบาย Flag ของ Terraform และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
บริการเสนอราคาของ AWS	ขอคำแนะนำเกี่ยวกับบริการเสนอราคาใน AWS และลักษณะการบันทึกและการกําหนดค่าเริ่มต้น	สำหรับการแก้ไขข้อบกพร่องบริการเสนอราคาภายใน TEE (เช่น บริการเสนอราคา) เราขอแนะนำให้ใช้การแก้ไขข้อบกพร่องที่ได้รับความยินยอมจาก AdTech ซึ่งจะช่วยให้คุณเปิดใช้การบันทึกโดยละเอียดและบันทึกข้อมูลคําขอ/การตอบกลับสําหรับคําขอทดสอบที่เฉพาะเจาะจงจากไคลเอ็นต์ได้โดยตรงเพื่อช่วยแก้ไขข้อบกพร่อง
TEE K/V เอกสารประกอบ	ขอคำชี้แจงเกี่ยวกับการเริ่มบังคับใช้ TKV ตามที่ระบุไว้ในเว็บไซต์สำหรับนักพัฒนาซอฟต์แวร์	เราจะแจ้งให้ทราบล่วงหน้าอย่างเพียงพอก่อนที่จะกำหนดให้ต้องใช้ TEE ในระหว่างนี้ คุณจะใช้เซิร์ฟเวอร์ของคุณเองสำหรับสัญญาณคีย์/ค่าแบบเรียลไทม์ต่อไปได้
การทดสอบและการวิเคราะห์ B&A	การวิเคราะห์และการทดสอบ B&A ยังคงมีค่าใช้จ่ายสูงและดูเหมือนว่ายังไม่พร้อมใช้งานจริง	เราต้องการข้อมูลเพิ่มเติมเกี่ยวกับการวิเคราะห์ต้นทุนและปัจจัยที่นำไปสู่การตัดสินความพร้อมใช้งานจริงเพื่อตรวจสอบเพิ่มเติม
การเพิ่มประสิทธิภาพเซิร์ฟเวอร์ที่เชื่อถือ	ข้อเสนอในการผสานพารามิเตอร์เฉพาะสำหรับผู้ขายคอมโพเนนต์เข้าด้วยกันเป็นพารามิเตอร์ inputsPerSeller รายการเดียว โดยใช้สตริง JSON เป็นค่า	เรากำลังหารือเกี่ยวกับข้อเสนอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
ความปลอดภัย	การใช้ B&A ช่วยบรรเทาความเสี่ยงด้านความปลอดภัยจาก TKV ได้อย่างไร	คุณสามารถป้องกันไม่ให้บุคคลภายนอกโทรหา TKV ได้ ซึ่งตอนนี้ GCP รองรับและกำหนดค่าได้อย่างเต็มที่ สำหรับ AWS จำเป็นต้องพัฒนาการสนับสนุนเพิ่มเติมเนื่องจากการเลิกใช้งาน AWS App Mesh ซึ่งก่อนหน้านี้ได้เปิดใช้ฟีเจอร์นี้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
บริการ B&A	ขอความชัดเจนเกี่ยวกับคําอธิบาย/การสื่อสารเกี่ยวกับคุณค่าของสตรีมมิง HTTP สําหรับการเพิ่มประสิทธิภาพการทดสอบและวัดผล	Privacy Sandbox รองรับความสามารถในการสตรีมในการโอนข้อมูล B&A เพื่อปรับปรุงเวลาในการตอบสนองสําหรับเทคโนโลยีโฆษณาที่เลือกใช้งาน การเพิ่มประสิทธิภาพเป็นตัวเลือกในกรณีที่ใช้โหมดผสม
Prebid	ขอข้อมูลอัปเดตเกี่ยวกับการมีส่วนร่วมในไลบรารี Prebid แบบโอเพนซอร์สเพื่อเปิดใช้ฟีเจอร์การทดสอบและรับรอง PA API สําหรับระบบนิเวศ	ในเดือนมีนาคม 2025 Chrome ได้เปิดตัวการเพิ่มประสิทธิภาพที่แนะนำของ Prebid ในเวอร์ชันเสถียรตามที่ระบุไว้ในแผนงานสาธารณะของ B&A (ดู เดือนมีนาคม 2025)
การกำหนดรูปแบบการเข้าชม	ขอกลไกในการบันทึกสัญญาณตามบริบทที่ได้รับจาก B&A เพื่อให้เข้าใจได้ดีขึ้นเมื่อมีการเปิดใช้งาน IG และปรับปรุงตรรกะ "ความตั้งใจที่จะเสนอราคา" ในการตอบสนองตามบริบท วิธีนี้ช่วยให้ใช้ทรัพยากรเครือข่ายได้ดียิ่งขึ้นเพื่อหลีกเลี่ยง "การเข้าชมที่ไม่มีประโยชน์" (หรือที่เรียกว่าการกำหนดปริมาณการเข้าชม)	ขณะนี้เรากำลังหารือเกี่ยวกับข้อเสนอ ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
เอกสารประกอบ คําชี้แจง	โปรดชี้แจงเกี่ยวกับข้อผิดพลาด "เข้าถึง Service/Vsock proxy ไม่ได้" ที่พบในการตั้งค่าการผสานรวมการทดสอบ B&A	สาเหตุคือข้อกำหนดขั้นต่ำของหน่วยความจำ เราได้อัปเดตคำอธิบายการกําหนดค่า AWS ให้สอดคล้องกับข้อกําหนดนี้

การวัดผลโฆษณาดิจิทัล

การรายงานการระบุแหล่งที่มา (และ API อื่นๆ)

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ข้อมูลแบบเรียลไทม์	การไม่มีข้อมูลแบบเรียลไทม์ส่งผลต่อทุกคนในอุตสาหกรรม ข้อมูลแบบเรียลไทม์ที่ล่าช้าเป็นปัญหาร้ายแรงสําหรับผู้ลงโฆษณา ผู้ซื้อจึงเปลี่ยนไปใช้แพลตฟอร์มที่มี Google Analytics เนื่องจากเป็นแพลตฟอร์มเดียวที่จะได้รับหลักฐานการเข้าถึงกลุ่มเป้าหมาย	ความล่าช้าของข้อมูลแบบเรียลไทม์ซึ่งเป็นส่วนหนึ่งของ Attribution Reporting API (ARA) จะใช้เป็นกลไกการคุ้มครองความเป็นส่วนตัวเพื่อลดความสามารถของเทคโนโลยีโฆษณาในการใช้รายงานระดับเหตุการณ์เพื่อติดตามผู้ใช้ในเว็บไซต์ต่างๆ อย่างไรก็ตาม ARA มีความยืดหยุ่นในการแสดงรายงานการระบุแหล่งที่มา โดยอนุญาตให้รายงานระดับเหตุการณ์มีกรอบเวลารายงานขั้นต่ำ 1 ชั่วโมง และอนุญาตให้รายงานแบบรวมมีตัวเลือกในการส่งไปยังเทคโนโลยีโฆษณาได้ทันทีโดยไม่มีเวลาหน่วง
การใช้ API	ขอการยืนยันเกี่ยวกับการกําหนดค่าที่ถูกต้องสําหรับขั้นตอนการระบุแหล่งที่มาแบบข้ามเว็บแอป โดยเฉพาะเมื่อใช้การระบุแหล่งที่มาแบบเว็บต่อเว็บและการระบุแหล่งที่มาแบบเว็บต่อแอปควบคู่กัน	เมื่อเรียกใช้แคมเปญจากเว็บสู่เว็บและจากเว็บสู่แอปควบคู่กัน เทคโนโลยีโฆษณาควรเลือกเพียงแพลตฟอร์มเดียวเพื่อลงทะเบียนแหล่งที่มาหรือทริกเกอร์แต่ละรายการ เพื่อป้องกันไม่ให้มีการนับซ้ำ เราขอแนะนําอย่างยิ่งให้ใช้ระบบปฏิบัติการ (OS) เมื่อเป็นไปได้ เนื่องจากระบบปฏิบัติการสามารถระบุแหล่งที่มาของทั้งเว็บต่อเว็บและเว็บต่อแอป ตราบใดที่มีการมอบสิทธิ์แหล่งที่มาของเว็บและทริกเกอร์อย่างถูกต้อง ซึ่งหมายความว่าการตอบกลับด้วยส่วนหัว Attribution-Reporting-Register-OS-Source สําหรับแหล่งที่มา และส่วนหัว Attribution-Reporting-Register-OS-Trigger สําหรับทริกเกอร์ ส่วนหัวการสนับสนุนการรายงานการระบุแหล่งที่มาสามารถใช้เพื่อระบุว่ามีการรองรับระดับ Chrome และ/หรือ Android หรือไม่ ส่วนหัว Attribution-Reporting-Info จะมีประโยชน์เมื่อไม่มีส่วนหัว Attribution-Reporting-Support ในคําขอ ซึ่งในกรณีนี้เบราว์เซอร์จะตัดสินใจเกี่ยวกับการลงทะเบียนแพลตฟอร์มโดยอิงตามความพร้อมให้บริการของการสนับสนุนแพลตฟอร์มในอุปกรณ์ของผู้ใช้
ข้อกำหนดของ API	ขอคำชี้แจงเกี่ยวกับส่วนหัวคำขอ HTTP ของ Attribution-Reporting-Support ที่ Attribution Reporting API ตั้งค่าไว้ และต้องการทราบว่าส่วนหัวมีไว้เพื่อให้มีทั้งคีย์เว็บและคีย์ระบบปฏิบัติการ ไม่ว่าแพลตฟอร์มจะเป็นแพลตฟอร์มใดก็ตาม	ส่วนหัวการสนับสนุนการรายงานการระบุแหล่งที่มาขึ้นอยู่กับเบราว์เซอร์ที่เพิ่มพารามิเตอร์ "GREASE" เพื่อให้แน่ใจว่าเซิร์ฟเวอร์ใช้โปรแกรมแยกวิเคราะห์ส่วนหัว Structured ที่เป็นไปตามข้อกําหนด สําหรับส่วนหัวนี้ ควรตีความเฉพาะคีย์ของพจนานุกรมที่มีโครงสร้างเท่านั้น ขณะนี้ไม่มีการใช้ค่าและพารามิเตอร์ ดูตัวอย่างได้ที่นี่
การรายงานที่อิงตาม 3PC	ขอคําแนะนําเกี่ยวกับวิธีแก้ปัญหาความคลาดเคลื่อนในการวัดผลระหว่าง ARA กับ 3PC ในแคมเปญโฆษณา	ARA รองรับรายงานข้อบกพร่อง 2 ประเภทที่สามารถใช้แก้ปัญหาและแก้ไขความคลาดเคลื่อนได้ คุณสามารถใช้รายงานการแก้ไขข้อบกพร่องการระบุแหล่งที่มาที่ประสบความสําเร็จเพื่อเปรียบเทียบผลลัพธ์ ARA กับผลลัพธ์จากเทคโนโลยีการวัดอื่นๆ ได้อย่างง่ายดาย และสามารถใช้รายงานการแก้ไขข้อบกพร่องแบบละเอียดเพื่อรับข้อมูลเพิ่มเติมและแก้ปัญหาที่อาจเกิดขึ้นในการลงทะเบียนการระบุแหล่งที่มา
การใช้ API	ขณะทดสอบ ARA เราพบปัญหาบางอย่าง เช่น การรายงานแบบละเอียดไม่เพียงพอซึ่งทําให้ข้อมูลมีสัญญาณรบกวนมากและการเพิ่มประสิทธิภาพแคมเปญยืดหยุ่นน้อย เกณฑ์สูงที่ยกเว้นผู้ลงโฆษณารายเล็ก และปัญหาในการเปรียบเทียบแคมเปญเนื่องจากตัวชี้วัดประสิทธิภาพหลักไม่สอดคล้องกัน	ARA มีความยืดหยุ่นเนื่องจากมีพารามิเตอร์หลายรายการที่นักเทคโนโลยีโฆษณาสามารถปรับแต่งเพื่อให้บรรลุกรณีการใช้งานการวัดผลที่เฉพาะเจาะจง รายงานระดับเหตุการณ์รองรับการรายงานระดับเหตุการณ์ที่ยืดหยุ่น ซึ่งช่วยให้นักเทคโนโลยีโฆษณาปรับแต่งกรอบเวลาการรายงาน จํานวนรายงานที่รับได้ และข้อมูลทริกเกอร์ที่ต้องการวัด ซึ่งสามารถเปลี่ยนผลกระทบของสัญญาณรบกวนต่อข้อมูลและช่วยให้บรรลุ Use Case ต่างๆ ได้ ในทํานองเดียวกัน รายงานรวมมีวิธีต่างๆ ที่เทคโนโลยีโฆษณาสามารถปรับแต่งการกําหนดค่า เช่น จํานวนมิติข้อมูลที่ติดตาม ความถี่การแบ่งกลุ่ม และการใช้งบประมาณการมีส่วนร่วมเพื่อเปลี่ยนผลกระทบของสัญญาณรบกวน และบรรลุกรณีการใช้งานที่แตกต่างกันด้วย
ข้อกำหนดของ API	คำถามเกี่ยวกับข้อกำหนดของ ARA ใน 3PC โดยเฉพาะว่ายังอยู่ในระยะการทดสอบที่ต้องใช้ 3PC เหล่านี้อยู่หรือไม่	ARA จะเปิดใช้แยกจาก 3PC แต่ต้องเปิดใช้ 3PC เพื่ออนุญาตให้การรายงานการแก้ไขข้อบกพร่องช่วงเปลี่ยนผ่านของ ARA เปรียบเทียบผลลัพธ์ของ ARA กับผลลัพธ์การระบุแหล่งที่มาโดยอิงตามคุกกี้
การใช้ API	คําถามเกี่ยวกับการลงทะเบียนแหล่งที่มาสำหรับการระบุแหล่งที่มาจากแอปไปยังเว็บใน Android เวอร์ชันเก่า (11, 12 และ 13) โดยใช้ ARA	ปัจจุบัน ARA ใช้งานได้ใน Android S ขึ้นไป (12 ขึ้นไป)
การใช้ API	ขอรายละเอียดอัตราค่าสมัครใช้บริการ ARA และรายละเอียดการเผยแพร่	คำตอบของเราไม่มีการเปลี่ยนแปลงจากไตรมาสก่อนหน้า "เราไม่มีแผนที่จะแชร์ข้อมูลนี้กับระบบนิเวศ นักพัฒนาแอปสามารถเรียกใช้ API ที่ตนมีโค้ดที่ติดตั้งใช้งานอยู่ในปัจจุบันเพื่อประเมินความพร้อมใช้งานของ Privacy Sandbox API"
ความพร้อมใช้งานของ API	เมื่อเปิดใช้ ARA 3PC เปิดหรือปิดใช้อยู่	เมื่อเปิดใช้ ARA ในเบราว์เซอร์ของผู้ใช้ การตั้งค่าคุกกี้ของผู้ใช้จะไม่ได้รับผลกระทบ เป็นไปได้ที่ ARA จะเปิดใช้อยู่และผู้ใช้จะเปิดหรือปิดใช้คุกกี้ก็ได้
การรายงาน	มีรายการค่าที่กำหนดไว้ล่วงหน้าซึ่งเราจะได้รับในส่วนหัว "Attribution-reporting-support" ไหม	ตามที่กำหนดไว้ใน คำแนะนำ ค่านี้เป็นพจนานุกรมส่วนหัวที่มีโครงสร้าง ซึ่งปัจจุบันมีการกำหนดความหมายไว้เพียงอย่างเดียวคือ การมีหรือไม่มีคีย์ระบบปฏิบัติการและคีย์เว็บ ส่วนอื่นๆ ทั้งหมดของส่วนหัวควรละเว้น กล่าวคือ ต้องใช้โปรแกรมแยกวิเคราะห์ส่วนหัว Structured ไม่ใช่การจับคู่สตริงอย่างง่าย

บริการรวมข้อมูล

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
คำขอฟีเจอร์	คำขอฟีเจอร์สําหรับบริการรวมข้อมูล การผสานรวมแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ การวัดผลข้ามอุปกรณ์ การรายงานการระบุแหล่งที่มาแบบหลายทัชพอยต์และการมีส่วนร่วมที่ง่ายดาย การระบุแหล่งที่มาแบบหลายช่องทาง และการรองรับลูปการเพิ่มประสิทธิภาพ ML ขั้นสูง (เช่น การฝึกโมเดลส่วนตัว)	เรากำลังประเมินคำขอเหล่านี้และจะแชร์รายละเอียดเพิ่มเติมเมื่อพร้อม เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าคำขอเหล่านี้ควรมีความสำคัญหรือไม่
คำขอฟีเจอร์	คำขอตั้งค่าพารามิเตอร์ delete_on_termination ของ EBS เป็น True ในสภาพแวดล้อม terraform เพื่อลดความกังวลเกี่ยวกับการรีเซ็ตเมื่ออัปเดตชุดบริการการรวม	เรากำลังประเมินคำขอนี้และจะแชร์รายละเอียดเพิ่มเติมเมื่อพร้อม เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าคำขอนี้ควรมีความสำคัญหรือไม่ที่นี่
เอกสารประกอบ คําชี้แจง	ขอคำแนะนำเกี่ยวกับสิ่งที่เปลี่ยนแปลงได้ (เช่น เกณฑ์การตรวจสอบ) และสิ่งที่ต้องคงไว้	เรากําลังประเมินการเผยแพร่เอกสารประกอบและคำแนะนำเพิ่มเติมเกี่ยวกับการปรับแต่งที่ใช้ได้สำหรับบริการรวบรวมข้อมูล
การทำให้ใช้งานได้	ขอคำชี้แจงเกี่ยวกับการทำให้ใช้งานได้ใหม่ไม่สำเร็จที่คำสั่ง bazel	การติดตั้งใช้งานไม่สําเร็จอาจเกิดขึ้นเนื่องจากเวอร์ชัน bazel ที่ใช้ในสภาพแวดล้อม เราจะปรับเอกสารประกอบให้ครอบคลุมการแก้ไขข้อบกพร่องเมื่อ Terraform ไม่ทำงาน รวมถึงระบุเวอร์ชัน Bazel ที่จำเป็น

Private Aggregation API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การใช้ API	ขอคำแนะนำเกี่ยวกับปัญหาการใช้งานบางอย่าง เช่น ข้อมูลที่อาจสูญหายเนื่องจากข้อจำกัดของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันที่รายงานไว้ ปัญหาเกี่ยวกับ Cardinality สูงที่ต้องใช้รายการที่อนุญาตของบริการรวบรวมข้อมูลที่ซับซ้อน (แนะนำให้ใช้ไวลด์การ์ด) และการทดสอบที่ช้าลงเนื่องจากกฎ "ไม่ซ้ำกัน" ของบริการรวบรวมข้อมูล	ขีดจํากัดการมีส่วนร่วม 20 รายการ (ดูรายละเอียดที่นี่) ของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันคือต่อการดำเนินการ 1 ครั้ง ไม่ใช่ต่อเดือน นอกจากนี้ ผู้เรียก API ยังลบล้างขีดจํากัดนี้ได้ ขีดจํากัดนี้มีไว้เพื่อช่วยจัดการค่าใช้จ่ายในการประมวลผลรายงานในบริการรวบรวมข้อมูล และไม่ได้จํากัดยูทิลิตีการรายงาน สำหรับคำค้นหาที่ใช้ไวลด์การ์ด เรากำลังประเมินคำขอนี้และจะแชร์รายละเอียดเพิ่มเติมเมื่อพร้อม สำหรับกฎ "ไม่ซ้ำกัน" เรารองรับโหมดแก้ไขข้อบกพร่องเป็นการชั่วคราวเพื่อวัตถุประสงค์ในการข้ามกฎนี้เพื่อให้สามารถทดสอบได้ ข้อมูลนี้ระบุไว้อย่างละเอียดที่นี่
การกรองรหัสและที่เก็บข้อมูล	ฉันจะขอใช้ที่เก็บข้อมูลเดียวกันกับบริการรวบรวมข้อมูลที่มีรหัสการกรอง 2 รหัสที่แตกต่างกันในการเรียกใช้การรวบรวมข้อมูล 2 ครั้งแยกกันได้ไหม เช่น รหัสการกรองจะทำหน้าที่เป็นการจัดสรรโดเมนเพิ่มเติมได้ไหม	รองรับ เมื่อทำการรวม ระบบจะประมวลผลเฉพาะข้อมูลที่มีส่วนร่วมซึ่งมีรหัสการกรองตรงกับรายการในพารามิเตอร์งาน ส่วนที่เหลือจะยังคงพร้อมให้ประมวลผลในการเรียกใช้แยกต่างหาก
การระบุแหล่งที่มาแบบมัลติทัช	คําขอคําชี้แจงเกี่ยวกับการใช้งานการระบุแหล่งที่มาแบบหลายทัชพอยต์ (MTA) 1) จํานวนการมีส่วนร่วมมีขีดจํากัดไหมหากค่าการรวมข้อมูลไม่เกิน 2^16 2) มีการจํากัดจํานวนคีย์การรวมที่ไม่ซ้ำกัน (ที่เก็บข้อมูล) ที่เก็บสําหรับบริบทหนึ่งๆ ได้ไหม 3) บริการรวมข้อมูลจะประมวลผลรายงานสรุปอย่างไรเมื่อ User Agent (เบราว์เซอร์) แต่ละรายการมีคีย์การรวมที่ไม่ซ้ำกัน ซึ่งเป็นไปได้ใน MTA	1) เราได้กำหนดขีดจำกัดการมีส่วนร่วมเริ่มต้นไว้ แต่ผู้เรียก API ยังมีตัวเลือกในการลบล้างขีดจำกัดดังกล่าวตามที่อธิบายไว้ที่นี่ ขีดจํากัดมีไว้เพื่อช่วยให้ผู้เรียก API จัดการค่าใช้จ่ายในการประมวลผลรายงานในบริการรวบรวมข้อมูล 2) ไม่มีขีดจํากัดดังกล่าว แต่เทคโนโลยีโฆษณาควรพิจารณาความละเอียดของคีย์การรวมข้อมูลเพื่อปรับปรุงอัตราส่วนสัญญาณต่อสัญญาณรบกวนตามที่อธิบายไว้เพิ่มเติมที่นี่ 3) โปรดดูคําแนะนํานี้ โดยเฉพาะคําแนะนําเกี่ยวกับสัญญาณรบกวนซึ่งระบุไว้ข้างต้นในข้อ 2)

จำกัดการติดตามแอบแฝง

การลด User Agent/คำแนะนำสำหรับไคลเอ็นต์ User Agent

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
คำขอฟีเจอร์	คำขอเพิ่ม Sec-CH-UA-Robot ลงในคำแนะนำไคลเอ็นต์ User-Agent (UA-CH) เนื่องจากจะช่วยให้เซิร์ฟเวอร์ระบุการเข้าชมอัตโนมัติสำหรับการปรับเปลี่ยนเนื้อหา ความปลอดภัย และการวิเคราะห์ได้	นี่เป็น Use Case ที่สําคัญซึ่งกำลังมีการพูดคุยกันในกลุ่มมาตรฐานอื่นๆ (ดูรายละเอียดเพิ่มเติมได้ที่ที่นี่ ) และเราขอแนะนําให้บุคคลที่สนใจเข้าร่วมโดยแสดงความคิดเห็น อย่างไรก็ตาม เราพิจารณาแล้วว่า UA-CH อาจไม่ใช่โซลูชันที่เหมาะสม เนื่องจากการเข้าชมอัตโนมัติสามารถดัดแปลงส่วนหัวของคําขอ HTTP ได้โดยง่าย

การปกป้อง IP (เดิมเรียกว่า Gnatcatcher)

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ความเป็นส่วนตัวเกี่ยวกับที่อยู่ IP	การที่ Google อนุญาตให้ใช้ที่อยู่ IP ขัดต่อเป้าหมายด้านความเป็นส่วนตัวที่ระบุไว้ แม้ว่า Google จะบอกว่าจะลบข้อมูลระบุตัวตนออกผ่านการปกป้อง IP แต่ผู้ใช้ต้องเข้าสู่ระบบ Chrome เพื่อใช้การปกป้อง IP ดังนั้น Google จึงยังคงเรียนรู้ข้อมูลระบุตัวตนของผู้ใช้	เหตุผลในการเข้าสู่ระบบมีไว้เพื่อวัตถุประสงค์ในการป้องกันการประพฤติมิชอบและการละเมิด โดยหลักๆ คือการจำกัดอัตราการเข้าถึงพร็อกซี นอกจากนี้ เพื่อปกป้องความเป็นส่วนตัวของผู้ใช้ในบริบทของข้อกําหนดการตรวจสอบสิทธิ์ การออกแบบโทเค็นของเราเป็นแบบเซ็นชื่อโดยไม่ระบุตัวตน ซึ่งหมายความว่าโทเค็นที่ออกในระหว่างการเข้าสู่ระบบจะแตกต่างจากโทเค็นที่ใช้ในระหว่างการพร็อกซี ดังนั้นโทเค็นที่ออกจึงไม่สามารถลิงก์กับข้อมูลประจำตัวของผู้ใช้ Google ในภายหลัง ซึ่งหมายความว่า Google จะไม่ทราบว่าผู้ใช้เป็นใครเมื่อมีการพร็อกซีการเข้าชมของผู้ใช้รายนั้นในโหมดไม่ระบุตัวตน แม้ว่าจะมีข้อกำหนดการตรวจสอบสิทธิ์เพื่อเหตุผลด้านการป้องกันการประพฤติมิชอบก็ตาม
ความเป็นส่วนตัวเกี่ยวกับที่อยู่ IP	การใช้ IP เป็นก้าวที่ผิดทาง ไม่สามารถลบออกจากเบราว์เซอร์ได้ เช่น คุกกี้ และผู้ใช้ไม่มีการควบคุมความโปร่งใสแบบเดียวกับคุกกี้ หากคุกกี้หมดไป อุตสาหกรรมจะเปลี่ยนไปใช้ IP เป็นโซลูชันทางเลือก โดยให้ความสําคัญกับการปกป้องตนเองมากกว่าความเป็นส่วนตัว	Chrome เป็นแพลตฟอร์มที่มุ่งมั่นที่จะมอบฟีเจอร์ต่างๆ ให้แก่ผู้ใช้เพื่อปรับปรุงประสบการณ์การท่องเว็บ สำหรับผู้ใช้ Chrome ที่เลือกท่องเว็บในโหมดไม่ระบุตัวตน ฟีเจอร์นี้จะมอบการปกป้องที่ดียิ่งขึ้นจากการติดตามข้ามเว็บไซต์ด้วยการจำกัดความพร้อมใช้งานของข้อมูลที่อยู่ IP ในบริบทของบุคคลที่สาม
รายการโดเมนที่มีการมาสก์	เกณฑ์การคัดเลือกในรายการโดเมนที่มีการมาสก์ (MDL) คืออะไร	Chrome ได้พัฒนาเกณฑ์เพื่อระบุโดเมนที่ควรอยู่ใน MDL และจะได้รับที่อยู่ IP ที่ถูกมาสก์ในบริบทของบุคคลที่สาม Google ได้ร่วมมือกับ Disconnect.me ซึ่งเป็นผู้นำด้านความเป็นส่วนตัวบนอินเทอร์เน็ตที่มีชื่อเสียงและยังทำงานร่วมกับเว็บเบราว์เซอร์อื่นๆ ด้วย Chrome จะใช้ Disconnect.me เพื่อระบุโดเมนที่สอดคล้องกับเกณฑ์ที่กำหนดไว้ของ Chrome นอกจากนี้ Chrome ยังพัฒนาวิธีการระบุฟังก์ชัน JavaScript ที่ใช้กันอย่างแพร่หลายซึ่งให้เอาต์พุตที่สอดคล้องกันจาก Web API ที่เสถียรและมีข้อมูลความน่าจะเป็นสูง จึงนำไปสร้างตัวระบุแบบความน่าจะเป็นที่มีข้อมูลความน่าจะเป็นสูงได้ จากนั้นระบบจะตรวจหาฟังก์ชันเหล่านี้เมื่อโหลดในเว็บไซต์ในบริบทของบุคคลที่สาม ซึ่งจะส่งผลให้มีรายการโดเมนที่แสดงสคริปต์ที่มีลักษณะเหล่านี้ซึ่งกลายเป็นส่วนหนึ่งของ MDL และได้รับการเปลี่ยนเส้นทาง ไปป์ไลน์การตรวจหาที่มองหารูปแบบการใช้ API ในทางที่ผิดเหล่านี้จะพิจารณาโดเมนทั้งหมด รวมถึงโดเมนของ Google เองด้วย
การป้องกันการประพฤติมิชอบ	ความคิดเห็นเกี่ยวกับโทเค็นการเปิดเผยแบบมีแนวโน้ม (PRT) ที่เสนอว่าความล่าช้าในการเปิดเผย 24 ชั่วโมงและอัตราการเปิดเผยที่เสนอจะขัดขวางการตรวจจับการประพฤติมิชอบแบบเรียลไทม์ ขอเวลาเลื่อนที่สั้นลง (เลื่อน 1 ชั่วโมง) และอัตราที่สูงขึ้น (อย่างน้อย 2 หลัก) คำแนะนำเพิ่มเติม ได้แก่ การเปิดใช้ราคาที่แตกต่างกันตามสัญญาณความเสี่ยง (VPN, เบราว์เซอร์อัตโนมัติ) และการอนุญาตให้แสดงโทเค็นที่เฉพาะเจาะจงตามเป้าหมาย	นักพัฒนาแอปส่วนใหญ่ที่เราพูดคุยด้วยจะรายงานให้ลูกค้าทราบเป็นรายชั่วโมง และอัปเดตรายการที่บล็อก IP หลายรายการตลอดทั้งวัน ระยะเวลาการเลื่อนเวลาสั้นลงจะช่วยให้มีการอัปเดตบ่อยขึ้น และหากน้อยกว่า 1 ชั่วโมง ระบบจะเปิดใช้การวัด IVT อีกครั้งในสถิติรายชั่วโมง แต่อาจเพิ่มโอกาสที่ผู้ใช้จะระบุตัวตนได้อีกครั้งด้วย เราเปิดกว้างที่จะลองลดระยะเวลารอและเปลี่ยนอัตราการแสดงผลตามการศึกษาระบบนิเวศ รวมถึงความคิดเห็นจากผู้มีส่วนเกี่ยวข้อง และยินดีรับความคิดเห็นเพิ่มเติมที่นี่
รายการโดเมนที่มีการมาสก์	คำถามเกี่ยวกับการรวมโดเมนใน MDL แม้ว่าจะไม่มีกรณีการใช้งานการโฆษณา ความกังวลว่าการดำเนินการนี้อาจเปิดใช้ "การบริดจ์ IP" เพื่อสร้างโปรไฟล์ตามที่อยู่ IP	เราตระหนักดีว่ากระบวนการอุทธรณ์สำหรับแนวทางตามรายการมีความสําคัญเพียงใด การอุทธรณ์ช่วยให้บริษัทสามารถอ้างว่าโดเมนของตนใน MDL ไม่เป็นไปตามเกณฑ์การรวมและควรถูกนำออก ซึ่งจะช่วยให้โดเมนดังกล่าวยังคงได้รับที่อยู่ IP เดิมของผู้ใช้ในบริบทของบุคคลที่สามในโหมดไม่ระบุตัวตนต่อไป ตอนนี้เราได้เริ่มกระบวนการอุทธรณ์เพื่อให้เจ้าของโดเมนมีเวลาเพียงพอในการอุทธรณ์และรับคำตัดสินก่อนการเปิดตัวการคุ้มครองทรัพย์สินทางปัญญาในโหมดไม่ระบุตัวตนใน Chrome เวอร์ชันเสถียร ดูรายละเอียดเพิ่มเติมเกี่ยวกับกระบวนการอุทธรณ์ได้ที่นี่
รายการโดเมนที่มีการมาสก์	ความคิดเห็นที่ผู้เผยแพร่โฆษณากำลังตรวจสอบผลกระทบที่เกิดจากการรวมพาร์ทเนอร์ของตนไว้ใน MDL ลูกค้ารู้สึกมั่นใจมากขึ้นเมื่ออ่านข้อกําหนดเกี่ยวกับ GeoIP ในส่วนคําอธิบายการปกป้อง IP	Chrome ตระหนักถึงความสำคัญของการรองรับกรณีการใช้งานตามภูมิศาสตร์ พร็อกซีจะกําหนดที่อยู่ IP ที่แสดงตําแหน่งโดยคร่าวๆ ของผู้ใช้ ซึ่งรวมถึงประเทศ ดูข้อมูลเพิ่มเติมได้ในคำอธิบายเกี่ยวกับตำแหน่งทางภูมิศาสตร์ของ IP
รายการโดเมนที่มีการมาสก์	คำถามเกี่ยวกับ MDL ว่าการกำหนดเป้าหมายระดับประเทศยังใช้งานได้หรือไม่	Chrome ตระหนักถึงความสำคัญของการรองรับกรณีการใช้งานตามภูมิศาสตร์ พร็อกซีจะกําหนดที่อยู่ IP ที่แสดงตําแหน่งโดยคร่าวๆ ของผู้ใช้ ซึ่งรวมถึงประเทศ ดูข้อมูลเพิ่มเติมได้ในคำอธิบายเกี่ยวกับตำแหน่งทางภูมิศาสตร์ของ IP
การตรวจจับการประพฤติมิชอบ	ข้อกังวลเกี่ยวกับผลกระทบของการป้องกัน IP ต่อระบบการตรวจจับการประพฤติมิชอบ ผู้ใช้จะเห็น IP ของพร็อกซีหรือส่วนหัวไหม SSP และ DSP จะดูที่อยู่ IP ของพร็อกซีเดียวกันสําหรับการใช้งานหนึ่งๆ ได้ไหม ความไม่สอดคล้องอาจส่งผลต่อการตรวจจับการประพฤติมิชอบและ OpenRTB	ผู้ใช้ที่ท่องเว็บในโหมดไม่ระบุตัวตนซึ่งเปิดใช้การปกป้อง IP และส่งคำขอไปยังโดเมนใน MDL จะได้รับที่อยู่ IP ของพร็อกซีตามฟีดข้อมูลทางภูมิศาสตร์ที่กําหนด องค์กรอาจขอให้ส่ง PRT เป็นส่วนหัวเพิ่มเติมในการเข้าชมผ่านพร็อกซี ซึ่งจะเปิดเผยตัวอย่าง IP เดิมจำนวนเล็กน้อยหลังจากระยะเวลาหน่วงเวลา เราสงสัยว่า SSP จํานวนมากจะส่งผ่านที่อยู่ IP ที่ใช้พร็อกซีในคําขอราคาเสนอฝั่งเซิร์ฟเวอร์ไปยังพาร์ทเนอร์ดีมานด์ แต่ DSP ที่ชนะไม่รับประกันว่าจะได้เห็นที่อยู่ IP ของพร็อกซีเดียวกัน ณ เวลาแสดงผล
การตรวจจับการประพฤติมิชอบ	คำถามเกี่ยวกับความถี่ในการอัปเดตไฟล์ตําแหน่งทางภูมิศาสตร์ของ IP, ช่วงเวลาการอัปเดตรายละเอียดการรายงานพฤติกรรมที่เป็นการฉ้อโกงและ PRT และวิธีที่เทคโนโลยีโฆษณาควรตรวจหากิจกรรมที่เป็นการฉ้อโกง	คําอธิบาย PRT พร้อมใช้งานแล้ว รวมถึงรายการที่อยู่ IP ของพร็อกซีและภูมิภาคตามภูมิศาสตร์ที่เชื่อมโยง เราขอแนะนําให้ตรวจสอบไฟล์นี้เป็นระยะๆ เพื่อดูการอัปเดตและการเปลี่ยนแปลง เนื่องจากที่อยู่ IP จะเปลี่ยนไปเรื่อยๆ เราจะประกาศอีเมลสาธารณะสำหรับรายงานการละเมิดเมื่อใกล้ถึงช่วงเปิดตัว
ตำแหน่งทางภูมิศาสตร์	คำขอรายการที่อยู่ IP สาธารณะที่ใช้สำหรับพร็อกซี	ไฟล์การแมปที่อยู่ IP กับตำแหน่งคร่าวๆ สำหรับการคุ้มครองทรัพย์สินทางปัญญามีให้ดูที่นี่ โปรดทราบว่าไฟล์นี้จะได้รับการอัปเดตเป็นระยะ
การใช้ API	การกล่าวอ้างว่าการปกป้อง IP เปิดอยู่โดยค่าเริ่มต้นและผู้ใช้ไม่มีตัวเลือกในการเลือกไม่ใช้	การปกป้องที่อยู่ IP จะพร้อมให้บริการแก่ผู้ใช้ในโหมดไม่ระบุตัวตนของ Chrome บนแพลตฟอร์ม Android และเดสก์ท็อป ผู้ใช้จะปิดใช้การปกป้อง IP ได้ สำหรับ Chrome เวอร์ชันที่จัดการโดยองค์กร คุณจะเปิดใช้การปกป้อง IP ได้ แต่ระบบจะปิดฟีเจอร์นี้ไว้โดยค่าเริ่มต้น
การใช้ API	คําถามเกี่ยวกับความพร้อมใช้งานของ Flag การทดสอบเพื่อเปิดใช้และทดสอบการคุ้มครองทรัพย์สินทางปัญญาใน Chrome Canary และรุ่นเบต้า	ขณะนี้เราไม่มี Flag การทดสอบสำหรับทดสอบฟีเจอร์การคุ้มครองทรัพย์สินทางปัญญาอย่างเต็มรูปแบบ การทดสอบฟังก์ชันการทำงานที่เราดําเนินการอยู่จะทดสอบเฉพาะการเข้าชมผ่านพร็อกซีที่ไปยังโดเมน Google เท่านั้น
ความเป็นส่วนตัวเกี่ยวกับที่อยู่ IP	การตั้งค่าข้อความแจ้ง 3PC จะทำงานอย่างไรเมื่อเบราว์เซอร์เปลี่ยนไปใช้โหมดไม่ระบุตัวตน	ระบบจะบล็อก 3PC โดยค่าเริ่มต้นในโหมดไม่ระบุตัวตน
โหมดไม่ระบุตัวตน	ขอคำชี้แจงว่าฟีเจอร์การปกป้อง IP ทำงานในโหมดไม่ระบุตัวตนเมื่อผู้ใช้ไม่ได้ลงชื่อเข้าใช้ Chrome หรือไม่	การปกป้อง IP จะไม่ทำงานหากผู้ใช้ไม่ได้เข้าสู่ระบบ Chrome ก่อนเปิดโหมดไม่ระบุตัวตน เหตุผลคือเพื่อวัตถุประสงค์ในการป้องกันการประพฤติมิชอบและการฉ้อโกง ซึ่งก็คือการจำกัดอัตราการเข้าถึงพร็อกซี การป้องกัน IP จะใช้การตรวจสอบสิทธิ์ไคลเอ็นต์เพื่อจำกัดความสามารถของผู้ไม่ประสงค์ดีในการใช้ประโยชน์จากพร็อกซีเพื่อขยายการโจมตีบริการใน MDL ดังนั้น การปกป้องที่อยู่ IP จะพร้อมให้บริการแก่ผู้ใช้ที่ได้รับการตรวจสอบสิทธิ์โดยใช้บัญชี Google ที่ลงชื่อเข้าใช้ในเบราว์เซอร์ Chrome ก่อนที่จะเปิดหน้าต่างที่ไม่ระบุตัวตนใหม่เท่านั้น
โหมดไม่ระบุตัวตน	คำขอประเมินผลกระทบของการป้องกัน IP ก่อนเปิดตัว ซึ่งรวมถึง (1) การใช้ Flag สถานะเบราว์เซอร์หรือการรายงาน API แบบรวมเพื่อประเมินปริมาณการใช้งานโหมดไม่ระบุตัวตน (2) การส่งส่วนหัวการป้องกัน IP เป็นระยะเวลาหนึ่งก่อนที่จะเปิดใช้ฟีเจอร์ และ (3) การนำฟีเจอร์ไปใช้กับการเข้าชมเพียงไม่กี่เปอร์เซ็นต์ที่ทราบเพื่อประมาณ	เราเข้าใจความสนใจของทั้งระบบนิเวศในการทําความเข้าใจและวัดขนาดและผลกระทบของการคุ้มครองทรัพย์สินทางปัญญา อย่างไรก็ตาม Chrome พยายามทำให้ตัวเลือกของผู้ใช้ในการท่องเว็บในโหมดไม่ระบุตัวตนเป็นส่วนตัว Chrome ไม่ได้เปิดเผยวิธีการตรวจหาผู้ใช้ที่ท่องเว็บในโหมดไม่ระบุตัวตน และได้ดำเนินการเพื่อจำกัดสัญญาณอื่นๆ ที่อาจเปิดเผยโหมดการท่องเว็บของผู้ใช้ เรากำลังพิจารณาวิธีอำนวยความสะดวกในการทดสอบนี้โดยไม่ส่งผลกระทบต่อความเป็นส่วนตัวของผู้ใช้ที่ท่องเว็บในโหมดไม่ระบุตัวตน และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ

การลดการติดตามการเข้าออก

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การปฏิบัติตามข้อกำหนด	การที่ Google ไม่เต็มใจให้สิทธิ์ในการใช้เทคนิคการลดการติดตามการตีกลับ (BTM) ที่เป็นไปตามนิติบัญญัติด้านการคุ้มครองข้อมูลนั้นไม่มีพื้นฐานทางกฎหมายและทำให้กระบวนการอุทธรณ์เกี่ยวกับแซนด์บ็อกซ์ความเป็นส่วนตัวไม่มีความหมาย	ตามที่เราได้อธิบายไว้ในรายงานความคิดเห็นฉบับก่อนหน้า สถานะการปฏิบัติตามข้อกำหนดไม่มีความสัมพันธ์กับการใช้งาน BTM และ Google ไม่ได้เป็นผู้ตัดสินใจใดๆ เกี่ยวกับการปฏิบัติตามข้อกำหนดในการใช้งาน BTM BTM เช่นเดียวกับการปกป้องความเป็นส่วนตัวอื่นๆ ของ Chrome จะมุ่งเน้นที่การขยายการควบคุมของผู้ใช้เกี่ยวกับการแชร์ข้อมูลของตนหรือไม่และอย่างไร กระบวนการอุทธรณ์ที่มีการจัดการโดยบุคคลที่สามซึ่งอ้างอิงในรายงานในไตรมาสที่ 2/3 ของ CMA เกี่ยวข้องกับเฉพาะกรณีที่ Google เป็นผู้ตัดสินใจเกี่ยวกับการรวมหรือยกเว้นบริษัทแต่ละรายในรายการ
การปฏิบัติตามข้อกำหนด	การพูดคุยเกี่ยวกับวิธีที่เบราว์เซอร์ปฏิบัติตามการดำเนินการที่ได้รับอนุญาตตามกฎหมายในบริบทของ GDPR โดยไฮไลต์สถานการณ์ที่เบราว์เซอร์อาจระงับการดำเนินการ (เช่น การเปลี่ยนเส้นทางหรือการตั้งค่าคุกกี้) ที่ผู้ใช้ให้ความยินยอมอย่างชัดเจน ซึ่งทำให้เกิดความขัดแย้งระหว่างความยินยอมตามกฎหมายกับการตั้งค่าความเป็นส่วนตัวของเบราว์เซอร์	เบราว์เซอร์จะไม่เห็นลักษณะความสัมพันธ์ระหว่างผู้ใช้กับเว็บไซต์ นอกจากนี้ ลักษณะการทํางานของ BTM ปัจจุบันยังมีวิธีแก้ปัญหาสําหรับผู้ใช้ในการให้ความยินยอมอย่างชัดแจ้งในการติดตามการตีกลับจากเว็บไซต์หนึ่งๆ ดูข้อมูลเพิ่มเติมเกี่ยวกับการปฏิบัติตามข้อกำหนดได้ในคำถามที่พบบ่อยเกี่ยวกับการปฏิบัติตามข้อกำหนดด้านความเป็นส่วนตัว
เว็บไซต์ที่มีการใช้งานแบบคู่	หากต้องการคำชี้แจงว่าการเปลี่ยนจาก WebView หรือแอปไปยังเว็บ (Chrome) จะถือว่าเป็น "เว็บไซต์ที่มีการใช้งานแบบคู่" ภายใต้ BTM หรือไม่	เบราว์เซอร์จะไม่ทราบได้ว่ามีการเริ่มเชนการตีกลับผ่านการเปลี่ยนไปใช้ WebView หรือแอป ดังนั้น BTM จึงไม่ให้การจัดการพิเศษกับ FLow เหล่านั้น แต่ระบบจะตีความขั้นตอนนี้เป็นการตีกลับข้ามเว็บไซต์ที่เริ่มต้นจาก "about:blank" และดำเนินการตามลักษณะการทํางานมาตรฐาน

เพิ่มความเข้มงวดให้กับขอบเขตความเป็นส่วนตัวข้ามเว็บไซต์

ชุดเว็บไซต์ที่เกี่ยวข้อง (เดิมคือชุดโดเมนของบุคคลที่หนึ่ง)

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การใช้ API	ข้อกังวลเกี่ยวกับโอกาสที่ RWS จะถูกละเมิดร่วมกับการปกป้องทรัพย์สินทางปัญญา การเปิดเผยที่อยู่ IP ให้กับองค์กรภายในชุด RWS อาจจูงใจให้องค์กรเข้าร่วมชุด RWS หลายชุดเพื่อให้เข้าถึงข้อมูลที่อยู่ IP แบบพกพาสำหรับการติดตามผู้ใช้ในโหมดไม่ระบุตัวตน	ข้อกำหนดที่กำหนดสำหรับเว็บไซต์ที่เกี่ยวข้อง เว็บไซต์บริการ และชุดโดยรวม ซึ่งบังคับใช้โดยการตรวจสอบอัตโนมัติ จะช่วยลดแรงจูงใจในการพยายามเข้าร่วมหลายชุด การรวมกิจกรรมของผู้ใช้ในชุดต่างๆ ผ่านที่อยู่ IP จะต้องรวมโดเมน MDL ไว้ในชุด ซึ่งต้องอาศัยการประสานงานระหว่างเจ้าของชุดกับเจ้าของโดเมน ความเสี่ยงเดียวกันนี้มีผลกับเว็บไซต์เดียว (กล่าวคือ ไม่มี RWS ที่เกี่ยวข้อง) ที่ประสานงานกับโดเมน MDL เราได้ตอบคำถามนี้อย่างละเอียดแล้วที่นี่

Fenced Frames API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
โฆษณาแบบเนทีฟ	ความคิดเห็นว่าเฟรมที่มีรั้วตามการออกแบบในปัจจุบันใช้ไม่ได้กับรูปแบบธุรกิจของโฆษณาเนทีฟ ซึ่งกำหนดให้โฆษณาต้องปรับให้เข้ากับเนื้อหาโดยรอบได้อย่างยืดหยุ่น	เรายังคงประเมินความต้องการด้านระบบนิเวศและข้อเสนอเฟรมที่มีรั้วล้อมในปัจจุบัน ไม่ว่าในกรณีใดก็ตาม ตามที่ระบุไว้ก่อนหน้านี้ คุณจะต้องใช้เฟรมที่มีการกำหนดเขตแดนไม่เร็วกว่าปี 2026

Shared Storage API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ข้อบกพร่องของ API	รายงานว่า Chrome บันทึกข้อผิดพลาดเมื่อกลไกการกำหนดงบประมาณของ Shared Storage API ป้องกันไม่ให้การดำเนินการ selectURL ทำงาน แม้ว่านี่จะเป็นลักษณะการทำงานที่คาดไว้ก็ตาม ขอให้ Chrome ดาวน์เกรดระดับการบันทึกจากข้อผิดพลาดเป็นคำเตือนหรือข้อมูล เนื่องจากผู้เรียกใช้ไม่สามารถดำเนินการกับข้อผิดพลาดได้	การเปลี่ยนแปลงนี้มีผลและรวมอยู่ใน Chrome M134 ซึ่งพร้อมให้ใช้งานตั้งแต่วันที่ 4 มีนาคม 2025

CHIPS

ธีมความคิดเห็น	สรุป	การตอบกลับของ Chrome
เอกสาร API	ต้องมีการชี้แจงเกี่ยวกับการป้องกันความปลอดภัยที่คุกกี้ที่มีการแบ่งพาร์ติชันมอบให้เมื่อเทียบกับคุกกี้ SameSite=Lax/Strict คำแนะนำว่าเอกสารประกอบควรระบุอย่างชัดเจนว่าคุกกี้ที่มีการแบ่งพาร์ติชันไม่ได้ให้การปกป้องในระดับเดียวกับคุกกี้ SameSite=Lax/Strict จากการโจมตี XSS และ CSRF	เราจะอัปเดตคำอธิบายและข้อกําหนดเฉพาะเพื่อชี้แจงความหมายและการป้องกันที่คุกกี้ที่มีการแบ่งพาร์ติชันมอบให้

FedCM

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
UI และความปลอดภัย	ความคิดเห็นที่ระบุว่า UI ของ FedCM คล้ายกับฟีเจอร์ลงชื่อเข้าใช้แบบแตะครั้งเดียวของ Google ก่อนหน้านี้มากเกินไป การประเมินประสิทธิภาพของ FedCM นั้นทำได้ยากเนื่องจากไม่มีเครื่องมือติดตามการแสดงผลแบบพาสซีฟ และคำแนะนำให้ใช้ภาษาในเอกสารประกอบที่ชัดเจนยิ่งขึ้นเกี่ยวกับ PKCE	เรามีส่วนร่วมกับผู้มีส่วนเกี่ยวข้องอย่างสม่ำเสมอเพื่อรับฟังความคิดเห็น ประเด็นที่เรากำลังหารือกันอยู่ ได้แก่ วิธีมอบเมตริกที่ดีขึ้นให้แก่ผู้ให้บริการข้อมูลประจำตัวเพื่อให้ติดตามประสิทธิภาพของ FedCM ได้ และการปรับปรุงที่เป็นไปได้เพื่อจัดการกับ Use Case ใหม่ๆ สำหรับ FedCM เกี่ยวกับ Use Case การสมัครใช้บริการ
การใช้ API	เมื่อผู้ใช้รีเฟรชหน้าเว็บและเรียก navigator.credentials.get เพื่อเข้าสู่ระบบ หน้าต่างป๊อปอัปจะปรากฏขึ้น โดยผู้ใช้ต้องคลิกเพื่อดำเนินการต่อ ซึ่งทำให้เกิดความล่าช้าที่ส่งผลต่อประสบการณ์ของผู้ใช้ บุคคลที่เชื่อถือ (RP) สามารถแคชโทเค็นที่ navigator.credentials.get แสดงผลเพื่อปรับปรุงประสบการณ์ของผู้ใช้ได้ไหม	RP สามารถใช้คุกกี้ของตนเองเพื่อจัดเก็บโทเค็นได้ จากนั้น RP จะตรวจสอบคุกกี้ของตนเองเพื่อดูว่าผู้ใช้เข้าสู่ระบบอยู่หรือไม่ก่อนที่จะเรียกใช้ navigator.credentials.get เราได้อธิบายเรื่องนี้อย่างละเอียดเพิ่มเติมที่นี่
การเลือกผู้ให้บริการระบุตัวตนหลายราย	เบราว์เซอร์จะแสดงตัวเลือกการเข้าสู่ระบบสำหรับผู้ให้บริการข้อมูลประจำตัว (IdP) หลายรายใน FedCM อย่างไร	เอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์มีข้อมูลเกี่ยวกับวิธีแสดงผู้ให้บริการระบุตัวตนหลายราย ผู้มีส่วนเกี่ยวข้องสามารถทดสอบฟังก์ชันนี้ได้โดยเปิดใช้ Flag fedcm-multi-idp ใน chrome://flags
เบราว์เซอร์และ IdP	เบราว์เซอร์ เช่น Chrome ทำหน้าที่เป็น IdP ได้ไหม เบราว์เซอร์อาจใช้ข้อมูลบัญชีและโปรไฟล์ที่จัดเก็บไว้เป็นแหล่งที่มาที่เชื่อถือได้ของการตรวจสอบสิทธิ์	เนื่องจากเบราว์เซอร์สามารถแก้ไขได้ (เช่น ผ่านส่วนขยาย) การอ้างสิทธิ์การยืนยันอีเมลที่เบราว์เซอร์ดำเนินการโดยตรงจึงไม่น่าเชื่อถือหากไม่มีการยืนยันเพิ่มเติมจากเซิร์ฟเวอร์ ดังนั้น เราจึงไม่แนะนําให้ใช้โซลูชันที่มุ่งเน้นที่ไคลเอ็นต์เพียงอย่างเดียว เราได้พูดคุยเกี่ยวกับปัญหานี้อย่างละเอียดแล้วที่นี่
ข้อกำหนดของ API	การพูดคุยกันว่าควรบังคับใช้หรือไม่บังคับใช้พารามิเตอร์สําหรับอัลกอริทึม IdentityCredential.disconnect()	ซึ่งตอนนี้ปัญหาได้รับการแก้ไขแล้ว อ่านรายละเอียดเพิ่มเติมได้ที่นี่
ความปลอดภัยของ API	ข้อกังวลเกี่ยวกับการรั่วไหลของโทเค็นในกระบวนการเข้าสู่ระบบ FedCM หาก RP มีช่องโหว่ XSS ผู้โจมตีอาจเรียกใช้ navigator.credentials.get ในโค้ดที่เป็นอันตรายเพื่อรับโทเค็น	FedCM ไม่ได้สร้างความเสี่ยง XSS ใหม่ ความเสี่ยงเหล่านี้มีอยู่ในเว็บแอปพลิเคชันและโปรโตคอลการตรวจสอบสิทธิ์ที่มีอยู่ เพื่อลดความเสี่ยงเหล่านี้ RP ควรยืนยันการอ้างสิทธิ์ aud ในโทเค็นระบุตัวตนและยอมรับเฉพาะการยืนยันที่ออกในต้นทางของตนเอง ดังที่ได้กล่าวไว้ที่นี่ มีแนวทางปฏิบัติแนะนำที่ยอมรับกันอย่างกว้างขวางเพื่อรักษาความปลอดภัยในการแลกเปลี่ยนโทเค็นนี้ในปัจจุบันและพร้อมให้ใช้งานกับ FedCM นอกจากนี้ Storage Access API ยังใช้ร่วมกับ FedCM ได้ และการเรียกใช้ Storage Access API จะได้รับการอนุญาตโดยอัตโนมัติเมื่อมีคำขอ FedCM ก่อนหน้านี้ ซึ่งควรเปิดใช้ขั้นตอนการเปลี่ยนเส้นทางแบบฝังที่กล่าวถึงในปัญหา GitHub
ข้อกำหนดของ API	client_metadata_endpoint เป็นช่องที่ต้องกรอกในการตอบกลับของปลายทางการกําหนดค่าสําหรับ FedCM ออบเจ็กต์ว่างเป็นคำตอบที่ถูกต้อง และ Chromium จะละเว้นการตอบกลับ 404 โดยอัตโนมัติ ซึ่งหมายความว่าระบบจะถือว่าปลายทางเป็นตัวเลือกในการใช้งานจริง	เราเห็นด้วยว่าข้อกำหนดอาจเปลี่ยนแปลงเพื่อให้สอดคล้องกับเรื่องนี้และทำให้ client_metadata_endpoint เป็นฟิลด์ที่ไม่บังคับ
การใช้ API	ข้อกังวลเกี่ยวกับความยากในการทดสอบการติดตั้งใช้งาน FedCM เนื่องจากอินเทอร์เฟซผู้ใช้ที่ควบคุมโดยเบราว์เซอร์ซึ่งเข้าถึงผ่าน DOM ไม่ได้	เรารองรับ API การทำงานอัตโนมัติของเบราว์เซอร์สำหรับการทดสอบแบบย้อนกลับ ซึ่งอาจช่วยคลายข้อกังวลเหล่านี้ได้ โปรดดูเอกสารประกอบเกี่ยวกับ API เหล่านี้ที่นี่
ข้อกำหนดของ API	พารามิเตอร์ login_url ซึ่งเป็นส่วนที่จำเป็นในการตอบกลับของปลายทางการกําหนดค่าไม่ได้ระบุไว้ในส่วนที่ 3.2 ของข้อกําหนด	เราได้ส่งการอัปเดตเอกสารประกอบเพื่อรวมพารามิเตอร์ login_url ไว้ในส่วนที่ 3.2 แล้ว
ข้อกำหนดของ API	ข้อกังวลเกี่ยวกับเวกเตอร์การติดตามที่อาจเกิดขึ้นใน FedCM IdP สามารถแทรกรหัสเป็นพารามิเตอร์เส้นทางลงในปลายทางที่ระบุในการตอบกลับของปลายทางการกําหนดค่า (accounts_endpoint, client_metadata_endpoint) และใช้รหัสเหล่านี้เพื่อเชื่อมโยงคําขอข้อมูลเมตาของบัญชีและลูกค้า	แม้ว่าจะไม่มีหลักฐานว่า IdP แทรกรหัสลงในปลายทางเหล่านี้ แต่เราก็กำลังพิจารณามาตรการบรรเทาปัญหานี้ที่นี่

ต่อสู้กับสแปมและการประพฤติมิชอบ

Private State Tokens API (และ API อื่นๆ)

ไม่ได้รับความคิดเห็นในไตรมาสนี้