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

รายงานรายไตรมาสสําหรับไตรมาสที่ 2 ปี 2023 เพื่อสรุปความคิดเห็นเกี่ยวกับระบบนิเวศที่ได้รับเกี่ยวกับข้อเสนอ Privacy Sandbox และการตอบสนองของ Chrome

ตามพันธสัญญาที่มีต่อ CMA ทาง Google ได้ตกลงที่จะจัดทำรายงานรายไตรมาสเกี่ยวกับกระบวนการมีส่วนร่วมของผู้มีส่วนเกี่ยวข้องสำหรับข้อเสนอ Privacy Sandbox (โปรดดูวรรคที่ 12 และ 17(c)(ii) ของ สัญญาผูกมัด) รายงานสรุปความคิดเห็นเกี่ยวกับ Privacy Sandbox เหล่านี้สร้างขึ้นโดยการรวบรวมความคิดเห็นที่ Chrome ได้รับจากแหล่งที่มาต่างๆ ตามที่ระบุไว้ในภาพรวมความคิดเห็น ซึ่งรวมถึงแต่ไม่จำกัดเพียงปัญหาเกี่ยวกับ GitHub, แบบฟอร์มความคิดเห็นที่มีให้ใน privacysandbox.com, การประชุมกับผู้มีส่วนเกี่ยวข้องในอุตสาหกรรม และฟอรัมมาตรฐานเว็บ Chrome ยินดีรับฟังความคิดเห็นที่ได้รับจากระบบนิเวศและกำลังดำเนินการสำรวจวิธีการต่างๆ ในการผสานรวมสิ่งที่เรียนรู้เข้ากับการตัดสินใจด้านการออกแบบ

ธีมความคิดเห็นจะจัดอันดับตามความแพร่หลายต่อ API ซึ่งทำได้โดยรวบรวมความคิดเห็นที่ทีม Chrome ได้รับจากธีมที่กำหนด และจัดระเบียบปริมาณจากมากไปหาน้อย ธีมความคิดเห็นที่พบบ่อยมาจากการตรวจสอบหัวข้อการพูดคุยจากการประชุมสาธารณะ (W3C, PatCG, IETF), ความคิดเห็นโดยตรง, GitHub และคำถามที่พบบ่อยซึ่งนำเสนอผ่านทีมภายในของ Google และแบบฟอร์มสาธารณะ

กล่าวอย่างเจาะจงก็คือ รายงานการประชุมของหน่วยงานมาตรฐานในเว็บได้รับการตรวจสอบ และสำหรับความคิดเห็นโดยตรง Google มีการพิจารณาบันทึกการประชุมของผู้มีส่วนเกี่ยวข้องแบบ 1:1, อีเมลที่วิศวกรแต่ละคนได้รับ, รายชื่ออีเมล API และแบบฟอร์ม แสดงความคิดเห็นสาธารณะ จากนั้น Google ได้ประสานงานระหว่างทีมที่เกี่ยวข้องกับกิจกรรมช่วยเหลือต่างๆ เหล่านี้เพื่อระบุความแพร่หลายของธีมที่เกิดขึ้นโดยเทียบกับ API แต่ละรายการ

คำอธิบายคำตอบของ Chrome ที่มีต่อความคิดเห็นของ Chrome นั้นพัฒนาขึ้นจากคำถามที่พบบ่อยที่มีการเผยแพร่ คำตอบที่เกิดขึ้นจริงต่อปัญหาที่ผู้มีส่วนเกี่ยวข้องเป็นผู้หยิบยกขึ้นมา และการกำหนดจุดยืนโดยเฉพาะเพื่อวัตถุประสงค์ในการจัดทำรายงานต่อสาธารณะนี้ ซึ่งได้รับความสนใจเป็นพิเศษจากหัวข้อ, Protected Audience และ Attribution Reporting API จะแสดงให้เห็นถึงความสำคัญในปัจจุบันของการพัฒนาและการทดสอบ

ความคิดเห็นที่ได้รับหลังจากสิ้นสุดระยะเวลาการรายงานปัจจุบันอาจยังไม่ได้รับคำตอบจาก Chrome

อภิธานศัพท์ของตัวย่อ

ชิป
คุกกี้ที่มีสถานะแบ่งพาร์ติชันอิสระ
DSP
แพลตฟอร์มฝั่งดีมานด์
FedCM
การจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์
FPS
ชุดบุคคลที่หนึ่ง
IAB
สมาคมโฆษณาอินเทอร์แอกทีฟ (Interactive Advertising Bureau)
IdP
ผู้ให้บริการข้อมูลประจำตัว
IETF
คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต
อินนิ่ง
ที่อยู่ Internet Protocol
openRTB
การเสนอราคาแบบเรียลไทม์
OT
ช่วงทดลองใช้จากต้นทาง
PatCG
กลุ่มชุมชนเทคโนโลยีการโฆษณาส่วนตัว
RP
ฝ่ายพึ่งพา
SSP
แพลตฟอร์มฝั่งซัพพลาย
TEE
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้
UA
สตริง User Agent
UA-CH
คำแนะนำไคลเอ็นต์ User Agent
W3C
World Wide Web Consortium
อยู่ระหว่างดำเนินการ
การตาบอด IP แบบจงใจ

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การกำกับดูแลข้อมูลและการปฏิบัติตามกฎระเบียบ คำแนะนำด้านระบบนิเวศในการใช้ Privacy Sandbox ตามข้อกำหนดด้านกฎระเบียบ เช่นเดียวกับเทคโนโลยีใหม่อื่นๆ แต่ละบริษัทมีหน้าที่ตรวจสอบว่าการใช้ Privacy Sandbox เป็นไปตามกฎหมาย Google ไม่สามารถให้คำแนะนำทางกฎหมายแก่ผู้อื่นได้ อย่างไรก็ตาม เราทราบดีว่านี่เป็นเรื่องที่น่าสนใจสำหรับระบบนิเวศนี้ สำหรับ API แต่ละรายการ เราได้เผยแพร่เอกสารทางเทคนิคที่ครบถ้วนสมบูรณ์ ซึ่งน่าจะเป็นพื้นฐานสำหรับการประเมินทางกฎหมายที่จำเป็น และเรากำลังพยายามทำให้มีเอกสารเพิ่มเติม เพื่อสนับสนุนความพยายามของบริษัทในการปฏิบัติตามข้อกำหนดที่เป็นระเบียบข้อบังคับ
ข้อเสนอการทดสอบเชิงปริมาณของ CMA ข้อมูลเพิ่มเติมเกี่ยวกับข้อเสนอการทดสอบเชิงปริมาณของ CMA เรากำลังทำงานร่วมกับ CMA เพื่อออกแบบการทดสอบที่จะแสดงให้เห็นภาพของผลกระทบจากการเลิกใช้งานคุกกี้ของบุคคลที่สามและการเปิดตัวข้อเสนอ Privacy Sandbox ในระบบนิเวศ ในเดือนเมษายน CMA ได้เผยแพร่คำแนะนำระดับสูงเกี่ยวกับสิ่งที่จะเกิดขึ้นในระยะเวลาการทดสอบและทดลอง ตามด้วยคำแนะนำโดยละเอียดในเดือนมิถุนายน เราขอแนะนำให้แชร์คำถามหรือความคิดเห็นเกี่ยวกับข้อเสนอการทดสอบเชิงปริมาณของ CMA กับ CMA โดยตรง
โหมดการทดสอบที่อำนวยความสะดวกโดย Chrome ข้อมูลเพิ่มเติมและการชี้แจงเกี่ยวกับกำหนดการทดสอบ เราได้เผยแพร่บล็อกโพสต์เมื่อวันที่ 18 พฤษภาคมเพื่อแชร์ข้อมูลเพิ่มเติมเกี่ยวกับการทดสอบ 2 โหมดที่อำนวยความสะดวกโดย Chrome รายละเอียดเหล่านี้ยังไม่เป็นที่สิ้นสุด และเราจะเผยแพร่คําแนะนําเพิ่มเติมในการติดตั้งใช้งานในไตรมาสที่ 3 ปี 2023
พื้นที่เก็บข้อมูลที่แบ่งพาร์ติชันแล้ว จะมีการใช้พื้นที่เก็บข้อมูลที่แบ่งพาร์ติชันระหว่างการทดสอบที่อำนวยความสะดวกโดย Chrome ไหม ระบบจะส่งการแบ่งพาร์ติชันพื้นที่เก็บข้อมูลไปยังผู้ใช้ทั้งหมดก่อนการทดสอบการเลิกใช้งานคุกกี้ของบุคคลที่สาม การทดสอบจึงจะเปิดใช้ได้ เว็บไซต์จะมีตัวเลือกในการเปิดใช้ช่วงทดลองใช้การเลิกใช้งานเพื่อรับพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชันในระยะเวลานี้
การสนับสนุนด้านการผลิต Chrome มีกระบวนการใดบ้างในการสนับสนุนปัญหาทางเทคนิคและการส่งต่อปัญหาของ Privacy Sandbox ที่ส่งผลต่อระบบนิเวศ Google มีช่องทางต่างๆ มากมายที่ช่วยให้เทคโนโลยีโฆษณาสามารถรายงานปัญหาและส่งต่อเรื่องที่จำเป็นได้
โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับฟอรัมสาธารณะและส่วนตัวสำหรับความคิดเห็นและการส่งต่อเรื่องได้จากโพสต์สำหรับนักพัฒนาซอฟต์แวร์
ลำดับเวลาการลงทะเบียน กรอบเวลาการลงทะเบียนปัจจุบันสั้นเกินไป เรายังคงประเมินกำหนดเวลาการบังคับใช้อยู่และต้องการทราบความคิดเห็นจากระบบนิเวศว่าจะใช้ลำดับเวลาใดที่เหมาะสมกว่ากัน
หมายเลข D-U-N-S ข้อมูลเพิ่มเติมเกี่ยวกับข้อกำหนดหมายเลข D-U-N-S สำหรับการลงทะเบียนและเอกสารรับรอง ผู้เข้าร่วมดูข้อกำหนดในการขอรับหมายเลข D-U-N-S ได้ในเว็บไซต์ Dun and Bradstreet ความต้องการจะแตกต่างกันไปตามตลาด ดังนั้นผู้เข้าร่วมควรแน่ใจว่าได้ตรวจสอบเว็บไซต์สำหรับตลาดที่พวกเขาสนใจ อย่างไรก็ตาม โดยทั่วไปผู้เข้าร่วมจะต้องให้ข้อมูลพื้นฐานเกี่ยวกับธุรกิจของตน เช่น ชื่อธุรกิจ ที่อยู่ และข้อมูลติดต่อสำหรับเจ้าของธุรกิจหรือผู้จัดการ นอกจากนี้ระบบยังอาจขอให้ผู้เข้าร่วมระบุข้อมูลทางการเงิน เช่น รายได้ต่อปีของธุรกิจ เมื่อการสมัครเสร็จสมบูรณ์ D&B จะตรวจสอบและออกหมายเลข D-U-N-S หากใบสมัครได้รับการอนุมัติ
การเปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไป การเปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไปจะส่งผลต่อผู้ทดสอบเวอร์ชันทดลองจากต้นทางในปัจจุบันไหม ตั้งแต่เดือนกรกฎาคม ผู้ทดสอบจะเข้าถึง API ความเกี่ยวข้องและ Measurement API ในเวอร์ชันสำหรับผู้ใช้ทั่วไปได้ ซึ่งจะทับซ้อนระหว่างความพร้อมให้บริการของช่วงทดลองใช้จากต้นทางกับเวอร์ชันสำหรับผู้ใช้ทั่วไป
การศึกษาของ AdExchanger ข้อมูลเพิ่มเติมเกี่ยวกับวิธีการสำรวจ แบบสำรวจนี้ขอให้ผู้ตอบประเมินอัตราการซิงค์และรายได้สำหรับธุรกิจของตน ผู้ตอบจะเป็นผู้เลือกใช้วิธีการตอบคำถามแต่ละข้อ
ค่าพารามิเตอร์ ค่าพารามิเตอร์ เช่น ระดับสัญญาณรบกวน เกณฑ์การไม่ระบุตัวตน และงบประมาณด้านความเป็นส่วนตัว ได้รับการกำหนดอย่างไร คำอธิบายเกี่ยวกับ GitHub นี้จะอธิบายหลักการทั่วไปที่อยู่เบื้องหลัง Privacy Sandbox API มีหลายค่าที่ยังอยู่ระหว่างการสรุปและเรายินดีรับฟังความคิดเห็นเกี่ยวกับเรื่องนี้

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

