ชุดโดเมนของบุคคลที่หนึ่ง (FPS) ออกแบบมาเพื่อรองรับประสบการณ์การท่องเว็บของผู้ใช้หลังจากการเลิกใช้งานคุกกี้ของบุคคลที่สามใน Chrome โปรเจ็กต์นี้พัฒนาไปอย่างมากในฟอรัมเว็บแบบเปิดในช่วงระยะบ่มเพาะของ FPS โดยเริ่มจากกลุ่มชุมชนด้านความเป็นส่วนตัวของ W3C และตอนนี้อยู่ในกลุ่มชุมชน Web Incubator
ในบล็อกโพสต์นี้ เราจะสรุปกระบวนการพัฒนา ชี้ให้เห็นการเปลี่ยนแปลงที่สำคัญ และอธิบายเหตุผลที่เราเชื่อว่าการเปลี่ยนแปลงดังกล่าวจะช่วยปรับปรุงความเป็นส่วนตัวบนเว็บไปพร้อมกับการรองรับระบบนิเวศต่อไป
ข้อมูลเบื้องต้น
เว็บไซต์มักอาศัยการเข้าถึงคุกกี้ในบริบทของบุคคลที่สามเพื่อมอบประสบการณ์การใช้งานที่ราบรื่นและปรับให้เหมาะกับผู้ใช้ นอกจากPrivacy Preserving Ads API (Topics, Protected Audience API และการระบุแหล่งที่มา) แล้ว ทีม Chrome ยังพยายามทําความเข้าใจขอบเขตของสถานการณ์ที่มีการใช้คุกกี้ของบุคคลที่สามนอกเหนือจากวัตถุประสงค์ในการปรับโฆษณาตามโปรไฟล์ของผู้ใช้หรือการวัดผล เพื่อมอบประสบการณ์การท่องเว็บที่ดีขึ้นให้แก่ผู้ใช้
เราพบว่าองค์กรอาจใช้คุกกี้ของบุคคลที่สามเนื่องจากสถาปัตยกรรมเว็บออกแบบมาเพื่อใช้หลายโดเมน ตัวอย่างเช่น องค์กรหนึ่งอาจมีโดเมนหนึ่งสําหรับบล็อกการเดินป่าและอีกโดเมนสําหรับร้านค้าขายอุปกรณ์แคมป์ปิ้ง และต้องการรองรับเส้นทางของผู้ใช้ในเว็บไซต์เหล่านั้น นอกจากนี้ องค์กรยังอาจดูแลรักษาโดเมนรหัสประเทศหลายรายการที่มีโครงสร้างพื้นฐานที่ใช้ร่วมกันสำหรับบริการบนเว็บได้ด้วย ในกรณีเช่นนี้ เรามุ่งมั่นที่จะสร้างโซลูชันที่สอดคล้องกับความต้องการขององค์กรดังกล่าว ในขณะเดียวกันก็รักษาความคาดหวังของผู้ใช้เกี่ยวกับความเป็นส่วนตัวบนเว็บไว้
จุดเริ่มต้น
เนื่องจากปัจจุบันเบราว์เซอร์ใช้ขอบเขตระดับเว็บไซต์ในการตีความ "บุคคลที่หนึ่ง" เทียบกับ "บุคคลที่สาม" เพื่อพิจารณาช่วงของโดเมนที่องค์กรอาจจัดการ จึงดูเหมือนว่าควรแทนที่ขอบเขตทางเทคนิคนี้ด้วยคําจํากัดความที่ละเอียดยิ่งขึ้น
ในปี 2021 ทาง Chrome ได้เสนอแอตทริบิวต์คุกกี้ SameParty สำหรับชุดบุคคลที่หนึ่งเพื่อให้เว็บไซต์กำหนดคุกกี้ที่มาจากเว็บไซต์ภายใน "บุคคลเดียวกัน" ได้ เราใช้นโยบาย User Agent เพื่อกำหนดสิ่งที่จะถือเป็น "บุคคลเดียวกัน" คําจํากัดความของนโยบายนี้พยายามที่จะต่อยอดจากเฟรมเวิร์กที่มีอยู่ของ "บุคคล" (เช่น จากข้อกําหนด DNT ของ W3C) และรวมคําแนะนําจากการสนทนาเรื่องความเป็นส่วนตัวที่เกี่ยวข้อง (เช่น รายงานของคณะกรรมการกํากับดูแลการค้าของรัฐบาลกลางปี 2012 ที่มีชื่อว่า"การปกป้องความเป็นส่วนตัวของผู้บริโภคในยุคที่มีการเปลี่ยนแปลงอย่างรวดเร็ว")
ในขณะนั้น เรารู้สึกว่าแนวทางนี้มีความยืดหยุ่นเพียงพอสําหรับองค์กรประเภทต่างๆ ในอุตสาหกรรมต่างๆ ทั้งยังสอดคล้องกับเป้าหมายพื้นฐานของเราในการลดการติดตามในวงกว้างผ่านคุกกี้ของบุคคลที่สาม
ความคิดเห็นเกี่ยวกับข้อเสนอเริ่มต้น
จากการพูดคุยกับผู้มีส่วนเกี่ยวข้องในระบบนิเวศของเว็บหลายครั้ง เราพบว่าการออกแบบเริ่มต้นนี้มีข้อจำกัด
ปัญหาด้านความเป็นส่วนตัวเกี่ยวกับการเข้าถึงคุกกี้แบบพาสซีฟผ่านแอตทริบิวต์ SameParty
ผู้ให้บริการเบราว์เซอร์รายอื่นๆ ต้องการใช้แนวทางแบบแอ็กทีฟในการเข้าถึงคุกกี้ของบุคคลที่สาม ซึ่งต้องมีการเรียกใช้ API อย่างชัดแจ้ง แทนที่จะกำหนดขอบเขตที่อาจมีการเข้าถึงคุกกี้แบบพาสซีฟ คําขอเข้าถึงคุกกี้ที่ใช้งานอยู่จะแสดงและควบคุมเบราว์เซอร์ได้ เพื่อลดความเสี่ยงในการติดตามแบบซ่อนเร้นผ่านคุกกี้ของบุคคลที่สาม นอกจากนี้ การแสดงผลนี้จะอนุญาตให้เบราว์เซอร์ให้ตัวเลือกแก่ผู้ใช้ในการอนุญาตหรือบล็อกการเข้าถึงคุกกี้ดังกล่าว
เราตัดสินใจที่จะดำเนินการไปในทิศทางนี้เพื่อประโยชน์ในการทำให้เว็บทำงานร่วมกันได้ระหว่างเบราว์เซอร์ต่างๆ รวมถึงเพื่อปรับปรุงสิทธิประโยชน์ด้านความเป็นส่วนตัว
ปัญหาการติดตั้งใช้งานนโยบายที่เสนอ
นโยบายฉบับเดิมเสนอข้อกำหนด 3 ข้อสำหรับโดเมนที่อยู่ในชุดเดียวกัน ได้แก่ "การเป็นเจ้าของร่วมกัน" "นโยบายความเป็นส่วนตัวเดียวกัน" และ "ข้อมูลประจำตัวกลุ่มเดียวกัน"
จากระบบนิเวศที่กว้างขึ้น เราพบว่าความคิดเห็นที่ได้รับเกี่ยวกับนโยบายนี้มุ่งเน้นไปที่ 4 หัวข้อหลัก
การเป็นเจ้าของร่วมกันมีข้อจํากัดมากเกินไป
เกี่ยวกับข้อกำหนด "การเป็นเจ้าของร่วมกัน" เราได้รับความคิดเห็นว่าคำจำกัดความของ FPS ที่มุ่งเน้นที่การเป็นเจ้าของของบริษัทเพียงอย่างเดียวจะทำให้บริษัทขนาดใหญ่มีความสามารถในการรวบรวมข้อมูลจากโดเมนและบริการที่แสดงต่อผู้ใช้ได้มากขึ้นเมื่อเทียบกับบริษัทขนาดเล็ก เนื่องจากเป้าหมายของเราคือการทำให้ Privacy Sandbox ใช้งานได้กับทั้งระบบนิเวศ เราจึงให้ความสำคัญกับความคิดเห็นนี้และให้ความสําคัญกับโซลูชันที่ครอบคลุมมากขึ้น
นโยบายเดียวจะจํากัดการขยายไปยังกรณีการใช้งาน
แม้ว่าแนวคิดของนโยบายแบบองค์รวมที่จะควบคุมขอบเขตมีจุดประสงค์เพื่อมอบความยืดหยุ่นให้กับโดเมนประเภทต่างๆ ที่ต้องอยู่ใน FPS ขององค์กร แต่เราพบว่า Use Case ที่สำคัญบางรายการไม่เป็นไปตามการออกแบบนโยบายนี้ ตัวอย่างเช่น โดเมนบริการ (เช่น โดเมนที่โฮสต์เนื้อหาที่ผู้ใช้สร้างขึ้น) อาจต้องเข้าถึงคุกกี้ในบริบทของบุคคลที่สามเพื่อตรวจสอบสิทธิ์หรือระบุตัวตนผู้ใช้ โดเมนดังกล่าวไม่ค่อยมีหน้าแรกที่ผู้ใช้เข้าถึงได้ จึงไม่สามารถปฏิบัติตามข้อกำหนดของ "ตัวตนกลุ่มเดียวกัน" หรือ "นโยบายความเป็นส่วนตัวเดียวกัน" กับโดเมนอื่นๆ ใน FPS เดียวกัน
มุมมองและความเข้าใจในอัตลักษณ์ของกลุ่มของผู้ใช้อาจแตกต่างกัน
เดิมเราเสนอขอบเขตเพื่อกําหนด "ตัวระบุกลุ่มที่พบบ่อย" เพื่อเป็นการพยายามกําหนดขอบเขตโดเมนภายในชุดเดียวให้อยู่ในรูปแบบที่เชื่อมโยงกับตัวระบุกลุ่มที่พบบ่อยได้ อย่างไรก็ตาม เราไม่สามารถกําหนดวิธีทางเทคนิคในการวัดและประเมินว่าผู้ใช้จะ "ค้นพบตัวตนกลุ่มที่พบบ่อย" ได้หรือไม่ ซึ่งอาจทำให้เกิดปัญหาการละเมิดและข้อสงสัยเกี่ยวกับการบังคับใช้
นอกจากนี้ เรายังได้รับ ความคิดเห็นว่าความเข้าใจความหมายของขอบเขต "การเป็นเจ้าของร่วมกัน" อาจแตกต่างกันไปในแต่ละผู้ใช้ ซึ่งทำให้การสร้างหลักเกณฑ์ที่ใช้กับทุกเว็บไซต์ได้นั้นเป็นเรื่องยาก
นโยบายที่ขึ้นอยู่กับความคิดเห็นเป็นเรื่องยากที่จะบังคับใช้ในวงกว้าง
เราได้รับคำขอจำนวนมากที่ต้องการทราบหลักเกณฑ์โดยละเอียดยิ่งขึ้น เนื่องจากข้อกำหนดบางอย่างมีลักษณะเป็นอัตวิสัย (เช่น "ตัวตนกลุ่มทั่วไป") และจำเป็นต้องครอบคลุมถึงข้อยกเว้นหรือกรณีพิเศษสำหรับข้อกำหนดอื่นๆ (เกี่ยวกับ "นโยบายความเป็นส่วนตัวทั่วไป")
Chrome จำเป็นต้องจัดทำหลักเกณฑ์ที่เฉพาะเจาะจงมากขึ้นให้แก่ผู้เขียนเว็บไซต์ เพื่อให้มั่นใจว่านโยบายจะมีผลบังคับใช้อย่างเท่าเทียมและสม่ำเสมอ เราพิจารณาแล้วว่าความพยายามที่จะสร้างหลักเกณฑ์ที่เข้มงวดขึ้นอาจส่งผลเสียต่อระบบนิเวศ
แม้ว่าในตอนแรกเราจะเสนอให้หน่วยงานบังคับใช้อิสระรับบทบาทในการตรวจสอบและการบังคับใช้การปฏิบัติตามนโยบาย แต่การค้นหาหน่วยงานบังคับใช้อิสระที่มีความเชี่ยวชาญที่เหมาะสมเพื่อทำหน้าที่เหล่านี้อย่างเป็นกลางนั้นเป็นเรื่องยากในระบบนิเวศปัจจุบัน แต่เราพยายามเปลี่ยนมาใช้นโยบายที่บังคับใช้ได้ทางเทคนิคเพื่อให้มั่นใจว่าการใช้งานจะมีความสอดคล้องและเป็นกลาง
วิวัฒนาการ
เราออกแบบ FPS ใหม่ตามความคิดเห็นที่ได้รับ เรากลับไปที่ปัญหาเฉพาะเจาะจงที่เราพยายามแก้ไข และตัดสินใจที่จะจัดเฟรมข้อเสนอให้ตรงกับกรณีการใช้งานที่เฉพาะเจาะจงมากขึ้น
การแก้ปัญหาสำหรับกรณีการใช้งานหลัก
Chrome ได้พัฒนา "ชุดย่อย" 3 ชุดที่แตกต่างกันโดยเฉพาะเพื่อรองรับกรณีการใช้งานหลักๆ บนเว็บ แนวทางนี้ปรับปรุงจากแนวทางเดิมให้มีความเป็นส่วนตัวมากขึ้น เฉพาะเจาะจงมากขึ้น และบังคับใช้อย่างสม่ำเสมอได้ง่ายขึ้น
- "ccTLD" (โดเมนระดับบนสุดตามรหัสประเทศ) — องค์กรอาจดูแลรักษาเว็บไซต์ที่มี ccTLD ต่างกันเพื่อประสบการณ์การใช้งานที่แปลแล้ว และเว็บไซต์เหล่านี้อาจยังคงต้องใช้การเข้าถึงบริการและโครงสร้างพื้นฐานที่แชร์
- โดเมน "บริการ" - เว็บไซต์อาจใช้โดเมนแยกต่างหากเพื่อวัตถุประสงค์ด้านความปลอดภัยหรือประสิทธิภาพ และเว็บไซต์เหล่านี้อาจต้องเข้าถึงข้อมูลประจำตัวของผู้ใช้เพื่อดำเนินการตามฟังก์ชันการทำงาน
- โดเมนที่ "เชื่อมโยง" - องค์กรอาจดูแลรักษาเว็บไซต์หลายแห่งสําหรับแบรนด์หรือผลิตภัณฑ์ที่เกี่ยวข้องแต่แตกต่างกัน ผู้ใช้อาจต้องการสิทธิ์เข้าถึงคุกกี้ข้ามเว็บไซต์สําหรับกรณีการใช้งาน เช่น ข้อมูลวิเคราะห์เส้นทางของผู้ใช้ในเว็บไซต์ที่เกี่ยวข้อง เพื่อให้เข้าใจได้ดียิ่งขึ้นว่าฐานผู้ใช้ขององค์กรโต้ตอบกับเว็บไซต์อย่างไร หรือเพื่อจดจําสถานะการเข้าสู่ระบบของผู้ใช้บนเว็บไซต์ที่เกี่ยวข้องซึ่งใช้โครงสร้างพื้นฐานการเข้าสู่ระบบเดียวกัน
สำหรับ Use Case แต่ละรายการเหล่านี้ มีข้อกำหนดด้านนโยบายที่แยกต่างหาก การตรวจสอบความถูกต้องทางเทคนิคที่เกี่ยวข้อง และลักษณะการทํางานเฉพาะของการจัดการเบราว์เซอร์ (ดูข้อมูลเพิ่มเติมได้ที่หลักเกณฑ์การส่ง) การเปลี่ยนแปลงเหล่านี้ช่วยแก้ไขข้อจำกัดในข้อเสนอฉบับแรกด้วยการเลิกใช้การออกแบบแบบ "ใช้กับทุกกรณี" และหันมาใช้เฟรมเวิร์กแบบแยกส่วนซึ่งขับเคลื่อนโดย Use Case
โอกาสในการทํางานร่วมกันผ่านคําขอที่ใช้งานอยู่สําหรับสิทธิ์เข้าถึงคุกกี้ของบุคคลที่สาม
Chrome มุ่งส่งเสริมการทำงานร่วมกันกับเบราว์เซอร์อื่นๆ เพื่อรักษาเสถียรภาพของแพลตฟอร์มเว็บ เนื่องจากปัจจุบันเบราว์เซอร์อื่นๆ เช่น Safari, Firefox และ Edge ใช้ Storage Access API (SAA) เพื่ออำนวยความสะดวกในคำขอคุกกี้ที่ใช้งานอยู่ เราจึงเลือกใช้ SAA ใน Chrome เพื่อไม่เพียงแต่ช่วยจัดการกับความคิดเห็นสำคัญที่ได้รับ แต่ยังเพื่อรองรับการทำงานร่วมกันของเว็บด้วย
เรายังได้เสนอ requestStorageAccessForOrigin API เพื่อให้นักพัฒนาแอปมีความยืดหยุ่นมากขึ้นและจัดการกับข้อจำกัดที่ทราบของ SAA
โอกาสในการใช้ Storage Access API และ FPS ร่วมกัน
เมื่อใช้ Storage Access API (SAA) เบราว์เซอร์อาจเลือกที่จะขอสิทธิ์จากผู้ใช้โดยตรง และเบราว์เซอร์อื่นๆ อาจเลือกที่จะอนุญาตคำขอจํานวนจํากัดโดยไม่แสดงข้อความแจ้งสิทธิ์
Chrome เชื่อว่า FPS จะเป็นเลเยอร์แบบโปร่งใสเหนือ SAA โดยจำกัดการขัดข้องของผู้ใช้และป้องกันไม่ให้ผู้ใช้เบื่อพรอมต์สำหรับ Use Case หลักแบบจํากัด FPS ยังช่วยให้เบราว์เซอร์มีความยืดหยุ่นในการให้บริบทเพิ่มเติมแก่ผู้ใช้เกี่ยวกับการเป็นสมาชิกที่กำหนดไว้ หากเลือกที่จะแจ้งให้ผู้ใช้ขอสิทธิ์
FPS ช่วยให้นักพัฒนาแอประบุเว็บไซต์ของตนเองที่ได้รับผลกระทบซึ่งให้บริการกรณีการใช้งานหลักได้ ซึ่งช่วยให้เอเจนซีคาดการณ์ได้ว่าเว็บไซต์จะทํางานอย่างไรสําหรับผู้ใช้ และนํามาตรการต่างๆ มาใช้เพื่อจํากัดผลกระทบต่อประสบการณ์ของผู้ใช้ โดยใช้ FPS หรือคุกกี้ของบุคคลที่สามแทน นอกจากนี้ FPS ยังช่วยให้นักพัฒนาแอปคาดการณ์แพลตฟอร์มได้ ซึ่งต่างจากวิธีการเฮิวริสติกที่อาจเปลี่ยนแปลงเมื่อเวลาผ่านไป หรือทําให้ผู้ใช้แต่ละรายมีพฤติกรรมแตกต่างกัน
สุดท้ายนี้ นักพัฒนาซอฟต์แวร์ที่ใช้ SAA เพื่อทำงานร่วมกับ FPS ใน Chrome จะใช้ประโยชน์จาก SAA เพื่อเพิ่มประสิทธิภาพของเว็บไซต์ในเบราว์เซอร์อื่นๆ ได้ด้วย แม้กระทั่งเบราว์เซอร์ที่ไม่ได้ให้บริการ FPS
การอภิปรายต่อ
เราเชื่อว่าข้อเสนอล่าสุดของเราสร้างสมดุลที่เหมาะสมในจุดที่ต้องมีการแลกเปลี่ยนที่ท้าทายซึ่งพิจารณาถึงความต้องการของผู้ใช้และนักพัฒนาแอป ขอขอบคุณความคิดเห็นที่ได้รับจากผู้มีส่วนเกี่ยวข้องในระบบนิเวศของเว็บซึ่งช่วยให้เราพัฒนาข้อเสนอ FPS ได้
เราตระหนักดีว่าผู้มีส่วนเกี่ยวข้องในระบบนิเวศของเว็บยังคงทำความคุ้นเคยกับข้อเสนอฉบับปรับปรุง โปรดมีส่วนร่วมกับเราเพื่อให้เราปรับปรุงการออกแบบต่อไปในลักษณะที่เป็นประโยชน์ต่อนักพัฒนาแอปมากขึ้นและปรับปรุงความเป็นส่วนตัวบนเว็บต่อไป นอกจากนี้ Google จะยังคงทำงานร่วมกับหน่วยงานกำกับดูแลการแข่งขันและการตลาด (CMA) ของสหราชอาณาจักรเพื่อให้แน่ใจว่าเป็นไปตามความมุ่งมั่น
หากต้องการมีส่วนร่วม โปรดดูแหล่งข้อมูลต่อไปนี้
การทำงานกับระบบนิเวศ
เรายินดีที่ได้เห็นบริษัทอย่าง Salesforce และ CafeMedia มีส่วนร่วมในการแสดงความคิดเห็นและการพัฒนาชุดข้อมูลของบุคคลที่หนึ่ง บุคคลเหล่านี้มีส่วนสำคัญในการพัฒนาเทคโนโลยี ผู้ใช้อีกหลายรายได้แชร์ความคิดเห็นเกี่ยวกับชุดของบุคคลที่หนึ่งและความพยายามของ Chrome ในการทำงานร่วมกับระบบนิเวศของเว็บด้วย
"Chrome กำลังพัฒนาชุดของบุคคลที่หนึ่งให้สอดคล้องกับกรณีการใช้งานจำนวนมาก เช่น การคงเส้นทางของผู้ใช้ไว้ สิ่งนี้แสดงให้เห็นว่าทีม Google พยายามทำความเข้าใจความต้องการประเภทต่างๆ ของเจ้าของเว็บไซต์ในเว็บ" - Mercado Libre
"ที่ VWO เราขอขอบคุณความพยายามของ Google ในการยกระดับมาตรฐานความเป็นส่วนตัว พร้อมทั้งดูแล Use Case จริง เราดีใจที่เห็นทีมทํางานร่วมกับระบบนิเวศของนักพัฒนาซอฟต์แวร์ และปรับปรุงการใช้งานข้อเสนอชุดของบุคคลที่หนึ่งอย่างต่อเนื่องตามความคิดเห็นจากผู้มีส่วนเกี่ยวข้องในเว็บ เรายินดีที่ได้เป็นส่วนหนึ่งของเส้นทางการทดสอบข้อเสนอนี้และหวังว่าจะได้ผสานรวมข้อเสนอดังกล่าวไว้ในเบราว์เซอร์" - Nitish Mittal ผู้อำนวยการฝ่ายวิศวกรรมของ VWO