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

รายงานรายไตรมาสสําหรับไตรมาสที่ 3 ของปี 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
ความพร้อมของระบบนิเวศ	SSP เน้นแสดงความกังวลที่ผู้เผยแพร่โฆษณาไม่พร้อมและไม่ดำเนินการติดตั้งใช้งานที่จำเป็น	Privacy Sandbox มีการเข้าถึงที่มุ่งเน้นในการให้ความรู้แก่ผู้เผยแพร่โฆษณาโดยเฉพาะ ซึ่งรวมถึงการสัมมนาผ่านเว็บและการประชุมเฉพาะที่มีทั้งผู้เผยแพร่โฆษณาและ SSP ที่เข้ามากระตุ้นงานในการติดตั้งใช้งาน
การเลิกใช้งานคุกกี้ของบุคคลที่สาม	ความกังวลเกี่ยวกับการเลิกใช้งานคุกกี้ของบุคคลที่สาม (3PCD) เพิ่มสูงขึ้นในไตรมาสที่ 4 ปี 2023 เนื่องจากเทคโนโลยีในอุตสาหกรรมหยุดทำงาน	เราได้หารือกับ CMA เกี่ยวกับไทม์ไลน์ของ Privacy Sandbox กับ CMA แล้ว โดยได้เวลาเตรียมตัวสำหรับช่วงครึ่งหลังของปี 2024 Privacy Sandbox จะเผยแพร่ข้อมูลที่ละเอียดมากขึ้นเกี่ยวกับการจัดลำดับการพัฒนา 3PCD ภายใต้สัญญาผูกมัด 3PCD จะขึ้นอยู่กับข้อกังวลในการแข่งขันของ CMA ที่ได้รับการแก้ไข
Google Ad Manager	Google Ad Manager ปฏิเสธที่จะเปิดเผยแพลตฟอร์ม API ซึ่งทำให้การทดสอบเป็นเรื่องยาก	คำตอบจาก Google Ad Manager: เหตุผลที่อธิบายไว้ในการตอบกลับนี้โดย Google Ad Manager แผนของ Google Ad Manager สำหรับการผสานรวม Protected Audience API ไม่ได้รวมการรองรับเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาของ Google โดยไม่มีการควบคุมการประมูลระดับบนสุด
Google Ad Manager	Google Ad Manager มีราคาพื้นลับเฉพาะที่เปิดเผยต่อ SSP ของ AdX หรือ SSP การเสนอราคาแบบเปิดเท่านั้น	เอกสารประกอบสาธารณะของ Google Ad Manager ระบุว่าผู้ชนะการประมูลตามบริบทจะส่งไปยังตรรกะการให้คะแนนระดับบนสุด ไม่ใช่ไปยังการประมูลที่เป็นส่วนประกอบ ซึ่งรวมถึง AdX หรือการเสนอราคาแบบเปิด นอกจากนี้ เอกสารยังกล่าวถึงตรรกะการให้คะแนนระดับบนสุดว่า "Ad Manager จะเปรียบเทียบราคาเสนอที่ชนะของการประมูลคอมโพเนนต์แต่ละครั้ง ซึ่งรวมถึงการประมูลคอมโพเนนต์ของ Ad Manager สำหรับราคาเสนอตามกลุ่มความสนใจของผู้ซื้อ รวมทั้งโฆษณาตามบริบทที่ดีที่สุด (ซึ่งเลือกผ่านการจัดสรรแบบไดนามิก) และแสดงโฆษณาที่มีราคาเสนอสูงสุด"
Google Ad Manager	ผลิตภัณฑ์ Google Ads ควรอยู่ภายใต้กฎเดียวกันกับผลิตภัณฑ์โฆษณาของบุคคลที่สาม	ผลิตภัณฑ์ Google Ads อยู่ภายใต้กฎเดียวกันกับบุคคลที่สามอยู่แล้ว
การทดสอบที่อำนวยความสะดวกโดย Chrome	เพิ่มป้ายกำกับสำหรับเบราว์เซอร์ที่ไม่อยู่ใน A หรือ B	เรายังไม่ได้พิจารณาที่จะทำเช่นนั้น เนื่องจากการตรวจสอบของเราพบว่าการเพิ่มป้ายกำกับที่ไม่ใช่การทดสอบอาจก่อให้เกิดปัญหาความเป็นส่วนตัวเกี่ยวกับการเข้าชมในโหมดไม่ระบุตัวตน
เอเจนซีโฆษณา	เอเจนซีหรือบริษัทที่ไม่มี JavaScript ในเว็บไซต์จะใช้ Privacy Sandbox API ได้ไหม	ทุกคนจะเรียกใช้ Privacy Sandbox API ได้ หากเอเจนซีหรือใครก็ตาม ต้องการสร้างเทคโนโลยีโดยตรงบน API พวกเขาก็ทำได้ API ฝั่งไคลเอ็นต์ต้องผสานรวมกับไคลเอ็นต์เช่นเดียวกับคุกกี้ API จํานวนมาก เช่น คุกกี้ มีอินเทอร์เฟซส่วนหัว HTTP ด้วย เราได้เห็นเฟรมเวิร์กของอุตสาหกรรมโฆษณาไปแล้วที่ชื่อ Prebid ซึ่งสร้างการผสานรวมฝั่งไคลเอ็นต์กับ API ได้ องค์กรอื่นๆ ก็ทำได้เช่นกัน
โซลูชันฝั่งไคลเอ็นต์	เหตุใด Google จึงใช้โซลูชันฝั่งไคลเอ็นต์สำหรับ Privacy Sandbox ในเมื่อวิศวกรคนหนึ่งเคยแสดงความกังวลเกี่ยวกับความสามารถในการปรับขนาดของโซลูชันดังกล่าวในปี 2012	เทคโนโลยีการเพิ่มประสิทธิภาพด้านความเป็นส่วนตัว (PET) ในสาขาวิชาได้พัฒนาขึ้นอย่างมากตั้งแต่ปี 2012 และใช้แอปพลิเคชันที่ใช้ได้จริงในเชิงพาณิชย์ หัวใจสำคัญของ Privacy Sandbox คือการผสมผสานระหว่าง PET ซึ่งไม่สามารถทำได้มานานกว่า 10 ปีมาแล้ว นอกจากนี้ ประสิทธิภาพการประมวลผลส่วนบุคคลก็เพิ่มขึ้น เช่นเดียวกับความคาดหวังของผู้บริโภคเกี่ยวกับเบราว์เซอร์ และความคาดหวังด้านกฎระเบียบที่มีต่อความเป็นส่วนตัว
แมชชีนเลิร์นนิง	แผนการใช้ Privacy Sandbox ของ Google สำหรับวัตถุประสงค์ด้านแมชชีนเลิร์นนิงคืออะไร	ระบบนิเวศของเทคโนโลยีโฆษณาส่วนใหญ่นั้นใช้แมชชีนเลิร์นนิงในปัจจุบัน และเราไม่คิดว่าสิ่งนี้จะเปลี่ยนแปลงไป Privacy Sandbox ไม่ได้ป้องกันบริษัทเทคโนโลยีโฆษณาหรือบุคคลอื่นใดในการใช้แมชชีนเลิร์นนิงต่อไป และ Privacy Sandbox ไม่ได้กำหนดให้บริษัทที่ผสานรวมกับ API ของตนใช้แมชชีนเลิร์นนิง เป็นเรื่องปกติที่จะคาดหวังว่าบริษัทต่างๆ จะสร้างผลิตภัณฑ์และบริการต่อไปในวิธีที่ตอบสนองความต้องการของลูกค้า ไม่ว่าจะรวมไปถึงแมชชีนเลิร์นนิงหรือไม่ก็ตาม แมชชีนเลิร์นนิงที่ผู้ผสานการทำงาน Privacy Sandbox สร้างขึ้นจะเป็นที่รู้จักในหมู่เครื่องมือเหล่านี้อย่างชัดเจน ข้อมูลเหล่านี้จึงไม่ถูกบดบัง
การยืนยันข้อมูล	บริษัทต่างๆ จะยืนยันได้อย่างไรว่าข้อมูลที่ตนได้รับจากการใช้ Privacy Sandbox นั้นถูกต้องและ Google ยินดีได้รับการตรวจสอบผ่านหน่วยงานอย่าง Media Rating Council (MRC) หรือไม่	Privacy Sandbox API สร้างไว้ในแพลตฟอร์มโอเพนซอร์สที่ขับเคลื่อน Chrome ส่วนต่างๆ ของ API ที่มีไว้เพื่อเรียกใช้ในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้เป็นแบบโอเพนซอร์สและตรวจสอบได้ ผู้ที่ต้องการตรวจสอบโค้ดสามารถ รวมถึง MRC ได้
(รายงานในไตรมาสที่แล้วด้วย) การสนับสนุนด้านการผลิต	Chrome มีกระบวนการใดบ้างในการสนับสนุนปัญหาทางเทคนิคและการส่งต่อปัญหา ของ Privacy Sandbox ที่ส่งผลต่อระบบนิเวศ	Google มีช่องทางที่หลากหลายเพื่อให้เทคโนโลยีโฆษณารายงานปัญหาทางเทคนิคและส่งต่อเรื่องที่จำเป็นเพื่อแก้ไขปัญหาดังกล่าวได้ นอกจากนี้ Chrome ยังคาดว่าจะสร้างและขยายกระบวนการเพิ่มเติมเพื่อแก้ไขปัญหาทางเทคนิคและการส่งต่อปัญหาที่ส่งผลกระทบต่อระบบนิเวศของระบบนิเวศ Chrome มุ่งมั่นที่จะสร้างทรัพยากร ที่หลากหลายสำหรับความพยายามนี้ โปรดอ่านโพสต์สำหรับนักพัฒนาซอฟต์แวร์เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับฟอรัมสาธารณะและส่วนตัวสำหรับความคิดเห็นและการส่งต่อ
โหมดการทดสอบที่อำนวยความสะดวกโดย Chrome	ดูข้อมูลเพิ่มเติมเกี่ยวกับลำดับเวลาและการติดตั้งใช้งานที่แน่นอนสำหรับโหมดการทดสอบที่ Chrome รองรับ	เราได้แชร์บล็อกโพสต์เกี่ยวกับโหมดการทดสอบต่างๆ และกำลังดำเนินการเพื่อแชร์ข้อมูลเพิ่มเติมเร็วๆ นี้ เรายินดีรับฟังคำแนะนำเกี่ยวกับขนาดของป้ายกำกับโหมดทดสอบ
การผสานรวมกับมาตรฐานอุตสาหกรรมอื่นๆ	Privacy Sandbox API จะเชื่อมต่อกับ TCF เวอร์ชัน 2.* และโหมดความยินยอมทั้งคู่หรือไม่	เราไม่มีแผนที่จะผสานรวม Privacy Sandbox API กับ TCF เวอร์ชัน 2 หรือโหมดความยินยอมโดยตรง อย่างไรก็ตาม บริษัทและกลุ่มการค้าในอุตสาหกรรมยินดีปรับผลิตภัณฑ์และเฟรมเวิร์กให้ทำงานร่วมกับ Privacy Sandbox API ได้ ตัวอย่างเช่น สำหรับเฟรมเวิร์กอย่าง TCF ผู้เข้าร่วมแต่ละคนต้องกำหนดแนวทางการปฏิบัติตามข้อกำหนดของตนเองโดยอิงตามสัญญาณ TCF ที่ได้รับและนโยบาย TCF ที่เกี่ยวข้อง เราคาดหวังให้บริษัทต่างๆ กำหนดเวลาและวิธีใช้ฟังก์ชันการทำงานต่างๆ ที่ Privacy Sandbox ของเรานำเสนอ

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ข้อจำกัด	ขั้นตอนการลงทะเบียนหมายความว่า Google เลือกได้ว่าจะให้บริษัทใดในระบบนิเวศได้รับอนุญาตให้ใช้ Privacy Sandbox API	ขั้นตอนการลงทะเบียนและเอกสารรับรองพื้นฐานจะต้องมีการยืนยันเอนทิตี (เช่น นิติบุคคลมีหมายเลข DUN สามารถระบุลิงก์ไปยังนโยบายความเป็นส่วนตัว เป็นต้น) และทำให้เอกสารรับรองสาธารณะเป็นข้อกำหนดสำหรับการเรียก API เอนทิตีที่ดำเนินการตามข้อกำหนดการลงทะเบียนได้สำเร็จจะได้รับการตรวจสอบ สำหรับบริษัทที่ไม่มี DUN เราจะจัดให้มีกระบวนการเร่งด่วนโดยไม่คิดค่าใช้จ่ายกับ Dun & Bradstreet เพื่อเข้าซื้อกิจการ วัตถุประสงค์คือการปรับปรุงการคุ้มครองความเป็นส่วนตัวของ API (ตามมาตรการที่เพิ่งกล่าวไป) และเพิ่มความโปร่งใสอีกชั้นให้กับ Privacy Sandbox API เพื่อให้ผู้ที่สนใจจะเข้าใจได้ดีขึ้นว่าใครกำลังใช้ API ใดอยู่ และการรับรองใดที่ตนกำลังสร้าง เรายินดีรับฟังความคิดเห็นเพิ่มเติมในอุตสาหกรรมเกี่ยวกับปัญหานี้ ซึ่งได้นำมาใช้เพื่อกำหนดกระบวนการแล้ว
ค่าใช้จ่ายในการลงทะเบียนซ้ำ	ไฟล์เอกสารรับรองจะหมดอายุทุก 12 เดือนและกำหนดให้เว็บไซต์ลงทะเบียนอีกครั้ง	เราได้รับฟังความคิดเห็นจากระบบนิเวศและแก้ไข แนวทางของเราอย่างต่อเนื่อง ซึ่งหมายความว่าไฟล์จะไม่หมดอายุหลังจากผ่านไป 12 เดือนหรือตามระยะเวลาที่กำหนดอีกต่อไป เรากำลังอัปเดตคู่มือการลงทะเบียน สำหรับนักพัฒนาซอฟต์แวร์ให้มีบริบทเพิ่มเติม
ไฟล์เอกสารรับรอง	มีการใช้ไฟล์เอกสารรับรองอย่างไร	บริษัททุกแห่งที่เรียกใช้ API ความเกี่ยวข้องและการวัดผลจะต้องอัปโหลดไฟล์เอกสารรับรองในเว็บไซต์ของบริษัทและเก็บไว้แสดงต่อสาธารณะตราบใดที่คุณตั้งใจที่จะเรียกใช้ API ต่อไป เว็บไซต์คาดว่าจะมีคำขอประมาณ 1 รายการต่อชั่วโมงจาก Privacy Sandbox และเอนทิตีอื่นๆ ที่อาจค้นหาได้เช่นกัน โดยใช้กลไกของระบบการลงทะเบียนเองเพื่อค้นหาเซิร์ฟเวอร์ของเอนทิตีที่ลงทะเบียนและตรวจสอบว่าไฟล์เอกสารรับรองถูกต้อง เอกสารรับรองจะรวมอยู่ในรายงานเพื่อความโปร่งใสและบุคคลทั่วไปมองเห็นได้ เราคาดหวังให้บริษัทต่างๆ ดำเนินการตามเอกสารรับรองที่ระบุไว้ เช่นเดียวกับส่วนที่เหลือของระบบนิเวศและหน่วยงานกำกับดูแลที่เกี่ยวข้อง
การลงทะเบียน	การลงทะเบียนต่อเว็บไซต์หรือต่อต้นทาง	การลงทะเบียนอยู่ในระดับเว็บไซต์

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