หัวข้อ

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การรักษาความเป็นส่วนตัว งานวิจัยที่ประเมิน Topics API เกี่ยวกับการสงวนความเป็นส่วนตัว เรามีส่วนร่วมกับชุมชนการวิจัยอย่างเต็มที่ โดยนำเสนอการวิจัยเกี่ยวกับคุณสมบัติความเป็นส่วนตัวของ Topics API ในเอกสาร รายงาน และงานนำเสนอสำหรับเวิร์กช็อป เราดีใจที่ได้เห็นสมาชิกภายนอกของชุมชนการวิจัยมีส่วนร่วมกับส่วนนี้มากขึ้น

Topics API ช่วยปกป้องผู้ใช้จากการติดตามทั่วไปในเว็บด้วยการทําให้ติดตามผู้ใช้ในวงกว้างได้ยากเกินไป รายงานเหล่านี้แสดงให้เห็นว่าเราประสบความสำเร็จกับ Topics API ได้อย่างไร มีความเป็นส่วนตัวมากกว่าคุกกี้ของบุคคลที่สามและปกป้องผู้ใช้ไปพร้อมๆ กับสนับสนุนเว็บไซต์ที่พวกเขาชอบเข้าชม
การจัดหมวดหมู่หัวข้อมีรายละเอียดไม่เพียงพอ การจัดหมวดหมู่หัวข้อแบบกว้างจะไม่รวมหัวข้อที่ละเอียดยิ่งขึ้น ซึ่งรวมถึงหัวข้อเฉพาะ เราได้เผยแพร่บล็อกโพสต์เมื่อวันที่ 15 มิถุนายน เพื่อตอบสนองต่อความคิดเห็นที่ได้รับในครั้งก่อนหน้าจากระบบนิเวศนี้ ซึ่งให้รายละเอียดเกี่ยวกับการจัดหมวดหมู่ใหม่ที่อัปเดต ซึ่งมีการปรับปรุงมากมายตามความคิดเห็นจากระบบนิเวศ ในส่วนหนึ่งของการดำเนินงานเกี่ยวกับการจัดหมวดหมู่ฉบับแก้ไขนี้ เราได้ร่วมงานกับบริษัทหลายแห่งในระบบนิเวศ เช่น Raptive (เดิมคือ CafeMedia) และ Criteo การจัดหมวดหมู่ที่อัปเดตนี้จะลบหมวดหมู่ที่เราได้ยินมานั้นไม่ค่อยมีประโยชน์ โดยการเปลี่ยนไปใช้หมวดหมู่ที่ตรงกับความสนใจของผู้ลงโฆษณามากกว่า ขณะเดียวกันก็ยังคงความมุ่งมั่นของเราในการยกเว้นหัวข้อที่อาจมีความละเอียดอ่อน

เราขอแนะนำให้ระบบนิเวศตรวจสอบการจัดหมวดหมู่ล่าสุดและแสดงความคิดเห็นเกี่ยวกับการเปลี่ยนแปลงดังกล่าว
กระบวนการอัปเดตการจัดหมวดหมู่และตัวแยกประเภท ข้อมูลเพิ่มเติมเกี่ยวกับการจัดหมวดหมู่ Topics และตารางการเผยแพร่ตัวแยกประเภท และวิธีการเตรียมความพร้อมสำหรับบริษัทต่างๆ สำหรับการอัปเดตดังกล่าว ตามที่ได้แจ้งไว้ในบล็อกโพสต์ล่าสุด เราคาดว่าการจัดหมวดหมู่มีการเปลี่ยนแปลงเมื่อเวลาผ่านไป และเพื่อการกำกับดูแลของการจัดหมวดหมู่จะมีการเปลี่ยนเป็นภายนอกที่เป็นตัวแทนของผู้มีส่วนเกี่ยวข้องจากทั่วทั้งอุตสาหกรรมในที่สุด และเรายังได้แชร์แผนการเพิ่มจำนวนในกลุ่มประกาศเรื่องด้วย
ผลกระทบต่อสัญญาณของบุคคลที่หนึ่ง จํานวน Topics ที่เพิ่มขึ้นในการอัปเดตการจัดหมวดหมู่ล่าสุดอาจมีมูลค่าสูง และทำให้สัญญาณตามความสนใจของบุคคลที่หนึ่งอื่นๆ ลดลง ในรายงานไตรมาสที่ 1 ปี 2023 CMA แสดงความคิดเห็นว่า "เราทราบว่า Google ได้หารือเกี่ยวกับการจัดหมวดหมู่ใหม่ที่นำเสนอกับผู้เข้าร่วมตลาดหลายรายในซัพพลายเชนของเทคโนโลยีโฆษณา ในขณะที่ผู้เผยแพร่โฆษณารายใหญ่บางรายกล่าวว่าประโยชน์เพิ่มเติมจากหัวข้อจะช่วยเพิ่มแรงกดดันในการแข่งขันให้กับโซลูชันที่อิงตามข้อมูลจากบุคคลที่หนึ่ง แต่มุมมองเบื้องต้นของเราคือประโยชน์ที่มากขึ้นจะดีกว่าสำหรับการแข่งขันโดยรวม โดยเฉพาะความสามารถของผู้เผยแพร่โฆษณาขนาดเล็กในการสร้างรายได้ต่อพื้นที่โฆษณาของตนต่อไปหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม" เราเห็นด้วยกับความคิดเห็นนี้ของ CMA
ความมีประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ เทคโนโลยีโฆษณาที่ทำหน้าที่เป็น SSP และ DSP อาจมีข้อได้เปรียบที่สำคัญเหนือกว่าผู้เล่นในระบบนิเวศอื่นๆ การตอบสนองของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่แล้ว

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

การอนุญาตให้ผู้เผยแพร่โฆษณาควบคุมการจัดประเภทของตนมีความเสี่ยง เว็บไซต์อาจจัดประเภทเว็บไซต์ของตนผิดประเภทโดยเจตนา ลดประโยชน์ในการใช้งานสำหรับทุกคน หรือเข้ารหัสความหมายที่ละเอียดอ่อนในหัวข้อที่พบไม่บ่อยนัก ซึ่งเป็นอันตรายต่อความเป็นส่วนตัวของผู้ใช้
ส่วนขยาย Chrome อนุญาตให้ส่วนขยาย Chrome จัดการและกรองหัวข้อ ซึ่งคล้ายกับส่วนขยายการจัดการคุกกี้ปัจจุบัน ซึ่งน่าจะเป็นไปได้อยู่แล้วตามที่ได้กล่าวไปใน GitHub แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การเปลี่ยนไปใช้รุ่นสำหรับผู้ใช้ทั่วไป จะมีผลกระทบต่อ Topics API ไหมเมื่อเปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไป ข้อมูลของผู้ที่เปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไปจะไม่สูญหาย
ความเป็นส่วนตัว ชื่อโฮสต์อาจมีข้อมูลส่วนตัวที่อาจเปิดเผยโดย Topics API เรามีการบรรเทาปัญหาหลายอย่างเพื่อรักษาความเป็นส่วนตัวตามที่อธิบายไว้ที่นี่
การประพฤติมิชอบและการละเมิด วิธีป้องกันการบิดเบือน Topics โดยการเข้าชมที่เป็นการฉ้อโกง ดูคำอธิบายเกี่ยวกับการลดปัญหาได้ที่นี่
ตัวแยกประเภทหัวข้อ เว็บไซต์จะขอเปลี่ยนการจัดประเภทหัวข้อได้ไหม เราอยากรับฟังความคิดเห็นเกี่ยวกับหัวข้อนี้จากระบบนิเวศและความคิดเห็นต้อนรับที่นี่
เว็บไซต์ของผู้ให้บริการ Topics กำหนดเว็บไซต์บางแห่งที่โฮสต์เนื้อหาสำหรับ Topics จำนวนมากเป็น "เว็บไซต์ของผู้ให้บริการหัวข้อพิเศษ" และฝึกตัวแยกประเภทตามแท็กที่ให้ไว้ในหน้าเว็บ เรากำลังพูดคุยเรื่องข้อเสนอที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม

Protected Audience API (ก่อนหน้านี้เรียกว่า FLEDGE)

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การกำหนดรูปแบบการเข้าชม ผลด้านประสิทธิภาพของการกรองที่ทำงานด้วย SSP เพื่อเพิ่มประสิทธิภาพการโหลดการค้นหาต่อวินาที (QPS) เราใช้เวลานานมากในการคิดรูปแบบการเข้าชม และข้อเสนอแนะคือให้ SSP ใช้ประโยชน์จากการแคช
กำลังทดสอบระดับเสียง การทดสอบ Protected Audience เป็นอุปสรรค เนื่องจาก SSP และ DSP พบปัญหาในการรับการเข้าชมปริมาณมาก เราร่วมมือกับพาร์ทเนอร์ SSP และ DSP อย่างต่อเนื่องเพื่อใช้และทดสอบ Protected Audience เวอร์ชันสำหรับผู้ใช้ทั่วไปได้เริ่มขึ้นแล้วและเรามั่นใจว่าเปอร์เซ็นต์การเข้าชมที่มีการเปิดใช้ PA จะทำให้พาร์ทเนอร์ทดสอบได้อย่างสบายใจมากขึ้น
ความซับซ้อน การนำโซลูชัน Protected Audience ไปใช้นั้นต้องใช้ความพยายามและต้นทุนสูง เราตระหนักดีว่าเทคโนโลยีใหม่ๆ นั้นนำมาใช้ได้ยาก ซึ่งรวมถึง Privacy Sandbox ทีม Privacy Sandbox ทํางานอย่างใกล้ชิดกับผู้มีส่วนเกี่ยวข้องต่างๆ มากมายเพื่อให้ความรู้และสนับสนุนความพยายามของตน อีกทั้งมีการประเมินตัวเร่งอื่นๆ อย่างต่อเนื่องเพื่อสนับสนุนการใช้งานในระบบนิเวศ
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ การสนับสนุนสำหรับ Trusted Execution Environments (TEE) ในสภาพแวดล้อมระบบคลาวด์ที่ไม่ใช่สาธารณะ แม้ว่าเรากำลังสำรวจตัวเลือกที่อาจสนับสนุนนอกเหนือจากโซลูชันระบบคลาวด์ แต่ขณะนี้ก็ยังไม่สามารถรองรับ TEE ภายในองค์กรได้ เนื่องจากมีข้อจำกัดด้านความปลอดภัยภายในองค์กร ซึ่งยังต้องประเมินเวลา Privacy Sandbox อยู่นาน เมื่อพิจารณาจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และความท้าทายสำคัญที่ได้รับจากการติดตั้งใช้งานภายในองค์กร เราเชื่อว่าการขยายและปรับปรุงการติดตั้งใช้งานในระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ GCP เพิ่มเติมจาก AWS) คือประโยชน์มากที่สุดสำหรับระบบนิเวศนี้ อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่จำเป็นต้องมีข้อกำหนดดังกล่าว
โครงสร้างค่าใช้จ่าย ข้อเสนอการเสนอราคาและบริการประมูลจะเพิ่มค่าใช้จ่ายและความซับซ้อนของเทคโนโลยีโฆษณาเมื่อเทียบกับรูปแบบฝั่งไคลเอ็นต์ ขณะนี้เรากำลังพัฒนาคู่มือในการประมาณต้นทุนในการรองรับการเสนอราคาและเวิร์กโฟลว์การประมูลในเซิร์ฟเวอร์การเสนอราคาและการประมูล ซึ่งจะสัมพันธ์กับการใช้เทคโนโลยีโฆษณาเพื่อบรรลุเป้าหมายการออกแบบของเรา
ไทม์ไลน์ของ K-Anon ข้อจำกัด k-anonymity ที่วางแผนไว้จะบังคับใช้ใน "renderUrl" เมื่อใด เรากำลังดำเนินการอธิบายลำดับเวลาการบังคับใช้ที่จะเปิดตัวเร็วๆ นี้
ข้อจำกัดในการเรียกใช้ AdAuction Chrome จำกัดให้เรียกใช้ runAdAuction จากหน้าด้านบนเท่านั้นได้ไหม แม้ว่าการออกแบบของเรารองรับ runAdAuction ให้เรียกจากหน้าแรกได้อย่างเต็มรูปแบบ แต่เราเชื่อว่าการทำให้ผู้เผยแพร่โฆษณาสามารถเรียกใช้ฟังก์ชันนั้นต้องโทรจากโดเมนระดับบนสุดเท่านั้นที่จะเป็นอันตรายมากกว่า

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

เราเชื่อว่าการอนุญาตให้ผู้เผยแพร่โฆษณาเลือกวิธีและบุคคลที่เรียกใช้ runAdAuction ในเว็บไซต์ของตนทำให้เรามีความยืดหยุ่นแก่ผู้เผยแพร่โฆษณาในการค้นหาเส้นทางที่ดีที่สุดตามความต้องการของตน
การสนับสนุนการใช้งาน Chrome สามารถสร้างหรือสนับสนุนการใช้งานโอเพนซอร์สของการประมูลผู้ขายหลายรายได้หรือไม่ Privacy Sandbox มีเป้าหมายที่จะพัฒนาเทคโนโลยีการรักษาความเป็นส่วนตัวที่ไม่ใช้คุกกี้ของบุคคลที่สามหรือตัวระบุข้ามเว็บไซต์อื่นๆ เราต้องการส่งเสริมระบบนิเวศที่ดีโดยไม่ต้องอธิบายถึงการทำงานของเทคโนโลยีโฆษณา

เราได้เผยแพร่คำแนะนำเกี่ยวกับวิธีการทำงานของ API ในที่เก็บ GitHub ของเรา และเปิดกว้างที่จะสำรวจโซลูชันร่วมกับอุตสาหกรรม

เราไม่มีแผนที่จะพัฒนารูปแบบที่เฉพาะเจาะจงใดๆ เนื่องจากข้อเสนอหลักของเราคือการสร้างเทคโนโลยีแพลตฟอร์ม ไม่ใช่การกำหนดกลยุทธ์สำหรับการใช้เทคโนโลยีเหล่านั้น เทคโนโลยีของเราจะช่วยให้บริษัทเทคโนโลยีโฆษณาให้บริการลูกค้าได้ดีที่สุดด้วยขอบเขตความเป็นส่วนตัวที่เหมาะกับผู้บริโภค
การประมูลกับผู้ขายหลายราย Chrome จะบังคับให้แชร์ผู้ชนะ "ตามบริบท" กับการประมูลคอมโพเนนต์หรือไม่ Protected Audience API ได้รับการออกแบบมาเพื่อมอบความสามารถให้กับบุคคลที่เริ่มการประมูลผู้ขายหลายราย ในการส่งผ่านข้อมูลไปยังการประมูลคอมโพเนนต์ (หมายเหตุ: ก่อนเริ่มการประมูลเท่านั้น)

อย่างไรก็ตาม เราไม่เห็นช่องทางให้เบราว์เซอร์แยกแยะได้ว่าข้อมูลชิ้นหนึ่งๆ จะถูกต้องตามบริบทหรือไม่ เราจึงบังคับใช้การบล็อกหรือกำหนดให้ข้อมูลบางอย่างไม่ได้
ค่ากําหนดของผู้ใช้สําหรับการติดตามความยินยอม Adtech ขอให้ PA ติดตั้งใช้งานการติดตามความยินยอมของผู้ใช้อย่างถูกต้อง ผลตอบรับของเรารวมถึงสิ่งที่เราพูดในไตรมาสที่ 1 ด้วย:
"เทคโนโลยีโฆษณาที่เกี่ยวข้องคือฝ่ายที่เหมาะสมที่สุดสำหรับการควบคุมว่าจะให้ครีเอทีฟโฆษณาใดแสดงหรือวิธีเลือกครีเอทีฟโฆษณาใด"

