[OUTDATED] ชุดโดเมนของบุคคลที่หนึ่งและแอตทริบิวต์ SameParty

คำเตือน: อัปเดตข้อเสนอชุดโดเมนของบุคคลที่หนึ่งแล้ว และบทความนี้ไม่ใช่ข้อมูลล่าสุดอีกต่อไป ดูข้อมูลล่าสุดในคำอธิบายและวิธีการทดสอบ

องค์กรจำนวนมากมีเว็บไซต์ที่เกี่ยวข้องซึ่งมีชื่อโดเมนต่างกัน เช่น brandx.site และ fly-brandx.site หรือโดเมนสำหรับแต่ละประเทศ เช่น example.com, example.rs, example.co.uk และอื่นๆ

เบราว์เซอร์ต่างๆ กำลังพัฒนาไปสู่การสร้างคุกกี้ของบุคคลที่สาม ล้าสมัย เพื่อปรับปรุงความเป็นส่วนตัวบนเว็บ แต่เว็บไซต์เหล่านี้มักจะอาศัยคุกกี้เพื่อ ฟังก์ชันที่ต้องมีการดูแลรักษาและการเข้าถึงสถานะข้ามโดเมน (เช่น การลงชื่อเพียงครั้งเดียวและการจัดการความยินยอม)

ชุดโดเมนของบุคคลที่หนึ่งจะอนุญาตชื่อโดเมนที่เกี่ยวข้องซึ่งมีเจ้าของและดำเนินการเอง นิติบุคคลเดียวกันจะถือว่าเป็นบุคคลที่หนึ่ง ในสถานการณ์ที่บุคคลที่หนึ่งและ บุคคลที่สามจะได้รับการปฏิบัติไม่เหมือนกัน ชื่อโดเมนภายใน กลุ่มบุคคลที่หนึ่งจะถือว่าเป็นกลุ่มเดียวกันและสามารถติดป้ายกำกับว่าคุกกี้ใด ที่ตั้งใจให้ตั้งค่าหรือส่งในบริบทที่เป็นฝ่ายเดียวกัน เป้าหมายคือการค้นหา รักษาสมดุลระหว่างการป้องกันการติดตามข้ามเว็บไซต์จากบุคคลที่สามในขณะที่ยังคง การดูแลรักษาเส้นทางที่ไม่แยก Use Case ที่ถูกต้อง

ปัจจุบันข้อเสนอชุดโดเมนของบุคคลที่หนึ่งอยู่ระหว่างการทดสอบ Phase, อ่านต่อเพื่อดูวิธีทำงาน และจะลองใช้งานได้อย่างไร

คุกกี้ของบุคคลที่หนึ่งกับบุคคลที่สามแตกต่างกันอย่างไร

คุกกี้ไม่ใช่ของบุคคลที่หนึ่งหรือบุคคลที่สามโดยธรรมชาติ แต่ขึ้นอยู่กับ บริบทที่มีคุกกี้รวมอยู่ด้วย ส่งคำขอใน ส่วนหัว 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 เพื่อทำสิ่งต่อไปนี้ เที่ยวบินและรถเช่าแยกต่างหาก ตลอดเส้นทางการจอง 1 เส้นทาง ผู้เข้าชม ระหว่างเว็บไซต์เหล่านี้เพื่อดูตัวเลือกต่างๆ พวกเขาคาดหวังว่า "รถเข็นช็อปปิ้ง" ให้คงอยู่ในเว็บไซต์เหล่านี้ brandx.site จัดการเซสชันของผู้ใช้ด้วยคุกกี้ SameSite=None เพื่ออนุญาต แบบข้ามเว็บไซต์ แต่ข้อเสียคือตอนนี้คุกกี้ไม่มีข้ามเว็บไซต์ ขอการป้องกันการปลอมแปลง (CSRF) หาก evil.site มีคำขอ brandx.site ก็จะมีคุกกี้นั้นรวมอยู่ด้วย

