รายงานรายไตรมาสสําหรับไตรมาสที่ 3 ของปี 2022 ซึ่งสรุปความคิดเห็นของระบบนิเวศที่ได้รับเกี่ยวกับข้อเสนอ 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 นั้นพัฒนาขึ้นจากคำถามที่พบบ่อยที่มีการเผยแพร่ คำตอบที่เกิดขึ้นจริงต่อปัญหาที่ผู้มีส่วนเกี่ยวข้องเป็นผู้หยิบยกขึ้นมา และการกำหนดจุดยืนโดยเฉพาะเพื่อวัตถุประสงค์ในการจัดทำรายงานต่อสาธารณะนี้ ปัจจุบันเราได้รับคำถามและความคิดเห็นเกี่ยวกับ Topics, Fledge และ 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 |
| (มีการรายงานในไตรมาส 2 ด้วย)
ความมีประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ |
ข้อกังวลว่าเทคโนโลยี Privacy Sandbox ชื่นชอบนักพัฒนาซอฟต์แวร์รายใหญ่ และเว็บไซต์เฉพาะกลุ่ม (ขนาดเล็ก) นั้นมีส่วนมากกว่าเว็บไซต์ทั่วไป (ขนาดใหญ่) | ข้อมูลอัปเดตในไตรมาสที่ 3:
Google ให้คำมั่นสัญญากับ CMA เพื่อออกแบบและนำข้อเสนอ Privacy Sandbox ไปใช้ในลักษณะที่จะไม่ทำให้การแข่งขันบิดเบือนจากการแข่งขันโดยมุ่งเน้นที่ธุรกิจของ Google ด้วยตนเอง และคำนึงถึงผลกระทบที่มีต่อการแข่งขันในการโฆษณาดิจิทัล รวมถึงผลกระทบต่อผู้เผยแพร่โฆษณาและผู้ลงโฆษณา โดยไม่คำนึงถึงขนาด เราทำงานอย่างใกล้ชิดกับ CMA อย่างต่อเนื่องเพื่อให้มั่นใจว่างานของเราสอดคล้องกับความมุ่งมั่นเหล่านี้ ขณะที่การทดสอบ Privacy Sandbox คืบหน้าไป หนึ่งในคำถามสำคัญที่เราจะประเมินคือประสิทธิภาพของเทคโนโลยีใหม่สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ ความคิดเห็นสำคัญในเรื่องนี้ โดยเฉพาะความคิดเห็นที่เฉพาะเจาะจงและนำไปใช้ได้จริงซึ่งช่วยให้เราปรับปรุงการออกแบบทางเทคนิคเพิ่มเติมได้ เราได้ทำงานร่วมกับ CMA เพื่อพัฒนาแนวทางการทดสอบเชิงปริมาณ และสนับสนุน CMA ที่ได้เผยแพร่หมายเหตุเกี่ยวกับการออกแบบการทดสอบเพื่อให้ข้อมูลเพิ่มเติมแก่ผู้เข้าร่วมตลาดและโอกาสที่จะได้แสดงความคิดเห็นเกี่ยวกับแนวทางที่เราเสนอ |
| (มีการรายงานในไตรมาส 2 ด้วย)
คำขอเอกสาร |
คำขอแหล่งข้อมูลเพิ่มเติมที่แสดงรายละเอียดวิธีจัดการการทดสอบ การวิเคราะห์ และการติดตั้งใช้งาน | ข้อมูลอัปเดตในไตรมาสที่ 3:
เรายินดีที่นักพัฒนาแอปพบว่าเนื้อหาปัจจุบันของเรามีประโยชน์ และมุ่งมั่นที่จะมอบเนื้อหาเพิ่มเติมในช่วงไม่กี่สัปดาห์และไม่กี่เดือนข้างหน้าเพื่อให้นักพัฒนาแอปได้ทำความเข้าใจต่อไปว่าเทคโนโลยีใหม่นี้จะมีประโยชน์ต่อตนอย่างไร นอกจากนี้ เรายังได้จัดเซสชันในเวลาทำการสำหรับนักพัฒนาซอฟต์แวร์แบบสาธารณะเพื่อแชร์แนวทางปฏิบัติที่ดีที่สุดและการสาธิต รวมถึงเซสชันถามและตอบกับหัวหน้าผลิตภัณฑ์และฝ่ายวิศวกรรมเพื่อเปิดโอกาสให้มีการพูดคุย/แลกเปลี่ยนความคิดเห็นแบบสดๆ |
| การสนับสนุนในเบราว์เซอร์ต่างๆ | ผู้ให้บริการเบราว์เซอร์รายอื่นๆ ที่ใช้ Privacy Sandbox API | ผู้ให้บริการเบราว์เซอร์อื่นๆ เช่น Apple, Mozilla และ Microsoft มีส่วนร่วมอย่างแข็งขันในฟอรัมสาธารณะที่มีการพูดคุยกันเรื่องหลักการความเป็นส่วนตัวและวิธีการบนเบราว์เซอร์ เราได้รับกำลังใจจากการสนทนาร่วมกันในฟอรัมต่างๆ เช่น การประชุม TPAC ประจำปีของ W3C เมื่อเร็วๆ นี้ และฟอรัม W3C PATCG ที่กำลังดำเนินอยู่ ซึ่งเห็นสัญญาณของการบรรจบกัน |
| ความแตกต่างของแพลตฟอร์ม | ขอให้ปรับชุดฟีเจอร์ในเว็บและ Android ให้สอดคล้องกันมากที่สุดเพื่อช่วยลดทรัพยากรที่จำเป็นสำหรับการเปลี่ยนผ่านนี้ | เราพยายามปรับแนวทางของเราให้สอดคล้องกันทั้งใน Chrome และ Android เพื่อหลีกเลี่ยงการสร้างความสับสน/การกระจายข้อมูลทั่วทั้งอุตสาหกรรม ความแตกต่างในแนวทางของเราส่วนใหญ่มักเกิดจากความแตกต่างทางเทคนิคที่จําเป็นระหว่างแพลตฟอร์มเว็บและแอปบนอุปกรณ์เคลื่อนที่ ซึ่งนักพัฒนาซอฟต์แวร์จะนํามาพิจารณาอยู่แล้ว |
| ทรัพยากรสำหรับการทดสอบ Privacy Sandbox API | ปัญหาที่จัดสรรให้เพียงพอ
สำหรับทดสอบ Privacy Sandbox API ตามอุปสรรคทางเศรษฐกิจในปัจจุบัน |
Google ปรับปรุงเอกสารประกอบและการสนับสนุนที่พร้อมให้บริการแก่ผู้ทดสอบอย่างต่อเนื่องเพื่อลดความซับซ้อนและช่วยในการปรับใช้ API เช่น รายชื่ออีเมลสำหรับ API โดยเฉพาะ เวลาทำการ และการอัปเดตที่ดำเนินอยู่ใน developers.chrome.com |
| สัญญาณการเลือกไม่ใช้ Sandbox API | ขอให้ระบุสัญญาณ "ผู้ใช้เลือกไม่ใช้แซนด์บ็อกซ์ API" ซึ่งเทคโนโลยีโฆษณาและเว็บไซต์จะใช้ได้ | เราได้เห็นหลายกรณีในอดีตที่เว็บไซต์ต่างๆ จะตอบสนองต่อตัวเลือกของผู้ใช้ เช่น "ปิดคุกกี้ของบุคคลที่สาม" โดยการกดดันให้ผู้ใช้เปลี่ยนการตั้งค่า บางครั้งรวมถึงการบล็อกการเข้าถึงเว็บไซต์หากผู้ใช้ทำเช่นนั้น สัญญาณการเลือกไม่ใช้อาจเป็นสัญญาณเพิ่มเติมสำหรับการเก็บลายนิ้วมือด้วยเช่นกัน ขณะนี้ Google ยังไม่มีเจตนาให้สัญญาณการเลือกไม่ใช้ |
| (มีการรายงานในไตรมาส 2 ด้วย)
ไทม์ไลน์ที่ชัดเจนขึ้น |
กำหนดการเผยแพร่ที่ชัดเจนและละเอียดยิ่งขึ้น | ข้อมูลอัปเดตในไตรมาสที่ 3:
ดังที่ได้อธิบายไว้ในส่วน "การเปลี่ยนแปลงเพื่อตอบสนองต่อความคิดเห็น" ด้านล่าง Google ได้อัปเดตไทม์ไลน์ Privacy Sandbox ในเดือนกรกฎาคมเพื่อให้เวลาตลาดในการทดสอบเบื้องต้นและความคิดเห็นต่างๆ รวมถึงมีเวลามากขึ้นในการทดสอบเมื่อมีการเปิดตัว Privacy Sandbox API อย่างสมบูรณ์ก่อนที่จะเลิกใช้งานคุกกี้ของบุคคลที่สาม |
| (มีการรายงานในไตรมาส 2 ด้วย)
ลำดับเวลาการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
คำขอเพื่อหลีกเลี่ยงความล่าช้าในการเลิกใช้งานคุกกี้ของบุคคลที่สาม | ข้อมูลอัปเดตในไตรมาสที่ 3:
เมื่อเดือนกรกฎาคม Chrome ได้ประกาศลำดับเวลาฉบับปรับปรุงสำหรับการเลิกใช้งานคุกกี้ของบุคคลที่สาม ซึ่งสะท้อนถึงความมุ่งมั่นของเราในการดำเนินการอย่างมีความรับผิดชอบเนื่องจากเทคโนโลยีดังกล่าวมีความซับซ้อนและสำคัญต่อระบบนิเวศ ก่อนการเปลี่ยนแปลงครั้งนี้ เราได้นำความคิดเห็นจากหน่วยงานกํากับดูแลและอุตสาหกรรมมาใช้จริง และเดินหน้าทํางานร่วมกับผู้มีส่วนเกี่ยวข้องทั้งหมดอย่างใกล้ชิด |
| คุกกี้ของบุคคลที่หนึ่ง | มีการเสนอข้อจำกัดเกี่ยวกับคุกกี้ของบุคคลที่หนึ่งด้วยหรือไม่ หากเป็นเช่นนั้น ความกังวลเกี่ยวกับความเสถียรในระยะยาว ความเสี่ยงจากการเปลี่ยนแปลงของเบราว์เซอร์ที่คาดเดาไม่ได้มากขึ้น และสิ้นเปลืองงานด้านวิศวกรรมในตอนนี้ | เราไม่พิจารณาข้อจำกัดใดๆ เกี่ยวกับคุกกี้ของบุคคลที่หนึ่ง จุดมุ่งเน้นของ Privacy Sandbox อยู่ที่การเลิกใช้งานคุกกี้ของบุคคลที่สาม |
แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง
หัวข้อ
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| (มีการรายงานในไตรมาส 2 ด้วย)
ความมีประโยชน์สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ |
มีผู้หยิบยกข้อกังวลเกี่ยวกับความมีประโยชน์สำหรับเว็บไซต์ขึ้นมา โดยจะขึ้นอยู่กับระดับการเข้าชมหรือความชำนาญเฉพาะทางของเนื้อหา | ข้อมูลอัปเดตในไตรมาสที่ 3:
เราจะสำรวจประโยชน์ของ API ผ่านการทดสอบ Google จะแชร์ผลการทดสอบดังกล่าวกับ CMA ตามที่กำหนดไว้ในวรรคที่ 17.c.ii ของสัญญาผูกมัด Chrome คาดหวังว่าการจัดหมวดหมู่และพารามิเตอร์อื่นๆ จะเปลี่ยนแปลงไปตามผลการทดสอบ วิวัฒนาการของการจัดหมวดหมู่หรือพารามิเตอร์อาจไม่จำเป็นต้องมีการเปลี่ยนแปลงที่เข้ากันไม่ได้แบบย้อนหลัง นอกจากนี้ Chrome คาดว่าผลตอบรับจะยังคงมีผลต่อวิวัฒนาการของ Topics API ต่อไปหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม |
| ความเป็นส่วนตัว/นโยบาย | คำขอให้นำข้อกำหนดการกรองหัวข้อต่อผู้โทรออก | จากความคิดเห็นจาก KOF ด้านความเป็นส่วนตัว ผู้สนับสนุนความเป็นส่วนตัว ผู้เชี่ยวชาญด้านความปลอดภัย กลุ่มสิทธิ์ดิจิทัล และบุคคลอื่นๆ ในระบบนิเวศ Chrome จึงเลือกใช้การออกแบบนี้เพื่อให้การเข้าถึงข้อมูลแก่บุคคลที่มีสิทธิ์เข้าถึงดังกล่าวเท่านั้น ซึ่งรวมถึงแต่ไม่จำกัดเพียงการจำกัดการรั่วไหลของข้อมูลแบบข้ามฝั่งที่เพิ่มขึ้น การรับประกันความโปร่งใสและคำอธิบาย การใช้วิธีการที่ง่ายในการปรับใช้และอธิบาย และจำกัดความเสี่ยงในการเก็บลายนิ้วมือ ผู้เผยแพร่โฆษณาและบุคคลที่สามที่ได้รับ Topics สามารถตัดสินใจได้ด้วยตนเองว่าจะแชร์ข้อมูลใดให้กับบุคคลที่สามในเว็บไซต์ของตน หากบุคคลที่สามแชร์ข้อมูลนี้ Chrome ขอแนะนำว่าควรแจ้งให้ผู้ใช้ทราบเกี่ยวกับการแชร์ดังกล่าวอย่างโปร่งใสและเสนอการควบคุมแก่บุคคลที่สาม |
| เว็บไซต์อยู่ผิดหมวดหมู่ | เว็บไซต์ถูกจัดหมวดหมู่ผิดเป็นหัวข้อที่ไม่ถูกต้อง ซึ่งอาจส่งผลให้การกำหนดเป้าหมายโฆษณาไม่ถูกต้อง | ระบบจะจัดประเภทเว็บไซต์โดยใช้รายการการลบล้างที่ดูแลจัดการโดยมนุษย์ ซึ่งประกอบด้วยเว็บไซต์ยอดนิยมและโมเดล ML ในอุปกรณ์ Chrome จะยังคงประเมินตัวเลือกของเว็บไซต์ต่างๆ เพื่อนำมาใช้ในการจัดประเภทหัวข้อ การปรับปรุงยูทิลิตีใดๆ จะต้องคำนึงถึงความเสี่ยงด้านความเป็นส่วนตัวและการละเมิด ตัวอย่างเช่น ความเสี่ยงบางส่วนมีดังนี้:
บุคคลทั่วไปสามารถตรวจสอบคอมโพเนนต์เหล่านี้ได้โดยใช้เครื่องมือที่มีให้ผ่าน chrome://topics-internals หรือ colab นี้ จากการทดสอบ เราคาดหวังว่าการจัดหมวดหมู่จะได้รับการปรับปรุงเมื่อเวลาผ่านไป และเรายินดีรับฟังความคิดเห็นเกี่ยวกับตัวอย่างเว็บไซต์ที่อาจจัดอยู่ในหมวดหมู่ที่ไม่ถูกต้อง |
| ข้อกำหนดในการเข้าถึง | ข้อกำหนด Topics ปัจจุบันสำหรับเอนทิตี DOM ในหน้าเป็นสคริปต์หรือ iframe เพื่อให้เข้าถึงได้ อาจทำให้เกิดพฤติกรรมไม่พึงประสงค์ของผู้เล่นในระบบนิเวศโฆษณา | เราได้รวมการเปลี่ยนแปลงในข้อความอธิบาย GitHub แล้ว เราตั้งใจจะสนับสนุน Topics ในส่วนหัว HTTP |
| การจัดหมวดหมู่หัวข้อมีรายละเอียดไม่เพียงพอ | การแยกประเภทหัวข้อปัจจุบันกว้างเกินไปและไม่รวมหัวข้อที่ละเอียดยิ่งขึ้น เช่น หัวข้อระดับภูมิภาค | การปรับปรุงการจัดหมวดหมู่เป็นความพยายามอย่างต่อเนื่อง และเราคาดว่าการจัดหมวดหมู่จะพัฒนาไปพร้อมกับการทดสอบและข้อมูลในระบบนิเวศ
เรารับฟังความคิดเห็นเกี่ยวกับการจัดหมวดหมู่ที่จะเป็นประโยชน์กับระบบนิเวศมากที่สุด ในการประเมินว่าจะขยายหัวข้อหรือรวมหัวข้อที่ละเอียดยิ่งขึ้นหรือไม่นั้น เราลองพิจารณา 2-3 ข้อ ได้แก่ 1) ผลกระทบด้านความเป็นส่วนตัวที่อาจเกิดขึ้น (เช่น หัวข้อจำนวนมากขึ้นอาจทําให้เกิดความเสี่ยงในการเก็บลายนิ้วมือ) และ 2) ความสามารถในการเรียกดูหัวข้อที่สังเกตมาก่อนก่อนหน้านี้ (เช่น เมื่อมีหัวข้อมากขึ้น โอกาสที่เทคโนโลยีโฆษณาที่เคยจะเห็นหัวข้อที่เลือกในอดีต) จากฉบับที่ 2 Google มุ่งเพิ่มความสามารถของผู้โทรในการเรียกหัวข้อที่สังเกตก่อนหน้านี้ให้สูงสุด ภายใต้ข้อกำหนดด้านการกรองที่มีอยู่ โดยมีเป้าหมายเพื่อให้สามารถใช้งานได้ทั้งประโยชน์และความเป็นส่วนตัว |
| จำนวนหัวข้อสูงสุด | เว็บไซต์ 3 หัวข้อเป็นข้อมูลน้อยเกินไปที่ผู้ลงโฆษณาจะแสดงโฆษณาได้ | ความคิดเห็นจากระบบนิเวศ โดยเฉพาะผลการทดสอบจากช่วงทดลองใช้จากต้นทาง จะส่งผลต่อวิวัฒนาการของ API ต่อไป โปรดทราบว่า Topics ควรเสริมสัญญาณอื่นๆ เช่น บริบท เพื่อช่วยค้นหาโฆษณาที่เหมาะสมสำหรับผู้เข้าชม ดังนั้นผู้ลงโฆษณาจึงมีข้อมูลเพิ่มเติมนอกเหนือจากหัวข้อ |
| (มีการรายงานในไตรมาส 2 ด้วย)
การควบคุมและความปลอดภัยของผู้ใช้ |
บางหัวข้ออาจส่งผลดีต่อกลุ่มที่ไวต่อมลพิษทางอากาศและผู้ใช้ต้องการการควบคุมเพิ่มเติมเพื่อป้องกันผลลัพธ์เชิงลบ | ข้อมูลอัปเดตในไตรมาสที่ 3:
หัวข้อแสดงถึงความก้าวหน้าที่สำคัญสำหรับการควบคุมของผู้ใช้และความโปร่งใส ผู้ใช้สามารถเลือกไม่ใช้หัวข้อ ตรวจสอบหัวข้อที่ได้รับมอบหมาย นำหัวข้อออก และทำความเข้าใจว่าบริษัทใดที่โต้ตอบกับหัวข้อของตนในหน้าเว็บหนึ่งๆ นอกจากนี้ ผู้ใช้ยังสามารถล้าง Topics ของตนเองโดยการลบประวัติการท่องเว็บของตนซึ่งเป็นหัวข้อที่ดึงมา ปัจจุบันการควบคุมเหล่านี้ใช้งานในเบราว์เซอร์ Chrome ที่ระดับอุปกรณ์ เรายินดีพูดคุยกับคุณอย่างต่อเนื่องเกี่ยวกับการควบคุมของผู้ใช้ขั้นสูง เช่น การควบคุมที่นักพัฒนาแอปแนะนำ อย่างไรก็ตาม เราจำเป็นต้องตรวจสอบว่าการเพิ่มแอปใหม่ๆ ได้รับการปรับเทียบให้เหมาะสมเพื่อรับมือกับข้อกังวลที่เกิดขึ้นและไม่ส่งผลให้เกิดการเปลี่ยนแปลงเป็นส่วนๆ ไป |
| ผลกระทบต่อ SEO | ผู้เผยแพร่โฆษณาการปรับชื่อโฮสต์ของเว็บไซต์เพื่อให้สะท้อน Topics ได้ดีขึ้นอาจส่งผลเสียต่อ SEO | เราจะระวังไม่ให้เว็บไซต์เปลี่ยนชื่อโฮสต์เพียงเพื่อ Topics เท่านั้น จริงอยู่ที่เว็บไซต์อาจสามารถโน้มน้าวหัวข้อที่ได้รับมอบหมายด้วยวิธีนี้ แต่ประโยชน์ที่ผู้เผยแพร่โฆษณาใช้ในการดำเนินการดังกล่าวยังไม่ชัดเจนและบ่อนทำลายคุณค่าของ Topics สำหรับระบบนิเวศทั้งระบบหากเว็บไซต์พยายาม "โกง" รูปแบบการจัดหมวดหมู่ การกำหนดหัวข้อก็ยังไม่ได้รับการแก้ไข เราคาดว่าการจัดหมวดหมู่จะพัฒนาต่อไปโดยอาศัยการทดสอบและการป้อนข้อมูล ในการทดสอบนี้ เราสนับสนุนให้คุณแสดงความคิดเห็น รวมถึงตัวอย่างเว็บไซต์ที่อาจจัดอยู่ในหมวดหมู่ที่ไม่ถูกต้อง |
| การประพฤติมิชอบและการละเมิด | มีวิธีที่ฝ่ายซื้อสามารถยืนยันว่าหัวข้อที่เห็นนั้นสร้างขึ้นโดยเบราว์เซอร์จริงๆ | ขอขอบคุณสำหรับคำแนะนำเพื่อสนับสนุนกลไกสำหรับผู้ซื้อเทคโนโลยีโฆษณาเพื่อใช้ยืนยันหัวข้อที่ผู้ขายส่งในการประมูลเพื่อแสดงโฆษณาแบบเป็นโปรแกรม เราสนับสนุนให้ระบบนิเวศเข้ามามีส่วนร่วมในการสนทนาอย่างจริงจังที่นี่ แม้ว่าในขณะนี้เราจะมุ่งเน้นไปที่การปรับปรุงอื่นๆ ที่มีลำดับความสำคัญสูงกว่า แต่เราตระหนักว่านี่อาจเป็นส่วนเพิ่มเติมที่สำคัญสำหรับการออกแบบนี้ในอนาคต |
| การประพฤติมิชอบและการละเมิด | อนุญาตให้มีการตรวจสอบแบบสาธารณะเกี่ยวกับบุคคลที่เป็นผู้ใช้ที่ถูกต้องของข้อมูล Topics ผ่านการโพสต์และการตรวจสอบแบบสาธารณะประเภทเดียวกับที่ชุดข้อมูลของบุคคลที่หนึ่งจะต้องอยู่ภายใต้การควบคุม | เราขอขอบคุณสำหรับคำแนะนำและยอมรับว่าความรับผิดชอบสาธารณะเป็นเครื่องมือสำคัญที่จะช่วยให้บรรลุเป้าหมายของ Privacy Sandbox การเรียก Topics API นั้นเป็นแบบสาธารณะอยู่แล้ว เนื่องจากทุกคนจะเข้าชมเว็บไซต์และดูการเรียก JavaScript API ของโดเมนได้ ดังนั้น บุคคลและองค์กรจึงดูกิจกรรมที่เกี่ยวข้องและประเมินได้ว่าเว็บไซต์ใดใช้ Topics และอย่างไร เราเชื่อว่าวิธีนี้เป็นวิธีที่ดีกว่าการประเมินในส่วน "ความถูกต้อง" ของเว็บไซต์ในส่วนของฟังก์ชันการทำงานของ Topics API เอง |
| ผลกระทบต่อสัญญาณของบุคคลที่หนึ่ง | สัญญาณ Topics อาจมีค่าสูง จึงส่งผลให้สัญญาณที่อิงตามความสนใจของบุคคลที่หนึ่งอื่นๆ มีคุณค่าลดลง | เราเชื่อว่าการโฆษณาตามความสนใจเป็นกรณีการใช้งานที่สำคัญสำหรับเว็บ และ Topics ได้รับการออกแบบมาเพื่อรองรับ Use Case นั้น ดังที่ได้อธิบายไว้ข้างต้น ผู้มีส่วนเกี่ยวข้องในระบบนิเวศรายอื่นๆ ได้แสดงความกังวลว่า Topics อาจไม่มีประโยชน์มากพอที่จะให้คุณค่า ในทุกกรณี การปรับปรุงการจัดหมวดหมู่ยังคงอาศัยความพยายามอย่างต่อเนื่อง และเราคาดหวังว่าการจัดหมวดหมู่จะได้รับการพัฒนาไปพร้อมกับการทดสอบและการป้อนข้อมูลในระบบนิเวศ |
FLEDGE
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| การประมูล FLEDGE | วิธีที่ SSP จะส่งข้อมูลไปยัง Google Ads เพื่อเสนอราคาในการประมูล FLEDGE | เราขอแนะนำให้บริษัทที่เข้าร่วมการทดสอบเผยแพร่เอกสารประกอบเกี่ยวกับแผนการทดสอบของตนแล้วทำงานร่วมกันตามความเหมาะสม
เราได้ทำงานร่วมกับ CMA เพื่อพัฒนาแนวทางการทดสอบเชิงปริมาณ และสนับสนุน CMA ที่ได้เผยแพร่หมายเหตุเกี่ยวกับการออกแบบการทดสอบเพื่อให้ข้อมูลเพิ่มเติมสำหรับผู้เข้าร่วมตลาดที่มีแผนจะมีส่วนร่วมในการทดลอง และโอกาสที่จะได้แสดงความคิดเห็นเกี่ยวกับแนวทางที่นำเสนอ ทีม Ad Manager ได้โพสต์เอกสารสำหรับผู้ขายที่สนใจการทดสอบ FLEDGE กับผู้เผยแพร่โฆษณาที่ใช้ Ad Manager เป็นเซิร์ฟเวอร์โฆษณาที่นี่ มีรายละเอียดทางเทคนิคเพิ่มเติมตามที่ระบุไว้ที่นี่ |
| FLEDGE ใน Fenced Frame ที่ซ้อนกัน | เฟรมที่มีการปิดกั้นช่วยให้ทดสอบที่เข้มงวดน้อยกว่า และมีการจำกัดมากขึ้นในอนาคต ไทม์ไลน์ที่ไม่ทราบนี้ก่อให้เกิดความท้าทายต่อระบบนิเวศข่าว | บริษัทสามารถทดสอบ FLEDGE กับ Fenced Frames ได้แล้ววันนี้ บริษัทต่างๆ สามารถเลือกติดตั้งใช้งาน FLEDGE ก่อนเพื่อให้ตัวเลือกการเริ่มต้นใช้งานง่ายขึ้น หลังจากใช้ FLEDGE แล้ว ผู้ใช้จะสามารถทดสอบ Fenced Frames กับการออกแบบ FLEDGE ได้ |
| นโยบายการจัดการข้อมูล | นโยบายการจัดการข้อมูลสำหรับกลุ่มความสนใจ / FLEDGE คืออะไร | ในการออกแบบ FLEDGE ข้อมูลทั้งหมดที่จัดเก็บไว้ในกลุ่มความสนใจ หรือเกี่ยวกับสิ่งที่ผู้คนอยู่ในกลุ่มความสนใจ จะยังคงอยู่ในอุปกรณ์ โดยจะไม่มีการส่งข้อมูลนี้ไปยังเซิร์ฟเวอร์ของ Google
การคุ้มครองความเป็นส่วนตัวบางอย่างที่ Chrome วางแผนไว้สำหรับ FLEDGE เกี่ยวข้องกับการโต้ตอบกับเซิร์ฟเวอร์ k-anonymity ที่ดำเนินการโดย Google เราออกแบบการโต้ตอบดังกล่าวมาอย่างรอบคอบเพื่อหลีกเลี่ยงการแชร์ข้อมูลเกี่ยวกับผู้ใช้ และให้ทำงานในสภาพแวดล้อมการดำเนินการที่เชื่อถือได้ (TEE) เพื่อรักษาความเท่าเทียมกันของข้อมูลทั่วทั้งระบบนิเวศโฆษณา \ Google มุ่งมั่นที่จะให้ CMA ออกแบบและนำข้อเสนอ Privacy Sandbox ไปใช้ในลักษณะที่จะไม่ทำให้การแข่งขันบิดเบือนไป โดยให้เห็นถึงธุรกิจของ Google เอง รวมถึงคำนึงถึงผลกระทบที่มีต่อการแข่งขันในการโฆษณาดิจิทัล รวมถึงต่อผู้เผยแพร่โฆษณาและผู้ลงโฆษณาด้วย เราทำงานอย่างใกล้ชิดกับ CMA อย่างต่อเนื่องเพื่อให้มั่นใจว่างานของเราสอดคล้องกับความมุ่งมั่นเหล่านี้ |
| นโยบายอายุ | Chrome จะแน่ใจได้อย่างไรว่ากลุ่มเป้าหมายที่สร้างโดย FLEDGE เป็นไปตามการจํากัดอายุ | ผู้เผยแพร่โฆษณาและผู้ลงโฆษณาควรประเมินได้ว่ากลุ่มเป้าหมายที่สร้างโดยใช้ FLEDGE เป็นไปตามกฎหมายที่เกี่ยวข้องหรือไม่ เพื่อปกป้องผู้ใช้มากขึ้น Privacy Sandbox API จะไม่ทํางานสําหรับผู้ใช้ที่ลงชื่อเข้าใช้ Chrome หากอายุที่เชื่อมโยงกับบัญชีมีอายุต่ำกว่า 18 ปี แม้ในช่วงระยะเวลาทดสอบ (สำหรับผู้ใช้ที่ออกจากระบบ Chrome จะไม่รวบรวมสัญญาณของโปรไฟล์ซึ่งจะทำให้เบราว์เซอร์อนุมานอายุของผู้ใช้ได้) |
| บริการจัดการคีย์/ค่าของ FLEDGE | เพิ่มความชัดเจนเกี่ยวกับสิ่งที่บริการคีย์/ค่า FLEDGE จะอนุญาต เช่น จํานวนคีย์และความถี่ที่อัปเดต | บริษัทที่ใช้ FLEDGE จะมีคีย์ได้มากเท่าที่จะใส่ได้ใน RAM โปรดดูคำอธิบายเพิ่มเติมที่นี่
เรากำลังมองหาช่องทางที่รวดเร็วขึ้นในการแก้ไขข้อมูลและคำแนะนำต้อนรับสำหรับข้อกำหนดต่างๆ |
| การทดสอบ | ทดสอบ FLEDGE กับ Google Ads ได้ยาก | โปรดดูเอกสารการเริ่มต้นใช้งานของ Google Ads เพื่อดูวิธีที่ดีที่สุดในช่วงทดลองใช้จากต้นทาง |
| API บริการเสนอราคาและการประมูล | Google มีแนวทางอย่างไรเกี่ยวกับการเสนอราคาและ API บริการประมูล เบราว์เซอร์ Chrome จะมีลำดับความสำคัญสูงกว่าหรือต่ำกว่า FLEDGE ของเบราว์เซอร์ Chrome ในการประมูลอุปกรณ์ | เรายังคงมุ่งมั่นที่จะออกแบบการเสนอราคา FLEDGE ในอุปกรณ์ในปัจจุบัน เราได้เสนอบริการการเสนอราคาและบริการประมูลเพื่อหาวิธีแก้ปัญหาที่เป็นไปได้เพื่อรองรับกรณีการใช้งานบางส่วนที่อุปกรณ์อาจมีประสิทธิภาพในการประมวลผลหรือความเร็วเครือข่ายที่จำกัด |
| การรายงานรวม | ขอการสนับสนุนรายงานสรุปที่อิงตามสัญญาณทั้งหมดที่มีอยู่ใน generateBid | เราวางแผนที่จะแชร์ข้อมูลเพิ่มเติมต่อสาธารณะเกี่ยวกับเรื่องนี้ในเร็วๆ นี้ |
| โฆษณาตามบริบท | การแสดงโฆษณาตามบริบทด้วย FLEDGE | เราพิจารณาตัวเลือกนี้แล้วและเหตุผลที่อธิบายไว้ในการอภิปรายนี้ เราจึงไม่แนะนำให้ใช้ FLEDGE สำหรับโฆษณาตามบริบท |
| การทดสอบในชีวิตจริง | คําแนะนําเกี่ยวกับวิธีแยก FLEDGE จากคุกกี้ของบุคคลที่สามสําหรับการทดสอบในชีวิตจริง | เรากำลังตรวจสอบวิธีต่างๆ ในการมอบกลุ่มประชากรในการทดสอบ
เราได้ทำงานร่วมกับ CMA เพื่อพัฒนาแนวทางการทดสอบเชิงปริมาณ และสนับสนุน CMA ที่ได้เผยแพร่หมายเหตุเกี่ยวกับการออกแบบการทดสอบเพื่อให้ข้อมูลเพิ่มเติมสำหรับผู้เข้าร่วมตลาดและโอกาสที่จะได้แสดงความคิดเห็นเกี่ยวกับแนวทางที่เราเสนอ |
| การทดสอบ FLEDGE และ Attribution Reporting API | ข้อใดคือวิธีที่ดีที่สุดในการใช้ Attribution Reporting API กับ FLEDGE เป็นความคิดที่ดีที่จะแยก FLEDGE กับ Attribution หรือทดสอบด้วยกัน | ท้ายที่สุดแล้วเราจะรองรับการทดสอบทั้ง FLEDGE และ Attribution Reporting API เป็นโซลูชันที่ผสานรวม แต่เราแนะนําให้นักพัฒนาแอปทดสอบ Attribution Reporting API ก่อนเป็นอันดับแรก จากนั้นจึงทดสอบกับ FLEDGE เมื่อการผสานรวมเสร็จสมบูรณ์ |
| การแสดงราคาเสนอ | คำขอเพื่อสร้างความสับสนให้กับราคาเสนอ | คุณจะกำหนดเบรกพอยท์ภายใน "generateBid()" หรือ "scoreAd()" เพื่อเข้าถึงมูลค่าราคาเสนอจากเครื่องมือสำหรับนักพัฒนาเว็บได้ ทีม Chrome ได้พิจารณาเวกเตอร์การโจมตีแบบแคบที่ปรากฏในความคิดเห็นเกี่ยวกับ FLEDGE นี้ อย่างไรก็ตาม โมเดลการรักษาความปลอดภัยและความเป็นส่วนตัวของ Chrome จะถือว่าผู้ใช้ไว้วางใจให้ทำในสิ่งที่ตนต้องการด้วยข้อมูลบนอุปกรณ์ของตนเอง ดังนั้นจึงไม่มีวิธีใดที่จะสามารถซ่อนข้อมูลราคาเสนอตามคำขอได้ |
| คำขอเอกสาร | เอกสารประกอบและตัวอย่างสำหรับการทดสอบในระบบนิเวศสด | เรายินดีที่นักพัฒนาแอปพบว่าเนื้อหาปัจจุบันของเรามีประโยชน์ และมุ่งมั่นที่จะมอบเนื้อหาเพิ่มเติมในช่วงไม่กี่สัปดาห์และไม่กี่เดือนข้างหน้าเพื่อให้นักพัฒนาแอปได้ทำความเข้าใจต่อไปว่าเทคโนโลยีใหม่นี้จะมีประโยชน์ต่อตนอย่างไร
นอกจากนี้ เรายังได้จัดชั่วโมงการทำงานสำหรับนักพัฒนาซอฟต์แวร์ภายนอกต่อสาธารณะเพื่อแชร์แนวทางปฏิบัติที่ดีที่สุดและการสาธิต รวมถึงเซสชันถามและตอบกับหัวหน้าผลิตภัณฑ์และฝ่ายวิศวกรรม โดยเปิดโอกาสให้พูดคุย/แลกเปลี่ยนความคิดเห็นแบบสดๆ |
| API การรวมส่วนตัว | หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับ Private Aggregation API | มีคำอธิบายสาธารณะพร้อมข้อมูลล่าสุดที่เราสามารถแชร์ได้ในขณะนี้ เราจะจัดเตรียมเอกสารเพิ่มเติมเมื่อเราพัฒนา API นี้และมีการกำหนด Use Case แล้ว |
| เวลาในการตอบสนองของข้อมูล | การดึงข้อมูลเซิร์ฟเวอร์คีย์/ค่า FLEDGE จะเป็นแบบเรียลไทม์ไหม | อาจไม่มีการอัปเดตเล็กน้อยในลำดับนาที อาจมีไม่กี่ชั่วโมงก่อนที่เซิร์ฟเวอร์จะส่งคืนข้อมูลที่อัปเดตสำหรับการค้นหา ตามที่อธิบายไว้ในปัญหา GitHub ที่ยังไม่ได้รับการแก้ไข นอกจากนี้ เรายังต้องการความคิดเห็นของนักพัฒนาซอฟต์แวร์ด้วย |
| การเสนอราคาและบริการประมูล | ราคาเสนอจะถูกซ่อนจากผู้ใช้หรือไม่ หากมีการใช้บริการเสนอราคาและการประมูล (B&A) | สำหรับแนวทางฝั่งเซิร์ฟเวอร์ B&A ราคาเสนอแบบเฉพาะเจาะจงจะไม่แสดงให้ผู้ใช้เห็น เนื่องจากคำขอราคาเสนอมาจากบริการการประมูล SSP โดยตรงไปยังบริการการประมูล DSP ทำให้ใช้ในเบราว์เซอร์ไม่ได้อีกต่อไป
อย่างไรก็ตาม เบราว์เซอร์จะยังเห็นราคาเสนอที่ชนะ (ซึ่งจะอธิบายรายละเอียดเพิ่มเติมข้างต้นเกี่ยวกับคำขอเพื่อสร้างความสับสนให้กับราคาเสนอ) |
| การเสนอราคาและบริการประมูล | เราจะโหลดการเสนอราคาและบริการประมูลสมดุลได้อย่างไร | ขณะนี้เรายังไม่มีคำแนะนำเกี่ยวกับการจัดสรรภาระงาน แต่เป็นข้อกังวลสำคัญในแง่ของทั้งประสิทธิภาพและความเป็นส่วนตัว เราจะให้รายละเอียดเพิ่มเติมในอนาคต |
| ขีดจำกัดของ FLEDGE | ขอเพิ่มระยะเวลาสูงสุดของ JoinAdInterestGroup จาก 30 วันเป็น 90 วัน | เรารู้สึกว่ากรอบเวลาการเก็บรักษาข้อมูล 30 วันสอดคล้องกับ API การโฆษณา Privacy Sandbox อื่นๆ เช่น ขีดจํากัด 30 วันใน Attribution Reporting และการมองย้อนกลับ 3 สัปดาห์ใน Topics กรอบเวลานี้ตอบสนองทั้งความต้องการเทคโนโลยีโฆษณาและความคาดหวังด้านความเป็นส่วนตัวของผู้ใช้
อย่างไรก็ตาม เรายินดีรับฟังความคิดเห็นเพิ่มเติมในระหว่างที่เรากำลังหารือถึงปัญหาต่อไปที่นี่ |
| พื้นที่เก็บข้อมูลที่ใช้ร่วมกันใน FLEDGE | ฉันสามารถใช้ Shared Storage API ใน FLEDGE ได้ไหม | เราตั้งใจจะรองรับ API พื้นที่เก็บข้อมูลที่ใช้ร่วมกันใน FLEDGE ในอนาคต และกำลังดำเนินการเพื่อให้ฟีเจอร์นี้พร้อมใช้งานในช่วงทดลองใช้จากต้นทางที่กำลังจะเกิดขึ้น |
| การควบคุมความถี่ตามจำนวนคลิก | เป็นไปได้ไหมที่จะมีการกำหนดความถี่สูงสุดตามการคลิก (ไม่ชนะ) ใน FLEDGE | FLEDGE ระบุว่า Fenced Frame สามารถเรียกใช้ navigator.leaveAdInterestGroup() (โดยไม่มีพารามิเตอร์) เพื่อออกจากกลุ่มความสนใจที่ทำให้โฆษณาแสดงขึ้น การเรียกนี้สามารถทำได้ในครั้งแรกที่มีการคลิก เพื่อป้องกันการเสนอราคาในอนาคต โดยเป็นการกำหนดความถี่สูงสุด ในปัจจุบัน โซลูชันนี้ไม่สามารถรองรับการกำหนดความถี่สูงสุดหลังจากมากกว่า 1 คลิก |
| FLEDGE ใน Fenced Frame ที่ซ้อนกัน | รายงานการคลิกผ่านการรายงานโฆษณาเฟรมที่มีการปิดกั้นไม่ได้ หากการคลิกนั้นเกิดขึ้นในเฟรมที่มีการซ้อนกัน | เราได้เผยแพร่ข้อเสนอในการแก้ปัญหาแล้วที่นี่ |
| การวัด | ต้องการคําแนะนําเกี่ยวกับวิธีรวบรวมข้อมูลเวลาในการตอบสนองของผู้เสนอราคาในการประมูล FLEDGE | เรากำลังเผยแพร่เอกสารการวัดประสิทธิภาพในเร็วๆ นี้ |
| การรายงาน | การรายงาน FLEDGE จะได้รับการจัดการอย่างไร | การรายงาน FLEDGE เกี่ยวกับการชนะ ผลการประมูล เหตุการณ์ เช่น การคลิกจะดูได้ผ่าน FLEDGE API เช่น reportResult() ในการรายงานที่มี Conversion โฆษณา การผสานรวมกับ Attribution Reporting API จะเป็นอิสระจาก FLEDGE แต่มีการหารือกับระบบนิเวศเกี่ยวกับแนวทางที่เป็นไปได้อยู่อย่างต่อเนื่อง
นอกจากนี้ยังสามารถใช้ Private Aggregation API เพื่อรายงานผลการประมูลจากภายในสภาพแวดล้อมการดำเนินการที่แยกออกมาได้อีกด้วย ดูคำอธิบายที่นี่ |
| ขนาดกลุ่มความสนใจ | เทคโนโลยีโฆษณาจะสามารถตรวจสอบขนาดของกลุ่มความสนใจ (เช่น จำนวนผู้ใช้ในกลุ่ม) ได้หรือไม่ | เบราว์เซอร์จะจัดเก็บข้อมูลการเป็นสมาชิกกลุ่มความสนใจไว้ในอุปกรณ์ของผู้ใช้ และจะไม่แชร์กับผู้ให้บริการเบราว์เซอร์หรือบุคคลอื่น
อย่างไรก็ตาม ในทางทฤษฎี เจ้าของกลุ่มความสนใจสามารถติดตามการเรียก navigator.joininterestgroup(...) ทั้งหมดได้ การติดตามการโทรนี้ไม่รับประกันขนาดที่แน่นอนของ IG (เนื่องจากผู้ใช้สามารถออกจากกลุ่มได้ตลอดเวลา) แต่จะทำให้เจ้าของสามารถตั้งขีดจำกัดสูงสุดและประมาณขนาดได้ |
| การแสดง | โค้ด JS/WebAssembly ในการเสนอราคาจะถูกคอมไพล์ในการประมูลแต่ละครั้งหรือไม่ | ระบบจะคอมไพล์โค้ด JS/WebAssembly เพียงครั้งเดียวในการประมูลแต่ละครั้ง |
| การแสดง | ขอบเขตของ BiddingDurationMsec คืออะไร | BiddingDurationMsec จะรวมเวลาในการคอมไพล์สคริปต์ แต่ไม่รวมเวลาดาวน์โหลด, เวลาคอมไพล์ Wasm, เวลาเครือข่าย, เวลาดึงข้อมูลจากเซิร์ฟเวอร์คีย์-ค่า หรือเวลาอื่นใดก่อนคอมไพล์ JS |
| การปรับแต่งช่อง | เป็นไปได้ไหมที่จะอัปเดต adComponent ให้มีการปรับแต่งสำหรับผู้ใช้ | adComponent จะอัปเดตได้เมื่อผู้เรียกใช้อัปเดตกลุ่มความสนใจเมื่อเรียกใช้joinInterestGroup หรือเมื่อ Chrome เรียกไปที่ DailyUpdateURL วิธีนี้ช่วยให้ผู้เรียกใช้อัปเดต adComponent ตามความรู้ของผู้ใช้จากเว็บไซต์ปัจจุบันหรือตามข้อมูลที่ไม่ระบุตัวบุคคลตามลำดับ คุณสามารถดูข้อเสนอต้นฉบับของ Turtledove ระดับผลิตภัณฑ์ได้ที่นี่ ซึ่งรวมถึงการวิเคราะห์บางส่วนโดย RTB House เกี่ยวกับผลกระทบต่อเมตริกหลักสำหรับกรณีการใช้งานคำแนะนำ |
| กลุ่มความสนใจ | เจ้าของกลุ่มความสนใจสามารถนำผู้ใช้บางรายออกอย่างมีเงื่อนไขได้ไหม | การเป็นสมาชิกกลุ่มความสนใจจะจัดเก็บอยู่ในเบราว์เซอร์ของผู้ใช้เท่านั้น และนำออกได้เฉพาะในฝั่งของผู้ใช้เท่านั้น (เช่น โดยการล้างข้อมูลเว็บไซต์)
อย่างไรก็ตาม เจ้าของกลุ่มความสนใจอาจเรียกใช้ navigator.leaveAdInterestGroup() (โดยมีตรรกะแบบมีเงื่อนไขล้อมรอบ) หากผู้ใช้กลับไปยังหน้าเว็บที่อยู่ภายใต้การควบคุมของเจ้าของกลุ่มความสนใจ |
| การแสดง | วิธีวัดประสิทธิภาพของ generateBid | เวลาในการคอมไพล์และดำเนินการสามารถวัดได้ด้วย BiddingDurationMsec คุณสามารถวัดเวลาดาวน์โหลดได้ด้วย chrome://net-export ใน Chrome เวอร์ชันล่าสุด เวลาคอมไพล์และดำเนินการจะแสดงในแท็บประสิทธิภาพของเครื่องมือสำหรับนักพัฒนาเว็บ |
| ความถี่ในการอัปเดตกลุ่มความสนใจ | มีการอัปเดตกลุ่มความสนใจจากเบราว์เซอร์บ่อยเพียงใด | สำหรับกลุ่มความสนใจที่ไม่มีการอัปเดตในช่วง 24 ชั่วโมงที่ผ่านมา Chrome จะพยายามอัปเดตเมื่อมีการเรียกใช้ navigator.updateAdInterestGroups() หรือเมื่อมีโอกาสเข้าร่วมการประมูล ดูคำอธิบายเพิ่มเติมที่นี่ |
| ผู้ให้บริการรวบรวมข้อมูล | จะมีการรองรับผู้ให้บริการคลาวด์อื่นๆ ในบริการรวบรวมข้อมูลเมื่อใด | ขณะนี้เรายังไม่มีข้อมูลอัปเดตเกี่ยวกับเวลาดังกล่าว แต่จะแจ้งให้ทราบอีกครั้งเมื่อมีการดำเนินการ ขณะนี้มีเพียง AWS เท่านั้นที่ตรงตามข้อกำหนดด้านความปลอดภัยของบริการรวบรวมข้อมูล |
| ไทม์ไลน์การทดสอบ FLEDGE | FLEDGE จะทดสอบใน BYOS นานเท่าใด มีเวลาเพียงพอที่จะเปลี่ยนจากโมเดล BYOS เป็นโมเดลแบบ TEE หรือไม่ | เพื่อให้แน่ใจว่าระบบนิเวศมีเวลาเพียงพอในการทดสอบ เราไม่คาดหวังว่าจะต้องมีการใช้ TEE จนกว่าเวลาจะผ่านไปหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สาม เราจะแจ้งข้อมูลที่สำคัญให้นักพัฒนาแอปเริ่มทดสอบและนำไปใช้ก่อนที่การเปลี่ยนแปลงนี้จะเกิดขึ้น ขณะนี้เราไม่มีการอัปเดตเพิ่มเติม แต่จะแจ้งให้ทราบเพิ่มเติมเมื่อเราดำเนินการแล้ว โปรดดูข้อมูลล่าสุดที่นี่ |
| ขีดจำกัดขนาดข้อมูล | จำกัดขนาดข้อมูลของ Wasm ในฟังก์ชันการเสนอราคาเท่าใด | มีข้อกำหนดว่าการอัปเดตกลุ่มความสนใจไม่สามารถส่งผลให้เกิดกลุ่มความสนใจที่มีขนาดเกิน 50 KB ตามที่กล่าวไปที่นี่ แต่ยังไม่ได้กำหนดขีดจำกัดของขนาดข้อมูลสำหรับ Wasm เราจึงอยากทราบความคิดเห็นเกี่ยวกับหัวข้อนี้ |
| สัญญาณการประมูล | จะมีโครงสร้างข้อมูลที่เป็นมาตรฐานสำหรับauctionSignals ไหม | ยังไม่มีการกำหนดระยะเวลานี้ แต่เรายินดีรับฟังความคิดเห็น |
| การค้นหาเซิร์ฟเวอร์เทคโนโลยีโฆษณา | เป็นไปได้ไหมที่จะค้นหาข้อมูลเซิร์ฟเวอร์เทคโนโลยีโฆษณาแบบเรียลไทม์จากเซิร์ฟเวอร์ K/V | ไม่ เซิร์ฟเวอร์ K/V ทำงานในรูปแบบความน่าเชื่อถือซึ่งบังคับใช้ "ไม่มีเครือข่าย การเข้าถึงดิสก์ ตัวจับเวลา หรือการบันทึก" เพื่อไม่ให้ข้อมูลผู้ใช้รั่วไหล โปรดดูรายละเอียดเพิ่มเติมจากตัวอธิบายโมเดลความน่าเชื่อถือที่นี่ |
| ความถี่ในการอัปเดต adComponents | ไม่สามารถอัปเดตฟิลด์ adComponents (ขณะนี้อยู่ในการตั้งค่า IG เท่านั้น) ตามประวัติการท่องเว็บของผู้ใช้ | Privacy Sandbox มีเป้าหมายที่จะสนับสนุนความต้องการของระบบนิเวศของเว็บโดยไม่มีการติดตามข้ามเว็บไซต์ ซึ่งหมายถึงการป้องกันการเข้าถึงประวัติการท่องเว็บ เราขอแนะนําให้ใช้ตัวเลือกอื่นๆ เช่น Topics |
| ผลการประมูล | วงการโฆษณารู้อัตราการชนะการประมูลได้หรือไม่ | ระบบจะรายงานผลการประมูลโดยเรียกใช้ฟังก์ชัน report Results() และ reportWin() ในโค้ดการประมูล ที่ผู้ขายและผู้ซื้อที่ชนะตามลำดับ ทำให้แต่ละค่ามีโอกาสทำการบันทึกและรายงานเกี่ยวกับผลการประมูล |
| (มีการรายงานในไตรมาส 2 ด้วย)
การรองรับการกำหนดเป้าหมายกลุ่มความสนใจเชิงลบ |
API สำหรับรองรับการกำหนดเป้าหมายกลุ่มความสนใจเชิงลบ: แสดงโฆษณาเฉพาะในกรณีที่ผู้ใช้ไม่ได้อยู่ในกลุ่มความสนใจเท่านั้น | ข้อมูลอัปเดตในไตรมาสที่ 3:
เราได้แชร์ ข้อเสนอ ใหม่และต้องการความคิดเห็น |
การวัดผลโฆษณาดิจิทัล
Attribution Reporting (และ API อื่นๆ)
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| ข้อกำหนด OT | นำข้อจำกัด Permission-Policy ออกระหว่าง / สำหรับ OT เท่านั้น | โปรดดูการเปลี่ยนแปลงที่ประกาศในนโยบายสิทธิ์ระหว่างการทดสอบ ข้อกังวลของผู้มีส่วนเกี่ยวข้องที่จัดการกับการเปลี่ยนแปลงนี้คือการอนุญาตให้ DSP ทดสอบ API กับ iframe แบบข้ามต้นทางในปริมาณที่สูงกว่า เริ่มแรก DSP ต้องประสานงานกับผู้เผยแพร่โฆษณา/SSP เพื่อตรวจสอบว่ามีการกำหนดนโยบายสิทธิ์ที่ถูกต้องเพื่อทดสอบ API ใน iframe แบบข้ามต้นทาง แต่ DSP ที่เปลี่ยนแปลงนี้จะเรียกใช้ API ได้โดยค่าเริ่มต้น และ SSP/ผู้เผยแพร่โฆษณาสามารถปิดใช้ API ได้หากจำเป็นในระหว่างช่วงทดลองใช้จากต้นทาง |
| เสียงรบกวน | แสดงความคิดเห็นว่าระดับเสียงสูงเกินไปและส่งผลต่อประโยชน์ของการรายงาน | เรายินดีรับฟังความคิดเห็นเกี่ยวกับสัญญาณรบกวนซึ่งเราจะใช้เพื่อกำหนดวิธีตั้งค่าพารามิเตอร์ที่เกี่ยวข้องกับสัญญาณรบกวนบางอย่าง นอกจากนี้ เรายังวางแผนที่จะเผยแพร่แหล่งข้อมูล เครื่องมือ และเอกสารอื่นๆ เพิ่มเติมเพื่อช่วยผู้ทดสอบในเรื่องนี้ด้วย |
| Conversion ข้ามโดเมน | วิธีติดตาม Conversion ที่ข้ามโดเมน เช่น มีปลายทาง 2 แห่งขึ้นไป | เรากำลังพูดคุยและรับฟังความคิดเห็นเกี่ยวกับคำถามนี้ |
| ข้อกำหนดในการแก้ไขข้อบกพร่อง | ขออนุญาตให้นักพัฒนาแอปตรวจสอบงบประมาณความเป็นส่วนตัวที่เหลืออยู่เมื่อติดตั้งใช้งาน / ทดสอบรายงานสรุปไหม | คุณสามารถติดตาม คำขอฟีเจอร์ได้ที่นี่ |
| นโยบายการใช้งาน API | ความคิดเห็นที่แนะนำนโยบายสำหรับผู้ที่สามารถใช้ API หนึ่งๆ ตามข้อจำกัดสำหรับสิ่งต่างๆ เช่น การเก็บลายนิ้วมือ | นี่เป็นแนวคิดที่น่าสนใจมากและเป็นสิ่งที่เราจะยินดีอย่างยิ่งที่จะได้ร่วมงานเพิ่มเติมกับทั้งผู้ให้บริการเบราว์เซอร์รายอื่นๆ และระบบนิเวศของเว็บที่กว้างขึ้น |
| การตั้งค่าวันหมดอายุในรายงาน Conversion | ขอการสนับสนุนตัวกรองรายงาน / หมดอายุไม่ถึง 24 ชั่วโมง | การหมดอายุระดับชั่วโมงเป็นสาเหตุที่ทำให้เกิดข้อกังวลด้านความเป็นส่วนตัว เนื่องจากทำให้เทคโนโลยีโฆษณารู้ได้อย่างแน่ชัดว่าผู้ใช้เข้าชมเว็บไซต์ของผู้ลงโฆษณาในช่วงเวลาใด การหมดอายุของระดับวันจะช่วยให้เทคโนโลยีโฆษณากรองการแสดงผลที่ไม่ถูกต้องออกโดยไม่ระบุว่าผู้ใช้เข้าชมเว็บไซต์ในเวลาใด |
| การหมดอายุของโทเค็น OT | ขอขยายความถูกต้องของโทเค็น OT ที่มีอยู่เพื่อลดค่าใช้จ่ายในการดำเนินการ | เราตระหนักดีว่าต้องมีการต่ออายุโทเค็นและกำลังดำเนินการเพื่อให้นักพัฒนาซอฟต์แวร์ง่ายขึ้นและแจ้งข้อมูลเพิ่มเติม |
| การสนับสนุนระดับภูมิภาค | ขณะนี้บริการรวบรวมข้อมูลยังไม่รองรับทุกภูมิภาค | นี่เป็นข้อจำกัดปัจจุบันสำหรับรุ่นเบต้า เราคาดว่าจะรองรับภูมิภาคอื่นๆ เพิ่มเติมขณะที่การทดสอบดำเนินไป แต่ยังไม่มีลำดับเวลาที่ชัดเจนสำหรับการดำเนินการนี้ |
| ความล่าช้าในการรายงานระดับเหตุการณ์ | ความล่าช้า 2-30 วันในการรายงานระดับเหตุการณ์อาจยาวเกินไปสําหรับ Use Case บางกรณี | เราได้แชร์ข้อเสนอที่นี่เพื่อให้เทคโนโลยีโฆษณาควบคุมว่าจะส่งรายงานระดับเหตุการณ์ผ่านวันหมดอายุเมื่อใด ค่าเริ่มต้นคือ 30 วัน แต่สามารถตั้งค่าให้สั้นกว่านี้ก็ได้ |
| (มีการรายงานในไตรมาส 2 ด้วย)
การระบุแหล่งที่มาแบบมัลติทัช |
อนุญาตการระบุแหล่งที่มาแบบมัลติทัช เช่น ข้ามอุปกรณ์หรือข้ามแอป | ข้อมูลอัปเดตในไตรมาสที่ 3:
วิธีการระบุแหล่งที่มาแบบมัลติทัชในปัจจุบันจำเป็นต้องมีการเชื่อมโยงการแสดงผลของผู้ใช้ (และข้อมูลระบุตัวตน) ในเว็บไซต์ต่างๆ เข้าด้วยกัน ดังนั้น ฟังก์ชันการทำงานนี้ในรูปแบบปัจจุบันไม่สอดคล้องกับเป้าหมายของ Privacy Sandbox ซึ่งมีจุดประสงค์เพื่อสนับสนุนกรณีการใช้งานโฆษณาหลักโดยไม่ต้องมีการติดตามข้ามเว็บไซต์ |
| ไทม์ไลน์การผสานรวม FLEDGE และ Attribution Reporting | ลำดับเวลาสำหรับการผสานรวม FLEDGE และ Attribution Reporting API | ขณะนี้เรายังไม่มีการอัปเดตใดๆ ที่จะแชร์ แต่จะแจ้งข้อมูลเพิ่มเติมต่อสาธารณะเมื่อเราสามารถกำหนดเวลาที่แน่นอนได้ |
| ทริกเกอร์หลายประเภท | คำขอเพื่อความยืดหยุ่นที่มากขึ้นในการลงทะเบียนทริกเกอร์ | เราได้เสนอระบบการกรองข้อมูลที่ซ้ำกันออกสำหรับ API แบบรวมที่จะช่วยให้เทคโนโลยีโฆษณามีความยืดหยุ่นมากขึ้นในการควบคุมรายงานระดับเหตุการณ์และรายงานที่รวบรวมได้ |
| การวัด | ขอรับข้อมูลการวัดว่าพื้นที่โฆษณามีประสิทธิภาพดีหรือไม่ | ขอขอบคุณสำหรับความคิดเห็น เราต้องการทราบรายละเอียดเพิ่มเติมเกี่ยวกับกรณีการใช้งานของคำขอนี้ |
| การหมดอายุของ Conversion | คำขอรองรับการหมดอายุของ Conversion ในแท็กทริกเกอร์แทนแท็กแหล่งที่มาเพียงอย่างเดียว | ขอขอบคุณสำหรับความคิดเห็น เราต้องการทราบรายละเอียดเพิ่มเติมเกี่ยวกับกรณีการใช้งานของคำขอนี้ |
| การรายงานเป็นกลุ่ม | ขอการวัดเพิ่มเติมในการรายงานเป็นกลุ่ม | เรายินดีรับฟังความคิดเห็นขณะที่เราคำนึงถึงผลกระทบต่อบริการรวบรวมข้อมูลอย่างต่อเนื่อง เราอยากรู้ว่าเทคโนโลยีโฆษณาคิดอย่างไรเกี่ยวกับรายงานแบบกลุ่มและความถี่ที่คาดหวัง รวมทั้งความคิดเห็นเกี่ยวกับการเปลี่ยนแปลงกลยุทธ์แบบกลุ่มตลอดทั้งปี |
| Epsilon | ค่าของ epsilon จะได้รับการกำหนดเมื่อใด | เรากำลังทำงานร่วมกับผู้ทดสอบในระบบนิเวศอย่างใกล้ชิดเพื่อสรุปค่าของ epsilon และวิธีนำค่าไปใช้ใน GA ค่านี้จะแสดงต่อสาธารณะ พร้อมด้วยการสนทนาที่นำไปสู่การตัดสินใจเกี่ยวกับค่า หากคุณมีความคิดเห็นใดๆ โปรดโพสต์ไว้ใน ปัญหานี้ |
จำกัดการติดตามแบบไม่เปิดเผย
การลด User Agent
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| ทรัพยากร Dependency ของการติดตั้งใช้งาน | แก้ไขปัญหาทรัพยากร Dependency ของการทำให้ใช้งานได้ของ Structured User Agent (SUA) | เราได้เปิดตัว "ระยะที่ 4" ซึ่งเป็นการลดเวอร์ชันย่อยให้เหลือ 100% ของผู้ใช้ Chrome ในเวอร์ชัน 101 ขึ้นไป ดูข้อมูลอัปเดตที่นี่ |
| การทดสอบ | ขอขยายช่วงทดลองใช้การลด User Agent จากต้นทางจาก Meta | เราได้ขยายช่วงทดลองใช้จากต้นทางและได้รับอนุญาตให้นำขีดจำกัดการเข้าชมออกเพื่อรองรับเว็บไซต์ขนาดใหญ่ ข้อจำกัดในการเข้าชมแบบผ่อนคลายจะมีผลกับทุกเว็บไซต์ ไม่ว่าจะเล็กหรือใหญ่ |
คำแนะนำไคลเอ็นต์ User Agent
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| (มีการรายงานในไตรมาส 2 ด้วย)
ข้อกังวลเกี่ยวกับการต่อต้านการประพฤติมิชอบ / การต่อต้านการละเมิด |
ฟีเจอร์บางอย่างที่อาจสูญหายผ่านทาง UA-CH ได้แก่ เครื่องมือติดตามการเปลี่ยนเส้นทางคลิก และการคลิกที่เป็นการฉ้อโกง | ข้อมูลอัปเดตในไตรมาสที่ 3:
เราได้รับเสียงตอบรับเชิงบวกจากบริษัทที่รายงานว่าไม่เห็นผลกระทบด้านลบต่อไปป์ไลน์การป้องกันการฉ้อโกง (ดูผลลัพธ์ที่นี่และที่นี่) ทีมของเรายังคงตรวจสอบปัญหาที่อาจเกิดขึ้นกับผู้มีส่วนเกี่ยวข้องในการต่อต้านการประพฤติมิชอบและการวัดผลอย่างต่อเนื่อง |
| นโยบายสิทธิ์ | แคชนโยบายสิทธิ์ไว้ไหม | ระบบไม่ได้แคชนโยบายสิทธิ์ ตามที่อธิบายไว้ในปัญหา GitHub นี้ |
กแนตแคตเชอร์ (WIP)
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| กรณีการใช้งานตำแหน่งทางภูมิศาสตร์ | Gnatcatcher อาจป้องกันไม่ให้มีการใช้งานกรณีการใช้งานตำแหน่งทางภูมิศาสตร์ที่ถูกต้องในอนาคต เช่น การปรับเปลี่ยนเนื้อหาตามตำแหน่งที่ตั้งทางภูมิศาสตร์ | เรากำลังทำงานร่วมกับผู้มีส่วนเกี่ยวข้องเพื่อให้ Chrome ยังคงสนับสนุนกรณีการใช้งานที่อยู่ IP ที่ถูกต้อง |
ขยายขอบเขตความเป็นส่วนตัวแบบข้ามเว็บไซต์
ชุดโดเมนของบุคคลที่หนึ่ง
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| นโยบาย | ข้อกังวลว่า FPS ไม่สอดคล้องกับบทบัญญัติของสัญญาผูกมัด CMA เกี่ยวกับ "นิติบัญญัติด้านการคุ้มครองข้อมูลที่เกี่ยวข้อง" โดยที่ GDPR ไม่ได้จํากัดจํานวนเว็บไซต์ในชุด แต่ FPS กําหนดขีดจํากัดที่ 3 รายการ | Google ให้คำมั่นสัญญากับ CMA เพื่อออกแบบและนำข้อเสนอ Privacy Sandbox ไปใช้ในลักษณะที่จะไม่ทำให้การแข่งขันบิดเบือนด้วยการพิจารณาตนเองเพื่อนำเสนอธุรกิจของ Google และคำนึงถึงผลกระทบที่มีต่อการแข่งขันในการโฆษณาดิจิทัล ผู้เผยแพร่โฆษณา และผู้ลงโฆษณา รวมถึงผลกระทบต่อผลลัพธ์ด้านความเป็นส่วนตัวและการปฏิบัติตามหลักการคุ้มครองข้อมูลตามที่ระบุไว้ในนิติบัญญัติด้านการคุ้มครองข้อมูลที่เกี่ยวข้อง ข้อกังวลที่แสดงดังกล่าวไม่ได้เปิดเผยความไม่สามารถใช้ร่วมกับ GDPR ได้ เราทำงานอย่างใกล้ชิดกับ CMA อย่างต่อเนื่องเพื่อให้มั่นใจว่างานของเราสอดคล้องกับความมุ่งมั่นเหล่านี้ รายละเอียดเพิ่มเติมจะอยู่ในส่วน "การเปลี่ยนแปลงต่างๆ ตามความคิดเห็น" ด้านล่าง |
| เอกสารประกอบ | ขอตัวอย่างเพิ่มเติมและอัปเดตคำอธิบายที่มีอยู่ | ตัวอย่างในข้อความอธิบายของเราอยู่ระหว่างตรวจสอบ และจะชี้แจงหรือนํารายการต่อไปนี้ออกตามความจําเป็น |
| การแชร์ค่ากำหนด | ข้อเสนอเพื่อสร้างค่ากำหนดในชุดพรรคเดียวกัน | เรายินดีรับฟังความคิดเห็นและพูดคุยเรื่องแนวคิดดังกล่าวกันอย่างต่อเนื่อง ที่นี่ |
| การบังคับใช้ | กระบวนการบังคับใช้ที่โปร่งใสมีความเสี่ยงในการละเมิดโดยผู้ไม่ประสงค์ดี | เราขอขอบคุณสำหรับความคิดเห็น และมีส่วนร่วมในการสนทนากับผู้มีส่วนเกี่ยวข้องใน GitHub (โดยพิจารณาประเด็นต่างๆ ในปัญหานี้ และต้องการรวบรวมคำแนะนำที่อยู่ในปัญหานี้) และฟอรัมอื่นๆ เพื่อประเมินความเสี่ยงนี้และระบุประเด็นปัญหาที่อาจเกิดขึ้น |
| การเป็นเจ้าของร่วมกัน | ข้อเสนอสำหรับการประกาศที่เครื่องอ่านได้สำหรับการเป็นเจ้าของร่วมกัน | เรายินดีและยินดีให้ข้อมูลเพิ่มเติมเกี่ยวกับข้อเสนอ |
| การเป็นเจ้าของโดเมนย่อย | โดเมนย่อยที่ต่างกันซึ่งมีผู้ควบคุมข้อมูลที่แตกต่างกัน นโยบายความเป็นส่วนตัวที่แตกต่างกัน หรือดำเนินการโดยบุคคลที่ต่างกันรวมอยู่ในชุดโดเมนของบุคคลที่หนึ่งเดียวกันหรือไม่ | เราวางแผนที่จะนำกรณีการใช้งาน eTLD ทั่วไปออกตามความคิดเห็นที่ได้รับ |
| การลดการละเมิด | ขอรายละเอียดเพิ่มเติมเกี่ยวกับมาตรการลดการละเมิด | เรากำลังพิจารณาการจัดการกระบวนการดังกล่าว เราจะแจ้งรายละเอียดเพิ่มเติมให้ทราบในอีกไม่กี่เดือนข้างหน้า |
| เวกเตอร์การโจมตีที่เป็นไปได้ | ชุดที่เกี่ยวข้องและหลอกลวงสําหรับหน้าเว็บที่ค้นหาได้ง่ายสามารถใช้เพื่อดึงการเข้าชมไปยังหน้าอื่นๆ ที่แสดงให้เห็นว่าเป็นหน้าเว็บอิสระโดยหลอกลวง | เรากำลังรวบรวมข้อมูลจากสาธารณะอย่างต่อเนื่องและพยายามหาวิธีการที่เป็นไปได้เพื่อจัดการปัญหานี้ |
| ตั้งค่าการตรวจสอบความถูกต้อง | ตรวจสอบความถูกต้องของชุดหนังสือผ่านนโยบายทั่วไปที่ได้รับความยินยอม | สมาชิกจำนวนมากของชุมชนมาตรฐานเว็บและระบบนิเวศในวงกว้างชี้ให้เห็นว่าเป็นไปไม่ได้ |
| ขีดจำกัดโดเมน | คำขอขยายจำนวนโดเมนที่เชื่อมโยง | เรากำลังหารือกันอย่างจริงจังเกี่ยวกับขีดจำกัดโดเมนใน FPS และยินดีรับฟังความคิดเห็นเพิ่มเติมจากชุมชนเกี่ยวกับจำนวนโดเมนที่เกี่ยวข้องที่จำเป็นสำหรับกรณีการใช้งาน |
| การโต้ตอบกับบริการย่อย | ข้อกังวลเกี่ยวกับบริการและการโต้ตอบกับชุดย่อยที่เกี่ยวข้อง | ขอขอบคุณสำหรับความคิดเห็น และจะพยายามทำให้เรื่องนี้ชัดเจนยิ่งขึ้นในข้อกำหนดเฉพาะในอนาคต |
| (มีการรายงานในไตรมาส 2 ด้วย)
การปรับปรุงความเป็นส่วนตัว |
การมีเว็บไซต์ในชุดเดียวกันมากเกินไปอาจทำให้เกิดผลลัพธ์คล้ายกับคุกกี้ของบุคคลที่สาม | ข้อมูลอัปเดตในไตรมาสที่ 3:
ข้อเสนอล่าสุดแนะนำขีดจำกัด 3 โดเมนสำหรับส่วนย่อย "ที่เชื่อมโยง" (ซึ่งไม่รวม ccTLD และโดเมนบริการ) Chrome กำลังทำงานร่วมกับระบบนิเวศอย่างจริงจังเพื่อตัดสินว่าขีดจำกัดนี้เหมาะสมหรือไม่ |
| (มีการรายงานในไตรมาส 2 ด้วย)
ข้อกำหนดทั่วไปของนโยบายความเป็นส่วนตัว |
เป็นไปไม่ได้ที่จะคงไว้ซึ่งนโยบายความเป็นส่วนตัวที่เหมือนกันสำหรับผลิตภัณฑ์ทั้งหมดและเขตอำนาจศาลที่ต้องอยู่ในชุดเดียวกัน | ข้อมูลอัปเดตในไตรมาสที่ 3:
นโยบายความเป็นส่วนตัวทั่วไปไม่ใช่ข้อกำหนดให้เป็นส่วนหนึ่งของชุดเดียวกันอีกต่อไป |
Fenced Frames API
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| เหตุใดจึงต้องเป็นองค์ประกอบใหม่แทนที่จะเป็นแอตทริบิวต์ใน iframe | คำถามเกี่ยวกับข้อเสนอ Frenced Frame แทนข้อเสนอ iFrame ที่มีอยู่ | เรายินดีรับฟังความคิดเห็นและยินดีรับฟังแนวคิดเกี่ยวกับวิธีรวมสถานการณ์ปัจจุบันของสิ่งต่างๆ ตามที่ได้พูดคุยกันไว้ ที่นี่ |
| ผู้สังเกตการณ์ทางแยกในกรอบที่มีรั้วล้อมรอบ | คำถามเกี่ยวกับความสามารถในการแสดงตัวโฆษณาของข้อมูลภายในเฟรมที่มีการปิดกั้น | ซึ่งอยู่ในช่วงการแสดงความคิดเห็นและในเอกสารนี้และใน GitHub เรายินดีให้พาร์ทเนอร์แชร์กรณีการใช้งานกับเราเพื่อทำความเข้าใจวิธีให้การสนับสนุนให้ดียิ่งขึ้น |
| รองรับพื้นที่โฆษณาวิดีโอและเนทีฟ | เฟรมที่มีการปิดกั้นรองรับพื้นที่โฆษณาวิดีโอและเนทีฟไหม | ในแง่ของความสามารถในการเล่นวิดีโอ Fenced Frames ไม่แตกต่างจาก iframe และนั่นคือเหตุผลที่ไม่มีการเรียกอย่างชัดแจ้งในเอกสารประกอบสาธารณะ หากพบปัญหาใดๆ เกี่ยวกับโฆษณาวิดีโอ โปรดส่งความคิดเห็นเพื่อให้เราตรวจสอบเพิ่มเติม |
| เว็บ Bundle | การแสดง / การแสดงโฆษณาโดยแพ็กเกจเว็บจะกลายเป็นข้อกำหนดเมื่อใช้ Fenced Frame x FLEDGE ในอนาคตไหม | เป้าหมายระยะยาวคือการรองรับ Web Bundle สำหรับการแสดงผลเนื้อหาโฆษณาในเฟรมที่มีการปิดกั้น อย่างไรก็ตาม การใช้งาน FLEDGE ในปัจจุบันไม่รองรับและต้องมีการแสดงผลทรัพยากร HTML ที่ดึงจาก generateUrl |
| มิติข้อมูลเนื้อหา | ขอRender_url เพื่อรองรับมาโครสำหรับความสูงและความกว้างของช่องโฆษณา เพื่อให้เราสามารถตอบกลับด้วยครีเอทีฟโฆษณาขนาดที่เหมาะสม | มีการพูดถึงเรื่องนี้อย่างแข็งขันที่นี่ |
API พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| การผสานรวม FLEDGE | พื้นที่เก็บข้อมูลที่ใช้ร่วมกันและ FLEDGE จะผสานรวมอย่างไร | แม้ว่าในขณะนี้เราจะไม่ได้ดำเนินการในเรื่องนี้ แต่เราก็สนใจที่จะสำรวจแนวคิดนี้หากเราสามารถรักษาการคุ้มครองความเป็นส่วนตัวไว้ได้ เราขอแนะนำให้ผู้ที่สนใจยื่นการแนะนำเกี่ยวกับกรณีการใช้งานที่เป็นไปได้ ข้อเสนอนี้อาจสนับสนุนในที่เก็บ GitHub ของพื้นที่เก็บข้อมูลที่ใช้ร่วมกันหรือที่เก็บ GitHub ของ FLEDGE |
| การเก็บรักษาข้อมูล | การล้างพื้นที่เก็บข้อมูลที่ใช้ร่วมกันจะลดประโยชน์ใช้สอย หากมีการขยายระยะเวลาเก็บรักษาหรือความสามารถในการลบคีย์/ค่าแต่ละรายการเป็นทางเลือกอื่น | เราพยายามรักษาสมดุลระหว่างความเป็นส่วนตัวของผู้ใช้กับข้อดีและข้อเสียของยูทิลิตีอยู่เสมอ เรายินดีรับฟังความคิดเห็นเกี่ยวกับการปรับปรุง และสนับสนุนให้พาร์ทเนอร์แสดงความคิดเห็นเพิ่มเติมและรายละเอียดเพิ่มเติมเมื่อทดสอบพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน |
| สัญญาณเชิงลบ | สัญญาณเชิงลบจาก Mozilla เกี่ยวกับข้อเสนอพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน | เราขอขอบคุณ Mozilla สำหรับการตรวจสอบข้อเสนอของเราอย่างถี่ถ้วน เรามีแผนที่จะตอบกลับความคิดเห็นของพวกเขาในอนาคตอันใกล้ |
ชิป
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| ข้อกำหนดที่แบ่งพาร์ติชันแล้ว | เพิ่มข้อกำหนดลักษณะการทำงานที่ชัดเจนสำหรับแอตทริบิวต์ "แบ่งพาร์ติชัน" ในคุกกี้ของบุคคลที่หนึ่ง | เราได้พูดคุยเรื่องนี้ทางโทรศัพท์ PrivacyCG และติดตามผลเกี่ยวกับปัญหาเกี่ยวกับ GitHub พร้อมแจ้งหมายเหตุแล้ว เรากำลังทำงานร่วมกับเบราว์เซอร์ นักพัฒนาซอฟต์แวร์ และชุมชนความเป็นส่วนตัวอย่างต่อเนื่องเพื่อปรับพฤติกรรมและระบุแนวทางนั้น |
| การฝังที่ตรวจสอบสิทธิ์แล้ว | CHIPS อาจส่งผลต่อขั้นตอนการลงชื่อเข้าใช้ SSO ปัจจุบัน เนื่องจากการแบ่งพาร์ติชันต่างๆ ส่งผลต่อการฝังที่ตรวจสอบสิทธิ์แล้ว | เราทราบกรณีการใช้งานแบบฝังที่ตรวจสอบสิทธิ์แล้วและกำลังดำเนินการสำรวจโซลูชัน |
| ขีดจำกัดพาร์ติชันคุกกี้ | กังวลว่าขีดจำกัดคุกกี้ 10 รายการในปัจจุบันอาจไม่เพียงพอสำหรับการใช้งานบางประเภท | เรากำลังยกเลิกการจำกัดจำนวนคุกกี้ให้มีหน่วยความจำไม่เกิน 12KB ซึ่งจะช่วยเราแก้ไขข้อกังวลเกี่ยวกับขีดจํากัดของคุกกี้ ในขณะเดียวกันก็มั่นใจได้ว่าประสิทธิภาพและการใช้งานหน่วยความจำของเบราว์เซอร์จะไม่ได้รับผลกระทบในเชิงลบ |
| ไทม์ไลน์ช่วงทดลองใช้จากต้นทาง | การขยายเวลาต่อเวลาเป็นไปตามการนำข้อกำหนดข้อจำกัดด้านชื่อโฮสต์ออก | เราได้ขยายกำหนดเวลาช่วงทดลองใช้จากต้นทางหลังจากได้รับความคิดเห็นจากระบบนิเวศ |
| ข้อจำกัดการทดสอบใน Chrome | ความสามารถในการทดสอบ CHIPS ใน Firefox เนื่องจากข้อจำกัดปัจจุบันใน Chrome | การใช้งานของ Firefox มีความแตกต่างโดยประมาณ Chrome มีขีดจำกัดคุกกี้ต่ำกว่า และ CHIPS เป็นวิธีการเลือกใช้ แต่ Firefox ได้รับการแบ่งพาร์ติชันตามค่าเริ่มต้น |
| (มีการรายงานในไตรมาส 2 ด้วย)
การฝังที่ตรวจสอบสิทธิ์แล้ว |
CHIPS มีการเก็บรักษาสถานะการลงชื่อเข้าใช้ไว้ด้วย CHIPS ไหม | ข้อมูลอัปเดตในไตรมาสที่ 3:
ขณะนี้ระบบไม่ได้เก็บรักษาสถานะที่ลงชื่อเข้าใช้ไว้ แต่ไม่ใช่ Use Case ที่ตั้งใจสำหรับ CHIPS เราทราบกรณีการใช้งานแบบฝังที่ตรวจสอบสิทธิ์แล้วและกำลังดำเนินการสำรวจโซลูชัน |
FedCM
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| (มีการรายงานในไตรมาส 2 ด้วย)
เวกเตอร์การโจมตีที่เป็นไปได้ |
เวกเตอร์การโจมตีที่อาจเกิดขึ้นผ่านการตกแต่งลิงก์และการโจมตีแบบเวลา | ข้อมูลอัปเดตในไตรมาสที่ 3:
เราได้ทำงานร่วมกับ Mozilla เพื่อหาความเข้าใจร่วมกันเกี่ยวกับวิธีจัดการกับปัญหาการโจมตีทางเวลาและดูรายละเอียดได้ที่นี่ ขณะนี้เรากำลังสร้างต้นแบบการเปลี่ยนแปลงทางสถาปัตยกรรมนี้และคาดว่าจะดำเนินการทดสอบในอีกไม่กี่ไตรมาสข้างหน้า |
| ผู้ให้บริการข้อมูลประจำตัว | ตัวเลือกบัญชีผู้ใช้: ผู้ให้บริการข้อมูลประจำตัวรายเดียว คำขออนุญาตผู้ให้บริการข้อมูลประจำตัวหลายราย | เราได้ทำงานร่วมกับผู้ให้บริการเบราว์เซอร์และ FedID CG เพื่อบรรลุผลในการอนุญาตให้มีผู้ให้บริการข้อมูลประจำตัวหลายราย และได้มาถึงสูตรที่คุ้มค่าที่จะลองใช้แล้ว ดูคำอธิบายข้อเสนอได้ที่นี่ และเราคาดว่าจะสามารถพัฒนาต้นแบบและทำการทดสอบได้ในอีกไม่กี่ไตรมาสต่อจากนี้ |
| ปัญหาที่ทราบเกี่ยวกับการรวมศูนย์ | ขอให้แจกแจงกรณีที่การรวมศูนย์อาจมีปัญหากับการเลิกใช้งานคุกกี้ของบุคคลที่สาม | FedID CG มีรายการงานซึ่งแจกแจงวิธีแบ่งการรวมศูนย์ที่นี่และที่นี่ นอกจากนี้ บริษัทยังสร้างเมทริกซ์การตัดสินใจเพื่อจับคู่ข้อขัดข้องกับ Web Platform API ที่นี่ |
| พารามิเตอร์คำนาม | พารามิเตอร์ Nounce จะส่งผลต่อขั้นตอนการลงชื่อเข้าใช้ไหม | การทำเช่นนี้อาจถือเป็นการติดตามข้ามเว็บไซต์ แต่เรายังคงรวบรวมข้อมูลอยู่และวิเคราะห์วิธีดำเนินการกับกรณีเช่นนี้อยู่ |
| คำยินยอมของผู้ใช้ | การลิงก์ฝ่ายพึ่งพิง (RP) ที่แตกต่างกันกับความยินยอมของผู้ใช้สำหรับแต่ละต้นทาง | ข้อกำหนดนี้ควบคุมวิธีที่ต้นทางภายในโดเมนเดียวกันแชร์คุกกี้ไม่ได้ ข้อกำหนดดังกล่าวจะอนุญาตให้ idtoken จากต้นทางของ IDP ไปยังต้นทาง RP แต่ขึ้นอยู่กับ RP ที่จะเลือกว่าจะจัดเก็บสถานะการลงชื่อเข้าใช้ของผู้ใช้ไว้ในคุกกี้ที่ล็อกไว้ที่ต้นทางเดียวนั้น หรือคุกกี้ที่แชร์กับต้นทางภายในโดเมนเดียวกัน |
| บัญชี IDP
ความสามารถในการถ่ายโอนได้ |
ตัวเลือกของผู้ใช้ในการย้ายข้อมูล IdP หากเลือกเมื่อโอนระหว่าง 2 IdP 2 รายการ | ดูเหมือนว่าผู้ใช้จะต้องดำเนินการโดยตรงในหน้าลงชื่อสมัครใช้ของ IdP ใหม่ที่ต้องการ ไม่ใช่ผ่าน FedCM API |
| การลบบัญชี | บัญชีการเพิกถอน IDP สำหรับการลบบัญชีด้วย IdP | เราเปิดคำขอฟีเจอร์นี้เพื่อป้อนข้อมูลและอยู่ระหว่างการตรวจสอบ |
| การอ้างสิทธิ์ UI | คำกล่าวอ้างเกี่ยวกับแง่มุมต่างๆ ของอินเทอร์เฟซสำหรับแต่ละเบราว์เซอร์ | โปรดดูคำขอพุลเพื่อแก้ปัญหานี้ |
| การตรวจสอบการอ้างอิงของ IDP | การตรวจสอบ IdP เพื่อหา URL ที่มาของ RP | เพิ่มการตรวจสอบผู้อ้างอิง IDP ไปยังข้อกำหนดแล้ว โปรดดูคำขอแบบพุล |
| ขั้นตอนการลงชื่อเข้าใช้ | ส่งคำขอให้ปรับแต่งขั้นตอนการลงชื่อเข้าใช้ตามค่ากำหนดของ RP | เรายินดีรับฟังแนวคิดและปรึกษาหารือกันอย่างต่อเนื่อง |
ต่อสู้กับสแปมและการประพฤติมิชอบ
API โทเค็นความน่าเชื่อถือ
| ธีมความคิดเห็น | สรุป | การตอบสนองของ Chrome |
| การประพฤติมิชอบและการละเมิด | เครื่องมือใดที่ช่วยให้มั่นใจว่าบ็อตไม่ได้หลอกให้ผู้ออกโทเค็นการให้โทเค็น บ็อตไม่ได้ควบคุมโทเค็นที่ออกให้กับผู้ใช้จริง และป้องกันไม่ให้บ็อตออกโทเค็นที่เป็นอันตราย | แม้ว่าบ็อตอาจสามารถรับโทเค็นจากผู้ออกบัตร แต่เราขอแนะนําให้ผู้ออกบัตรมีข้อจำกัดเกี่ยวกับความถี่ในการออกโทเค็นและวิธีการที่มีประสิทธิภาพในการออกโทเค็นและการอัปเดตตรรกะการออกเมื่อผู้ไม่ประสงค์ดีพยายามหลบเลี่ยง ผู้ออกที่ไม่มีตรรกะที่ชัดเจนเพียงพอในการออกโทเค็นมีแนวโน้มที่จะได้รับความเชื่อถือน้อยลงในระบบนิเวศเนื่องจากเว็บไซต์ต่างๆ จะให้ความสำคัญกับโดยขึ้นอยู่กับผู้ออกบัตรที่มีประสิทธิภาพมากกว่า |
| การประพฤติมิชอบและการละเมิด | ผู้แลกสิทธิ์ Trust Token จะระบุได้ว่าจะยอมรับ Trust Token จากเอนทิตีบางรายการเท่านั้นหรือไม่ | เป็นไปได้ ส่วนการแลกสิทธิ์โทเค็นความน่าเชื่อถือในข้อความอธิบายจะอธิบายวิธีการทำงาน |
| การประพฤติมิชอบและการละเมิด | ผู้ออก Trust Token จะระบุรายชื่อผู้แลกสิทธิ์และไม่อนุญาตให้ผู้อื่นแลกสิทธิ์โทเค็นได้ไหม | ขณะนี้ไม่ได้อยู่ในกรณี แต่ทีมกำลังตรวจสอบกรณีการใช้งานนี้อยู่ |
| ไทม์ไลน์ | Trust Token API จะพร้อมให้บริการสำหรับผู้ใช้ทั่วไปเมื่อใด | ทันทีที่เราสามารถทำตามกำหนดเวลาได้ เราจะแชร์ข้อมูลเพิ่มเติมต่อสาธารณะ |
| (มีการรายงานในไตรมาส 2 ด้วย)
ค่าใช้จ่ายในการบำรุงรักษา |
ไม่ระบุระยะเวลาการสนับสนุนเวอร์ชันโปรโตคอล | ข้อมูลอัปเดตในไตรมาสที่ 3:
และมีการเพิ่มการรองรับเพิ่มเติมใน API เพื่อรองรับการใช้งานพร้อมกันหลายเวอร์ชันเพื่อให้เปลี่ยนเวอร์ชันต่างๆ ได้อย่างค่อยเป็นค่อยไป แต่กรอบเวลาสำหรับการรองรับ / การเลิกใช้งานยังคงอยู่ระหว่างการพิจารณา |