เราได้พูดคุยเกี่ยวกับสถานการณ์ที่เกี่ยวข้องกับปัญหานี้ระหว่างการประชุม Protected Audience สำหรับ WICG ประจำเดือนพฤษภาคม และเรายินดีรับฟังความคิดเห็นและการพูดคุยเพิ่มเติมเกี่ยวกับปัญหานี้
กลุ่มเป้าหมายที่กำหนดเอง Protected Audience API จะรองรับ Use Case ของ SSP ที่เกี่ยวข้องกับการสร้างกลุ่มเป้าหมายที่กำหนดเองไหม Protected Audience API ช่วยให้ SSP และผู้ให้บริการเทคโนโลยีโฆษณาอื่นๆ เป็นเจ้าของและจัดการกลุ่มเป้าหมายที่กำหนดเองได้ เรากำลังพัฒนาคำแนะนำเพิ่มเติมเกี่ยวกับวิธีที่ SSP ผสานรวมกับ PA API และจะเปิดให้ SSP และผู้ให้บริการเทคโนโลยีโฆษณาอื่นๆ สนับสนุนความพยายามในการผสานรวม
รูปแบบ Protected Audience API รองรับวิดีโอไหม โฆษณาวิดีโอจะแสดงด้วยวิธีใดวิธีหนึ่งจาก 2 วิธี ได้แก่ VAST XML หรือ HTML (โฆษณานอกสตรีมที่อาจโหลด VAST XML ลงในโปรแกรมเล่นวิดีโอด้วย) ผู้ซื้อสามารถส่งกลับรูปแบบใดรูปแบบหนึ่งได้ผ่านทาง RenderURL ข้อกำหนดของ VAST เพิ่งได้รับการอัปเดตเมื่อเร็วๆ นี้เพื่อรองรับ Attribution Reporting API เว็บไซต์ที่แสดงโฆษณาวิดีโอจะต้องเตรียมพร้อมสำหรับวิธีการแสดงโฆษณาผ่าน Protected Audience API ซึ่งหมายความว่าแท็กตำแหน่งโฆษณาสามารถส่ง URL จาก iframe ของ Protected Audience ไปยังโปรแกรมเล่นวิดีโอได้ สำหรับ Fenced Frame เราจะพยายามแก้ไขปัญหาเกี่ยวกับวิดีโอก่อนข้อกำหนดให้ใช้ Fenced Frame ซึ่งก่อนปี 2026
ความเร็วในการบรรลุเป้าหมาย กรณีการใช้งานการกำหนดอัตราการแสดงโฆษณาทำงานร่วมกับ Protected Audience API อย่างไร ขอขอบคุณสำหรับความคิดเห็น เราต้องการเห็นอินสแตนซ์อื่นๆ ของคำขอนี้ ซึ่งมีรายละเอียดเพิ่มเติมมาจากพาร์ทเนอร์ SSP จำนวนมากขึ้น เนื่องจากที่ผ่านมาตอนนี้เป็นข้อกังวลเกี่ยวกับ DSP เป็นส่วนใหญ่
ความถี่ในการอัปเดต ความถี่ของการโทรจาก dailyUpdate (สูงสุด 1 สายต่อกลุ่มความสนใจต่อวัน) อาจไม่เพียงพอสำหรับการใช้งานบางกรณี เช่น การอัปเดตข้อมูลผลิตภัณฑ์ ขอขอบคุณสำหรับความคิดเห็น ยังมีโซลูชันอื่นๆ ที่พร้อมให้เทคโนโลยีโฆษณาใช้สัญญาณที่มีการรีเฟรชตามความถี่ต่างๆ กัน เช่น การค้นหา K/V
การควบคุมคุณภาพของโฆษณา ผู้เผยแพร่โฆษณาใช้การควบคุมคุณภาพโฆษณาอย่างไร ปัจจุบัน Protected Audience API มีฟังก์ชันให้ผู้เผยแพร่โฆษณาแจ้ง SSP เกี่ยวกับการควบคุมบางอย่างที่สามารถกำหนดเป็นส่วนหนึ่งของการกำหนดค่าการประมูล การเสนอราคาล่วงหน้า (เช่น รายการที่ปฏิเสธตามป้ายกำกับที่เชื่อมโยงกับโฆษณา) เรายินดีรับฟังความคิดเห็นเกี่ยวกับฟังก์ชันอื่นๆ ที่ระบบนิเวศอาจต้องการ
การแก้ไขข้อบกพร่อง ฟังก์ชันการทำงานของ forDebuggingOnly จะถูกนำออกเมื่อใด เราวางแผนที่จะเลิกใช้ forDebuggingOnly สำหรับเหตุการณ์ความสูญเสียเนื่องจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม เราวางแผนที่จะเลิกใช้ forDebuggingOnly สำหรับกิจกรรมที่จะชนะในปี 2026 อย่างเร็วที่สุด
กลุ่มความสนใจข้ามอุปกรณ์ ข้อเสนอเพื่อเปิดใช้กลุ่มความสนใจข้ามอุปกรณ์สำหรับ User Agent ที่ตรวจสอบสิทธิ์แล้ว เรากำลังประเมินข้อเสนอนี้ แต่การกำหนดเป้าหมายจากหลายอุปกรณ์ที่มีความเฉพาะเจาะจงสูงก่อให้เกิดข้อกังวลเกี่ยวกับความเป็นส่วนตัวอย่างมาก ดังที่กล่าวไว้ในปัญหาของ GitHub นี้
(มีการรายงานในไตรมาส 1 ด้วย) รีมาร์เก็ตติ้งแบบไดนามิก รีมาร์เก็ตติ้งแบบไดนามิกจะยังทําได้ด้วย Protected Audience API หลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามหรือไม่ เราเชื่อว่ากรณีการใช้งานนี้เป็นไปได้เมื่อใช้ Protected Audience ตามที่อธิบายไว้ที่นี่
ข้อมูลที่เกี่ยวข้องกับคลิก เพิ่มข้อมูลที่เกี่ยวข้องกับคลิกลงใน browserSignals. ขณะนี้ เรากำลังขอให้มีการชี้แจงว่าการคลิกเกิดขึ้นเมื่อใดเพื่อให้ตำแหน่งเบื้องต้น
(มีการรายงานในไตรมาสที่ 4 ปี 2022 ด้วย) ฟังก์ชันที่กำหนดโดยผู้ใช้ใน Protected Audience Protected Audience API จะรองรับฟังก์ชันที่กำหนดโดยผู้ใช้ (UDF) อย่างไร ต่อไปนี้เป็นฟังก์ชันที่ผู้ใช้ปลายทางตั้งโปรแกรมได้เพื่อขยายฟังก์ชันการทำงานของ API เทคโนโลยีโฆษณาที่แจ้งปัญหานี้ก็กล่าวด้วยว่ากำลังประเมินสิ่งที่สามารถทำได้กับ UDF จึงยังไม่มีความคิดเห็นที่นำไปใช้ได้จริงที่จะตอบสนองต่อปัญหานี้ รวมถึงไม่ได้รอให้พร้อมใช้งานสำหรับเวอร์ชันสำหรับผู้ใช้ทั่วไปเป็นอย่างน้อย
สกุลเงิน จำนวนเงินสกุลเงินไม่ควรแสดงด้วยจุดทศนิยม เราได้แก้ไขปัญหานี้โดยละเอียดที่นี่
ความสามารถในการเลือกโฆษณาที่ไม่ใช่ DSP เซิร์ฟเวอร์โฆษณามีบทบาทอย่างไรในการประมูล Protect Audience API เราทราบว่ามีคำขอให้เซิร์ฟเวอร์โฆษณาให้บริการการเลือกโฆษณาหลังการเสนอราคา / การเพิ่มประสิทธิภาพโฆษณาแบบไดนามิกต่อไป ขณะนี้เรากำลังประเมินการวิเคราะห์ช่องโหว่โดยละเอียดที่มีอยู่ระหว่าง Protected Audience API ปัจจุบันกับคำขอเหล่านี้
GenerateBid การรองรับข้อเสนอของ Google Ads ให้แสดงโฆษณาตัวเลือกมากกว่า 1 รายการต่อกลุ่มความสนใจของโฆษณาจาก generateBid และผู้สมัครเหล่านั้นได้คะแนนใน "scoreAd" เรากําลังประเมินคำถามอยู่ เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่
คำสั่งซื้อของการประมูล การประมูล Protected Audience API จำเป็นต้องเป็นการประมูลครั้งสุดท้ายหรือไม่ เพื่อให้สามารถรับข้อมูลจากผลของการประมูลอื่นๆ ทั้งหมด ไม่มีข้อกำหนดทางเทคนิคที่จะทำให้ Protected Audience API ทำงานเป็นครั้งล่าสุด
การนำทางที่ไม่ได้เริ่มต้นโดยผู้ใช้ แสดงการไปยังส่วนต่างๆ ที่ไม่ได้เริ่มต้นโดยผู้ใช้ เรากำลังตรวจสอบคำขอนี้และสนทนาเกี่ยวกับคำขอดังกล่าวที่นี่ รวมทั้งยินดีรับฟังความคิดเห็นเพิ่มเติม
การแคช SSP ไม่ควรสร้าง PerBuyerSignals ของ DSP ที่ระบุจากแคชหากสถานะผู้ใช้มีการเปลี่ยนแปลง เราเข้าใจดีว่าการแคชใช้ไม่ได้กับ Use Case ทุกกรณีสำหรับสัญญาณต่อผู้ซื้อ และเรากำลังประเมินตัวเลือกอื่นๆ อยู่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าการแคชจะใช้ได้ผลกับกรณีการใช้งานของตนหรือไม่
การรายงานการระบุแหล่งที่มาและกลุ่มเป้าหมายที่มีการป้องกัน Attribution Reporting API และ Protected Audience Audience API จะทำงานร่วมกันอย่างไร ปัจจุบันการผสานรวมใช้ได้กับ Protected Audience API ทั้งสำหรับโหมด Attribution Reporting API (ระดับเหตุการณ์และรายงานสรุป) เราได้แชร์ข้อมูลเพิ่มเติมเกี่ยวกับการผสานรวม Protected Audience API และ Attribution Reporting ที่ปรับปรุงใหม่เมื่อวันที่ 1 มิถุนายน อ่านได้ที่นี่
ปลายทางเซิร์ฟเวอร์ ปลายทางเซิร์ฟเวอร์จะเป็นเซิร์ฟเวอร์รวมที่เชื่อถือได้ในการออกแบบขั้นสุดท้ายหรือไม่ ปลายทางเซิร์ฟเวอร์คือปลายทางที่ดูแลรักษาเทคโนโลยีโฆษณาซึ่งเป็นอิสระจากเซิร์ฟเวอร์รวบรวมข้อมูลที่เชื่อถือได้ซึ่งใช้ในการประมวลผลรายงานที่รวบรวมและเปลี่ยนรูปแบบ เรายังไม่มีการเปลี่ยนแปลงใดๆ ที่วางแผนไว้สำหรับปลายทางการรายงานในขณะนี้ การออกแบบปัจจุบันมีเป้าหมายเพื่อให้มั่นใจว่าตัวรายงานที่รวบรวมได้นั้น (โดยมีเพย์โหลดที่เข้ารหัส) ไม่ทำให้ข้อมูลข้ามเว็บไซต์รั่วไหล ดังนั้นจึงไม่จำเป็นต้องมีปลายทางที่เชื่อถือได้ ข้อมูลเสริมคือเทคโนโลยีโฆษณาที่แตกต่างกันมีแนวโน้มที่จะมีกลยุทธ์แบบกลุ่มที่ต้องการแตกต่างกัน เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่
WebIDL ข้อมูลจำเพาะของ Protected Audience API ปัจจุบันใช้กับข้อกำหนด WebIDL ไม่ได้ เรากำลังประเมินความคิดเห็นนี้และหารือเกี่ยวกับปัญหาที่นี่
การจัดการความยินยอม การส่งสัญญาณความยินยอมใน Protected Audience API จะได้รับการจัดการอย่างไร ข้อมูลตามบริบทไม่ได้อยู่ในขอบเขตของ Protected Audience API เรากำลังสนทนาเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติม
การตลาดตามบัญชี กรณีการใช้งานการตลาดตามบัญชีสามารถทำได้หรือไม่ Protected Audience API รองรับกรณีการใช้งานทางการตลาดตามกลุ่มเป้าหมายที่หลากหลาย เรายังคงทำความเข้าใจอย่างต่อเนื่องว่า Protected Audience API จะให้การสนับสนุนกรณีการใช้งานนี้อย่างดีที่สุดได้อย่างไร และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้จากระบบนิเวศ
การประมูลคอมโพเนนต์ ผู้เข้าร่วมการประมูลที่เป็นส่วนประกอบได้คะแนนอะไร การประมูลคอมโพเนนต์ไม่ได้ให้คะแนนกลุ่มความสนใจโดยตรง แต่จะให้คะแนนโฆษณาและราคาเสนอที่ DSP ส่งจากฟังก์ชัน generateBid ฟังก์ชัน generateBid() จะทำงานต่อกลุ่มความสนใจ และ DSP จะส่งกลับข้อมูลต่อไปนี้เมื่อเรียกใช้ generateBid: 

return {
  'ad': adObject,
  'adCost': optionalAdCost,
  'bid': bidValue,
  'render': renderUrl,
  'adComponents':
    [adComponent1, adComponent2, ...],
  'allowComponentAuction': false,
  'modelingSignals': 123};
}

การมีส่วนร่วมจากภายนอก ขอรองรับการมีส่วนร่วมภายนอกในฐานโค้ด GitHub สำหรับคีย์/ค่าเซิร์ฟเวอร์ เรากำลังอัปเดตกระบวนการที่เกี่ยวข้องเพื่อรองรับการมีส่วนร่วมจากภายนอกในโค้ด GitHub
ขนาดกลุ่มความสนใจ จำนวนคีย์สูงสุดที่รองรับซึ่ง IG รองรับคือเท่าไร ขีดจำกัดปัจจุบันคือ 50 KB สำหรับขนาดของ IG 1 รายการและคีย์จะนับเป็นส่วนหนึ่งของจำนวนนั้น เรายินดีรับพูดคุยเพิ่มเติมเกี่ยวกับขีดจำกัดขนาด
รวมกลุ่ม ฉันจะลดจำนวนการเรียกใช้เซิร์ฟเวอร์ K/V ได้อย่างไร คุณสามารถใช้ส่วนหัวการควบคุมแคช HTTP เพื่อลดจำนวนการเรียก K/V เช่น อาจมีการแคชไว้ในการประมูลองค์ประกอบต่างๆ และระหว่างช่องโฆษณาในหน้าเดียวด้วย
การควบคุมเวอร์ชัน การรองรับโค้ดเทคโนโลยีโฆษณาหลายเวอร์ชัน บริการการเสนอราคาและบริการประมูลจะรองรับโค้ดเทคโนโลยีโฆษณาหลายเวอร์ชัน ใน API การเสนอราคาและการประมูล คำขอ SelectAd สามารถระบุเวอร์ชันของโค้ดที่ใช้สำหรับคำขอการประมูล (เช่น สำหรับการเสนอราคา / การประมูล รวมถึงการรายงาน)
พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน รองรับการเขียนไปยังพื้นที่เก็บข้อมูลที่ใช้ร่วมกันในบริการการเสนอราคาและบริการประมูล ปัจจุบันการเสนอราคาและบริการประมูลไม่รองรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมว่าเหตุใดกรณีการใช้งานดังกล่าวจึงสำคัญต่อระบบนิเวศ
เว็บไปยังแอป รองรับการแชร์กลุ่มความสนใจจากเว็บไปยังแอป ขณะนี้เว็บไปยังแอปยังไม่มีขอบเขตการใช้งาน Protected Audience API ใน Chrome และ Android แต่เราต้องการรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับความสำคัญของกรณีการใช้งานนี้
K-Anonymity วิธีจัดการวิดีโอสำรองสำหรับ K-Anonymity เรากำลังพูดคุยเกี่ยวกับปัญหาและยินดีรับฟังความคิดเห็นเพิ่มเติม

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