หัวข้อ

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การแสดง	ข้อกังวลด้านประสิทธิภาพเกี่ยวกับผลกระทบจากอัตราการเลือกรับ Topics ในเขตเศรษฐกิจยุโรป	เราขอแนะนำให้ผู้มีส่วนเกี่ยวข้องติดต่อหน่วยงานคุ้มครองข้อมูลที่เกี่ยวข้องเกี่ยวกับปัญหานี้ เราแนะนำให้ตอบข้อกังวลดังกล่าวและโน้มน้าวว่าการใช้เทคโนโลยีที่เพิ่มประสิทธิภาพความเป็นส่วนตัวได้รับการกระตุ้นโดยกฎหมายหรือปฏิบัติเหมือนการติดตาม ซึ่งต้องใช้แนวทางเดียวกันในการให้ความยินยอม เนื่องจากอาจทำให้ API อย่างเช่นใน Privacy Sandbox ใช้งานไม่ได้บ่อยนัก
การลงทะเบียน	ผู้เสนอราคาดาวน์สตรีมต้องลงทะเบียนใน Topics API เพื่อใช้ Topics Signals จาก SSP ต้นทางไหม	รีซีฟเวอร์ดาวน์สตรีมของหัวข้อที่นอกเหนือจากตัวเรียกใช้ Topics API เริ่มต้นนั้นไม่จำเป็นต้องลงทะเบียน แต่จำนวนมากมีแนวโน้มที่จะได้รับการลงทะเบียนเพื่อใช้งาน API อื่นๆ รายชื่อผู้ลงทะเบียน Privacy Sandbox จะได้รับแบบเป็นโปรแกรมโดยเป็นส่วนหนึ่งของความพยายามในการสร้างความโปร่งใสของโปรแกรม ซึ่งจะช่วยให้ผู้เรียกใช้ Topics API ที่สนใจสามารถตรวจสอบได้ว่าผู้รับที่ตนส่งหัวข้อไปลงทะเบียนหรือไม่ หากผู้โทรต้องการ
การกรองหัวข้อ	ขอให้ใช้ตัวกรองของผู้โทรรายอื่นกับหัวข้อที่เรียกดูในหน้า เพื่อแชร์เฉพาะสิ่งที่ผู้ซื้อมีสิทธิ์เรียกดู	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การยกเว้นเว็บไซต์	ยกเว้นเว็บไซต์ไม่ให้มีส่วนร่วมในหัวข้อของผู้ใช้	จะไม่มีการเรียกหัวข้อโดยค่าเริ่มต้น โปรดทราบว่าระบบจะไม่พิจารณาเนื้อหาของหน้าเมื่อเลือกหัวข้อ และระบบจะดูแลจัดการทุกหัวข้อเพื่อให้ไม่มีความละเอียดอ่อน นอกจากนี้ เว็บไซต์ยังจํากัดเว็บไซต์ของตนไม่ให้รวมอยู่ในการคำนวณหัวข้อผ่านส่วนหัวของนโยบายสิทธิ์ต่อไปนี้ได้ด้วย Permissions-Policy: browsing-topics=()
การสังเกตการณ์หัวข้อ	อนุญาตให้ผู้เผยแพร่โฆษณาให้สิทธิ์แก่ Chrome ในการจัดประเภทหัวข้อตามเนื้อหาในหน้า (เช่น ส่วนหัวหรือร่างกาย)	ก่อนหน้านี้เราพิจารณาการเสนอฟังก์ชันการทำงานในการจัดประเภทเว็บไซต์เป็นหัวข้อต่างๆ ตามเนื้อหาหน้าเว็บ และตัดสินใจที่จะไม่ดำเนินการต่อตามข้อกังวลเกี่ยวกับความเป็นส่วนตัวและความปลอดภัย ข้อเสนอนี้อาจช่วยลดข้อกังวลเหล่านั้นได้แต่ยังไม่ชัดเจนว่าในขอบเขตใด เนื่องด้วยระยะเวลาการทดสอบ CMA ที่กำลังจะเกิดขึ้น เราคาดว่าการเปลี่ยนแปลงนี้จะไม่ได้เกิดขึ้นก่อน 3PCD เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่
การสังเกตการณ์หัวข้อ	ระบุนโยบายสิทธิ์ที่ละเอียดยิ่งขึ้นให้กับผู้เผยแพร่โฆษณา	การแสดงนโยบายสิทธิ์ที่ละเอียดขึ้นแก่ผู้เผยแพร่โฆษณาจะทำให้เว็บไซต์ของผู้เผยแพร่โฆษณาส่งผลเสียต่อประโยชน์ของ Topics API สำหรับระบบนิเวศโดยรวมได้ โดยไม่ส่งผลเสียต่อประโยชน์ของ Topics API สำหรับตัวเว็บไซต์เอง โปรดอ่านนโยบายสิทธิ์การอัปเดตเพื่อรองรับสิทธิ์แยกต่างหากสำหรับการดึงและสังเกตปัญหาของ GitHub เพื่อดูการพูดคุยในหัวข้อดังกล่าวโดยละเอียด
หัวข้อทางการแพทย์และสุขภาพ	เหตุใดการจัดหมวดหมู่ Topics จึงไม่ครอบคลุมหัวข้อในหมวดหมู่การแพทย์หรือสุขภาพ	หมวดหมู่การแพทย์และสุขภาพถือเป็นหัวข้อที่ละเอียดอ่อนและ ไม่รวมอยู่ในการจัดหมวดหมู่ Topics
การดึงข้อมูลหัวข้อ	วิธีที่ DSP รับ Topics ได้เร็วขึ้นโดยไม่ต้องดึงข้อมูลโดยใช้ส่วนหัว	เมธอดของส่วนหัวมีประสิทธิภาพมากกว่าและต้นทุนต่ำกว่าการสร้าง iframe แบบข้ามต้นทางและทำการเรียก document.browsingTopics() จาก iframe นี้ (ต้องใช้ iframe แบบข้ามต้นทางสำหรับการเรียก เนื่องจากบริบทระดับบนสุดในการดูหัวข้อต้องตรงกับบริบทที่หัวข้อที่มีการเข้าถึง) มีการอภิปรายเกี่ยวกับเรื่องนี้โดยละเอียดที่นี่
การดึงข้อมูลหัวข้อ	คำขอเพื่อสนับสนุนการส่ง Topics ผ่านส่วนหัวในคำขอแท็กสคริปต์แบบข้ามต้นทาง	ในแง่ความปลอดภัย เป็นไปไม่ได้ เอกสารแต่ละรายการและสภาพแวดล้อมการดำเนินการเอกสารนั้นจะเชื่อมโยงกับต้นทางเดียวของเอกสารนั้น ทรัพยากรย่อยของบุคคลที่สามที่โหลดและดำเนินการภายในสภาพแวดล้อมเดียวกันนั้นจะถือว่าเป็นเจ้าของโดยต้นทางของเอกสาร ซึ่งเป็นการป้องกันการรั่วไหลของข้อมูลที่ไม่ได้รับความยินยอมจากต้นทางหนึ่งไปยังอีกต้นทาง อีกวิธีหนึ่งคือการระบุแอตทริบิวต์ browsingTopics ในแท็ก <script> ข้อมูลนี้ควรปลอดภัยในแง่ของความปลอดภัย และไม่ทำให้เวลาในการตอบสนองเพิ่มขึ้น เรายินดีรับฟัง ความคิดเห็นจากผู้ที่มีความสนใจ
การรับรู้	เพิ่มการรับรู้เกี่ยวกับ Topics API ของสาธารณชนและวิธีใช้ API	โดยเราได้ติดต่อกับผู้มีส่วนเกี่ยวข้องที่แสดงความคิดเห็นนี้และปัญหานี้ได้รับการแก้ไขแล้วใน GitHub จากนี้ไป เราจะสนับสนุนความเข้าใจในระบบนิเวศของ API ต่อไป และหวังเป็นอย่างยิ่งว่าจะได้รับความคิดเห็นจากผู้มีส่วนเกี่ยวข้อง ในระหว่างนี้ เราขอแนะนำให้ผู้มีส่วนเกี่ยวข้องต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับ Topics API ให้ทำความคุ้นเคยกับเอกสารในคู่มือนักพัฒนาซอฟต์แวร์ Chrome
การแจ้งเตือน	การแจ้งเตือนเพื่อแจ้งให้ผู้ใช้ทราบเมื่อเว็บไซต์มีการเฝ้าสังเกต Topics ของผู้ใช้	เราได้จัดการความคิดเห็นนี้เกี่ยวกับ GitHub ผู้ใช้สามารถดูข้อมูลเพิ่มเติมเกี่ยวกับการควบคุมหัวข้อได้ในศูนย์ช่วยเหลือของ Chrome
แมชชีนเลิร์นนิง	ใช้ ML ในการอนุมาน Topics ของผู้ใช้ได้อย่างไร	เรากำลังพูดคุยเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติม
ความมีประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ	บริษัทเทคโนโลยีโฆษณาขนาดเล็กอาจไม่สามารถดู Topics ได้เนื่องจากวิธีที่เบราว์เซอร์คำนวณ	เฉพาะเทคโนโลยีโฆษณาที่สังเกตเห็นว่าผู้ใช้เข้าชมหน้าเว็บเกี่ยวกับหัวข้อที่เป็นปัญหาภายใน 3 สัปดาห์ที่ผ่านมาเท่านั้นที่จะได้รับหัวข้อดังกล่าว หากเทคโนโลยีโฆษณาไม่ได้เรียกใช้ API ในช่วง 3 สัปดาห์ที่ผ่านมาสำหรับผู้ใช้รายนั้นในเว็บไซต์เกี่ยวกับหัวข้อนั้น ค่าที่แสดงผลจะว่างเปล่า ฟีเจอร์นี้หมายความว่าเทคโนโลยีโฆษณาที่มีเจ้าของเว็บไซต์จำนวนมากใช้บริการดังกล่าว จึงทำให้มีโอกาสสังเกตการเข้าชมเว็บไซต์ของผู้ใช้คนดังกล่าวมากกว่า อาจได้รับหัวข้อมากกว่าเทคโนโลยีโฆษณาอื่นๆ ฟีเจอร์นี้จำเป็นต่อการคุ้มครองความเป็นส่วนตัวของ API เนื่องจากจะจำกัดข้อมูลเกี่ยวกับผู้ใช้ให้เข้าถึงได้เฉพาะผู้ที่สังเกตข้อมูลเดียวกันนี้ได้อยู่แล้ว (ปัจจุบันคือผ่านคุกกี้ของบุคคลที่สาม)
คำขอ XHR	Topics ที่รวมไว้ในคำขอ XMLHttpRequest (XHR) จะเลิกใช้งานเมื่อใด	ตามที่ Chrome ได้ประกาศไปเมื่อเดือนสิงหาคม 2023 ว่า Chrome เริ่มหยุดรองรับ XHR เมื่อเปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไป เมื่อมีการเริ่มพัฒนา Topics มากขึ้น การสนับสนุน XHR จะรวมเฉพาะผู้ใช้ที่เปิดใช้ฟีเจอร์ OT ให้เท่านั้นและเลิกใช้งานโดยสมบูรณ์เมื่อรวมกลุ่มทดสอบ OT แต่ละกลุ่ม หากคุณใช้ Topics กับ XHR เว็บไซต์จะไม่ขัดข้อง ระบบจะไม่เพิ่มหัวข้อเท่านั้นในส่วนหัวของคำขอ XHR เราขอแนะนำให้คุณเปลี่ยนไปใช้ fetch สำหรับคำขอ ใช้แอตทริบิวต์ iframe หรือใช้ JavaScript API เพื่อเรียกข้อมูลหัวข้อ โปรแกรม Googlebot จำลองรองรับเบราว์เซอร์ใหม่ๆ ทั้งหมด แต่ไม่ใช่ Internet Explorer หรือ Opera Mini
กระบวนการอัปเดตการจัดหมวดหมู่และตัวแยกประเภท	ข้อมูลเพิ่มเติมเกี่ยวกับรอบการเผยแพร่การจัดหมวดหมู่และตัวแยกประเภท Topics และวิธีที่บริษัทเตรียมความพร้อมสำหรับการอัปเดตดังกล่าว	ผลตอบรับของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่ 2 ตามที่ได้แจ้งไว้ในบล็อกโพสต์ล่าสุด เราคาดว่าการจัดหมวดหมู่จะมีการเปลี่ยนแปลงอยู่ตลอดเวลา และการกำกับดูแลของการจัดหมวดหมู่จะมีการเปลี่ยนเป็นบุคคลภายนอกที่เป็นตัวแทนของผู้มีส่วนเกี่ยวข้องจากทั่วทั้งอุตสาหกรรมในท้ายที่สุด นอกจากนี้ เรายังได้แชร์แผนการเพิ่มจำนวนในกลุ่มประกาศตามหัวข้อด้วย
การละเมิด	การโจมตีที่อาจเกิดขึ้นผ่านห่วงโซ่การเปลี่ยนเส้นทาง	เรากำลังพิจารณาปัญหานี้ และยินดีรับฟังความคิดเห็นเพิ่มเติม
ประเภทพื้นที่โฆษณาของผู้เผยแพร่โฆษณา	พื้นที่โฆษณาของผู้เผยแพร่โฆษณาประเภทใดจะรองรับการทดสอบของ Protected Audience และ Topics	ทั้ง Protected Audience และ Topics ไม่ได้มีข้อจำกัดในเรื่องของประเภทพื้นที่โฆษณาที่ใช้งานได้
เวลาในการเพิ่มจำนวน	แนะนำว่าอย่าอยู่ในช่วงเร่งปริมาณสำหรับการจัดหมวดหมู่ใหม่ให้ถึง 100%	เราได้ประกาศแผนการเปิดตัวการจัดหมวดหมู่ใหม่ตามคำขอความคิดเห็นนี้จากระบบนิเวศและการพูดคุยระหว่างการประชุมของ PATCG

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การประมูลระดับบนสุด	ใช้เซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาของ Google ได้โดยไม่ต้องให้ Google Ad Manager ควบคุมการประมูล Protected Audience API ระดับบนสุด	คำตอบจาก Google Ad Manager: แผนของ Google Ad Manager สำหรับ Protected Audience API ไม่ได้รวมการรองรับเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาของ Google โดยไม่มีการควบคุมการประมูล Protected Audience ระดับบนสุดด้วยเหตุผลต่อไปนี้ เซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาของ Google ต้องรักษาการควบคุมการประมูลของ Protected Audience ระดับบนสุดไว้เพื่อให้บริการลูกค้าในตลาดการแสดงโฆษณาของผู้เผยแพร่โฆษณาได้อย่างเหมาะสม ในฐานะเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา บทบาทของเราคือให้การคาดการณ์แก่ผู้เผยแพร่โฆษณา เพื่อให้สามารถเจรจาต่อรองเกี่ยวกับแคมเปญแบบขายตรงโดยไม่ต้องจองมากกว่าจำนวนที่มี การดำเนินการนี้จะต้องมีการประมูลครั้งสุดท้าย เพื่อเปรียบเทียบความต้องการทั้งทางตรงและทางอ้อมที่มีสิทธิ์ทั้งหมด การคาดการณ์และการกำหนดอัตราการแสดงโฆษณาเป็นฟังก์ชันหลักที่ผู้เผยแพร่โฆษณาคาดหวังจากเซิร์ฟเวอร์โฆษณา หากไม่มีการคาดการณ์ที่แม่นยำ ผู้เผยแพร่โฆษณาอาจขายพื้นที่โฆษณามากเกินไปจนทำให้เกิดความเสี่ยงต่อชื่อเสียงทางธุรกิจ ความเร็วในการดำเนินการก็มีความสำคัญเช่นกัน เพราะการไม่สามารถปฏิบัติตามสัญญาการจองกับผู้ลงโฆษณายังมีความเสี่ยงต่อความสัมพันธ์โดยตรงระหว่างผู้เผยแพร่โฆษณากับผู้ลงโฆษณาด้วย ซึ่งอาจส่งผลกระทบสำคัญต่อธุรกิจของผู้เผยแพร่โฆษณา โดยสรุปแล้ว เราจะไม่เห็นว่ากิจกรรมที่คุณทำกับเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาเรื่องการประมูลกลุ่มเป้าหมายระดับบนสุดนั้นแตกต่างจากกิจกรรมอื่นๆ ในเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา
directFrom SellerSignals	directFrom SellerSignals ทำให้ Google Ad Manager ป้องกันไม่ให้ผู้เผยแพร่โฆษณาเห็นราคาการประมูลตามบริบทของตน	การตอบสนองของ Chrome: ข้อมูลที่ส่งผ่านไปยัง runAdAuction() ไม่อาจมาจากผู้ขาย เว้นแต่ผู้ขายจะเรียกใช้ runAdAuction() จาก iframe ของตนเอง ในการประมูลผู้ขายหลายราย ผู้ขายทุกรายจะสร้างเฟรมที่เรียกใช้ runAdAuction() ไม่ได้ directFromSellerSignals แก้ไขปัญหานี้ด้วยการโหลดเนื้อหาจากแพ็กเกจทรัพยากรย่อย ซึ่งโหลดจากต้นทางของผู้ขาย ซึ่งช่วยให้มั่นใจว่าข้อเท็จจริงและความสมบูรณ์ของข้อมูลที่ส่งเข้าร่วมการประมูลจากการกำหนดค่าของผู้ขายและการประมูลนั้นไม่สามารถจัดการได้ หากผู้เผยแพร่โฆษณาต้องการใช้ Protected Audience API เพื่อทำความเข้าใจข้อมูลใดๆ ที่ผู้ให้บริการเทคโนโลยีของตนกำลังส่งเข้าร่วมการประมูลสำหรับ Protected Audience ผู้เผยแพร่โฆษณาสามารถถามผู้ให้บริการเทคโนโลยีดังกล่าวเกี่ยวกับฟังก์ชันการทำงานได้ คำตอบจาก Google Ad Manager: เราให้ความสำคัญกับความเป็นธรรมในการประมูลมาตลอดหลายปี รวมถึงสัญญาว่าจะไม่มีการแชร์ราคาจากแหล่งที่มาของโฆษณาที่ไม่มีการรับประกันของผู้เผยแพร่โฆษณา ซึ่งรวมถึงราคารายการโฆษณาที่ไม่รับประกันการแสดงผล กับผู้ซื้อรายอื่นก่อนที่จะเสนอราคาในการประมูล ซึ่งจากนั้นเราจะยืนยันอีกครั้งในสัญญาผูกมัดกับหน่วยงานการแข่งขันของฝรั่งเศส สำหรับการประมูลสำหรับ Protected Audience เราตั้งใจที่จะรักษาสัญญาของเราโดยใช้ประโยชน์จาก directFromSellerSignals และจะไม่แชร์ราคาเสนอของผู้มีส่วนร่วมในการประมูลกับผู้เข้าร่วมการประมูลรายอื่นๆ ก่อนที่การประมูลในการประมูลจะมีผู้ขายหลายรายจะเสร็จสมบูรณ์ ขออธิบายให้ชัดเจนว่าเราจะไม่แชร์ราคาของการประมูลตามบริบทกับการประมูลคอมโพเนนต์ของเราเอง ตามที่อธิบายไว้ในการอัปเดตเพิ่มเติมเกี่ยวกับการเปลี่ยนแปลงแบบไดนามิกของการประมูลระดับบนสุด
การเปิดเผยข้อมูล	เบราว์เซอร์อาจเปิดเผยตรรกะทางธุรกิจและรายละเอียดสัญญาที่มีความละเอียดอ่อน	คนที่ใช้เว็บเบราว์เซอร์จะเห็นทุกอย่างที่เกิดขึ้นในเบราว์เซอร์ เมื่อการประมูลเพื่อแสดงโฆษณาเกิดขึ้นภายในเบราว์เซอร์ บุคคลที่เบราว์เซอร์นั้นจะดูการประมูลนั้นเกิดขึ้นได้ รวมถึงการดูว่าฝ่ายต่างๆ เลือกเสนอราคาเท่าใด เนื่องจากเบราว์เซอร์เป็นตัวแทนของผู้ใช้ เราคิดว่าไม่สามารถทำได้ หรือไม่ควรพยายามเปลี่ยนแปลงเรื่องนี้ อย่างไรก็ตาม มีเพียงผู้ที่ใช้เบราว์เซอร์เท่านั้นที่จะเห็นการดำเนินการเหล่านี้ การประมูลในอุปกรณ์ซึ่งทำงานโดยใช้ Protected Audience API จะสังเกตไม่ได้ในเซิร์ฟเวอร์ใดๆ รวมถึงของ Google ด้วย
PerBuyerExperiment GroupId	ช่วงค่าปัจจุบันของ PerBuyerExperiment GroupId อาจช่วยให้ผู้ซื้อเชื่อมโยงข้อมูลตามบริบทกับคำขอของเซิร์ฟเวอร์ที่เชื่อถือได้	การใช้ Protected Audience API ด้วยวิธีนี้ไม่สอดคล้องกับเอกสารรับรองบังคับของ Privacy Sandbox ที่ว่าผู้ใช้ API จะไม่พยายามหลีกเลี่ยงการปกป้อง Privacy Sandbox ในอนาคต การกำหนดให้เซิร์ฟเวอร์คีย์-ค่าทำงานในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) จะให้การป้องกันทางเทคนิคจากการโจมตีนี้
นโยบายต้นทางเดียวกัน	ลดความเข้มงวดของนโยบายต้นทางเดียวกันเพื่ออนุญาตโดเมนย่อย	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การกำหนดเวอร์ชัน API	คำขอเวอร์ชันและบันทึกประจำรุ่นสำหรับการเปลี่ยนแปลงใน Protected Audience API	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
การประมูล Multi-SSP	อนุญาตให้สัญญาณการประมูลระดับบนสุดดำเนินการผสาน JSON กับสัญญาณคอมโพเนนต์ auctionSignals	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
ขีดจำกัดราคาเสนอ	เพิ่มขีดจำกัดจำนวนองค์ประกอบโฆษณาที่ป้อนราคาเสนอจาก 20 เป็น 40	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับเหตุผลที่สิ่งนี้จะเป็นประโยชน์
(รายงานในไตรมาสก่อนหน้าด้วย) ประสิทธิภาพของการประมูลสำหรับกลุ่มเป้าหมายที่มีการป้องกัน	รายงานจากผู้ทดสอบว่าการประมูลสำหรับกลุ่มเป้าหมายที่มีการป้องกันมีเวลาในการตอบสนองสูง	ในส่วนของคำถามเกี่ยวกับเวลาในการตอบสนอง โดยทั่วไปแล้ว Protected Audience API ได้ดำเนินการตามกระบวนทัศน์มาตรฐานที่มีอยู่ในการควบคุมการสร้าง โดยให้ผู้ขายกำหนดเวลาและทรัพยากรที่ผู้เสนอราคาจะใช้ได้ รวมถึงสร้างเครื่องมือที่ช่วยให้ผู้ซื้อตัดสินใจได้ว่าจะใช้ทรัพยากรที่มีอยู่อย่างไรให้เกิดประโยชน์สูงสุด โดยทั่วไปแล้วการควบคุมและเครื่องมือเหล่านี้มีให้ใช้ในปัจจุบัน แต่ประโยชน์ต่างๆ ทั้งหมดของเครื่องมือนี้จะเริ่มต้นขึ้นก็ต่อเมื่อผู้ซื้อและผู้ขายนำมาใช้งานเท่านั้น นอกจากนี้ Chrome จะยังคงทำงานเพื่อปรับปรุงโครงสร้างพื้นฐานในด้านต่างๆ เพื่อปรับปรุงความเร็วในการประมูล (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323) เราขอเชิญให้ความคิดเห็นเกี่ยวกับทั้ง 2 ด้านเกี่ยวกับเวลาในการตอบสนองนี้ ซึ่งได้แก่ เครื่องมือใหม่ๆ ที่ผู้ซื้อและผู้ขายพบว่ามีประโยชน์ และรายงานปัญหาคอขวดที่พบซึ่งวิศวกร Chrome ควรตรวจสอบ
การกรองฝั่งซื้อ	เพิ่มการรองรับการกรองฝั่งซื้อตามกลุ่มความสนใจ	เราได้แนะนำวิธีต่างๆ ที่ SSP และ DSP ควรปรับเปลี่ยนการออกแบบเพื่อจัดการกับสถานการณ์นี้ ย้ายงานบางส่วนไปยังเซิร์ฟเวอร์คีย์/ค่าของ DSP SSP สร้างสัญญาณบริบทบางอย่างและมอบสัญญาณเหล่านั้นแก่ DSP SSP ที่แคชสัญญาณบริบทสำหรับ DSP
การควบคุมกลุ่มความสนใจของผู้เผยแพร่โฆษณา	การสนับสนุนสำหรับผู้เผยแพร่โฆษณาที่ต้องการมอบสิทธิ์การใช้กลุ่มความสนใจที่ผู้เผยแพร่โฆษณาสร้างขึ้น	ทั้งนี้เราได้ร่วมหารือกับหลายฝ่ายเกี่ยวกับคำขอดังกล่าว เราเชื่อว่ากรณีการใช้งานดังกล่าวทั้งหมดที่เกี่ยวข้องกับ "การมอบสิทธิ์" กลุ่มความสนใจที่ผู้เผยแพร่โฆษณาสร้างขึ้นนั้นรองรับได้ในตอนนี้ และเรายังควรสร้างการสนับสนุนเพิ่มเติมเพื่อให้กรณีการใช้งานบางกรณีดำเนินไปอย่างราบรื่นยิ่งขึ้นในอนาคต
(มีการรายงานในไตรมาสที่ 2) สภาพแวดล้อมการดำเนินการที่เชื่อถือได้	การสนับสนุนสำหรับ Trusted Execution Environments (TEE) ในสภาพแวดล้อมระบบคลาวด์ที่ไม่ใช่สาธารณะ	การตอบสนองของเราคล้ายกับไตรมาสที่แล้ว ในขณะที่เรากำลังสำรวจการสนับสนุนสำหรับตัวเลือกที่นอกเหนือจากโซลูชันสาธารณะในระบบคลาวด์ ยังไม่มีแผนที่จะรองรับ TEE ภายในองค์กรในขณะนี้ จากขั้นนี้ เมื่อพิจารณาจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และความท้าทายสำคัญที่ได้รับจากการติดตั้งใช้งานภายในองค์กร เราเชื่อว่าการขยายและปรับปรุงการทำให้ใช้งานได้บนระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ Google Cloud เพิ่มเติมจาก AWS) จะมีประโยชน์ต่อระบบนิเวศมากที่สุด อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมว่า เหตุใดข้อกำหนดดังกล่าวจึงจำเป็นและเป็นไปได้เนื่องจากมีข้อจำกัดด้านความเป็นส่วนตัวและความปลอดภัย
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้	คอมโพเนนต์ในเส้นทางการแสดงโฆษณา TEE เช่น ตัวจัดสรรภาระงาน จะสังเกตเห็นการเข้าชมทั้งหมดและมีข้อมูลเกี่ยวกับที่อยู่ IP ของคำขอแต่ละรายการ	ปัจจุบันที่อยู่ IP จะส่งผ่านเป็นข้อมูลเมตาในส่วนหัวของคำขอไปยังบริการโฆษณาของผู้ขายที่ไม่น่าเชื่อถือในกรณีที่เป็นทั้งการเสนอราคาและการประมูล และการประมูลสำหรับกลุ่มเป้าหมายที่มีการป้องกันในอุปกรณ์ โปรดดูข้อมูลเพิ่มเติมที่การส่งต่อข้อมูลเมตา ในระยะยาว เราวางแผนที่จะพร็อกซีการรับส่งข้อมูลเทคโนโลยีโฆษณาและเครื่องมือติดตามผ่านพร็อกซี IP ซึ่งจะป้องกันไม่ให้คอมโพเนนต์สังเกตการเข้าชมทั้งหมดในเส้นทางการแสดงผล
Time to Live (TTL)	จะมีการตั้งค่า Time to Live (TTL) ก่อนที่บริการจะต้องขอคีย์ใหม่ หรือต้องการให้มีความยืดหยุ่น (หรือไดนามิก) หรือไม่	โดยทั่วไป TTL เป็นแบบคงที่ ปัจจุบัน TTL สำหรับสาธารณะคือ 8 วันและการหมุนเวียนจะเกิดขึ้นทุก 7 วัน และ TTL จะเหมือนกันสำหรับคีย์ส่วนตัวในกรณีของบริการรวบรวม ในกรณีของบริการเสนอราคาและการประมูล ระบบจะดึงข้อมูลคีย์ส่วนตัวและคีย์สาธารณะทุก N ชั่วโมงในเส้นทางที่ไม่ได้ส่งคำขอและแคชไว้ในหน่วยความจำ เพื่อให้เกิดความล่าช้าไม่เกิน N ชั่วโมงระหว่างการหมุนเวียนคีย์และเซิร์ฟเวอร์ที่กำลังเก็บคีย์ดังกล่าว บัฟเฟอร์ 1 วันระหว่างการหมุนเวียนคีย์จนถึงวันหมดอายุเพื่อให้มั่นใจว่าบริการจะยังทำงานต่อไปแม้จะสร้างคีย์ไม่สำเร็จ เรากำลังพิจารณาขยาย TTL ให้มีความยืดหยุ่นมากขึ้นสำหรับการหยุดทำงาน ในกรณีที่มีการรั่วไหลของคีย์ เราวางแผนที่จะบังคับให้สร้างคีย์ด้วยตนเองและทำให้คีย์ใช้งานไม่ได้เร็วขึ้น โปรดทราบว่าคีย์สาธารณะจะแคชไว้บนไคลเอ็นต์เป็นเวลา 24 ชั่วโมงอีกครั้ง เพื่อให้มั่นใจว่าบริการจะยังทำงานได้ต่อในกรณีที่การประสานงานหยุดทำงาน
การกำหนดรูปแบบการเข้าชม	การรองรับการกำหนดรูปแบบการเข้าชมสำหรับบริการเสนอราคาและบริการประมูล	ผู้ซื้อสามารถระบุความต้องการในการประมูลของ Protected Audience โดยอ้างอิงตามข้อมูลจากบุคคลที่หนึ่งของผู้เผยแพร่โฆษณาหรือข้อมูลบริบท ผู้ขายสามารถดำเนินการพิจารณาในลักษณะเดียวกันสำหรับเซิร์ฟเวอร์โฆษณาของผู้ขายหรือเซิร์ฟเวอร์ Ad Exchange ได้เช่นกัน โดยโมเดลสามารถฝึกกับข้อมูลจากบุคคลที่หนึ่งและรายงานรวมจากการประมูลสำหรับกลุ่มเป้าหมายที่ได้รับการคุ้มครองได้ ผู้ขายสามารถใช้ข้อมูลนี้เพื่อหลีกเลี่ยงการส่งคำขอไปยังเซิร์ฟเวอร์การเสนอราคาและเซิร์ฟเวอร์การประมูลเมื่อไม่มีความต้องการเข้าร่วมการประมูลสำหรับกลุ่มเป้าหมายที่มีการป้องกัน เราเชื่อว่านี่จะเป็นวิธีที่มีประสิทธิภาพใน การกำหนดรูปแบบการเข้าชม
การประมูลคอมโพเนนต์	สัญญาณการประมูลระดับบนสุดใดบ้างที่แชร์กับผู้ขายคอมโพเนนต์	ผู้ซื้อในการประมูลคอมโพเนนต์จะได้รับสัญญาณจากผู้ขายคอมโพเนนต์เท่านั้น เราต้องการแชร์เอกสารประกอบเกี่ยวกับลำดับโดยรวมของการประมูลแบบรวมกับการเสนอราคาส่วนหัวและการประมูลสำหรับกลุ่มเป้าหมายที่มีการป้องกันเร็วๆ นี้
การแสดงผลวิดีโอ	รองรับการแสดงภาพวิดีโอโดยใช้ Protected Audience และ Fenced Frame	Protected Audience API รองรับการแสดงภาพวิดีโอโดยใช้กลไกที่อาศัย iframe อย่างไรก็ตาม เรายังไม่ได้ออกแบบโซลูชันที่เข้ากันได้กับ Fenced Frame และนี่คือเหตุผลหนึ่งที่เราตัดสินใจยกเลิกการบังคับใช้ Fenced Frames กลับไปเป็นปี 2026 ซึ่งหมายความว่าหากพาร์ทเนอร์ตัดสินใจบังคับใช้ Fenced Frames ตอนนี้ พาร์ทเนอร์รายนั้นจะขาดการสนับสนุนวิดีโอ
การกำหนดความถี่สูงสุด	(รายงานในไตรมาสที่แล้วด้วย) การควบคุมความถี่ต่อผู้ใช้ภายในแคมเปญและกลุ่มโฆษณา	การตอบสนองของเราจะไม่เปลี่ยนแปลงจากรายงานก่อนหน้า Protected Audience จะรองรับการกำหนดความถี่สูงสุดสำหรับการประมูลในอุปกรณ์และแคมเปญตามบริบทและการสร้างแบรนด์ด้วยเช่นกัน พื้นที่เก็บข้อมูลที่ใช้ร่วมกันและขีดจำกัดสูงสุดเฉพาะเว็บไซต์ยังใช้สำหรับการควบคุมการกำหนดความถี่สูงสุดเพิ่มเติมได้
ค่ากำหนดโฆษณา	Protected Audience มีวิธีในการเลือกไม่ใช้หรือรายการที่บล็อกโดยเว็บไซต์ของผู้ลงโฆษณา หรือวิธีออกจากกลุ่มความสนใจทั้งหมดจากเจ้าของรายเดียวกันหรือไม่	ผู้ใช้สามารถบล็อกการเข้าถึง Protected Audience API และฟีเจอร์อื่นๆ ของ Privacy Sandbox ได้หลายวิธี
นโยบายต้นทางเดียวกันสำหรับ URL แหล่งที่มาของการเสนอราคาและสคริปต์การประมูล	ลดข้อกำหนดที่ว่าทุกช่องที่ระบุ URL สำหรับสคริปต์การโหลดหรือ JSON ต้องเป็นต้นทางเดียวกับเจ้าของ	ขณะนี้เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
forDebuggingOnly	อาจมีการนำ forDebuggingOnly .reportAdAuctionWin ไปใช้ในทางที่ผิดหากยังคงใช้โพสต์ 3PCD อยู่	ตลอดหลายปีที่ผ่านมา เราได้รับความคิดเห็นจากระบบนิเวศเกี่ยวกับช่องโหว่ด้านฟังก์ชันการทำงานใน Protected Audience เมื่อเลิกใช้งานคุกกี้ของบุคคลที่สาม และเรากำลังวางแผนสำหรับการรองรับคุกกี้ของบุคคลที่สามหลังจากโพสต์ 3PCD โดยไม่กระทบต่อเป้าหมายของ Privacy Sandbox เรายินดีรับคำแนะนำและความคิดเห็นเพิ่มเติม เกี่ยวกับฟังก์ชันการทำงานที่ขาดหายไปซึ่งระบบนิเวศอยากเห็น
กลุ่มความสนใจหลายกลุ่ม	ใช้กลุ่มความสนใจหลายกลุ่มในราคาเสนอเดียวกัน	ปัจจุบัน Protected Audience API ยังไม่รองรับฟีเจอร์นี้ เนื่องจากจะส่งผลให้เกิดการเปลี่ยนแปลงโมเดลความเป็นส่วนตัวที่สำคัญ เรายินดีรับการสนทนาเพิ่มเติมที่นี่
การประมูลในอุปกรณ์	Chrome ใน Android รองรับการประมูลใน Protected Audience ในอุปกรณ์ไหม	ใช่ การประมูลในอุปกรณ์จะได้รับการสนับสนุนใน Chrome บน Android
(รายงานในไตรมาสที่ 2 ปี 2023) ข้อมูลที่เกี่ยวข้องกับการคลิก	เพิ่มข้อมูลเกี่ยวกับคลิกลงใน BrowserSignals	เราประเมินคำขอฟีเจอร์นี้อย่างต่อเนื่องและยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ควรให้ความสำคัญในส่วนนี้
ผู้ให้บริการสภาพแวดล้อมการดำเนินการที่เชื่อถือได้	ข้อเสนอสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ ของผู้ให้บริการระบบคลาวด์ต่างๆ แตกต่างกันอย่างมีนัยสำคัญหรือไม่	เราไม่ได้ทราบถึงความแตกต่างที่สําคัญใดๆ แต่แนะนําให้ระบบนิเวศตรวจสอบคู่มือการทําให้ใช้งานได้แบบสาธารณะเพื่อดูว่าโซลูชันใดเหมาะกับความต้องการของตนมากที่สุด Google Cloud AWS
(รายงานในไตรมาสที่แล้ว ) การสนับสนุนการกำหนดเป้าหมายกลุ่มความสนใจเชิงลบ	API ที่สนับสนุนการกำหนดเป้าหมายกลุ่มความสนใจเชิงลบ: แสดงโฆษณาเฉพาะในกรณีที่ผู้ใช้ไม่ได้อยู่ในกลุ่มความสนใจเท่านั้น	เรากำลังพิจารณาใช้ฟีเจอร์นี้และพูดคุยเกี่ยวกับคำขอ
การละเมิดเนื้อหา	รองรับฟีเจอร์ที่อนุญาตให้ผู้ใช้รายงานโฆษณาที่ไม่ดีที่แสดงโดย Protected Audience API ใน Fenced Frames	เราเชื่อว่า กลไกการรายงานโฆษณาเฟรมที่มีการปิดกั้นที่มีอยู่เป็นตัวเลือกที่ดีสำหรับเทคโนโลยีโฆษณาที่ต้องการขั้นตอนการรายงาน "โฆษณาไม่ดี" ที่ผู้ใช้สร้างขึ้น ซึ่งจะทำให้มีการรายงานโฆษณาที่ไม่ดีโดยพื้นฐานแล้วไม่เปลี่ยนไปจากมาตรฐานอุตสาหกรรมปัจจุบัน เรายินดีรับคำขอฟีเจอร์เพิ่มเติมหากยังมีช่องว่างอยู่ ซึ่งรวมถึงช่วงเวลาหลังจากการนำคุกกี้ของบุคคลที่สามออก แต่ก่อนที่การแสดงผล Fenced Frame จะแพร่กระจายในวงกว้าง
การรายงาน Private Aggregation API	เราจะคำนวณเวลาที่ผู้ใช้ใช้ไปกับกลุ่มความสนใจนั้นได้อย่างไร	ใน Chrome M116+ คุณควรสามารถใช้ความใหม่ได้ตามที่กำหนดไว้ pull/639
เซิร์ฟเวอร์ K-Anonymity	ข้อมูลเพิ่มเติมเกี่ยวกับเซิร์ฟเวอร์ K-Anonymity	เราได้แชร์ข้อมูลเพิ่มเติมเกี่ยวกับเซิร์ฟเวอร์ K-Anonymity ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม
URL โฆษณาแบบไดนามิก	รองรับ URL ของครีเอทีฟโฆษณาที่ไม่มีการประกาศล่วงหน้า ในขณะที่ยังคงเคารพ k-anonymity	เรากำลังหารือกันเกี่ยวกับคำขอฟีเจอร์นี้และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ควรให้ความสำคัญในส่วนนี้
ข้อกำหนดสำหรับ K-anonymity	จะมีการเปิดตัวข้อกำหนดเกี่ยวกับ K-anonymity เกี่ยวกับกลุ่มความสนใจอีกครั้งไหม	เราคาดว่าจะไม่มีการเปลี่ยนแปลงตําแหน่งที่ระบุไว้ในโพสต์ GitHub นี้ ตามที่ได้ประกาศไว้ในโพสต์นั้น เราตัดสินใจนำข้อกำหนดด้าน k-anonymity ออกจากการอัปเดตกลุ่มความสนใจใน Protected Audience ซึ่งไม่ได้ส่งผลกระทบอย่างมีนัยสำคัญต่อการคุ้มครองความเป็นส่วนตัวโดยรวมของ API และวางแผนที่จะพิจารณาการป้องกันอื่นๆ ที่เป็นไปได้โดยตรงมากกว่า (เช่น ความเป็นส่วนตัวของที่อยู่ IP หรือเซิร์ฟเวอร์การอัปเดตที่เชื่อถือได้) ในภายหลังเมื่อมีการพัฒนา ปรับใช้งาน และนำเทคโนโลยีที่เกี่ยวข้องมาใช้มากขึ้น
การทดสอบการเสนอราคาและบริการประมูลรุ่นเบต้า	การเสนอราคาและบริการประมูลรุ่นเบต้าจะเริ่มเมื่อใด	ตามที่ระบุไว้ในไทม์ไลน์และแผนกลยุทธ์ การทดสอบเฟสแรกของการเสนอราคาและบริการประมูลจะเริ่มในเดือนพฤศจิกายน 2023
แสดงร่วมกัน	คําขอสนับสนุนการประสานงานครีเอทีฟโฆษณาสําหรับเครือข่ายโฆษณา (SSP และ DSP อยู่ในบริษัทหรือพร็อพเพอร์ตี้เดียวกัน)	เราขอขอบคุณสำหรับความคิดเห็นสำหรับกรณีการใช้งานนี้ และเราต้องการทราบว่าผู้เชี่ยวชาญด้านโฆษณาสนใจเห็นการสนับสนุนนี้มากขึ้นหรือไม่ เรายินดีรับฟังความคิดเห็นเพิ่มเติม
โฆษณาเนทีฟ	การรองรับเฟรมที่มีการปิดกั้นสำหรับโฆษณาเนทีฟ	เรากำลังพิจารณาที่จะสนับสนุนกรณีการใช้งานดังกล่าวและพูดคุยกันเรื่องวิธีแก้ปัญหาเฉพาะหน้าและวิธีแก้ไขปัญหาที่เป็นไปได้
K-anonymity	ฉันจะเพิ่มโฆษณาตามกลุ่มความสนใจให้ตรงกับเกณฑ์ K-Anon ได้อย่างไร	เราได้แชร์คำแนะนำเชิงกลยุทธ์เกี่ยวกับหัวข้อนี้
การสนับสนุน POST	รองรับการส่งข้อมูลการประมูลผ่านคำขอ POST	เรากำลังประเมินคำขอฟีเจอร์นี้และยินดีรับการส่งปัญหา GitHub เพิ่มเติมเกี่ยวกับเหตุผลที่ควรจัดลำดับความสำคัญนี้
รายละเอียดของการรายงาน	การรายงานโฆษณาเฟรมที่มีการปิดกั้นด้วยโฆษณาที่ประกอบด้วยหลายชิ้นมีความละเอียดเท่าใด	การออกแบบปัจจุบันไม่อนุญาตให้จับภาพรหัสผลิตภัณฑ์หรือตำแหน่งเนื่องจากอาจละเมิดความเป็นส่วนตัวของผู้ใช้ สามารถเรียกใช้ reserved.top_navigation เท่านั้น ซึ่งจะส่งเมื่อมีการเปิดใช้งานผู้ใช้ (เช่น การคลิก) ในเฟรมที่มีการปิดกั้นของคอมโพเนนต์โฆษณา ซึ่งส่งผลให้เกิดการนำทางระดับบนสุด
การประมูลเพื่อแสดงโฆษณา	SSP ที่เข้าร่วมการประมูลคอมโพเนนต์ทำให้เกิดการประมูลคอมโพเนนต์อื่นได้ไหม	componentSeller ต้องไม่มี componentAuctions การประมูลที่มีผู้ขายหลายรายมีเพียง 2 ระดับเท่านั้น ดังนี้ 1. การประมูลคอมโพเนนต์พร้อมกัน 2. การประมูลระดับบนสุด (ที่โฆษณาที่ชนะจาก componentAuction แต่ละรายการแข่งขันกัน)
ความพร้อมให้บริการของการเสนอราคาและบริการประมูล	การเสนอราคาและการประมูลจะใช้งานได้ในช่วง การทดสอบที่อำนวยความสะดวกของ Chrome ไหม	การเสนอราคาและเซิร์ฟเวอร์การประมูลจะไม่สามารถใช้ได้ในระยะทดสอบที่อำนวยความสะดวกโดย Chrome
สัญญาณการเสนอราคา	อนุญาตให้เบราว์เซอร์ขอและลบสัญญาณการเสนอราคา	เรากำลังสนทนาเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ควรให้ความสำคัญในเรื่องนี้ก่อน
generateBid()	ความสามารถในการอัปเดต userBiddingSignals ของInterestGroup ถึง updateURL	เรากำลังพิจารณาข้อเสนอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมและการพูดคุย
ประเภทพื้นที่โฆษณาของผู้เผยแพร่โฆษณา	พื้นที่โฆษณาของผู้เผยแพร่โฆษณาประเภทใดที่จะรองรับ การทดสอบกลุ่มเป้าหมายที่มีการป้องกันและการทดสอบ TOPICS	ทั้ง Protected Audience และ Topics ไม่ได้มีข้อจำกัดในเรื่องของประเภทพื้นที่โฆษณาที่ใช้งานได้
การผสานรวมแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์	ต้องมีการผสานรวมโดยตรงระหว่าง SSP กับ DSP สำหรับกลุ่มเป้าหมายที่มีการป้องกันไหม	ไม่จำเป็นต้องใช้การผสานรวมโดยตรงระหว่าง SSP กับ DSP หาก DSP ไม่จำเป็นต้องประมวลผลสัญญาณบริบทในเซิร์ฟเวอร์ของตนเอง เพื่อส่งข้อมูลที่ประมวลผลแล้วไปยังฟังก์ชันการเสนอราคาในอุปกรณ์
ฟิลด์ bid_currency ใน B&A	รองรับช่อง bid_currency ในการเสนอราคาและบริการประมูล	B&A ยังไม่รองรับ bid_currency แต่เราวางแผนที่จะรองรับภายในสิ้นเดือนมกราคม 2024 โปรดดูไทม์ไลน์ที่นี่
perBuyerSignals	มีการจำกัดขนาด perBuyerSignals ไหม	ไม่มีขีดจำกัดสำหรับจำนวนสัญญาณต่อผู้ซื้อ แต่การส่งข้อมูลมากเกินไปอาจมีผลกระทบที่เป็นอันตรายต่อประสิทธิภาพของเบราว์เซอร์
กรณีการใช้งานแบบข้ามเว็บไซต์	เราจะใช้กลุ่มความสนใจของ Protected Audience API กับหลายๆ เว็บไซต์ได้ไหม	Protected Audience ไม่ได้ออกแบบมาสำหรับกรณีการใช้งานดังกล่าวตามที่อธิบายไว้ใน turtledove/issues/282
คำขอ HTTP ของกลุ่มความสนใจ	รวม Blob ของกลุ่มความสนใจในส่วนหัว HTTP	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับคำขอนี้
การควบคุมคุณภาพของโฆษณา	การสูญเสียการควบคุมคุณภาพโฆษณาที่เกี่ยวข้องกับข้อมูลข้ามเว็บไซต์	เรากำลังพิจารณาความคิดเห็นนี้และยินดีรับฟังความคิดเห็นเพิ่มเติม
เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome	คำขอของเครือข่าย Protected Audience ขาออกควรแสดงอยู่ในแท็บเครือข่ายเครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ Chrome	เรากำลังดำเนินการเปิดใช้ฟังก์ชันนี้ในแท็บเครือข่ายและยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ควรให้ความสำคัญในส่วนนี้
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้	เราจะเพิ่มรายละเอียดเกี่ยวกับเมตริกที่มีผลต่อความเป็นส่วนตัว (และระดับของเมตริกเหล่านั้น) ไว้ในคำอธิบายเกี่ยวกับการตรวจสอบสภาพแวดล้อมการดำเนินการที่เชื่อถือได้เมื่อใด	ขณะนี้เรากำลังดำเนินการอัปเดตคำอธิบายด้วย ข้อมูลนี้ คำอธิบายที่อัปเดตจะพร้อมใช้งานภายในเดือนพฤศจิกายน 2023
directFrom SellerSignals	เหตุใด directFrom SellerSignals จึงไม่จัดแพ็กเกจเป็น Web Bundle	โดยเราได้แจ้งเหตุผลของการตัดสินใจนี้ที่นี่
การมอบสิทธิ์การแสดงผล	มีวิธีที่ใช้ได้จริงสำหรับการมอบสิทธิ์การแสดงผล หากผลลัพธ์ของกลุ่มความสนใจที่ได้รับเลือกเป็นการกำหนดเป้าหมายอีกแบบหนึ่งหรือไม่	การประมูลที่ซ้อนกันอยู่หลายแห่งจะไม่สอดคล้องกับเป้าหมาย ความเป็นส่วนตัวของเราด้วยเหตุผล 2 ข้อ อย่างแรก เมื่อผู้ชนะการประมูลแสดงผลภายในเฟรมที่มีการปิดกั้น เป้าหมายด้านความเป็นส่วนตัวของเราสำหรับ Protected Audience จะรวมการแสดงผลครีเอทีฟโฆษณาที่ไม่ทราบบริบท เช่น URL ของหน้าที่ล้อมรอบหรือคุกกี้ของบุคคลที่หนึ่งเป็นการละเมิดความเป็นส่วนตัว ในสภาพแวดล้อมดังกล่าว คุณจะไม่สามารถประมูลแบบซ้อนได้ รูปแบบที่ 2 รูปแบบกลุ่มเป้าหมายที่มีการป้องกันจะระบุว่าผู้ชนะการประมูลแต่ละครั้งควรอิงตามข้อมูลจากเว็บไซต์เพิ่มเติมเพียง 1 เว็บไซต์ การประมูลแบบซ้อนกันจะเป็นวิธีหนึ่งในการรวมกลุ่มกัน ส่งผลให้มีโอกาสเลือกโฆษณาตามโปรไฟล์หลายเว็บไซต์ได้
ข้อมูลที่เกณฑ์ส่วนที่เหลือ	อธิบายเพิ่มเติมเกี่ยวกับเกณฑ์ "ข้อมูล" ที่เกณฑ์ "พัก" ในรูปแบบ Service Trunk ของคีย์/ค่า	ข้อมูลในบริการคีย์-ค่าจะถูกโหลดลงในหน่วยความจำและแสดงผลจากที่นั่นแทนการแคชแบบอ่านผ่าน
สัญญาณข้อมูลของผู้ซื้อ	มีการจำกัดขนาดสัญญาณ buyer_data ที่ได้รับจาก DSP ไว้ไหม	ขณะนี้ยังไม่มีขีดจำกัดที่เบราว์เซอร์กำหนดไว้สำหรับสัญญาณ buyer_data ที่ได้รับจาก DSP

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

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
หลายอุปกรณ์	วางแผนการรองรับหลายอุปกรณ์สำหรับ Attribution Reporting API	หลายอุปกรณ์มีความท้าทายใหม่ๆ ด้านความเป็นส่วนตัวมากกว่า 3PC และยังเพิ่มปัญหาด้านการเผยแพร่เทคโนโลยีตามอุปกรณ์และแพลตฟอร์มหลากหลายที่ผู้ใช้อาจใช้ เรากำลังสำรวจโซลูชันที่เป็นไปได้ แต่มุ่งเน้นที่ Use Case สำคัญที่ Attribution Reporting รองรับในปัจจุบัน และไม่มีแผนที่จะเปิดตัวการสนับสนุนแบบหลายอุปกรณ์ก่อนที่จะนำคุกกี้ของบุคคลที่สามออก
(รายงานในไตรมาสที่แล้วด้วย) ขนาดข้อมูลทริกเกอร์	เหตุใดข้อมูลทริกเกอร์จึงจำกัดไว้ที่ 3 บิต	ขนาดจะจำกัดอยู่ที่ 3 บิตและค่าที่แตกต่างกัน 8 ค่าเพื่อให้มั่นใจว่าปริมาณข้อมูลแบบข้ามเว็บไซต์และข้ามบริบทเกี่ยวกับผู้ใช้มีจํากัด เรายินดีให้ผู้เล่นในระบบนิเวศส่งความคิดเห็นว่าพารามิเตอร์ปัจจุบันสำหรับการรายงานระดับเหตุการณ์นั้นเพียงพอหรือไม่
Conversion Funnel	รายงานหลายโดเมนที่ใช้ใน Conversion	กรณีการใช้งานนี้เป็นไปได้เนื่องจากมีการเพิ่มปลายทางหลายแห่ง เรายินดีรับความคิดเห็นเพิ่มเติม
โดเมนเดียวกันในประเทศต่างๆ สนับสนุน	การรายงานการระบุแหล่งที่มาทำงานร่วมกับเว็บไซต์ที่มีโดเมนเดียวกัน แต่มี TLD หลายประเทศได้ไหม	ปัญหานี้ได้มีการพูดคุยและแก้ปัญหาร่วมกับผู้มีส่วนเกี่ยวข้องที่ตั้งคำถามแล้ว ถ้าเทคโนโลยีโฆษณาจำเป็นต้องใช้ TLD ของหลายประเทศ ก็จะต้องมีการลงทะเบียนหลายรายการ โดยมี 1 รายการสำหรับ TLD ของแต่ละประเทศ
Protected Audience and Attribution Reporting	เทคโนโลยีโฆษณาสามารถเข้าถึงทั้ง Conversion การดูผ่านสำหรับการประมูลสำหรับกลุ่มเป้าหมายที่มีการป้องกัน และ Conversion การคลิกผ่านสำหรับการรายงานการระบุแหล่งที่มาไหม	ใช่ Privacy Sandbox ควรรองรับทั้ง VTC และ CTC ภายใน Protected Audience
ความล่าช้าของรายงานที่รวบรวมได้	ลดความล่าช้าของรายงานแบบรวมได้มากขึ้น	เราได้รับความคิดเห็นล่าสุดเกี่ยวกับเรื่องนี้และได้แชร์ไอเดียที่นี่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ
ความล่าช้าของรายงานที่รวบรวมได้	ลดความล่าช้าด้วยการแนะนำสื่อกลางของเซิร์ฟเวอร์	เรากำลังพิจารณาข้อเสนอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติม
ความล่าช้าของรายงานระดับเหตุการณ์	ลดความล่าช้าของรายงานระดับเหตุการณ์	ข้อเสนอระดับเหตุการณ์ที่ยืดหยุ่นทั้งหมดซึ่งอธิบายไว้ในการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นช่วยลดความล่าช้าของการรายงานระดับเหตุการณ์ลงได้ถึง 1 ชั่วโมงด้วยการตัดเสียงรบกวน
ต้นทางการรายงานแหล่งที่มาต่อแหล่งที่มา	ข้อจำกัดสูงสุดของต้นทางการรายงานแหล่งที่มาต่อเว็บไซต์การรายงานแหล่งที่มาป้องกันไม่ให้เทคโนโลยีโฆษณาลงทะเบียนแหล่งที่มาจากต้นทางการรายงานที่แตกต่างกันสำหรับต้นทางของผู้เผยแพร่โฆษณาแห่งเดียว	เราได้หารือกับผู้มีส่วนเกี่ยวข้องที่แจ้งปัญหานี้แล้ว และกำลังมีการทดสอบโซลูชันที่เป็นไปได้ในการใช้ต้นทางการรายงาน 1 รายการต่อเว็บไซต์ที่รายงานแหล่งที่มา ก่อนที่จะลองใช้วิธีแก้ปัญหาอื่นๆ ที่เป็นไปได้ซึ่งเกี่ยวข้องกับการเปลี่ยนเส้นทาง เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับขีดจำกัดนี้จากระบบนิเวศ
การรายงานปัญหา	เราจะรายงานข้อผิดพลาดหรือปัญหาเกี่ยวกับ Attribution Reporting API ให้ Chrome ทราบได้อย่างไร	ในตอนนี้ เราขอแนะนำให้เทคโนโลยีโฆษณารายงานข้อผิดพลาดของ Attribution Reporting API ที่อาจพบเป็นปัญหาใน GitHub หากพวกเขาประสบปัญหาเกี่ยวกับ Chrome เราขอแนะนำให้สร้างข้อบกพร่องของ Chromium คุณจะดูลิงก์เกี่ยวกับวิธีและตำแหน่งในการรายงานปัญหาได้ในมีส่วนร่วมและแชร์ความคิดเห็น
การนำออกข้อมูลซ้ำซ้อน	เราจะกรอง Conversion ที่ซ้ำกันออกจากไปป์ไลน์และอุปกรณ์ต่างๆ ได้อย่างไร	การกรองที่ซ้ำกันในอุปกรณ์ต่างๆ และไปป์ไลน์การวัดผลเป็นความท้าทายอย่างหนึ่งที่เทคโนโลยีโฆษณาต้องเผชิญในปัจจุบันเมื่อใช้ 3PC Attribution Reporting API ช่วยให้เทคโนโลยีโฆษณาเลือกได้ว่าจะลงทะเบียน Conversion เฉพาะเมื่อใด และเพิ่มข้อมูลเมตาที่ต้องการเพื่อระบุไปป์ไลน์การวัดผลที่ใช้ติดตาม Conversion (กล่าวคือเป็นส่วนหนึ่งของคีย์การรวม) ซึ่งสามารถเปรียบเทียบกับไปป์ไลน์การวัดผลอื่นๆ ได้ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับระบบนิเวศนี้
การกรองข้อมูลที่ซ้ำกันออกและลำดับความสำคัญ	ขอให้เพิ่มลำดับความสำคัญก่อนการกรองข้อมูลที่ซ้ำกันออก	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติม
ป้องกันการประพฤติมิชอบ	ความเสี่ยงที่ผู้ใช้ที่เป็นอันตรายจะแทรกแซงข้อมูลระดับเหตุการณ์	การยืนยันรายงานใช้ไม่ได้กับการรายงานระดับเหตุการณ์สําหรับเหตุผลที่อธิบายไว้ในเหตุใดรายงานระดับเหตุการณ์นี้จึงไม่รองรับ
ประเภท Conversion	เราจะแยกความแตกต่างระหว่างการดูผ่านและการนำทางในการรายงานการระบุแหล่งที่มาได้อย่างไร	เรามีตัวเลือกการกรองในตัวดังต่อไปนี้: source_type ดูรายละเอียดเพิ่มเติมได้ที่นี่

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

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

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
URL ของ Blob	คำขอสนับสนุน Blob URL ในพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน	เพิ่มการรองรับ URL ของ Blob ใน Chrome M116 แล้ว

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

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
JavaScript API	ความพร้อมใช้งาน JavaScript API ของ User Agent Client Hints	เราไม่มีแผนที่จะนำฟังก์ชันการทำงานนี้ออก เนื่องจากเป็นโซลูชันหลักสำหรับพาร์ทเนอร์ที่ต้องการเข้าถึงข้อมูลเอนโทรปีสูงอย่างกระตือรือร้น นอกเหนือไปจากข้อมูลที่มีอยู่โดยค่าเริ่มต้นใน UA ที่หยุดนิ่งและลดลง
ข้อมูลอุปกรณ์และฟอร์มแฟกเตอร์	ความสามารถสำหรับเว็บไซต์ในการทำความเข้าใจอินพุต เอาต์พุต และข้อมูลอื่นๆ ที่อุปกรณ์ซึ่งเข้าชมเว็บไซต์สามารถรองรับ	เราได้เพิ่มการสนับสนุนสำหรับคำขอนี้ตามความคิดเห็นจากระบบนิเวศ

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การเข้าชมของบุคคลที่สามที่มีสิทธิ์	"การเข้าชมของบุคคลที่สามที่มีสิทธิ์" หมายถึงอะไรในเครื่องมืออธิบาย	เราเข้าใจถึงความสำคัญของคำถามนี้ และกำลังดำเนินการอย่างเต็มที่เพื่อระบุว่าการเข้าชมใดของบุคคลที่สามจะมีสิทธิ์และใดไม่มีสิทธิ์ เรายินดีรับฟังความคิดเห็นเกี่ยวกับหัวข้อนี้
การตรวจสอบการจราจรของข้อมูลในเครือข่าย	การสนับสนุนสำหรับองค์กรในการตรวจสอบการจราจรของข้อมูลในเครือข่าย	เฉพาะการเข้าชมของบุคคลที่สามที่ฝังอยู่ในเว็บไซต์จากบุคคลที่หนึ่งเท่านั้นที่จะได้รับผลกระทบ ซึ่งควรจำกัดปริมาณการเข้าชมที่ต้องกรอง นอกจากนี้ เราวางแผนที่จะให้ผู้ใช้เลือกได้ว่าจะใช้การป้องกัน IP หรือไม่ ส่วน Chrome ที่ควบคุมโดยองค์กรจะมีนโยบายระดับองค์กรที่จะปิดใช้การป้องกัน IP สุดท้ายนี้เราจะมาสำรวจว่าจะมีการควบคุมใดบ้าง (หากมี) ที่โอเปอเรเตอร์เครือข่ายจะปิดใช้การป้องกัน IP เรายินดีรับฟังความคิดเห็น เกี่ยวกับหัวข้อนี้
การควบคุมการเข้าถึง	การปกป้อง IP อาจส่งผลต่อบริการเว็บที่ใช้ที่อยู่ IP เพื่อควบคุมการเข้าถึง	เราเข้าใจถึงความสำคัญของกรณีการใช้งานเพื่อป้องกันการฉ้อโกงและผลกระทบที่อาจเกิดขึ้นกับกรณีการใช้งานดังกล่าว เราต้องการความคิดเห็นเกี่ยวกับระบบนิเวศเพื่อที่เราจะสามารถให้การสนับสนุนที่ดียิ่งขึ้นสำหรับ Use Case ต่อต้านการประพฤติมิชอบ ซึ่งมักจะต้องใช้ที่อยู่ IP
การสื่อสารระหว่างพร็อกซี 2-Hop	วิธีตรวจสอบว่าไม่มีข้อมูลระหว่างพร็อกซี	เรากำลังออกแบบการโต้ตอบกับพร็อกซี เป้าหมายของเราคือลดโอกาสในการแชร์ข้อมูลดังกล่าวผ่านธุรกิจ กระบวนการ และวิธีการทางเทคนิค
การตรวจสอบสิทธิ์ที่ไม่ใช่ของ Google	การสนับสนุนสำหรับการตรวจสอบสิทธิ์ที่ไม่ใช่ของ Google	เราวางแผนที่จะเผยแพร่รายละเอียดเพิ่มเติมเกี่ยวกับการตรวจสอบสิทธิ์บัญชีในอนาคต แต่เราได้แชร์ข้อควรพิจารณาเบื้องต้นบางประการแล้ว
การแยกประเภทเครื่องมือติดตาม	การป้องกัน IP จะกำหนดองค์ประกอบของเครื่องมือติดตามและตัวแปรของการติดตามอย่างไร	เราเข้าใจถึงความสำคัญของคำถามนี้ และกำลังดำเนินการอย่างเต็มที่เพื่อระบุว่าการเข้าชมใดของบุคคลที่สามจะมีสิทธิ์และใดไม่มีสิทธิ์ เรายินดีรับฟังความคิดเห็นเกี่ยวกับหัวข้อนี้
Analytics	การป้องกัน IP อาจส่งผลต่อความแม่นยำของบริการข้อมูลวิเคราะห์	เราต้องการทำความเข้าใจผลกระทบของการป้องกัน IP เพิ่มเติมและยินดีรับฟังความคิดเห็นและตัวอย่างเพิ่มเติมจากระบบนิเวศ
พร็อกซี	หากผู้ใช้ใช้พร็อกซีหรือกำหนดพร็อกซีด้วยตนเอง IP Mask จะทำงานอย่างไรในกรณีนี้	เราต้องการทำความเข้าใจผลกระทบที่การปกป้อง IP อาจมีต่อพร็อกซีอื่นๆ เราไม่มีแผนที่จะแชร์ในตอนนี้ เรายินดีรับฟังความคิดเห็นเกี่ยวกับหัวข้อนี้
ข้อเสนอแบบพรีเมียม	การป้องกัน IP จะเป็นฟีเจอร์แบบชำระเงินไหม	การปกป้อง IP จะมีให้บริการสำหรับผู้ใช้ Chrome ซึ่งเป็นส่วนหนึ่งของประสบการณ์การใช้งานหลักของเบราว์เซอร์ ซึ่งไม่ใช่ฟีเจอร์แบบชำระเงิน
พร็อกซีเซิร์ฟเวอร์	จะมีการใช้พร็อกซีเซิร์ฟเวอร์เดียวกันระหว่างเซสชันของผู้ใช้หรือไม่	การเชื่อมต่อ HTTP/S จะใช้พร็อกซีคู่เดียวและนำเสนอที่อยู่ IP ที่มาสก์เดียวไปยังต้นทาง นอกจากนี้ ไม่มีข้อจำกัดถาวรในการเชื่อมต่อ HTTP/S ที่ต่างกันและต้องใช้เซิร์ฟเวอร์เดียวกัน
การรองรับแพลตฟอร์ม	การป้องกัน IP จะได้รับการสนับสนุนในแพลตฟอร์มใด	การป้องกัน IP จะเริ่มมีให้บริการใน Chrome สำหรับ Android และเดสก์ท็อปในช่วงแรก เรายังคงประเมินวิธีขยายการป้องกันไปยังแพลตฟอร์มอื่นๆ ต่อไป
เลือกไม่รับ	ผู้ใช้จะปิดใช้การป้องกัน IP ได้ไหม	เราวางแผนที่จะให้ผู้ใช้เลือกได้ว่าจะใช้การป้องกัน IP หรือไม่
การลบข้อมูลระบุตัวบุคคล	คำขอประเภทใดบ้างที่จะไม่มีการระบุชื่อภายใต้การป้องกัน IP	คำขอ HTTP/S และ DNS ที่ส่งไปยังโดเมนของบุคคลที่สามที่มีสิทธิ์จะมีการลบข้อมูลระบุตัวบุคคลผ่านพร็อกซีความเป็นส่วนตัว เราจะให้รายละเอียดเพิ่มเติมในคำอธิบายต่อไปเกี่ยวกับวิธีพิจารณาเลือกโดเมนที่จะใช้ การรับส่งข้อมูลที่เหลือ (เช่น คำขอ DNS ที่เหลือหรือการรับส่งข้อมูล HTTP/S อื่นๆ) จะไม่ได้รับผลกระทบ
ระดับการเข้าถึงข้อมูล	อาจมีการเข้าถึงที่อยู่เครือข่ายระหว่างการ Hop แรกในการป้องกัน IP	ในโมเดลพร็อกซีแบบ 2 ฮอพ ฮอพแรก (ควบคุมโดย Google) จะเห็นเฉพาะ IP ไคลเอ็นต์ต้นทางและคำขอเพื่อเชื่อมต่อกับฮอพที่ 2 ขณะที่ฮอพที่ 2 (ควบคุมโดย CDN ภายนอก) จะเห็นเฉพาะ Tuple ในฮอพแรก (พอร์ต IP ของพร็อกซี) และ IP ปลายทาง สำหรับการตอบสนองจากต้นทาง ฮอพที่ 2 จะส่งต่อการตอบกลับไปยังพอร์ต พร็อกซี+ฮอพแรกที่เชื่อมโยงกับคำขอได้ และไม่จำเป็นต้องเรียนรู้อะไรเกี่ยวกับ IP ของไคลเอ็นต์เดิม (และฮอพแรกจะแค่แสดงการตอบกลับไปยังไคลเอ็นต์โดยไม่ต้องรู้อะไรเกี่ยวกับ IP ปลายทางเลย) วิธีนี้จะทำให้ ฮอพแรกเรียนรู้เฉพาะ IP ไคลเอ็นต์และฮอพที่ 2 ส่วนฮอพที่ 2 จะเรียนรู้เฉพาะ IP ปลายทาง
WebView	การป้องกัน IP จะใช้งานกับ Android WebView ในอนาคตได้ไหม	เรายังไม่มีแผนที่จะแจ้งให้ทราบในขณะนี้ แต่วิสัยทัศน์ของเราคือให้การป้องกันนี้ในวงกว้างที่สุดเท่าที่จะเป็นไปได้

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การติดตามการโต้ตอบ	มีการติดตามการโต้ตอบของผู้ใช้อย่างไร	การลดการติดตามการเข้าออกจะติดตามการโต้ตอบของผู้ใช้ 2 ประเภทดังนี้ การเปิดใช้งานของผู้ใช้ตามที่กำหนดไว้ในข้อกำหนด HTML ซึ่งได้แก่ การคลิก การกดแป้น การแตะหน้าจอสัมผัส ฯลฯ การยืนยัน webauth สำเร็จ ซึ่งก็คือกรณีที่ผู้ใช้แตะคีย์ความปลอดภัยหรือใช้พาสคีย์เป็นรูปแบบการตรวจสอบสิทธิ์ การโต้ตอบเหล่านี้จะเชื่อมโยงกับเว็บไซต์ระดับบนสุดในหน้าเว็บที่เกิดขึ้น เช่น หากผู้ใช้คลิกใน iframe ที่ฝังไว้ การโต้ตอบจะเชื่อมโยงกับเว็บไซต์ระดับบนสุด ไม่ใช่เว็บไซต์ที่ฝัง ระบบจะเก็บการโต้ตอบไว้ในฐานข้อมูลที่มี etld+1 แบบไม่มีกำหนด และเวลาที่ทำการโต้ตอบ การโต้ตอบจะปกป้องโดเมนที่เกี่ยวข้องจากการลบสถานะการลดการติดตามการเข้าออกเป็นเวลา 45 วัน
การยกเว้นในรายการที่อนุญาต	ฉันยกเว้นโดเมนได้ไหม	เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นจากระบบนิเวศเพิ่มเติม

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

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

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

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
แนวทางแบบรวมศูนย์	ข้อกังวลเกี่ยวกับแนวทางที่เก็บแบบรวมศูนย์สำหรับการจัดการชุดเว็บไซต์ที่เกี่ยวข้อง	ที่เก็บแบบสาธารณะที่เข้าถึงได้ง่ายคือกุญแจสำคัญในการออกแบบ RWS เนื่องจากทำให้ต้องส่งมุมมองที่จำเป็น ท้ายที่สุดแล้วฟังก์ชันการทำงานของคุกกี้ของบุคคลที่สามจะมาจากการใช้ Storage Access API หรือ rSAFor API ขณะที่การเป็นสมาชิก RWS ที่ให้สิทธิ์โดยอัตโนมัติ (แทนที่จะเข้าถึงผ่านทางพรอมต์ด้วย Storage Access API) เราเชื่อว่ากระบวนการส่ง RWS เป็นข้อกำหนดที่เหมาะสมสำหรับการเข้าถึงคุกกี้ของบุคคลที่สามที่ได้รับอนุญาตโดยอัตโนมัติ
กำลังเปลี่ยนชื่อไฟล์ JSON	ในการเปลี่ยนชื่อ API คุณต้องเปลี่ยนชื่อไฟล์ JSON ที่โฮสต์ไหม	ใช่ หลักเกณฑ์การส่งมีการเปลี่ยนแปลง และโดเมนหลักจะต้องแสดงไฟล์ JSON ที่ /.well-known/related-website-set.json ไม่จำเป็นต้องเปลี่ยนชุดที่มีอยู่ในรายการ RWS แต่หากมีการส่งการแก้ไขไปยังชุดที่มีอยู่ ก็จะต้องเปลี่ยนไฟล์ JSON
(รายงานในไตรมาสที่แล้วด้วย) ขีดจำกัดโดเมน	คำขอขยายจำนวนโดเมนที่เชื่อมโยง	ตามที่ได้ประกาศในบล็อกโพสต์เมื่อวันที่ 31 สิงหาคม เราได้เพิ่มขีดจำกัดโดเมนที่เกี่ยวข้องเป็น 5 โดเมน ตามความคิดเห็นจากระบบนิเวศ เราได้ตัดสินใจที่จะเพิ่มขีดจำกัดโดเมนที่เกี่ยวข้องเป็น 5 โดเมน (บวกด้วยโดเมนหลัก 1 โดเมน) ซึ่งตรงกับการใช้งานที่มีการเปรียบเทียบมากที่สุดที่เบราว์เซอร์หลักอื่นนำเสนอ
คุกกี้ของบุคคลที่สาม	ชุดเว็บไซต์ที่เกี่ยวข้องจะทํางานร่วมกับคุกกี้ของบุคคลที่สามเท่านั้นไหม	ชุดเว็บไซต์ที่เกี่ยวข้องจะใช้ได้แม้ว่าผู้ใช้ไม่ได้บล็อกคุกกี้ของบุคคลที่สาม แต่จะไม่มีผลที่สังเกตได้ เนื่องจากคุกกี้ที่เกี่ยวข้องพร้อมใช้งานโดยไม่จำเป็นต้องใช้ชุดเว็บไซต์ที่เกี่ยวข้องและ API การเข้าถึงพื้นที่เก็บข้อมูล
การแก้ไขโดยชอบธรรม	ที่เก็บชุดเว็บไซต์ที่เกี่ยวข้องจะป้องกันไม่ให้ผู้ที่ไม่ใช่เจ้าของแก้ไขชุดได้อย่างไร	ตามคู่มือการส่ง ทุกคนสามารถส่ง PR ใน GitHub เพื่อแก้ไขไฟล์ first_party_sets.JSON ได้ อย่างไรก็ตาม หาก PR ได้รับอนุมัติ (ผ่านการตรวจสอบทางเทคนิค ฯลฯ) Google จะผสานรวมเป็นกลุ่มกับรายการ FPS มาตรฐาน 1 ครั้งต่อสัปดาห์ (วันอังคารเวลา 12:00 น. เวลาตะวันออก) หากมีผู้ไม่ประสงค์ดีพยายามแก้ไขชุดวิดีโอที่ไม่ได้เป็นเจ้าของ ก็ไม่น่าจะมีปัญหาใดๆ เนื่องจากผู้ไม่ประสงค์ดีจะไม่สามารถแก้ไขไฟล์ .well-known ได้ ซึ่งจะทำให้การตรวจสอบไม่สำเร็จ
การลักลอบใช้โดเมน	การลักลอบใช้โดเมนอาจเปิดเผยข้อมูลโดเมนที่เกี่ยวข้องแก่บุคคลที่ไม่ได้รับอนุญาต	ซึ่งเป็นไปไม่ได้ ตามที่อธิบายไว้ในปัญหา GitHub สำหรับ Protected Audience นี้

