รายงานรายไตรมาสสำหรับไตรมาสที่ 2 ของปี 2023 ที่สรุปความคิดเห็นเกี่ยวกับระบบนิเวศที่ได้รับเกี่ยวกับข้อเสนอ Privacy Sandbox และคำตอบของ Chrome
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 พัฒนาขึ้นจากการเผยแพร่ คำถามที่พบบ่อย คำตอบจริงสำหรับประเด็นที่ผู้มีส่วนเกี่ยวข้องหยิบยกขึ้นมา และพิจารณาว่า ตามวัตถุประสงค์ของแบบฝึกหัดการรายงานต่อสาธารณะนี้โดยเฉพาะ สะท้อนให้เห็นถึงจุดมุ่งเน้นในปัจจุบันของการพัฒนาและการทดสอบ คำถาม และความคิดเห็น โดยเฉพาะในส่วนที่เกี่ยวข้องกับ Topics, Protected Audience และการระบุแหล่งที่มา Reporting API
ความคิดเห็นที่ได้รับหลังจากสิ้นสุดระยะเวลาการรายงานปัจจุบันอาจยัง เป็นการตอบสนองของ Chrome ที่ได้รับการพิจารณา
อภิธานศัพท์ของตัวย่อ
- CHIPS
- คุกกี้มีสถานะการแบ่งพาร์ติชันอิสระ
- DSP
- แพลตฟอร์มฝั่งดีมานด์
- FedCM
- การจัดการการรับรองแบบรวมศูนย์
- FPS
- ชุดของบุคคลที่หนึ่ง
- IAB
- หน่วยงานการโฆษณาอินเทอร์แอกทีฟ
- IDP
- ผู้ให้บริการข้อมูลประจำตัว
- IETF
- คณะทำงานเฉพาะกิจด้านวิศวกรรมอินเทอร์เน็ต
- IP
- ที่อยู่ Internet Protocol
- openRTB
- การเสนอราคาแบบเรียลไทม์
- OT
- ช่วงทดลองใช้จากต้นทาง
- PatCG
- กลุ่มชุมชนเทคโนโลยีโฆษณาส่วนตัว
- ผู้สัมผัส
- ฝ่ายที่ต้องพึ่งพา
- SSP
- แพลตฟอร์มฝั่งขาย
- TEE
- สภาพแวดล้อมการดำเนินการที่เชื่อถือได้
- UA
- สตริง User Agent
- UA-CH
- คำแนะนำสำหรับไคลเอ็นต์ User Agent
- W3C
- World Wide Web Consortium
- WIPB
- การมองเห็น 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 ความเกี่ยวข้องและการวัดผลในเวอร์ชันสำหรับผู้ใช้ทั่วไปได้ การดำเนินการนี้จะทำให้เกิดความคาบเกี่ยวกันระหว่างความพร้อมให้บริการของช่วงทดลองใช้จากต้นทางและเวอร์ชันสำหรับผู้ใช้ทั่วไป |
| การศึกษาของ 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 มุ่งมั่นที่จะออกแบบและติดตั้งใช้งานข้อเสนอ Privacy Sandbox ในลักษณะที่ไม่บิดเบือนการแข่งขันด้วยการเลือกธุรกิจของคุณของ Google เองเป็นหลัก และคํานึงถึงผลกระทบต่อการแข่งขันในการโฆษณาดิจิทัลและต่อผู้เผยแพร่โฆษณาและผู้ลงโฆษณา โดยไม่คำนึงถึงขนาดของบริษัท เราจะทำงานร่วมกับ CMA อย่างใกล้ชิดต่อไปเพื่อให้มั่นใจว่างานของเราจะเป็นไปตามความมุ่งมั่นเหล่านี้ ขณะที่การทดสอบ Privacy Sandbox ดำเนินไปอยู่ คำถามสำคัญอย่างหนึ่งที่เราจะประเมินคือ ประสิทธิภาพของเทคโนโลยีใหม่สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ ความคิดเห็นมีความสำคัญอย่างยิ่งในเรื่องนี้ โดยเฉพาะความคิดเห็นที่เฉพาะเจาะจงและนำไปใช้ได้จริงซึ่งจะช่วยให้เราปรับปรุงการออกแบบทางเทคนิคให้ดียิ่งขึ้นได้ เราทำงานร่วมกับ CMA เพื่อพัฒนาแนวทางในการทดสอบเชิงปริมาณและสนับสนุนให้ CMA เผยแพร่บันทึกเกี่ยวกับการออกแบบการทดสอบเพื่อให้ข้อมูลเพิ่มเติมแก่ผู้เข้าร่วมตลาดและเปิดโอกาสให้แสดงความคิดเห็นเกี่ยวกับแนวทางที่นำเสนอ" |
| หัวข้อสืบทอด | เมื่อใช้เกณฑ์การเลือกหัวข้อเป็นความถี่ของการเข้าชมเบราว์เซอร์ การกระจายกลุ่มจะทำให้หัวข้อที่สืบทอดมาไม่เคยขึ้นไปยังด้านบนสุดใช่หรือไม่ | ขณะนี้ Chrome กำลังประเมินวิธีการจัดอันดับอื่นๆ และสำรวจสัญญาณอื่นๆ ที่อาจช่วยปรับปรุงการจัดอันดับได้ และจะสื่อสารแผนงานที่แก้ไขแล้วกับระบบนิเวศได้โดยเร็ว |
| ความไว | เป้าหมายของ Topics API ควรเป็นเพื่อให้มั่นใจว่าข้อมูลผู้ใช้ที่ได้รับหรือได้มาจาก Topics API ควรมีความละเอียดอ่อนส่วนบุคคลน้อยกว่าข้อมูลที่ได้เมื่อใช้วิธีการติดตามในปัจจุบัน | เราเชื่อว่า Topics API เป็นส่วนตัวกว่าเทคโนโลยีปัจจุบันอย่างมาก จำกัดการระบุตัวตนของผู้ใช้ซ้ำอย่างชัดเจน และออกแบบมาเพื่อยกเว้นหัวข้อที่ละเอียดอ่อน เราทราบว่าหัวข้อต่างๆ สามารถเชื่อมโยงหรือรวมกับข้อมูลจากบุคคลที่หนึ่งเพื่อสร้างหมวดหมู่ที่ละเอียดอ่อน แต่เราเชื่อว่า Topics API เป็นความก้าวหน้าไปอีกขั้นในด้านความเป็นส่วนตัวของผู้ใช้ และเรามุ่งมั่นที่จะปรับปรุง API ต่อไป |
| โครงสร้างการจัดหมวดหมู่ | เพิ่มรหัส การกำหนดเวอร์ชัน และโครงสร้างข้อมูลเมตาอื่นๆ ในการจัดหมวดหมู่ของ Topics | ปัจจุบันเราได้รวมรหัสการจัดหมวดหมู่ไว้ในการตอบกลับของ API ในขณะที่เราก้าวสู่การกำกับดูแลในระยะยาว คุณควรตรวจสอบออบเจ็กต์ Topics และใส่ข้อมูลเมตาเพิ่มเติมเกี่ยวกับการกำหนดเวอร์ชันหากจำเป็น |
| การควบคุมของผู้เผยแพร่โฆษณา | ผู้เผยแพร่โฆษณาควรมีการระบุหัวข้อว่าเว็บไซต์ของตนควรได้รับการจัดประเภทเป็นหัวข้อใด | การจัดประเภทเว็บไซต์ที่ไม่ถูกต้องอาจทําให้สัญญาณ Topics มีประโยชน์น้อยลงเล็กน้อยในฐานะที่เป็นสัญญาณโดยรวม แต่เว็บไซต์หนึ่งๆ ที่ถูกจัดประเภทไม่ถูกต้องไม่ได้รับความเสียหายจากการเข้าชมเหล่านี้มากไปกว่าเว็บไซต์อื่นๆ ทั้งนี้เนื่องจากข้อมูลตามบริบทของเว็บไซต์จะพร้อมใช้งานสำหรับการประมูลในเว็บไซต์นั้นๆ เสมอ ซึ่งจะให้ข้อมูลที่เปรียบเทียบกับหัวข้อที่ถูกต้องได้ แม้ว่าจะมีการจัดประเภทที่ไม่ถูกต้องก็ตาม เรายินดีรับความคิดเห็นเกี่ยวกับเรื่องนี้ที่นี่ การอนุญาตให้ผู้เผยแพร่โฆษณาควบคุมการจัดประเภทของตนนั้นมีความเสี่ยง เว็บไซต์อาจจัดประเภทเว็บไซต์ไม่ถูกต้องโดยเจตนา ลดประโยชน์สําหรับทั้งหมด หรือเข้ารหัสความหมายที่มีความละเอียดอ่อนในหัวข้อที่พบไม่บ่อย ซึ่งเป็นอันตรายต่อความเป็นส่วนตัวของผู้ใช้ |
| ส่วนขยาย Chrome | อนุญาตให้ส่วนขยาย Chrome จัดการและกรองหัวข้อ ซึ่งคล้ายกับส่วนขยายการจัดการคุกกี้ในปัจจุบัน | ซึ่งมีความเป็นไปได้อยู่แล้วดังที่อธิบายไว้ใน GitHub แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
| การเปลี่ยนไปใช้เวอร์ชันสำหรับผู้ใช้ทั่วไป | Topics API จะมีผลอย่างไรเมื่อเปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไป | ข้อมูลจะไม่สูญหายสำหรับผู้ใช้ที่เปลี่ยนจากช่วงทดลองใช้จากต้นทางไปเป็นเวอร์ชันสำหรับผู้ใช้ทั่วไป |
| ความเป็นส่วนตัว | ชื่อโฮสต์อาจมีข้อมูลส่วนตัวที่ Topics API อาจเปิดเผย | เรามีการผ่อนปรนชั่วคราวหลายอย่างเพื่อรักษาความเป็นส่วนตัวดังที่ระบุไว้ที่นี่ |
| การประพฤติมิชอบและการละเมิด | วิธีป้องกันการบิดเบือน Topics ด้วยการเข้าชมที่เป็นการฉ้อโกง | มีคำอธิบายเกี่ยวกับการผ่อนปรนชั่วคราวที่นี่ |
| ตัวแยกประเภทหัวข้อ | เว็บไซต์จะขอเปลี่ยนการจัดประเภท Topics ได้ไหม | เราอยากรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับเรื่องนี้ และขอยินดีรับฟังความคิดเห็นจากคุณที่นี่ |
| เว็บไซต์ผู้ให้บริการ Topics | กำหนดบางเว็บไซต์ที่โฮสต์เนื้อหาสำหรับ Topics จำนวนมากเป็น "เว็บไซต์ Topics Provider พิเศษ" และฝึกตัวแยกประเภทโดยอิงตามแท็กที่ให้ไว้ในหน้าเว็บ | เรากำลังพูดคุยเกี่ยวกับข้อเสนอที่นี่ และยินดีรับฟังความคิดเห็นเพิ่มเติม |
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" เมื่อใด | เรากำลังสร้างคำอธิบายสำหรับไทม์ไลน์การบังคับใช้ที่เราจะเผยแพร่ในเร็วๆ นี้ |
| ข้อจำกัดของ RunAdAuction | 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 ลงในโปรแกรมเล่นวิดีโอด้วยเช่นกัน) ผู้ซื้อสามารถแสดงผลโฆษณาทั้ง 2 รูปแบบผ่าน 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 สำหรับสัญญาณ PerBuyer จึงกำลังประเมินตัวเลือกเพิ่มเติม เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศว่าการแคชเหมาะกับกรณีการใช้งานหรือไม่ |
| Attribution Reporting และ Protected Audience | Attribution Reporting API และ Protected 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 รองรับ Use Case ทางการตลาดที่หลากหลายตามกลุ่มเป้าหมาย เรายังคงทำความเข้าใจว่า 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 รองรับคีย์ได้สูงสุดกี่คีย์ | ขีดจำกัดปัจจุบันคือขนาด 1 IG ที่ 50 KB และนับรวมคีย์ด้วย เรายินดีรับการสนทนาเพิ่มเติมเกี่ยวกับขีดจำกัดของขนาด |
| แบบกลุ่ม | ฉันจะลดจำนวนการเรียกใช้เซิร์ฟเวอร์ K/V ได้อย่างไร | คุณสามารถใช้ส่วนหัว Cache-Control ของ HTTP เพื่อลดจำนวนการเรียกใช้ K/V ได้ เช่น อาจมีการแคชไว้ในการประมูลคอมโพเนนต์และช่องโฆษณาในหน้าเดียว |
| การควบคุมเวอร์ชัน | การรองรับโค้ดเทคโนโลยีโฆษณาหลายเวอร์ชัน | บริการเสนอราคาและประมูลจะรองรับโค้ดเทคโนโลยีโฆษณาหลายเวอร์ชัน ใน API การเสนอราคาและการประมูล คำขอ SelectAd จะระบุเวอร์ชันของโค้ดที่ใช้สำหรับคำขอการประมูล (เช่น สำหรับการเสนอราคา / การประมูลและการรายงาน) |
| พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน | รองรับการเขียนถึงพื้นที่เก็บข้อมูลที่ใช้ร่วมกันในบริการเสนอราคาและประมูล | ปัจจุบันบริการเสนอราคาและบริการประมูลยังไม่รองรับพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับสาเหตุที่กรณีการใช้งานดังกล่าวมีความสำคัญต่อระบบนิเวศ |
| เว็บไปยังแอป | รองรับการแชร์กลุ่มความสนใจจากเว็บไปยังแอป | ขณะนี้เว็บไปยังแอปยังไม่ได้กำหนดขอบเขตในการใช้งาน Protected Audience API ใน Chrome และ Android แต่เราสนใจที่จะรับฟังความคิดเห็นจากระบบนิเวศเกี่ยวกับความสำคัญของ Use Case นี้ |
| การไม่ระบุตัวตน | วิธีจัดการกับวิดีโอสำรอง K-Anonymity | เรากำลังปรึกษาปัญหาและยินดีรับฟังความคิดเห็นเพิ่มเติม |
การวัดผลโฆษณาดิจิทัล
Attribution Reporting (และ API อื่นๆ)
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| การกำหนดค่ารายงานระดับเหตุการณ์ VTC อื่นๆ | ความคิดเห็นเกี่ยวกับการกำหนดค่ารายงานระดับเหตุการณ์ VTC ทางเลือก | เราได้รับความคิดเห็นมาว่าการกำหนดค่าระดับเหตุการณ์ในปัจจุบันยังไม่เหมาะสม และเราขอความคิดเห็นเกี่ยวกับการกำหนดค่าส่วนกลางที่มีประสิทธิภาพสูงสุด เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับเรื่องนี้ และคิดว่าวิดีโออธิบายระดับกิจกรรมที่ยืดหยุ่นจะช่วยแก้ไขปัญหานี้ได้ |
| การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น | ฟีเจอร์การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นมีสถานะใด | เราได้แชร์เอกสารประกอบเกี่ยวกับการกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น คุณลักษณะยังอยู่ในขั้นการเสนอเพลง และเราต้องการทราบความคิดเห็นเพิ่มเติมเกี่ยวกับสถานะของคุณลักษณะที่จะเป็นประโยชน์ต่อระบบนิเวศนี้ |
| การกำหนดค่าระดับเหตุการณ์ที่ยืดหยุ่น | รายงานที่ขัดแย้งกันจากหลายฝ่ายจะกระทบยอดได้อย่างไร | สถานการณ์การรายงานส่วนใหญ่แก้ไขได้โดยใช้รายงานสรุป ส่วนข้อเสนอการกําหนดค่าระดับเหตุการณ์ที่ยืดหยุ่นจะให้ความยืดหยุ่นเพิ่มเติมสําหรับรายงานระดับเหตุการณ์โดยเฉพาะ ซึ่งมักใช้สำหรับ Use Case การเพิ่มประสิทธิภาพ เรายินดีรับฟังความคิดเห็นและข้อเสนอแนะเพิ่มเติมเกี่ยวกับระบบนิเวศนี้เกี่ยวกับสถานการณ์นี้ |
| การลงทะเบียนแหล่งที่มา | จะเกิดอะไรขึ้นหากการลงทะเบียนแหล่งที่มาเกิดขึ้นหลังจากการลงทะเบียนทริกเกอร์ | ในปัจจุบัน หากการลงทะเบียนแหล่งที่มาเกิดขึ้นหลังจากการลงทะเบียนทริกเกอร์ แหล่งที่มาและทริกเกอร์จะไม่สามารถระบุแหล่งที่มาว่ากันและกันได้ นี่อาจเป็นสถานการณ์ที่เป็นปัญหา เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับปัญหานี้ และจะพยายามแก้ปัญหาหากเป็นสถานการณ์ที่พบเจอกับเทคโนโลยีโฆษณาที่หลายคนต้องเผชิญ |
| การทำงานร่วมกับเอเจนซีโฆษณาหลายแห่ง | DSP จะใช้ Attribution Reporting API ได้อย่างไร เมื่อผู้ลงโฆษณาทำงานร่วมกับเอเจนซีโฆษณาหลายแห่ง | API รองรับการเปลี่ยนเส้นทาง ดังนั้นจึงใช้ได้แม้ในกรณีที่ผู้ลงโฆษณาทำงานร่วมกับเอเจนซีโฆษณาหลายแห่ง นอกจากนี้ ยังมีข้อจำกัดบางอย่างเกี่ยวกับการเปลี่ยนเส้นทาง เพื่อให้มั่นใจว่า API จะปรับปรุงความเป็นส่วนตัว เรายังได้ระบุวิธีแก้ปัญหาเบื้องต้นที่ใช้ Shared Storage API กับสถานการณ์ที่เทคโนโลยีโฆษณาได้หยิบยกขึ้นมาด้วย เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับสถานการณ์นี้ และจะปรับปรุงอย่างต่อเนื่องตามความคิดเห็นที่ได้รับ |
| ขีดจำกัดปลายทาง | กรณีการใช้งานโฆษณาที่รีเฟรชอัตโนมัติอาจได้รับผลกระทบจากการมีขีดจํากัดปลายทาง | เราได้พูดคุยถึงปัญหานี้ในการประชุม WICG ในวันที่ 1 พฤษภาคมและกำลังมองหาความคิดเห็นเกี่ยวกับขีดจำกัดที่สมเหตุสมผล เราได้เพิ่มลงใน Attribution Reporting พร้อมตัวอธิบายรายงานระดับเหตุการณ์ โดยระบุว่าเบราว์เซอร์สามารถจำกัดจำนวน eTLD+1 "ปลายทาง" ที่แสดงโดยเว็บไซต์แหล่งที่มาได้ (ดูคำขอพุล) |
| Attribution Reporting และ Protected Audience | Attribution Reporting API และ Protected 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 เป็นต้นไป เราจะเริ่มเปิดใช้ Relevance and Measurement 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) จะเป็นประโยชน์ต่อระบบนิเวศนี้มากที่สุด อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมว่าเหตุใดจึงจำเป็นต้องปฏิบัติตามข้อกำหนดดังกล่าว |
| ประมวลผลรายงานอีกครั้งสำหรับช่วงเวลาต่างๆ | ความสามารถในการประมวลผลรายงานอีกครั้งในช่วงเวลาต่างๆ | เราได้รับคําขอที่คล้ายกันให้แบ่งกลุ่มสําหรับช่วงวันที่ต่างๆ ได้ ข้อเสนอหนึ่งคือให้ขยายรหัสที่แชร์ด้วยป้ายกำกับที่กำหนดโดยเทคโนโลยีโฆษณาได้ เพื่อให้ระบบแยกรายงานออกเป็นกลุ่มๆ ได้ เราอยู่ในขั้นตอนเริ่มต้นในการประเมินกระบวนการนี้ และจะอัปเดตระบบนิเวศเมื่อข้อเสนอนี้เปลี่ยนแปลงไป |
| ผลกระทบด้านความเป็นส่วนตัวของสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ | ความรู้สึกในแง่บวกต่อนัยยะด้านความเป็นส่วนตัวของสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ | เรายินดีที่ได้ทราบผลตอบรับเชิงบวกจากระบบนิเวศเกี่ยวกับข้อเสนอของเรา และยินดีรับฟังความคิดเห็นเพิ่มเติมในระหว่างที่เดินหน้าปรับปรุงและพัฒนาต่อไป |
| ข้อกำหนดในการให้บริการ | วันสุดท้ายในการยอมรับข้อกำหนดในการให้บริการของ Aggregation Service คือเมื่อใด | แม้จะยังไม่ได้ระบุกำหนดเวลาในการยอมรับข้อกำหนดในการให้บริการ แต่เราขอแนะนำให้บริษัทในระบบนิเวศยอมรับข้อกำหนดและเงื่อนไขโดยเร็วที่สุดเพื่อป้องกันความล่าช้าในการลงทะเบียน เราแนะนำให้บริษัทต่างๆ ติดต่อเราหากมีข้อสงสัย |
| การค้นพบที่สำคัญ | ฟีเจอร์การค้นพบคีย์จะช่วยให้ผู้ทดสอบค้นหารายงานสรุปได้โดยไม่จำเป็นต้องมีรายการชุดค่าผสมที่เป็นไปได้ที่ชัดเจนเพื่อประมวลผลรายงานสรุปสำหรับการระบุแหล่งที่มาข้ามเครือข่ายเพื่อปรับปรุงประสิทธิภาพและความแม่นยำให้ดีขึ้น | ขณะนี้เรากำลังสำรวจโซลูชันและวิธีแก้ปัญหาที่เป็นไปได้ และยินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
Private Aggregation API
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| ต้นทางการรายงาน | ที่มาของการรายงานมีคำจำกัดความว่าอย่างไร | ต้นทางการรายงานจะเป็นต้นทางสคริปต์ของผู้โทรการรวมข้อมูลแบบส่วนตัวเสมอ |
| พื้นที่คีย์ 128 บิต | ความชัดเจนเกี่ยวกับขีดจำกัดของพื้นที่คีย์ 128 บิต | เราจะทำให้ข้อจำกัดของคีย์สเปซนี้ชัดเจนยิ่งขึ้น และแก้ไขความไม่สอดคล้องของหน้าต่างๆ เราขอแนะนำให้ใช้กลยุทธ์การแฮชเพื่อให้อยู่ในช่องว่างนี้ |
| สัดส่วนสูงสุดต่อรายงาน | ขีดจำกัดการมีส่วนร่วม 20 รายการต่อรายงานในปัจจุบันต่ำเกินไป | แทนที่จะเพิ่มจำนวนการมีส่วนร่วมสูงสุด เรายินดีพิจารณาแยกรายงานแทนการตัดข้อความให้เหลือตามจำนวนสูงสุด เราจะมีส่วนร่วมกับระบบนิเวศเมื่อข้อเสนอนี้เปลี่ยนแปลงไป |
| การรายงานการเข้าถึง | ขอการเข้าถึงการรายงานแบบข้ามแพลตฟอร์ม/ข้ามอุปกรณ์ การเข้าถึงเป็นเมตริกพื้นฐานของการโฆษณาแบรนด์ ผู้ลงโฆษณาอาศัยค่าประมาณแบบข้ามแพลตฟอร์ม/ข้ามอุปกรณ์สำหรับการรายงานการเข้าถึงและความถี่เพื่อวิเคราะห์แคมเปญและจัดสรรการใช้จ่าย โมเดลการเข้าถึงใช้คุกกี้ของบุคคลที่สามเป็นสัญญาณในการวัดโฆษณาที่แสดงในสภาพแวดล้อมของบุคคลที่สาม เทคโนโลยีโฆษณาจึงได้ขอโซลูชันทางเลือกเมื่อเลิกใช้งานคุกกี้ของบุคคลที่สามแล้ว |
ทีม Privacy Sandbox กำลังศึกษาฟีเจอร์ต่างๆ ที่จะรองรับวิธีการการเข้าถึงแบบข้ามโดเมนหลังการเลิกใช้งานคุกกี้ของบุคคลที่สาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศ |
จำกัดการติดตามแบบไม่เปิดเผย
การลด User Agent/คำแนะนำสำหรับไคลเอ็นต์ User Agent
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| (รายงานในไตรมาสที่ 1 ปี 2023 เช่นกัน) คำแนะนำสำหรับรูปแบบของอุปกรณ์เพิ่มเติม | ขอคําแนะนําไคลเอ็นต์ของ User Agent (UA-CH) เพื่อระบุรูปแบบของอุปกรณ์เพิ่มเติม เช่น TV, VR | เรายังคงอยู่ระหว่างตัดสินใจด้านการออกแบบที่สำคัญ (ว่าจะระบุค่าเดียว เช่น "ทีวี" หรือรายการความสามารถของรูปแบบของอุปกรณ์) แต่ยังคงสนใจที่จะสร้างต้นแบบของไอเดียนี้ |
| งบประมาณความเป็นส่วนตัว | ข้อจำกัดด้านงบประมาณความเป็นส่วนตัวอาจทำให้คำขอ UA-CH ไม่เป็นไปตามข้อกำหนดเมื่อมีการส่งคำขอมากเกินไป | เรายังไม่มีข้อมูลอัปเดตใหม่ๆ เกี่ยวกับข้อเสนองบประมาณความเป็นส่วนตัวในขณะนี้ แต่เรามุ่งมั่นที่จะไม่จำกัดคำขอสำหรับคำแนะนำของไคลเอ็นต์ UA ก่อนที่จะมีการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
| ความเข้ากันได้ของไซต์ | เว็บไซต์ใช้แบรนด์ UA-CH เพื่อจํากัดไม่ให้บางเบราว์เซอร์เข้าถึงเว็บไซต์ | มีกรณีการใช้งานที่ถูกต้องสำหรับรายการแบรนด์และหนึ่งในนั้นคือความเข้ากันได้อย่างแม่นยำ UA มีแบรนด์ต่างๆ เพื่อจัดการกับปัญหาเหล่านี้ได้อย่างอิสระ |
การปกป้อง IP (เดิมคือ Gnatcatcher)
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| การประพฤติมิชอบและ ละเมิด | บริษัทต่างๆ จะกำหนดมาตรการป้องกันการประพฤติมิชอบด้วยการปกป้อง IP ได้อย่างไร | เราเข้าใจถึงความสำคัญของ Use Case การป้องกันการประพฤติมิชอบและผลกระทบที่อาจเกิดขึ้นกับ Use Case เหล่านั้น เราวางแผนที่จะเผยแพร่รายละเอียดเพิ่มเติมเกี่ยวกับการสนับสนุนการต่อต้านการประพฤติมิชอบในช่วงหน้าร้อนนี้ เราต้องการทราบความคิดเห็นจากระบบนิเวศเกี่ยวกับวิธีที่เราจะสนับสนุนกรณีการใช้งานที่ป้องกันการประพฤติมิชอบได้ดีขึ้น |
| GeoIP | ข้อมูลเพิ่มเติมเกี่ยวกับไทม์ไลน์การทดสอบและการติดตั้งใช้งานสำหรับ GeoIP | เมื่อเร็วๆ นี้ Chrome ได้เผยแพร่ข้อมูลใหม่เกี่ยวกับแผน GeoIP ของเรา เรากำลังวางแผนที่จะเผยแพร่ข้อมูลเพิ่มเติมเกี่ยวกับลำดับเวลาการติดตั้งใช้งานในไตรมาสที่ 3 เราคาดว่าจะเปิดตัวการปกป้อง IP ในฐานะฟีเจอร์ที่ผู้ใช้เลือกใช้กับการเข้าชมเพียงไม่กี่เปอร์เซ็นต์ในช่วงแรก เนื่องจากเราตระหนักดีว่าข้อเสนอนี้อาจมีการเปลี่ยนแปลงที่สำคัญสำหรับบริษัทต่างๆ และเราอยากให้เวลาระบบนิเวศในการปรับตัวและแสดงความคิดเห็นก่อนที่จะมีการเปิดตัวฟีเจอร์นี้ในวงกว้างขึ้น |
| การตรวจสอบสิทธิ์บัญชี | การตรวจสอบสิทธิ์บัญชีกับพร็อกซีเซิร์ฟเวอร์จะทำงานอย่างไร | เราวางแผนที่จะเผยแพร่รายละเอียดเพิ่มเติมเกี่ยวกับการตรวจสอบสิทธิ์บัญชีในช่วงปลายฤดูร้อนนี้ แต่เราได้แจ้งข้อพิจารณาเบื้องต้นไปบ้างแล้ว |
การลดการติดตามการเข้าออก
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| คำแนะนำในการทดสอบ | ข้อมูลเกี่ยวกับวิธีทดสอบการลดการติดตามการเข้าออก | เราได้เผยแพร่ บล็อกโพสต์ในเดือนพฤษภาคมพร้อมข้อมูลเพิ่มเติมเกี่ยวกับวิธีทดสอบการลดการติดตามการเข้าออก |
| เอกสารประกอบ | ความชัดเจนของข้อเสนอการติดตามการเข้าออก | ข้อเสนอปัจจุบันยังอยู่ระหว่างการพัฒนาและ Chrome ก็อัปเดตข้อเสนอดังกล่าวอย่างต่อเนื่องเพื่อแสดงความชัดเจนและข้อมูลแก่ระบบนิเวศ เรากำลังดำเนินการให้รายละเอียดเพิ่มเติมและยินดีรับฟังความคิดเห็นเพิ่มเติม |
| การลบคุกกี้ | การลดการติดตามการเข้าออกจะลบคุกกี้ทั้งหมดในโดเมนหรือไม่ | การลดการติดตามการเข้าออก (BTM) จะล้างพื้นที่เก็บข้อมูลและแคชทั้งหมดตามที่อธิบายไว้ที่นี่ |
| การหลีกเลี่ยงการลดการติดตามการเข้าออก | อาจข้ามการจัดประเภทของเครื่องมือติดตามการเข้าออกได้โดยการเปลี่ยนเส้นทางโดยใช้ป๊อปอัปหรือแท็บใหม่ | ข้อกำหนดจำเพาะของการลดการติดตามการเข้าออกยังอยู่ระหว่างการพัฒนา ที่ผ่านมาเราให้ความสำคัญกับการเปลี่ยนเส้นทางในแท็บเดียวกันเป็นส่วนใหญ่ แต่เราวางแผนที่จะดำเนินการในรูปแบบป๊อปอัปในอนาคต เรายินดีรับฟังความคิดเห็นเพิ่มเติมที่นี่ |
งบประมาณความเป็นส่วนตัว
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| การกำหนดเป้าหมายที่ใกล้เคียง | งบประมาณความเป็นส่วนตัวอาจส่งผลต่อกรณีการใช้งานการกำหนดเป้าหมายสถานที่ใกล้เคียง | เราได้รับความคิดเห็นเกี่ยวกับปัญหานี้แล้วและสนใจที่จะฟังข้อมูลเพิ่มเติมเกี่ยวกับผลกระทบที่อาจเกิดขึ้นจากระบบนิเวศ |
เสริมสร้างขอบเขตความเป็นส่วนตัวข้ามเว็บไซต์
ชุดโดเมนของบุคคลที่หนึ่ง
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| (รายงานในไตรมาสก่อนหน้าด้วย) ขีดจำกัดโดเมน | คำขอเพิ่มจำนวนโดเมนที่เชื่อมโยง | Chrome กำลังประเมินขีดจำกัดตัวเลขที่เหมาะสมสำหรับชุดย่อยที่เกี่ยวข้อง ซึ่งจะสร้างสมดุลระหว่างความเป็นส่วนตัวและประโยชน์ใช้สอยสำหรับ Use Case ที่ได้ระบุไว้ นับตั้งแต่เริ่มต้น Chrome แจ้งว่าจำนวนที่แน่นอนของชุดข้อมูลย่อยที่เชื่อมโยงนั้นยังไม่ได้สรุป |
| กรณีการใช้งานที่ฝัง | การรองรับ Use Case แบบฝังที่ต้องใช้ชุดโดเมนของบุคคลที่หนึ่ง, CHIP และพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน | Chrome ได้รับความคิดเห็นเกี่ยวกับกรณีการใช้งานนี้ และทีมกำลังตรวจสอบยินดีรับความคิดเห็นเพิ่มเติม |
| การจัดการที่เก็บ | ข้อมูลเกี่ยวกับนโยบายการนำชุดโดเมนของบุคคลที่หนึ่งออกจากที่เก็บ GitHub หากมีความคลาดเคลื่อนหรือละเลย | Chrome ได้รับความคิดเห็นเกี่ยวกับกรณีการใช้งานนี้แล้ว ทีมของเรากำลังตรวจสอบและขอความคิดเห็นเพิ่มเติม |
| การให้ความรู้แก่ผู้ใช้ | Chrome ควรเพิ่มการรับรู้และความเข้าใจของผู้ใช้เกี่ยวกับชุดโดเมนของบุคคลที่หนึ่งเพื่อกระตุ้นการใช้งาน | Chrome มุ่งมั่นที่จะให้ความรู้แก่ผู้ใช้เกี่ยวกับชุดโดเมนของบุคคลที่หนึ่ง และได้เผยแพร่ บทความในศูนย์ช่วยเหลือ (เชื่อมโยงจาก UI ของ Chrome) เกี่ยวกับเรื่องนี้ นอกจากนี้ Chrome ยังลงทุนอย่างต่อเนื่องในการเรียนรู้วิธีให้ความรู้ที่ดีที่สุดแก่ผู้ใช้ในบริบทที่เหมาะสม |
| โพสต์ของบุคคลที่สาม PCD | คุกกี้ของบุคคลที่สามจะยังคงอยู่ในชุดโดเมนของบุคคลที่หนึ่งหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม | แม้ว่า requestStorageAccess และ requestStorageAccessFor จะทำให้คุกกี้ของบุคคลที่สามพร้อมใช้งานอีกครั้งสำหรับ Use Case ที่เจาะจงและกำหนดไว้อย่างชัดเจน แต่ตอนนี้การตั้งค่าดังกล่าวต้องใช้การเรียกใช้ที่ใช้งานอยู่ในเว็บไซต์ แทนที่จะพร้อมใช้งานโดยค่าเริ่มต้น เช่นเดียวกับสถานะปัจจุบันของคุกกี้ของบุคคลที่สาม (ใน Chrome)แม้ว่าการเรียกใช้นี้ภายในชุดเดียวจะไม่จำเป็นต้องได้รับการอนุมัติจากผู้ใช้ แต่ผู้ใช้สามารถป้องกันการเรียกใช้นี้ได้โดยเลือกไม่ใช้ลักษณะการทำงานนี้ในการตั้งค่า ดูข้อมูลเพิ่มเติมได้ในบทความในศูนย์ช่วยเหลือ (ลิงก์จาก UI ของ Chrome) เราวางแผนที่จะขยายการใช้งานจากคู่มือนักพัฒนาซอฟต์แวร์ที่มีอยู่เนื่องจาก FPS จะเพิ่มขึ้นถึง 100% |
| การส่งชุดโดเมนของบุคคลที่หนึ่ง | เปลี่ยนชื่อ .well-known/first-party-set ที่จำเป็นเพื่อรวมส่วนขยาย .json |
เราทำการเปลี่ยนแปลงนี้เพื่อให้ระบบรองรับแพ็กเกจเว็บโฮสติ้งบางแพ็กเกจ |
| การจดทะเบียน IANA | first_party_sets.JSON ควรจดทะเบียนกับ IANA |
เรากำลังพิจารณาข้อเสนอและยินดีรับความคิดเห็นเพิ่มเติมที่นี่ |
API เฟรมที่มีการปิดกั้น
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| การบล็อกโฆษณา | เฟรมที่มีการปิดกั้นอาจทำให้ตัวบล็อกโฆษณาบล็อกโฆษณาได้ง่ายขึ้น | ส่วนขยายสามารถโต้ตอบกับเฟรมที่มีการปิดกั้นคล้ายกับการโต้ตอบกับ iframe URL จริงที่เฟรมที่ปิดกั้นกำลังจะไปถึงจะแสดงต่อส่วนขยายด้วย ดังนั้นจึงสามารถใช้กฎการจับคู่ URL กับการบล็อกเช่นเดียวกับใน iframe การบล็อกเฟรมที่มีการปิดกั้นทั้งหมดอย่างไม่มีเงื่อนไขอาจทำให้กรณีการใช้งานที่ไม่ใช่โฆษณาเสียหายสำหรับเฟรมที่มีการปิดกั้น |
Shared Storage API
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| การใช้งานที่กว้างขึ้น | พื้นที่เก็บข้อมูลที่ใช้ร่วมกันควรเป็นมาตรฐานที่ใช้ทั่วทั้งอุตสาหกรรมและบนเบราว์เซอร์ต่างๆ | เรายินดีรับฟังและรับทราบความคิดเห็นนี้ Chrome ยังคงเข้าร่วมกับ W3C อย่างต่อเนื่องเพื่อสนับสนุนข้อเสนอ ขอความคิดเห็น และผลักดันให้เกิดการนำไปใช้ |
| ประตูเอาต์พุต | เกตเอาต์พุตของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันถูกจำกัดมากเกินไป | เรากำลังพิจารณาความคิดเห็นนี้ และยินดีรับฟังความคิดเห็นเพิ่มเติมสำหรับระบบนิเวศเกี่ยวกับสาเหตุที่ขีดจำกัดเอาต์พุตของเอาต์พุต |
| การปฏิบัติตามกฎระเบียบ | พื้นที่เก็บข้อมูลที่ใช้ร่วมกันจะจัดการกับการปฏิบัติตามกฎระเบียบ เช่น นโยบายการเก็บรักษาข้อมูล อย่างไร | พื้นที่เก็บข้อมูลที่ใช้ร่วมกันมีความยืดหยุ่นในการใช้งานและปรับแต่งตรรกะเพื่อควบคุมอายุการใช้งานและการหมดอายุของข้อมูลที่จัดเก็บไว้ เทคโนโลยีโฆษณาสามารถอัปเดตหรือล้างข้อมูลในพื้นที่เก็บข้อมูลที่ใช้ร่วมกันได้ตามการประทับเวลาการเขียน |
| การทดสอบ A/B | จะทำการทดสอบ 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) หลังการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
ต่อสู้กับสแปมและการประพฤติมิชอบ
Private State Token API (และ API อื่นๆ)
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
|---|---|---|
| การสำรวจสัญญาณใหม่ๆ | พาร์ทเนอร์หลายรายแสดงความคิดเห็นในแง่บวกต่อการสำรวจสัญญาณที่อำนวยความสะดวกโดยเบราว์เซอร์ที่บ่งบอกถึงความสมบูรณ์ของอุปกรณ์หรือความไว้วางใจของผู้ใช้ โดยทั่วไปแล้ว พวกเขาจะระมัดระวังเกี่ยวกับสัญญาณที่สร้างขึ้นเพื่อวัตถุประสงค์ใหม่ๆ ซึ่งเพียงพอที่จะรักษาระดับการตรวจจับการประพฤติมิชอบในปัจจุบัน | เราตื่นเต้นที่จะได้สำรวจข้อเสนอใหม่ๆ ร่วมกันภายในชุมชนต่อต้านการฉ้อโกงและความปลอดภัยของเว็บ รวมถึงรับทราบและแชร์ข้อกังวลของพวกเขาด้วย นี่จึงเป็นเหตุผลว่าทำไม "การต่อสู้กับสแปมและการประพฤติมิชอบ" ถือเป็นแนวทางหลักของ Privacy Sandbox และเป็นเหตุผลที่เรายังคงให้ความสำคัญกับการลงทุนด้านการรักษาความปลอดภัยของเว็บอย่างต่อเนื่องไปพร้อมๆ กับปรับปรุงความเป็นส่วนตัวของผู้ใช้ |
| ความคิดเห็นเชิงบวกเกี่ยวกับ PST | พาร์ทเนอร์หลายรายได้แสดงความสนใจในการทดสอบหรือใช้งาน PST สำหรับกรณีการใช้งานต่างๆ ด้านการป้องกันการฉ้อโกงหรือความปลอดภัยของเว็บ | เราตื่นเต้นที่จะได้รับฟังการสนับสนุนและความสนใจที่จะศึกษาเพิ่มเติมเกี่ยวกับโซลูชันใหม่ๆ ที่ใช้ PST เรามีทรัพยากรและโค้ดตัวอย่างพร้อมให้บริการผ่านเว็บไซต์นักพัฒนาซอฟต์แวร์ Chrome เรายินดีรับฟังความคิดเห็นเพิ่มเติม |
| การประพฤติมิชอบและการละเมิด | คำแนะนำสำหรับการป้องกันการฉ้อโกงผ่านโฆษณา / การตรวจหาในการวัดผลหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามเมื่อตัวระบุไม่พร้อมใช้งานอีกต่อไป | เราได้เปิดตัวเครื่องมือต่างๆ เช่น โทเค็นสถานะส่วนตัว ซึ่งช่วยกู้คืนสัญญาณบางส่วนที่คุกกี้ของบุคคลที่สามสูญหายไปเพื่อวัตถุประสงค์ด้านการป้องกันการประพฤติมิชอบ แต่ก็มีการควบคุมความเป็นส่วนตัวแบบใหม่อยู่แล้ว เรามุ่งมั่นทุ่มเทลงทุนกับข้อเสนอใหม่ด้านการป้องกันการประพฤติมิชอบและการละเมิด เพื่อรักษาความสามารถไว้ตามการเปลี่ยนแปลงอื่นๆ ของ Privacy Sandbox |
| อัตราการกรอกข้อมูลจากผู้ออกบัตรต่อต้นทาง | อัตราข้อมูลผู้ออกใบรับรองต่อต้นทางสูงเพียงพอที่จะระบุผู้ใช้ที่ไม่ซ้ำ | เราได้อัปเดตข้อกำหนดให้มีความชัดเจนยิ่งขึ้นเกี่ยวกับข้อมูลผู้ใช้ที่สามารถสื่อสารได้โดยใช้โทเค็นสถานะส่วนตัว เราออกแบบให้สามารถใช้คีย์สาธารณะพร้อมกันได้สูงสุด 6 รายการ ซึ่งอาจแสดงถึง "สถานะ" สำหรับผู้ใช้รายหนึ่งๆ ชุดคีย์เหล่านี้จะอัปเดตทุกๆ 60 วันเท่านั้น (ยกเว้นในบางกรณีที่ต้องมีการหมุนเวียนคีย์ฉุกเฉิน) ซึ่งจะทำให้โอกาสในการรวมข้อมูลผู้ใช้เพิ่มเติมช้าลงเมื่อเวลาผ่านไป สำหรับ Web API ใหม่ใดก็ตาม จะมีความสมดุลระหว่างประโยชน์และข้อมูลผู้ใช้ใหม่ที่มีให้ เราคาดว่า PST จะมีจุดสมดุลที่เหมาะสมในการปกป้องความเป็นส่วนตัวของผู้ใช้ ในขณะเดียวกันก็เปิดใช้ Use Case หลักๆ เพื่อป้องกันการประพฤติมิชอบซึ่งได้รับผลกระทบจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
| การผสานรวมการดึงข้อมูล | การผสานรวม fetch มีความซับซ้อนและไม่จำเป็น |
การใช้ fetch มีข้อดีและข้อเสียอยู่ และเราก็ต้องการที่จะกำหนดมาตรฐานต่อไปภายในระบบนิเวศของเว็บ แต่เราคิดว่าคงเร็วเกินไปที่จะทำการเปลี่ยนแปลงนี้จนกว่าเราจะเข้าใจได้ชัดเจนยิ่งขึ้นว่ามาตรฐานนี้จะมีหน้าตาเป็นอย่างไร หากและเมื่อเกิดมาตรฐานนี้ขึ้น เรามุ่งมั่นที่จะเปลี่ยนนักพัฒนาเว็บไปใช้มาตรฐานดังกล่าวอย่างมีความรับผิดชอบ |
| ตำแหน่งของพื้นที่เก็บข้อมูล | ควรเก็บการกำหนดค่าคีย์ Private State Tokens ไว้ในตำแหน่งเดียวกับโปรโตคอล PrivacyPass | ระหว่างการทดสอบระหว่างช่วงทดลองใช้จากต้นทาง นักพัฒนาแอประบุว่าต้องการให้มีความยืดหยุ่นในการจัดเก็บคีย์ใน URL ทั่วไปแทนในไดเรกทอรี .well-known รูปแบบสัญญาผูกมัดคีย์ใน PrivacyPass ไม่เหมาะกับเวอร์ชันที่ชุดคีย์มีไว้เพื่ออนุญาตให้มี "ข้อมูลเมตาสาธารณะ" โดยนัย หาก PrivacyPass เวอร์ชันหนึ่งได้รับการกำหนดค่ามาตรฐานโดยมีข้อมูลเมตาสาธารณะ (ไม่ว่าจะเป็น POPRF, การปิดบัง RSA บางส่วน หรือคีย์เซ็ต) เราอาจย้ายไปยัง PST เวอร์ชันในอนาคตเพื่อรองรับการดำเนินการดังกล่าว |
| การใช้งานส่วนหัวของ API | คำถามเกี่ยวกับการใช้งานส่วนหัวของ API | เมื่อ API ได้รับการปรับให้เป็นมาตรฐานและการใช้งานในระบบนิเวศของ API นี้จะได้รับการพัฒนามากขึ้น เราหวังว่าจะสามารถรองรับทั้งเวอร์ชันมาตรฐานที่ไม่ใช่ส่วนหัวของ API นี้ และอาจเลิกใช้งานเวอร์ชันส่วนหัวในที่สุดหากการใช้งานต่ำเพียงพอ หรือมีเครื่องมือ/การสนับสนุนสำหรับนักพัฒนาซอฟต์แวร์เพียงพอสำหรับวิธีมาตรฐานในการจับคู่คำขอออก/การแลกสิทธิ์กับข้อมูลอื่นๆ เรากำลังพูดคุยเกี่ยวกับปัญหาดังกล่าวที่นี่ |
| การลงทะเบียน | การทำให้ผู้ออกบัตรลงทะเบียนกับผู้ให้บริการเบราว์เซอร์ใช้งานได้จริงหรือไม่ | เราได้ปรับปรุงข้อกำหนดเพื่ออธิบายเกี่ยวกับขั้นตอนการลงทะเบียนผู้ออกบัตรสำหรับโทเค็นสถานะส่วนตัว แม้ว่าจะมีกระบวนการทำงานของตนเอง แต่ก็คล้ายกับแผนการลงทะเบียนสำหรับการใช้งานอื่นๆ ที่เหลือของ Privacy Sandbox โดยเราจะขอให้ผู้ออกบัตรออกแถลงการณ์สาธารณะว่าจะใช้ PST อย่างไรและรับทราบข้อจำกัดทางเทคนิคที่ช่วยปกป้องความเป็นส่วนตัวของผู้ใช้ |