รายงานความคิดเห็น - ไตรมาสที่ 4 ปี 2022

รายงานรายไตรมาสสําหรับไตรมาสที่ 4 ของปี 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
(มีการรายงานไว้ในไตรมาสที่ 3) ความมีประโยชน์สําหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ	ข้อกังวลว่าเทคโนโลยี Privacy Sandbox ชื่นชอบนักพัฒนาซอฟต์แวร์รายใหญ่ และเว็บไซต์เฉพาะกลุ่ม (ขนาดเล็ก) นั้นมีส่วนมากกว่าเว็บไซต์ทั่วไป (ขนาดใหญ่)	การตอบสนองของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่ 3 "Google ให้คำมั่นสัญญากับ CMA เพื่อออกแบบและนำข้อเสนอ Privacy Sandbox ไปใช้ในลักษณะที่ไม่ทำให้การแข่งขันบิดเบือนจากการพิจารณาธุรกิจของ Google เอง และคำนึงถึงผลกระทบที่มีต่อการแข่งขันด้านโฆษณาดิจิทัล รวมถึงผลกระทบต่อผู้เผยแพร่โฆษณาและผู้ลงโฆษณาด้วย ไม่ว่าจะมีขนาดเท่าใดก็ตาม เราจะทำงานร่วมกับ CMA อย่างใกล้ชิดเพื่อให้งานของเราสอดคล้องกับความมุ่งมั่นเหล่านี้ ขณะที่การทดสอบ Privacy Sandbox คืบหน้าไป หนึ่งในคำถามหลักที่เราจะประเมินคือประสิทธิภาพของเทคโนโลยีใหม่สำหรับผู้มีส่วนเกี่ยวข้องประเภทต่างๆ ความคิดเห็นเป็นสิ่งสำคัญในเรื่องนี้ โดยเฉพาะความคิดเห็นที่เฉพาะเจาะจงและนำไปใช้ได้จริง ซึ่งจะช่วยให้เราปรับปรุงการออกแบบทางเทคนิคให้ดียิ่งขึ้นต่อไป เราได้ทำงานร่วมกับ CMA เพื่อพัฒนาแนวทางการทดสอบเชิงปริมาณ รวมทั้งสนับสนุนให้ CMA เผยแพร่หมายเหตุเกี่ยวกับการออกแบบการทดสอบเพื่อให้ข้อมูลเพิ่มเติมแก่ผู้เข้าร่วมตลาดและโอกาสที่จะได้แสดงความคิดเห็นเกี่ยวกับแนวทางที่เราเสนอ"
(มีการรายงานในไตรมาส 3 ด้วย) คำขอเอกสาร	คำขอแหล่งข้อมูลเพิ่มเติมที่แสดงรายละเอียดวิธีจัดการการทดสอบ การวิเคราะห์ และการติดตั้งใช้งาน	ข้อมูลอัปเดตในไตรมาสที่ 4: เราขอขอบคุณนักพัฒนาซอฟต์แวร์ที่พบว่าเนื้อหาในปัจจุบันของเรามีประโยชน์ และยังคงมุ่งมั่นที่จะมอบเนื้อหาเพิ่มเติมต่อไปเพื่อให้นักพัฒนาแอปได้เข้าใจการทำงานของเทคโนโลยีใหม่เหล่านี้ ในช่วงไตรมาสที่ผ่านมา เราได้เพิ่มส่วน "ข่าวสารและข้อมูลอัปเดต" ใน privacysandbox.com และเผยแพร่การตรวจสอบโดยละเอียดเกี่ยวกับวิธีที่ Privacy Sandbox ช่วยเพิ่มความเกี่ยวข้องของโฆษณาในอนาคต นอกจากนี้ เรายังมีเซสชันสาธารณะในเวลาทำการสำหรับนักพัฒนาซอฟต์แวร์เพื่อแชร์แนวทางปฏิบัติแนะนำและการสาธิต รวมถึงเซสชันถามและตอบกับหัวหน้าทีมผลิตภัณฑ์และวิศวกรเพื่อเปิดโอกาสให้มีการแลกเปลี่ยนความคิดเห็น/คำถามแบบสด
Core Web Vitals	เวลาในการตอบสนองของ Privacy Sandbox API ส่งผลต่อ Core Web Vitals อย่างไร	การรักษาเวลาในการตอบสนองให้น้อยที่สุดคือเป้าหมายในการออกแบบที่สำคัญของ Privacy Sandbox API ปัจจุบันเราคาดหวังว่าเวลาในการตอบสนองของ API น่าจะส่งผลต่อ Core Web Vitals ของเว็บไซต์น้อยที่สุด เนื่องจากระบบจะเรียกใช้ API ส่วนใหญ่หลังจากการแสดงผลเว็บไซต์ครั้งแรก เราติดตามและปรับปรุงอย่างต่อเนื่องเพื่อลดเวลาในการตอบสนองสำหรับ API แต่ละรายการ รวมถึงกระตุ้นให้มีการทดสอบและแสดงความคิดเห็นอย่างต่อเนื่อง จะมีการแก้ไขเวลาในการตอบสนองของกระบวนการเสนอราคาแบบเรียลไทม์ในส่วน FLEDGE ในส่วน "ประสิทธิภาพของการประมูล FLEDGE"
ความสามารถในการทำงานร่วมกัน	ข้อกังวลเกี่ยวกับความสามารถในการทำงานร่วมกันกับโซลูชันอื่นๆ ที่เป็นไปได้	เป้าหมายของ Privacy Sandbox คือการปกป้องผู้ใช้จากการติดตามข้ามเว็บไซต์ ในขณะเดียวกันก็สนับสนุนความต้องการของระบบนิเวศของเว็บด้วย เรามุ่งหวังที่จะบรรลุเป้าหมายนี้โดยเลิกใช้เทคโนโลยีเบราว์เซอร์เดิมที่เปิดใช้การติดตามข้ามเว็บไซต์ เช่น คุกกี้ของบุคคลที่สาม และให้เทคโนโลยีใหม่ที่สร้างขึ้นเพื่อรองรับ Use Case ที่เฉพาะเจาะจงแทน ข้อเสนอ Privacy Sandbox เพิ่มความเป็นส่วนตัวด้วยการจำกัดข้อมูลที่ออกจากอุปกรณ์ของผู้ใช้ ข้อเสนอนี้ไม่ได้กำหนดข้อจำกัดทางเทคนิคเกี่ยวกับความสามารถของเว็บไซต์ในการแชร์หรือประมวลผลข้อมูลเมื่อมีการรวบรวมจากเบราว์เซอร์ ดังนั้น เทคโนโลยีเหล่านี้จึงไม่ได้ป้องกันบริษัทต่างๆ จากการทำข้อตกลง "การดูแลข้อมูล" หรือความสัมพันธ์ทางสัญญาอื่นใดที่คล้ายคลึงกัน ในทํานองเดียวกัน ไม่มีการจํากัดความสามารถของผู้ใช้ในการยินยอมให้แชร์ข้อมูลของตนผ่านช่องทางอื่นๆ เพื่อความชัดเจน Google มุ่งมั่นที่จะนำเทคโนโลยี Privacy Sandbox ไปใช้แบบเดียวกับเว็บไซต์ทั้งหมด รวมถึงผลิตภัณฑ์และบริการของ Google หลังจากที่ Chrome ยุติการสนับสนุนคุกกี้ของบุคคลที่สามแล้ว ความมุ่งมั่นยังแสดงให้เห็นอย่างชัดเจนว่า Google จะไม่ใช้ข้อมูลส่วนตัวอื่นๆ เช่น ประวัติการท่องเว็บใน Chrome ที่ซิงค์ของผู้ใช้ เพื่อติดตามผู้ใช้สำหรับการกำหนดเป้าหมายหรือการวัดผลการโฆษณาดิจิทัล

แสดงเนื้อหาและโฆษณาที่เกี่ยวข้อง