คุกกี้เป็นแบบข้ามเว็บไซต์ แต่เว็บไซต์ทั้งหมดเหล่านั้นมีเจ้าของและดำเนินการเองเช่นกัน องค์กร นอกจากนี้ ผู้เข้าชมยังเข้าใจว่าเป็นองค์กรเดียวกัน และต้องการให้ เซสชันเดียวกัน เรียกอีกอย่างหนึ่งว่า อัตลักษณ์ที่มีร่วมกันระหว่างทั้งสอง

หมายเหตุ: เมื่อใช้ชุดโดเมนของบุคคลที่หนึ่ง จะมีเส้นทางสำหรับกำหนดสถานการณ์ที่ บริบทแบบข้ามเว็บไซต์ยังคงเป็นบุคคลที่หนึ่งอยู่ สามารถรวมคุกกี้ ภายในกลุ่มบุคคลที่หนึ่งและยกเว้นในบริบทของบุคคลที่สาม

นโยบายชุดโดเมนของบุคคลที่หนึ่ง

ชุดโดเมนของบุคคลที่หนึ่งมี ในการกำหนดความสัมพันธ์นี้อย่างชัดแจ้งในหลายเว็บไซต์ที่ มีเจ้าของและเป็นผู้ดำเนินการโดยบุคคลเดียวกัน การดำเนินการนี้จะทำให้ brandx.site สามารถ กำหนดความสัมพันธ์ของบุคคลที่หนึ่งกับ fly-brandx.site drive-brandx.site และอื่นๆ

โมเดลความเป็นส่วนตัวที่ขับเคลื่อน ข้อเสนอ Privacy Sandbox ต่างๆ นั้น อิงตามแนวคิดของการแบ่งพาร์ติชัน ระบุตัวตนในการป้องกันการติดตามข้ามเว็บไซต์ ซึ่งเป็นการกำหนดขอบเขตระหว่างเว็บไซต์ที่ จำกัดการเข้าถึงข้อมูลที่สามารถใช้ระบุตัวตนผู้ใช้ได้

แม้ว่าตัวเลือกเริ่มต้นจะเป็นการแบ่งพาร์ติชันตามเว็บไซต์ ซึ่งจะแก้ไขปัญหาของบุคคลที่หนึ่งจำนวนมาก ในกรณีการใช้งาน ตัวอย่าง brandx.site แสดงให้เห็นว่าบุคคลที่หนึ่งอาจมีขนาดใหญ่กว่า มากกว่าเว็บไซต์เดียว

ส่วนสำคัญของข้อเสนอชุดโดเมนของบุคคลที่หนึ่งคือการทำให้นโยบาย เพื่อป้องกันการละเมิดหรือการใช้ในทางที่ผิด เช่น ชุดโดเมนของบุคคลที่หนึ่งต้องไม่ ทำให้สามารถแลกเปลี่ยนข้อมูลผู้ใช้ข้ามไซต์ที่ไม่เกี่ยวข้องกันหรือการจัดกลุ่ม เว็บไซต์ที่ไม่ได้เป็นของนิติบุคคลเดียวกัน แนวคิดก็คือเพื่อให้มั่นใจว่า ชุดโดเมนของบุคคลที่หนึ่งจะจับคู่กับสิ่งที่ผู้ใช้เข้าใจว่าเป็นบุคคลที่หนึ่ง และ ไม่ใช้เป็นวิธีการแชร์ข้อมูลประจำตัวระหว่างฝ่ายต่างๆ

วิธีหนึ่งที่เป็นไปได้ที่เว็บไซต์จะลงทะเบียนกลุ่มของบุคคลที่หนึ่งได้คือสำหรับเว็บไซต์ เพื่อส่งกลุ่มโดเมนที่เสนอไปยังเครื่องมือติดตามสาธารณะ (เช่น ที่เก็บ GitHub โดยเฉพาะ) พร้อมด้วยข้อมูลที่จำเป็นสำหรับการตอบสนองของเบราว์เซอร์

