รายงานรายไตรมาสสําหรับไตรมาสที่ 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 ยังกังวลเกี่ยวกับข้อจำกัดต่อไปนี้ของข้อเสนอทางเลือกนี้
เนื่องจากมีการเพิ่มทางเลือกนี้ 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 นี้ |
การยืนยันฝั่งเซิร์ฟเวอร์ | คำถามที่ว่าโทเค็นสถานะส่วนตัวจะยืนยันในฝั่งเซิร์ฟเวอร์ได้หรือไม่ | จะมีการแลกสิทธิ์โทเค็นให้กับผู้ออกบัตร จากนั้นผู้ออกบัตรจะสร้างระเบียนการแลกสิทธิ์ที่อาจมีตัวโทเค็นเองหรือค่าที่ลงนามแล้วบางส่วนที่ได้จากโทเค็น เซิร์ฟเวอร์จะใช้บันทึกการแลกสิทธิ์นั้นเพื่อยืนยันความถูกต้องของโทเค็น และเราคาดว่าระบบนิเวศของผู้ออกบัตรที่แตกต่างกันจะมีมาตรฐานที่แตกต่างกันสำหรับวิธีตีความบันทึกการแลกสิทธิ์ |