หัวข้อ

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ผลกระทบต่อการจัดอันดับในการค้นหาของ Google	คำถามว่าจะมีการใช้การรองรับ Topics API ของเว็บไซต์เป็นสัญญาณที่เป็นไปได้สำหรับการจัดอันดับผลการค้นหาของ Google Search หรือไม่	บางเว็บไซต์อาจเลือกไม่ใช้ Topics API ทีม Privacy Sandbox ไม่ได้ประสานงานหรือร้องขอจากองค์กร Search ให้ใช้การจัดอันดับหน้าเว็บเป็นสิ่งจูงใจเพื่อให้เว็บไซต์นำ Topics API มาใช้ Google ยืนยันกับ CMA ว่า Google Search จะไม่ใช้การตัดสินใจของเว็บไซต์ในการเลือกไม่ใช้ Topics API เป็นสัญญาณการจัดอันดับ
ตัวแยกประเภทหัวข้อ	เพิ่ม URL และเนื้อหาของหน้าเว็บนอกเหนือจากชื่อโฮสต์เพื่อกำหนดหัวข้อของหน้าเว็บเพื่อปรับปรุงประโยชน์ใช้สอยสำหรับผู้มีส่วนเกี่ยวข้องต่างๆ	ปัจจุบันประวัติการท่องเว็บของผู้ใช้ได้รับการจัดประเภทโดยใช้ชื่อโฮสต์ของเว็บไซต์ Chrome จะยังคงประเมินตัวเลือกเพื่อพิจารณาข้อมูลเมตาระดับหน้าเว็บ (เช่น คอมโพเนนต์ทั้งหมดหรือบางส่วนของ URL หน้าเว็บและ/หรือเนื้อหา) ในการจัดประเภทหัวข้อ การปรับปรุงยูทิลิตีใดๆ จะต้องคำนึงถึงความเสี่ยงด้านความเป็นส่วนตัวและการละเมิด ตัวอย่างเช่น ความเสี่ยงเกี่ยวกับข้อมูลเมตาโดยเฉพาะมีดังนี้ - เว็บไซต์แก้ไขข้อมูลเมตาระดับหน้าเว็บเพื่อเข้ารหัสความหมายที่แตกต่าง (และอาจมีความละเอียดอ่อน) เป็นหัวข้อต่างๆ - เว็บไซต์ที่แก้ไขข้อมูลเมตาระดับหน้าเว็บเพื่อสื่อให้เข้าใจผิดเกี่ยวกับหัวข้อของตนเพื่อผลประโยชน์ทางการเงิน - เว็บไซต์แก้ไขข้อมูลเมตาระดับหน้าเว็บแบบไดนามิกเป็นวิธีการติดตามข้ามเว็บไซต์
(มีการรายงานในไตรมาส 3 ด้วย) ผลกระทบต่อสัญญาณของบุคคลที่หนึ่ง	สัญญาณ Topics อาจมีค่าสูง จึงส่งผลให้สัญญาณที่อิงตามความสนใจของบุคคลที่หนึ่งอื่นๆ มีคุณค่าลดลง	ผลตอบรับของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่ 3 "เราเชื่อว่าการโฆษณาตามความสนใจเป็นกรณีการใช้งานที่สำคัญสำหรับเว็บ และ Topics ได้รับการออกแบบมาเพื่อรองรับ Use Case นั้น ดังที่ได้อธิบายไว้ [ในรายงานไตรมาส 3] ผู้มีส่วนเกี่ยวข้องในระบบนิเวศรายอื่นๆ ได้แสดงความกังวลว่า Topics อาจไม่มีประโยชน์มากพอที่จะให้คุณค่า ในทุกกรณี การปรับปรุงการจัดหมวดหมู่ยังคงอาศัยความพยายามอย่างต่อเนื่อง และเราคาดหวังว่าการจัดหมวดหมู่จะได้รับการพัฒนาไปพร้อมกับการทดสอบและการป้อนข้อมูลในระบบนิเวศ"
การอัปเดตการจัดหมวดหมู่	รายการการจัดหมวดหมู่จะได้รับการอัปเดตอย่างไร	เรากำลังรับฟังความคิดเห็นเกี่ยวกับการจัดหมวดหมู่ที่จะเป็นประโยชน์มากที่สุดสำหรับระบบนิเวศนี้ การจัดหมวดหมู่ที่รวมอยู่ในข้อเสนอ Topics API เริ่มต้นออกแบบมาเพื่อเปิดใช้การทดสอบการทำงาน Chrome กำลังพิจารณาแนวทางหลายๆ วิธีในการอัปเดตการจัดหมวดหมู่ ตัวอย่างเช่น Chrome อาจใช้แนวคิดเกี่ยวกับคุณค่าเชิงพาณิชย์สำหรับแต่ละหัวข้อเพื่อพิจารณาว่าควรรวมหมวดหมู่ใดไว้ในการปรับปรุงในอนาคต
ประสิทธิภาพของตัวแยกประเภทระดับภูมิภาคสำหรับหัวข้อ	ตัวแยกประเภทหัวข้อมีประสิทธิภาพไม่ดีในโดเมนระดับภูมิภาค	เรากําลังปรับปรุงตัวแยกประเภทอย่างต่อเนื่อง จากความคิดเห็นที่เราได้รับ ความเป็นไปได้อย่างหนึ่งที่เราต้องพิจารณาคือการขยายรายการลบล้าง Topics ซึ่งการวิเคราะห์ของเราแสดงให้เห็นว่าจะเพิ่มความครอบคลุมทั่วโลกและปรับปรุงความแม่นยํา อธิบายว่าการแยกประเภท Topics API มีองค์ประกอบที่เกี่ยวข้อง 2 อย่าง ได้แก่ (1) รายการการลบล้างที่มีเว็บไซต์ 10,000 อันดับแรกและหัวข้อของเว็บไซต์ และ (2) โมเดล ML ในอุปกรณ์ที่จัดประเภทชื่อโฮสต์เป็นหัวข้อ เมื่อขยายรายการการลบล้าง (1) เราจะปรับปรุงประสิทธิภาพของการแยกประเภทสําหรับภูมิภาคที่ตัวแยกประเภทอาจด้อยประสิทธิภาพได้
1 สัปดาห์ Epoch	Epoch ระยะเวลา 1 สัปดาห์นานเกินไปสำหรับผู้ใช้ที่ต้องการตัดสินใจในระยะสั้น	เรากำลังพิจารณาความยาวของ Epoch ที่เหมาะสมและยินดีรับ ความคิดเห็นเพิ่มเติมว่า Epoch ใดที่ควรปรับปรุงสำหรับระบบนิเวศ
การดึงข้อมูลส่วนหัว HTTP	กังวลว่ามีข้อมูลไม่เพียงพอเกี่ยวกับการดึงข้อมูลส่วนหัว HTTP ของหัวข้อ	อยู่ระหว่างดำเนินการสำหรับส่วนหัวและ fetch() เรายังมีข้อมูลอยู่ที่นี่ และเรายังได้เพิ่มข้อมูล อย่างไรก็ตามข้ามขั้นตอนนี้ ไปในตัวอธิบายด้วย
หัวข้อมีไว้เพื่อช่วยผู้ลงโฆษณาเท่านั้น ไม่ใช่ผู้ใช้	Topics/Privacy Sandbox เป็นวิธีการที่มุ่งเน้นอุตสาหกรรมเป็นหลัก ประโยชน์สำหรับผู้ใช้ไม่ชัดเจนเท่าสิทธิประโยชน์ในอุตสาหกรรม	ประโยชน์ที่ผู้ใช้ได้รับคือ Topics สนับสนุนโฆษณาตามความสนใจซึ่งทําให้เว็บใช้งานได้ฟรีและเปิดกว้างอยู่เสมอ และเราก็เชื่อว่าช่วยเพิ่มความเป็นส่วนตัวได้อย่างมากเมื่อเทียบกับคุกกี้ของบุคคลที่สาม การนําคุกกี้ของบุคคลที่สามออกโดยไม่มีทางเลือกอื่นที่ใช้ได้อาจส่งผลเสียต่อผู้เผยแพร่โฆษณา และอาจนำไปสู่แนวทางที่แย่กว่า ซึ่งมีความเป็นส่วนตัวน้อยลง ไม่โปร่งใส และผู้ใช้ไม่สามารถรีเซ็ตหรือควบคุมได้จริง บริษัทจำนวนมากกำลังทดสอบ Topics และ Sandbox API และเรามุ่งมั่นที่จะให้บริการเครื่องมือเพื่อความก้าวหน้าด้านความเป็นส่วนตัวและสนับสนุนเว็บ เมื่อเร็วๆ นี้ W3C Technical Architecture Group ได้เผยแพร่มุมมองเริ่มต้นเกี่ยวกับ Topics API ซึ่งเราจะตอบกลับแบบสาธารณะ ในขั้นตอนนี้ เนื่องจาก Google ได้รับคำถามจากระบบนิเวศเกี่ยวกับสิ่งที่รีวิวนี้อาจบ่งบอกถึงการพัฒนาและการเปิดตัว Topics API เราจึงขอยืนยันอีกครั้งถึงแผนที่จะทำให้ฟีเจอร์นี้พร้อมใช้งานใน Chrome เวอร์ชันเสถียรในปีนี้ แม้ว่า Google จะชื่นชมกับความคิดเห็นของ W3C Technical Architecture Group แต่ถือว่าความพยายามดังกล่าวสำคัญอย่างยิ่งในการพัฒนาและทดสอบ Topics ด้วยการปรึกษากับ CMA และระบบนิเวศ
การรั่วไหลของข้อมูล	ข้อกังวลว่า Topics อาจรั่วไหลไปยังเว็บไซต์อื่นๆ โดยไม่ได้รับอนุญาต	การออกแบบ Topics API ทำให้มีโอกาสมากที่ข้อมูลจากผู้เผยแพร่โฆษณารายเดียว (และแม้แต่ผู้เผยแพร่โฆษณากลุ่มเล็กๆ) จะรั่วไหลออกไปไม่ว่าในทางใดก็ตาม เว็บไซต์ของผู้เผยแพร่โฆษณายังควบคุม Topics API ได้อย่างเต็มรูปแบบและห้ามไม่ให้เข้าถึง API นี้ผ่านนโยบายสิทธิ์ได้ด้วย
ไม่มีผู้ลงโฆษณาสำหรับการทดสอบ	ผู้เผยแพร่โฆษณากังวลว่าตนเองยังไม่สามารถแสดงคุณค่าของ Topics ต่อผู้ลงโฆษณาได้	ในช่วงครึ่งหลังของปี 2023 เราวางแผนที่จะเตรียม API ทั้งหมดที่เกี่ยวข้องกับโฆษณาทั้งหมดไว้สำหรับการทดสอบการผสานรวม และเปิดใช้การวิเคราะห์ระบบนิเวศของคุณค่าของ Topics สำหรับผู้ลงโฆษณา CMA จะควบคุมดูแลการทดสอบและการเผยแพร่ผลลัพธ์ ซึ่งจะตรวจสอบข้อมูล การวิเคราะห์ และระเบียบวิธี เราสนับสนุนให้ระบบนิเวศแชร์ความคิดเห็นกับ Google และ CMA
Topics และ FLEDGE	ขอข้อมูลเพิ่มเติมเกี่ยวกับวิธีใช้ Topics ภายในตรรกะการเสนอราคาของ FLEDGE	เป็นไปได้ที่จะใช้ Topics ภายในตรรกะการเสนอราคาของ FLEDGE คู่มือการผสานรวมก็อยู่ระหว่างดำเนินการ และจะมีรายละเอียดเพิ่มเติมเกี่ยวกับการใช้งานด้วย
การจัดอันดับที่กำหนดเองสำหรับผู้โทรหัวข้อ	อนุญาตให้ผู้โทรปรับแต่งการจัดอันดับ	ความท้าทายของการจัดอันดับหัวข้อที่กําหนดเองหรือค่าสําหรับเทคโนโลยีโฆษณาแต่ละรายการคือ เทคโนโลยีนี้อาจกลายเป็นกลไกที่ทำให้เทคโนโลยีโฆษณามีอิทธิพลต่อหัวข้อที่แสดงขึ้น ซึ่งนั่นก็คือเวกเตอร์การเก็บลายนิ้วมือ
รายการลำดับความสำคัญของผู้โทรแบบหัวข้อ	ให้ผู้โทรระบุรายการหัวข้อที่มีลำดับความสำคัญสูงที่ Topics API จะส่งคืนโดยอิงตามการมีสิทธิ์	ขณะนี้เรากำลังพูดคุยเพิ่มเติมเกี่ยวกับแนวคิดนี้ และยินดีรับฟังข้อมูลเพิ่มเติม