หมายเหตุ: กระบวนการยอมรับกลุ่มใหม่ของบุคคลที่หนึ่งอยู่ระหว่างการหารือกับ W3C และ 1 ใน ตัวเลือก ที่ พิจารณา คือ การยืนยัน จะ โดย ที่เป็นอิสระ ไม่ใช่บริษัทเบราว์เซอร์

เมื่อการยืนยันชุดของบุคคลที่หนึ่งได้รับการยืนยันตามนโยบายแล้ว เบราว์เซอร์อาจ จากนั้นให้ดึงข้อมูลลิสต์ชุดผ่านกระบวนการอัปเดต

ช่วงทดลองใช้จากต้นทางมีนโยบายที่กำหนดไว้ ซึ่งยังไม่เป็นที่สิ้นสุด แต่หลักการดังกล่าวมีดังนี้ ที่มีแนวโน้มว่าจะยังคงเหมือนเดิม:

• โดเมนในชุดบุคคลที่หนึ่งต้องเป็นเจ้าของและดำเนินการเองโดยฝ่ายเดียวกัน องค์กร
• โดเมนควรจดจำได้สำหรับผู้ใช้เป็นกลุ่ม
• โดเมนเหล่านี้ควรใช้นโยบายความเป็นส่วนตัวเดียวกัน

หมายเหตุ: ดูข้อมูลเพิ่มเติมเกี่ยวกับนโยบายที่เสนอสำหรับบุคคลที่หนึ่ง เซ็ต

วิธีกำหนดกลุ่มของบุคคลที่หนึ่ง

เมื่อคุณระบุสมาชิกและเจ้าของบุคคลที่หนึ่งขององค์กรแล้ว ขั้นตอนสำคัญก็คือการส่งชุดที่เสนอเพื่อขออนุมัติ ผลลัพธ์ที่แน่นอน กระบวนการยังอยู่ระหว่างการหารือ

ข้อควรระวัง: กลุ่มของบุคคลที่หนึ่งไม่ได้หมายถึงรายการโดยสมบูรณ์ของ เว็บไซต์ที่อยู่ในองค์กรเดียวกัน คุณต้องสร้างชุดเท่านั้น ระหว่างเว็บไซต์ต่างๆ หากคุณต้องการอย่างชัดแจ้งให้อนุญาตคุกกี้ข้ามเว็บไซต์ โปรดดูกรณีการใช้งานที่เหมาะกับชุดโดเมนของบุคคลที่หนึ่ง ช่วงทดลองใช้จากต้นทางไหมที่ด้านล่าง

หากต้องการประกาศชุดบุคคลที่หนึ่ง ทรัพยากร 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" }

กลุ่มของบุคคลที่หนึ่งมีข้อจำกัดบางประการ ดังนี้

• แต่ละชุดมีเจ้าของได้เพียงคนเดียว
• สมาชิกจะต้องเป็นสมาชิกเพียงกลุ่มเดียว โดยไม่มีการทับซ้อนหรือปะปนกัน
• รายชื่อสมาชิกมีจุดมุ่งหมายเพื่อให้มนุษย์อ่านเข้าใจได้ และไม่ ใหญ่เกินไป

หมายเหตุ: คุณอาจโฮสต์ไฟล์ที่คล้ายกันอยู่แล้วหากคุณใช้ไฟล์ดิจิทัล ลิงก์ชิ้นงานไปยังเว็บไซต์ลิงก์ ที่ใช้แบ็กเอนด์การจัดการบัญชีเดียวกัน เพื่อช่วยให้ ข้อมูลรับรองเดียวกันกับที่เครื่องมือจัดการรหัสผ่านของ Chrome แนะนำทั่วทั้ง เว็บไซต์แอฟฟิลิเอต

ชุดโดเมนของบุคคลที่หนึ่งส่งผลต่อคุกกี้อย่างไร

