รายงานรายไตรมาสสำหรับไตรมาสที่ 3 ปี 2023 ซึ่งสรุปความคิดเห็นที่ได้รับเกี่ยวกับข้อเสนอ Privacy Sandbox และคำตอบของ Chrome จากระบบนิเวศ
Google ตกลงที่จะเผยแพร่รายงานรายไตรมาสเกี่ยวกับกระบวนการมีส่วนร่วมของผู้มีส่วนเกี่ยวข้องสำหรับข้อเสนอ Privacy Sandbox ของตนต่อสาธารณะ (ดูย่อหน้า 12 และ 17(ค)(ii) ของความมุ่งมั่น) ตามข้อตกลงกับ CMA รายงานสรุปความคิดเห็นเกี่ยวกับ Privacy Sandbox เหล่านี้สร้างขึ้นโดยการรวบรวมความคิดเห็นที่ Chrome ได้รับจากแหล่งที่มาต่างๆ ตามที่ระบุไว้ในภาพรวมความคิดเห็น ซึ่งรวมถึงแต่ไม่จำกัดเพียง GitHub Issues, แบบฟอร์มความคิดเห็นที่มีให้ใช้งานใน privacysandbox.com, การประชุมกับผู้มีส่วนเกี่ยวข้องในอุตสาหกรรม และฟอรัมมาตรฐานเว็บ Chrome ยินดีรับฟังความคิดเห็นที่ได้รับจากระบบนิเวศและกำลังสำรวจวิธีผสานรวมสิ่งที่ได้เรียนรู้เข้ากับการตัดสินใจด้านการออกแบบ
ธีมความคิดเห็นจะจัดอันดับตามความถี่ต่อ API โดยรวบรวมจำนวนความคิดเห็นที่ทีม Chrome ได้รับเกี่ยวกับธีมหนึ่งๆ แล้วจัดเรียงตามลำดับจากมากไปน้อย เราระบุธีมความคิดเห็นที่พบบ่อยโดยการตรวจสอบหัวข้อการสนทนาจากการประชุมสาธารณะ (W3C, PatCG, IETF) ความคิดเห็นโดยตรง, GitHub และคำถามที่พบบ่อยซึ่งปรากฏผ่านทีมภายในของ Google และแบบฟอร์มสาธารณะ
กล่าวโดยละเอียดคือ เราได้ตรวจสอบบันทึกการประชุมขององค์กรมาตรฐานเว็บ และพิจารณาความคิดเห็นโดยตรงจากบันทึกการประชุมแบบ 1:1 ของผู้มีส่วนเกี่ยวข้องของ Google, อีเมลที่ได้รับจากวิศวกรแต่ละคน, รายชื่ออีเมลของ API และแบบฟอร์มความคิดเห็นสาธารณะ จากนั้น Google ได้ประสานงานระหว่างทีมต่างๆ ที่เกี่ยวข้องในกิจกรรมการติดต่อเหล่านี้เพื่อระบุความแพร่หลายของธีมที่ปรากฏขึ้นซึ่งเกี่ยวข้องกับ API แต่ละรายการ
คำอธิบายการตอบสนองของ Chrome ต่อความคิดเห็นพัฒนามาจากคําถามที่พบบ่อยที่เผยแพร่ การตอบกลับจริงสำหรับปัญหาที่ระบุโดยผู้มีส่วนเกี่ยวข้อง และการกำหนดจุดยืนเพื่อวัตถุประสงค์ในการรายงานต่อสาธารณะโดยเฉพาะ เราได้รับคําถามและความคิดเห็นเกี่ยวกับ Topics, Protected Audience และ Attribution Reporting API โดยเฉพาะ ซึ่งสอดคล้องกับจุดเน้นในการพัฒนาและการทดสอบในปัจจุบัน
ความคิดเห็นที่ได้รับหลังจากสิ้นสุดระยะเวลาการรายงานปัจจุบันอาจยังไม่มีคําตอบจาก Chrome
อภิธานศัพท์เกี่ยวกับตัวย่อ
- CHIPS
- คุกกี้ที่มีสถานะการแบ่งพาร์ติชันอิสระ
- DSP
- แพลตฟอร์มฝั่งดีมานด์
- FedCM
- การจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์
- FPS
- ชุดโดเมนของบุคคลที่หนึ่ง
- IAB
- Interactive Advertising Bureau
- IDP
- ผู้ให้บริการข้อมูลประจำตัว
- IETF
- คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต
- IP
- ที่อยู่ Internet Protocol
- openRTB
- การเสนอราคาแบบเรียลไทม์
- OT
- ช่วงทดลองใช้จากต้นทาง
- PatCG
- กลุ่มชุมชนเทคโนโลยีโฆษณาส่วนตัว
- RP
- ผู้เชื่อถือ
- SSP
- แพลตฟอร์มฝั่งขาย
- TEE
- สภาพแวดล้อมการดำเนินการที่เชื่อถือได้
- UA
- สตริง User Agent
- UA-CH
- คำแนะนำสำหรับไคลเอ็นต์ User Agent
- W3C
- World Wide Web Consortium
- WIPB
- การจงใจปิดบัง IP
ความคิดเห็นทั่วไป ไม่มี API หรือเทคโนโลยีที่เฉพาะเจาะจง
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ความพร้อมของระบบนิเวศ | SSP เน้นย้ำความกังวลเกี่ยวกับผู้เผยแพร่โฆษณาที่ไม่พร้อมและไม่ทํางานเพื่อเตรียมใช้งานที่จำเป็น | Privacy Sandbox มีการติดต่อสื่อสารที่มุ่งเน้นไปที่การให้ความรู้แก่ผู้เผยแพร่โฆษณาโดยเฉพาะ ซึ่งรวมถึงการสัมมนาผ่านเว็บและการประชุมเฉพาะที่มีทั้งผู้เผยแพร่โฆษณาและ SSP เข้าร่วมเพื่อขับเคลื่อนการใช้งาน |
| การเลิกใช้งานคุกกี้ของบุคคลที่สาม | ความกังวลเกี่ยวกับการเลิกใช้งานคุกกี้ของบุคคลที่สาม (3PCD) เพิ่มขึ้นในไตรมาสที่ 4 ปี 2023 เนื่องจากอุตสาหกรรมเทคโนโลยีหยุดชะงัก | เราได้พูดคุยเกี่ยวกับลำดับเวลาของ Privacy Sandbox กับ CMA แล้ว โดยลำดับเวลาดังกล่าวจะนำไปสู่การพร้อมใช้งานในช่วงครึ่งหลังของปี 2024 Privacy Sandbox จะเผยแพร่ข้อมูลโดยละเอียดเพิ่มเติมเกี่ยวกับลำดับขั้นของการเพิ่ม 3PCD ภายใต้ความมุ่งมั่นนี้ 3PCD จะต้องปฏิบัติตามข้อกังวลด้านการแข่งขันของ CMA |
| Google Ad Manager | Google Ad Manager ปฏิเสธที่จะแสดงแพลตฟอร์ม API ทําให้การทดสอบทําได้ยาก | คําตอบจาก Google Ad Manager: แผนการผสานรวม Protected Audience API ของ Google Ad Manager ไม่ได้รองรับเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาของ Google ที่ไม่มีการควบคุมการประมูลระดับบนสุดตามเหตุผลที่อธิบายไว้ในคําตอบนี้จาก Google Ad Manager |
| Google Ad Manager | Google Ad Manager มีราคาพื้นลับที่แสดงต่อ SSP ของ AdX หรือการเสนอราคาแบบเปิดเท่านั้น | เอกสารประกอบสาธารณะของ 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 กว่าปีก่อนคงเป็นไปไม่ได้ นอกจากนี้ ความสามารถของคอมพิวเตอร์ส่วนบุคคลก็เพิ่มขึ้นด้วย รวมถึงความคาดหวังของผู้บริโภคเกี่ยวกับเบราว์เซอร์และความคาดหวังด้านกฎระเบียบด้านความเป็นส่วนตัว |
| แมชชีนเลิร์นนิง | Google มีแผนที่จะใช้ Privacy Sandbox เพื่อวัตถุประสงค์ด้านการเรียนรู้ของเครื่องอย่างไร | ปัจจุบันระบบนิเวศเทคโนโลยีโฆษณาส่วนใหญ่ใช้แมชชีนเลิร์นนิง และเราคาดว่าแนวโน้มนี้จะไม่เปลี่ยนแปลง Privacy Sandbox ไม่ได้ป้องกันไม่ให้บริษัทเทคโนโลยีโฆษณาหรือบุคคลอื่นใช้แมชชีนเลิร์นนิงต่อไป และ Privacy Sandbox ก็ไม่ได้กําหนดให้บริษัทที่ผสานรวมกับ API ต้องใช้แมชชีนเลิร์นนิง เราคาดหวังได้ว่าบริษัทต่างๆ จะยังคงสร้างผลิตภัณฑ์และบริการในลักษณะที่ตรงกับความต้องการของลูกค้าต่อไป ไม่ว่าจะใช้แมชชีนเลิร์นนิงในกระบวนการหรือไม่ก็ตาม ข้อมูลแมชชีนเลิร์นนิงทั้งหมดที่ผู้ผสานรวม Privacy Sandbox สร้างขึ้นจะเป็นที่รู้จักของผู้ผสานรวมอย่างชัดเจน จึงจะไม่ถูกปิดบัง |
| การยืนยันข้อมูล | บริษัทจะยืนยันได้อย่างไรว่าข้อมูลที่ได้จากการใช้ Privacy Sandbox นั้นถูกต้อง และ Google ยินดีรับการตรวจสอบผ่านหน่วยงานอย่างเช่นคณะกรรมการจัดอันดับความน่าเชื่อถือของสื่อ (MRC) หรือไม่ | Privacy Sandbox API สร้างขึ้นภายในแพลตฟอร์มโอเพนซอร์สที่ขับเคลื่อน Chrome ส่วนต่างๆ ของ API ที่มีไว้เพื่อทำงานในสภาพแวดล้อมการทํางานที่เชื่อถือได้ยังเป็นโอเพนซอร์สและตรวจสอบได้ด้วย ทุกคนที่ต้องการตรวจสอบโค้ดได้ รวมถึง MRC |
| (รายงานในไตรมาสก่อนหน้าด้วย) การสนับสนุนเวอร์ชันที่ใช้งานจริง | กระบวนการที่ Chrome ใช้เพื่อรองรับ Privacy Sandbox มีขั้นตอนอย่างไร ทั้งปัญหาทางเทคนิคและการส่งต่อปัญหาที่ส่งผลกระทบต่อระบบนิเวศ | Google มีช่องทางที่หลากหลายเพื่อให้ผู้เชี่ยวชาญด้านเทคโนโลยีโฆษณารายงานปัญหาทางเทคนิคและส่งต่อปัญหาที่จำเป็นเพื่อแก้ไขปัญหาดังกล่าว นอกจากนี้ Chrome ยังคาดว่าจะสร้างและปรับขนาดกระบวนการเพื่อแก้ปัญหาทางเทคนิคและการส่งต่อปัญหาที่ส่งผลต่อความเสถียรของระบบนิเวศต่อไป Chrome มุ่งมั่นที่จะจัดสรรทรัพยากรเพื่อดำเนินการนี้ โปรดไปที่ฟอรัมสาธารณะและฟอรัมส่วนตัวเพื่อส่งความคิดเห็นและส่งต่อ |
| โหมดการทดสอบที่อำนวยความสะดวกโดย Chrome | ข้อมูลเพิ่มเติมเกี่ยวกับลำดับเวลาและการใช้งานที่แน่นอนสำหรับโหมดการทดสอบที่ Chrome อำนวยความสะดวก | เราได้แชร์บล็อกโพสต์เกี่ยวกับโหมดการทดสอบแล้ว และกำลังดำเนินการเพื่อแชร์ข้อมูลเพิ่มเติมในเร็วๆ นี้ เรายินดีรับฟังคำแนะนำเกี่ยวกับขนาดของป้ายกำกับโหมดทดสอบ |
| การผสานรวมกับมาตรฐานอุตสาหกรรมอื่นๆ | Privacy Sandbox API จะเชื่อมต่อกับ TCF v2.* และโหมดความยินยอมอย่างใดอย่างหนึ่งหรือทั้ง 2 อย่างหรือไม่ | เราไม่มีแผนที่จะผสานรวม Privacy Sandbox API กับ TCF เวอร์ชัน 2 หรือโหมดความยินยอมโดยตรง อย่างไรก็ตาม บริษัทและกลุ่มอุตสาหกรรมการค้ายินดีที่จะปรับผลิตภัณฑ์และเฟรมเวิร์กให้ทำงานร่วมกับ Privacy Sandbox API ได้ ตัวอย่างเช่น ในกรณีของเฟรมเวิร์กอย่าง TCF ผู้เข้าร่วมแต่ละรายต้องกำหนดแนวทางการปฏิบัติตามข้อกำหนดของตนเองโดยอิงตามสัญญาณ TCF ที่ได้รับและนโยบาย TCF ที่เกี่ยวข้อง เราคาดหวังให้บริษัทต่างๆ เป็นผู้กำหนดเวลาและวิธีใช้ฟังก์ชันต่างๆ ที่องค์ประกอบพื้นฐานของ Privacy Sandbox มีให้ |
การลงทะเบียนและการรับรอง
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ข้อจำกัด | กระบวนการลงทะเบียนหมายความว่า Google จะเลือกได้ว่าจะให้บริษัทใดในระบบนิเวศได้รับอนุญาตให้ใช้ Privacy Sandbox API | กระบวนการลงทะเบียนและการรับรองโดยพื้นฐานแล้วเกี่ยวข้องกับการยืนยันตัวตน (เช่น บุคคลนั้นมีหมายเลข DUNs สามารถระบุลิงก์ไปยังนโยบายความเป็นส่วนตัว และอื่นๆ) และกำหนดให้การรับรองแบบสาธารณะเป็นข้อกำหนดในการเรียกใช้ API ระบบจะตรวจสอบนิติบุคคลที่มีคุณสมบัติตรงตามข้อกําหนดในการลงทะเบียน สําหรับบริษัทที่ไม่มี DUNs เรามีกระบวนการที่รวดเร็วและไม่มีค่าใช้จ่ายกับ Dun & Bradstreet ในการขอรับ DUNs โดยมีวัตถุประสงค์เพื่อปรับปรุงการคุ้มครองความเป็นส่วนตัวของ API (ด้วยมาตรการที่เพิ่งกล่าวถึง) และเพิ่มความโปร่งใสอีกระดับให้กับ Privacy Sandbox API เพื่อให้ผู้ที่เกี่ยวข้องเข้าใจได้ดีขึ้นว่าใครกำลังใช้ API ใดและกำลังทำการรับรองอะไร เรายินดีรับความคิดเห็นเพิ่มเติมจากอุตสาหกรรมเกี่ยวกับปัญหานี้ ซึ่งเราได้นำไปใช้เพื่อกำหนดกระบวนการแล้ว |
| ค่าใช้จ่ายในการลงทะเบียนอีกครั้ง | ไฟล์การรับรองจะหมดอายุทุก 12 เดือน และกำหนดให้เว็บไซต์ต้องลงทะเบียนอีกครั้ง | เราได้รับฟังความคิดเห็นจากระบบนิเวศและแก้ไขแนวทางของเราตามความเหมาะสมแล้ว ซึ่งหมายความว่าไฟล์จะไม่หมดอายุอีกต่อไปหลังจากผ่านไป 12 เดือนหรือระยะเวลาที่กำหนดไว้ เรากำลังอัปเดตคู่มือนักพัฒนาแอปเกี่ยวกับการลงทะเบียนโดยให้บริบทเพิ่มเติม |
| ไฟล์รับรอง | ไฟล์รับรองใช้อย่างไร | บริษัททุกแห่งที่เรียกใช้ API ที่เกี่ยวข้องกับความเกี่ยวข้องและการวัดผลจะต้องอัปโหลดไฟล์รับรองในเว็บไซต์ของตนและเก็บไว้ให้สาธารณะดูภายในกำหนดเวลาบังคับใช้ ตราบใดที่คุณตั้งใจจะเรียกใช้ API ต่อไป เว็บไซต์อาจได้รับคำขอประมาณ 1 คำขอต่อชั่วโมงจาก Privacy Sandbox และอาจมีการค้นหาจากบุคคลอื่นๆ ด้วย การดำเนินการนี้จะดำเนินการผ่านกลไกของระบบการลงทะเบียนเพื่อค้นหาเซิร์ฟเวอร์ของนิติบุคคลที่ลงทะเบียนและตรวจสอบว่าไฟล์รับรองถูกต้อง การรับรองจะรวมอยู่ในรายงานเพื่อความโปร่งใสและบุคคลทั่วไปจะดูได้ เราคาดหวังให้บริษัทดำเนินการตามการรับรองที่ระบุไว้ เช่นเดียวกับระบบนิเวศส่วนอื่นๆ และหน่วยงานกำกับดูแลที่เกี่ยวข้อง |
| การลงทะเบียน | การลงทะเบียนเป็นแบบต่อเว็บไซต์หรือต่อต้นทาง | การลงทะเบียนจะอยู่ที่ระดับเว็บไซต์ |
แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง
หัวข้อ
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ประสิทธิภาพ | ข้อกังวลด้านประสิทธิภาพเกี่ยวกับผลกระทบของอัตราการเลือกใช้ Topics ในเขตเศรษฐกิจยุโรป | เราขอแนะนำให้ผู้มีส่วนเกี่ยวข้องติดต่อหน่วยงานคุ้มครองข้อมูลที่เกี่ยวข้องเกี่ยวกับปัญหานี้ หน่วยงานเหล่านี้อยู่ในจุดที่เหมาะที่สุดในการแก้ไขข้อกังวลดังกล่าวและกำหนดว่ากฎหมายจะให้แรงจูงใจต่อการใช้งานเทคโนโลยีที่ปรับปรุงความเป็นส่วนตัวหรือไม่ หรือจะถือว่าการใช้งานดังกล่าวเป็นการติดตามซึ่งต้องใช้แนวทางเดียวกันในการขอความยินยอม ซึ่งอาจส่งผลให้ API เช่น API ใน Privacy Sandbox ไม่พร้อมใช้งานบ่อยนัก |
| การลงทะเบียน | ผู้เสนอราคาปลายทางต้องลงทะเบียนใน Topics API เพื่อใช้สัญญาณ Topics จาก SSP ต้นทางไหม | ผู้รับปลายทางของหัวข้อที่อยู่นอกเหนือ Topics API ที่เรียกใช้ครั้งแรกไม่จำเป็นต้องลงทะเบียน แต่ก็มีแนวโน้มว่าหลายๆ รายจะลงทะเบียนเพื่อการใช้งาน API อื่นๆ รายชื่อผู้ลงทะเบียน Privacy Sandbox จะแสดงแบบเป็นโปรแกรมโดยเป็นส่วนหนึ่งของความพยายามในการแสดงความโปร่งใสของโปรแกรม ซึ่งจะช่วยให้ผู้เรียกใช้ Topics API ที่สนใจตรวจสอบได้ว่าผู้รับที่ตนส่งหัวข้อให้ลงทะเบียนหรือไม่ หากผู้เรียกใช้ต้องการ |
| การกรองหัวข้อ | ขอใช้การกรองของผู้เรียกรายอื่นกับหัวข้อที่เรียกข้อมูลในหน้าเว็บ เพื่อแชร์เฉพาะสิ่งที่ผู้ซื้อมีสิทธิ์เรียกข้อมูล | เรากำลังพิจารณาคำขอนี้และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
| การยกเว้นเว็บไซต์ | ยกเว้นเว็บไซต์ไม่ให้มีส่วนร่วมในหัวข้อของผู้ใช้ | ระบบจะไม่เรียกใช้หัวข้อโดยค่าเริ่มต้น โปรดทราบว่าระบบจะไม่พิจารณาเนื้อหาของหน้าเว็บเมื่อเลือกหัวข้อ และหัวข้อทั้งหมดจะได้รับการดูแลจัดการเพื่อให้แน่ใจว่าไม่เป็นเรื่องละเอียดอ่อน นอกจากนี้ เว็บไซต์ยังจำกัดไม่ให้ระบบรวมเว็บไซต์ของตนไว้ในการคำนวณหัวข้อได้ผ่านส่วนหัวของนโยบายสิทธิ์ต่อไปนี้ Permissions-Policy:
browsing-topics=() |
| การสังเกตหัวข้อ | อนุญาตให้ผู้เผยแพร่โฆษณาให้สิทธิ์แก่ Chrome เพื่อจัดหมวดหมู่หัวข้อตามเนื้อหาหน้าเว็บ (เช่น ส่วนหัวหรือเนื้อหา) | ก่อนหน้านี้เราเคยพิจารณาที่จะเสนอฟังก์ชันการจัดประเภทเว็บไซต์ตามหัวข้อโดยอิงตามเนื้อหาของหน้าเว็บ แต่ตัดสินใจที่จะไม่ดำเนินการต่อเนื่องจากข้อกังวลด้านความเป็นส่วนตัวและความปลอดภัย ข้อเสนอนี้อาจช่วยลดข้อกังวลบางประการได้ แต่ไม่แน่ชัดว่าจะช่วยลดได้มากน้อยเพียงใด เนื่องจากช่วงการทดสอบ CMA ที่กําลังจะมาถึง เราจึงไม่คาดว่าการเปลี่ยนแปลงนี้จะเกิดขึ้นก่อน 3PCD เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่ |
| การสังเกตหัวข้อ | ระบุนโยบายสิทธิ์แบบละเอียดยิ่งขึ้นสำหรับผู้เผยแพร่โฆษณา | การกำหนดนโยบายสิทธิ์ที่ละเอียดยิ่งขึ้นสำหรับผู้เผยแพร่โฆษณาจะช่วยให้เว็บไซต์ของผู้เผยแพร่โฆษณาส่งผลเสียต่อประโยชน์ของ Topics API สำหรับทั้งระบบนิเวศได้ โดยไม่ส่งผลเสียต่อประโยชน์ของ Topics API สำหรับเว็บไซต์นั้นๆ โปรดดูการพูดคุยเรื่องสิทธิ์ในหัวข้ออัปเดตนโยบายสิทธิ์เพื่อรองรับสิทธิ์แยกต่างหากสำหรับการดึงข้อมูลและการสังเกตใน GitHub |
| หัวข้อทางการแพทย์และสุขภาพ | เหตุใดการจัดหมวดหมู่ตามหัวข้อจึงไม่ครอบคลุมหัวข้อในหมวดหมู่การแพทย์หรือสุขภาพ | หมวดหมู่ทางการแพทย์และสุขภาพถือเป็นหัวข้อที่ละเอียดอ่อน จึงได้รับการยกเว้นจากการจัดหมวดหมู่หัวข้อ |
| การรับหัวข้อ | วิธีที่ DSP รับ Topics ได้เร็วขึ้นโดยไม่ต้องดึงข้อมูลโดยใช้ส่วนหัว | วิธีการส่วนหัวมีประสิทธิภาพมากกว่าและมีต้นทุนต่ำกว่าการสร้าง iframe ข้ามแหล่งที่มาและการเรียกใช้ document.browsingTopics() จาก iframe ดังกล่าว (ต้องใช้ iframe ข้ามแหล่งที่มาสำหรับการเรียก เนื่องจากบริบทระดับบนสุดในการสังเกตหัวข้อต้องตรงกับบริบทที่เข้าถึงหัวข้อ) เรื่องนี้มีการพูดคุยกันโดยละเอียดที่นี่ |
| การรับหัวข้อ | คำขอเพื่อรองรับการส่ง Topics ผ่านส่วนหัวในคำขอแท็กสคริปต์ข้ามต้นทาง | การดำเนินการนี้ไม่สามารถทำได้จากมุมมองด้านความปลอดภัย เอกสารแต่ละรายการและสภาพแวดล้อมการเรียกใช้จะเชื่อมโยงกับต้นทางเดียว ซึ่งเป็นต้นทางของเอกสาร ทรัพยากรย่อยของบุคคลที่สามที่โหลดและดำเนินการภายในสภาพแวดล้อมเดียวกันจะถือว่าเป็นเจ้าของโดยต้นทางของเอกสาร การดำเนินการนี้เพื่อป้องกันการรั่วไหลของข้อมูลจากแหล่งที่มาหนึ่งไปยังอีกแหล่งที่มาหนึ่งโดยไม่ได้รับความยินยอม อีกวิธีหนึ่งคือระบุแอตทริบิวต์ browsingTopics ในแท็ก <script>
ซึ่งควรเป็นวิธีที่ปลอดภัยและไม่มีเวลาในการตอบสนองเพิ่มเติม เรายินดีรับฟัง
ความคิดเห็นจากบุคคลที่สนใจ |
| การรับรู้ | เพิ่มการรับรู้ของสาธารณะเกี่ยวกับ Topics API และวิธีใช้ API | เราได้ติดต่อผู้มีส่วนเกี่ยวข้องซึ่งให้ความคิดเห็นนี้และแก้ไขปัญหานี้ใน GitHub แล้ว
นับจากนี้ไป เราจะยังคงสนับสนุนความเข้าใจเกี่ยวกับ API ในระบบนิเวศต่อไป และหวังว่าจะได้ยินความคิดเห็นจากผู้มีส่วนเกี่ยวข้อง ในระหว่างนี้ เราขอแนะนำให้ผู้มีส่วนเกี่ยวข้องที่ต้องการทราบข้อมูลเพิ่มเติมเกี่ยวกับ Topics API ศึกษาเอกสารประกอบในคู่มือนักพัฒนาซอฟต์แวร์ Chrome |
| การแจ้งเตือน | การแจ้งเตือนเพื่อแจ้งให้ผู้ใช้ทราบเมื่อเว็บไซต์กำลังดู Topics ของผู้ใช้ | เราได้จัดการความคิดเห็นนี้ใน GitHub แล้ว ผู้ใช้ดูข้อมูลเพิ่มเติมเกี่ยวกับการควบคุม Topics ได้ในศูนย์ช่วยเหลือของ Chrome |
| แมชชีนเลิร์นนิง | แมชชีนเลิร์นนิงใช้อนุมาน Topics ของผู้ใช้ได้อย่างไร | เรากำลังหารือเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| ประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ | บริษัทเทคโนโลยีโฆษณาขนาดเล็กอาจไม่สามารถสังเกต Topics ได้เนื่องจากวิธีคำนวณของเบราว์เซอร์ | เฉพาะเทคโนโลยีโฆษณาที่สังเกตเห็นผู้ใช้เข้าชมหน้าเว็บเกี่ยวกับหัวข้อดังกล่าวภายใน 3 สัปดาห์ที่ผ่านมาเท่านั้นที่จะได้รับหัวข้อ หากเทคโนโลยีโฆษณาไม่ได้เรียกใช้ API ในช่วง 3 สัปดาห์ก่อนหน้าสําหรับผู้ใช้รายนั้นในเว็บไซต์เกี่ยวกับหัวข้อนั้น ค่าที่แสดงผลจะว่างเปล่า ฟีเจอร์นี้หมายความว่าเทคโนโลยีโฆษณาที่เจ้าของเว็บไซต์จํานวนมากใช้บริการ จึงมีโอกาสสังเกตการเข้าชมเว็บไซต์ของผู้ใช้รายหนึ่งๆ ได้มากกว่า จึงอาจได้รับหัวข้อมากกว่าเทคโนโลยีโฆษณาอื่นๆ ฟีเจอร์นี้มีความสําคัญต่อการคุ้มครองความเป็นส่วนตัวของ API เนื่องจากจะจํากัดความพร้อมใช้งานของข้อมูลเกี่ยวกับผู้ใช้ไว้สําหรับบุคคลที่สามที่สามารถดูข้อมูลพื้นฐานเดียวกันอยู่แล้วเท่านั้น (ปัจจุบันผ่านคุกกี้ของบุคคลที่สาม) |
| คำขอ XHR | เราจะเลิกใช้งานการรวม Topics ในคำขอ XMLHttpRequest (XHR) เมื่อใด |
ตามที่ได้ประกาศไปในเดือนสิงหาคม 2023 Chrome ได้เริ่มเลิกใช้งานการรองรับ XHR เมื่อเปลี่ยนจากช่วงทดลองใช้จากต้นทางเป็นการพร้อมให้บริการแก่ผู้ใช้ทั่วไป เมื่อมีการเปิดตัว Topics มากขึ้น การสนับสนุน XHR จะรวมไว้สําหรับผู้ใช้ที่เปิดใช้ฟีเจอร์ OT เท่านั้น และเลิกใช้งานอย่างสมบูรณ์เมื่อมีการผสานกลุ่มทดสอบ OT แต่ละกลุ่ม หากคุณใช้ Topics กับ XHR เว็บไซต์จะไม่หยุดทำงาน ระบบจะไม่เพิ่มหัวข้อในส่วนหัวของคำขอ XHR เราขอแนะนําให้คุณเปลี่ยนไปใช้ fetch สำหรับคำขอ ใช้แอตทริบิวต์ iframe หรือใช้ JavaScript API เพื่อดึงข้อมูลหัวข้อ เบราว์เซอร์สมัยใหม่ทั้งหมดรองรับการดึงข้อมูล ยกเว้น Internet Explorer หรือ Opera Mini |
| กระบวนการอัปเดตการจัดหมวดหมู่และตัวจัดประเภท | ข้อมูลเพิ่มเติมเกี่ยวกับลําดับชั้นการจัดหมวดหมู่และลําดับการเผยแพร่ของตัวแยกประเภท Topics รวมถึงวิธีที่บริษัทต่างๆ สามารถเตรียมพร้อมสําหรับการอัปเดตดังกล่าว | คำตอบของเรายังคงเหมือนเดิมจากไตรมาสที่ 2 ดังที่ได้แชร์ไว้ในบล็อกโพสต์ล่าสุด เราคาดว่าการจัดหมวดหมู่จะพัฒนาขึ้นเมื่อเวลาผ่านไป และในที่สุดการกํากับดูแลการจัดหมวดหมู่จะเปลี่ยนไปเป็นของบุคคลภายนอกที่เป็นตัวแทนผู้มีส่วนเกี่ยวข้องจากทั่วทั้งอุตสาหกรรม นอกจากนี้ เรายังได้แชร์แผนการเพิ่มจำนวนผู้ใช้ในtopics-announce group ด้วย |
| การละเมิด | การโจมตีที่อาจเกิดขึ้นผ่านการเปลี่ยนเส้นทางหลายรายการ | เรากำลังพิจารณาปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| ประเภทพื้นที่โฆษณาของผู้เผยแพร่โฆษณา | พื้นที่โฆษณาประเภทใดบ้างที่ 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 ระดับบนสุดเพื่อแสดงโฆษณาต่อลูกค้าในตลาดการแสดงโฆษณาของผู้เผยแพร่โฆษณาอย่างเหมาะสม ในฐานะเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา บทบาทของเราคือการคาดการณ์ให้แก่ผู้เผยแพร่โฆษณาเพื่อให้เจรจาต่อรองแคมเปญที่ขายโดยตรงได้โดยไม่ต้องจองเกินจำนวน และเพื่อกำหนดจังหวะและแสดงการจองโดยตรงอย่างเหมาะสม ซึ่งต้องทำการประมูลครั้งสุดท้ายเพื่อเปรียบเทียบดีมานด์โดยตรงและทางอ้อมที่มีสิทธิ์ทั้งหมด การคาดการณ์และการกำหนดอัตราการแสดงโฆษณาเป็นฟังก์ชันหลักที่ผู้เผยแพร่โฆษณาคาดหวังจากเซิร์ฟเวอร์โฆษณา หากไม่มีการคาดการณ์ที่แม่นยำ ผู้เผยแพร่โฆษณาอาจขายพื้นที่โฆษณามากเกินไป ซึ่งจะเสี่ยงต่อชื่อเสียงทางธุรกิจ การกำหนดอัตราการจองก็สำคัญเช่นกัน เนื่องจากการที่ไม่สามารถปฏิบัติตามสัญญาการจองกับผู้ลงโฆษณาอาจเสี่ยงที่จะสร้างความเสียหายต่อความสัมพันธ์โดยตรงระหว่างผู้เผยแพร่โฆษณากับผู้ลงโฆษณา ซึ่งอาจส่งผลต่อธุรกิจของผู้เผยแพร่โฆษณาได้ กล่าวโดยย่อคือ เราจึงไม่ถือว่ากิจกรรมของเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณาในการเรียกใช้การประมูล Protected Audience ระดับบนสุดแตกต่างจากกิจกรรมอื่นๆ ของเซิร์ฟเวอร์โฆษณาของผู้เผยแพร่โฆษณา |
directFrom |
directFromช่วยให้ Google Ad Manager ป้องกันไม่ให้ผู้เผยแพร่โฆษณาเห็นราคาของการประมูลตามบริบท |
การตอบกลับของ Chrome: ข้อมูลที่มีการส่งไปยัง runAdAuction() นั้นไม่ทราบว่ามาจากผู้ขาย เว้นแต่ว่าผู้ขายจะเรียกใช้ runAdAuction() จาก iframe ของตนเอง ในการประมูลแบบผู้ขายหลายราย เป็นไปไม่ได้ที่ผู้ขายทุกรายจะสร้างเฟรมที่เรียก runAdAuction() directFromSellerSignals
แก้ไขปัญหานี้ด้วยการโหลดเนื้อหาจากแพ็กเกจทรัพยากรย่อยซึ่งโหลดจากต้นทางของผู้ขาย วิธีนี้ช่วยให้มั่นใจว่าความถูกต้องและความสมบูรณ์ของข้อมูลที่ส่งไปยังการประมูลจากการกําหนดค่าการประมูลของผู้ขายจะไม่สามารถถูกดัดแปลงได้ หากผู้เผยแพร่โฆษณาต้องการใช้ Protected Audience API เพื่อทําความเข้าใจข้อมูลใดๆ ที่ผู้ให้บริการเทคโนโลยีส่งไปยังการประมูลของ Protected Audience ก็ขอฟังก์ชันนี้จากผู้ให้บริการเทคโนโลยีได้คำตอบจาก Google Ad Manager: เรามุ่งเน้นที่ความเป็นธรรมในการประมูลมาอย่างยาวนาน รวมถึงสัญญาว่าจะไม่มีการแชร์ราคาจากแหล่งโฆษณาที่ไม่รับประกันของผู้เผยแพร่โฆษณา รวมถึงราคารายการโฆษณาที่ไม่รับประกันกับผู้ซื้อรายอื่นก่อนที่จะเสนอราคาในการประมูล ซึ่งเราได้ยืนยันอีกครั้งในความมุ่งมั่นของเราที่มีต่อหน่วยงานกำกับดูแลการแข่งขันของฝรั่งเศส สําหรับการประมูล Protected Audience เราตั้งใจที่จะรักษาสัญญาของเราด้วยการใช้ directFromSellerSignals และไม่แชร์ราคาเสนอของผู้เข้าร่วมการประมูลกับผู้เข้าร่วมการประมูลรายอื่นจนกว่าการประมูลจะเสร็จสมบูรณ์ในการประมูลแบบผู้ขายหลายราย เพื่อความชัดเจน เราจะไม่แชร์ราคาของการประมูลตามบริบทกับการประมูลคอมโพเนนต์ของเราเองเช่นกัน ตามที่อธิบายไว้ในข้อมูลอัปเดตอธิบายการเปลี่ยนแปลงของการประมูลระดับบนสุดเพิ่มเติม |
| การเปิดเผยข้อมูล | เบราว์เซอร์อาจเปิดเผยตรรกะทางธุรกิจที่ละเอียดอ่อนและรายละเอียดสัญญา | ผู้ใช้เว็บเบราว์เซอร์จะเห็นทุกอย่างที่เกิดขึ้นในเบราว์เซอร์ เมื่อการประมูลเพื่อแสดงโฆษณาเกิดขึ้นในเบราว์เซอร์ บุคคลที่ใช้เบราว์เซอร์นั้นสามารถดูการประมูลที่เกิดขึ้น รวมถึงดูจำนวนเงินที่บุคคลต่างๆ เลือกที่จะเสนอราคาได้ เนื่องจากเบราว์เซอร์เป็นตัวแทนของผู้ใช้ เราจึงคิดว่าเป็นไปไม่ได้หรือไม่ควรที่จะพยายามเปลี่ยนแปลงเรื่องนี้ อย่างไรก็ตาม เฉพาะผู้ใช้เบราว์เซอร์เท่านั้นที่จะเห็นการดำเนินการเหล่านี้ เซิร์ฟเวอร์ใดๆ รวมถึงเซิร์ฟเวอร์ของ Google จะไม่สามารถสังเกตการประมูลในอุปกรณ์ที่ใช้ Protected Audience API ได้ |
PerBuyerExperiment |
ช่วงค่าปัจจุบันของPerBuyerExperimentอาจช่วยให้ผู้ซื้อเชื่อมโยงข้อมูลตามบริบทกับคําขอของเซิร์ฟเวอร์ที่เชื่อถือได้ |
การใช้ Protected Audience API ในลักษณะนี้ไม่สอดคล้องกับการรับรองที่จําเป็นของ Privacy Sandbox ที่ว่าผู้ใช้ API จะไม่พยายามหลบเลี่ยงการคุ้มครองของ Privacy Sandbox ในอนาคต ข้อกำหนดที่ว่าเซิร์ฟเวอร์คีย์-ค่าต้องทำงานในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) จะมอบการป้องกันทางเทคนิคจากการโจมตีนี้ |
| นโยบายต้นทางเดียวกัน | ผ่อนปรนนโยบายต้นทางเดียวกันเพื่ออนุญาตโดเมนย่อย | เรากำลังพิจารณาคำขอนี้และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
| การกําหนดเวอร์ชัน API | คำขอการระบุเวอร์ชันและบันทึกประจำรุ่นสำหรับการเปลี่ยนแปลง Protected Audience API | เรากำลังพิจารณาคำขอนี้และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
| การประมูลหลาย SSP | อนุญาตให้สัญญาณการประมูลระดับบนสุดทำการผสาน JSON กับสัญญาณคอมโพเนนต์ auctionSignals |
เรากำลังพิจารณาคำขอนี้และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
| ขีดจำกัดราคาเสนอ | เพิ่มขีดจํากัดจํานวนองค์ประกอบโฆษณาที่เข้าสู่ราคาเสนอจาก 20 เป็น 40 | เรากำลังพิจารณาคำขอนี้และยินดีรับความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับเหตุผลที่การดำเนินการนี้มีประโยชน์ |
| (รายงานในไตรมาสก่อนหน้าด้วย) ประสิทธิภาพของการประมูลสำหรับกลุ่มเป้าหมายที่ได้รับการคุ้มครอง |
รายงานจากผู้ทดสอบว่าการประมูลที่ใช้ Protected Audience API มีค่าเวลาในการตอบสนองสูง | โดยทั่วไปแล้ว Protected Audience API จะเป็นไปตามรูปแบบมาตรฐานที่มีอยู่ในการสร้างการควบคุมซึ่งช่วยให้ผู้ขายตัดสินใจเกี่ยวกับเวลาและทรัพยากรที่ผู้เสนอราคาใช้ได้ รวมถึงสร้างเครื่องมือที่ช่วยให้ผู้ซื้อตัดสินใจเกี่ยวกับวิธีใช้ทรัพยากรที่มีอยู่ให้ดีที่สุด โดยทั่วไปแล้วการควบคุมและเครื่องมือเหล่านี้พร้อมใช้งานแล้วในปัจจุบัน แต่ผู้ซื้อและผู้ขายจะต้องนำการควบคุมและเครื่องมือเหล่านี้ไปใช้จึงจะได้รับประโยชน์อย่างเต็มที่ นอกจากนี้ Chrome ยังทํางานอย่างต่อเนื่องเพื่อปรับปรุงโครงสร้างพื้นฐานต่างๆ เพื่อเพิ่มความเร็วในการประมูล (crrev.com/1190815, crrev.com/1199839, crrev.com/1201837, crrev.com/1198339, crrev.com/1197323) เรายินดีรับฟังความคิดเห็นเกี่ยวกับทั้ง 2 ส่วนของความพยายามในการลดเวลาในการตอบสนองนี้ ได้แก่ เครื่องมือใหม่ๆ ที่ผู้ซื้อและผู้ขายจะพบว่ามีประโยชน์ และรายงานเกี่ยวกับปัญหาคอขวดที่พบซึ่งวิศวกรของ Chrome ควรตรวจสอบ |
| การกรองฝั่งซื้อ | เพิ่มการรองรับการกรองฝั่งซื้อตามกลุ่มความสนใจ | เราได้แนะนําวิธีต่างๆ ที่ SSP และ DSP เปลี่ยนแปลงการออกแบบเพื่อจัดการกับปัญหานี้
|
| การควบคุมกลุ่มความสนใจของผู้เผยแพร่โฆษณา | การสนับสนุนสําหรับผู้เผยแพร่โฆษณาที่ต้องการมอบสิทธิ์การใช้กลุ่มความสนใจที่ผู้เผยแพร่โฆษณาสร้างขึ้น | เราได้พูดคุยกับหลายฝ่ายเกี่ยวกับคำขอนี้ เราเชื่อว่ากรณีการใช้งานทั้งหมดที่เกี่ยวข้องกับ "การมอบสิทธิ์" กลุ่มความสนใจที่สร้างโดยผู้เผยแพร่โฆษณาสามารถรองรับได้แล้วในตอนนี้ และเราควรสร้างการสนับสนุนเพิ่มเติมเพื่อให้กรณีการใช้งานบางอย่างทำงานได้อย่างราบรื่นยิ่งขึ้นในอนาคต |
| (รายงานในไตรมาสที่ 2 ด้วย) สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ | การรองรับสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) ในสภาพแวดล้อมระบบคลาวด์แบบไม่เป็นสาธารณะ | คำตอบของเราจะคล้ายกับในไตรมาสก่อน แม้ว่าเราจะยังคงสำรวจการสนับสนุนตัวเลือกนอกเหนือจากโซลูชันที่ทำงานบนระบบคลาวด์สาธารณะ แต่ปัจจุบันเรายังไม่มีแผนที่จะรองรับ TEE ในระบบภายใน ในขั้นตอนนี้ เราเชื่อว่าการขยายและปรับปรุงการใช้งานบนระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ Google Cloud นอกเหนือจาก AWS) เป็นสิ่งที่มีประโยชน์ต่อระบบนิเวศมากที่สุด เนื่องจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และข้อจำกัดที่สำคัญของการใช้งานในเครื่อง อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมว่าเหตุใดข้อกำหนดดังกล่าวจึงจำเป็นและทำได้จริงเมื่อพิจารณาจากข้อจำกัดด้านความเป็นส่วนตัวและความปลอดภัย |
| สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ | คอมโพเนนต์ในเส้นทางการแสดงผล TEE เช่น โหลดบาลานเซอร์ สามารถตรวจสอบการรับส่งข้อมูลทั้งหมดและมีข้อมูลที่อยู่ IP ของคำขอแต่ละรายการ | ปัจจุบันระบบจะส่งที่อยู่ IP เป็นข้อมูลเมตาในส่วนหัวของคำขอไปยังบริการโฆษณาของผู้ขายที่ไม่น่าเชื่อถือ ทั้งในเรื่องการเสนอราคาและการประมูล รวมถึงการประมูล Protected Audience ในอุปกรณ์ โปรดดูข้อมูลเพิ่มเติมที่การส่งต่อข้อมูลเมตา ในระยะยาว เราวางแผนที่จะใช้พร็อกซีสำหรับเทคโนโลยีโฆษณาและการเข้าชมของเครื่องมือติดตามผ่านพร็อกซี IP ซึ่งจะป้องกันไม่ให้คอมโพเนนต์สังเกตเห็นการเข้าชมทั้งหมดในเส้นทางการแสดงโฆษณา |
| Time to Live (TTL) | จะมีการตั้งค่า Time to Live (TTL) ก่อนที่บริการจะต้องขอคีย์ใหม่ไหม หรือมีไว้เพื่อให้ยืดหยุ่น (หรือแบบไดนามิก) | โดยปกติแล้ว TTL จะเป็นค่าคงที่ ปัจจุบัน TTL สำหรับคีย์สาธารณะคือ 8 วัน และการหมุนเวียนจะเกิดขึ้นทุก 7 วัน TTL สำหรับคีย์ส่วนตัวในกรณีของบริการรวบรวมข้อมูลก็เหมือนกัน ในกรณีที่ใช้บริการเสนอราคาและการประมูล ระบบจะดึงข้อมูลคีย์ส่วนตัวและคีย์สาธารณะทุกๆ N ชั่วโมงในเส้นทางที่ไม่ใช่คำขอและแคชไว้ในหน่วยความจำ เพื่อให้เกิดความล่าช้าไม่เกิน N ชั่วโมงระหว่างการเปลี่ยนคีย์กับเซิร์ฟเวอร์ที่รับคีย์เหล่านี้ ระยะห่าง 1 วันระหว่างการหมุนเวียนคีย์กับการหมดอายุมีไว้เพื่อให้มั่นใจว่าบริการจะยังคงทำงานต่อไปได้แม้ว่าการสร้างคีย์จะล้มเหลวก็ตาม เรากำลังพิจารณาขยาย TTL เพื่อเพิ่มความยืดหยุ่นในกรณีที่ระบบหยุดทำงาน ในกรณีที่มีการรั่วไหลของคีย์ เราวางแผนที่จะบังคับให้สร้างคีย์ด้วยตนเองและทำให้คีย์ใช้งานไม่ได้เร็วขึ้น โปรดทราบว่าระบบจะแคชคีย์สาธารณะไว้ในไคลเอ็นต์เป็นเวลา 24 ชั่วโมง เพื่อให้มั่นใจว่าบริการจะยังคงทำงานได้ในกรณีที่ผู้ประสานงานหยุดทำงาน |
| การกำหนดรูปแบบการเข้าชม | การรองรับการกำหนดรูปแบบการเข้าชมสําหรับบริการเสนอราคาและประมูล | ผู้ซื้อสามารถระบุดีมานด์สำหรับการประมูลกลุ่มเป้าหมายที่ได้รับการคุ้มครองโดยอิงตามข้อมูลจากบุคคลที่หนึ่งของผู้เผยแพร่โฆษณาหรือข้อมูลตามบริบท ผู้ขายสามารถทําการกําหนดค่าที่คล้ายกันได้ในเซิร์ฟเวอร์โฆษณาหรือเซิร์ฟเวอร์ Ad Exchange ของผู้ขาย โมเดลสามารถฝึกด้วยข้อมูล 1 ฝ่ายและรายงานรวมจากการประมูลของกลุ่มเป้าหมายที่มีการป้องกัน ผู้ขายสามารถใช้ข้อมูลนี้เพื่อหลีกเลี่ยงการส่งคําขอไปยังเซิร์ฟเวอร์การเสนอราคาและการประมูลเมื่อไม่มีดีมานด์ในการประมูลกลุ่มเป้าหมายที่ได้รับการคุ้มครอง เราเชื่อว่าวิธีนี้อาจเป็นวิธีที่มีประสิทธิภาพในการกำหนดการเข้าชม |
| การประมูลคอมโพเนนต์ | auctionSignal ระดับบนสุดใดบ้างที่แชร์กับผู้ขายคอมโพเนนต์ | ผู้ซื้อในการประมูลคอมโพเนนต์จะได้รับสัญญาณจากผู้ขายคอมโพเนนต์เท่านั้น เรากําลังจะแชร์เอกสารประกอบเกี่ยวกับลําดับโดยรวมของการประมูลแบบรวมกับการเสนอราคาส่วนหัวและการประมูลสําหรับกลุ่มเป้าหมายที่ได้รับการคุ้มครองเร็วๆ นี้ |
| การแสดงผลวิดีโอ | การรองรับการแสดงผลวิดีโอโดยใช้ Protected Audience และ Fenced Frame | Protected Audience API รองรับการแสดงผลวิดีโอโดยใช้กลไกที่อาศัย iframe อย่างไรก็ตาม เรายังไม่ได้ออกแบบโซลูชันที่เข้ากันได้กับเฟรมที่มีการกำหนดเขต และนี่เป็นหนึ่งในเหตุผลที่เราตัดสินใจเลื่อนการบังคับใช้เฟรมที่มีการกำหนดเขตออกไปเป็นปี 2026 ซึ่งหมายความว่าหากพาร์ทเนอร์ตัดสินใจบังคับใช้เฟรมที่มีการกำหนดขอบเขตในตอนนี้ พาร์ทเนอร์รายดังกล่าวจะไม่ได้รับการสนับสนุนสำหรับวิดีโอ |
| การกำหนดความถี่สูงสุด | (รายงานในไตรมาสก่อนหน้าด้วย) การควบคุมความถี่ต่อผู้ใช้ภายในแคมเปญและกลุ่มโฆษณา |
คำตอบของเราไม่มีการเปลี่ยนแปลงจากรายงานก่อนหน้านี้ กลุ่มเป้าหมายที่ได้รับการปกป้องจะรองรับการกำหนดความถี่สูงสุดสำหรับการประมูลในอุปกรณ์ รวมถึงแคมเปญตามบริบทและแคมเปญการสร้างแบรนด์ด้วย นอกจากนี้ คุณยังใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันและขีดจํากัดเฉพาะเว็บไซต์เพื่อควบคุมการจำกัดความถี่เพิ่มเติมได้ด้วย |
| ค่ากําหนดของโฆษณา | กลุ่มเป้าหมายที่ได้รับการคุ้มครองมีวิธีเลือกไม่ใช้หรือบล็อกเว็บไซต์ของผู้ลงโฆษณา หรือมีวิธีออกจากกลุ่มความสนใจทั้งหมดจากผู้เป็นเจ้าของรายเดียวกันไหม | ผู้ใช้สามารถบล็อกการเข้าถึง Protected Audience API และฟีเจอร์อื่นๆ ของ Privacy Sandbox ได้หลายวิธี |
| นโยบายต้นทางเดียวกันสําหรับ URL แหล่งที่มาของสคริปต์การเสนอราคาและการประมูล | ผ่อนปรนข้อกำหนดที่ว่าช่องทั้งหมดที่ระบุ URL สำหรับการโหลดสคริปต์หรือ JSON จะต้องมาจากแหล่งที่มาเดียวกันกับเจ้าของ | ขณะนี้เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
forDebuggingOnly |
มีโอกาสที่ forDebuggingOnly จะถูกนำไปใช้ในทางที่ผิดหากยังคงอยู่หลัง 3PCD |
ในช่วงหลายปีที่ผ่านมา เราได้รับความคิดเห็นจากระบบนิเวศเกี่ยวกับช่องโหว่ด้านฟังก์ชันการทํางานของกลุ่มเป้าหมายที่ได้รับการคุ้มครองเมื่อมีการเลิกใช้งานคุกกี้ของบุคคลที่สาม และเรากําลังพยายามหาวิธีรองรับกลุ่มเป้าหมายดังกล่าวหลัง 3PCD โดยไม่ลดทอนเป้าหมายของ Privacy Sandbox เรายินดีรับฟังคำแนะนำและความคิดเห็นเพิ่มเติมเกี่ยวกับฟังก์ชันการทำงานที่ระบบนิเวศต้องการเห็น |
| กลุ่มความสนใจหลายกลุ่ม | ใช้กลุ่มความสนใจหลายกลุ่มในการเสนอราคาเดียวกัน | ปัจจุบัน Protected Audience API ไม่รองรับการดำเนินการนี้ เนื่องจากจะส่งผลให้รูปแบบความเป็นส่วนตัวพื้นฐานมีการเปลี่ยนแปลง เรายินดีพูดคุยเพิ่มเติมที่นี่ |
| การประมูลในอุปกรณ์ | Chrome ใน Android จะรองรับการประมูลกลุ่มเป้าหมายที่ได้รับการปกป้องในอุปกรณ์ไหม | ใช่ Chrome ใน Android จะรองรับการประมูลในอุปกรณ์ |
| (รายงานในไตรมาสที่ 2 ปี 2023) ข้อมูลที่เกี่ยวข้องกับการคลิก | เพิ่มข้อมูลที่เกี่ยวข้องกับการคลิกลงใน browserSignals | เรายังคงประเมินคำขอฟีเจอร์นี้และยินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ควรให้ความสำคัญกับฟีเจอร์นี้ |
| ผู้ให้บริการสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ | แพ็กเกจ Trusted Execution Environment ของผู้ให้บริการระบบคลาวด์รายต่างๆ มีความแตกต่างกันมากไหม | เราไม่ทราบถึงความแตกต่างที่สำคัญ แต่ขอแนะนำให้ระบบนิเวศอ่านคู่มือการใช้งานแบบสาธารณะเพื่อดูว่าโซลูชันใดเหมาะกับความต้องการมากที่สุด Google Cloud AWS |
| (รายงานในไตรมาสก่อนหน้า) การรองรับการกำหนดกลุ่มความสนใจเชิงลบ |
API ที่รองรับการกำหนดกลุ่มความสนใจเชิงลบ: แสดงโฆษณาเฉพาะในกรณีที่ผู้ใช้ไม่ได้อยู่ในกลุ่มความสนใจ | เรากำลังพิจารณาที่จะใช้ฟีเจอร์นี้และกำลังพูดคุยเกี่ยวกับคำขอ |
| การละเมิดเนื้อหา | รองรับฟีเจอร์ที่อนุญาตให้ผู้ใช้รายงานโฆษณาที่ไม่ดีซึ่งแสดงโดย Protected Audience API ในเฟรมที่มีการกำหนดขอบเขต | เราเชื่อว่า กลไกการรายงานโฆษณาเฟรมที่มีรั้วล้อมที่มีอยู่เป็นตัวเลือกที่ดีสําหรับเทคโนโลยีโฆษณาที่ต้องการขั้นตอนการรายงาน "โฆษณาที่ไม่ดี" ที่ผู้ใช้สร้างขึ้น วิธีนี้จะช่วยให้การรายงานโฆษณาที่ไม่ดีเป็นไปในรูปแบบที่ไม่เปลี่ยนแปลงจากมาตรฐานอุตสาหกรรมในปัจจุบัน เรายินดีรับคำขอฟีเจอร์เพิ่มเติมหากยังมีช่องว่างอยู่ รวมถึงในช่วงเวลาหลังจากการนําคุกกี้ของบุคคลที่สามออก แต่ก่อนที่การแสดงผลเฟรมที่มีรั้วล้อมจะแพร่หลาย |
| การรายงาน Private Aggregation API | เราจะคํานวณเวลาที่ผู้ใช้ใช้ในกลุ่มความสนใจนั้นได้อย่างไร | ใน Chrome M116 ขึ้นไป คุณควรใช้ "ความใหม่" ตามที่กำหนดไว้ใน pull/639 ได้ |
| เซิร์ฟเวอร์ K-Anonymity | ข้อมูลเพิ่มเติมเกี่ยวกับเซิร์ฟเวอร์ K-Anonymity | เราได้แชร์ข้อมูลเพิ่มเติมเกี่ยวกับเซิร์ฟเวอร์ K-Anonymity ที่นี่และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| URL ของครีเอทีฟโฆษณาแบบไดนามิก | รองรับ URL ของครีเอทีฟโฆษณาโดยไม่ต้องประกาศล่วงหน้าในขณะที่ยังคงเค-แอนนิไมตี | เรากำลังหารือเกี่ยวกับคำขอฟีเจอร์นี้และยินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ควรให้ความสำคัญกับฟีเจอร์นี้ |
| ข้อกำหนดเกี่ยวกับ k-anonymity | เราจะนำข้อกำหนดด้าน k-anonymity ในการอัปเดตกลุ่มความสนใจกลับมาใช้ไหม | เราคาดว่าจะไม่มีการเปลี่ยนแปลงตำแหน่งที่ระบุไว้ในโพสต์ GitHub นี้ ตามที่ได้ประกาศไว้ในโพสต์ดังกล่าว เราตัดสินใจที่จะนําข้อกําหนดด้านความเป็นส่วนตัวแบบไม่ระบุตัวบุคคล (K-anonymity) ในการอัปเดตกลุ่มความสนใจของกลุ่มเป้าหมายที่ได้รับการคุ้มครองออก ซึ่งไม่ส่งผลกระทบอย่างมีนัยสําคัญต่อการคุ้มครองความเป็นส่วนตัวโดยรวมของ API และเราวางแผนที่จะพิจารณาการคุ้มครองอื่นๆ ที่อาจเป็นไปได้โดยตรงมากขึ้น (เช่น ความเป็นส่วนตัวของที่อยู่ IP หรือเซิร์ฟเวอร์อัปเดตที่เชื่อถือได้) ในภายหลังเมื่อเทคโนโลยีที่เกี่ยวข้องได้รับการพัฒนา ติดตั้งใช้งาน และนำมาใช้มากขึ้น |
| การทดสอบเบต้าบริการเสนอราคาและประมูล | การทดสอบเบต้าของบริการเสนอราคาและประมูลจะเริ่มขึ้นเมื่อใด | ตามที่ระบุไว้ในไทม์ไลน์และแผนงาน การทดสอบบริการเสนอราคาและบริการประมูลระยะที่ 1 จะเริ่มขึ้นในเดือนพฤศจิกายน 2023 |
| การแสดงร่วมกัน | คำขอรับการสนับสนุนการประสานงานครีเอทีฟโฆษณาสําหรับเครือข่ายโฆษณา (SSP และ DSP อยู่ในบริษัทหรือพร็อพเพอร์ตี้เดียวกัน) | ขอขอบคุณสำหรับความคิดเห็นเกี่ยวกับกรณีการใช้งานนี้ และเราต้องการทราบว่านักพัฒนาเทคโนโลยีโฆษณารายอื่นๆ สนใจที่จะให้รองรับกรณีการใช้งานนี้หรือไม่ เรายินดีรับฟังความคิดเห็นเพิ่มเติม |
| โฆษณาแบบเนทีฟ | การรองรับเฟรมที่มีขอบเขตสำหรับโฆษณาเนทีฟ | เรากำลังพิจารณาที่จะรองรับ Use Case นี้และกำลังหารือเกี่ยวกับวิธีแก้ปัญหาชั่วคราวและวิธีแก้ปัญหาที่เป็นไปได้ |
| K-anonymity | ฉันจะเพิ่มจำนวนโฆษณากลุ่มความสนใจที่เป็นไปตามเกณฑ์ k-anon ได้สูงสุดได้อย่างไร | เราได้แชร์คำแนะนำเชิงกลยุทธ์เกี่ยวกับหัวข้อนี้ |
| การรองรับ POST | การรองรับการส่งข้อมูลการประมูลผ่านคำขอ POST | เรากำลังประเมินคำขอฟีเจอร์นี้และยินดีรับการส่งปัญหาเพิ่มเติมใน GitHub เพื่ออธิบายเหตุผลที่ควรให้ความสำคัญกับฟีเจอร์นี้ |
| รายละเอียดการรายงาน | ความละเอียดของการรายงานโฆษณาเฟรมที่มีรั้วล้อมด้วยโฆษณาที่ประกอบด้วยหลายส่วนคืออะไร | การออกแบบปัจจุบันไม่อนุญาตให้บันทึกรหัสหรือตำแหน่งผลิตภัณฑ์เนื่องจากอาจละเมิดความเป็นส่วนตัวของผู้ใช้ เรียกใช้ได้เฉพาะ reserved.top_navigation
เท่านั้น ซึ่งจะส่งเมื่อมีการเรียกให้ผู้ใช้ดำเนินการ (เช่น การคลิก) ในเฟรมที่มีรั้วล้อมของคอมโพเนนต์โฆษณา ซึ่งส่งผลให้เกิดการนําทางระดับบนสุด |
| การประมูลเพื่อแสดงโฆษณา | SSP ที่เข้าร่วมการประมูลคอมโพเนนต์สามารถเรียกใช้การประมูลคอมโพเนนต์อื่นได้ไหม | componentSeller ต้องไม่มี componentAuctions ด้วยการประมูลของผู้ขายหลายรายมีเพียง 2 ระดับเท่านั้น 1. การประมูลคอมโพเนนต์พร้อมกัน 2. การประมูลระดับบนสุด (ที่โฆษณาที่ชนะจากแต่ละ componentAuctionแข่งขันกัน) |
| ความพร้อมให้บริการของบริการเสนอราคาและการประมูล | การเสนอราคาและการประมูลจะพร้อมใช้งานในช่วงการทดสอบที่ Chrome อำนวยความสะดวกไหม | เซิร์ฟเวอร์การเสนอราคาและการประมูลจะใช้งานไม่ได้ในระหว่างระยะการทดสอบที่ Chrome อำนวยความสะดวก |
| สัญญาณการเสนอราคา | อนุญาตให้เบราว์เซอร์ขอและลบสัญญาณการเสนอราคา | เรากำลังหารือเกี่ยวกับคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมว่าเหตุใดเราจึงควรให้ความสำคัญกับเรื่องนี้ |
generateBid() |
ความสามารถในการอัปเดต userBiddingSignals ของ interestGroup ผ่าน
updateURL |
เรากำลังพิจารณาข้อเสนอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมและการพูดคุย |
| ประเภทพื้นที่โฆษณาของผู้เผยแพร่โฆษณา | พื้นที่โฆษณาประเภทใดบ้างที่ผู้เผยแพร่โฆษณาจะรองรับการทดสอบกลุ่มเป้าหมายที่ได้รับการคุ้มครองและ TOPICS | ทั้งกลุ่มเป้าหมายที่ได้รับการคุ้มครองและหัวข้อไม่ได้จํากัดประเภทพื้นที่โฆษณาที่ใช้ได้ |
| การผสานรวมแบบเซิร์ฟเวอร์ต่อเซิร์ฟเวอร์ | ต้องใช้การผสานรวมโดยตรงระหว่าง SSP กับ DSP สําหรับกลุ่มเป้าหมายที่ได้รับการปกป้องไหม | คุณไม่จำเป็นต้องผสานรวม SSP กับ DSP โดยตรงหาก DSP ไม่ต้องประมวลผลสัญญาณตามบริบทในเซิร์ฟเวอร์ของตนเองเพื่อส่งข้อมูลที่ประมวลผลแล้วไปยังฟังก์ชันการเสนอราคาบนอุปกรณ์ |
ช่อง bid_currency ใน B&A |
รองรับช่อง bid_currency ในบริการเสนอราคาและประมูล |
B&A ยังไม่รองรับ bid_currency แต่เรามีแผนที่จะรองรับภายในสิ้นเดือนมกราคม 2024 โปรดดูไทม์ไลน์ที่นี่ |
perBuyerSignals |
perBuyerSignals มีขีดจำกัดขนาดไหม |
ไม่มีขีดจํากัดจํานวนสัญญาณต่อผู้ซื้อ แต่การส่งข้อมูลมากเกินไปอาจส่งผลเสียต่อประสิทธิภาพของเบราว์เซอร์ |
| กรณีการใช้งานข้ามเว็บไซต์ | เราใช้กลุ่มความสนใจของ Protected Audience API ในเว็บไซต์หลายแห่งได้ไหม | Protected Audience ไม่ได้ออกแบบมาเพื่อ Use Case ดังกล่าว ตามที่อธิบายไว้ใน turtledove/issues/282 |
| คำขอ HTTP ของกลุ่มความสนใจ | ใส่ Blob กลุ่มความสนใจในส่วนหัว HTTP | เรากำลังพิจารณาคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับคำขอนี้ |
| การควบคุมคุณภาพโฆษณา | สูญเสียการควบคุมคุณภาพโฆษณาที่เกี่ยวข้องกับข้อมูลข้ามเว็บไซต์ | เรากำลังพิจารณาความคิดเห็นนี้และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| เครื่องมือสำหรับนักพัฒนาเว็บใน Chrome | คําขอเครือข่ายกลุ่มเป้าหมายที่ได้รับการคุ้มครองขาออกควรปรากฏในแท็บเครือข่ายของเครื่องมือสําหรับนักพัฒนาซอฟต์แวร์ Chrome | เรากำลังดำเนินการเปิดใช้ฟังก์ชันนี้ในแท็บเครือข่าย และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่ควรให้ความสำคัญกับเรื่องนี้ |
| สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ | เราจะเพิ่มรายละเอียดเกี่ยวกับเมตริกที่ส่งผลต่อความเป็นส่วนตัว (และระดับการส่งผล) ลงในคำอธิบายการตรวจสอบสภาพแวดล้อมการทํางานที่เชื่อถือได้เมื่อใด | เรากําลังอัปเดตคําอธิบายประกอบด้วยข้อมูลนี้ คําอธิบายที่อัปเดตแล้วจะพร้อมใช้งานภายในเดือนพฤศจิกายน 2023 |
directFrom |
เหตุใด directFrom จึงไม่ได้จัดแพ็กเกจเป็น Web Bundle |
เราได้แชร์เหตุผลในการตัดสินนี้ที่นี่ |
| การมอบสิทธิ์การแสดงผล | มีวิธีใดที่เป็นไปได้ในการมอบสิทธิ์การแสดงผลที่ผลลัพธ์ของการเลือกกลุ่มความสนใจเป็นการกระทําในการกําหนดเป้าหมายอีกอย่างหนึ่ง | การประมูลที่ซ้อนกันหลายรายการใช้ร่วมกับเป้าหมายด้านความเป็นส่วนตัวของเราไม่ได้เนื่องจากเหตุผล 2 ข้อ ประการแรก เมื่อผู้ชนะการประมูลแสดงผลภายในกรอบที่กั้นไว้ เป้าหมายด้านความเป็นส่วนตัวสําหรับกลุ่มเป้าหมายที่ได้รับการคุ้มครองจะรวมการแสดงผลครีเอทีฟโฆษณาที่แสดงผลโดยไม่ทราบว่าบริบทคือ URL ของหน้าเว็บโดยรอบหรือคุกกี้ของบุคคลที่หนึ่งซึ่งละเมิดความเป็นส่วนตัว การประมูลที่ซ้อนกันจะใช้ไม่ได้ในสภาพแวดล้อมดังกล่าว ประการที่ 2 คือรูปแบบกลุ่มเป้าหมายที่ได้รับการคุ้มครองระบุว่าผู้ชนะการประมูลแต่ละครั้งควรอิงตามข้อมูลจากเว็บไซต์อื่นเพียงเว็บไซต์เดียว การประมูลที่ซ้อนกันจะเป็นวิธีเพิ่มประสิทธิภาพดังกล่าว ซึ่งอาจส่งผลให้มีการเลือกโฆษณาตามโปรไฟล์หลายเว็บไซต์ |
| เกณฑ์ข้อมูลที่ไม่มีการเคลื่อนไหว | อธิบายเกณฑ์ข้อมูลพักไว้ในรูปแบบบริการแบบคีย์/ค่า | ระบบจะโหลดข้อมูลในบริการคีย์-ค่าลงในหน่วยความจําและแสดงจากหน่วยความจํานั้นแทนที่จะแคชการอ่านผ่าน |
| สัญญาณข้อมูลผู้ซื้อ | มีการกําหนดขีดจํากัดขนาดสําหรับbuyer_dataสัญญาณที่ได้รับจาก DSP ไหม |
ปัจจุบันไม่มีขีดจํากัดที่เบราว์เซอร์กำหนดสำหรับbuyer_dataสัญญาณที่ได้รับจาก DSP |
วัดผลโฆษณาดิจิทัล
การรายงานการระบุแหล่งที่มา (และ API อื่นๆ)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| หลายอุปกรณ์ | วางแผนรองรับ Attribution Reporting API ข้ามอุปกรณ์ | การทำงานข้ามอุปกรณ์ทำให้เกิดปัญหาด้านความเป็นส่วนตัวใหม่ๆ นอกเหนือจาก 3PC และยังเพิ่มปัญหาด้านการจัดจำหน่ายเทคโนโลยีด้วยเนื่องจากมีอุปกรณ์และแพลตฟอร์มที่หลากหลายซึ่งผู้ใช้อาจใช้ เรากําลังสํารวจโซลูชันที่เป็นไปได้ แต่มุ่งเน้นที่กรณีการใช้งานที่สําคัญซึ่งการรายงานการระบุแหล่งที่มารองรับในปัจจุบัน และไม่มีแผนที่จะเปิดตัวการรองรับหลายอุปกรณ์ก่อนนําคุกกี้ของบุคคลที่สามออก |
| (รายงานในไตรมาสก่อนหน้าด้วย) ขนาดข้อมูลทริกเกอร์ |
เหตุใดขนาดข้อมูลทริกเกอร์จึงจํากัดไว้ที่ 3 บิต | ขนาดถูกจํากัดไว้ที่ 3 บิตและค่าที่แตกต่างกัน 8 ค่าเพื่อให้มั่นใจว่าปริมาณข้อมูลข้ามเว็บไซต์และข้ามบริบทเกี่ยวกับผู้ใช้จะจํากัด เรายินดีให้ผู้เล่นในระบบนิเวศส่งความคิดเห็นว่าการกำหนดพารามิเตอร์ปัจจุบันสำหรับการรายงานระดับเหตุการณ์เพียงพอหรือไม่ |
| Conversion Funnel | รายงานหลายโดเมนที่ใช้ใน Conversion | กรณีการใช้งานนี้เป็นไปได้เนื่องจากมีการเพิ่มปลายทางหลายแห่ง เรายินดีรับฟังความคิดเห็นเพิ่มเติม |
| โดเมนเดียวกันในประเทศที่ต่างกัน | การรายงานการระบุแหล่งที่มาทํางานกับเว็บไซต์ที่มีโดเมนเดียวกันแต่มี TLD หลายประเทศได้ไหม | เราได้พูดคุยและแก้ไขปัญหานี้กับผู้ที่มีส่วนเกี่ยวข้องซึ่งได้ตั้งคำถามแล้ว หากเทคโนโลยีโฆษณาต้องใช้ TLD ของประเทศหลายรายการ จะต้องลงทะเบียนหลายครั้ง โดยลงทะเบียน 1 ครั้งสำหรับ TLD ของประเทศแต่ละรายการ |
| การรายงานการระบุแหล่งที่มาและ Protected Audience | เทคโนโลยีโฆษณาเข้าถึงทั้ง Conversion การดูผ่านสําหรับการประมูลกลุ่มเป้าหมายที่ได้รับการคุ้มครอง รวมถึง Conversion การคลิกผ่านสําหรับการรายงานการระบุแหล่งที่มาได้ไหม | ใช่ Privacy Sandbox ควรรองรับทั้ง VTC และ CTC ภายในกลุ่มเป้าหมายที่ได้รับการคุ้มครอง |
| ความล่าช้าของรายงานที่รวบรวมได้ | ลดความล่าช้าของรายงานที่รวบรวมได้ | เราได้รับความคิดเห็นล่าสุดเกี่ยวกับเรื่องนี้และได้แชร์แนวคิดที่นี่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
| ความล่าช้าของรายงานที่รวบรวมได้ | การลดเวลาในการตอบสนองด้วยการใช้สื่อกลางของเซิร์ฟเวอร์ | เรากำลังพิจารณาข้อเสนอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติม |
| ความล่าช้าของรายงานระดับเหตุการณ์ | ลดความล่าช้าของรายงานระดับเหตุการณ์ | โปรโปซาลระดับเหตุการณ์แบบยืดหยุ่นทั้งหมดที่อธิบายไว้ในการกำหนดค่าระดับเหตุการณ์แบบยืดหยุ่นสามารถลดความล่าช้าในการรายงานระดับเหตุการณ์ให้เหลือเพียง 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 คนต้องพร้อมใช้งานอย่างเต็มรูปแบบเพื่อให้ระบบทำงานได้อย่างถูกต้อง ในกรณีที่ไม่พร้อมใช้งานเป็นระยะเวลาสั้นๆ ไลบรารีไคลเอ็นต์จะรองรับการลองอีกครั้ง แต่ในกรณีที่ไม่พร้อมใช้งานเป็นเวลานานกว่า 1 ใน 2 ของเครื่องมือประสานงานจะทําให้งานรวบรวมข้อมูลไม่สําเร็จ คุณสามารถเรียกใช้งานอีกครั้งได้หากงบประมาณด้านความเป็นส่วนตัวยังไม่ถูกใช้ ในกรณีที่บริการไม่ทํางานทําให้งบประมาณถูกใช้ไปโดยไม่มีรายงานสรุปที่เขียนลงในพื้นที่เก็บข้อมูลเทคโนโลยีโฆษณา ปัจจุบันเราขอแนะนําให้ใช้รายงานการแก้ไขข้อบกพร่องเพื่อดึงข้อมูลโดยใช้เครื่องมือทดสอบในเครื่อง นอกจากนี้ เรายังพัฒนาฟีเจอร์ที่ช่วยให้กู้คืนงบประมาณได้ในกรณีที่ทำงานไม่สำเร็จ เพื่อให้นักพัฒนาเทคโนโลยีโฆษณาทำงานซ้ำได้ |
Private Aggregation API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| URL ของ Blob | คำขอให้รองรับ URL ของ Blob ในพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน | เพิ่มการรองรับ URL ของ Blob ใน Chrome M116 แล้ว |
จำกัดการติดตามแอบแฝง
การลด User Agent และคำแนะนำสำหรับไคลเอ็นต์ User Agent
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| JavaScript API | ความพร้อมใช้งานของ User Agent Client Hints JavaScript API | เราไม่มีแผนที่จะนําฟังก์ชันการทํางานนี้ออกเนื่องจากเป็นโซลูชันหลักสําหรับพาร์ทเนอร์ที่ต้องการเข้าถึงข้อมูลที่มีความผันผวนสูงอย่างสม่ำเสมอนอกเหนือจากข้อมูลที่มีให้โดยค่าเริ่มต้นใน UA แบบแช่แข็งและแบบลดขนาด |
| ข้อมูลอุปกรณ์และรูปแบบของอุปกรณ์ | ความสามารถของเว็บไซต์ในการเข้าใจอินพุต เอาต์พุต และข้อมูลอื่นๆ ที่อุปกรณ์ที่เข้าชมเว็บไซต์รองรับ | เราได้เพิ่มการรองรับคำขอนี้ตามความคิดเห็นที่ได้รับจากระบบนิเวศ |
การปกป้อง IP (เดิมเรียกว่า Gnatcatcher)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การเข้าชมของบุคคลที่สามที่มีสิทธิ์ | "การเข้าชมของบุคคลที่สามที่มีสิทธิ์" หมายถึงอะไรในคำอธิบาย | เราเข้าใจความสำคัญของคำถามนี้และกำลังดำเนินการเพื่อระบุการเข้าชมของบุคคลที่สามที่มีสิทธิ์และไม่มีสิทธิ์ เรายินดีรับฟังความคิดเห็นเกี่ยวกับหัวข้อนี้ |
| การตรวจสอบการเข้าชมเครือข่าย | รองรับการตรวจสอบการเข้าชมเครือข่ายสําหรับเครือข่ายขององค์กร | เฉพาะการเข้าชมของบุคคลที่สามที่ฝังอยู่ในเว็บไซต์ของบุคคลที่หนึ่งเท่านั้นที่จะได้รับผลกระทบ ซึ่งควรจำกัดปริมาณการเข้าชมที่ต้องกรอง นอกจากนี้ เราวางแผนที่จะให้ผู้ใช้เลือกว่าจะใช้การปกป้อง IP หรือไม่ และสำหรับ Chrome ที่องค์กรควบคุม ผู้ใช้จะปิดใช้การปกป้อง IP ได้โดยทำตามนโยบายขององค์กร สุดท้าย เรากำลังพิจารณาว่าจะให้การควบคุมใด (หากมี) แก่ผู้ให้บริการเครือข่ายเพื่อปิดใช้การปกป้อง IP เรายินดีรับฟังความคิดเห็นเกี่ยวกับหัวข้อนี้ |
| การควบคุมการเข้าถึง | การปกป้อง IP อาจส่งผลต่อบริการเว็บที่ใช้ที่อยู่ IP ในการควบคุมการเข้าถึง | เราเข้าใจความสำคัญของกรณีการใช้งานการป้องกันการประพฤติมิชอบและผลกระทบที่อาจเกิดขึ้นกับกรณีการใช้งานเหล่านั้น เราต้องการความคิดเห็นจากระบบนิเวศเกี่ยวกับวิธีที่เราจะช่วยสนับสนุน Use Case การป้องกันกลโกงซึ่งโดยปกติแล้วจะใช้ที่อยู่ IP ได้ดีขึ้น |
| การสื่อสารระหว่างพร็อกซี 2 Hop | วิธีตรวจสอบว่าไม่มีข้อมูลระหว่างพร็อกซี | เรากําลังออกแบบการโต้ตอบของพร็อกซี เป้าหมายของเราคือการลดโอกาสในการแชร์ข้อมูลดังกล่าวผ่านช่องทางทางธุรกิจ กระบวนการ และทางเทคนิค |
| การตรวจสอบสิทธิ์ที่ไม่ใช่ของ Google | การรองรับการตรวจสอบสิทธิ์ที่ไม่ใช่ของ Google | เรามีแผนที่จะเผยแพร่รายละเอียดเพิ่มเติมเกี่ยวกับการรับรองสิทธิ์บัญชีในอนาคต แต่เราได้แชร์ข้อควรพิจารณาเบื้องต้นแล้ว |
| การจัดประเภทเครื่องมือติดตาม | การป้องกัน IP จะกำหนดว่าอะไรคือองค์ประกอบของเครื่องมือติดตามและตัวแปรของเครื่องมือติดตามได้อย่างไร | เราเข้าใจความสำคัญของคำถามนี้และกำลังดำเนินการเพื่อระบุการเข้าชมของบุคคลที่สามที่มีสิทธิ์และไม่มีสิทธิ์ เรายินดีรับฟังความคิดเห็นเกี่ยวกับหัวข้อนี้ |
| Analytics | การป้องกันทรัพย์สินทางปัญญาอาจส่งผลต่อความถูกต้องของบริการวิเคราะห์ | เราต้องการทําความเข้าใจผลกระทบของการคุ้มครองทรัพย์สินทางปัญญาเพิ่มเติม และยินดีรับฟังความคิดเห็นและตัวอย่างเพิ่มเติมจากระบบนิเวศ |
| พร็อกซี | หากผู้ใช้ใช้พร็อกซีหรือกําหนดพร็อกซีด้วยตนเอง IP Mask จะทํางานอย่างไรในกรณีนี้ | เราต้องการทราบผลกระทบที่การป้องกัน IP อาจมีต่อพร็อกซีอื่นๆ เรายังไม่มีแผนที่จะแชร์ในขณะนี้ เรายินดีรับฟังความคิดเห็นเกี่ยวกับหัวข้อนี้ |
| ข้อเสนอระดับพรีเมียม | การปกป้อง IP จะเป็นฟีเจอร์ที่ต้องเสียค่าใช้จ่ายไหม | การป้องกัน IP จะพร้อมให้บริการแก่ผู้ใช้ Chrome โดยเป็นส่วนหนึ่งของประสบการณ์การใช้งานเบราว์เซอร์หลัก โดยฟีเจอร์นี้จะไม่เสียค่าใช้จ่าย |
| พร็อกซีเซิร์ฟเวอร์ | ระบบจะใช้พร็อกซีเซิร์ฟเวอร์เดียวกันในระหว่างเซสชันของผู้ใช้หรือไม่ | การเชื่อมต่อ HTTP/S จะใช้พร็อกซีคู่เดียวและจะแสดงที่อยู่ IP ที่ถูกมาสก์รายการเดียวต่อต้นทาง นอกจากนี้ การเชื่อมต่อ HTTP/S ต่างๆ ไม่จำเป็นต้องใช้เซิร์ฟเวอร์เดียวกัน |
| การรองรับแพลตฟอร์ม | การปกป้องทรัพย์สินทางปัญญาจะรองรับในแพลตฟอร์มใด | การป้องกันทรัพย์สินทางปัญญาจะพร้อมใช้งานใน Chrome สำหรับ Android และเดสก์ท็อปก่อน เรายังคงประเมินวิธีขยายการปกป้องไปยังแพลตฟอร์มอื่นๆ |
| เลือกไม่ใช้ | ผู้ใช้จะปิดใช้การปกป้อง IP ได้ไหม | เราวางแผนที่จะให้ผู้ใช้เลือกได้ว่าต้องการใช้ IP Protection หรือไม่ |
| การลบข้อมูลระบุตัวบุคคล | คำขอประเภทใดบ้างที่จะได้รับการลบข้อมูลระบุตัวตนภายใต้การคุ้มครองทรัพย์สินทางปัญญา | ระบบจะลบข้อมูลระบุตัวตนในคำขอ HTTP/S และ DNS ที่ส่งไปยังโดเมนของบุคคลที่สามที่มีสิทธิ์ผ่านพร็อกซีความเป็นส่วนตัว เราจะให้รายละเอียดเพิ่มเติมในคำอธิบายที่กำลังจะเผยแพร่เกี่ยวกับวิธีที่เรากำหนดว่าโดเมนใดบ้างที่จะรวมอยู่ด้วย การเข้าชมที่เหลือ (เช่น คำขอ DNS ที่เหลือหรือการเข้าชม HTTP/S อื่นๆ) จะไม่ได้รับผลกระทบ |
| ระดับการเข้าถึงข้อมูล | ระบบอาจเข้าถึงที่อยู่เครือข่ายระหว่าง Hop แรกใน IP Protection | ในโมเดลพร็อกซีแบบ 2 ฮ็อป ฮ็อปแรก (Google เป็นผู้ควบคุม) จะมองเห็นเฉพาะ IP ของไคลเอ็นต์ต้นทางและคำขอเชื่อมต่อกับฮ็อปที่ 2 ส่วนฮ็อปที่ 2 (CDN ภายนอกเป็นผู้ควบคุม) จะมองเห็นเฉพาะชุดค่าผสมในฮ็อปแรก (IP ของพร็อกซี + พอร์ต) และ IP ปลายทาง สําหรับการตอบกลับจากต้นทาง ฮ็อปที่ 2 สามารถส่งต่อการตอบกลับไปยังพร็อกซี+พอร์ตของฮ็อปแรกซึ่งเชื่อมโยงกับคําขอ และไม่จำเป็นต้องทราบข้อมูลใดๆ เกี่ยวกับ IP เดิมของไคลเอ็นต์ (และฮ็อปแรกจะแสดงการตอบกลับต่อไคลเอ็นต์เท่านั้น โดยไม่ต้องทราบข้อมูลใดๆ เกี่ยวกับ IP ปลายทาง) วิธีนี้จะทำให้ Hop แรกเรียนรู้เฉพาะ IP ของไคลเอ็นต์และ Hop ที่ 2 ส่วน Hop ที่ 2 จะเรียนรู้เฉพาะ IP ปลายทาง |
| WebView | การปกป้อง IP จะพร้อมใช้งานใน Android WebView ในอนาคตไหม | ขณะนี้เรายังไม่มีแผนที่จะแชร์ข้อมูล แต่วิสัยทัศน์ของเราคือการมอบการปกป้องนี้ให้ครอบคลุมมากที่สุด |
การลดการติดตามการเข้าชม
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การติดตามการโต้ตอบ | การโต้ตอบของผู้ใช้ได้รับการติดตามอย่างไร | การลดการติดตามการเข้าออกจะติดตามการโต้ตอบของผู้ใช้ 2 ประเภท ได้แก่
การโต้ตอบเหล่านี้จะเชื่อมโยงกับเว็บไซต์ระดับบนสุดในหน้าเว็บที่เกิดเหตุการณ์ เช่น หากผู้ใช้คลิกใน iframe ที่ฝังอยู่ การโต้ตอบจะเชื่อมโยงกับเว็บไซต์ระดับบนสุด ไม่ใช่เว็บไซต์ที่ฝัง การโต้ตอบจะจัดเก็บไว้ในฐานข้อมูลที่มี schemeless 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 โดเมน) ซึ่งตรงกับการใช้งานที่เปรียบเทียบได้มากที่สุดซึ่งเบราว์เซอร์รายใหญ่รายอื่นเสนอ |
| คุกกี้ของบุคคลที่สาม | ชุดเว็บไซต์ที่เกี่ยวข้องจะทํางานกับคุกกี้ของบุคคลที่สามที่ปิดใช้เท่านั้นใช่ไหม | ชุดเว็บไซต์ที่เกี่ยวข้องจะทํางานแม้ว่าผู้ใช้จะไม่ได้บล็อกคุกกี้ของบุคคลที่สาม แต่จะไม่มีผลที่สังเกตได้เนื่องจากคุกกี้ที่เกี่ยวข้องจะพร้อมใช้งานโดยไม่ต้องใช้ชุดเว็บไซต์ที่เกี่ยวข้องและ Storage Access API |
| การแก้ไขที่ถูกต้อง | ที่เก็บชุดเว็บไซต์ที่เกี่ยวข้องป้องกันไม่ให้ผู้ที่ไม่ใช่เจ้าของแก้ไขชุดได้อย่างไร | ตามคำแนะนำในการส่ง ทุกคนสามารถส่ง PR ใน GitHub เพื่อแก้ไขไฟล์ first_party_sets.JSON ได้ อย่างไรก็ตาม หาก PR ได้รับอนุมัติ (ผ่านการตรวจสอบทางเทคนิค ฯลฯ) Google จะผสาน PR ดังกล่าวเป็นกลุ่มๆ ลงในรายการ FPS หลักด้วยตนเองสัปดาห์ละครั้ง (วันอังคารเวลา 12:00 น. ตามเวลาตะวันออก)หากผู้ไม่ประสงค์ดีพยายามแก้ไขชุดที่ตนไม่ได้เป็นเจ้าของ ก็ไม่ควรจะเป็นปัญหา เนื่องจากผู้ไม่ประสงค์ดีจะแก้ไขไฟล์ .well-known ไม่ได้ และการตรวจสอบจะดำเนินการไม่สำเร็จ |
| การลักลอบใช้โดเมน | การลักลอบใช้โดเมนอาจเปิดเผยข้อมูลโดเมนที่เกี่ยวข้องต่อบุคคลที่ไม่ได้รับอนุญาต | การดำเนินการนี้ไม่สามารถทำได้ ตามที่เราได้อธิบายไว้ในปัญหาเกี่ยวกับ Protected Audience ใน GitHub นี้ |
Fenced Frames API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การละเมิดเนื้อหา | อนุญาตให้ผู้ใช้รายงานโฆษณาที่น่าสงสัย | เฟรมที่มีรั้วรอบขอบชิดไม่ได้ป้องกันไม่ให้มีการรายงานโฆษณาที่น่าสงสัย ผู้ใช้จะยังคงโต้ตอบกับโฆษณาและรายงานโฆษณาที่น่าสงสัยไปยังเทคโนโลยีโฆษณาได้เหมือนเดิม |
| การโต้ตอบกับสถานที่รอบๆ | อนุญาตการโต้ตอบกับเว็บไซต์รอบข้างหรือเว็บไซต์ระดับบนสุด | เราต้องการทราบเหตุผลที่ต้องมีคำขอนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
| โฆษณาแบบเนทีฟ | การรองรับเฟรมที่มีขอบเขตสำหรับโฆษณาเนทีฟ | เรากำลังพิจารณาที่จะรองรับ Use Case นี้และกำลังหารือเกี่ยวกับวิธีแก้ปัญหาชั่วคราวและวิธีแก้ปัญหาที่เป็นไปได้ |
Shared Storage API
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| ข้ามโดเมน | อนุญาตให้สื่อสารข้ามโดเมนสำหรับพื้นที่เก็บข้อมูลในเครื่อง | ปัจจุบัน Use Case นี้ไม่สอดคล้องกับเกตเอาต์พุตที่รักษาความเป็นส่วนตัวของพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน แต่เรายินดีรับบริบทเพิ่มเติมขณะที่เราพัฒนาข้อเสนอสำหรับพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชัน |
| URL ของ Blob | คำขอให้รองรับ URL ของ Blob ในพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน | เพิ่มการรองรับ URL ของ Blob ใน Chrome M116 แล้ว |
CHIPs
ไม่ได้รับความคิดเห็นในไตรมาสนี้
FedCM
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| คุกกี้ของบุคคลที่สาม | ปัจจุบัน FedCM ปิดอยู่ไหมหากผู้ใช้เปิดใช้ "บล็อกคุกกี้ของบุคคลที่สาม" ในการตั้งค่า Chrome" | ใช่ FedCM ปิดใช้อยู่ในขณะนี้ สําหรับการทดสอบ เราขอแนะนําให้คุณเปิดใช้chrome://flags/#fedcm-เพิ่มเติมเรากําลังมองหาวิธีรองรับ FedCM โดยไม่ต้องใช้คุกกี้ของบุคคลที่สามในอนาคต |
ต่อสู้กับสแปมและการประพฤติมิชอบ
Private State Tokens API (และ API อื่นๆ)
| ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
|---|---|---|
| การหมดอายุของโทเค็น | เมื่อถอนการติดตั้ง Google Chrome แล้ว โทเค็นจะหายไปหรือระบบจะแคชไว้ไหม | โทเค็นจะหายไปหากผู้ใช้ถอนการติดตั้ง Google Chrome |
| ข้อมูลโทเค็น | ผู้ออกบัตรจะเก็บข้อมูลภายใน Private State Token ให้เป็นส่วนตัวได้อย่างไร | ข้อมูลจะเก็บไว้เป็นส่วนตัวในโทเค็นเสมอ และบุคคลภายนอกที่ไม่มีคีย์จะไม่สามารถถอดรหัสได้ |
| ข้อผิดพลาดในเดโม | เกิดข้อผิดพลาดขณะพยายามเรียกใช้การสาธิตโทเค็นสถานะส่วนตัว | เราได้อัปเดตเดโมแล้วและตอนนี้น่าจะทํางานได้อย่างถูกต้อง |