FLEDGE

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
Google Ad Manager	ข้อกังวลว่า Google Ad Manager เป็นผู้ตัดสินใจขั้นสุดท้ายสำหรับการประมูล FLEDGE และสนับสนุนแท็กผู้เผยแพร่โฆษณาผ่าน Google และ Google Ad Manager	FLEDGE ช่วยให้ผู้เผยแพร่โฆษณาแต่ละรายเลือกโครงสร้างการประมูล รวมถึงตัวเลือกผู้ขายระดับบนสุดและผู้ขายคอมโพเนนต์ได้ ผู้ซื้อและผู้ขายแต่ละรายในการประมูลที่เป็นส่วนประกอบจะรู้ว่าผู้ขายระดับบนสุดคือใคร และสามารถเลือกได้ว่าจะเสนอราคาหรือไม่
มีผู้เข้าร่วมทดสอบ FLEDGE ไม่เพียงพอ	ขอให้กระตุ้นให้บริษัทอื่นๆ ทดสอบ FLEDGE เช่น โดยการปรับปรุงฟังก์ชันการทำงานของ API และไม่สนับสนุนทางเลือกอื่นที่รบกวนความเป็นส่วนตัว เช่น การเก็บลายนิ้วมือ	Privacy Sandbox กำลังดำเนินการอย่างเป็นขั้นตอนโดยเป็นพาร์ทเนอร์อย่างใกล้ชิดกับแนวทางของ CMA และ ICO และการทดสอบ FLEDGE ที่ใช้งานได้แสดงให้เห็นถึงความเสถียรและความสามารถที่จำเป็น Google ยังคงสนับสนุนให้ระบบนิเวศทดสอบ Sandbox API โดยเพิ่งเผยแพร่เอกสารประกอบ "เพิ่มความเกี่ยวข้องของโฆษณาสูงสุด" เพื่อแสดงให้เห็นว่า FLEDGE และ API อื่นๆ ช่วยสนับสนุน Use Case ที่สำคัญสำหรับอุตสาหกรรมโฆษณาได้หลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามอย่างไร ส่วนอื่นๆ ของ Privacy Sandbox รองรับการบรรเทาปัญหาเพื่อให้ครอบคลุมการติดตามอยู่แล้ว (ดู UA-CH, IP Protection และการลดการติดตามการเข้าออก) และจะปรับปรุงอย่างต่อเนื่อง เป้าหมายของ Google ไม่ได้ทําให้ FLEDGE เป็นโซลูชันการกำหนดเป้าหมายเดียวที่ใช้ได้จริง แต่ยังคงมุ่งมั่นที่จะทํางานร่วมกับภาคธุรกิจและหน่วยงานกํากับดูแล เพื่อขับเคลื่อนเทคโนโลยีโฆษณาที่รักษาความเป็นส่วนตัวได้ดีที่สุดในเบราว์เซอร์ Chrome
กรณีการใช้งานแมชชีนเลิร์นนิง	FLEDGE และ Attribution Reporting จะรองรับกรณีการใช้งานของแมชชีนเลิร์นนิงเพื่อฝึกอัลกอริทึมการเสนอราคาในการประมูลเพิ่มเติม	เราตระหนักถึงความจำเป็นในการช่วยให้ผู้ทดสอบค้นพบวิธีที่มีประโยชน์มากที่สุดในการนำเทคโนโลยี Privacy Sandbox ไปประยุกต์ใช้ เราได้เริ่มเผยแพร่คำแนะนำที่เกี่ยวข้องกับการใช้ด้านต่างๆ ของ Privacy Sandbox API เป็นอินพุตสำหรับแมชชีนเลิร์นนิงโดยเฉพาะ ส่วนล่าสุด "เพิ่มความเกี่ยวข้องของโฆษณาสูงสุด" กล่าวถึงวิธีที่อุตสาหกรรมโฆษณาจะใช้ประโยชน์จากสัญญาณเหล่านี้สําหรับแมชชีนเลิร์นนิง และเราวางแผนที่จะเผยแพร่คําแนะนําดังกล่าวต่อไปในอนาคต
การค้นหาเซิร์ฟเวอร์ค่าคีย์ FLEDGE (K/V)	ทําไมเซิร์ฟเวอร์ K/V จึงเป็นการค้นหาแบบสาธารณะ	เซิร์ฟเวอร์ K/V มีจุดประสงค์เพื่อให้สัญญาณแบบเรียลไทม์แก่การประมูล FLEDGE ดังนั้น เซิร์ฟเวอร์ K/V จะต้องเข้าถึงได้จากตำแหน่งที่มีการประมูล FLEDGE เหล่านี้ดำเนินการ ซึ่งอยู่บนอุปกรณ์ของผู้ใช้ โดยกำหนดให้เซิร์ฟเวอร์ดังกล่าวพร้อมใช้งานแบบสาธารณะ เฉพาะผู้ที่มีคีย์อยู่แล้วจึงจะดึงค่าที่เก็บไว้ในเซิร์ฟเวอร์ K/V ได้ ดังนั้นหากเทคโนโลยีโฆษณาให้คีย์แก่เบราว์เซอร์ที่อยู่ในกลุ่มความสนใจเท่านั้นและไม่ได้ใช้คีย์ที่คาดเดาได้ ก็มีเพียงเบราว์เซอร์ที่ต้องใช้ค่าดังกล่าวเพื่อเรียกใช้การประมูลเท่านั้นที่จะเรียกข้อมูลค่านั้นได้
การกำหนดเป้าหมายตามวัน/เวลาทำอย่างไร	รองรับออบเจ็กต์วันที่ในฟังก์ชันตรรกะการเสนอราคา	ซึ่งทำได้หลายวิธี ผู้ซื้อสามารถขอให้ผู้ขายแจ้งวันที่และเวลาปัจจุบันได้ ผู้ขายจะให้ข้อมูลนี้แก่ผู้ซื้อทุกรายได้โดยสะดวก ผู้ซื้อยังระบุวันที่และเวลาในการตอบกลับคีย์-ค่าแบบเรียลไทม์ได้ด้วย สุดท้าย ผู้ซื้อสามารถระบุวันที่และเวลาซึ่งเป็นส่วนหนึ่งของการตอบสนองตามบริบทในสัญญาณต่อผู้ซื้อ ซึ่งผู้ขายสามารถส่งต่อไปยังสคริปต์ generateBid ของผู้ซื้อ
ค่ากำหนดของผู้ใช้	ความสามารถสำหรับผู้ใช้ในการเลือกที่จะบล็อกครีเอทีฟโฆษณาตามผู้ลงโฆษณาเมื่อแสดงผ่าน FLEDGE หรือโซลูชันทางเลือก	ผู้ใช้สามารถเลือกไม่ใช้ Ads API ใน Chrome ได้ สําหรับโฆษณาบางรายการ เทคโนโลยีโฆษณาที่เกี่ยวข้องคือฝ่ายที่เหมาะสมที่สุดในการควบคุมครีเอทีฟโฆษณาที่จะแสดงหรือวิธีเลือกครีเอทีฟโฆษณา
ไทม์ไลน์ที่ชัดเจนขึ้น	ขอข้อมูลเพิ่มเติมเกี่ยวกับความพร้อมใช้งานของการคุ้มครองความเป็นส่วนตัวใน FLEDGE เช่น การกำหนดให้ต้องมี Fenced Frame	เราวางแผนที่จะเผยแพร่ลำดับเวลาอย่างละเอียดมากขึ้นในไตรมาสที่ 1
การรายงานความสับสน	ขอความชัดเจนเพิ่มเติมเกี่ยวกับวิธีที่การรายงาน FLEDGE จะทํางานร่วมกับ API อื่นๆ เช่น Fenced Frames และ Private Aggregation API	เราวางแผนที่จะเผยแพร่ข้อความอธิบายเกี่ยวกับการโต้ตอบระหว่าง Private Aggregation API, FLEDGE และ Fenced Frames ในอีกไม่กี่สัปดาห์ข้างหน้า
การเสนอราคาแบบเรียลไทม์และ FLEDGE	คําแนะนําเกี่ยวกับวิธีที่ FLEDGE ผสานรวมกับการเสนอราคาแบบเรียลไทม์มาตรฐาน	สิ่งสำคัญ 2 ประการที่ทำให้ความสามารถของเทคโนโลยีโฆษณาเกี่ยวกับการเสนอราคาแบบเรียลไทม์คือการเข้าถึงข้อมูลระดับเหตุการณ์และการผสานรวมกับ ARA ที่ง่ายขึ้น เราวางแผนที่จะส่งการอัปเดตและคำอธิบายเกี่ยวกับทั้ง 2 เรื่องนี้ในไตรมาสที่ 1
ประสิทธิภาพของการประมูล FLEDGE	รายงานจากผู้ทดสอบว่าการประมูล FLEDGE มีเวลาในการตอบสนองสูง	ขอขอบคุณอย่างยิ่งที่รายงานจากผู้ทดสอบที่แชร์ผลลัพธ์และกรณีการใช้งาน รวมถึงได้แชร์คำแนะนำบางอย่างเกี่ยวกับวิธีปรับปรุงประสิทธิภาพของ FLEDGE ในขณะเดียวกัน เราได้เพิ่มเครื่องมือลงในเบราว์เซอร์เพื่อช่วยให้นักพัฒนาซอฟต์แวร์วินิจฉัยสิ่งที่ทำให้การประมูลช้าลงได้ดีขึ้น และจัดการกับแหล่งที่มาหลักๆ ของเวลาในการตอบสนองที่พบอย่างเป็นระบบ การปรับปรุงล่าสุด ได้แก่ ระยะหมดเวลาสำหรับการประมูลที่ช้า เทคนิคการกรองผู้เสนอราคาที่รวดเร็ว วิธีการใช้เวิร์กเล็ต FLEDGE ซ้ำเพื่อหลีกเลี่ยงค่าใช้จ่ายในการเริ่มต้น และการดำเนินการอย่างต่อเนื่องเพื่ออนุญาตให้คำขอโฆษณาตามบริบททำงานไปพร้อมกับกับเวลาเริ่มต้นของ FLEDGE และการดึงข้อมูลเครือข่าย เราคาดว่าการเพิ่มประสิทธิภาพเวลาในการตอบสนองจะยังคงเป็นการสนทนาต่อเนื่องระหว่างนักพัฒนาซอฟต์แวร์ Chrome และผู้ทดสอบ FLEDGE โดยอิงตามประสบการณ์จริงในการใช้งาน API
ขีดจำกัดหน่วยความจำขนาดของกลุ่มความสนใจ	คำขอเพิ่มขีดจำกัดของขนาดของกลุ่มความสนใจเดียวจาก 50 KB	เรากำลังพิจารณาคำขออย่างจริงจังและกำลังมองหาความคิดเห็นว่าการจำกัดค่าใดใช้ได้ผล
การรวมข้อมูลที่แสดงของ FLEDGE กับคุกกี้ของบุคคลที่หนึ่ง	FLEDGE จะรองรับการผสานรวมกับข้อมูลจากบุคคลที่หนึ่งของผู้ลงโฆษณาไหม	FLEDGE สร้างขึ้นเพื่อสนับสนุนการโฆษณาโดยใช้ข้อมูลจากบุคคลที่หนึ่งที่ผู้ลงโฆษณามีอยู่แล้ว อย่างไรก็ตาม FLEDGE ไม่ได้มีจุดมุ่งหมายที่จะสนับสนุนให้ผู้ลงโฆษณาเรียนรู้พฤติกรรมการท่องเว็บของผู้ใช้บนเว็บไซต์อื่นนอกเหนือจากเว็บไซต์ของผู้ลงโฆษณาเอง การแนบพฤติกรรมการท่องเว็บนอกเว็บไซต์เข้ากับข้อมูลจากบุคคลที่หนึ่งเป็นการขัดแย้งกับเป้าหมายของ Privacy Sandbox เราวางแผนที่จะแชร์คู่มือการผสานรวมพร้อมรายละเอียดเพิ่มเติมเกี่ยวกับวิธีที่ FLEDGE จะรองรับการผสานรวมกับข้อมูลจากบุคคลที่หนึ่งในอีกไม่กี่สัปดาห์ข้างหน้า
ค่า K-anonymity	ระบบจะพิจารณาค่า "K" ถึง "k-anon" อย่างไรและจะนำไปเผยแพร่	ค่า "K" ยังอยู่ระหว่างการสรุปและเราจะแชร์ข้อมูลเพิ่มเติมไปพร้อมกับการพัฒนาแผนการของเรา เราต้องการทราบว่าค่า K ที่ไม่รู้จักอาจขัดขวางความพร้อมของ FLEDGE และการฝึกโมเดล ML ที่กำหนดขอบเขตได้อย่างไร เรายินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับเรื่องนี้
การรองรับ SSP หลายรายการ	FLEDGE จะรองรับ SSP หลายรายการอย่างไร	FLEDGE รองรับการประมูลกับผู้ขายหลายรายตามที่ระบุไว้ในข้อเสนอนี้
การเปิดเผยตรรกะการเสนอราคา	ข้อกังวลว่าตรรกะการเสนอราคา DSP จะแสดงใน JavaScript	บุคคลอื่นจะเข้าถึง JavaScript ของตรรกะการเสนอราคาการออกแบบในปัจจุบันได้ แต่เราก็ยินดีรับฟังความคิดเห็นเพิ่มเติมว่าเหตุใดการดำเนินการนี้จึงเป็นข้อกังวลสำหรับ DSP
prebid.js	ลำดับเวลาในการรองรับ prebid.js ใน FLEDGE เป็นอย่างไร	Prebid.js เฉพาะเวอร์ชัน 7.14 ขึ้นไปเท่านั้นที่รองรับโมดูล FLEDGE ผู้เผยแพร่โฆษณาที่สนใจการทดสอบต้องเพิ่มโมดูล FLEDGE และอัปเกรดอินสแตนซ์ Prebid
ฟังก์ชันที่ผู้ใช้กำหนดใน FLEDGE	FLEDGE จะรองรับฟังก์ชันที่ผู้ใช้กำหนด (UDF) อย่างไร ต่อไปนี้เป็นฟังก์ชันที่ผู้ใช้ปลายทางตั้งโปรแกรมได้เพื่อขยายฟังก์ชันการทำงานของ API	ดูคำอธิบายได้ที่นี่ ระบบกำลังปรับปรุงส่วนนี้ให้ดีขึ้น เราจึงยินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับกรณีการใช้งาน
คลายข้อจำกัดที่มีต้นทางเดียวกันในทรัพยากรของกลุ่มความสนใจ	ขอผ่อนปรนข้อจำกัดที่มีต้นทางเดียวกันในทรัพยากรของกลุ่มความสนใจเพื่อเปิดใช้กรณีการใช้งานเทคโนโลยีโฆษณาบางรายการ	ในการใช้งาน FLEDGE ปัจจุบัน biddingLogicUrl, biddingWasmHelperUrl, dailyUpdateUrl และ trustedBiddingSignalsUrl ต้องมีต้นทางเดียวกันกับเจ้าของกลุ่มความสนใจ ข้อจำกัดดังกล่าวมีไว้เพื่อป้องกันการเจาะช่องโหว่บางอย่างจากผู้โจมตีตามที่อธิบายไว้ที่นี่
การเป็นเจ้าของกลุ่มความสนใจ	ส่งคำขอจำกัดว่าเทคโนโลยีโฆษณาจะใช้ JoinInterestGroup กับกลุ่มความสนใจเดียวกันในเว็บไซต์ต่างๆ ได้หรือไม่	เราโฟกัสที่วิธีใช้กลุ่มเป้าหมาย ไม่ใช่วิธีสร้าง เราพร้อมพูดคุยเกี่ยวกับแนวทางที่เป็นไปได้ที่นี่ และยินดีรับฟังข้อมูลเพิ่มเติม
การหมดอายุของคีย์เซิร์ฟเวอร์สำหรับคีย์-ค่า	การหารือเกี่ยวกับการนำคีย์เซิร์ฟเวอร์ออกเมื่อกลุ่มความสนใจที่เกี่ยวข้องหมดอายุแล้ว	เรากำลังสำรวจวิธีจัดการการหมดอายุของคีย์และต้องการทราบความคิดเห็นที่นี่