ส่วนผสมที่ตรงกันสำหรับคุกกี้คือ SameParty ที่เสนอ กำลังระบุ SameParty จะแจ้งให้เบราว์เซอร์รวมคุกกี้เมื่อบริบทเป็นส่วนหนึ่งของ บุคคลที่หนึ่งเป็นบริบทระดับบนสุด

ซึ่งหมายความว่าหาก brandx.site ตั้งค่าคุกกี้นี้

Set-Cookie: session=123; Secure; SameSite=Lax; SameParty

จากนั้นเมื่อผู้เข้าชมอยู่ใน fly-brandx.site และคำขอไปยัง brandx.site คุกกี้ session จะรวมอยู่ในคำขอนั้น ตัวอย่างเช่น หากเว็บไซต์อื่นๆ ที่ไม่ได้เป็นส่วนหนึ่งของชุดบุคคลที่หนึ่ง hotel.xyz ส่งคำขอไปยัง brandx.site โดยจะไม่รวมคุกกี้

ใช้แอตทริบิวต์ SameSite ควบคู่กับ SameParty เพื่อ กำหนดลักษณะการทำงานสำรองสำหรับคุกกี้ ลองนึกถึง 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 แบบเข้มงวดในเว็บไซต์ภายในชุด

ประเด็นหลัก: แอตทริบิวต์ SameParty จะมีผลกับบริบทที่ อาจมีการส่งคุกกี้ ก็ไม่ได้สร้างโหลคุกกี้ที่แชร์ คุกกี้จาก brandx.site ใช้ได้กับคำขอหรือเอกสารสำหรับ brandx.site คุกกี้นี้ไม่สามารถใช้งานได้โดยตรงกับ fly-brandx.site ซึ่งอาจทำให้สับสนเนื่องจากคุณอาจเห็นการอ้างอิงว่า ที่มีอัตลักษณ์ร่วมกัน แต่นั่นหมายความว่า ขอบเขตที่ไม่เคร่งครัดระหว่างไซต์ทั้งสอง ช่วยให้ตั้งค่าหรือส่งคุกกี้ในบริบทของฝ่ายเดียวกันและข้ามเว็บไซต์ ไม่ใช่ ที่มีการแชร์คุกกี้โดยตรง

กรณีการใช้งานใดเหมาะกับชุดโดเมนของบุคคลที่หนึ่ง

ชุดโดเมนของบุคคลที่หนึ่งเหมาะกับกรณีที่องค์กรต้องการรูปแบบ ที่เปิดเผยร่วมกันในเว็บไซต์ระดับบนสุดต่างๆ อัตลักษณ์ที่มีร่วมกันในกรณีนี้ หมายถึงทุกอย่างตั้งแต่โซลูชันการลงชื่อเพียงครั้งเดียวเต็มรูปแบบ ไปจนถึงความต้องการ ความต้องการข้ามเว็บไซต์

หมายเหตุ: คุณระบุคำที่อาจนำไปใช้ได้สำหรับ Use Case เหล่านี้ เนื่องจากโปรแกรมเหล่านี้ เป็นอินสแตนซ์ที่คุณได้ทำเครื่องหมายคุกกี้เป็น SameSite=None แล้ว อย่างไรก็ตาม การดำเนินการดังกล่าวมีไว้สำหรับบริบทแบบข้ามเว็บไซต์ซึ่งคุณเป็นเจ้าของเว็บไซต์ทั้งหมดที่เกี่ยวข้องเท่านั้น

องค์กรของคุณอาจมีโดเมนระดับบนสุดแตกต่างกันสำหรับบริการต่อไปนี้

• โดเมนแอป: 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 Flag บรรทัดคำสั่งและระบุรายการที่คั่นด้วยคอมมา เว็บไซต์

คุณสามารถลองใช้งานได้ในเว็บไซต์เดโมที่ 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