Fenced Frames API

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

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

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ข้ามโดเมน	อนุญาตให้สื่อสารข้ามโดเมนสำหรับพื้นที่เก็บข้อมูลในเครื่อง	ปัจจุบันกรณีการใช้งานนี้ไม่เป็นไปตามประตูเอาต์พุตที่รักษาความเป็นส่วนตัวของพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน แต่เราก็ยินดีรับบริบทเพิ่มเติมในระหว่างที่เรากำลังพัฒนาข้อเสนอสำหรับพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชัน
URL ของ Blob	คำขอสนับสนุน Blob URL ในพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน	เพิ่มการรองรับ URL ของ Blob ใน Chrome M116 แล้ว

ชิป

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

FedCM

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
คุกกี้ของบุคคลที่สาม	ปัจจุบัน FedCM ปิดใช้งานอยู่หรือไม่หากผู้ใช้เปิดใช้ "บล็อกคุกกี้ของบุคคลที่สาม" ในการตั้งค่า Chrome	ใช่ ตอนนี้ FedCM ปิดใช้อยู่ สำหรับการทดสอบ เราขอแนะนำให้คุณเปิดใช้ chrome://flags/#fedcm- without-third-party-cookies เพิ่มเติม เรากำลังมองหาวิธีรองรับ FedCM โดยไม่ใช้คุกกี้ของบุคคลที่สามในอนาคต

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

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

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