การวัดผลโฆษณาดิจิทัล

Attribution Reporting (และ API อื่นๆ)

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
การเข้าชมจากช่วงทดลองใช้จากต้นทาง	การรับส่งข้อมูลแบบทดลองใช้จากต้นทางในปัจจุบันไม่เพียงพอที่จะทดสอบยูทิลิตี	ช่วงทดลองใช้จากต้นทางในปัจจุบันมีไว้ให้ผู้เล่นในระบบนิเวศทำการทดสอบการทำงานเพื่อให้มั่นใจว่า API ทำงานได้ตามที่ต้องการ เราเข้าใจว่าจะต้องมีการรับส่งข้อมูลจำนวนมากเพื่อทดสอบยูทิลิตีเมื่อการพัฒนา Privacy Sandbox API ที่หลากหลายมีคุณภาพมากขึ้น ลำดับเวลาการทดสอบปัจจุบันระบุว่าการดำเนินการนี้จะเกิดขึ้นสำหรับเวอร์ชันสำหรับผู้ใช้ทั่วไป (นั่นคือ เมื่อเทคโนโลยีสำหรับ Use Case จะเปิดตัวและพร้อมใช้งานสำหรับการเข้าชม Chrome 100%) ในไตรมาสที่ 3 ปี 2023 (ดูไทม์ไลน์ล่าสุดใน privacysandbox.com) เรายินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับการทดสอบ Use Case ที่จำเป็นต้องมีการรับส่งข้อมูลเพิ่มเติม
ฟังก์ชันการทำงานของ API การวัดผลของ Privacy Sandbox ที่แตกต่างกัน	ข้อกังวลเกี่ยวกับการมีแนวทางการวัดผลหลายๆ แบบที่ทับซ้อนกันผ่าน Privacy Sandbox จะทําให้เกิดความซับซ้อนมากขึ้น เช่น Attribution Reporting API และ Private Aggregation API	เรากำลังจัดทำเอกสารประกอบที่ดีขึ้นเพื่อชี้แจง Use Case ต่างๆ สำหรับ API และยินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับประเด็นที่ยังไม่มีคำอธิบาย เช่น Attribution Reporting API มีจุดประสงค์เพื่อรองรับการวัด Conversion โดยเฉพาะ ขณะที่ Private Aggregation API และพื้นที่เก็บข้อมูลที่ใช้ร่วมกันเป็น API ที่มีวัตถุประสงค์ทั่วไป เพื่อรองรับการใช้งานการวัดข้ามเว็บไซต์ในขอบเขตที่กว้างขึ้น
ลองส่งคำขอรายงานที่ล้มเหลวอีกครั้ง	การชี้แจงเกี่ยวกับจำนวนครั้งที่มีการพยายามส่งคำขอรายงานหากไม่สำเร็จ	เราได้เผยแพร่คําแนะนําเกี่ยวกับเรื่องนี้แล้ว โดยสรุปแล้ว ระบบจะส่งรายงานเมื่อเบราว์เซอร์ทำงาน/ออนไลน์เท่านั้น หลังจากส่งไม่สำเร็จในครั้งแรก จะลองส่งรายงานอีกครั้งหลังจากผ่านไป 5 นาที หากไม่สำเร็จครั้งที่ 2 ระบบจะส่งรายงานอีกครั้งหลังผ่านไป 15 นาที หลังจากนั้นระบบจะไม่ส่งรายงานอีก
ความล่าช้าในการรายงาน	เราคาดว่าการรายงานจะล่าช้าเพียงใด	เราต้องการรับฟังความคิดเห็นเพิ่มเติมจากระบบนิเวศเกี่ยวกับความล่าช้าในการรายงานที่เกิดขึ้นขณะรวบรวมข้อมูลเพื่อประเมินความล่าช้าเหล่านี้เพิ่มเติมไปพร้อมกัน
หน้าแสดงผลล่วงหน้า	การระบุแหล่งที่มา ARA จะใช้กับหน้าที่แสดงผลล่วงหน้าได้ไหม	ระบบจะเลื่อนการลงทะเบียนการระบุแหล่งที่มาในหน้าที่แสดงผลล่วงหน้าจนกว่าจะมีการเปิดใช้งาน (เกิดการคลิกหรือการดูจริง) ซึ่งหมายความว่าเราจะเลื่อนเวลาคำสั่ง ping ของคำขอ "attributionsrc"
การวัด Conversion Lift	วิธีวัด Conversion Lift ด้วยการทดสอบ AB ในโดเมนเดียวกัน	เว็บไซต์สามารถวัด Conversion Lift ด้วยการทดสอบ A/B ในโดเมนเดียวกันผ่านการรายงานการระบุแหล่งที่มา เข้ารหัสพารามิเตอร์ A/B เป็นคีย์โดยใช้ API แบบรวม จากนั้นรับรายงานสรุปสำหรับมูลค่า Conversion จากที่เก็บข้อมูลคีย์เหล่านั้น
(รายงานในไตรมาสที่ 3 ด้วย) Conversion ข้ามโดเมน	วิธีติดตาม Conversion ที่ข้ามโดเมน เช่น มีปลายทาง 2 แห่งขึ้นไป	ข้อมูลอัปเดตในไตรมาสที่ 4: เราได้เผยแพร่ข้อเสนอเพื่อนำข้อจำกัดปลายทางของหน้า Landing Page ออก ซึ่งจะทำให้ติดตามการสนทนาข้ามโดเมนได้ ข้อเสนอนี้นำไปใช้แล้ว
(รายงานในไตรมาสที่ 3 ด้วย) การตั้งค่าวันหมดอายุในรายงาน Conversion	ขอการสนับสนุนตัวกรองรายงาน / หมดอายุไม่ถึง 24 ชั่วโมง	ข้อมูลอัปเดตในไตรมาสที่ 4: เราได้แจ้งคำขอแบบพุล นี้ ซึ่งจะแยกวันหมดอายุและกรอบเวลาการรายงาน เพื่อลดความล่าช้าในการรายงานเทียบกับวันหมดอายุของ Conversion ซึ่งตอนนี้เปิดตัวในเวอร์ชัน M110 แล้ว
การประพฤติมิชอบและการละเมิด	คำขอจากผู้ลงโฆษณาและนักการตลาดให้สามารถแบ่งและรวบรวมข้อมูลตามเว็บไซต์ของผู้เผยแพร่โฆษณาที่แสดงโฆษณา ซึ่งจะให้ข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุดสำหรับโฆษณาที่ฉ้อโกง	เรากําลังพูดคุยเกี่ยวกับความคิดเห็นนี้ที่นี่ และเรายินดีรับฟังข้อมูลเพิ่มเติม
(มีการรายงานในไตรมาสที่ 3 ด้วย) ความล่าช้าในการรายงานระดับเหตุการณ์	ความล่าช้า 2-30 วันในการรายงานระดับเหตุการณ์อาจยาวเกินไปสําหรับ Use Case บางกรณี	การรายงานระดับเหตุการณ์มีกรอบเวลาการรายงานเริ่มต้นเป็น 2, 7 และ 30 วัน ซึ่งแก้ไขได้โดยใช้พารามิเตอร์ "expiry" เทคโนโลยีโฆษณาสามารถกำหนดค่าเวลาหมดอายุเป็น 1 วันเป็นอย่างน้อย เพื่อรับรายงานที่เป็นไปได้ภายในไม่ถึง 2 วัน เราจำกัดรายละเอียดวันหมดอายุไว้ที่ 1 วันเพื่อเป็นกลไกการคุ้มครองความเป็นส่วนตัว เนื่องจากการรายงานที่ละเอียดยิ่งขึ้นอาจนำไปสู่การโจมตีแบบกำหนดเวลา นอกจากนี้ เรายังอนุญาตให้ตั้งค่าพารามิเตอร์ "การหมดอายุ" แบบอิสระสำหรับระดับเหตุการณ์และรายงานสรุปรวมด้วย โปรดดูที่นี่ นอกจากนี้ Google Ads จะไม่ได้รับหน้าต่างการรายงานพิเศษที่เทคโนโลยีโฆษณาอื่นๆ ไม่ได้รับผ่าน Attribution Reporting API
ข้อกำหนดที่มาของการรายงานเดียวกัน	คำขอลบข้อกำหนดสำหรับต้นทางการจดทะเบียนแหล่งที่มาให้เหมือนกับต้นทางการจดทะเบียน Conversion	เราขอเสนอให้ใช้การเปลี่ยนเส้นทาง HTTP เพื่อมอบสิทธิ์การลงทะเบียนเพื่อแก้ปัญหา Use Case นี้ เรายินดีรับความคิดเห็นเพิ่มเติมเกี่ยวกับคำแนะนำใหม่
เครื่องมือวัด Conversion	ต้องแยกความแตกต่างว่า Conversion เกิดขึ้นก่อน/หลังช่วงเวลาที่ผู้ลงโฆษณากำหนดไว้หรือไม่	Attribution Reporting API รองรับการตั้งค่ากรอบเวลาการหมดอายุและลำดับความสำคัญสำหรับการระบุแหล่งที่มาของแหล่งที่มา การใช้ทั้ง 2 อย่างในทางเทคนิค จะช่วยให้ระบุแหล่งที่มาของ Conversion ที่เกิดขึ้นภายในกรอบเวลา X วันแยกจาก Conversion ที่เกิดขึ้นหลังจาก X ได้
การจำลองเสียงรบกวน	ขอให้สามารถจำลองปริมาณ Conversion ต่อที่เก็บข้อมูลที่แตกต่างกันเพื่อให้เข้าใจผลกระทบต่อผู้ลงโฆษณาที่มี Conversion น้อยกว่า	เรากำลังจะเพิ่มวิธีจำลองนี้ใน Noise Lab เวอร์ชันต่อๆ ไป เรายินดีรับฟังความคิดเห็นเพิ่มเติม
การรายงานบนอุปกรณ์เคลื่อนที่	ระบบจะยังส่งรายงานอยู่ไหมเมื่อ Chrome ทำงานอยู่เบื้องหลังบนอุปกรณ์เคลื่อนที่	ในขณะนี้ ระบบจะไม่ส่งรายงานเมื่อ Chrome ทำงานอยู่เบื้องหลัง แม้แต่ในอุปกรณ์เคลื่อนที่ ลักษณะนี้มีแนวโน้มที่จะเปลี่ยนแปลงเมื่อ API ผสานรวมกับ Privacy Sandbox ของ Android โปรดดูที่นี่ โปรดทราบว่า Privacy Sandbox ของ Android ไม่ได้เป็นส่วนหนึ่งของสัญญาผูกมัดที่ CMA ยอมรับ
ความพร้อมใช้งานของข้อมูล	ข้อกังวลว่า Google จะมีสิทธิ์เพิ่มเติมในการเข้าถึงข้อมูลผ่าน Privacy Sandbox API	ประการแรก Google Ads ไม่ได้รับสิทธิพิเศษในการเข้าถึงข้อมูลจาก Attribution Reporting API หรือ Privacy Sandbox API อื่นๆ ปัญหานี้ยังมีการแก้ไขในส่วน "ความคิดเห็นทั่วไป" ภายใต้ "การทำงานร่วมกัน" ซึ่งมีรายละเอียดเพิ่มเติมเกี่ยวกับสัญญาผูกมัดของ Google ด้วย อย่างที่ 2 ในความแตกต่างระหว่างเว็บไซต์ขนาดใหญ่และขนาดเล็ก Google ตระหนักดีว่าการคุ้มครองความเป็นส่วนตัวแบบอิงตามสัญญาณรบกวนอาจส่งผลมากกว่าต่อข้อมูลขนาดเล็ก แต่ก็มีการบรรเทาปัญหาบางประการ เช่น วิธีการต่างๆ อย่างเช่นการรวมข้อมูลในช่วงเวลาที่นานกว่านี้สามารถแก้ไขปัญหานี้ได้ อย่างไรก็ตาม เรายังไม่ทราบอย่างแน่ชัดว่าข้อสรุปที่มาจากข้อมูลส่วนเล็กๆ (เช่น การซื้อ 1 หรือ 2 รายการ) มีความหมายต่อผู้ลงโฆษณาหรือไม่ ในระหว่างช่วงทดลองใช้จากต้นทาง Google ได้สนับสนุนให้ผู้ทดสอบใช้ประโยชน์จากความสามารถในการทดสอบกับพารามิเตอร์ความเป็นส่วนตัวและสัญญาณรบกวนที่หลากหลายเพื่อให้ความคิดเห็นที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับปัญหานี้