Attribution Reporting (และ API อื่นๆ)

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การกำหนดค่ารายงานระดับเหตุการณ์ VTC ทางเลือก ความคิดเห็นเกี่ยวกับการกำหนดค่ารายงานระดับเหตุการณ์ VTC ทางเลือก เราได้รับความคิดเห็นมาว่าการกําหนดค่าระดับเหตุการณ์ปัจจุบันไม่เหมาะสม และขอความคิดเห็นเกี่ยวกับการกําหนดค่าส่วนกลางที่มีประสิทธิภาพสูงสุด เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเรื่องนี้ และคิดว่าเครื่องมืออธิบายระดับเหตุการณ์ที่ยืดหยุ่นจะช่วยแก้ปัญหานี้ได้เช่นกัน
การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น ฟีเจอร์การกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นมีสถานะอย่างไร เราได้แชร์เอกสารประกอบเกี่ยวกับการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น ฟีเจอร์ดังกล่าวยังอยู่ในขั้นตอนการทำข้อเสนอ และเรากำลังมองหาความคิดเห็นเพิ่มเติมว่าฟีเจอร์ดังกล่าวจะมีประโยชน์ต่อระบบนิเวศหรือไม่
การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น รายงานที่ขัดแย้งจากฝ่ายต่างๆ จะกระทบยอดกันได้อย่างไร สถานการณ์การรายงานส่วนใหญ่จะแก้ไขโดยการใช้รายงานสรุป ขณะที่ข้อเสนอการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นนั้นมีความยืดหยุ่นเป็นพิเศษสำหรับรายงานระดับเหตุการณ์ ซึ่งมักใช้กับกรณีการใช้งานการเพิ่มประสิทธิภาพโดยเฉพาะ เรายินดีรับฟังความคิดเห็น/ข้อเสนอแนะเพิ่มเติมจากระบบนิเวศนี้
การลงทะเบียนแหล่งที่มา จะเกิดอะไรขึ้นหากการลงทะเบียนต้นทางเกิดขึ้นหลังจากการลงทะเบียนทริกเกอร์ ในปัจจุบัน หากการลงทะเบียนแหล่งที่มาเกิดขึ้นหลังจากการลงทะเบียนทริกเกอร์ แหล่งที่มาและทริกเกอร์จะไม่สามารถระบุแหล่งที่มาซึ่งกันและกันได้ ดูเหมือนว่าจะเป็นสถานการณ์ที่เป็นปัญหาที่สุด เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้และจะพยายามแก้ไขหากเป็นสถานการณ์ที่ผู้เชี่ยวชาญด้านโฆษณาจำนวนมากต้องเผชิญ
การทำงานร่วมกับเอเจนซีโฆษณาหลายราย DSP จะใช้ Attribution Reporting API ได้อย่างไรเมื่อผู้ลงโฆษณาทำงานร่วมกับเอเจนซีโฆษณาหลายแห่ง API รองรับการเปลี่ยนเส้นทาง ดังนั้นจึงสามารถใช้ได้แม้ในกรณีที่ผู้ลงโฆษณาทำงานร่วมกับเอเจนซีโฆษณาหลายแห่ง นอกจากนี้ ยังมีข้อจำกัดบางประการเกี่ยวกับการเปลี่ยนเส้นทางเพื่อให้มั่นใจว่า API จะมีการปรับปรุงความเป็นส่วนตัว เรายังได้ระบุวิธีแก้ปัญหาเฉพาะหน้าที่เป็นไปได้โดยใช้ API พื้นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับสถานการณ์เฉพาะที่เทคโนโลยีโฆษณาได้นำเสนอขึ้นด้วย เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับสถานการณ์นี้และจะดำเนินการตรวจสอบตามความคิดเห็นนั้น
ขีดจำกัดปลายทาง กรณีการใช้งานโฆษณาที่รีเฟรชอัตโนมัติอาจได้รับผลกระทบจากการมีขีดจํากัดปลายทาง เราได้พูดคุยเกี่ยวกับปัญหานี้ในการประชุม WICG ของวันที่ 1 พฤษภาคม และต้องการทราบความคิดเห็นเกี่ยวกับขีดจำกัดที่สมเหตุสมผล เราได้เพิ่มการรายงานการระบุแหล่งที่มาด้วยตัวอธิบายรายงานระดับเหตุการณ์ ซึ่งระบุว่าเบราว์เซอร์สามารถจำกัดจำนวน eTLD+1 ของ "ปลายทาง" ที่แสดงโดยเว็บไซต์ต้นทางได้ (ดูการดึงข้อมูลคำขอ)
การรายงานการระบุแหล่งที่มาและกลุ่มเป้าหมายที่มีการป้องกัน Attribution Reporting API และ Protected Audience Audience API จะทำงานร่วมกันอย่างไร ปัจจุบันการผสานรวมใช้ได้กับ Protected Audience API ทั้งสำหรับโหมด Attribution Reporting API (ระดับเหตุการณ์และรายงานสรุป) เราได้แชร์ข้อมูลเพิ่มเติมเกี่ยวกับการผสานรวม Protected Audience API และ Attribution Reporting ที่ปรับปรุงใหม่เมื่อวันที่ 1 มิถุนายน อ่านได้ที่นี่
การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น แชร์แนวทางปฏิบัติแนะนำสำหรับการจำลองสัญญาณรบกวนเนื่องจากสามารถกำหนดค่าพารามิเตอร์ได้แล้ว เรามีโค้ดที่แชร์ร่วมกันบน GitHub ซึ่งทุกคนสามารถใช้ประเมินข้อมูลที่ได้รับและผลกระทบจากสัญญาณรบกวนสำหรับการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นที่ต้องการทดสอบ เรายินดีรับฟังความคิดเห็นจากผู้ที่เลือกทดสอบโค้ดและต้องการแชร์ความคิดเห็น
การวัดการระบุแหล่งที่มาข้ามแอปและเว็บ การวัดการระบุแหล่งที่มาข้ามแอปและเว็บจะพร้อมใช้งานเมื่อใด เราได้ประกาศไปเมื่อวันที่ 9 พฤษภาคมเกี่ยวกับการทดสอบการวัดการระบุแหล่งที่มาข้ามแอปและเว็บผ่าน Attribution Reporting API แม้ว่าจะมีการวางแผนความพร้อมให้บริการทั่วไปสําหรับ API ความเกี่ยวข้องและการวัดผลใน Chrome 115 แต่ขณะนี้การวัดการระบุแหล่งที่มาข้ามแอปและเว็บยังไม่มีแผนที่จะใช้งานกับ Chrome 115 เวอร์ชันสำหรับผู้ใช้ทั่วไป
กรองข้อมูล Conversion ที่ซ้ำกันออก โซลูชันการวัดผลอิสระจะปรับยอดกับ ARA ได้อย่างไร ผู้ลงโฆษณาจะทํางานร่วมกับผู้ให้บริการวัดผลอิสระบุคคลที่สามเพื่อกรองการรายงาน Conversion ที่ซ้ำกันออก เช่นเดียวกับแนวทางปฏิบัติมาตรฐานปัจจุบัน เรามีแหล่งข้อมูลเกี่ยวกับวิธีกรองข้อมูล Conversion ที่ซ้ำกันออกสำหรับการรายงานระดับเหตุการณ์
ข้อมูลสูญหายระหว่างการอัปเดตฐานข้อมูล Attribution Reporting ข้อมูลจะสูญหายหรือไม่เมื่อ Chrome อัปเดตฐานข้อมูล Attribution Reporting ตามที่ได้ประกาศไว้ ตั้งแต่ Chrome เวอร์ชันเสถียร 115 เป็นต้นไป เราจะเริ่มเปิดใช้ API ความเกี่ยวข้องและการวัดผลสำหรับผู้ใช้ Chrome บางส่วนโดยค่าเริ่มต้น เวอร์ชันสำหรับผู้ใช้ทั่วไปนี้จะเพิ่มขึ้นขณะที่เราตรวจสอบปัญหาที่อาจเกิดขึ้น เป้าหมายคือการทำให้ความพร้อมใช้งานครบ 100% ภายในไม่กี่สัปดาห์ภายในไตรมาส 3 ปี 2023 ซึ่งจะตรงกับเวลาสิ้นสุดของช่วงทดลองใช้ความเกี่ยวข้องและการวัดผลจากต้นทาง ตั้งแต่เดือนกรกฎาคมเป็นต้นไป ผู้ทดสอบจะสามารถลงทะเบียนเพื่อเข้าถึง API เหล่านี้ได้ในเวอร์ชันสำหรับผู้ใช้ทั่วไป ซึ่งจะให้ความคาบเกี่ยวระหว่างความพร้อมให้บริการของช่วงทดลองใช้จากต้นทางกับเวอร์ชันสำหรับผู้ใช้ทั่วไปผ่านการลงทะเบียน โทเค็นช่วงทดลองใช้จากต้นทางจะใช้ได้จนถึงวันที่ 19 กันยายน แต่เราขอแนะนำให้คุณลงทะเบียน API ก่อนหมดอายุเพื่อให้ย้ายออกจากช่วงทดลองใช้จากต้นทางได้อย่างราบรื่นโดยไม่รบกวนการทดสอบที่ดำเนินอยู่

ดังที่ระบุไว้ในประกาศนี้ ระบบจะไม่ย้ายข้อมูลที่ลงทะเบียนจากเวอร์ชันเก่า (M113 และก่อนหน้า) หลังการอัปเดต ดังนั้นข้อมูลจึงอาจสูญหาย การสูญหายของข้อมูลนี้จะไม่แสดงในการรายงานการแก้ไขข้อบกพร่อง และเราจะพยายามป้องกันไม่ให้ข้อมูลสูญหายจาก 114 ถึง 115
การเรียกเก็บเงิน การใช้ Attribution Reporting สําหรับการเรียกเก็บเงินแบบต้นทุนต่อ Conversion ตามที่ระบุไว้ในบทความนี้ Attribution Reporting API อาจไม่เหมาะกับการเรียกเก็บเงินแบบต้นทุนต่อ Conversion เนื่องจากมีการเพิ่มข้อมูลรบกวนลงในรายงานระดับเหตุการณ์และรายงานสรุป เราสนับสนุนให้ผู้เล่นในระบบนิเวศแชร์ความคิดเห็นเกี่ยวกับผลกระทบต่อรูปแบบการเรียกเก็บเงินต่างๆ ด้วย Attribution Reporting API ใน GitHub

