รายงานรายไตรมาสสําหรับไตรมาสที่ 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 |
directFrom ทำให้ 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 |
ช่วงค่าปัจจุบันของPerBuyerExperiment อาจช่วยให้ผู้ซื้อเชื่อมโยงข้อมูลตามบริบทกับคำขอของเซิร์ฟเวอร์ที่เชื่อถือได้ |
การใช้ 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 ควรปรับเปลี่ยนการออกแบบเพื่อจัดการกับสถานการณ์นี้
|
การควบคุมกลุ่มความสนใจของผู้เผยแพร่โฆษณา | การสนับสนุนสำหรับผู้เผยแพร่โฆษณาที่ต้องการมอบสิทธิ์การใช้กลุ่มความสนใจที่ผู้เผยแพร่โฆษณาสร้างขึ้น | ทั้งนี้เราได้ร่วมหารือกับหลายฝ่ายเกี่ยวกับคำขอดังกล่าว เราเชื่อว่ากรณีการใช้งานดังกล่าวทั้งหมดที่เกี่ยวข้องกับ "การมอบสิทธิ์" กลุ่มความสนใจที่ผู้เผยแพร่โฆษณาสร้างขึ้นนั้นรองรับได้ในตอนนี้ และเรายังควรสร้างการสนับสนุนเพิ่มเติมเพื่อให้กรณีการใช้งานบางกรณีดำเนินไปอย่างราบรื่นยิ่งขึ้นในอนาคต |
(มีการรายงานในไตรมาสที่ 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 ไปใช้ในทางที่ผิดหากยังคงใช้โพสต์ 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 |
เหตุใด directFrom จึงไม่จัดแพ็กเกจเป็น 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 ประเภทดังนี้
การโต้ตอบเหล่านี้จะเชื่อมโยงกับเว็บไซต์ระดับบนสุดในหน้าเว็บที่เกิดขึ้น เช่น หากผู้ใช้คลิกใน 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- เพิ่มเติมเรากำลังมองหาวิธีรองรับ FedCM โดยไม่ใช้คุกกี้ของบุคคลที่สามในอนาคต |
ต่อสู้กับสแปมและการประพฤติมิชอบ
API โทเค็นสถานะส่วนตัว (และ API อื่นๆ)
ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
---|---|---|
การหมดอายุของโทเค็น | เมื่อถอนการติดตั้ง Google Chrome แล้ว โทเค็นจะหายไปหรืออาจมีการแคชโทเค็นไว้ | โทเค็นจะหายไปหากผู้ใช้ถอนการติดตั้ง Google Chrome |
ข้อมูลโทเค็น | ผู้ออกบัตรจะเก็บข้อมูลที่ออกภายในโทเค็นสถานะส่วนตัว ไว้เป็นส่วนตัวได้อย่างไร | ข้อมูลจะถูกเก็บไว้เป็นส่วนตัวในโทเค็นเสมอ และบุคคลภายนอกที่ไม่มีคีย์จะไม่เข้ารหัส |
ข้อผิดพลาดในการสาธิต | เกิดข้อผิดพลาดขณะพยายามเรียกใช้การสาธิตโทเค็นสถานะส่วนตัว | เราได้อัปเดตเดโมแล้ว เดโมควรทำงานได้อย่างถูกต้องทันที |