จำกัดการติดตามแบบไม่เปิดเผย

การลด User Agent

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
เลื่อนการลด User Agent จนกว่าระบบนิเวศของเว็บจะพร้อมทำงานมากขึ้น	เรามีเวลาไม่เพียงพอที่จะปรับตัวให้ทันกับการเปลี่ยนแปลงการลด User Agent ที่กำลังจะเกิดขึ้น	เราจัดการกับความคิดเห็นนี้ในรายงานฉบับเต็มในส่วน "ข้อกังวลของผู้มีส่วนเกี่ยวข้อง" ในส่วนที่ชื่อ "การโต้ตอบของ Google กับ CMA"
เลื่อนการลด User Agent จนกว่าระบบนิเวศของเว็บจะพร้อมทำงานมากขึ้น	ขอเลื่อนการเปิดตัวการลด User Agent จนกว่าจะติดตั้งใช้งาน User Agent ที่มีโครงสร้าง (SUA)	ทีม Google Ads เสนอการเพิ่ม User-Agent ที่มีโครงสร้าง (ดูข้อกำหนด) ไปยัง OpenRTB ในเดือนตุลาคม 2021 และได้รวมไว้ในการอัปเดตข้อมูลจำเพาะ 2.6 ซึ่งเผยแพร่ไปเมื่อเดือนเมษายน 2022 เรามีหลักฐานส่วนหนึ่งว่า SUA ใช้งานได้และพร้อมให้ใช้งานแล้วในปัจจุบัน ตามที่แสดงในบล็อกโพสต์ Scientia Mobile ซึ่งสาธิตวิธีใช้ UA-CH และ WURFL API เพื่อสร้าง SUA

###

คำแนะนำไคลเอ็นต์ User Agent

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ทดสอบ UA-CH ด้วยเทคนิคการติดตามอื่นๆ ในการป้องกันการปกปิด	คําแนะนําเกี่ยวกับวิธีทดสอบ Privacy Sandbox API ทั้งหมดและเทคนิคการเก็บลายนิ้วมือที่นำเสนอร่วมกันในแนวทางแบบองค์รวม	แผนการทดสอบของเราออกแบบมาเพื่อสะท้อนลำดับเวลาที่ไม่พร้อมกันสำหรับการพัฒนามาตรการป้องกันลายนิ้วมือของเรา ซึ่งตรงข้ามกับข้อเสนออื่นๆ ของแซนด์บ็อกซ์ เพื่อจัดการกับความจริงที่ว่ามาตรการป้องกันลายนิ้วมือบางอย่าง (เช่น งบประมาณความเป็นส่วนตัว การป้องกัน IP และการลดการติดตามการเข้าออก) จะได้รับการพัฒนาอย่างสมบูรณ์และพร้อมเปิดตัวสู่เวอร์ชันสำหรับผู้ใช้ทั่วไปหลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามแล้วเท่านั้น แม้ว่ามาตรการป้องกันการเก็บลายนิ้วมือจะไม่รวมอยู่ในการทดสอบเชิงปริมาณ แต่จะต้องได้รับการประเมินเชิงคุณภาพที่อิงตามข้อเท็จจริงที่มีอยู่ ณ เวลาที่หยุดนิ่ง
(มีการรายงานในไตรมาส 2 ด้วย) ประสิทธิภาพ	ข้อกังวลเกี่ยวกับเวลาในการตอบสนองของการได้รับคำแนะนำผ่าน Critical-CH (ในการโหลดหน้าเว็บแรก)	ดูส่วน UA-CH โดยเฉพาะด้านล่าง
ความคิดเห็นไม่เพียงพอ	ความคิดเห็นจากระบบนิเวศเกี่ยวกับการเปลี่ยนแปลง UA-CH อาจยังไม่เพียงพอ ซึ่งนำไปสู่ความกังวลเกี่ยวกับการขาดการรับรู้จากระบบนิเวศ	เราได้แชร์แผนการของเราในเชิงรุกเพื่อให้การเปิดตัวด้วยความระมัดระวังจะช่วยลดการหยุดชะงัก มีการนำเสนอแผนสำหรับการลด User Agent และ UA-CH API ต่อกลุ่มชุมชน W3C Anti-Fraud เมื่อวันที่ 18 มีนาคม 2022 และทั้งคณะทำงานเกี่ยวกับ Web Payments และ Web Payments Security Interest Group เมื่อวันที่ 20 มกราคม 2022 ไม่มีการนำเสนอข้อกังวลที่สำคัญในระหว่างหรือหลังการนำเสนอ Google ได้ร่วมมือกับผู้ให้บริการเว็บไซต์กว่า 100 แห่งในเชิงรุกเพื่อรับฟังความคิดเห็น นอกจากนี้ Google ยังใช้ช่องทาง Blink-Dev เพื่อแจ้งการเปิดตัวการลด User Agent ต่อสาธารณะตามความคิดเห็นจากผู้มีส่วนเกี่ยวข้องในระบบนิเวศ
ช่วงเวลา	ข้อกังวลเกี่ยวกับช่วงเวลาการเปิดตัวและการเตรียมความพร้อมของอุตสาหกรรม	ดูส่วน UA-CH โดยเฉพาะด้านล่าง
สถานะแพลตฟอร์ม Chrome	ขอให้อัปเดตหน้า chromestatus สำหรับ UA-CH	รายการ chromestatus ได้รับการอัปเดตเมื่อวันที่ 19 ธันวาคมเป็น "สัญญาณผสม"

