องค์กรหลายแห่งมีเว็บไซต์ที่เกี่ยวข้องซึ่งมีชื่อโดเมนต่างกัน เช่น 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 ที่มี
SameSite=Lax,StrictหรือNoneจะทําให้คุกกี้เป็นคุกกี้ของบุคคลที่หนึ่ง - บริบทข้ามเว็บไซต์ที่มี
SameSite=Noneทําให้คุกกี้เป็นของบุคคลที่สาม
อย่างไรก็ตาม เรื่องนี้อาจไม่ชัดเจนเสมอไป สมมติว่า brandx.site เป็นเว็บไซต์การจองการเดินทางและใช้ fly-brandx.site และ drive-brandx.site เพื่อแยกเที่ยวบินและรถเช่า ตลอดเส้นทางการจอง 1 รายการ ผู้เข้าชมจะไปยังเว็บไซต์เหล่านี้เพื่อเลือกตัวเลือกต่างๆ โดยคาดหวังว่า "รถเข็นช็อปปิ้ง" ของตัวเลือกจะยังคงอยู่ตลอดในเว็บไซต์เหล่านี้ brandx.site
จัดการเซสชันของผู้ใช้ด้วยคุกกี้ SameSite=None เพื่ออนุญาตในบริบทข้ามเว็บไซต์ แต่ข้อเสียคือตอนนี้คุกกี้จะไม่มีการป้องกันการปลอมแปลงคําขอข้ามเว็บไซต์ (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" }
ชุดของบุคคลที่หนึ่งมีข้อจำกัดบางประการ ดังนี้
- ชุดหนึ่งๆ มีเจ้าของได้เพียงคนเดียว
- สมาชิกจะอยู่ในชุดได้เพียงชุดเดียวเท่านั้น ไม่มีการทับซ้อนหรือผสม
- รายชื่อสมาชิกควรเป็นรายการที่มนุษย์อ่านออกได้และไม่ใหญ่จนเกินไป
ชุดโดเมนของบุคคลที่หนึ่งส่งผลต่อคุกกี้อย่างไร
ส่วนผสมที่ตรงกันสำหรับคุกกี้คือ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 ด้วย Flag ต่อไปนี้
--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 ในคุกกี้ โปรดพิจารณารูปแบบ 2 รูปแบบต่อไปนี้
ตัวเลือก 1
ขั้นแรก ให้เพิ่มแอตทริบิวต์ SameParty ลงในคุกกี้ที่ติดป้ายกํากับเป็น SameSite=None แต่คุณต้องการจํากัดให้ใช้ในบริบทของบุคคลที่หนึ่ง ในเบราว์เซอร์ที่มีการทดลองใช้แหล่งที่มาอยู่ ระบบจะไม่ส่งคุกกี้ในบริบทข้ามเว็บไซต์นอกชุด
อย่างไรก็ตาม สําหรับเบราว์เซอร์ส่วนใหญ่ที่อยู่นอกการทดสอบต้นทาง ระบบจะยังคงส่งคุกกี้ข้ามเว็บไซต์ตามปกติ โปรดพิจารณาว่านี่เป็นแนวทางการปรับปรุงแบบค่อยเป็นค่อยไป
ก่อน:
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 เหล่านี้