ชุดโดเมนของบุคคลที่หนึ่ง (FPS) ออกแบบมาเพื่อรองรับประสบการณ์การท่องเว็บของผู้ใช้หลังจากที่เลิกใช้งานคุกกี้ของบุคคลที่สามใน Chrome ข้อเสนอนี้เปลี่ยนแปลงไปอย่างมากในฟอรัมเว็บแบบเปิดระหว่างการบ่มเพาะ FPS ซึ่งแรกเริ่มในกลุ่มชุมชนด้านความเป็นส่วนตัวของ W3C และตอนนี้อยู่ใน Web Incubator Community Group
ในบล็อกโพสต์นี้ เราจะสรุปกระบวนการวิวัฒนาการ ไฮไลต์การเปลี่ยนแปลงที่สำคัญ และพูดคุยถึงเหตุผลที่เราเชื่อว่าการเปลี่ยนแปลงดังกล่าวจะช่วยปรับปรุงความเป็นส่วนตัวบนเว็บ ขณะเดียวกันก็ยังคงสนับสนุนระบบนิเวศนี้ต่อไป
ที่มา
เว็บไซต์มักอาศัยการเข้าถึงคุกกี้ในบริบทของบุคคลที่สามเพื่อมอบประสบการณ์ที่ราบรื่นและเหมาะกับผู้ใช้ นอกจาก API โฆษณาที่รักษาความเป็นส่วนตัว (Topics, Protected Audience API และ Attribution) แล้ว ทีม Chrome ยังพยายามทำความเข้าใจขอบเขตของสถานการณ์ที่มีการใช้คุกกี้ของบุคคลที่สาม นอกเหนือจากการปรับเปลี่ยนโฆษณาในแบบของคุณหรือการวัด เพื่อมอบประสบการณ์การท่องเว็บที่ดีขึ้นให้แก่ผู้ใช้
เราพบว่าองค์กรต่างๆ อาจต้องใช้คุกกี้ของบุคคลที่สามเนื่องจากสถาปัตยกรรมเว็บขององค์กรนั้นออกแบบมาเพื่อใช้หลายโดเมน ตัวอย่างเช่น องค์กรอาจมีโดเมนหนึ่งสำหรับบล็อกการเดินป่าและอีกโดเมนหนึ่งสำหรับร้านขายการตั้งแคมป์ และต้องการสนับสนุนเส้นทางของผู้ใช้ในเว็บไซต์เหล่านั้น องค์กรหนึ่งยังอาจรักษาโดเมนรหัสประเทศหลายโดเมนที่มีโครงสร้างพื้นฐานร่วมกันสำหรับบริการเว็บของตน สำหรับกรณีเช่นนี้ เราได้คิดที่จะสร้างโซลูชันที่สอดคล้องกับความต้องการขององค์กรเหล่านั้น ขณะเดียวกันก็รักษาความคาดหวังของผู้ใช้เกี่ยวกับความเป็นส่วนตัวของตนบนเว็บ
จุดเริ่มต้น
เนื่องจากปัจจุบันเบราว์เซอร์ใช้ขอบเขตระดับเว็บไซต์เพื่อตีความ "บุคคลที่หนึ่ง" กับ "บุคคลที่สาม" เพื่ออธิบายช่วงของโดเมนที่องค์กรอาจจัดการ จึงดูเหมาะสมที่จะใช้คำจำกัดความที่ละเอียดยิ่งขึ้นแทนขอบเขตทางเทคนิคนี้
ในปี 2021 ในตอนแรก Chrome ได้เสนอแอตทริบิวต์คุกกี้ SameParty สำหรับชุดโดเมนของบุคคลที่หนึ่ง เพื่อให้เว็บไซต์กำหนดคุกกี้ที่มาจากเว็บไซต์ภายใน "ฝ่ายเดียวกัน" ได้ เราใช้นโยบาย User Agent เพื่อกำหนดสิ่งที่ถือเป็น "บุคคลเดียวกัน" คำนิยามนโยบายนี้พยายามสร้างขึ้นจากเฟรมเวิร์กที่มีอยู่ของ "ฝ่าย" (เช่น จากข้อกำหนด W3C DNT) และการรวมคำแนะนำจากการอภิปรายด้านความเป็นส่วนตัวที่เกี่ยวข้อง (เช่น รายงานของคณะกรรมาธิการการค้าของรัฐบาลกลางปี 2012 ที่มีชื่อว่า "การปกป้องความเป็นส่วนตัวของผู้บริโภคในยุคแห่งการเปลี่ยนแปลงอย่างรวดเร็ว")
ในตอนนั้น เรารู้สึกว่าวิธีการนี้มีความยืดหยุ่นเพียงพอสำหรับองค์กรประเภทต่างๆ ในอุตสาหกรรมต่างๆ ขณะเดียวกันก็ยังคงยึดมั่นในเป้าหมายพื้นฐานของเราในการลดการติดตามอย่างแพร่หลายผ่านคุกกี้ของบุคคลที่สาม
ความคิดเห็นเกี่ยวกับข้อเสนอเริ่มต้น
จากการสนทนาหลายครั้งกับผู้มีส่วนเกี่ยวข้องในระบบนิเวศของเว็บ เราพบว่าการออกแบบในระยะแรกนี้มีข้อจำกัด
ความท้าทายด้านความเป็นส่วนตัวด้วยการเข้าถึงคุกกี้แบบแพสซีฟผ่านแอตทริบิวต์ SameParty
ผู้ให้บริการเบราว์เซอร์อื่น ขอแนะนำวิธีแบบเชิงรุกสำหรับการเข้าถึงคุกกี้ของบุคคลที่สามซึ่งต้องมีการเรียกใช้ API ที่ชัดเจน แทนการสร้างขอบเขตที่สามารถเก็บรักษาการเข้าถึงคุกกี้แบบแพสซีฟได้ คำขอเข้าถึงคุกกี้ที่ใช้งานอยู่ช่วยให้เบราว์เซอร์เข้าถึงและควบคุมได้ เพื่อลดความเสี่ยงในการติดตามโดยไม่เปิดเผยตัวตนผ่านทางคุกกี้ของบุคคลที่สาม นอกจากนี้ ระดับการเข้าถึงนี้จะทำให้เบราว์เซอร์ให้ตัวเลือกแก่ผู้ใช้ในการอนุญาตหรือบล็อกการเข้าถึงคุกกี้ดังกล่าวด้วย
เพื่อมองหาความสามารถในการทำงานร่วมกันบนเว็บในเบราว์เซอร์ต่างๆ รวมถึงปรับปรุงประโยชน์ด้านความเป็นส่วนตัว เราจึงตัดสินใจไปในทิศทางนี้
ความท้าทายในการใช้งานเกี่ยวกับนโยบายที่เสนอ
นโยบายเดิมเสนอข้อกำหนด 3 ข้อสำหรับโดเมนที่จะอยู่ในชุดเดียว ได้แก่ "การเป็นเจ้าของร่วมกัน" "นโยบายความเป็นส่วนตัวทั่วไป" และ "อัตลักษณ์ของกลุ่มทั่วไป"
จากระบบนิเวศในวงกว้าง เราพบความคิดเห็นที่เราได้รับเกี่ยวกับนโยบายดังกล่าวเพื่อปฏิบัติตาม 4 ประเด็นหลัก
การเป็นเจ้าของร่วมกันมีข้อจำกัดมากเกินไป
สำหรับข้อกำหนด "การเป็นเจ้าของร่วมกัน" เราได้รับความคิดเห็นว่าคำจำกัดความของ FPS ที่มุ่งเน้นการเป็นเจ้าขององค์กรเพียงอย่างเดียวจะทำให้บริษัทขนาดใหญ่สามารถรวบรวมข้อมูลในโดเมนและบริการที่แสดงต่อผู้ใช้ที่หลากหลายได้มากกว่าเมื่อเทียบกับบริษัทขนาดเล็ก เนื่องจากเป้าหมายของเราคือการสร้าง Privacy Sandbox สำหรับระบบนิเวศโดยรวม เราจึงพิจารณาความคิดเห็นนี้อย่างจริงจังและให้ความสำคัญกับโซลูชันที่ครอบคลุมมากขึ้น
นโยบายเดียวจำกัดความสามารถในการขยายการใช้งานของ Use Case
แม้ว่าแนวคิดเกี่ยวกับนโยบายแบบองค์รวมเพื่อควบคุมขอบเขตมีวัตถุประสงค์เพื่อให้ความยืดหยุ่นต่อโดเมนประเภทต่างๆ ที่จำเป็นต้องใช้ใน FPS ขององค์กร เราพบว่ากรณีการใช้งานที่สำคัญบางกรณีไม่เป็นไปตามการออกแบบนโยบายนี้ ตัวอย่างเช่น โดเมนบริการ (เช่น โดเมนที่โฮสต์เนื้อหาที่ผู้ใช้สร้างขึ้น) อาจจำเป็นต้องมีสิทธิ์เข้าถึงคุกกี้ของตนในบริบทของบุคคลที่สามเพื่อตรวจสอบสิทธิ์หรือระบุตัวผู้ใช้ โดเมนดังกล่าวแทบไม่มีหน้าแรกที่ผู้ใช้เข้าถึงได้ ดังนั้นไม่เป็นไปตามข้อกำหนดของ "ข้อมูลประจำตัวของกลุ่มทั่วไป" หรือ "นโยบายความเป็นส่วนตัวทั่วไป" ที่มีโดเมนอื่นๆ ใน FPS เดียวกัน
การรับรู้และความเข้าใจของผู้ใช้เกี่ยวกับอัตลักษณ์ของกลุ่มอาจแตกต่างกัน
เดิมที เราได้เสนอแนวป้องกันเพื่อกำหนด "อัตลักษณ์ของกลุ่มทั่วไป" เพื่อพยายามกำหนดขอบเขตโดเมนภายในชุดเดียว ให้แก่โดเมนที่สามารถเชื่อมโยงกับอัตลักษณ์ของกลุ่มทั่วไปได้โดยง่าย อย่างไรก็ตาม เราไม่สามารถกำหนดวิธีการทางเทคนิคที่ใช้วัดและประเมินได้ว่าข้อมูลประจำตัวของกลุ่มทั่วไปนั้น "ผู้ใช้ค้นพบได้ง่าย" หรือไม่ วิธีนี้เปิดโอกาสให้เกิดการละเมิด และตอบคำถามเกี่ยวกับการบังคับใช้
นอกจากนี้ เรายังได้รับ ความคิดเห็นว่าการทำความเข้าใจความหมายของขอบเขต "การเป็นเจ้าของร่วมกัน" อาจแตกต่างกันไปตามผู้ใช้แต่ละราย จึงทำให้การสร้างหลักเกณฑ์ที่นำไปใช้ได้กับทุกเว็บไซต์เป็นเรื่องยาก
นโยบายที่เป็นความคิดเห็นนั้นบังคับใช้ในวงกว้างได้ยาก
เราได้รับคำขอจำนวนมากเกี่ยวกับหลักเกณฑ์โดยละเอียดโดยพิจารณาจากข้อกำหนดบางประการ (เช่น "อัตลักษณ์ของกลุ่มทั่วไป") และความจำเป็นที่จะต้องครอบคลุมข้อยกเว้นหรือกรณีที่เป็นปัญหาที่สุดสำหรับผู้อื่น (เกี่ยวกับ "นโยบายความเป็นส่วนตัวทั่วไป")
Chrome จะต้องระบุหลักเกณฑ์ที่เจาะจงมากขึ้นแก่ผู้เขียนเว็บไซต์เพื่อให้แน่ใจว่ามีการบังคับใช้นโยบายอย่างเท่าเทียมและสอดคล้องกัน เราพิจารณาแล้วว่าการพยายามสร้างหลักเกณฑ์ที่เข้มงวดขึ้นอาจเป็นผลเสียของระบบนิเวศนั้นๆ โดยเฉพาะ
ในตอนแรกเราเสนอให้หน่วยงานอิสระในการบังคับใช้รับบทบาทในการตรวจสอบและบังคับใช้นโยบาย แต่ในระบบนิเวศปัจจุบัน การหาหน่วยงานผู้บังคับใช้อิสระที่มีความเชี่ยวชาญที่เหมาะสมเพื่อทำงานเหล่านี้อย่างเป็นกลางเป็นเรื่องที่ท้าทาย เราจึงพยายามที่จะปรับเปลี่ยนนโยบายที่อาจนำมาบังคับใช้ทางเทคนิคได้ เพื่อให้แน่ใจว่าการใช้งานจะสอดคล้องกันและเป็นไปตามวัตถุประสงค์
วิวัฒนาการ
เราจึงได้ออกแบบ FPS ใหม่เพื่อเป็นการตอบสนองต่อความคิดเห็น เราได้ย้อนกลับไปที่ปัญหาเฉพาะที่เราพยายามแก้ไข และตัดสินใจที่จะกำหนดกรอบข้อเสนอในเรื่อง Use Case เฉพาะที่เรากำลังแก้ปัญหาให้โดยตรง
การแก้ไขปัญหาสำหรับกรณีการใช้งานที่สำคัญ
Chrome พัฒนา "ซับเซ็ต" ที่สร้างขึ้นเพื่อจุดประสงค์ต่างๆ กัน 3 แบบเพื่อให้ตรงตามกรณีการใช้งานหลักๆ บนเว็บ แนวทางของกลุ่มย่อยได้รับการปรับปรุงจากแนวทางเดิมโดยให้ความเป็นส่วนตัวมากขึ้น เจาะจงมากขึ้น และบังคับใช้ได้อย่างต่อเนื่องได้ง่ายขึ้น
- "ccTLD" (โดเมนระดับบนสุดที่ใช้รหัสประเทศ) - องค์กรอาจดูแลเว็บไซต์ที่มี ccTLD ต่างกันเพื่อประสบการณ์การใช้งานที่แปลแล้ว และเว็บไซต์เหล่านี้อาจยังต้องการเข้าถึงบริการและโครงสร้างพื้นฐานที่แชร์
- โดเมน "บริการ" - เว็บไซต์อาจใช้โดเมนแยกกันเพื่อวัตถุประสงค์ด้านความปลอดภัยหรือประสิทธิภาพ และเว็บไซต์เหล่านี้อาจจำเป็นต้องมีสิทธิ์เข้าถึงข้อมูลประจำตัวของผู้ใช้เพื่อดำเนินการต่างๆ
- โดเมนที่ "เชื่อมโยงแล้ว" — องค์กรอาจมีเว็บไซต์หลายเว็บสำหรับแบรนด์หรือผลิตภัณฑ์ที่แตกต่างกันและเกี่ยวข้องกัน ผู้ให้บริการอาจต้องการสิทธิ์เข้าถึงคุกกี้แบบข้ามเว็บไซต์สำหรับ 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 ได้โดยจำกัดความยุ่งยากของผู้ใช้และป้องกันไม่ให้ผู้ใช้รู้สึกเบื่อหน่ายกับกรณีการใช้งานหลักที่สำคัญ 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