การป้องกัน IP (เดิมคือ Gnatcatcher)

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
เลือกใช้หรือเลือกไม่ใช้	การเลือกใช้ความเป็นส่วนตัวของที่อยู่ IP เป็นแบบใช้หรือไม่ใช้	เป้าหมายของเราคือการให้การป้องกัน IP แก่ผู้ใช้ทั้งหมด ตอนนี้เรากำลังประเมินตัวเลือกทางเลือกของผู้ใช้สําหรับการป้องกัน IP โดยคำนึงถึงเป้าหมายดังกล่าว
กรณีการใช้งานที่อยู่ IP สำหรับข้อมูลจากบุคคลที่หนึ่ง	สามารถใช้ที่อยู่ IP เพื่อต่อเส้นทางของผู้ใช้ระหว่างโดเมนบุคคลที่หนึ่งเพื่อโพสต์การป้องกัน IP เข้าด้วยกันได้ไหม	ตามที่ได้เผยแพร่ไปก่อนหน้านี้ การปกป้อง IP จะมุ่งเน้นไปที่การติดตามในบริบทของบุคคลที่สามในขั้นต้น ซึ่งหมายความว่าโดเมนของบุคคลที่หนึ่งจะไม่ได้รับผลกระทบ
กรณีการใช้งานเทคโนโลยีโฆษณา	บริษัทจะกำหนดมาตรการป้องกันการประพฤติมิชอบด้วยการป้องกัน IP ได้อย่างไร	เราตระหนักถึงความสำคัญของที่อยู่ IP ในการเปรียบเสมือนสัญญาณของความพยายามต่อต้านการฉ้อโกงในเว็บปัจจุบัน จากคำมั่นสัญญาของเราที่มีต่อ CMA (วรรคที่ 20) เราได้กล่าวไว้ว่าเราจะไม่ใช้การป้องกัน IP โดยไม่มีการใช้ความพยายามตามสมควรเพื่อสนับสนุนความสามารถของเว็บไซต์ในการป้องกันสแปมและการฉ้อโกง สิ่งหนึ่งที่เราให้ความสำคัญสูงสุดคือการทำความเข้าใจว่าการป้องกัน IP ส่งผลต่อ Use Case เพื่อป้องกันการประพฤติมิชอบและความสามารถในการตรวจจับอย่างไร เพื่อที่เราจะได้ลงทุนกับเทคโนโลยีการรักษาความเป็นส่วนตัวที่ช่วยให้บริษัทต่างๆ รักษาความปลอดภัยของเว็บได้มากยิ่งขึ้น เราสนับสนุนการแสดงความคิดเห็นและจัดทำข้อเสนอใหม่ที่มีจุดมุ่งหมายเพื่อสนับสนุนความต้องการของบริษัทด้านความปลอดภัยและบริษัทต่อต้านการประพฤติมิชอบ แม้ว่าสัญญาณจะเปลี่ยนแปลงเมื่อเวลาผ่านไป
การประพฤติมิชอบและการละเมิด	การปกป้อง IP มีการป้องกันการปฏิเสธการให้บริการ (DoS) ไหม	เรามุ่งมั่นที่จะปรับปรุงความเป็นส่วนตัวพร้อมกับรักษาเว็บให้ปลอดภัย และการป้องกันการโจมตีแบบปฏิเสธการให้บริการคือกรณีการใช้งานเพื่อการป้องกันการละเมิดที่สำคัญที่ควรออกแบบ เราหวังว่าจะลดผลกระทบที่มีต่อการป้องกัน DoS ให้เหลือน้อยที่สุดผ่านการออกแบบการป้องกัน IP และโซลูชันการป้องกันการละเมิดใหม่ๆ เนื่องจากการปกป้อง IP มุ่งเน้นไปที่บริการแบบฝังของบุคคลที่สามในช่วงแรก ผู้มีส่วนเกี่ยวข้องบางรายได้ระบุว่าวิธีนี้ควรจะมีผลกระทบที่จำกัดต่อการปกป้อง DoS สำหรับเว็บไซต์บุคคลที่หนึ่ง อย่างไรก็ตาม เราจะขอความคิดเห็นสาธารณะต่อไปเพื่อประเมินความเสี่ยงต่อ Use Case เกี่ยวกับ DoS โดยเฉพาะอย่างยิ่งกับบริการแบบฝังของบุคคลที่สาม ในขณะเดียวกัน เรากำลังศึกษากลไกการบล็อกความคิดเห็นเกี่ยวกับการละเมิดและการบล็อกไคลเอ็นต์ที่จะช่วยให้เว็บไซต์หรือบริการบล็อกผู้ใช้ที่เป็นสแปมโดยไม่ระบุตัวตนของผู้ใช้ได้
การกรองเนื้อหา	การกรองเนื้อหาด้วยการป้องกัน IP	บริษัทแต่ละแห่งมีความต้องการแตกต่างกันในการกรองเนื้อหาและปรับแต่งประสบการณ์ของผู้ใช้ กรณีการใช้งานดังกล่าวไม่ได้อาศัยที่อยู่ IP อยู่แล้ว ดังนั้นจึงไม่ควรได้รับผลกระทบจากการปกป้อง IP ตัวอย่างเช่น ผู้เผยแพร่โฆษณาที่ต้องการปรับแต่งเนื้อหาและเพิ่มการมีส่วนร่วมมากขึ้นอาจใช้คุกกี้ของบุคคลที่หนึ่งหรือคุกกี้ที่แบ่งพาร์ติชันของบุคคลที่สาม (CHIP) เพื่อทำความเข้าใจความสนใจและการโต้ตอบที่ผ่านมาของผู้ใช้กับผู้เผยแพร่โฆษณา หรือพาร์ทเนอร์เทคโนโลยีโฆษณาที่มุ่งเน้นการแสดงโฆษณาที่เหมาะสมต่อผู้ใช้ที่เหมาะสมสามารถรวม FLEDGE และ Topics ไว้ เช่น เพื่อสร้างผลลัพธ์โฆษณาที่คล้ายกันกับปัจจุบันกับคุกกี้ของบุคคลที่สามหรือเทคโนโลยีการติดตามข้ามเว็บไซต์อื่นๆ เรากำลังพัฒนาความสามารถใหม่ๆ ในการรักษาความเป็นส่วนตัวในการปกป้อง IP เช่น ตำแหน่งทางภูมิศาสตร์แบบคร่าวๆ เพื่อรองรับการกรองเนื้อหาที่มีกลไกที่มีอยู่ไม่เพียงพอ เรายินดีรับฟังความคิดเห็นเพิ่มเติมเกี่ยวกับกรณีการใช้งานการกรองเนื้อหาที่อาจได้รับผลกระทบจากการปกป้อง IP
(รายงานในไตรมาส 3 ด้วย) กรณีการใช้งานตำแหน่งทางภูมิศาสตร์	การป้องกัน IP อาจป้องกันไม่ให้มีการใช้งาน Use Case ตำแหน่งทางภูมิศาสตร์ที่ถูกต้องในอนาคต เช่น การปรับเปลี่ยนเนื้อหาตามการค้นหาตำแหน่งทางภูมิศาสตร์	ข้อมูลอัปเดตในไตรมาสที่ 4 เรากําลังทํางานร่วมกับผู้มีส่วนเกี่ยวข้องเพื่อให้ Chrome รองรับ Use Case ที่ถูกต้องสําหรับที่อยู่ IP ต่อไป เราต้องการความคิดเห็นเกี่ยวกับระบบนิเวศของรายละเอียดเกี่ยวกับตำแหน่งทางภูมิศาสตร์จาก IP ที่นี่

งบประมาณด้านความเป็นส่วนตัว

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
เอกสารประกอบที่ชัดเจนยิ่งขึ้น	ตัวอย่างเพิ่มเติมเพื่อให้ผู้มีส่วนเกี่ยวข้องสามารถคาดการณ์ได้ว่าจะมีข้อจำกัดอย่างไรเมื่อมีการนำงบประมาณด้านความเป็นส่วนตัวมาใช้	ข้อเสนองบประมาณความเป็นส่วนตัวยังอยู่ระหว่างการพูดคุยและยังไม่มีการนำไปใช้งานโดยเบราว์เซอร์ใดๆ วันแรกสุดของความพร้อมใช้งานที่ปรับขนาดแสดงวันที่เร็วที่สุดที่สามารถบังคับใช้งบประมาณความเป็นส่วนตัว ซึ่งจะไม่เกิดขึ้นก่อนจะมีการนําคุกกี้ของบุคคลที่สามออกในปี 2024 เราไม่มีเอกสารเพิ่มเติมที่จะแชร์ในขณะนี้ เราจะแชร์รายละเอียดเพิ่มเติมเกี่ยวกับข้อเสนอเมื่อได้ข้อสรุปเพิ่มเติมแล้ว ในระหว่างนี้ เรายินดีให้ผู้มีส่วนเกี่ยวข้องแชร์ความคิดเห็นที่จะเป็นประโยชน์ในการพัฒนาข้อเสนอ