บริการรวบรวม

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การเปลี่ยนแปลงความล่าช้าของรายงานแบบรวมได้ ปฏิกิริยาเชิงบวกต่อข้อเสนอเพื่อเปลี่ยนความล่าช้าของรายงานที่รวบรวมได้เป็น [10-60 นาที] เป็น [0-10 นาที] หลังจากได้รับความคิดเห็นจากระบบนิเวศ เรายินดีที่ได้เห็นปฏิกิริยาเชิงบวกต่อการเปลี่ยนแปลงที่เสนอนี้ และสนับสนุนให้ระบบนิเวศแสดงความคิดเห็นเกี่ยวกับข้อเสนอของเราต่อไป
โซลูชันของบริษัท สามารถนําบริการรวบรวมข้อมูลไปใช้งานในศูนย์ข้อมูลภายในองค์กรได้ไหม แม้ว่าเรากำลังสำรวจตัวเลือกที่อาจสนับสนุนนอกเหนือจากโซลูชันระบบคลาวด์ แต่ขณะนี้ก็ยังไม่สามารถรองรับ TEE ภายในองค์กรได้ เนื่องจากมีข้อจำกัดด้านความปลอดภัยภายในองค์กร ซึ่งยังต้องประเมินเวลา Privacy Sandbox อยู่นาน เมื่อพิจารณาจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และความท้าทายสำคัญที่ได้รับจากการติดตั้งใช้งานภายในองค์กร เราเชื่อว่าการขยายและปรับปรุงการติดตั้งใช้งานในระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ GCP เพิ่มเติมจาก AWS) คือประโยชน์มากที่สุดสำหรับระบบนิเวศนี้ อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่จำเป็นต้องมีข้อกำหนดดังกล่าว
ประมวลผลรายงานสำหรับช่วงเวลาต่างๆ อีกครั้ง ความสามารถในการประมวลผลรายงานในช่วงเวลาต่างๆ อีกครั้ง เราได้รับคําขอที่คล้ายกันให้แยกกลุ่มสำหรับช่วงวันที่อื่นๆ ได้ ข้อเสนอหนึ่งคือการเพิ่มความสามารถในการขยายรหัสที่แชร์ด้วยป้ายกำกับที่เทคโนโลยีโฆษณากำหนด เพื่อให้รายงานแบ่งออกเป็นกลุ่มต่างๆ ได้ เรากำลังอยู่ในขั้นตอนเริ่มต้นของการประเมินกระบวนการนี้ และจะคอยอัปเดตระบบนิเวศในระหว่างที่ข้อเสนอนี้เปลี่ยนแปลงไปเรื่อยๆ
ผลกระทบด้านความเป็นส่วนตัวของสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ ความรู้สึกในเชิงบวกต่อผลกระทบด้านความเป็นส่วนตัวของสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ เรายินดีที่ได้ทราบปฏิกิริยาเชิงบวกจากระบบนิเวศเกี่ยวกับข้อเสนอของเรา และเรายินดีรับฟังความคิดเห็นเพิ่มเติมในระหว่างที่เรากำลังปรับปรุงและพัฒนาอย่างต่อเนื่อง
ข้อกำหนดในการให้บริการ กำหนดเวลาในการยอมรับข้อกำหนดในการให้บริการของบริการรวบรวมข้อมูลคือเมื่อใด แม้ว่าเราจะยังไม่ได้ระบุกำหนดเวลาในการยอมรับข้อกำหนดและเงื่อนไข แต่เราก็ขอแนะนำให้บริษัทที่ให้บริการด้านระบบนิเวศยอมรับข้อกำหนดในการให้บริการโดยเร็วที่สุดเพื่อป้องกันไม่ให้เกิดความล่าช้าในการลงทะเบียน เราแนะนำให้บริษัทต่างๆ ติดต่อกลับมาหากมีคำถาม
การค้นพบคีย์ ฟีเจอร์การค้นพบหลักจะทำให้ผู้ทดสอบค้นหารายงานเชิงสถิติได้โดยไม่จำเป็นต้องมีรายการชุดคีย์ผสมที่เป็นไปได้อย่างชัดเจน เพื่อประมวลผลรายงานสรุปสำหรับการระบุแหล่งที่มาข้ามเครือข่ายเพื่อปรับปรุงประสิทธิภาพและความแม่นยำ ขณะนี้เรากำลังสำรวจวิธีแก้ปัญหาที่เป็นไปได้และวิธีแก้ไขปัญหาเฉพาะหน้า และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ

API การรวมส่วนตัว

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
ต้นทางการรายงาน ที่มาของการรายงานมีคำจำกัดความอย่างไร ต้นทางการรายงานจะเป็นต้นทางสคริปต์ของผู้โทรการรวมส่วนตัวเสมอ
แป้นเว้นวรรค 128 บิต ความชัดเจนของข้อจำกัดของพื้นที่ทำงาน 128 บิต เราจะทำให้การจำกัดพื้นที่แป้นนี้ชัดเจนขึ้นและแก้ไขความไม่สอดคล้องกันของหน้าต่างๆ เราขอแนะนําให้ใช้กลยุทธ์การแฮชเพื่อให้อยู่ในแป้นนี้
การมีส่วนร่วมสูงสุดต่อรายงาน ขีดจํากัดปัจจุบันที่ 20 การมีส่วนร่วมต่อรายงานต่ำเกินไป แทนที่จะเพิ่มจำนวนการมีส่วนร่วมสูงสุด เราก็ยินดีพิจารณาแยกรายงานแทนที่จะตัดให้เหลือเพียงจำนวนครั้งสูงสุด เราจะมีส่วนร่วมในระบบนิเวศขณะที่ข้อเสนอนี้พัฒนา
การรายงานการเข้าถึง ขอการรายงานการเข้าถึงข้ามแพลตฟอร์ม/หลายอุปกรณ์ การเข้าถึงเป็นเมตริกพื้นฐานของการโฆษณาแบรนด์ ผู้ลงโฆษณาอาศัยการคาดการณ์แบบข้ามแพลตฟอร์ม/หลายอุปกรณ์ในการรายงานการเข้าถึงและความถี่เพื่อวิเคราะห์แคมเปญและจัดสรรการใช้จ่าย โมเดลการเข้าถึงใช้คุกกี้ของบุคคลที่สามเป็นสัญญาณในการวัดโฆษณาที่แสดงในสภาพแวดล้อมของบุคคลที่สาม เทคโนโลยีโฆษณาจึงขอโซลูชันอื่นเมื่อเลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว
 ทีม Privacy Sandbox กำลังสำรวจฟีเจอร์ต่างๆ เพื่อสนับสนุนวิธีการเข้าถึงผลแบบข้ามโดเมนหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม
เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ

จำกัดการติดตามแบบไม่เปิดเผย

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
(มีการรายงานในไตรมาสที่ 1 ปี 2023 ด้วย) คำแนะนำสำหรับรูปแบบของอุปกรณ์เพิ่มเติม ขอคำแนะนำสำหรับ User Agent Client (UA-CH) เพื่อระบุรูปแบบของอุปกรณ์เพิ่มเติม เช่น TV, VR เรายังคงตัดสินใจเลือกการออกแบบที่สำคัญๆ อยู่ (ว่าจะจัดเตรียมค่าเดี่ยวๆ เช่น "ทีวี" หรือรายการความสามารถของรูปแบบของอุปกรณ์) แต่ยังคงสนใจในการสร้างต้นแบบของแนวคิดนี้
งบประมาณด้านความเป็นส่วนตัว ข้อจำกัดด้านงบประมาณความเป็นส่วนตัวอาจทำให้คำขอ UA-CH เป็นแบบไม่ได้กำหนดเมื่อมีการส่งคำขอมากเกินไป เรายังไม่มีการอัปเดตใหม่สำหรับข้อเสนองบประมาณความเป็นส่วนตัวในตอนนี้ แต่เรามุ่งมั่นที่จะไม่จำกัดคำขอคำแนะนำสำหรับไคลเอ็นต์ UA ก่อนที่จะมีการเลิกใช้งานคุกกี้ของบุคคลที่สาม
ความเข้ากันได้ของเว็บไซต์ เว็บไซต์ใช้แบรนด์ UA-CH ในการจำกัดไม่ให้บางเบราว์เซอร์เข้าถึงเว็บไซต์ การใช้รายการแบรนด์นั้นมีอยู่ด้วยกันหลายกรณี และหนึ่งในนั้นคือความเข้ากันได้ที่แน่นอน UA เป็นอิสระในการให้หลายแบรนด์ช่วยแก้ปัญหาเหล่านี้

การป้องกัน IP (เดิมคือ Gnatcatcher)

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การประพฤติมิชอบและการละเมิด บริษัทจะกำหนดมาตรการป้องกันการประพฤติมิชอบด้วยการป้องกัน IP ได้อย่างไร เราเข้าใจถึงความสำคัญของกรณีการใช้งานเพื่อป้องกันการฉ้อโกงและผลกระทบที่อาจเกิดขึ้นกับกรณีการใช้งานดังกล่าว เราวางแผนที่จะเผยแพร่รายละเอียดเพิ่มเติมเกี่ยวกับการสนับสนุนการป้องกันการประพฤติมิชอบในช่วงฤดูร้อนนี้ เรากำลังรับฟังความคิดเห็นเกี่ยวกับระบบนิเวศเพื่อที่เราจะได้ให้การสนับสนุนแก่ Use Case ป้องกันการทุจริตให้ดียิ่งขึ้น
GeoIP ข้อมูลเพิ่มเติมเกี่ยวกับระยะเวลาการทดสอบและการปรับใช้งานสำหรับ GeoIP เมื่อเร็วๆ นี้ Chrome ได้เผยแพร่ข้อมูลใหม่ซึ่งให้รายละเอียดเกี่ยวกับแผน GeoIP ของเรา เรากำลังวางแผนที่จะเผยแพร่ข้อมูลเพิ่มเติมเกี่ยวกับลำดับเวลาการทำให้ใช้งานได้ในไตรมาสที่ 3 เราคาดว่าจะเปิดตัวการป้องกัน IP ในรูปแบบที่ผู้ใช้เลือกใช้กับการเข้าชมจำนวนเล็กน้อยในตอนแรก เหตุผลก็คือเราตระหนักดีว่าข้อเสนอนี้อาจเกี่ยวข้องกับการเปลี่ยนแปลงที่สำคัญบางอย่างสำหรับบริษัท และเราต้องการให้เวลาระบบนิเวศในการปรับเปลี่ยนและแสดงความคิดเห็นก่อนที่จะเปิดตัวฟีเจอร์นี้ในวงกว้างขึ้น
การตรวจสอบสิทธิ์บัญชี การตรวจสอบสิทธิ์บัญชีกับพร็อกซีเซิร์ฟเวอร์จะทำงานอย่างไร เราวางแผนที่จะเผยแพร่รายละเอียดเพิ่มเติมเกี่ยวกับการตรวจสอบสิทธิ์บัญชีภายหลังในฤดูร้อนนี้ แต่เราได้แชร์สิ่งที่ควรพิจารณาเบื้องต้นไปบ้างแล้ว

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

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
คำแนะนำในการทดสอบ ข้อมูลเกี่ยวกับวิธีทดสอบการลดการติดตามการเข้าออก เราได้เผยแพร่ บล็อกโพสต์ในเดือนพฤษภาคมพร้อมข้อมูลเพิ่มเติมเกี่ยวกับวิธีทดสอบการลดการติดตามการเข้าออก
เอกสารประกอบ ความชัดเจนในข้อเสนอการติดตามการเข้าออก ข้อเสนอปัจจุบันยังอยู่ระหว่างการพัฒนา และ Chrome จะอัปเดตข้อเสนออย่างต่อเนื่องเพื่อให้ข้อมูลและความชัดเจนแก่ระบบนิเวศ เรากำลังดำเนินการเพื่อให้รายละเอียดเพิ่มเติมและยินดีรับฟังความคิดเห็นเพิ่มเติม
การลบคุกกี้ การลดการติดตามการเข้าออกจะลบคุกกี้ทั้งหมดในโดเมนไหม การลดการติดตามการเข้าออก (BTM) จะล้างพื้นที่เก็บข้อมูลและแคชทั้งหมดตามที่อธิบายไว้ที่นี่
การหลีกเลี่ยงการลดการติดตามการเข้าออก การเปลี่ยนเส้นทางด้วยป๊อปอัปหรือแท็บใหม่อาจข้ามการจัดหมวดหมู่เครื่องติดตามการตีกลับได้ ข้อมูลจำเพาะของการลดการติดตามการเข้าออกยังคงอยู่ระหว่างการพัฒนา ที่ผ่านมาเราเน้นที่การเปลี่ยนเส้นทางแท็บเดียวกันเป็นส่วนใหญ่ แต่เราวางแผนที่จะทำการแสดงป๊อปอัปในอนาคต เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่

