องค์กรจำนวนมากมีเว็บไซต์ที่เกี่ยวข้องซึ่งมีชื่อโดเมนต่างกัน เช่น brandx.site และ fly-brandx.site หรือโดเมนสำหรับแต่ละประเทศ เช่น example.com, example.rs, example.co.uk เป็นต้น
เบราว์เซอร์กำลังมุ่งสู่การทำให้คุกกี้ของบุคคลที่สามล้าสมัยเพื่อปรับปรุงความเป็นส่วนตัวในเว็บ แต่เว็บไซต์เหล่านี้มักอาศัยคุกกี้สำหรับฟังก์ชันการทำงานที่จำเป็นต้องดูแลรักษาและเข้าถึงสถานะในโดเมนต่างๆ (เช่น การลงชื่อเพียงครั้งเดียวและการจัดการความยินยอม)
ชุดโดเมนของบุคคลที่หนึ่งสามารถทำให้ชื่อโดเมนที่เกี่ยวข้องซึ่งบุคคลเดียวกันเป็นเจ้าของและดำเนินการเองได้รับการปฏิบัติเหมือนเป็นบุคคลที่หนึ่งในกรณีที่บุคคลที่หนึ่งและบุคคลที่สามได้รับการปฏิบัติต่างกัน ชื่อโดเมนภายในชุดบุคคลที่หนึ่งจะถือเป็นบุคคลเดียวกัน และสามารถติดป้ายกำกับได้ว่าคุกกี้ใดที่ตั้งใจจะตั้งค่าหรือส่งในบริบทของบุคคลที่หนึ่ง เป้าหมายคือการหาจุดสมดุลระหว่างการป้องกันการติดตามข้ามเว็บไซต์โดยบุคคลที่สามโดยที่ยังรักษาเส้นทางที่ไม่กระทบต่อกรณีการใช้งานที่ถูกต้อง
ขณะนี้ข้อเสนอชุดโดเมนของบุคคลที่หนึ่งยังอยู่ในระยะทดสอบ โปรดอ่านต่อเพื่อดูวิธีการใช้งานและวิธีทดลองใช้
คุกกี้ของบุคคลที่หนึ่งและบุคคลที่สามแตกต่างกันอย่างไร
คุกกี้ไม่ใช่บุคคลที่หนึ่งหรือบุคคลที่สามโดยพื้นฐาน แต่จะขึ้นอยู่กับบริบทปัจจุบันที่มีคุกกี้นั้นรวมอยู่ด้วย ซึ่งอยู่ในคำขอในส่วนหัว cookie หรือผ่าน document.cookie ใน JavaScript
ตัวอย่างเช่น หาก video.site มีคุกกี้ theme=dark เมื่อคุณท่องเว็บ video.site และส่งคำขอไปยัง video.site จะถือว่าเป็นบริบทเว็บไซต์เดียวกันและคุกกี้ที่รวมไว้ด้วยคือบุคคลที่หนึ่ง
อย่างไรก็ตาม หากคุณใช้ my-blog.site ซึ่งฝังโปรแกรมเล่น iframe สำหรับ video.site เมื่อมีการส่งคำขอจาก my-blog.site ไปยัง video.site บริบทแบบข้ามเว็บไซต์และคุกกี้ theme เป็นบุคคลที่สาม
การรวมคุกกี้จะกำหนดโดยแอตทริบิวต์ SameSite ของคุกกี้ ดังนี้
- บริบทของเว็บไซต์เดียวกันที่มี
SameSite=Lax,StrictหรือNoneทำให้คุกกี้เป็นบุคคลที่หนึ่ง - บริบทแบบข้ามเว็บไซต์ด้วย
SameSite=Noneจะทำให้คุกกี้เป็นบุคคลที่สาม
แต่ภาพนี้ก็ไม่ได้ชัดเจนเสมอไป สมมติว่า brandx.site เป็นเว็บไซต์จองการเดินทาง ซึ่งใช้ fly-brandx.site และ drive-brandx.site เพื่อแยกเที่ยวบินและการเช่ารถด้วย ตลอดระยะเวลาการจองเส้นทางหนึ่ง ผู้เข้าชมจะไปยังแต่ละไซต์เพื่อเลือกตัวเลือกต่างๆ โดยคาดว่า "รถเข็นช็อปปิ้ง" ที่เลือกจะยังคงอยู่บนเว็บไซต์เหล่านี้ brandx.site จัดการเซสชันของผู้ใช้ด้วยคุกกี้ SameSite=None เพื่ออนุญาตในบริบทแบบข้ามเว็บไซต์ ข้อเสียก็คือตอนนี้คุกกี้ไม่มีการปกป้อง Cross SiteRequest Forgery (CSRF) หาก evil.site มีคำขอไปยัง brandx.site คำขอจะรวมคุกกี้นั้นด้วย
คุกกี้เป็นแบบข้ามเว็บไซต์ แต่เว็บไซต์เหล่านั้นทั้งหมดมีองค์กรเดียวกันเป็นเจ้าของและดำเนินการเอง ผู้เข้าชมยังเข้าใจว่าองค์กรนี้เป็นองค์กรเดียวกัน และต้องการเซสชันเดียวกัน หรือก็คือตัวตนที่ใช้ร่วมกันนั่นเอง ระหว่างทั้งสององค์กร
นโยบายชุดโดเมนของบุคคลที่หนึ่ง
ชุดโดเมนของบุคคลที่หนึ่งเสนอวิธีการกำหนดความสัมพันธ์นี้อย่างชัดแจ้งในหลายๆ เว็บไซต์ที่มีเจ้าของและดำเนินการเอง การดำเนินการนี้จะช่วยให้ brandx.site กำหนดความสัมพันธ์ของบุคคลที่หนึ่งกับ fly-brandx.site, drive-brandx.site และอื่นๆ ได้
โมเดลความเป็นส่วนตัวที่ขับเคลื่อนข้อเสนอ Privacy Sandbox ที่หลากหลายนั้นอิงตามแนวคิดในการแบ่งพาร์ติชันข้อมูลประจำตัวเพื่อป้องกันการติดตามข้ามเว็บไซต์ ซึ่งเป็นการกำหนดขอบเขตระหว่างเว็บไซต์ที่จำกัดการเข้าถึงข้อมูลที่ใช้ระบุผู้ใช้ได้
แม้ว่าตัวเลือกเริ่มต้นคือการแบ่งพาร์ติชันตามเว็บไซต์ ซึ่งจะแก้ไข Use Case ของบุคคลที่หนึ่งจำนวนมาก แต่ตัวอย่าง brandx.site แสดงให้เห็นว่าบุคคลที่หนึ่งอาจมีขนาดใหญ่กว่าเว็บไซต์เพียงเว็บไซต์เดียวได้
ส่วนสำคัญของข้อเสนอชุดโดเมนของบุคคลที่หนึ่งคือตรวจสอบว่านโยบายสำหรับเบราว์เซอร์ต่างๆ ป้องกันการละเมิดหรือการใช้ในทางที่ผิด ตัวอย่างเช่น ชุดโดเมนของบุคคลที่หนึ่งต้องไม่ทำให้เกิดการแลกเปลี่ยนข้อมูลผู้ใช้ข้ามเว็บไซต์ที่ไม่เกี่ยวข้อง หรือการรวมกลุ่มเว็บไซต์ที่ไม่ได้เป็นของเอนทิตีเดียวกัน แนวคิดก็คือเพื่อให้มั่นใจว่าชุดโดเมนของบุคคลที่หนึ่งจะแมปกับสิ่งที่ผู้คนเข้าใจว่าเป็นบุคคลที่หนึ่ง และไม่ได้นำไปใช้เป็นวิธีแชร์ตัวตนระหว่างฝ่ายต่างๆ
วิธีหนึ่งที่เว็บไซต์จะลงทะเบียนชุดบุคคลที่หนึ่งได้คือการให้เว็บไซต์ส่งกลุ่มโดเมนที่เสนอไปยังตัวติดตามสาธารณะ (เช่น ที่เก็บ GitHub โดยเฉพาะ) พร้อมกับข้อมูลที่จำเป็นต่อการปฏิบัติตามนโยบายเบราว์เซอร์
เมื่อการยืนยันสิทธิ์บุคคลที่หนึ่งได้รับการยืนยันตามนโยบายแล้ว เบราว์เซอร์อาจดึงข้อมูลรายการชุดผ่านกระบวนการอัปเดต
ช่วงทดลองใช้จากต้นทางมีนโยบายที่กำหนดไว้ซึ่งยังไม่สิ้นสุด แต่หลักการมีแนวโน้มที่จะยังคงเหมือนเดิม ดังนี้
- โดเมนในชุดบุคคลที่หนึ่งต้องเป็นองค์กรเดียวกันและเป็นเจ้าของและดำเนินการเอง
- ผู้ใช้ควรรู้จักโดเมนเป็นกลุ่ม
- โดเมนต่างๆ ควรใช้นโยบายความเป็นส่วนตัวร่วมกัน
วิธีกำหนดชุดโดเมนของบุคคลที่หนึ่ง
เมื่อคุณระบุสมาชิกและเจ้าของกลุ่มบุคคลที่หนึ่งขององค์กรแล้ว ขั้นตอนสำคัญคือการส่งชุดที่คุณเสนอเพื่อขออนุมัติ ขั้นตอนที่แน่นอนยังอยู่ระหว่างหารือ
หากต้องการประกาศชุดบุคคลที่หนึ่ง ทรัพยากร JSON แบบคงที่ที่แสดงสมาชิกและเจ้าของควรโฮสต์ที่ /.well-known/first-party-set ที่ระดับบนสุดของแต่ละโดเมนที่รวมไว้
ในตัวอย่างชุดโดเมนของบุคคลที่หนึ่ง brandx โดเมนที่เป็นเจ้าของโฮสต์สิ่งต่อไปนี้ที่ https://brandx.site/.well-known/first-party-set
{
"owner": "brandx.site",
"version": 1,
"members": ["fly-brandx.site", "drive-brandx.site"]
}
สมาชิกแต่ละคนของชุดยังโฮสต์ทรัพยากร JSON แบบคงที่ซึ่งชี้กลับไปที่เจ้าของชุดด้วย
ที่ https://fly-brandx.site/.well-known/first-party-set เรามี:
{ "owner": "brandx.site" }
และที่ https://drive-brandx.site/.well-known/first-party-set:
{ "owner": "brandx.site" }
ชุดของบุคคลที่หนึ่งจะมีข้อจำกัดบางประการดังนี้
- ชุดหนึ่งๆ มีเจ้าของได้เพียงรายเดียว
- สมาชิก 1 คนต้องอยู่ในชุดเดียวเท่านั้น ห้ามซ้อนทับหรือปะปนกัน
- รายชื่อสมาชิกมีไว้เพื่อให้มนุษย์อ่านเข้าใจได้ไม่มากจนเกินไป
ชุดโดเมนของบุคคลที่หนึ่งส่งผลต่อคุกกี้อย่างไร
ส่วนผสมที่ตรงกันสำหรับคุกกี้คือแอตทริบิวต์ SameParty ที่เสนอ การระบุ SameParty จะบอกให้เบราว์เซอร์รวมคุกกี้เมื่อบริบทเป็นส่วนหนึ่งของชุดบุคคลที่หนึ่งเดียวกันกับบริบทระดับบนสุด
ซึ่งหมายความว่าหาก brandx.site ตั้งค่าคุกกี้นี้
Set-Cookie: session=123; Secure; SameSite=Lax; SameParty
จากนั้นเมื่อผู้เข้าชมอยู่ใน fly-brandx.site และมีการส่งคำขอไปที่ brandx.site คุกกี้ session จะรวมอยู่ในคำขอนั้น
หากเว็บไซต์อื่นที่ไม่ได้เป็นส่วนหนึ่งของชุดบุคคลที่หนึ่ง เช่น hotel.xyz ส่งคําขอไปยัง brandx.site ระบบจะไม่รวมคุกกี้นั้น
จนกว่า SameParty จะได้รับการรองรับอย่างกว้างขวาง ให้ใช้แอตทริบิวต์ SameSite ร่วมกับแอตทริบิวต์นั้น เพื่อกำหนดลักษณะการทำงานสำรองสำหรับคุกกี้ อาจมีแอตทริบิวต์ SameParty เป็นการตั้งค่าระหว่าง SameSite=Lax ถึง SameSite=None
SameSite=Lax; SamePartyจะขยายฟังก์ชันLaxให้รวมบริบทของบุคคลเดียวกันในกรณีที่รองรับ แต่จะกลับมาอยู่ภายใต้ข้อจำกัดLaxหากไม่SameSite=None; SamePartyจะจำกัดฟังก์ชันการทำงานของNoneให้เข้าถึงเฉพาะบริบทของบุคคลเดียวกันในกรณีที่ระบบรองรับเท่านั้น แต่จะกลับไปใช้สิทธิ์Noneที่มีขอบเขตกว้างกว่าแทน
โดยมีข้อกำหนดเพิ่มเติมดังนี้
- คุกกี้
SamePartyต้องมีSecure - คุกกี้
SamePartyต้องไม่มีSameSite=Strict
มีการกำหนดให้ Secure ดำเนินการเนื่องจากเรื่องนี้ยังคงเป็นแบบข้ามเว็บไซต์และคุณควรลดความเสี่ยงเหล่านั้นด้วยการดูแลให้การเชื่อมต่อ (HTTPS) ปลอดภัย ในทำนองเดียวกัน เนื่องจากนี่เป็นความสัมพันธ์แบบข้ามเว็บไซต์ SameSite=Strict จึงไม่ถูกต้องเนื่องจากยังอนุญาตให้มีการป้องกัน CSRF แบบอิงตามเว็บไซต์อย่างเข้มงวดภายในชุดหนึ่งๆ
กรณีการใช้งานใดเหมาะกับชุดโดเมนของบุคคลที่หนึ่ง
ชุดโดเมนของบุคคลที่หนึ่งเหมาะสำหรับกรณีที่องค์กรต้องการรูปแบบข้อมูลระบุตัวตนที่ใช้ร่วมกันในเว็บไซต์ระดับบนสุดต่างๆ ข้อมูลประจำตัวที่ใช้ร่วมกันในกรณีนี้หมายถึงอะไรก็ได้ ตั้งแต่โซลูชันการลงชื่อเพียงครั้งเดียวแบบสมบูรณ์ ไปจนถึงเพียงความต้องการร่วมกันระหว่างเว็บไซต์
องค์กรของคุณอาจมีโดเมนระดับบนสุดแตกต่างกันสำหรับรายการต่อไปนี้
- โดเมนของแอป:
office.com,live.com,microsoft.com - โดเมนที่มีแบรนด์:
amazon.com,audible.com/disney.com,pixar.com - โดเมนเฉพาะประเทศเพื่อเปิดใช้การแปล:
google.co.in,google.co.uk - โดเมนบริการที่ผู้ใช้ไม่เคยโต้ตอบด้วยโดยตรง แต่ให้บริการในเว็บไซต์ขององค์กรเดียวกัน ได้แก่
gstatic.com,githubassets.com,fbcdn.net - โดเมนแซนด์บ็อกซ์ที่ผู้ใช้ไม่เคยโต้ตอบด้วยโดยตรง แต่สร้างขึ้นด้วยเหตุผลด้านความปลอดภัย ได้แก่
googleusercontent.com,githubusercontent.com
คุณจะมีส่วนร่วมได้อย่างไร
หากคุณมีชุดเว็บไซต์ที่ตรงกับเกณฑ์ข้างต้น เรามีตัวเลือกต่างๆ ที่คุณสามารถใช้มีส่วนร่วมได้ การลงทุนน้อยที่สุดคือการอ่านและ ร่วมสนทนาเกี่ยวกับข้อเสนอ 2 ข้อนี้
- การสนทนาในกลุ่มชุมชนความเป็นส่วนตัวของชุดโดเมนของบุคคลที่หนึ่ง
- การสนทนาเกี่ยวกับแอตทริบิวต์ของคุกกี้ SameParty
ในระยะทดสอบ คุณลองใช้ฟังก์ชันการทำงานได้โดยใช้แฟล็กบรรทัดคำสั่ง --use-first-party-set และระบุรายการเว็บไซต์ที่คั่นด้วยเครื่องหมายจุลภาค
คุณอาจลองใช้เว็บไซต์สาธิตที่ https://fps-member1.glitch.me/ หลังจากเริ่มใช้ Chrome ด้วยแฟล็กต่อไปนี้
--use-first-party-set=https://fps-member1.glitch.me,https://fps-member2.glitch.me,https://fps-member3.glitch.me
วิธีนี้มีประโยชน์หากคุณต้องการทดสอบในสภาพแวดล้อมในการพัฒนาซอฟต์แวร์หรือต้องการลองเพิ่มแอตทริบิวต์ SameParty ในสภาพแวดล้อมที่เผยแพร่อยู่เพื่อดูว่าชุดบุคคลที่หนึ่งจะส่งผลต่อคุกกี้อย่างไร
หากมีแบนด์วิดท์สำหรับการทดลองและความคิดเห็น คุณยังลงชื่อสมัครใช้ช่วงทดลองใช้จากต้นทางสำหรับชุดบุคคลที่หนึ่งและ SameParty ที่พร้อมให้บริการใน Chrome ตั้งแต่เวอร์ชัน 89 ถึง 93 ได้ด้วย
วิธีอัปเดตคุกกี้สำหรับช่วงทดลองใช้จากต้นทาง
หากเข้าร่วมช่วงทดลองใช้จากต้นทางและทดสอบแอตทริบิวต์ SameParty บนคุกกี้ คุณควรคำนึงถึงรูปแบบต่อไปนี้
ตัวเลือก 1
ก่อนอื่น หากมีคุกกี้ที่ติดป้ายกำกับว่า SameSite=None แต่ต้องการจำกัดเฉพาะบริบทของบุคคลที่หนึ่ง คุณจะเพิ่มแอตทริบิวต์ SameParty ลงในคุกกี้ดังกล่าวได้ ในเบราว์เซอร์ที่มีช่วงทดลองใช้จากต้นทางอยู่ ระบบจะไม่ส่งคุกกี้ในบริบทแบบข้ามเว็บไซต์นอกชุดอุปกรณ์
อย่างไรก็ตาม สำหรับเบราว์เซอร์ส่วนใหญ่ที่อยู่นอกช่วงทดลองใช้จากต้นทาง คุกกี้จะยังคงมีการส่งข้ามเว็บไซต์ตามปกติ ให้มองว่านี่เป็นแนวทางการเพิ่มประสิทธิภาพแบบต่อเนื่อง
ก่อน:
set-cookie: cname=cval; SameSite=None; Secure
หลัง:
set-cookie: cname=cval; SameSite=None; Secure; SameParty
ตัวเลือก 2
ตัวเลือกที่ 2 จะดีกว่า แต่ช่วยให้คุณแยกช่วงทดลองใช้จากต้นทางออกจากฟังก์ชันการทำงานที่มีอยู่ได้เต็มที่ และอนุญาตให้ทดสอบชุดค่าผสม SameSite=Lax; SameParty โดยเฉพาะ
ก่อน:
set-cookie: cname=cval; SameSite=None; Secure
หลัง:
set-cookie: cname=cval; SameSite=None; Secure
set-cookie: cname-fps=cval; SameSite=Lax; Secure; SameParty
เมื่อตรวจสอบคุกกี้ในคำขอที่เข้ามาใหม่ คุณควรจะเห็นคุกกี้ cname-fps ในคำขอแบบข้ามเว็บไซต์เฉพาะในกรณีที่เว็บไซต์ที่เกี่ยวข้องอยู่ในชุดและเบราว์เซอร์ที่อยู่ในช่วงทดลองใช้จากต้นทาง ลองพิจารณาวิธีนี้เหมือนการเปิดตัวฟีเจอร์ที่อัปเดตพร้อมกันก่อนที่จะยุติการให้บริการเวอร์ชันก่อนหน้า
เหตุใดคุณจึงไม่จำเป็นต้องใช้ชุดบุคคลที่หนึ่ง
สำหรับเว็บไซต์ส่วนใหญ่ ขอบเขตเว็บไซต์เป็นที่ที่ยอมรับได้ในการวาดพาร์ติชันหรือขอบเขตความเป็นส่วนตัว นี่คือเส้นทางที่เสนอด้วย CHIPS (คุกกี้ที่มีสถานะพาร์ติชันอิสระ) ซึ่งจะให้เส้นทางการเลือกใช้แก่เว็บไซต์ผ่านแอตทริบิวต์ Partitioned เพื่อให้ยังคงมีการฝัง ทรัพยากร, API และบริการข้ามเว็บไซต์ที่สำคัญเหล่านั้น ขณะเดียวกันก็ป้องกันการรั่วไหลของการระบุข้อมูลข้ามเว็บไซต์
สิ่งอื่นๆ ที่ควรคำนึงถึง ซึ่งหมายความว่าเว็บไซต์จะไม่มีปัญหาใดๆ โดยไม่จำเป็นต้องตั้งค่า เช่น
- คุณโฮสต์บนต้นทางที่ต่างกัน ไม่ใช่คนละเว็บไซต์ ในตัวอย่างด้านบน หาก
brandx.siteมีfly.brandx.siteและdrive.brandx.siteสิ่งเหล่านี้จะเป็นโดเมนย่อยที่ต่างกันทั้งหมดภายในเว็บไซต์เดียวกัน คุกกี้จะใช้SameSite=Laxได้และไม่จำเป็นต้องตั้งค่า - คุณฝังไฟล์ของบุคคลที่สามในเว็บไซต์อื่นๆ ในบทนำ ตัวอย่างวิดีโอจาก
video.siteที่ฝังไว้ในmy-blog.siteเป็นการหารโดยบุคคลที่สามอย่างชัดเจน เว็บไซต์เหล่านี้ดำเนินการโดยองค์กรต่างๆ และผู้ใช้จะเห็นเป็นนิติบุคคลแยกต่างหาก เว็บไซต์ทั้ง 2 แห่งนี้ไม่ควรอยู่ในชุดเดียวกัน - คุณให้บริการลงชื่อเข้าใช้ผ่านโซเชียลของบุคคลที่สาม ผู้ให้บริการข้อมูลประจำตัวที่ใช้สิ่งต่างๆ เช่น OAuth หรือ OpenId Connect มักจะอาศัยคุกกี้ของบุคคลที่สามเพื่อให้ผู้ใช้ลงชื่อเข้าใช้ได้ราบรื่นยิ่งขึ้น เป็นกรณีการใช้งานที่ถูกต้อง แต่ไม่เหมาะกับชุดโดเมนของบุคคลที่หนึ่ง เนื่องจากมีความแตกต่างในองค์กรอย่างชัดเจน ข้อเสนอในช่วงแรก เช่น WebID คือการสำรวจวิธีเปิดใช้ Use Case เหล่านี้