ขยายขอบเขตความเป็นส่วนตัวแบบข้ามเว็บไซต์

ชุดโดเมนของบุคคลที่หนึ่ง

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
(มีการรายงานในไตรมาสที่ 3 ด้วย) ขีดจํากัดโดเมน	คำขอขยายจำนวนโดเมนที่เชื่อมโยง	ข้อมูลอัปเดตในไตรมาสที่ 4: เราได้เผยแพร่ FPS สำหรับการทดสอบในท้องถิ่น ซึ่งรวมถึงกระบวนการส่งชุดจำลองใน GitHub และแฟล็กเพื่อทดสอบ rSA และ rSAFor ในเครื่อง และเรายังได้จัดการประชุมแบบเปิด 2 รายการสำหรับนักพัฒนาซอฟต์แวร์เกี่ยวกับ FPS เพื่อตอบคำถามเกี่ยวกับกรณีการใช้งานของกลุ่มย่อยที่เกี่ยวข้องต่อไป เราขอแนะนำให้นักพัฒนาซอฟต์แวร์ทดสอบฟังก์ชัน FPS เพื่อแสดงความคิดเห็นว่าขีดจำกัดโดเมนสำหรับชุดย่อยที่เกี่ยวข้องจะส่งผลต่อความสามารถในการใช้งาน FPS ของกรณีการใช้งานอย่างไร เราได้ชี้แจงในการเรียกของ WICG ว่า Chrome มุ่งมั่นที่จะให้บริการโซลูชันที่ใช้งานได้ และคำนึงถึงความสนใจด้านความเป็นส่วนตัวของผู้ใช้ด้วยเช่นกัน ด้วยเหตุนี้ เราขอขอบคุณความคิดเห็นจากชุมชนเกี่ยวกับ Use Case ที่เจาะจงซึ่งอาจได้รับผลกระทบจากขีดจำกัดโดเมน เพื่อให้ทีมได้พิจารณาวิธีจัดการ Use Case เหล่านี้ไปพร้อมๆ กับปกป้องความเป็นส่วนตัวของผู้ใช้ต่อไป
ขอรายละเอียดเพิ่มเติมเกี่ยวกับมาตรการลดการละเมิด	จะเกิดอะไรขึ้นหากมีการเพิ่มโดเมนในชุดที่ผู้ใช้ไม่ยินยอม	เราได้เผยแพร่หลักเกณฑ์การส่งชุดโดเมนของบุคคลที่หนึ่งแล้ว ที่นี่เมื่อวันที่ 2 ธันวาคม 2022 ตามที่อธิบายไว้ในหลักเกณฑ์การส่งงาน ชุดการจัดการการเปลี่ยนแปลงใดๆ จะทำตามและเคารพกระบวนการตรวจสอบบน GitHub รวมถึงการตรวจสอบการเป็นเจ้าของ ซึ่งช่วยลดความเสี่ยงนี้ได้
การบรรเทาการละเมิด	ข้อกังวลว่าอาจมีการใช้ประโยชน์จากการก่อตัวของชุดโดเมนของบุคคลที่หนึ่ง	เรากําลังมองหาวิธีขยายการตรวจสอบทางเทคนิคสําหรับประเภทย่อย และมองหาข้อมูลเพิ่มเติมจากชุมชนที่นี่
กรณีการใช้งานโฆษณา	คำถามที่ว่าควรใช้ชุดโดเมนของบุคคลที่หนึ่งเพื่อรองรับการกำหนดเป้าหมายโฆษณาหรือไม่	เราไม่ได้พยายามรองรับ Use Case การกำหนดเป้าหมายของโฆษณาสำหรับชุดโดเมนของบุคคลที่หนึ่ง และขอแนะนำให้ใช้ Ads API ที่พร้อมใช้งานกับกรณีการใช้งานดังกล่าว
(มีการรายงานในไตรมาส 3 ด้วย)	ข้อกังวลว่า FPS ไม่สอดคล้องกับสัญญาผูกมัดของ CMA เกี่ยวกับ "นิติบัญญัติด้านการคุ้มครองข้อมูลที่เกี่ยวข้อง" โดยมีพื้นฐานว่า GDPR ไม่ได้กำหนดขีดจำกัดจำนวนเว็บไซต์ในชุด แต่ FPS ก็จำกัดไว้ที่ 3 รายการ	ผลตอบรับของเราจะไม่เปลี่ยนแปลงจากไตรมาสที่ 3 "Google ยังคงยึดมั่นใน CMA เพื่อออกแบบและนำข้อเสนอ Privacy Sandbox ไปใช้ในลักษณะที่ไม่ทำให้การแข่งขันบิดเบือนจากการแข่งขันด้วยการอ้างถึงธุรกิจของ Google ด้วยตนเอง และคำนึงถึงผลกระทบต่อการแข่งขันในการโฆษณาดิจิทัล ผู้เผยแพร่โฆษณา และผู้ลงโฆษณา รวมถึงผลกระทบต่อผลลัพธ์ด้านความเป็นส่วนตัวและการปฏิบัติตามหลักการการคุ้มครองข้อมูล ตามที่ระบุไว้ในนิติบัญญัติด้านการคุ้มครองข้อมูลที่เกี่ยวข้อง ข้อกังวลที่แสดงดังกล่าวไม่ได้เปิดเผยความไม่สามารถใช้ร่วมกับ GDPR ได้ เราจะทำงานร่วมกับ CMA อย่างใกล้ชิดเพื่อให้มั่นใจว่างานของเราสอดคล้องกับความมุ่งมั่นเหล่านี้"
ข้อเสนอทางเลือก	ชุดที่ตรวจสอบแล้วของ GDPR	นอกจากความคิดเห็นจากระบบนิเวศเกี่ยวกับข้อเสนอให้ใช้ "ชุดที่ตรวจสอบตาม GDPR" แล้ว Chrome ยังกังวลเกี่ยวกับข้อจำกัดต่อไปนี้ของข้อเสนอทางเลือกนี้ "ชุดที่ตรวจสอบตาม GDPR" อ้างว่า "สอดคล้องกับ" GDPR (แม้ว่าจะไม่ชัดเจนว่าหมายถึงอะไร) ในทางตรงกันข้าม คำมั่นสัญญาของ Google กำหนดให้เราพิจารณา "ผลกระทบต่อผลลัพธ์ด้านความเป็นส่วนตัว" โดยทั่วไป ในการตัดสินใจยอมรับสัญญาผูกมัด CMA ชี้ให้เห็นว่าการดำเนินการนี้แตกต่างจากภาระหน้าที่ของ Google ในการคำนึงถึง "การปฏิบัติตามหลักการคุ้มครองข้อมูลตามที่ระบุไว้ในนิติบัญญัติด้านการคุ้มครองข้อมูลที่เกี่ยวข้อง" ซึ่ง CMA อธิบายไว้ว่า CMA ได้อธิบายข้อเท็จจริงที่ว่า Google มีข้อผูกพันตามนิติบัญญัติด้านการคุ้มครองข้อมูลที่เกี่ยวข้อง ทั้งที่มีผลบังคับใช้กับสัญญาผูกมัดและโดยทั่วไป เรามีข้อกังวลเกี่ยวกับความเป็นส่วนตัวเกี่ยวกับข้อเสนอเพื่ออนุญาตให้โดเมนปรากฏในหลายๆ ชุด ชุดโดเมนของบุคคลที่หนึ่งมีไว้เพื่อรองรับกรณีการใช้งานเฉพาะซึ่งปัจจุบันอาศัยคุกกี้ของบุคคลที่สามโดยไม่เปิดใช้การติดตามข้ามเว็บไซต์แบบกระจายทั่วเว็บไซต์ การอนุญาตให้โดเมนเข้าร่วมชุดหลายรายการจะนำการคุ้มครองความเป็นส่วนตัวที่สำคัญที่สร้างไว้ในข้อเสนอชุดโดเมนของบุคคลที่หนึ่งออก โดยไม่ทำให้เกิดข้อจำกัดที่มีความหมายอื่นๆ นอกจากนี้ ชุดที่ตรวจสอบโดย GDPR ยังเสนอให้ "กำหนดชุดข้อมูลเป็นกลุ่มของผู้ควบคุมข้อมูลและผู้ประมวลผลข้อมูลที่ใช้นโยบายการใช้งานร่วมกันร่วมกัน" สิ่งนี้คล้ายกับข้อกำหนดในข้อเสนอชุดโดเมนของบุคคลที่หนึ่งของเราที่ว่าทุกฝ่ายในชุดต้องแชร์นโยบายความเป็นส่วนตัวร่วมกัน ตั้งแต่นั้นมา เราได้นำข้อกำหนดดังกล่าวออกตามความคิดเห็นที่ชัดเจนจากระบบนิเวศที่ก่อให้เกิดข้อกังวลเกี่ยวกับข้อกำหนดตามนโยบายความเป็นส่วนตัว ตัวอย่างเช่น เราทราบจากผู้เผยแพร่เว็บไซต์ว่าการรักษานโยบายความเป็นส่วนตัวร่วมกันนั้นทำไม่ได้ เนื่องจากผลิตภัณฑ์และภูมิศาสตร์รูปแบบต่างๆ รวมถึงความท้าทายอื่นๆ ที่เกิดจากสมาชิกของชุมชน W3C (1, 2, 3) เราเชื่อว่าข้อเสนอนี้ก็คงจะประสบปัญหาเดียวกันเช่นกัน เนื่องจากมีการเพิ่มทางเลือกนี้ Chrome ได้อัปเดตข้อเสนอสำหรับชุดโดเมนของบุคคลที่หนึ่งและหลักเกณฑ์การส่งที่เผยแพร่สำหรับการสร้างชุดใหม่