คำสำคัญ: การทดลองใช้จริงเป็นวิธีของ Chrome ในการช่วยให้นักพัฒนาซอฟต์แวร์ภายนอกทดสอบ ข้อเสนอเบื้องต้นในสถานการณ์จริงเพื่อให้ความคิดเห็นที่จำเป็นต่อการพัฒนา และทำซ้ำเพื่อให้เป็นไปตามสิ่งที่ ตรงกับความต้องการของแพลตฟอร์มเว็บ ดูข้อมูล ข้อมูลเพิ่มเติมในการเริ่มต้นใช้งานต้นทางของ Chrome ครั้ง

วิธีอัปเดตคุกกี้สำหรับช่วงทดลองใช้จากต้นทาง

หากคุณเข้าร่วมช่วงทดลองใช้จากต้นทางและทดสอบแอตทริบิวต์ SameParty ใน คุกกี้ของคุณมี 2 รูปแบบที่ต้องพิจารณา

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

เหตุใดคุณจึงไม่จำเป็นต้องใช้ชุดบุคคลที่หนึ่ง

สำหรับเว็บไซต์ส่วนใหญ่ ขอบเขตไซต์เป็นที่ที่ยอมรับได้สำหรับการวาด พาร์ติชันหรือขอบเขตความเป็นส่วนตัว นี่คือเส้นทางที่เสนอพร้อมกับ ชิป (คุกกี้ที่มีการแบ่งพาร์ติชันอิสระ) สถานะ) ที่จะให้เว็บไซต์ต่างๆ เลือกรับ ผ่านแอตทริบิวต์ Partitioned เพื่อยังคงมีการข้ามเว็บไซต์ที่สำคัญเหล่านั้น ข้อมูลที่ฝัง ทรัพยากร, API และบริการ ในขณะที่ป้องกันการรั่วไหลของข้อมูล ข้อมูลข้ามเว็บไซต์

ปัจจัยอื่นๆ ที่ควรพิจารณา ซึ่งหมายความว่าเว็บไซต์ของคุณจะสามารถใช้งานได้โดยไม่จำเป็นต้อง ชุด:

• คุณโฮสต์ในหลายต้นทาง ไม่ใช่เว็บไซต์ที่แตกต่างกัน ในตัวอย่างด้านบน ถ้า brandx.site มี fly.brandx.site และ drive.brandx.site แล้ว คือโดเมนย่อยที่ต่างกันทั้งหมดภายในเว็บไซต์เดียวกัน คุกกี้สามารถใช้ SameSite=Lax และไม่จำเป็นต้องตั้งค่า
• คุณให้การฝังของบุคคลที่สามในเว็บไซต์อื่นๆ ในช่วงอินโทร ตัวอย่างของ วิดีโอจาก video.site ซึ่งฝังอยู่ใน my-blog.site เป็นบุคคลที่สามที่ชัดเจน หาร เว็บไซต์ได้รับการจัดการโดยองค์กรต่างๆ และผู้ใช้จะมองเห็น เป็นเอนทิตีแยกต่างหาก เว็บไซต์ 2 เว็บนี้ไม่ควรอยู่ในชุดเดียวกัน
• คุณให้บริการลงชื่อเข้าใช้ผ่านโซเชียลของบุคคลที่สาม ผู้ให้บริการข้อมูลประจำตัวที่ใช้ เช่น OAuth หรือ OpenId Connect มักอาศัยคุกกี้ของบุคคลที่สาม การลงชื่อเข้าใช้ที่ราบรื่นยิ่งขึ้นสำหรับผู้ใช้ เป็นกรณีการใช้งานที่ถูกต้อง แต่ไม่ใช่ เหมาะกับชุดโดเมนของบุคคลที่หนึ่งเนื่องจากมีความแตกต่างอย่างชัดเจนในองค์กร ข้อเสนอเบื้องต้น เช่น WebID สำรวจวิธีเปิดใช้ Use Case เหล่านี้