งบประมาณด้านความเป็นส่วนตัว

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การกำหนดเป้าหมายที่ใกล้เคียง งบประมาณด้านความเป็นส่วนตัวอาจส่งผลต่อ Use Case การกำหนดเป้าหมายที่ใกล้เคียงกัน เราได้รับความคิดเห็นเกี่ยวกับปัญหานี้แล้ว และสนใจที่จะรับฟังเพิ่มเติมเกี่ยวกับผลกระทบที่อาจเกิดขึ้นจากระบบนิเวศ

ขยายขอบเขตความเป็นส่วนตัวแบบข้ามเว็บไซต์

ชุดโดเมนของบุคคลที่หนึ่ง

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
(รายงานในไตรมาสที่แล้วด้วย) ขีดจำกัดโดเมน คำขอขยายจำนวนโดเมนที่เชื่อมโยง Chrome กำลังประเมินขีดจำกัดตัวเลขที่เหมาะสมสำหรับชุดย่อยที่เกี่ยวข้อง ซึ่งจะสร้างสมดุลระหว่างความเป็นส่วนตัวกับประโยชน์ในการใช้งานที่ได้ระบุมา ในช่วงเริ่มต้น Chrome ได้แจ้งว่าตัวเลขที่แน่นอนของชุดย่อยที่เกี่ยวข้องยังไม่ได้รับการสรุป
กรณีการใช้งานแบบฝัง การรองรับ Use Case แบบฝังซึ่งต้องใช้ชุดโดเมนของบุคคลที่หนึ่ง, CHIP และพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน Chrome ได้รับความคิดเห็นเกี่ยวกับกรณีการใช้งานนี้ และทีมของเรากำลังตรวจสอบและยินดีรับความคิดเห็นเพิ่มเติม
การจัดการที่เก็บ ข้อมูลเกี่ยวกับนโยบายที่จะนำชุดโดเมนของบุคคลที่หนึ่งออกจากที่เก็บ GitHub หากมีความคลาดเคลื่อนหรือละเลย Chrome ได้รับความคิดเห็นเกี่ยวกับกรณีการใช้งานนี้แล้ว ทีมของเรากำลังตรวจสอบและยินดีรับความคิดเห็นเพิ่มเติม
การให้ความรู้แก่ผู้ใช้ Chrome ควรเพิ่มการรับรู้และความเข้าใจของผู้ใช้เกี่ยวกับชุดโดเมนของบุคคลที่หนึ่งเพื่อกระตุ้นให้เกิดการใช้งาน Chrome มุ่งมั่นที่จะให้ความรู้แก่ผู้ใช้เกี่ยวกับชุดโดเมนของบุคคลที่หนึ่ง และเผยแพร่ บทความในศูนย์ช่วยเหลือ (ลิงก์จาก UI ของ Chrome) เกี่ยวกับนโยบายนี้ Chrome ยังลงทุนอย่างต่อเนื่องในการเรียนรู้วิธีให้ความรู้ที่ดีที่สุดแก่ผู้ใช้ในบริบทที่เหมาะสม
โพสต์แบบ 3PCD คุกกี้ของบุคคลที่สามจะยังคงอยู่ในชุดโดเมนของบุคคลที่หนึ่งหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม แม้ว่า requestStorageAccess และ requestStorageAccessFor จะทำให้คุกกี้ของบุคคลที่สามพร้อมใช้งานอีกครั้งสำหรับ Use Case ที่เจาะจงและระบุไว้อย่างชัดเจน แต่ในตอนนี้เว็บไซต์กำหนดให้เรียกใช้คุกกี้ที่ใช้งานอยู่แทนพร้อมใช้งานโดยค่าเริ่มต้น อย่างเช่นสถานะปัจจุบันของคุกกี้ของบุคคลที่สาม (ใน Chrome)

แม้ว่าคำขอนี้จะไม่จำเป็นต้องมีการอนุมัติจากผู้ใช้ แต่ผู้ใช้สามารถป้องกันการดำเนินการนี้ได้โดยเลือกไม่ใช้ลักษณะการทำงานนี้ในการตั้งค่า

ผู้ใช้ดูข้อมูลเพิ่มเติมได้ที่บทความในศูนย์ช่วยเหลือ (ลิงก์จาก UI ของ Chrome) เราวางแผนที่จะขยายการใช้งานตามคู่มือนักพัฒนาซอฟต์แวร์ที่มีอยู่เนื่องจากอัตรา FPS สูงสุด 100%
การส่งชุดโดเมนของบุคคลที่หนึ่ง เปลี่ยนชื่อ .well-known/first-party-set ที่ต้องระบุเพื่อรวมส่วนขยาย .json เราได้ทำการเปลี่ยนแปลงนี้เพื่อรองรับแพ็กเกจเว็บโฮสติ้งบางแพ็กเกจ
การจดทะเบียน IANA first_party_sets.JSON ควรลงทะเบียนกับ IANA เรากำลังพิจารณาข้อเสนอนี้และยินดีรับความคิดเห็นเพิ่มเติมที่นี่

Fenced Frames API

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

API พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การนำไปใช้งานในวงกว้างขึ้น พื้นที่เก็บข้อมูลที่ใช้ร่วมกันควรเป็นมาตรฐานอุตสาหกรรมทั่วทั้งเบราว์เซอร์ เรายินดีรับฟังและรับทราบความคิดเห็นนี้ Chrome ยังคงมีส่วนร่วมใน W3C อย่างต่อเนื่องเพื่อสนับสนุนข้อเสนอ ขอความคิดเห็น และกระตุ้นการนำไปใช้
ประตูเอาต์พุต ขีดจำกัดเอาต์พุตของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีจำกัดเกินไป เรากำลังพิจารณาความคิดเห็นนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมของระบบนิเวศเกี่ยวกับสาเหตุที่โอกาสรับผลลัพธ์ถูกจำกัดมากเกินไป
การปฏิบัติตามกฎระเบียบ พื้นที่เก็บข้อมูลที่ใช้ร่วมกันจะจัดการการปฏิบัติตามข้อกำหนด เช่น นโยบายการเก็บรักษาข้อมูล พื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีความยืดหยุ่นในการใช้งานและปรับแต่งตรรกะเพื่อควบคุมอายุการใช้งานและการหมดอายุของข้อมูลที่จัดเก็บไว้ เทคโนโลยีโฆษณาสามารถอัปเดตหรือล้างข้อมูลพื้นที่เก็บข้อมูลที่ใช้ร่วมกันโดยอิงตามการประทับเวลาการเขียน
การทดสอบอัลฟา/เบต้า การทดสอบ A/B สำหรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกันและ Protected Audience API จะดำเนินการได้อย่างไร เรากำลังเผยแพร่คำแนะนำเพิ่มเติมเกี่ยวกับเรื่องนี้อยู่และหวังว่าจะได้แชร์รายละเอียดเพิ่มเติมในอนาคต
ขีดจำกัดของพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน จะเกิดอะไรขึ้นเมื่อใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันถึงขีดจำกัด หากถึงขีดจำกัดแล้ว ระบบจะไม่จัดเก็บอินพุตใดๆ เพิ่มเติม
การเข้าถึงหลายรายการในการโหลดหน้าเว็บเดียวกัน จะเกิดอะไรขึ้นเมื่อมีการเข้าถึงพื้นที่เก็บข้อมูลที่ใช้ร่วมกันหลายครั้งในการโหลดหน้าเว็บเดียวกัน วิธีที่ดีที่สุดในการจัดการปัญหานี้คือการดำเนินการผ่านฟังก์ชัน window.sharedStorage.append(key, value) แทนที่จะอัปเดตค่าของโฆษณาแต่ละรายการ ซึ่งอาจทำให้เกิดความขัดแย้งกันในกรณีที่มีโฆษณาหลายรายการ ฟังก์ชันการต่อท้ายจะเพิ่มค่าใหม่ที่ส่วนท้ายของค่าที่มีอยู่ก่อนหน้า
ฟังก์ชันการทำงานของ iframe พื้นที่เก็บข้อมูลที่ใช้ร่วมกันจะรองรับฟังก์ชันการทำงานบางอย่างของ iframe หรือไม่หลังจากเลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว หลังการเลิกใช้งานคุกกี้ของบุคคลที่สาม เว็บไซต์ระดับบนสุดจะแบ่งพาร์ติชันพื้นที่เก็บข้อมูลในเครื่องใน iframe ตามเว็บไซต์ระดับบนสุด แต่จะไม่บล็อก iframe ข้อมูลในพื้นที่เก็บข้อมูลในเครื่องของ iframe จะไม่สามารถทำซ้ำในเว็บไซต์ระดับบนสุดหลายๆ เว็บไซต์ แต่พื้นที่เก็บข้อมูลในเครื่องจะยังคงใช้ภายใน iframe ได้