Fenced Frames API

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
ข้อจำกัดของเฟรมที่มีการปิดกั้นระหว่าง OT	ปัจจุบันมีข้อจำกัดเกี่ยวกับ Fenced Frame สำหรับช่วงทดลองใช้จากต้นทางอย่างไร	เรากำลังจัดทำเอกสารประกอบเกี่ยวกับข้อจำกัดและสถานะการติดตั้งใช้งาน และวางแผนที่จะแชร์ข้อมูลดังกล่าวในช่วงไตรมาสที่ 1 ปี 2023
โฆษณาหลายรายการในเฟรมที่มีการปิดกั้นเดียวกัน	ขอแสดงผู้ลงโฆษณาหลายรายในเฟรมที่มีการปิดกั้นเดียวในการประมูลครั้งเดียว	ขณะนี้ยังไม่มีการพัฒนาคำขอนี้อย่างต่อเนื่อง แต่เรายินดีรับฟังความคิดเห็นเพิ่มเติมหากผู้เล่นในระบบนิเวศเห็นว่าฟีเจอร์นี้สำคัญ
เว็บ Bundle	ข้อกำหนดและการสนับสนุนที่วางแผนไว้สำหรับ Web Bundle ที่มี Fenced Frames มีอะไรบ้าง	ขณะนี้เรายังไม่มีข้อมูลอัปเดตว่าการดำเนินการนี้จะเป็นข้อกำหนดในอนาคตหรือไม่ เราจะประกาศการเปลี่ยนแปลงใดๆ ล่วงหน้าและจะไม่มีการบังคับใช้ก่อนการเลิกใช้งานคุกกี้ของบุคคลที่สาม โปรดดูสถานะปัจจุบันจากคำอธิบายนี้

API พื้นที่เก็บข้อมูลที่ใช้ร่วมกัน

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
พื้นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับเทคโนโลยีโฆษณา	ความไม่แน่นอนเกี่ยวกับการใช้พื้นที่เก็บข้อมูลที่ใช้ร่วมกันสำหรับ Use Case ของเทคโนโลยีโฆษณา	พื้นที่เก็บข้อมูลที่ใช้ร่วมกันและ API การสรุปรวมส่วนตัวสามารถใช้เพื่อวัตถุประสงค์ในการวัดผลได้หลายประเภท ซึ่งจำเป็นต้องใช้การวัดพื้นที่เก็บข้อมูลข้ามเว็บไซต์ ดูตัวอย่างได้ที่นี่ เราคาดหวังให้ผู้ให้บริการโซลูชันการวัดผลและ DSP เป็นผู้รวมหลักสำหรับกรณีการใช้งานโฆษณา

ชิป

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
(มีการรายงานในไตรมาสที่ 3 ด้วย) ข้อกำหนดที่แบ่งพาร์ติชันแล้ว	เพิ่มข้อกำหนดลักษณะการทำงานที่ชัดเจนสำหรับแอตทริบิวต์ "แบ่งพาร์ติชัน" ในคุกกี้ของบุคคลที่หนึ่ง	ข้อมูลอัปเดตไตรมาสที่ 4: หลังจากการหารือเกี่ยวกับการเรียกใช้ GitHub และ PrivacyCG สิ่งที่เรายึดมั่นก็คือคุกกี้ที่แบ่งพาร์ติชันกับคุกกี้ของบุคคลที่หนึ่งจะใช้คีย์พาร์ติชันเป็น (A,A) โดยที่ "A" เป็นเว็บไซต์ระดับบนสุด เราจะบันทึกลักษณะการทำงานนี้ไว้ในคำอธิบายและข้อกำหนด
การจัดการคุกกี้	มีเครื่องมือสำหรับการจัดการ/ควบคุมคุกกี้ของบุคคลที่หนึ่งหรือบุคคลที่สามหรือไม่	คุณใช้ Chrome DevTools และ NetLog เพื่อทดสอบเว็บไซต์ที่เปิดใช้การบล็อกคุกกี้ของบุคคลที่สามได้ เครื่องมือทั้งสองจะรายงานเมื่อคุกกี้ถูกบล็อกเนื่องจากการกำหนดค่าของผู้ใช้ เรายินดีรับฟังความคิดเห็นเกี่ยวกับประเภทของเว็บไซต์การตรวจสอบเพิ่มเติมที่คุณต้องการเห็น

FedCM

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
IdP ต้องใช้ความรู้เกี่ยวกับ RP เพื่ออนุญาตเซสชัน	ปัญหาเมื่อผู้ใช้พยายามเข้าสู่ระบบ Feide IdP จาก RP ที่แตกต่างกัน 2 ราย	เรากำลังพูดคุยถึงวิธีการแก้ปัญหานี้ ที่นี่
ความสามารถในการทำงานร่วมกัน	ข้อกังวลเกี่ยวกับผลกระทบที่ FedCM มีต่อความสัมพันธ์ระหว่างผู้ใช้และเว็บไซต์ที่เข้าสู่ระบบด้วย FedCM รวมถึง "ความสามารถในการทำงานร่วมกัน" ระหว่างเว็บไซต์	FedCM มุ่งหวังที่จะสนับสนุนบริการข้อมูลประจำตัวแบบรวมศูนย์ที่ปัจจุบันซึ่งใช้คุกกี้ของบุคคลที่สามต่อไปเมื่อมีการนำคุกกี้ของบุคคลที่สามออกจาก Chrome เราคาดหวังว่า FedCM จะเป็นเพียงตัวเลือกเดียวที่มีให้กับบริการดังกล่าว ผู้ให้บริการข้อมูลประจำตัว (IdP) และผู้ให้บริการ (RP) มีอิสระที่จะใช้เทคโนโลยีอื่นๆ ที่อาจเหมาะสมกับความต้องการของตนมากกว่า ดูเหมือนว่าข้อกังวลเกี่ยวกับความสัมพันธ์ระหว่างผู้ใช้กับ RP และ "ความสามารถในการทำงานร่วมกัน" เป็นสาเหตุของความเข้าใจผิดเกี่ยวกับข้อเสนอของ FedCM FedCM จะให้สิทธิ์ IdP ในการตัดสินใจว่าจะแชร์ข้อมูลใดกับ RP และกำหนดรูปแบบใดเมื่อผู้ใช้เลือกลงชื่อเข้าใช้เว็บไซต์ของ RP นั้น FedCM ไม่ได้กำหนดให้ IdP ต้อง "สร้างตัวระบุที่ผ่านการประมวลผลข้อมูลเพื่อไม่ให้ระบุตัวบุคคลนั้นได้ที่ไม่ซ้ำสำหรับ [RP] แต่ละรายการที่ผู้ใช้ตรวจสอบสิทธิ์ด้วย" แต่ FedCM จะเปิดให้ IdP แต่ละรายเลือกได้ว่าจะแชร์ตัวระบุจริงของผู้ใช้ เวอร์ชันสำหรับตัวระบุแต่ละเว็บไซต์ หรือข้อมูลนี้ในรูปแบบอื่น (ข้อกำหนดของ FedCM ระบุว่าความสัมพันธ์ข้ามเว็บไซต์เป็นความเสี่ยงด้านความเป็นส่วนตัวที่เกี่ยวข้องกับ API และกล่าวถึงตัวระบุที่กำหนด (ต่อเว็บไซต์) ว่าเป็นการลดความเสี่ยงที่อาจเกิดขึ้น อย่างไรก็ตาม การตัดสินใจว่าจะใช้ตัวระบุโดยตรงหรือไม่จะเป็นของ IdP ไม่กำหนดโดยเบราว์เซอร์) นอกจากนี้ FedCM ยังให้ผู้ใช้มีตัวเลือกเกี่ยวกับข้อมูลประจำตัวด้วย ตัวอย่างเช่น หากผู้ใช้มีข้อมูลประจำตัวหลายรายการที่มี IdP เดียวกัน (เช่น โปรไฟล์งานและโปรไฟล์ส่วนตัว) FedCM จะให้ผู้ใช้เลือกรหัสที่ต้องการใช้ลงชื่อเข้าสู่ระบบเว็บไซต์ของ RP หลังจากนั้น RP แต่ละรายจะเป็นผู้ตัดสินใจเองว่าจะรองรับ IdP ใดในเว็บไซต์ของตน แง่มุมหนึ่งของการตัดสินใจดังกล่าวคือการพิจารณากลไกที่ IdP ใช้งาน ไม่ว่าจะเป็น FedCM หรือเทคโนโลยีอื่น ขอย้ำอีกครั้งว่าเบราว์เซอร์จะไม่กำหนดตัวเลือกเหล่านี้สำหรับ RP หรือ IdP

ต่อสู้กับสแปมและการประพฤติมิชอบ

API โทเค็นสถานะส่วนตัว

ธีมความคิดเห็น	สรุป	การตอบสนองของ Chrome
บ็อตสำหรับจัดการ	จะเกิดอะไรขึ้นหากผู้ออกบัตรพบว่ามีการออกโทเค็นสถานะส่วนตัวให้แก่บ็อต	เพื่อหลีกเลี่ยงไม่ให้โทเค็นที่ออกให้บ็อตหลงเหลืออยู่ในระบบนิเวศเป็นเวลานาน ผู้ออกบัตรควรหมุนเวียนคีย์ที่ใช้ในการลงนามโทเค็นเป็นประจำ เพื่อให้โทเค็นเก่าที่ออกภายใต้ตรรกะการออกใบรับรองที่อาจไม่ถูกต้องนั้นหมดอายุ และเว็บไซต์ต่างๆ จะแลกสิทธิ์โทเค็นที่ใหม่กว่าพร้อมตรรกะการออกที่ได้รับการปรับปรุงใหม่
การส่งแบบฟอร์มในเว็บไซต์เดียวกัน	สามารถใช้โทเค็นสถานะส่วนตัวสำหรับการส่งแบบฟอร์มในเว็บไซต์เดียวกันที่เกี่ยวข้องกับการนำทางแบบเต็มหน้า (เช่น Content-Type: application/x-www-form-urlencrypted) แทนที่จะใช้คำขอจาก API การดึงข้อมูล/XMLHttpRequest ได้หรือไม่	ปัจจุบันโทเค็นสถานะส่วนตัวเวอร์ชันแรกยังไม่รองรับโทเค็นนี้ เรายินดีรับฟังความคิดเห็นจากระบบนิเวศหากมีความต้องการใช้งานสูงสำหรับ Use Case นี้
การยืนยันฝั่งเซิร์ฟเวอร์	คำถามที่ว่าโทเค็นสถานะส่วนตัวจะยืนยันในฝั่งเซิร์ฟเวอร์ได้หรือไม่	จะมีการแลกสิทธิ์โทเค็นให้กับผู้ออกบัตร จากนั้นผู้ออกบัตรจะสร้างระเบียนการแลกสิทธิ์ที่อาจมีตัวโทเค็นเองหรือค่าที่ลงนามแล้วบางส่วนที่ได้จากโทเค็น เซิร์ฟเวอร์จะใช้บันทึกการแลกสิทธิ์นั้นเพื่อยืนยันความถูกต้องของโทเค็น และเราคาดว่าระบบนิเวศของผู้ออกบัตรที่แตกต่างกันจะมีมาตรฐานที่แตกต่างกันสำหรับวิธีตีความบันทึกการแลกสิทธิ์