รายงานรายไตรมาสสําหรับไตรมาสที่ 2 ปี 2023 เพื่อสรุปความคิดเห็นเกี่ยวกับระบบนิเวศที่ได้รับเกี่ยวกับข้อเสนอ Privacy Sandbox และการตอบสนองของ Chrome
ตามพันธสัญญาที่มีต่อ CMA ทาง Google ได้ตกลงที่จะจัดทำรายงานรายไตรมาสเกี่ยวกับกระบวนการมีส่วนร่วมของผู้มีส่วนเกี่ยวข้องสำหรับข้อเสนอ Privacy Sandbox (โปรดดูวรรคที่ 12 และ 17(c)(ii) ของ สัญญาผูกมัด) รายงานสรุปความคิดเห็นเกี่ยวกับ Privacy Sandbox เหล่านี้สร้างขึ้นโดยการรวบรวมความคิดเห็นที่ Chrome ได้รับจากแหล่งที่มาต่างๆ ตามที่ระบุไว้ในภาพรวมความคิดเห็น ซึ่งรวมถึงแต่ไม่จำกัดเพียงปัญหาเกี่ยวกับ GitHub, แบบฟอร์มความคิดเห็นที่มีให้ใน privacysandbox.com, การประชุมกับผู้มีส่วนเกี่ยวข้องในอุตสาหกรรม และฟอรัมมาตรฐานเว็บ Chrome ยินดีรับฟังความคิดเห็นที่ได้รับจากระบบนิเวศและกำลังดำเนินการสำรวจวิธีการต่างๆ ในการผสานรวมสิ่งที่เรียนรู้เข้ากับการตัดสินใจด้านการออกแบบ
ธีมความคิดเห็นจะจัดอันดับตามความแพร่หลายต่อ API ซึ่งทำได้โดยรวบรวมความคิดเห็นที่ทีม Chrome ได้รับจากธีมที่กำหนด และจัดระเบียบปริมาณจากมากไปหาน้อย ธีมความคิดเห็นที่พบบ่อยมาจากการตรวจสอบหัวข้อการพูดคุยจากการประชุมสาธารณะ (W3C, PatCG, IETF), ความคิดเห็นโดยตรง, GitHub และคำถามที่พบบ่อยซึ่งนำเสนอผ่านทีมภายในของ Google และแบบฟอร์มสาธารณะ
กล่าวอย่างเจาะจงก็คือ รายงานการประชุมของหน่วยงานมาตรฐานในเว็บได้รับการตรวจสอบ และสำหรับความคิดเห็นโดยตรง Google มีการพิจารณาบันทึกการประชุมของผู้มีส่วนเกี่ยวข้องแบบ 1:1, อีเมลที่วิศวกรแต่ละคนได้รับ, รายชื่ออีเมล API และแบบฟอร์ม แสดงความคิดเห็นสาธารณะ จากนั้น Google ได้ประสานงานระหว่างทีมที่เกี่ยวข้องกับกิจกรรมช่วยเหลือต่างๆ เหล่านี้เพื่อระบุความแพร่หลายของธีมที่เกิดขึ้นโดยเทียบกับ API แต่ละรายการ
คำอธิบายคำตอบของ Chrome ที่มีต่อความคิดเห็นของ Chrome นั้นพัฒนาขึ้นจากคำถามที่พบบ่อยที่มีการเผยแพร่ คำตอบที่เกิดขึ้นจริงต่อปัญหาที่ผู้มีส่วนเกี่ยวข้องเป็นผู้หยิบยกขึ้นมา และการกำหนดจุดยืนโดยเฉพาะเพื่อวัตถุประสงค์ในการจัดทำรายงานต่อสาธารณะนี้ ซึ่งได้รับความสนใจเป็นพิเศษจากหัวข้อ, Protected Audience และ Attribution Reporting API จะแสดงให้เห็นถึงความสำคัญในปัจจุบันของการพัฒนาและการทดสอบ
ความคิดเห็นที่ได้รับหลังจากสิ้นสุดระยะเวลาการรายงานปัจจุบันอาจยังไม่ได้รับคำตอบจาก Chrome
อภิธานศัพท์ของตัวย่อ
- ชิป
- คุกกี้ที่มีสถานะแบ่งพาร์ติชันอิสระ
- DSP
- แพลตฟอร์มฝั่งดีมานด์
- FedCM
- การจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์
- FPS
- ชุดบุคคลที่หนึ่ง
- IAB
- สมาคมโฆษณาอินเทอร์แอกทีฟ (Interactive Advertising Bureau)
- IdP
- ผู้ให้บริการข้อมูลประจำตัว
- IETF
- คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต
- อินนิ่ง
- ที่อยู่ Internet Protocol
- openRTB
- การเสนอราคาแบบเรียลไทม์
- OT
- ช่วงทดลองใช้จากต้นทาง
- PatCG
- กลุ่มชุมชนเทคโนโลยีการโฆษณาส่วนตัว
- RP
- ฝ่ายพึ่งพา
- SSP
- แพลตฟอร์มฝั่งซัพพลาย
- TEE
- สภาพแวดล้อมการดำเนินการที่เชื่อถือได้
- UA
- สตริง User Agent
- UA-CH
- คำแนะนำไคลเอ็นต์ User Agent
- W3C
- World Wide Web Consortium
- อยู่ระหว่างดำเนินการ
- การตาบอด IP แบบจงใจ
ความคิดเห็นทั่วไป ไม่มี API/เทคโนโลยีที่เฉพาะเจาะจง
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การกำกับดูแลข้อมูลและการปฏิบัติตามกฎระเบียบ | คำแนะนำด้านระบบนิเวศในการใช้ Privacy Sandbox ตามข้อกำหนดด้านกฎระเบียบ | เช่นเดียวกับเทคโนโลยีใหม่อื่นๆ แต่ละบริษัทมีหน้าที่ตรวจสอบว่าการใช้ Privacy Sandbox เป็นไปตามกฎหมาย Google ไม่สามารถให้คำแนะนำทางกฎหมายแก่ผู้อื่นได้ อย่างไรก็ตาม เราทราบดีว่านี่เป็นเรื่องที่น่าสนใจสำหรับระบบนิเวศนี้ สำหรับ API แต่ละรายการ เราได้เผยแพร่เอกสารทางเทคนิคที่ครบถ้วนสมบูรณ์ ซึ่งน่าจะเป็นพื้นฐานสำหรับการประเมินทางกฎหมายที่จำเป็น และเรากำลังพยายามทำให้มีเอกสารเพิ่มเติม เพื่อสนับสนุนความพยายามของบริษัทในการปฏิบัติตามข้อกำหนดที่เป็นระเบียบข้อบังคับ |
ข้อเสนอการทดสอบเชิงปริมาณของ CMA | ข้อมูลเพิ่มเติมเกี่ยวกับข้อเสนอการทดสอบเชิงปริมาณของ CMA | เรากำลังทำงานร่วมกับ CMA เพื่อออกแบบการทดสอบที่จะแสดงให้เห็นภาพของผลกระทบจากการเลิกใช้งานคุกกี้ของบุคคลที่สามและการเปิดตัวข้อเสนอ Privacy Sandbox ในระบบนิเวศ ในเดือนเมษายน CMA ได้เผยแพร่คำแนะนำระดับสูงเกี่ยวกับสิ่งที่จะเกิดขึ้นในระยะเวลาการทดสอบและทดลอง ตามด้วยคำแนะนำโดยละเอียดในเดือนมิถุนายน เราขอแนะนำให้แชร์คำถามหรือความคิดเห็นเกี่ยวกับข้อเสนอการทดสอบเชิงปริมาณของ CMA กับ CMA โดยตรง |
โหมดการทดสอบที่อำนวยความสะดวกโดย Chrome | ข้อมูลเพิ่มเติมและการชี้แจงเกี่ยวกับกำหนดการทดสอบ | เราได้เผยแพร่บล็อกโพสต์เมื่อวันที่ 18 พฤษภาคมเพื่อแชร์ข้อมูลเพิ่มเติมเกี่ยวกับการทดสอบ 2 โหมดที่อำนวยความสะดวกโดย Chrome รายละเอียดเหล่านี้ยังไม่เป็นที่สิ้นสุด และเราจะเผยแพร่คําแนะนําเพิ่มเติมในการติดตั้งใช้งานในไตรมาสที่ 3 ปี 2023 |
พื้นที่เก็บข้อมูลที่แบ่งพาร์ติชันแล้ว | จะมีการใช้พื้นที่เก็บข้อมูลที่แบ่งพาร์ติชันระหว่างการทดสอบที่อำนวยความสะดวกโดย Chrome ไหม | ระบบจะส่งการแบ่งพาร์ติชันพื้นที่เก็บข้อมูลไปยังผู้ใช้ทั้งหมดก่อนการทดสอบการเลิกใช้งานคุกกี้ของบุคคลที่สาม การทดสอบจึงจะเปิดใช้ได้ เว็บไซต์จะมีตัวเลือกในการเปิดใช้ช่วงทดลองใช้การเลิกใช้งานเพื่อรับพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชันในระยะเวลานี้ |
การสนับสนุนด้านการผลิต | Chrome มีกระบวนการใดบ้างในการสนับสนุนปัญหาทางเทคนิคและการส่งต่อปัญหาของ Privacy Sandbox ที่ส่งผลต่อระบบนิเวศ | Google มีช่องทางต่างๆ มากมายที่ช่วยให้เทคโนโลยีโฆษณาสามารถรายงานปัญหาและส่งต่อเรื่องที่จำเป็นได้ โปรดดูข้อมูลเพิ่มเติมเกี่ยวกับฟอรัมสาธารณะและส่วนตัวสำหรับความคิดเห็นและการส่งต่อเรื่องได้จากโพสต์สำหรับนักพัฒนาซอฟต์แวร์ |
ลำดับเวลาการลงทะเบียน | กรอบเวลาการลงทะเบียนปัจจุบันสั้นเกินไป | เรายังคงประเมินกำหนดเวลาการบังคับใช้อยู่และต้องการทราบความคิดเห็นจากระบบนิเวศว่าจะใช้ลำดับเวลาใดที่เหมาะสมกว่ากัน |
หมายเลข D-U-N-S | ข้อมูลเพิ่มเติมเกี่ยวกับข้อกำหนดหมายเลข D-U-N-S สำหรับการลงทะเบียนและเอกสารรับรอง | ผู้เข้าร่วมดูข้อกำหนดในการขอรับหมายเลข D-U-N-S ได้ในเว็บไซต์ Dun and Bradstreet ความต้องการจะแตกต่างกันไปตามตลาด ดังนั้นผู้เข้าร่วมควรแน่ใจว่าได้ตรวจสอบเว็บไซต์สำหรับตลาดที่พวกเขาสนใจ อย่างไรก็ตาม โดยทั่วไปผู้เข้าร่วมจะต้องให้ข้อมูลพื้นฐานเกี่ยวกับธุรกิจของตน เช่น ชื่อธุรกิจ ที่อยู่ และข้อมูลติดต่อสำหรับเจ้าของธุรกิจหรือผู้จัดการ นอกจากนี้ระบบยังอาจขอให้ผู้เข้าร่วมระบุข้อมูลทางการเงิน เช่น รายได้ต่อปีของธุรกิจ เมื่อการสมัครเสร็จสมบูรณ์ D&B จะตรวจสอบและออกหมายเลข D-U-N-S หากใบสมัครได้รับการอนุมัติ |
การเปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไป | การเปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไปจะส่งผลต่อผู้ทดสอบเวอร์ชันทดลองจากต้นทางในปัจจุบันไหม | ตั้งแต่เดือนกรกฎาคม ผู้ทดสอบจะเข้าถึง API ความเกี่ยวข้องและ Measurement API ในเวอร์ชันสำหรับผู้ใช้ทั่วไปได้ ซึ่งจะทับซ้อนระหว่างความพร้อมให้บริการของช่วงทดลองใช้จากต้นทางกับเวอร์ชันสำหรับผู้ใช้ทั่วไป |
การศึกษาของ AdExchanger | ข้อมูลเพิ่มเติมเกี่ยวกับวิธีการสำรวจ | แบบสำรวจนี้ขอให้ผู้ตอบประเมินอัตราการซิงค์และรายได้สำหรับธุรกิจของตน ผู้ตอบจะเป็นผู้เลือกใช้วิธีการตอบคำถามแต่ละข้อ |
ค่าพารามิเตอร์ | ค่าพารามิเตอร์ เช่น ระดับสัญญาณรบกวน เกณฑ์การไม่ระบุตัวตน และงบประมาณด้านความเป็นส่วนตัว ได้รับการกำหนดอย่างไร | คำอธิบายเกี่ยวกับ GitHub นี้จะอธิบายหลักการทั่วไปที่อยู่เบื้องหลัง Privacy Sandbox API มีหลายค่าที่ยังอยู่ระหว่างการสรุปและเรายินดีรับฟังความคิดเห็นเกี่ยวกับเรื่องนี้ |
แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง
หัวข้อ
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การรักษาความเป็นส่วนตัว | งานวิจัยที่ประเมิน Topics API เกี่ยวกับการสงวนความเป็นส่วนตัว | เรามีส่วนร่วมกับชุมชนการวิจัยอย่างเต็มที่ โดยนำเสนอการวิจัยเกี่ยวกับคุณสมบัติความเป็นส่วนตัวของ Topics API ในเอกสาร รายงาน และงานนำเสนอสำหรับเวิร์กช็อป เราดีใจที่ได้เห็นสมาชิกภายนอกของชุมชนการวิจัยมีส่วนร่วมกับส่วนนี้มากขึ้น Topics API ช่วยปกป้องผู้ใช้จากการติดตามทั่วไปในเว็บด้วยการทําให้ติดตามผู้ใช้ในวงกว้างได้ยากเกินไป รายงานเหล่านี้แสดงให้เห็นว่าเราประสบความสำเร็จกับ Topics API ได้อย่างไร มีความเป็นส่วนตัวมากกว่าคุกกี้ของบุคคลที่สามและปกป้องผู้ใช้ไปพร้อมๆ กับสนับสนุนเว็บไซต์ที่พวกเขาชอบเข้าชม |
การจัดหมวดหมู่หัวข้อมีรายละเอียดไม่เพียงพอ | การจัดหมวดหมู่หัวข้อแบบกว้างจะไม่รวมหัวข้อที่ละเอียดยิ่งขึ้น ซึ่งรวมถึงหัวข้อเฉพาะ | เราได้เผยแพร่บล็อกโพสต์เมื่อวันที่ 15 มิถุนายน เพื่อตอบสนองต่อความคิดเห็นที่ได้รับในครั้งก่อนหน้าจากระบบนิเวศนี้ ซึ่งให้รายละเอียดเกี่ยวกับการจัดหมวดหมู่ใหม่ที่อัปเดต ซึ่งมีการปรับปรุงมากมายตามความคิดเห็นจากระบบนิเวศ ในส่วนหนึ่งของการดำเนินงานเกี่ยวกับการจัดหมวดหมู่ฉบับแก้ไขนี้ เราได้ร่วมงานกับบริษัทหลายแห่งในระบบนิเวศ เช่น Raptive (เดิมคือ CafeMedia) และ Criteo การจัดหมวดหมู่ที่อัปเดตนี้จะลบหมวดหมู่ที่เราได้ยินมานั้นไม่ค่อยมีประโยชน์ โดยการเปลี่ยนไปใช้หมวดหมู่ที่ตรงกับความสนใจของผู้ลงโฆษณามากกว่า ขณะเดียวกันก็ยังคงความมุ่งมั่นของเราในการยกเว้นหัวข้อที่อาจมีความละเอียดอ่อน เราขอแนะนำให้ระบบนิเวศตรวจสอบการจัดหมวดหมู่ล่าสุดและแสดงความคิดเห็นเกี่ยวกับการเปลี่ยนแปลงดังกล่าว |
กระบวนการอัปเดตการจัดหมวดหมู่และตัวแยกประเภท | ข้อมูลเพิ่มเติมเกี่ยวกับการจัดหมวดหมู่ Topics และตารางการเผยแพร่ตัวแยกประเภท และวิธีการเตรียมความพร้อมสำหรับบริษัทต่างๆ สำหรับการอัปเดตดังกล่าว | ตามที่ได้แจ้งไว้ในบล็อกโพสต์ล่าสุด เราคาดว่าการจัดหมวดหมู่มีการเปลี่ยนแปลงเมื่อเวลาผ่านไป และเพื่อการกำกับดูแลของการจัดหมวดหมู่จะมีการเปลี่ยนเป็นภายนอกที่เป็นตัวแทนของผู้มีส่วนเกี่ยวข้องจากทั่วทั้งอุตสาหกรรมในที่สุด และเรายังได้แชร์แผนการเพิ่มจำนวนในกลุ่มประกาศเรื่องด้วย |
ผลกระทบต่อสัญญาณของบุคคลที่หนึ่ง | จํานวน Topics ที่เพิ่มขึ้นในการอัปเดตการจัดหมวดหมู่ล่าสุดอาจมีมูลค่าสูง และทำให้สัญญาณตามความสนใจของบุคคลที่หนึ่งอื่นๆ ลดลง | ในรายงานไตรมาสที่ 1 ปี 2023 CMA แสดงความคิดเห็นว่า "เราทราบว่า Google ได้หารือเกี่ยวกับการจัดหมวดหมู่ใหม่ที่นำเสนอกับผู้เข้าร่วมตลาดหลายรายในซัพพลายเชนของเทคโนโลยีโฆษณา ในขณะที่ผู้เผยแพร่โฆษณารายใหญ่บางรายกล่าวว่าประโยชน์เพิ่มเติมจากหัวข้อจะช่วยเพิ่มแรงกดดันในการแข่งขันให้กับโซลูชันที่อิงตามข้อมูลจากบุคคลที่หนึ่ง แต่มุมมองเบื้องต้นของเราคือประโยชน์ที่มากขึ้นจะดีกว่าสำหรับการแข่งขันโดยรวม โดยเฉพาะความสามารถของผู้เผยแพร่โฆษณาขนาดเล็กในการสร้างรายได้ต่อพื้นที่โฆษณาของตนต่อไปหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม" เราเห็นด้วยกับความคิดเห็นนี้ของ CMA |
ความมีประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ | เทคโนโลยีโฆษณาที่ทำหน้าที่เป็น SSP และ DSP อาจมีข้อได้เปรียบที่สำคัญเหนือกว่าผู้เล่นในระบบนิเวศอื่นๆ | การตอบสนองของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่แล้ว "Google ให้คำมั่นสัญญากับ CMA เพื่อออกแบบและนำข้อเสนอ Privacy Sandbox ไปใช้ในลักษณะที่ไม่ทำให้การแข่งขันบิดเบือนจากการแข่งขันด้วยการกล่าวถึงธุรกิจของ Google ด้วยตนเอง และคำนึงถึงผลกระทบต่อการแข่งขันในการโฆษณาดิจิทัล รวมถึงผลกระทบต่อผู้เผยแพร่โฆษณาและผู้ลงโฆษณาด้วย ไม่ว่าจะมีขนาดเท่าใดก็ตาม เราทำงานอย่างใกล้ชิดกับ CMA อย่างต่อเนื่องเพื่อให้มั่นใจว่างานของเราสอดคล้องกับความมุ่งมั่นเหล่านี้ ขณะที่การทดสอบ Privacy Sandbox คืบหน้าไป หนึ่งในคำถามสำคัญที่เราจะประเมินคือประสิทธิภาพของเทคโนโลยีใหม่สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ ความคิดเห็นเป็นสิ่งสำคัญในเรื่องนี้ โดยเฉพาะความคิดเห็นที่เฉพาะเจาะจงและนำไปใช้ได้จริง ซึ่งจะช่วยให้เราปรับปรุงการออกแบบทางเทคนิคเพิ่มเติมได้ เราได้ทำงานร่วมกับ CMA เพื่อพัฒนาแนวทางการทดสอบเชิงปริมาณ รวมถึงสนับสนุน CMA ที่ได้เผยแพร่หมายเหตุเกี่ยวกับการออกแบบการทดสอบเพื่อให้ข้อมูลเพิ่มเติมแก่ผู้เข้าร่วมตลาดและโอกาสที่จะได้แสดงความคิดเห็นเกี่ยวกับแนวทางที่เราเสนอ" |
หัวข้อสืบทอด | เมื่อใช้เกณฑ์การเลือกหัวข้อซึ่งก็คือความถี่ของการเข้าชมเบราว์เซอร์ การแยกส่วนตามหัวข้อจะทำให้หัวข้อที่ต่อเนื่องกันไม่ขึ้นไปอยู่ในอันดับสูงสุดหรือไม่ | Chrome กำลังประเมินวิธีการจัดอันดับอื่นๆ และสำรวจสัญญาณอื่นๆ ที่อาจส่งผลต่อการจัดอันดับดีขึ้น เราจะแจ้งแผนที่แก้ไขแล้วให้ระบบนิเวศทราบโดยเร็วที่สุด |
ความไว | เป้าหมายของ Topics API ควรเป็นเพื่อให้มั่นใจว่าข้อมูลผู้ใช้ที่ได้มาหรือได้มาจาก Topics API ควรมีความละเอียดอ่อนส่วนบุคคลน้อยกว่าสิ่งที่ได้มาจากวิธีการติดตามในปัจจุบัน | เราเชื่อว่า Topics API มีความเป็นส่วนตัวมากกว่าเทคโนโลยีปัจจุบันอย่างมาก จำกัดการระบุตัวตนผู้ใช้ซ้ำเป็นอย่างมาก และออกแบบมาเพื่อยกเว้นหัวข้อที่ละเอียดอ่อน เรารับทราบว่าหัวข้ออาจเชื่อมโยงหรือรวมกับข้อมูลจากบุคคลที่หนึ่งเพื่อสร้างหมวดหมู่ที่ละเอียดอ่อนได้ แต่เราเชื่อว่า Topics API เป็นการก้าวไปสู่ความเป็นส่วนตัวของผู้ใช้ และเรามุ่งมั่นที่จะปรับปรุง API นี้อย่างต่อเนื่อง |
โครงสร้างการจัดหมวดหมู่ | เพิ่มรหัส การกำหนดเวอร์ชัน และโครงสร้างข้อมูลเมตาอื่นๆ ในการจัดหมวดหมู่หัวข้อ | ขณะนี้เราได้รวมรหัสการจัดหมวดหมู่ไว้ในการตอบกลับของ API เนื่องจากเราจะก้าวไปสู่การกํากับดูแลระยะยาว ดังนั้นการตรวจสอบออบเจ็กต์ Topics และรวมข้อมูลเมตาเพิ่มเติมเกี่ยวกับการกำหนดเวอร์ชันหากจำเป็น |
การควบคุมของผู้เผยแพร่โฆษณา | ผู้เผยแพร่โฆษณาควรมีสิทธิ์ออกหัวข้อว่า Topics เว็บไซต์ของตนควรจัดอยู่ในประเภทใด | การจัดประเภทเว็บไซต์ที่ไม่ถูกต้องอาจทำให้สัญญาณ Topics มีประโยชน์น้อยลงเล็กน้อยเมื่อเป็นสัญญาณโดยรวม แต่เว็บไซต์ที่เจาะจงซึ่งจัดหมวดหมู่ผิดนั้นไม่ส่งผลเสียต่อปัญหานี้มากไปกว่าเว็บไซต์อื่นๆ เนื่องจากข้อมูลบริบทของเว็บไซต์จะมีสำหรับการประมูลในเว็บไซต์อยู่เสมอ ซึ่งจะให้ข้อมูลที่เทียบเคียงได้กับหัวข้อที่ถูกต้อง แม้จะเป็นการจัดประเภทที่ไม่ถูกต้องก็ตาม เรายินดีรับความคิดเห็นในเรื่องนี้ที่นี่ การอนุญาตให้ผู้เผยแพร่โฆษณาควบคุมการจัดประเภทของตนมีความเสี่ยง เว็บไซต์อาจจัดประเภทเว็บไซต์ของตนผิดประเภทโดยเจตนา ลดประโยชน์ในการใช้งานสำหรับทุกคน หรือเข้ารหัสความหมายที่ละเอียดอ่อนในหัวข้อที่พบไม่บ่อยนัก ซึ่งเป็นอันตรายต่อความเป็นส่วนตัวของผู้ใช้ |
ส่วนขยาย Chrome | อนุญาตให้ส่วนขยาย Chrome จัดการและกรองหัวข้อ ซึ่งคล้ายกับส่วนขยายการจัดการคุกกี้ปัจจุบัน | ซึ่งน่าจะเป็นไปได้อยู่แล้วตามที่ได้กล่าวไปใน GitHub แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
การเปลี่ยนไปใช้รุ่นสำหรับผู้ใช้ทั่วไป | จะมีผลกระทบต่อ Topics API ไหมเมื่อเปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไป | ข้อมูลของผู้ที่เปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไปจะไม่สูญหาย |
ความเป็นส่วนตัว | ชื่อโฮสต์อาจมีข้อมูลส่วนตัวที่อาจเปิดเผยโดย Topics API | เรามีการบรรเทาปัญหาหลายอย่างเพื่อรักษาความเป็นส่วนตัวตามที่อธิบายไว้ที่นี่ |
การประพฤติมิชอบและการละเมิด | วิธีป้องกันการบิดเบือน Topics โดยการเข้าชมที่เป็นการฉ้อโกง | ดูคำอธิบายเกี่ยวกับการลดปัญหาได้ที่นี่ |
ตัวแยกประเภทหัวข้อ | เว็บไซต์จะขอเปลี่ยนการจัดประเภทหัวข้อได้ไหม | เราอยากรับฟังความคิดเห็นเกี่ยวกับหัวข้อนี้จากระบบนิเวศและความคิดเห็นต้อนรับที่นี่ |
เว็บไซต์ของผู้ให้บริการ Topics | กำหนดเว็บไซต์บางแห่งที่โฮสต์เนื้อหาสำหรับ Topics จำนวนมากเป็น "เว็บไซต์ของผู้ให้บริการหัวข้อพิเศษ" และฝึกตัวแยกประเภทตามแท็กที่ให้ไว้ในหน้าเว็บ | เรากำลังพูดคุยเรื่องข้อเสนอที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม |
Protected Audience API (ก่อนหน้านี้เรียกว่า FLEDGE)
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การกำหนดรูปแบบการเข้าชม | ผลด้านประสิทธิภาพของการกรองที่ทำงานด้วย SSP เพื่อเพิ่มประสิทธิภาพการโหลดการค้นหาต่อวินาที (QPS) | เราใช้เวลานานมากในการคิดรูปแบบการเข้าชม และข้อเสนอแนะคือให้ SSP ใช้ประโยชน์จากการแคช |
กำลังทดสอบระดับเสียง | การทดสอบ Protected Audience เป็นอุปสรรค เนื่องจาก SSP และ DSP พบปัญหาในการรับการเข้าชมปริมาณมาก | เราร่วมมือกับพาร์ทเนอร์ SSP และ DSP อย่างต่อเนื่องเพื่อใช้และทดสอบ Protected Audience เวอร์ชันสำหรับผู้ใช้ทั่วไปได้เริ่มขึ้นแล้วและเรามั่นใจว่าเปอร์เซ็นต์การเข้าชมที่มีการเปิดใช้ PA จะทำให้พาร์ทเนอร์ทดสอบได้อย่างสบายใจมากขึ้น |
ความซับซ้อน | การนำโซลูชัน Protected Audience ไปใช้นั้นต้องใช้ความพยายามและต้นทุนสูง | เราตระหนักดีว่าเทคโนโลยีใหม่ๆ นั้นนำมาใช้ได้ยาก ซึ่งรวมถึง Privacy Sandbox ทีม Privacy Sandbox ทํางานอย่างใกล้ชิดกับผู้มีส่วนเกี่ยวข้องต่างๆ มากมายเพื่อให้ความรู้และสนับสนุนความพยายามของตน อีกทั้งมีการประเมินตัวเร่งอื่นๆ อย่างต่อเนื่องเพื่อสนับสนุนการใช้งานในระบบนิเวศ |
สภาพแวดล้อมการดำเนินการที่เชื่อถือได้ | การสนับสนุนสำหรับ Trusted Execution Environments (TEE) ในสภาพแวดล้อมระบบคลาวด์ที่ไม่ใช่สาธารณะ | แม้ว่าเรากำลังสำรวจตัวเลือกที่อาจสนับสนุนนอกเหนือจากโซลูชันระบบคลาวด์ แต่ขณะนี้ก็ยังไม่สามารถรองรับ TEE ภายในองค์กรได้ เนื่องจากมีข้อจำกัดด้านความปลอดภัยภายในองค์กร ซึ่งยังต้องประเมินเวลา Privacy Sandbox อยู่นาน เมื่อพิจารณาจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และความท้าทายสำคัญที่ได้รับจากการติดตั้งใช้งานภายในองค์กร เราเชื่อว่าการขยายและปรับปรุงการติดตั้งใช้งานในระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ GCP เพิ่มเติมจาก AWS) คือประโยชน์มากที่สุดสำหรับระบบนิเวศนี้ อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่จำเป็นต้องมีข้อกำหนดดังกล่าว |
โครงสร้างค่าใช้จ่าย | ข้อเสนอการเสนอราคาและบริการประมูลจะเพิ่มค่าใช้จ่ายและความซับซ้อนของเทคโนโลยีโฆษณาเมื่อเทียบกับรูปแบบฝั่งไคลเอ็นต์ | ขณะนี้เรากำลังพัฒนาคู่มือในการประมาณต้นทุนในการรองรับการเสนอราคาและเวิร์กโฟลว์การประมูลในเซิร์ฟเวอร์การเสนอราคาและการประมูล ซึ่งจะสัมพันธ์กับการใช้เทคโนโลยีโฆษณาเพื่อบรรลุเป้าหมายการออกแบบของเรา |
ไทม์ไลน์ของ K-Anon | ข้อจำกัด k-anonymity ที่วางแผนไว้จะบังคับใช้ใน "renderUrl" เมื่อใด | เรากำลังดำเนินการอธิบายลำดับเวลาการบังคับใช้ที่จะเปิดตัวเร็วๆ นี้ |
ข้อจำกัดในการเรียกใช้ AdAuction | Chrome จำกัดให้เรียกใช้ runAdAuction จากหน้าด้านบนเท่านั้นได้ไหม |
แม้ว่าการออกแบบของเรารองรับ runAdAuction ให้เรียกจากหน้าแรกได้อย่างเต็มรูปแบบ แต่เราเชื่อว่าการทำให้ผู้เผยแพร่โฆษณาสามารถเรียกใช้ฟังก์ชันนั้นต้องโทรจากโดเมนระดับบนสุดเท่านั้นที่จะเป็นอันตรายมากกว่าเราทราบมาโดยเจาะจงจากระบบนิเวศว่า Privacy Sandbox ต้องการลดภาระของผู้เผยแพร่โฆษณาและผู้ลงโฆษณา ความคิดเห็นดังกล่าวสอดคล้องกับหลักการทั่วไปของการพัฒนาเว็บที่เจ้าของเว็บไซต์สามารถใช้เครื่องมือของบุคคลที่สามในการดูแลเว็บไซต์ได้ เป้าหมายของ Privacy Sandbox คือการส่งเสริมให้มีระบบนิเวศที่ดีโดยที่ไม่จำเป็นต้องกําหนดวิธีการทำงานของผู้เผยแพร่โฆษณาและเทคโนโลยีโฆษณา เราเชื่อว่าการอนุญาตให้ผู้เผยแพร่โฆษณาเลือกวิธีและบุคคลที่เรียกใช้ runAdAuction ในเว็บไซต์ของตนทำให้เรามีความยืดหยุ่นแก่ผู้เผยแพร่โฆษณาในการค้นหาเส้นทางที่ดีที่สุดตามความต้องการของตน |
การสนับสนุนการใช้งาน | Chrome สามารถสร้างหรือสนับสนุนการใช้งานโอเพนซอร์สของการประมูลผู้ขายหลายรายได้หรือไม่ | Privacy Sandbox มีเป้าหมายที่จะพัฒนาเทคโนโลยีการรักษาความเป็นส่วนตัวที่ไม่ใช้คุกกี้ของบุคคลที่สามหรือตัวระบุข้ามเว็บไซต์อื่นๆ เราต้องการส่งเสริมระบบนิเวศที่ดีโดยไม่ต้องอธิบายถึงการทำงานของเทคโนโลยีโฆษณา เราได้เผยแพร่คำแนะนำเกี่ยวกับวิธีการทำงานของ API ในที่เก็บ GitHub ของเรา และเปิดกว้างที่จะสำรวจโซลูชันร่วมกับอุตสาหกรรม เราไม่มีแผนที่จะพัฒนารูปแบบที่เฉพาะเจาะจงใดๆ เนื่องจากข้อเสนอหลักของเราคือการสร้างเทคโนโลยีแพลตฟอร์ม ไม่ใช่การกำหนดกลยุทธ์สำหรับการใช้เทคโนโลยีเหล่านั้น เทคโนโลยีของเราจะช่วยให้บริษัทเทคโนโลยีโฆษณาให้บริการลูกค้าได้ดีที่สุดด้วยขอบเขตความเป็นส่วนตัวที่เหมาะกับผู้บริโภค |
การประมูลกับผู้ขายหลายราย | Chrome จะบังคับให้แชร์ผู้ชนะ "ตามบริบท" กับการประมูลคอมโพเนนต์หรือไม่ | Protected Audience API ได้รับการออกแบบมาเพื่อมอบความสามารถให้กับบุคคลที่เริ่มการประมูลผู้ขายหลายราย ในการส่งผ่านข้อมูลไปยังการประมูลคอมโพเนนต์ (หมายเหตุ: ก่อนเริ่มการประมูลเท่านั้น) อย่างไรก็ตาม เราไม่เห็นช่องทางให้เบราว์เซอร์แยกแยะได้ว่าข้อมูลชิ้นหนึ่งๆ จะถูกต้องตามบริบทหรือไม่ เราจึงบังคับใช้การบล็อกหรือกำหนดให้ข้อมูลบางอย่างไม่ได้ |
ค่ากําหนดของผู้ใช้สําหรับการติดตามความยินยอม | Adtech ขอให้ PA ติดตั้งใช้งานการติดตามความยินยอมของผู้ใช้อย่างถูกต้อง | ผลตอบรับของเรารวมถึงสิ่งที่เราพูดในไตรมาสที่ 1 ด้วย: "เทคโนโลยีโฆษณาที่เกี่ยวข้องคือฝ่ายที่เหมาะสมที่สุดสำหรับการควบคุมว่าจะให้ครีเอทีฟโฆษณาใดแสดงหรือวิธีเลือกครีเอทีฟโฆษณาใด" เราได้พูดคุยเกี่ยวกับสถานการณ์ที่เกี่ยวข้องกับปัญหานี้ระหว่างการประชุม Protected Audience สำหรับ WICG ประจำเดือนพฤษภาคม และเรายินดีรับฟังความคิดเห็นและการพูดคุยเพิ่มเติมเกี่ยวกับปัญหานี้ |
กลุ่มเป้าหมายที่กำหนดเอง | Protected Audience API จะรองรับ Use Case ของ SSP ที่เกี่ยวข้องกับการสร้างกลุ่มเป้าหมายที่กำหนดเองไหม | Protected Audience API ช่วยให้ SSP และผู้ให้บริการเทคโนโลยีโฆษณาอื่นๆ เป็นเจ้าของและจัดการกลุ่มเป้าหมายที่กำหนดเองได้ เรากำลังพัฒนาคำแนะนำเพิ่มเติมเกี่ยวกับวิธีที่ SSP ผสานรวมกับ PA API และจะเปิดให้ SSP และผู้ให้บริการเทคโนโลยีโฆษณาอื่นๆ สนับสนุนความพยายามในการผสานรวม |
รูปแบบ | Protected Audience API รองรับวิดีโอไหม | โฆษณาวิดีโอจะแสดงด้วยวิธีใดวิธีหนึ่งจาก 2 วิธี ได้แก่ VAST XML หรือ HTML (โฆษณานอกสตรีมที่อาจโหลด VAST XML ลงในโปรแกรมเล่นวิดีโอด้วย) ผู้ซื้อสามารถส่งกลับรูปแบบใดรูปแบบหนึ่งได้ผ่านทาง RenderURL ข้อกำหนดของ VAST เพิ่งได้รับการอัปเดตเมื่อเร็วๆ นี้เพื่อรองรับ Attribution Reporting API เว็บไซต์ที่แสดงโฆษณาวิดีโอจะต้องเตรียมพร้อมสำหรับวิธีการแสดงโฆษณาผ่าน Protected Audience API ซึ่งหมายความว่าแท็กตำแหน่งโฆษณาสามารถส่ง URL จาก iframe ของ Protected Audience ไปยังโปรแกรมเล่นวิดีโอได้ สำหรับ Fenced Frame เราจะพยายามแก้ไขปัญหาเกี่ยวกับวิดีโอก่อนข้อกำหนดให้ใช้ Fenced Frame ซึ่งก่อนปี 2026 |
ความเร็วในการบรรลุเป้าหมาย | กรณีการใช้งานการกำหนดอัตราการแสดงโฆษณาทำงานร่วมกับ Protected Audience API อย่างไร | ขอขอบคุณสำหรับความคิดเห็น เราต้องการเห็นอินสแตนซ์อื่นๆ ของคำขอนี้ ซึ่งมีรายละเอียดเพิ่มเติมมาจากพาร์ทเนอร์ SSP จำนวนมากขึ้น เนื่องจากที่ผ่านมาตอนนี้เป็นข้อกังวลเกี่ยวกับ DSP เป็นส่วนใหญ่ |
ความถี่ในการอัปเดต | ความถี่ของการโทรจาก dailyUpdate (สูงสุด 1 สายต่อกลุ่มความสนใจต่อวัน) อาจไม่เพียงพอสำหรับการใช้งานบางกรณี เช่น การอัปเดตข้อมูลผลิตภัณฑ์ |
ขอขอบคุณสำหรับความคิดเห็น ยังมีโซลูชันอื่นๆ ที่พร้อมให้เทคโนโลยีโฆษณาใช้สัญญาณที่มีการรีเฟรชตามความถี่ต่างๆ กัน เช่น การค้นหา K/V |
การควบคุมคุณภาพของโฆษณา | ผู้เผยแพร่โฆษณาใช้การควบคุมคุณภาพโฆษณาอย่างไร | ปัจจุบัน Protected Audience API มีฟังก์ชันให้ผู้เผยแพร่โฆษณาแจ้ง SSP เกี่ยวกับการควบคุมบางอย่างที่สามารถกำหนดเป็นส่วนหนึ่งของการกำหนดค่าการประมูล การเสนอราคาล่วงหน้า (เช่น รายการที่ปฏิเสธตามป้ายกำกับที่เชื่อมโยงกับโฆษณา) เรายินดีรับฟังความคิดเห็นเกี่ยวกับฟังก์ชันอื่นๆ ที่ระบบนิเวศอาจต้องการ |
การแก้ไขข้อบกพร่อง | ฟังก์ชันการทำงานของ forDebuggingOnly จะถูกนำออกเมื่อใด |
เราวางแผนที่จะเลิกใช้ forDebuggingOnly สำหรับเหตุการณ์ความสูญเสียเนื่องจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม เราวางแผนที่จะเลิกใช้ forDebuggingOnly สำหรับกิจกรรมที่จะชนะในปี 2026 อย่างเร็วที่สุด |
กลุ่มความสนใจข้ามอุปกรณ์ | ข้อเสนอเพื่อเปิดใช้กลุ่มความสนใจข้ามอุปกรณ์สำหรับ User Agent ที่ตรวจสอบสิทธิ์แล้ว | เรากำลังประเมินข้อเสนอนี้ แต่การกำหนดเป้าหมายจากหลายอุปกรณ์ที่มีความเฉพาะเจาะจงสูงก่อให้เกิดข้อกังวลเกี่ยวกับความเป็นส่วนตัวอย่างมาก ดังที่กล่าวไว้ในปัญหาของ GitHub นี้ |
(มีการรายงานในไตรมาส 1 ด้วย) รีมาร์เก็ตติ้งแบบไดนามิก | รีมาร์เก็ตติ้งแบบไดนามิกจะยังทําได้ด้วย Protected Audience API หลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามหรือไม่ | เราเชื่อว่ากรณีการใช้งานนี้เป็นไปได้เมื่อใช้ Protected Audience ตามที่อธิบายไว้ที่นี่ |
ข้อมูลที่เกี่ยวข้องกับคลิก | เพิ่มข้อมูลที่เกี่ยวข้องกับคลิกลงใน browserSignals. |
ขณะนี้ เรากำลังขอให้มีการชี้แจงว่าการคลิกเกิดขึ้นเมื่อใดเพื่อให้ตำแหน่งเบื้องต้น |
(มีการรายงานในไตรมาสที่ 4 ปี 2022 ด้วย) ฟังก์ชันที่กำหนดโดยผู้ใช้ใน Protected Audience | Protected Audience API จะรองรับฟังก์ชันที่กำหนดโดยผู้ใช้ (UDF) อย่างไร ต่อไปนี้เป็นฟังก์ชันที่ผู้ใช้ปลายทางตั้งโปรแกรมได้เพื่อขยายฟังก์ชันการทำงานของ API | เทคโนโลยีโฆษณาที่แจ้งปัญหานี้ก็กล่าวด้วยว่ากำลังประเมินสิ่งที่สามารถทำได้กับ UDF จึงยังไม่มีความคิดเห็นที่นำไปใช้ได้จริงที่จะตอบสนองต่อปัญหานี้ รวมถึงไม่ได้รอให้พร้อมใช้งานสำหรับเวอร์ชันสำหรับผู้ใช้ทั่วไปเป็นอย่างน้อย |
สกุลเงิน | จำนวนเงินสกุลเงินไม่ควรแสดงด้วยจุดทศนิยม | เราได้แก้ไขปัญหานี้โดยละเอียดที่นี่ |
ความสามารถในการเลือกโฆษณาที่ไม่ใช่ DSP | เซิร์ฟเวอร์โฆษณามีบทบาทอย่างไรในการประมูล Protect Audience API | เราทราบว่ามีคำขอให้เซิร์ฟเวอร์โฆษณาให้บริการการเลือกโฆษณาหลังการเสนอราคา / การเพิ่มประสิทธิภาพโฆษณาแบบไดนามิกต่อไป ขณะนี้เรากำลังประเมินการวิเคราะห์ช่องโหว่โดยละเอียดที่มีอยู่ระหว่าง Protected Audience API ปัจจุบันกับคำขอเหล่านี้ |
GenerateBid | การรองรับข้อเสนอของ Google Ads ให้แสดงโฆษณาตัวเลือกมากกว่า 1 รายการต่อกลุ่มความสนใจของโฆษณาจาก generateBid และผู้สมัครเหล่านั้นได้คะแนนใน "scoreAd" |
เรากําลังประเมินคำถามอยู่ เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่ |
คำสั่งซื้อของการประมูล | การประมูล Protected Audience API จำเป็นต้องเป็นการประมูลครั้งสุดท้ายหรือไม่ เพื่อให้สามารถรับข้อมูลจากผลของการประมูลอื่นๆ ทั้งหมด | ไม่มีข้อกำหนดทางเทคนิคที่จะทำให้ Protected Audience API ทำงานเป็นครั้งล่าสุด |
การนำทางที่ไม่ได้เริ่มต้นโดยผู้ใช้ | แสดงการไปยังส่วนต่างๆ ที่ไม่ได้เริ่มต้นโดยผู้ใช้ | เรากำลังตรวจสอบคำขอนี้และสนทนาเกี่ยวกับคำขอดังกล่าวที่นี่ รวมทั้งยินดีรับฟังความคิดเห็นเพิ่มเติม |
การแคช | SSP ไม่ควรสร้าง PerBuyerSignals ของ DSP ที่ระบุจากแคชหากสถานะผู้ใช้มีการเปลี่ยนแปลง | เราเข้าใจดีว่าการแคชใช้ไม่ได้กับ Use Case ทุกกรณีสำหรับสัญญาณต่อผู้ซื้อ และเรากำลังประเมินตัวเลือกอื่นๆ อยู่ เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าการแคชจะใช้ได้ผลกับกรณีการใช้งานของตนหรือไม่ |
การรายงานการระบุแหล่งที่มาและกลุ่มเป้าหมายที่มีการป้องกัน | Attribution Reporting API และ Protected Audience Audience API จะทำงานร่วมกันอย่างไร | ปัจจุบันการผสานรวมใช้ได้กับ Protected Audience API ทั้งสำหรับโหมด Attribution Reporting API (ระดับเหตุการณ์และรายงานสรุป) เราได้แชร์ข้อมูลเพิ่มเติมเกี่ยวกับการผสานรวม Protected Audience API และ Attribution Reporting ที่ปรับปรุงใหม่เมื่อวันที่ 1 มิถุนายน อ่านได้ที่นี่ |
ปลายทางเซิร์ฟเวอร์ | ปลายทางเซิร์ฟเวอร์จะเป็นเซิร์ฟเวอร์รวมที่เชื่อถือได้ในการออกแบบขั้นสุดท้ายหรือไม่ | ปลายทางเซิร์ฟเวอร์คือปลายทางที่ดูแลรักษาเทคโนโลยีโฆษณาซึ่งเป็นอิสระจากเซิร์ฟเวอร์รวบรวมข้อมูลที่เชื่อถือได้ซึ่งใช้ในการประมวลผลรายงานที่รวบรวมและเปลี่ยนรูปแบบ เรายังไม่มีการเปลี่ยนแปลงใดๆ ที่วางแผนไว้สำหรับปลายทางการรายงานในขณะนี้ การออกแบบปัจจุบันมีเป้าหมายเพื่อให้มั่นใจว่าตัวรายงานที่รวบรวมได้นั้น (โดยมีเพย์โหลดที่เข้ารหัส) ไม่ทำให้ข้อมูลข้ามเว็บไซต์รั่วไหล ดังนั้นจึงไม่จำเป็นต้องมีปลายทางที่เชื่อถือได้ ข้อมูลเสริมคือเทคโนโลยีโฆษณาที่แตกต่างกันมีแนวโน้มที่จะมีกลยุทธ์แบบกลุ่มที่ต้องการแตกต่างกัน เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่ |
WebIDL | ข้อมูลจำเพาะของ Protected Audience API ปัจจุบันใช้กับข้อกำหนด WebIDL ไม่ได้ | เรากำลังประเมินความคิดเห็นนี้และหารือเกี่ยวกับปัญหาที่นี่ |
การจัดการความยินยอม | การส่งสัญญาณความยินยอมใน Protected Audience API จะได้รับการจัดการอย่างไร | ข้อมูลตามบริบทไม่ได้อยู่ในขอบเขตของ Protected Audience API เรากำลังสนทนาเกี่ยวกับปัญหานี้และยินดีรับฟังความคิดเห็นเพิ่มเติม |
การตลาดตามบัญชี | กรณีการใช้งานการตลาดตามบัญชีสามารถทำได้หรือไม่ | Protected Audience API รองรับกรณีการใช้งานทางการตลาดตามกลุ่มเป้าหมายที่หลากหลาย เรายังคงทำความเข้าใจอย่างต่อเนื่องว่า Protected Audience API จะให้การสนับสนุนกรณีการใช้งานนี้อย่างดีที่สุดได้อย่างไร และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้จากระบบนิเวศ |
การประมูลคอมโพเนนต์ | ผู้เข้าร่วมการประมูลที่เป็นส่วนประกอบได้คะแนนอะไร | การประมูลคอมโพเนนต์ไม่ได้ให้คะแนนกลุ่มความสนใจโดยตรง แต่จะให้คะแนนโฆษณาและราคาเสนอที่ DSP ส่งจากฟังก์ชัน generateBid ฟังก์ชัน generateBid() จะทำงานต่อกลุ่มความสนใจ และ DSP จะส่งกลับข้อมูลต่อไปนี้เมื่อเรียกใช้ generateBid: return { 'ad': adObject, 'adCost': optionalAdCost, 'bid': bidValue, 'render': renderUrl, 'adComponents': [adComponent1, adComponent2, ...], 'allowComponentAuction': false, 'modelingSignals': 123}; } |
การมีส่วนร่วมจากภายนอก | ขอรองรับการมีส่วนร่วมภายนอกในฐานโค้ด GitHub สำหรับคีย์/ค่าเซิร์ฟเวอร์ | เรากำลังอัปเดตกระบวนการที่เกี่ยวข้องเพื่อรองรับการมีส่วนร่วมจากภายนอกในโค้ด GitHub |
ขนาดกลุ่มความสนใจ | จำนวนคีย์สูงสุดที่รองรับซึ่ง IG รองรับคือเท่าไร | ขีดจำกัดปัจจุบันคือ 50 KB สำหรับขนาดของ IG 1 รายการและคีย์จะนับเป็นส่วนหนึ่งของจำนวนนั้น เรายินดีรับพูดคุยเพิ่มเติมเกี่ยวกับขีดจำกัดขนาด |
รวมกลุ่ม | ฉันจะลดจำนวนการเรียกใช้เซิร์ฟเวอร์ K/V ได้อย่างไร | คุณสามารถใช้ส่วนหัวการควบคุมแคช HTTP เพื่อลดจำนวนการเรียก K/V เช่น อาจมีการแคชไว้ในการประมูลองค์ประกอบต่างๆ และระหว่างช่องโฆษณาในหน้าเดียวด้วย |
การควบคุมเวอร์ชัน | การรองรับโค้ดเทคโนโลยีโฆษณาหลายเวอร์ชัน | บริการการเสนอราคาและบริการประมูลจะรองรับโค้ดเทคโนโลยีโฆษณาหลายเวอร์ชัน ใน API การเสนอราคาและการประมูล คำขอ SelectAd สามารถระบุเวอร์ชันของโค้ดที่ใช้สำหรับคำขอการประมูล (เช่น สำหรับการเสนอราคา / การประมูล รวมถึงการรายงาน) |
พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน | รองรับการเขียนไปยังพื้นที่เก็บข้อมูลที่ใช้ร่วมกันในบริการการเสนอราคาและบริการประมูล | ปัจจุบันการเสนอราคาและบริการประมูลไม่รองรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมว่าเหตุใดกรณีการใช้งานดังกล่าวจึงสำคัญต่อระบบนิเวศ |
เว็บไปยังแอป | รองรับการแชร์กลุ่มความสนใจจากเว็บไปยังแอป | ขณะนี้เว็บไปยังแอปยังไม่มีขอบเขตการใช้งาน Protected Audience API ใน Chrome และ Android แต่เราต้องการรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับความสำคัญของกรณีการใช้งานนี้ |
K-Anonymity | วิธีจัดการวิดีโอสำรองสำหรับ K-Anonymity | เรากำลังพูดคุยเกี่ยวกับปัญหาและยินดีรับฟังความคิดเห็นเพิ่มเติม |
การวัดผลโฆษณาดิจิทัล
Attribution Reporting (และ API อื่นๆ)
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การกำหนดค่ารายงานระดับเหตุการณ์ VTC ทางเลือก | ความคิดเห็นเกี่ยวกับการกำหนดค่ารายงานระดับเหตุการณ์ VTC ทางเลือก | เราได้รับความคิดเห็นมาว่าการกําหนดค่าระดับเหตุการณ์ปัจจุบันไม่เหมาะสม และขอความคิดเห็นเกี่ยวกับการกําหนดค่าส่วนกลางที่มีประสิทธิภาพสูงสุด เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเรื่องนี้ และคิดว่าเครื่องมืออธิบายระดับเหตุการณ์ที่ยืดหยุ่นจะช่วยแก้ปัญหานี้ได้เช่นกัน |
การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น | ฟีเจอร์การกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นมีสถานะอย่างไร | เราได้แชร์เอกสารประกอบเกี่ยวกับการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น ฟีเจอร์ดังกล่าวยังอยู่ในขั้นตอนการทำข้อเสนอ และเรากำลังมองหาความคิดเห็นเพิ่มเติมว่าฟีเจอร์ดังกล่าวจะมีประโยชน์ต่อระบบนิเวศหรือไม่ |
การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น | รายงานที่ขัดแย้งจากฝ่ายต่างๆ จะกระทบยอดกันได้อย่างไร | สถานการณ์การรายงานส่วนใหญ่จะแก้ไขโดยการใช้รายงานสรุป ขณะที่ข้อเสนอการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นนั้นมีความยืดหยุ่นเป็นพิเศษสำหรับรายงานระดับเหตุการณ์ ซึ่งมักใช้กับกรณีการใช้งานการเพิ่มประสิทธิภาพโดยเฉพาะ เรายินดีรับฟังความคิดเห็น/ข้อเสนอแนะเพิ่มเติมจากระบบนิเวศนี้ |
การลงทะเบียนแหล่งที่มา | จะเกิดอะไรขึ้นหากการลงทะเบียนต้นทางเกิดขึ้นหลังจากการลงทะเบียนทริกเกอร์ | ในปัจจุบัน หากการลงทะเบียนแหล่งที่มาเกิดขึ้นหลังจากการลงทะเบียนทริกเกอร์ แหล่งที่มาและทริกเกอร์จะไม่สามารถระบุแหล่งที่มาซึ่งกันและกันได้ ดูเหมือนว่าจะเป็นสถานการณ์ที่เป็นปัญหาที่สุด เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้และจะพยายามแก้ไขหากเป็นสถานการณ์ที่ผู้เชี่ยวชาญด้านโฆษณาจำนวนมากต้องเผชิญ |
การทำงานร่วมกับเอเจนซีโฆษณาหลายราย | DSP จะใช้ Attribution Reporting API ได้อย่างไรเมื่อผู้ลงโฆษณาทำงานร่วมกับเอเจนซีโฆษณาหลายแห่ง | API รองรับการเปลี่ยนเส้นทาง ดังนั้นจึงสามารถใช้ได้แม้ในกรณีที่ผู้ลงโฆษณาทำงานร่วมกับเอเจนซีโฆษณาหลายแห่ง นอกจากนี้ ยังมีข้อจำกัดบางประการเกี่ยวกับการเปลี่ยนเส้นทางเพื่อให้มั่นใจว่า API จะมีการปรับปรุงความเป็นส่วนตัว เรายังได้ระบุวิธีแก้ปัญหาเฉพาะหน้าที่เป็นไปได้โดยใช้ API พื้นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับสถานการณ์เฉพาะที่เทคโนโลยีโฆษณาได้นำเสนอขึ้นด้วย เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับสถานการณ์นี้และจะดำเนินการตรวจสอบตามความคิดเห็นนั้น |
ขีดจำกัดปลายทาง | กรณีการใช้งานโฆษณาที่รีเฟรชอัตโนมัติอาจได้รับผลกระทบจากการมีขีดจํากัดปลายทาง | เราได้พูดคุยเกี่ยวกับปัญหานี้ในการประชุม WICG ของวันที่ 1 พฤษภาคม และต้องการทราบความคิดเห็นเกี่ยวกับขีดจำกัดที่สมเหตุสมผล เราได้เพิ่มการรายงานการระบุแหล่งที่มาด้วยตัวอธิบายรายงานระดับเหตุการณ์ ซึ่งระบุว่าเบราว์เซอร์สามารถจำกัดจำนวน eTLD+1 ของ "ปลายทาง" ที่แสดงโดยเว็บไซต์ต้นทางได้ (ดูการดึงข้อมูลคำขอ) |
การรายงานการระบุแหล่งที่มาและกลุ่มเป้าหมายที่มีการป้องกัน | Attribution Reporting API และ Protected Audience Audience API จะทำงานร่วมกันอย่างไร | ปัจจุบันการผสานรวมใช้ได้กับ Protected Audience API ทั้งสำหรับโหมด Attribution Reporting API (ระดับเหตุการณ์และรายงานสรุป) เราได้แชร์ข้อมูลเพิ่มเติมเกี่ยวกับการผสานรวม Protected Audience API และ Attribution Reporting ที่ปรับปรุงใหม่เมื่อวันที่ 1 มิถุนายน อ่านได้ที่นี่ |
การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น | แชร์แนวทางปฏิบัติแนะนำสำหรับการจำลองสัญญาณรบกวนเนื่องจากสามารถกำหนดค่าพารามิเตอร์ได้แล้ว | เรามีโค้ดที่แชร์ร่วมกันบน GitHub ซึ่งทุกคนสามารถใช้ประเมินข้อมูลที่ได้รับและผลกระทบจากสัญญาณรบกวนสำหรับการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นที่ต้องการทดสอบ เรายินดีรับฟังความคิดเห็นจากผู้ที่เลือกทดสอบโค้ดและต้องการแชร์ความคิดเห็น |
การวัดการระบุแหล่งที่มาข้ามแอปและเว็บ | การวัดการระบุแหล่งที่มาข้ามแอปและเว็บจะพร้อมใช้งานเมื่อใด | เราได้ประกาศไปเมื่อวันที่ 9 พฤษภาคมเกี่ยวกับการทดสอบการวัดการระบุแหล่งที่มาข้ามแอปและเว็บผ่าน Attribution Reporting API แม้ว่าจะมีการวางแผนความพร้อมให้บริการทั่วไปสําหรับ API ความเกี่ยวข้องและการวัดผลใน Chrome 115 แต่ขณะนี้การวัดการระบุแหล่งที่มาข้ามแอปและเว็บยังไม่มีแผนที่จะใช้งานกับ Chrome 115 เวอร์ชันสำหรับผู้ใช้ทั่วไป |
กรองข้อมูล Conversion ที่ซ้ำกันออก | โซลูชันการวัดผลอิสระจะปรับยอดกับ ARA ได้อย่างไร | ผู้ลงโฆษณาจะทํางานร่วมกับผู้ให้บริการวัดผลอิสระบุคคลที่สามเพื่อกรองการรายงาน Conversion ที่ซ้ำกันออก เช่นเดียวกับแนวทางปฏิบัติมาตรฐานปัจจุบัน เรามีแหล่งข้อมูลเกี่ยวกับวิธีกรองข้อมูล Conversion ที่ซ้ำกันออกสำหรับการรายงานระดับเหตุการณ์ |
ข้อมูลสูญหายระหว่างการอัปเดตฐานข้อมูล Attribution Reporting | ข้อมูลจะสูญหายหรือไม่เมื่อ Chrome อัปเดตฐานข้อมูล Attribution Reporting ตามที่ได้ประกาศไว้ | ตั้งแต่ Chrome เวอร์ชันเสถียร 115 เป็นต้นไป เราจะเริ่มเปิดใช้ API ความเกี่ยวข้องและการวัดผลสำหรับผู้ใช้ Chrome บางส่วนโดยค่าเริ่มต้น เวอร์ชันสำหรับผู้ใช้ทั่วไปนี้จะเพิ่มขึ้นขณะที่เราตรวจสอบปัญหาที่อาจเกิดขึ้น เป้าหมายคือการทำให้ความพร้อมใช้งานครบ 100% ภายในไม่กี่สัปดาห์ภายในไตรมาส 3 ปี 2023 ซึ่งจะตรงกับเวลาสิ้นสุดของช่วงทดลองใช้ความเกี่ยวข้องและการวัดผลจากต้นทาง ตั้งแต่เดือนกรกฎาคมเป็นต้นไป ผู้ทดสอบจะสามารถลงทะเบียนเพื่อเข้าถึง API เหล่านี้ได้ในเวอร์ชันสำหรับผู้ใช้ทั่วไป ซึ่งจะให้ความคาบเกี่ยวระหว่างความพร้อมให้บริการของช่วงทดลองใช้จากต้นทางกับเวอร์ชันสำหรับผู้ใช้ทั่วไปผ่านการลงทะเบียน โทเค็นช่วงทดลองใช้จากต้นทางจะใช้ได้จนถึงวันที่ 19 กันยายน แต่เราขอแนะนำให้คุณลงทะเบียน API ก่อนหมดอายุเพื่อให้ย้ายออกจากช่วงทดลองใช้จากต้นทางได้อย่างราบรื่นโดยไม่รบกวนการทดสอบที่ดำเนินอยู่ ดังที่ระบุไว้ในประกาศนี้ ระบบจะไม่ย้ายข้อมูลที่ลงทะเบียนจากเวอร์ชันเก่า (M113 และก่อนหน้า) หลังการอัปเดต ดังนั้นข้อมูลจึงอาจสูญหาย การสูญหายของข้อมูลนี้จะไม่แสดงในการรายงานการแก้ไขข้อบกพร่อง และเราจะพยายามป้องกันไม่ให้ข้อมูลสูญหายจาก 114 ถึง 115 |
การเรียกเก็บเงิน | การใช้ Attribution Reporting สําหรับการเรียกเก็บเงินแบบต้นทุนต่อ Conversion | ตามที่ระบุไว้ในบทความนี้ Attribution Reporting API อาจไม่เหมาะกับการเรียกเก็บเงินแบบต้นทุนต่อ Conversion เนื่องจากมีการเพิ่มข้อมูลรบกวนลงในรายงานระดับเหตุการณ์และรายงานสรุป เราสนับสนุนให้ผู้เล่นในระบบนิเวศแชร์ความคิดเห็นเกี่ยวกับผลกระทบต่อรูปแบบการเรียกเก็บเงินต่างๆ ด้วย Attribution Reporting API ใน GitHub |
บริการรวบรวม
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การเปลี่ยนแปลงความล่าช้าของรายงานแบบรวมได้ | ปฏิกิริยาเชิงบวกต่อข้อเสนอเพื่อเปลี่ยนความล่าช้าของรายงานที่รวบรวมได้เป็น [10-60 นาที] เป็น [0-10 นาที] หลังจากได้รับความคิดเห็นจากระบบนิเวศ | เรายินดีที่ได้เห็นปฏิกิริยาเชิงบวกต่อการเปลี่ยนแปลงที่เสนอนี้ และสนับสนุนให้ระบบนิเวศแสดงความคิดเห็นเกี่ยวกับข้อเสนอของเราต่อไป |
โซลูชันของบริษัท | สามารถนําบริการรวบรวมข้อมูลไปใช้งานในศูนย์ข้อมูลภายในองค์กรได้ไหม | แม้ว่าเรากำลังสำรวจตัวเลือกที่อาจสนับสนุนนอกเหนือจากโซลูชันระบบคลาวด์ แต่ขณะนี้ก็ยังไม่สามารถรองรับ TEE ภายในองค์กรได้ เนื่องจากมีข้อจำกัดด้านความปลอดภัยภายในองค์กร ซึ่งยังต้องประเมินเวลา Privacy Sandbox อยู่นาน เมื่อพิจารณาจากข้อกำหนดด้านความปลอดภัยของ Privacy Sandbox และความท้าทายสำคัญที่ได้รับจากการติดตั้งใช้งานภายในองค์กร เราเชื่อว่าการขยายและปรับปรุงการติดตั้งใช้งานในระบบคลาวด์อย่างต่อเนื่อง (เช่น การรองรับ GCP เพิ่มเติมจาก AWS) คือประโยชน์มากที่สุดสำหรับระบบนิเวศนี้ อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเหตุผลที่จำเป็นต้องมีข้อกำหนดดังกล่าว |
ประมวลผลรายงานสำหรับช่วงเวลาต่างๆ อีกครั้ง | ความสามารถในการประมวลผลรายงานในช่วงเวลาต่างๆ อีกครั้ง | เราได้รับคําขอที่คล้ายกันให้แยกกลุ่มสำหรับช่วงวันที่อื่นๆ ได้ ข้อเสนอหนึ่งคือการเพิ่มความสามารถในการขยายรหัสที่แชร์ด้วยป้ายกำกับที่เทคโนโลยีโฆษณากำหนด เพื่อให้รายงานแบ่งออกเป็นกลุ่มต่างๆ ได้ เรากำลังอยู่ในขั้นตอนเริ่มต้นของการประเมินกระบวนการนี้ และจะคอยอัปเดตระบบนิเวศในระหว่างที่ข้อเสนอนี้เปลี่ยนแปลงไปเรื่อยๆ |
ผลกระทบด้านความเป็นส่วนตัวของสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ | ความรู้สึกในเชิงบวกต่อผลกระทบด้านความเป็นส่วนตัวของสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ | เรายินดีที่ได้ทราบปฏิกิริยาเชิงบวกจากระบบนิเวศเกี่ยวกับข้อเสนอของเรา และเรายินดีรับฟังความคิดเห็นเพิ่มเติมในระหว่างที่เรากำลังปรับปรุงและพัฒนาอย่างต่อเนื่อง |
ข้อกำหนดในการให้บริการ | กำหนดเวลาในการยอมรับข้อกำหนดในการให้บริการของบริการรวบรวมข้อมูลคือเมื่อใด | แม้ว่าเราจะยังไม่ได้ระบุกำหนดเวลาในการยอมรับข้อกำหนดและเงื่อนไข แต่เราก็ขอแนะนำให้บริษัทที่ให้บริการด้านระบบนิเวศยอมรับข้อกำหนดในการให้บริการโดยเร็วที่สุดเพื่อป้องกันไม่ให้เกิดความล่าช้าในการลงทะเบียน เราแนะนำให้บริษัทต่างๆ ติดต่อกลับมาหากมีคำถาม |
การค้นพบคีย์ | ฟีเจอร์การค้นพบหลักจะทำให้ผู้ทดสอบค้นหารายงานเชิงสถิติได้โดยไม่จำเป็นต้องมีรายการชุดคีย์ผสมที่เป็นไปได้อย่างชัดเจน เพื่อประมวลผลรายงานสรุปสำหรับการระบุแหล่งที่มาข้ามเครือข่ายเพื่อปรับปรุงประสิทธิภาพและความแม่นยำ | ขณะนี้เรากำลังสำรวจวิธีแก้ปัญหาที่เป็นไปได้และวิธีแก้ไขปัญหาเฉพาะหน้า และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
API การรวมส่วนตัว
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
ต้นทางการรายงาน | ที่มาของการรายงานมีคำจำกัดความอย่างไร | ต้นทางการรายงานจะเป็นต้นทางสคริปต์ของผู้โทรการรวมส่วนตัวเสมอ |
แป้นเว้นวรรค 128 บิต | ความชัดเจนของข้อจำกัดของพื้นที่ทำงาน 128 บิต | เราจะทำให้การจำกัดพื้นที่แป้นนี้ชัดเจนขึ้นและแก้ไขความไม่สอดคล้องกันของหน้าต่างๆ เราขอแนะนําให้ใช้กลยุทธ์การแฮชเพื่อให้อยู่ในแป้นนี้ |
การมีส่วนร่วมสูงสุดต่อรายงาน | ขีดจํากัดปัจจุบันที่ 20 การมีส่วนร่วมต่อรายงานต่ำเกินไป | แทนที่จะเพิ่มจำนวนการมีส่วนร่วมสูงสุด เราก็ยินดีพิจารณาแยกรายงานแทนที่จะตัดให้เหลือเพียงจำนวนครั้งสูงสุด เราจะมีส่วนร่วมในระบบนิเวศขณะที่ข้อเสนอนี้พัฒนา |
การรายงานการเข้าถึง | ขอการรายงานการเข้าถึงข้ามแพลตฟอร์ม/หลายอุปกรณ์ การเข้าถึงเป็นเมตริกพื้นฐานของการโฆษณาแบรนด์ ผู้ลงโฆษณาอาศัยการคาดการณ์แบบข้ามแพลตฟอร์ม/หลายอุปกรณ์ในการรายงานการเข้าถึงและความถี่เพื่อวิเคราะห์แคมเปญและจัดสรรการใช้จ่าย โมเดลการเข้าถึงใช้คุกกี้ของบุคคลที่สามเป็นสัญญาณในการวัดโฆษณาที่แสดงในสภาพแวดล้อมของบุคคลที่สาม เทคโนโลยีโฆษณาจึงขอโซลูชันอื่นเมื่อเลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว |
ทีม Privacy Sandbox กำลังสำรวจฟีเจอร์ต่างๆ เพื่อสนับสนุนวิธีการเข้าถึงผลแบบข้ามโดเมนหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
จำกัดการติดตามแบบไม่เปิดเผย
การลด User Agent/คำแนะนำไคลเอ็นต์ User Agent
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
(มีการรายงานในไตรมาสที่ 1 ปี 2023 ด้วย) คำแนะนำสำหรับรูปแบบของอุปกรณ์เพิ่มเติม | ขอคำแนะนำสำหรับ User Agent Client (UA-CH) เพื่อระบุรูปแบบของอุปกรณ์เพิ่มเติม เช่น TV, VR | เรายังคงตัดสินใจเลือกการออกแบบที่สำคัญๆ อยู่ (ว่าจะจัดเตรียมค่าเดี่ยวๆ เช่น "ทีวี" หรือรายการความสามารถของรูปแบบของอุปกรณ์) แต่ยังคงสนใจในการสร้างต้นแบบของแนวคิดนี้ |
งบประมาณด้านความเป็นส่วนตัว | ข้อจำกัดด้านงบประมาณความเป็นส่วนตัวอาจทำให้คำขอ UA-CH เป็นแบบไม่ได้กำหนดเมื่อมีการส่งคำขอมากเกินไป | เรายังไม่มีการอัปเดตใหม่สำหรับข้อเสนองบประมาณความเป็นส่วนตัวในตอนนี้ แต่เรามุ่งมั่นที่จะไม่จำกัดคำขอคำแนะนำสำหรับไคลเอ็นต์ UA ก่อนที่จะมีการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
ความเข้ากันได้ของเว็บไซต์ | เว็บไซต์ใช้แบรนด์ UA-CH ในการจำกัดไม่ให้บางเบราว์เซอร์เข้าถึงเว็บไซต์ | การใช้รายการแบรนด์นั้นมีอยู่ด้วยกันหลายกรณี และหนึ่งในนั้นคือความเข้ากันได้ที่แน่นอน UA เป็นอิสระในการให้หลายแบรนด์ช่วยแก้ปัญหาเหล่านี้ |
การป้องกัน IP (เดิมคือ Gnatcatcher)
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การประพฤติมิชอบและการละเมิด | บริษัทจะกำหนดมาตรการป้องกันการประพฤติมิชอบด้วยการป้องกัน IP ได้อย่างไร | เราเข้าใจถึงความสำคัญของกรณีการใช้งานเพื่อป้องกันการฉ้อโกงและผลกระทบที่อาจเกิดขึ้นกับกรณีการใช้งานดังกล่าว เราวางแผนที่จะเผยแพร่รายละเอียดเพิ่มเติมเกี่ยวกับการสนับสนุนการป้องกันการประพฤติมิชอบในช่วงฤดูร้อนนี้ เรากำลังรับฟังความคิดเห็นเกี่ยวกับระบบนิเวศเพื่อที่เราจะได้ให้การสนับสนุนแก่ Use Case ป้องกันการทุจริตให้ดียิ่งขึ้น |
GeoIP | ข้อมูลเพิ่มเติมเกี่ยวกับระยะเวลาการทดสอบและการปรับใช้งานสำหรับ GeoIP | เมื่อเร็วๆ นี้ Chrome ได้เผยแพร่ข้อมูลใหม่ซึ่งให้รายละเอียดเกี่ยวกับแผน GeoIP ของเรา เรากำลังวางแผนที่จะเผยแพร่ข้อมูลเพิ่มเติมเกี่ยวกับลำดับเวลาการทำให้ใช้งานได้ในไตรมาสที่ 3 เราคาดว่าจะเปิดตัวการป้องกัน IP ในรูปแบบที่ผู้ใช้เลือกใช้กับการเข้าชมจำนวนเล็กน้อยในตอนแรก เหตุผลก็คือเราตระหนักดีว่าข้อเสนอนี้อาจเกี่ยวข้องกับการเปลี่ยนแปลงที่สำคัญบางอย่างสำหรับบริษัท และเราต้องการให้เวลาระบบนิเวศในการปรับเปลี่ยนและแสดงความคิดเห็นก่อนที่จะเปิดตัวฟีเจอร์นี้ในวงกว้างขึ้น |
การตรวจสอบสิทธิ์บัญชี | การตรวจสอบสิทธิ์บัญชีกับพร็อกซีเซิร์ฟเวอร์จะทำงานอย่างไร | เราวางแผนที่จะเผยแพร่รายละเอียดเพิ่มเติมเกี่ยวกับการตรวจสอบสิทธิ์บัญชีภายหลังในฤดูร้อนนี้ แต่เราได้แชร์สิ่งที่ควรพิจารณาเบื้องต้นไปบ้างแล้ว |
การลดการติดตามการเข้าออก
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
คำแนะนำในการทดสอบ | ข้อมูลเกี่ยวกับวิธีทดสอบการลดการติดตามการเข้าออก | เราได้เผยแพร่ บล็อกโพสต์ในเดือนพฤษภาคมพร้อมข้อมูลเพิ่มเติมเกี่ยวกับวิธีทดสอบการลดการติดตามการเข้าออก |
เอกสารประกอบ | ความชัดเจนในข้อเสนอการติดตามการเข้าออก | ข้อเสนอปัจจุบันยังอยู่ระหว่างการพัฒนา และ Chrome จะอัปเดตข้อเสนออย่างต่อเนื่องเพื่อให้ข้อมูลและความชัดเจนแก่ระบบนิเวศ เรากำลังดำเนินการเพื่อให้รายละเอียดเพิ่มเติมและยินดีรับฟังความคิดเห็นเพิ่มเติม |
การลบคุกกี้ | การลดการติดตามการเข้าออกจะลบคุกกี้ทั้งหมดในโดเมนไหม | การลดการติดตามการเข้าออก (BTM) จะล้างพื้นที่เก็บข้อมูลและแคชทั้งหมดตามที่อธิบายไว้ที่นี่ |
การหลีกเลี่ยงการลดการติดตามการเข้าออก | การเปลี่ยนเส้นทางด้วยป๊อปอัปหรือแท็บใหม่อาจข้ามการจัดหมวดหมู่เครื่องติดตามการตีกลับได้ | ข้อมูลจำเพาะของการลดการติดตามการเข้าออกยังคงอยู่ระหว่างการพัฒนา ที่ผ่านมาเราเน้นที่การเปลี่ยนเส้นทางแท็บเดียวกันเป็นส่วนใหญ่ แต่เราวางแผนที่จะทำการแสดงป๊อปอัปในอนาคต เรายินดีรับความคิดเห็นเพิ่มเติมที่นี่ |
งบประมาณด้านความเป็นส่วนตัว
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การกำหนดเป้าหมายที่ใกล้เคียง | งบประมาณด้านความเป็นส่วนตัวอาจส่งผลต่อ Use Case การกำหนดเป้าหมายที่ใกล้เคียงกัน | เราได้รับความคิดเห็นเกี่ยวกับปัญหานี้แล้ว และสนใจที่จะรับฟังเพิ่มเติมเกี่ยวกับผลกระทบที่อาจเกิดขึ้นจากระบบนิเวศ |
ขยายขอบเขตความเป็นส่วนตัวแบบข้ามเว็บไซต์
ชุดโดเมนของบุคคลที่หนึ่ง
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
(รายงานในไตรมาสที่แล้วด้วย) ขีดจำกัดโดเมน | คำขอขยายจำนวนโดเมนที่เชื่อมโยง | Chrome กำลังประเมินขีดจำกัดตัวเลขที่เหมาะสมสำหรับชุดย่อยที่เกี่ยวข้อง ซึ่งจะสร้างสมดุลระหว่างความเป็นส่วนตัวกับประโยชน์ในการใช้งานที่ได้ระบุมา ในช่วงเริ่มต้น Chrome ได้แจ้งว่าตัวเลขที่แน่นอนของชุดย่อยที่เกี่ยวข้องยังไม่ได้รับการสรุป |
กรณีการใช้งานแบบฝัง | การรองรับ Use Case แบบฝังซึ่งต้องใช้ชุดโดเมนของบุคคลที่หนึ่ง, CHIP และพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน | Chrome ได้รับความคิดเห็นเกี่ยวกับกรณีการใช้งานนี้ และทีมของเรากำลังตรวจสอบและยินดีรับความคิดเห็นเพิ่มเติม |
การจัดการที่เก็บ | ข้อมูลเกี่ยวกับนโยบายที่จะนำชุดโดเมนของบุคคลที่หนึ่งออกจากที่เก็บ GitHub หากมีความคลาดเคลื่อนหรือละเลย | Chrome ได้รับความคิดเห็นเกี่ยวกับกรณีการใช้งานนี้แล้ว ทีมของเรากำลังตรวจสอบและยินดีรับความคิดเห็นเพิ่มเติม |
การให้ความรู้แก่ผู้ใช้ | Chrome ควรเพิ่มการรับรู้และความเข้าใจของผู้ใช้เกี่ยวกับชุดโดเมนของบุคคลที่หนึ่งเพื่อกระตุ้นให้เกิดการใช้งาน | Chrome มุ่งมั่นที่จะให้ความรู้แก่ผู้ใช้เกี่ยวกับชุดโดเมนของบุคคลที่หนึ่ง และเผยแพร่ บทความในศูนย์ช่วยเหลือ (ลิงก์จาก UI ของ Chrome) เกี่ยวกับนโยบายนี้ Chrome ยังลงทุนอย่างต่อเนื่องในการเรียนรู้วิธีให้ความรู้ที่ดีที่สุดแก่ผู้ใช้ในบริบทที่เหมาะสม |
โพสต์แบบ 3PCD | คุกกี้ของบุคคลที่สามจะยังคงอยู่ในชุดโดเมนของบุคคลที่หนึ่งหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม | แม้ว่า requestStorageAccess และ requestStorageAccessFor จะทำให้คุกกี้ของบุคคลที่สามพร้อมใช้งานอีกครั้งสำหรับ Use Case ที่เจาะจงและระบุไว้อย่างชัดเจน แต่ในตอนนี้เว็บไซต์กำหนดให้เรียกใช้คุกกี้ที่ใช้งานอยู่แทนพร้อมใช้งานโดยค่าเริ่มต้น อย่างเช่นสถานะปัจจุบันของคุกกี้ของบุคคลที่สาม (ใน Chrome)แม้ว่าคำขอนี้จะไม่จำเป็นต้องมีการอนุมัติจากผู้ใช้ แต่ผู้ใช้สามารถป้องกันการดำเนินการนี้ได้โดยเลือกไม่ใช้ลักษณะการทำงานนี้ในการตั้งค่า ผู้ใช้ดูข้อมูลเพิ่มเติมได้ที่บทความในศูนย์ช่วยเหลือ (ลิงก์จาก UI ของ Chrome) เราวางแผนที่จะขยายการใช้งานตามคู่มือนักพัฒนาซอฟต์แวร์ที่มีอยู่เนื่องจากอัตรา FPS สูงสุด 100% |
การส่งชุดโดเมนของบุคคลที่หนึ่ง | เปลี่ยนชื่อ .well-known/first-party-set ที่ต้องระบุเพื่อรวมส่วนขยาย .json |
เราได้ทำการเปลี่ยนแปลงนี้เพื่อรองรับแพ็กเกจเว็บโฮสติ้งบางแพ็กเกจ |
การจดทะเบียน IANA | first_party_sets.JSON ควรลงทะเบียนกับ IANA |
เรากำลังพิจารณาข้อเสนอนี้และยินดีรับความคิดเห็นเพิ่มเติมที่นี่ |
Fenced Frames API
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การบล็อกโฆษณา | เฟรมที่มีการปิดกั้นโฆษณาอาจช่วยให้ตัวบล็อกโฆษณาบล็อกโฆษณาได้ง่ายขึ้น | ส่วนขยายสามารถโต้ตอบกับเฟรมที่มีการปิดกั้นได้คล้ายกับในการโต้ตอบกับ iframe URL จริงที่ระบบจะไปยังเฟรมที่มีการกั้นรั้วไปยังส่วนขยายก็จะเห็น URL จริงด้วย ดังนั้นส่วนขยายจึงใช้กฎการจับคู่ URL ใดๆ ในการบล็อกได้เช่นเดียวกับใน iframe การบล็อกเฟรมที่มีการรั้วทั้งหมดอย่างไม่มีเงื่อนไขอาจทำให้เฟรมที่มีรั้วล้อมรอบการใช้งานที่ไม่ใช่โฆษณาเสียหายได้ |
API พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การนำไปใช้งานในวงกว้างขึ้น | พื้นที่เก็บข้อมูลที่ใช้ร่วมกันควรเป็นมาตรฐานอุตสาหกรรมทั่วทั้งเบราว์เซอร์ | เรายินดีรับฟังและรับทราบความคิดเห็นนี้ Chrome ยังคงมีส่วนร่วมใน W3C อย่างต่อเนื่องเพื่อสนับสนุนข้อเสนอ ขอความคิดเห็น และกระตุ้นการนำไปใช้ |
ประตูเอาต์พุต | ขีดจำกัดเอาต์พุตของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีจำกัดเกินไป | เรากำลังพิจารณาความคิดเห็นนี้และยินดีรับฟังความคิดเห็นเพิ่มเติมของระบบนิเวศเกี่ยวกับสาเหตุที่โอกาสรับผลลัพธ์ถูกจำกัดมากเกินไป |
การปฏิบัติตามกฎระเบียบ | พื้นที่เก็บข้อมูลที่ใช้ร่วมกันจะจัดการการปฏิบัติตามข้อกำหนด เช่น นโยบายการเก็บรักษาข้อมูล | พื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีความยืดหยุ่นในการใช้งานและปรับแต่งตรรกะเพื่อควบคุมอายุการใช้งานและการหมดอายุของข้อมูลที่จัดเก็บไว้ เทคโนโลยีโฆษณาสามารถอัปเดตหรือล้างข้อมูลพื้นที่เก็บข้อมูลที่ใช้ร่วมกันโดยอิงตามการประทับเวลาการเขียน |
การทดสอบอัลฟา/เบต้า | การทดสอบ A/B สำหรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกันและ Protected Audience API จะดำเนินการได้อย่างไร | เรากำลังเผยแพร่คำแนะนำเพิ่มเติมเกี่ยวกับเรื่องนี้อยู่และหวังว่าจะได้แชร์รายละเอียดเพิ่มเติมในอนาคต |
ขีดจำกัดของพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน | จะเกิดอะไรขึ้นเมื่อใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันถึงขีดจำกัด | หากถึงขีดจำกัดแล้ว ระบบจะไม่จัดเก็บอินพุตใดๆ เพิ่มเติม |
การเข้าถึงหลายรายการในการโหลดหน้าเว็บเดียวกัน | จะเกิดอะไรขึ้นเมื่อมีการเข้าถึงพื้นที่เก็บข้อมูลที่ใช้ร่วมกันหลายครั้งในการโหลดหน้าเว็บเดียวกัน | วิธีที่ดีที่สุดในการจัดการปัญหานี้คือการดำเนินการผ่านฟังก์ชัน window.sharedStorage.append(key, value) แทนที่จะอัปเดตค่าของโฆษณาแต่ละรายการ ซึ่งอาจทำให้เกิดความขัดแย้งกันในกรณีที่มีโฆษณาหลายรายการ ฟังก์ชันการต่อท้ายจะเพิ่มค่าใหม่ที่ส่วนท้ายของค่าที่มีอยู่ก่อนหน้า |
ฟังก์ชันการทำงานของ iframe | พื้นที่เก็บข้อมูลที่ใช้ร่วมกันจะรองรับฟังก์ชันการทำงานบางอย่างของ iframe หรือไม่หลังจากเลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว | หลังการเลิกใช้งานคุกกี้ของบุคคลที่สาม เว็บไซต์ระดับบนสุดจะแบ่งพาร์ติชันพื้นที่เก็บข้อมูลในเครื่องใน iframe ตามเว็บไซต์ระดับบนสุด แต่จะไม่บล็อก iframe ข้อมูลในพื้นที่เก็บข้อมูลในเครื่องของ iframe จะไม่สามารถทำซ้ำในเว็บไซต์ระดับบนสุดหลายๆ เว็บไซต์ แต่พื้นที่เก็บข้อมูลในเครื่องจะยังคงใช้ภายใน iframe ได้ |
ชิป
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
ขีดจำกัดพาร์ติชัน | 10 KiB ต่อเว็บไซต์ที่แบ่งพาร์ติชันยังมีความสำคัญมากและอยากให้ลดลง | Firefox ได้ระบุ อันดับเชิงบวกบน CHIPS แล้ว สําหรับการรองรับ Webkit เราขอแนะนําให้นักพัฒนาแอปแสดงความคิดเห็นต่อ Apple โดยตรงเกี่ยวกับ ปัญหาเกี่ยวกับ GitHub เกี่ยวกับกรณีการใช้งานที่ควรใช้คุกกี้ที่แบ่งพาร์ติชันมากกว่าพื้นที่เก็บข้อมูลที่แบ่งพาร์ติชัน |
การฝังที่ตรวจสอบสิทธิ์แล้ว | CHIP อาจส่งผลต่อขั้นตอนการลงชื่อเข้าใช้ SSO ปัจจุบันเนื่องจากการแบ่งพาร์ติชันที่แตกต่างกันซึ่งส่งผลต่อการฝังที่ตรวจสอบสิทธิ์แล้ว | เราตั้งใจที่จะใช้ประโยชน์จาก Storage Access API (พร้อมข้อความแจ้งผู้ใช้) เพื่อรองรับ Use Case การฝังที่ผ่านการตรวจสอบสิทธิ์ และเพิ่งส่ง Intent เพื่อสร้างต้นแบบ |
นโยบายตลอดอายุการใช้งาน | นโยบายตลอดอายุการใช้งานที่เป็นไปได้จะมีผลกับคุกกี้ของบุคคลที่หนึ่งไหม | ขณะนี้เราไม่มีแผนที่จะกำหนดขีดจำกัดตลอดอายุการใช้งานคุกกี้ของบุคคลที่หนึ่ง |
FedCM
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การสนับสนุนการให้สิทธิ์ OAuth | ทำให้สอดคล้องกันกับการให้สิทธิ์ขอบเขต OAuth ที่ไม่ใช่โปรไฟล์ | เรากำลังอย่างเต็มที่เพื่อขอความคิดเห็นจากชุมชน Web Identity ผ่าน W3C FedID CG เกี่ยวกับวิธีที่ดีที่สุดในการรองรับการให้สิทธิ์นอกเหนือจากการตรวจสอบสิทธิ์ขั้นพื้นฐานหลังการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
การสนับสนุนสำหรับ SAML | ปฏิบัติตามข้อกําหนดสำหรับการรองรับ SAML | ทีมของเราพยายามอย่างเต็มที่เพื่อขอความคิดเห็นจากชุมชนการวิจัยและการศึกษาเกี่ยวกับความต้องการรับการสนับสนุน SAML (นอกเหนือจากการสนับสนุน OpenID Connect) หลังการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
ต่อสู้กับสแปมและการประพฤติมิชอบ
API โทเค็นสถานะส่วนตัว (และ API อื่นๆ)
ธีมความคิดเห็น | สรุป | การตอบกลับของ Chrome |
---|---|---|
การสำรวจสัญญาณใหม่ | พาร์ทเนอร์หลายรายแสดงความคิดเห็นเชิงบวกต่อการสำรวจสัญญาณจากความสมบูรณ์ของอุปกรณ์หรือความไว้วางใจของผู้ใช้ที่ได้จากเบราว์เซอร์ โดยทั่วไปแล้ว ผู้ผลิตจะต้องระมัดระวังเกี่ยวกับสัญญาณใหม่ๆ ที่สร้างขึ้นเพื่อวัตถุประสงค์เฉพาะเพื่อให้เพียงพอที่จะรักษาระดับการตรวจจับการประพฤติมิชอบในปัจจุบันไว้ | เราตื่นเต้นที่จะได้สำรวจข้อเสนอใหม่ๆ ร่วมกันภายในชุมชนต่อต้านการประพฤติมิชอบและความปลอดภัยบนเว็บ ตลอดจนรับทราบและแชร์ข้อกังวลของพวกเขา นี่คือเหตุผลว่าทำไม "การต่อสู้กับสแปมและการประพฤติมิชอบ" จึงเป็นกระบวนการหลักของ Privacy Sandbox และสาเหตุที่เราให้ความสำคัญกับการลงทุนในการรักษาความปลอดภัยของเว็บอย่างต่อเนื่อง ไปพร้อมๆ กับปรับปรุงความเป็นส่วนตัวของผู้ใช้ |
ความคิดเห็นเชิงบวกเกี่ยวกับ PST | พาร์ทเนอร์หลายรายได้แสดงความสนใจที่จะทดสอบหรือใช้ PST สำหรับกรณีการใช้งานต่างๆ เพื่อป้องกันการประพฤติมิชอบหรือความปลอดภัยของเว็บ | เราตื่นเต้นที่จะได้ฟังการสนับสนุนและสนใจสำรวจโซลูชันใหม่ๆ ที่ใช้ PST ต่อไป เรามีทรัพยากรและโค้ดตัวอย่างให้ใช้งานทางเว็บไซต์นักพัฒนาซอฟต์แวร์ Chrome และยินดีรับฟังความคิดเห็นเพิ่มเติม |
การประพฤติมิชอบและการละเมิด | คำแนะนำสำหรับการป้องกันการฉ้อโกง / การตรวจจับโฆษณาในการวัดผลหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามเมื่อไม่มีตัวระบุแล้ว | เราได้เปิดตัวเครื่องมือต่างๆ เช่น โทเค็นสถานะส่วนตัว ซึ่งจะช่วยกู้คืนสัญญาณบางส่วนที่คุกกี้ของบุคคลที่สามสูญเสียไปเพื่อจุดประสงค์ในการป้องกันการประพฤติมิชอบ แต่ด้วยการควบคุมความเป็นส่วนตัวแบบใหม่ เรากําลังลงทุนอย่างแข็งขันสำหรับข้อเสนอการป้องกันการประพฤติมิชอบและการละเมิดใหม่ๆ เพื่อรักษาความสามารถเอาไว้ด้วยการเปลี่ยนแปลงอื่นๆ ของ Privacy Sandbox |
อัตราสำหรับข้อมูลผู้ออกบัตรถึงต้นทาง | อัตราข้อมูลของผู้ออกไปยังต้นทางสูงพอที่จะระบุผู้ใช้ที่ไม่ซ้ำได้ | เราได้อัปเดตข้อกำหนดให้ชัดเจนยิ่งขึ้นเกี่ยวกับข้อมูลผู้ใช้ที่สื่อสารได้โดยใช้โทเค็นสถานะส่วนตัว ตามหลักแล้ว สามารถใช้คีย์สาธารณะพร้อมกันได้สูงสุด 6 รหัส ซึ่งอาจแสดงถึง "รัฐ" สำหรับผู้ใช้รายนั้นๆ ชุดคีย์เหล่านี้จะอัปเดตได้ทุกๆ 60 วันเท่านั้น (ยกเว้นในกรณีที่ต้องมีการหมุนเวียนคีย์ฉุกเฉิน ซึ่งเป็นกรณีที่พบไม่บ่อยนัก) ซึ่งจะทำให้การผูกข้อมูลผู้ใช้เพิ่มเติมช้าลงเมื่อเวลาผ่านไป เมื่อใช้ Web API ใหม่ จะมีความสมดุลของยูทิลิตีที่ให้ไว้และข้อมูลผู้ใช้ใหม่สุทธิที่แอปให้ เราประเมินว่า PST จะมีจุดสมดุลที่เหมาะสมในการปกป้องความเป็นส่วนตัวของผู้ใช้ พร้อมกับเปิดใช้ Use Case หลักเพื่อป้องกันการฉ้อโกงซึ่งได้รับผลกระทบจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
การผสานรวมการดึงข้อมูล | การผสานรวม fetch มีความซับซ้อนและไม่จำเป็น |
การใช้ fetch มีทั้งข้อดีและข้อเสีย และเราต้องการทำตามมาตรฐานนี้ให้มากยิ่งขึ้นภายในระบบนิเวศของเว็บ แต่เราคิดว่ายังเร็วเกินไปที่จะทำการเปลี่ยนแปลงนี้จนกว่าเราจะมีความชัดเจนมากขึ้นว่ามาตรฐานนี้จะมีหน้าตาอย่างไร และหากมาตรฐานปรากฏ เราก็มุ่งมั่นที่จะให้นักพัฒนาเว็บเปลี่ยนไปใช้มาตรฐานนั้นอย่างมีความรับผิดชอบ |
ตำแหน่งพื้นที่เก็บข้อมูล | ควรจัดเก็บการกำหนดค่าคีย์โทเค็นสถานะส่วนตัวไว้ในตำแหน่งเดียวกับโปรโตคอล PrivacyPass | ขณะทดสอบระหว่างช่วงทดลองใช้จากต้นทาง นักพัฒนาซอฟต์แวร์ระบุว่าต้องการให้ความยืดหยุ่นในการจัดเก็บคีย์ใน URL ทั่วไปแทนที่จะเก็บไว้ในไดเรกทอรี .well-known รูปแบบสัญญาผูกมัดหลักใน PrivacyPass ไม่เหมาะกับเวอร์ชันที่ชุดคีย์มีไว้เพื่ออนุญาตให้มีค่า "ข้อมูลเมตาสาธารณะ" โดยนัย หาก PrivacyPass เวอร์ชันหนึ่งได้รับข้อมูลเมตาสาธารณะที่เป็นมาตรฐาน (ไม่ว่าจะเป็น POPRF, การปกปิด RSA บางส่วน หรือชุดคีย์) เราอาจเปลี่ยนไปใช้ PST เวอร์ชันในอนาคตเพื่อรองรับการใช้งานดังกล่าว |
การใช้งาน API ในส่วนหัวของ | คำถามเกี่ยวกับการติดตั้งใช้งาน API ในส่วนหัวของ | เมื่อ API ได้รับการปรับให้เป็นมาตรฐานและการใช้งานระบบนิเวศของ API นี้มากขึ้น เราหวังว่าจะรองรับทั้งเวอร์ชันมาตรฐานที่ไม่ใช่ส่วนหัวของ API นี้ และอาจเลิกใช้งานเวอร์ชันส่วนหัวในที่สุดหากมีการใช้งานต่ำเพียงพอหรือมีเครื่องมือ/การสนับสนุนสำหรับนักพัฒนาซอฟต์แวร์เพียงพอสำหรับวิธีมาตรฐานในการเชื่อมโยงคำขอออก/แลกสิทธิ์กับข้อมูลอื่น เรากำลังหารือเกี่ยวกับปัญหาที่นี่ |
การลงทะเบียน | การทำให้ผู้ออกการลงทะเบียนกับผู้ให้บริการเบราว์เซอร์สามารถปฏิบัติได้จริงหรือไม่ | เราได้อัปเดตข้อกำหนดให้อธิบายถึงขั้นตอนการลงทะเบียนผู้ออกใบรับรองสำหรับโทเค็นสถานะส่วนตัว แม้ว่าจะใช้กระบวนการของตนเอง แต่ก็คล้ายกับแผนการลงทะเบียนสำหรับงานอื่นๆ ของ Privacy Sandbox โดยเราจะขอให้ผู้ออกแถลงการณ์ต่อสาธารณะเกี่ยวกับความตั้งใจในการใช้ PST และรับทราบข้อจำกัดทางเทคนิคซึ่งปกป้องความเป็นส่วนตัวของผู้ใช้ |