ชิป

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
ขีดจำกัดพาร์ติชัน 10 KiB ต่อเว็บไซต์ที่แบ่งพาร์ติชันยังมีความสำคัญมากและอยากให้ลดลง Firefox ได้ระบุ อันดับเชิงบวกบน CHIPS แล้ว สําหรับการรองรับ Webkit เราขอแนะนําให้นักพัฒนาแอปแสดงความคิดเห็นต่อ Apple โดยตรงเกี่ยวกับ ปัญหาเกี่ยวกับ GitHub เกี่ยวกับกรณีการใช้งานที่ควรใช้คุกกี้ที่แบ่งพาร์ติชันมากกว่าพื้นที่เก็บข้อมูลที่แบ่งพาร์ติชัน
การฝังที่ตรวจสอบสิทธิ์แล้ว CHIP อาจส่งผลต่อขั้นตอนการลงชื่อเข้าใช้ SSO ปัจจุบันเนื่องจากการแบ่งพาร์ติชันที่แตกต่างกันซึ่งส่งผลต่อการฝังที่ตรวจสอบสิทธิ์แล้ว เราตั้งใจที่จะใช้ประโยชน์จาก Storage Access API (พร้อมข้อความแจ้งผู้ใช้) เพื่อรองรับ Use Case การฝังที่ผ่านการตรวจสอบสิทธิ์ และเพิ่งส่ง Intent เพื่อสร้างต้นแบบ
นโยบายตลอดอายุการใช้งาน นโยบายตลอดอายุการใช้งานที่เป็นไปได้จะมีผลกับคุกกี้ของบุคคลที่หนึ่งไหม ขณะนี้เราไม่มีแผนที่จะกำหนดขีดจำกัดตลอดอายุการใช้งานคุกกี้ของบุคคลที่หนึ่ง

FedCM

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การสนับสนุนการให้สิทธิ์ OAuth ทำให้สอดคล้องกันกับการให้สิทธิ์ขอบเขต OAuth ที่ไม่ใช่โปรไฟล์ เรากำลังอย่างเต็มที่เพื่อขอความคิดเห็นจากชุมชน Web Identity ผ่าน W3C FedID CG เกี่ยวกับวิธีที่ดีที่สุดในการรองรับการให้สิทธิ์นอกเหนือจากการตรวจสอบสิทธิ์ขั้นพื้นฐานหลังการเลิกใช้งานคุกกี้ของบุคคลที่สาม
การสนับสนุนสำหรับ SAML ปฏิบัติตามข้อกําหนดสำหรับการรองรับ SAML ทีมของเราพยายามอย่างเต็มที่เพื่อขอความคิดเห็นจากชุมชนการวิจัยและการศึกษาเกี่ยวกับความต้องการรับการสนับสนุน SAML (นอกเหนือจากการสนับสนุน OpenID Connect) หลังการเลิกใช้งานคุกกี้ของบุคคลที่สาม

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

API โทเค็นสถานะส่วนตัว (และ API อื่นๆ)

ธีมความคิดเห็น สรุป การตอบกลับของ Chrome
การสำรวจสัญญาณใหม่ พาร์ทเนอร์หลายรายแสดงความคิดเห็นเชิงบวกต่อการสำรวจสัญญาณจากความสมบูรณ์ของอุปกรณ์หรือความไว้วางใจของผู้ใช้ที่ได้จากเบราว์เซอร์ โดยทั่วไปแล้ว ผู้ผลิตจะต้องระมัดระวังเกี่ยวกับสัญญาณใหม่ๆ ที่สร้างขึ้นเพื่อวัตถุประสงค์เฉพาะเพื่อให้เพียงพอที่จะรักษาระดับการตรวจจับการประพฤติมิชอบในปัจจุบันไว้ เราตื่นเต้นที่จะได้สำรวจข้อเสนอใหม่ๆ ร่วมกันภายในชุมชนต่อต้านการประพฤติมิชอบและความปลอดภัยบนเว็บ ตลอดจนรับทราบและแชร์ข้อกังวลของพวกเขา นี่คือเหตุผลว่าทำไม "การต่อสู้กับสแปมและการประพฤติมิชอบ" จึงเป็นกระบวนการหลักของ Privacy Sandbox และสาเหตุที่เราให้ความสำคัญกับการลงทุนในการรักษาความปลอดภัยของเว็บอย่างต่อเนื่อง ไปพร้อมๆ กับปรับปรุงความเป็นส่วนตัวของผู้ใช้
ความคิดเห็นเชิงบวกเกี่ยวกับ PST พาร์ทเนอร์หลายรายได้แสดงความสนใจที่จะทดสอบหรือใช้ PST สำหรับกรณีการใช้งานต่างๆ เพื่อป้องกันการประพฤติมิชอบหรือความปลอดภัยของเว็บ เราตื่นเต้นที่จะได้ฟังการสนับสนุนและสนใจสำรวจโซลูชันใหม่ๆ ที่ใช้ PST ต่อไป เรามีทรัพยากรและโค้ดตัวอย่างให้ใช้งานทางเว็บไซต์นักพัฒนาซอฟต์แวร์ Chrome และยินดีรับฟังความคิดเห็นเพิ่มเติม
การประพฤติมิชอบและการละเมิด คำแนะนำสำหรับการป้องกันการฉ้อโกง / การตรวจจับโฆษณาในการวัดผลหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามเมื่อไม่มีตัวระบุแล้ว เราได้เปิดตัวเครื่องมือต่างๆ เช่น โทเค็นสถานะส่วนตัว ซึ่งจะช่วยกู้คืนสัญญาณบางส่วนที่คุกกี้ของบุคคลที่สามสูญเสียไปเพื่อจุดประสงค์ในการป้องกันการประพฤติมิชอบ แต่ด้วยการควบคุมความเป็นส่วนตัวแบบใหม่ เรากําลังลงทุนอย่างแข็งขันสำหรับข้อเสนอการป้องกันการประพฤติมิชอบและการละเมิดใหม่ๆ เพื่อรักษาความสามารถเอาไว้ด้วยการเปลี่ยนแปลงอื่นๆ ของ Privacy Sandbox
อัตราสำหรับข้อมูลผู้ออกบัตรถึงต้นทาง อัตราข้อมูลของผู้ออกไปยังต้นทางสูงพอที่จะระบุผู้ใช้ที่ไม่ซ้ำได้ เราได้อัปเดตข้อกำหนดให้ชัดเจนยิ่งขึ้นเกี่ยวกับข้อมูลผู้ใช้ที่สื่อสารได้โดยใช้โทเค็นสถานะส่วนตัว ตามหลักแล้ว สามารถใช้คีย์สาธารณะพร้อมกันได้สูงสุด 6 รหัส ซึ่งอาจแสดงถึง "รัฐ" สำหรับผู้ใช้รายนั้นๆ ชุดคีย์เหล่านี้จะอัปเดตได้ทุกๆ 60 วันเท่านั้น (ยกเว้นในกรณีที่ต้องมีการหมุนเวียนคีย์ฉุกเฉิน ซึ่งเป็นกรณีที่พบไม่บ่อยนัก) ซึ่งจะทำให้การผูกข้อมูลผู้ใช้เพิ่มเติมช้าลงเมื่อเวลาผ่านไป เมื่อใช้ Web API ใหม่ จะมีความสมดุลของยูทิลิตีที่ให้ไว้และข้อมูลผู้ใช้ใหม่สุทธิที่แอปให้ เราประเมินว่า PST จะมีจุดสมดุลที่เหมาะสมในการปกป้องความเป็นส่วนตัวของผู้ใช้ พร้อมกับเปิดใช้ Use Case หลักเพื่อป้องกันการฉ้อโกงซึ่งได้รับผลกระทบจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม
การผสานรวมการดึงข้อมูล การผสานรวม fetch มีความซับซ้อนและไม่จำเป็น การใช้ fetch มีทั้งข้อดีและข้อเสีย และเราต้องการทำตามมาตรฐานนี้ให้มากยิ่งขึ้นภายในระบบนิเวศของเว็บ แต่เราคิดว่ายังเร็วเกินไปที่จะทำการเปลี่ยนแปลงนี้จนกว่าเราจะมีความชัดเจนมากขึ้นว่ามาตรฐานนี้จะมีหน้าตาอย่างไร และหากมาตรฐานปรากฏ เราก็มุ่งมั่นที่จะให้นักพัฒนาเว็บเปลี่ยนไปใช้มาตรฐานนั้นอย่างมีความรับผิดชอบ
ตำแหน่งพื้นที่เก็บข้อมูล ควรจัดเก็บการกำหนดค่าคีย์โทเค็นสถานะส่วนตัวไว้ในตำแหน่งเดียวกับโปรโตคอล PrivacyPass ขณะทดสอบระหว่างช่วงทดลองใช้จากต้นทาง นักพัฒนาซอฟต์แวร์ระบุว่าต้องการให้ความยืดหยุ่นในการจัดเก็บคีย์ใน URL ทั่วไปแทนที่จะเก็บไว้ในไดเรกทอรี .well-known รูปแบบสัญญาผูกมัดหลักใน PrivacyPass ไม่เหมาะกับเวอร์ชันที่ชุดคีย์มีไว้เพื่ออนุญาตให้มีค่า "ข้อมูลเมตาสาธารณะ" โดยนัย หาก PrivacyPass เวอร์ชันหนึ่งได้รับข้อมูลเมตาสาธารณะที่เป็นมาตรฐาน (ไม่ว่าจะเป็น POPRF, การปกปิด RSA บางส่วน หรือชุดคีย์) เราอาจเปลี่ยนไปใช้ PST เวอร์ชันในอนาคตเพื่อรองรับการใช้งานดังกล่าว
การใช้งาน API ในส่วนหัวของ คำถามเกี่ยวกับการติดตั้งใช้งาน API ในส่วนหัวของ เมื่อ API ได้รับการปรับให้เป็นมาตรฐานและการใช้งานระบบนิเวศของ API นี้มากขึ้น เราหวังว่าจะรองรับทั้งเวอร์ชันมาตรฐานที่ไม่ใช่ส่วนหัวของ API นี้ และอาจเลิกใช้งานเวอร์ชันส่วนหัวในที่สุดหากมีการใช้งานต่ำเพียงพอหรือมีเครื่องมือ/การสนับสนุนสำหรับนักพัฒนาซอฟต์แวร์เพียงพอสำหรับวิธีมาตรฐานในการเชื่อมโยงคำขอออก/แลกสิทธิ์กับข้อมูลอื่น เรากำลังหารือเกี่ยวกับปัญหาที่นี่
การลงทะเบียน การทำให้ผู้ออกการลงทะเบียนกับผู้ให้บริการเบราว์เซอร์สามารถปฏิบัติได้จริงหรือไม่ เราได้อัปเดตข้อกำหนดให้อธิบายถึงขั้นตอนการลงทะเบียนผู้ออกใบรับรองสำหรับโทเค็นสถานะส่วนตัว แม้ว่าจะใช้กระบวนการของตนเอง แต่ก็คล้ายกับแผนการลงทะเบียนสำหรับงานอื่นๆ ของ Privacy Sandbox โดยเราจะขอให้ผู้ออกแถลงการณ์ต่อสาธารณะเกี่ยวกับความตั้งใจในการใช้ PST และรับทราบข้อจำกัดทางเทคนิคซึ่งปกป้องความเป็นส่วนตัวของผู้ใช้