Chrome เสนอประสบการณ์การใช้งานแบบใหม่ที่ให้ผู้ใช้ตัดสินใจเกี่ยวกับคุกกี้ของบุคคลที่สาม คุณต้องเตรียมเว็บไซต์ให้พร้อมสําหรับผู้ใช้ที่เลือกท่องเว็บโดยไม่มีคุกกี้ของบุคคลที่สาม
ในหน้านี้ คุณจะเห็นข้อมูลเกี่ยวกับสถานการณ์การระบุตัวตนที่เป็นไปได้มากที่สุดที่ได้รับผลกระทบ รวมถึงข้อมูลอ้างอิงเกี่ยวกับวิธีแก้ปัญหาที่เป็นไปได้
หากเว็บไซต์จัดการเฉพาะขั้นตอนภายในโดเมนและโดเมนย่อยเดียวกัน เช่น publisher.example และ login.publisher.example เว็บไซต์จะไม่ใช้คุกกี้ข้ามเว็บไซต์ และขั้นตอนลงชื่อเข้าใช้จะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงคุกกี้ของบุคคลที่สาม
อย่างไรก็ตาม หากเว็บไซต์ใช้โดเมนแยกต่างหากสำหรับการเข้าสู่ระบบ เช่น Google sign-in หรือ Facebook sign-in หรือเว็บไซต์จำเป็นต้องแชร์การตรวจสอบสิทธิ์ผู้ใช้ในหลายโดเมนหรือโดเมนย่อย คุณอาจต้องทําการเปลี่ยนแปลงเว็บไซต์เพื่อให้การเปลี่ยนจากคุกกี้ข้ามเว็บไซต์เป็นไปอย่างราบรื่น
เส้นทางของผู้ใช้ที่พบบ่อย
ก่อนหน้านี้เวิร์กโฟลว์การระบุตัวตนจำนวนมากใช้คุกกี้ของบุคคลที่สาม ตารางนี้แสดงเส้นทางที่พบบ่อยของผู้ใช้และโซลูชันที่เป็นไปได้สําหรับแต่ละเส้นทาง ซึ่งไม่ใช้คุกกี้ของบุคคลที่สาม ส่วนต่อไปนี้จะอธิบายเหตุผลของคําแนะนําเหล่านี้
API ทางเลือกที่แนะนำสำหรับ Use Case ที่พบบ่อย
ในตารางยังอยู่ในช่วงเริ่มต้นของการพัฒนา ความคิดเห็นของคุณมีคุณค่าและจะช่วยกำหนดอนาคตของฟีเจอร์นี้ แชร์ความคิดเห็นเกี่ยวกับ Popins แบบแบ่งพาร์ติชันเหล่านี้
| เส้นทางของผู้ใช้ | API ที่แนะนํา |
|---|---|
| การลงชื่อเข้าใช้ด้วยบัญชีโซเชียล |
สําหรับผู้ให้บริการข้อมูลประจําตัว: ใช้ FedCM สําหรับบุคคลที่เชื่อถือ: ติดต่อผู้ให้บริการข้อมูลประจําตัว |
|
สําหรับผู้ให้บริการข้อมูลประจําตัวหรือโซลูชันที่กําหนดเอง ให้ใช้ชุดเว็บไซต์ที่เกี่ยวข้อง |
|
| การจัดการโปรไฟล์ผู้ใช้ |
Storage Access API ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS FedCM + SAA |
|
Storage Access API ชุดเว็บไซต์ที่เกี่ยวข้อง CHIPS FedCM + SAA |
|
| การตรวจสอบสิทธิ์ |
Storage Access API FedCM Web Authentication API scienceป๊อปอัปที่มีการแบ่งพาร์ติชัน |
| โดยทั่วไปแล้ว สถานการณ์เหล่านี้จะไม่ใช้คุกกี้ของบุคคลที่สามและคาดว่าจะไม่ได้รับผลกระทบ |
ทดสอบเส้นทางของผู้ใช้ที่เกี่ยวข้องกับข้อมูลประจำตัว
วิธีที่ดีที่สุดในการทดสอบว่าขั้นตอนการลงชื่อเข้าใช้ได้รับผลกระทบจากการเปลี่ยนแปลงคุกกี้ของบุคคลที่สามหรือไม่คือให้ทำตามขั้นตอนการลงทะเบียน การกู้คืนรหัสผ่าน การลงชื่อเข้าใช้ และการออกจากระบบโดยเปิดใช้ Flag การทดสอบคุกกี้ของบุคคลที่สาม
ต่อไปนี้เป็นรายการสิ่งที่ต้องตรวจสอบเมื่อคุณจํากัดคุกกี้ของบุคคลที่สามแล้ว
- การลงทะเบียนผู้ใช้: การสร้างบัญชีใหม่ทํางานได้ตามปกติ หากใช้ผู้ให้บริการข้อมูลประจำตัวของบุคคลที่สาม ให้ตรวจสอบว่าการลงทะเบียนบัญชีใหม่ใช้งานได้กับการผสานรวมทุกรายการ
- การกู้คืนรหัสผ่าน: การกู้คืนรหัสผ่านทำงานได้ตามที่คาดไว้ ตั้งแต่ UI ของเว็บ CAPTCHA ไปจนถึงการรับอีเมลสำหรับการกู้คืนรหัสผ่าน
- การลงชื่อเข้าใช้: เวิร์กโฟลว์การลงชื่อเข้าใช้จะทำงานภายในโดเมนเดียวกันและเมื่อไปยังโดเมนอื่น อย่าลืมทดสอบการผสานรวมการลงชื่อเข้าใช้ทุกรายการ
- การออกจากระบบ: กระบวนการออกจากระบบทำงานได้ตามที่คาดไว้ และผู้ใช้จะยังคงออกจากระบบหลังจากขั้นตอนการออกจากระบบ
นอกจากนี้ คุณควรทดสอบว่าฟีเจอร์อื่นๆ ของเว็บไซต์ที่ต้องมีการลงชื่อเข้าใช้ของผู้ใช้ยังคงทํางานได้โดยไม่ต้องใช้คุกกี้ข้ามเว็บไซต์ โดยเฉพาะในกรณีที่เกี่ยวข้องกับการโหลดทรัพยากรข้ามเว็บไซต์ เช่น หากคุณใช้ CDN เพื่อโหลดรูปโปรไฟล์ผู้ใช้ ให้ตรวจสอบว่า CDN ยังคงใช้งานได้ หากคุณมีเส้นทางของผู้ใช้ที่สําคัญ เช่น การชําระเงิน ที่มีการจำกัดไม่ให้เข้าถึงได้จนกว่าจะลงชื่อเข้าใช้ โปรดตรวจสอบว่าเส้นทางเหล่านี้ยังคงทํางานต่อไป
โซลูชันการลงชื่อเข้าใช้
ในส่วนนี้ คุณจะเห็นข้อมูลที่เฉพาะเจาะจงมากขึ้นเกี่ยวกับผลกระทบที่อาจเกิดขึ้นกับขั้นตอนเหล่านั้น
การลงชื่อเพียงครั้งเดียว (SSO) ของบุคคลที่สาม
การลงชื่อเพียงครั้งเดียว (SSO) ของบุคคลที่สามช่วยให้ผู้ใช้ตรวจสอบสิทธิ์ด้วยข้อมูลเข้าสู่ระบบชุดเดียวในแพลตฟอร์มเดียว จากนั้นเข้าถึงแอปพลิเคชันและเว็บไซต์หลายรายการได้โดยไม่ต้องป้อนข้อมูลเข้าสู่ระบบอีกครั้ง เนื่องจากการติดตั้งใช้งานโซลูชัน SSO มีความซับซ้อน หลายบริษัทจึงเลือกใช้ผู้ให้บริการโซลูชันบุคคลที่สามเพื่อแชร์สถานะการลงชื่อเข้าใช้ระหว่างต้นทางหลายแห่ง ตัวอย่างผู้ให้บริการ ได้แก่ Okta, Ping Identity, Google Cloud IAM หรือ Microsoft Entra ID
หากโซลูชันของคุณอาศัยผู้ให้บริการบุคคลที่สาม คุณอาจต้องทำการเปลี่ยนแปลงเล็กๆ น้อยๆ เช่น การอัปเกรดไลบรารี แนวทางที่ดีที่สุดคือการขอคำแนะนำจากผู้ให้บริการเกี่ยวกับผลกระทบของทรัพยากร Dependency ของคุกกี้ของบุคคลที่สามต่อโซลูชัน และแนวทางที่ผู้ให้บริการแนะนำสำหรับบริการของตน ผู้ให้บริการบางรายจะย้ายข้อมูลออกจากคุกกี้ของบุคคลที่สามโดยอัตโนมัติ ซึ่งในกรณีนี้ บุคคลที่สามที่เชื่อถือไม่จำเป็นต้องอัปเดต
หลายโดเมน
บางเว็บไซต์ใช้โดเมนอื่นเพื่อตรวจสอบสิทธิ์ผู้ใช้ที่ไม่มีสิทธิ์ใช้คุกกี้ของเว็บไซต์เดียวกันเท่านั้น เช่น เว็บไซต์ที่ใช้ example.com สำหรับเว็บไซต์หลักและ login.example สำหรับขั้นตอนการเข้าสู่ระบบ ซึ่งอาจต้องมีการเข้าถึงคุกกี้ของบุคคลที่สามเพื่อให้แน่ใจว่าผู้ใช้ได้รับการตรวจสอบสิทธิ์ในทั้ง 2 โดเมน
ธุรกิจบางแห่งอาจมีผลิตภัณฑ์หลายรายการที่โฮสต์ในโดเมนหรือโดเมนย่อยที่แตกต่างกัน โซลูชันดังกล่าวอาจต้องการแชร์เซสชันผู้ใช้ในผลิตภัณฑ์เหล่านั้น ซึ่งเป็นสถานการณ์ที่อาจต้องมีการเข้าถึงคุกกี้ของบุคคลที่สามระหว่างโดเมนหลายรายการ
เส้นทางการย้ายข้อมูลสำหรับสถานการณ์นี้มีดังนี้
- อัปเดตเพื่อใช้คุกกี้ของบุคคลที่หนึ่ง ("เว็บไซต์เดียวกัน"): การเปลี่ยนแปลงโครงสร้างพื้นฐานของเว็บไซต์เพื่อให้โฮสต์ขั้นตอนการเข้าสู่ระบบในโดเมนเดียวกัน (หรือโดเมนย่อย) กับเว็บไซต์หลัก ซึ่งจะใช้เฉพาะคุกกี้ของบุคคลที่หนึ่ง ซึ่งอาจต้องใช้ความพยายามมากกว่า โดยขึ้นอยู่กับวิธีตั้งค่าโครงสร้างพื้นฐาน
- ใช้ชุดเว็บไซต์ที่เกี่ยวข้อง (RWS) และ Storage Access API (SAA): RWS ช่วยให้เข้าถึงคุกกี้ข้ามเว็บไซต์ได้แบบจํากัดระหว่างโดเมนที่เกี่ยวข้องกลุ่มเล็กๆ เมื่อใช้ RWS ผู้ใช้ไม่จำเป็นต้องได้รับข้อความแจ้งเมื่อขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลด้วย Storage Access API ซึ่งจะช่วยให้ใช้ SSO ใน RP เหล่านั้นที่อยู่ใน RWS เดียวกับ IdP ได้ อย่างไรก็ตาม RWS รองรับการเข้าถึงคุกกี้ข้ามเว็บไซต์ในโดเมนจํานวนจํากัดเท่านั้น
- ใช้ Web Authentication API: Web Authentication API อนุญาตให้บุคคลที่เชื่อถือ (RP) ลงทะเบียนชุดต้นทางที่เกี่ยวข้องแบบจํากัดซึ่งสร้างและใช้ข้อมูลเข้าสู่ระบบได้
- หากตรวจสอบสิทธิ์ผู้ใช้ในโดเมนที่เชื่อมโยงมากกว่า 5 โดเมน ให้ดูการจัดการข้อมูลเข้าสู่ระบบแบบรวมศูนย์ (FedCM) FedCM ช่วยให้ผู้ให้บริการข้อมูลประจำตัวใช้ Chrome ในการจัดการขั้นตอนที่เกี่ยวข้องกับข้อมูลประจำตัวได้โดยไม่ต้องใช้คุกกี้ของบุคคลที่สาม ในกรณีของคุณ "โดเมนการลงชื่อเข้าใช้" อาจทำหน้าที่เป็นผู้ให้บริการข้อมูลประจำตัวของ FedCM และใช้เพื่อตรวจสอบสิทธิ์ผู้ใช้ในโดเมนอื่นๆ
การตรวจสอบสิทธิ์จากการฝัง
สมมติว่าฝัง iframe ของ 3-party-app.example ใน top-level.example ใน 3-party-app.example ผู้ใช้จะเข้าสู่ระบบด้วยข้อมูลเข้าสู่ระบบ 3-party-app.example หรือผู้ให้บริการบุคคลที่สามรายอื่นก็ได้
ผู้ใช้คลิก "เข้าสู่ระบบ" และตรวจสอบสิทธิ์ภายใน3-party-app.example
ป๊อปอัป ป๊อปอัป 3-party-app.example จะตั้งค่าคุกกี้ของบุคคลที่หนึ่ง อย่างไรก็ตาม 3-party-app.example iframe ที่ฝังใน top-level.example จะมีการแบ่งพาร์ติชันและเข้าถึงคุกกี้ที่ตั้งค่าไว้ในบริบทของบุคคลที่หนึ่งใน 3-party-app.example ไม่ได้
ปัญหาเดียวกันนี้จะเกิดขึ้นเมื่อระบบเปลี่ยนเส้นทางผู้ใช้จาก top-level.example
ไปยัง 3-party-app.example และกลับ คุกกี้จะเขียนในบริบทของบุคคลที่หนึ่งของเว็บไซต์ 3-party-app.example แต่มีการแบ่งพาร์ติชันและเข้าถึงไม่ได้ภายใน iframe ของ 3-party-app.example
ในกรณีที่ผู้ใช้เข้าชมต้นทางที่ฝังในบริบทระดับบนสุด Storage Access API เป็นโซลูชันที่ดี
หากต้องการเปลี่ยนไปใช้โซลูชันที่ไม่ใช้คุกกี้ของบุคคลที่สาม เราขอแนะนำให้ผู้ให้บริการข้อมูลประจำตัวใช้ FedCM API และเรียกใช้ FedCM จากภายในการฝังแทนป๊อปอัป
โซลูชันอีกอย่างที่แนะนําสําหรับขั้นตอนนี้คือ ป๊อปอัปที่มีการแบ่งพาร์ติชัน ซึ่งกําลังอยู่ระหว่างการใช้งาน
การลงชื่อเข้าใช้ด้วยโซเชียล
ปุ่มลงชื่อเข้าใช้ เช่น ลงชื่อเข้าใช้ด้วย Google, Facebook Login และลงชื่อเข้าใช้ด้วย Twitter เป็นสัญญาณที่ชัดเจนว่าเว็บไซต์ของคุณใช้ผู้ให้บริการข้อมูลประจำตัวแบบรวมศูนย์ ผู้ให้บริการข้อมูลประจำตัวที่รวมศูนย์แต่ละรายจะมีการติดตั้งใช้งานของตนเอง
หากคุณใช้ไลบรารีแพลตฟอร์ม JavaScript ของ Google Sign-In ที่เลิกใช้งานแล้ว คุณสามารถดูข้อมูลเกี่ยวกับวิธีย้ายข้อมูลไปยังไลบรารี Google Identity Services เวอร์ชันใหม่เพื่อการตรวจสอบสิทธิ์และการให้สิทธิ์
เว็บไซต์ส่วนใหญ่ที่ใช้ไลบรารี Google Identity Services เวอร์ชันใหม่ได้นําการพึ่งพาคุกกี้ของบุคคลที่สามออกแล้ว เนื่องจากไลบรารีจะย้ายข้อมูลFedCM แบบเงียบๆเพื่อใช้งานร่วมกันได้ เราขอแนะนําให้ทดสอบเว็บไซต์โดยเปิดใช้ Flag การทดสอบการเลิกใช้งานคุกกี้ของบุคคลที่สาม และหากจําเป็น ให้ใช้รายการตรวจสอบการย้ายข้อมูล FedCM เพื่อเตรียมพร้อม
เข้าถึงและแก้ไขข้อมูลผู้ใช้จากการฝัง
เนื้อหาที่ฝังมักใช้กับเส้นทางของผู้ใช้ เช่น การเข้าถึงหรือจัดการข้อมูลโปรไฟล์หรือการติดตามของผู้ใช้
เช่น ผู้ใช้อาจเข้าสู่ระบบ website.example ซึ่งฝังวิดเจ็ต subscriptions.example วิดเจ็ตนี้ช่วยให้ผู้ใช้จัดการข้อมูลได้ เช่น การสมัครใช้บริการเนื้อหาพรีเมียมหรืออัปเดตข้อมูลสำหรับการเรียกเก็บเงิน หากต้องการแก้ไขข้อมูลผู้ใช้ วิดเจ็ตที่ฝังอาจต้องเข้าถึงคุกกี้ของตัวเองขณะที่ฝังอยู่ใน website.example ในกรณีที่ควรแยกข้อมูลนี้ไว้website.example CHIPS จะช่วยให้มั่นใจได้ว่าการฝังจะสามารถเข้าถึงข้อมูลที่ต้องการ เมื่อใช้ CHIPS subscriptions.example
วิดเจ็ตที่ฝังใน website.example จะไม่มีสิทธิ์เข้าถึงข้อมูลการสมัครใช้บริการของผู้ใช้บนเว็บไซต์อื่นๆ
ลองพิจารณาอีกกรณีหนึ่ง: มีวิดีโอจาก streaming.example ฝังอยู่ใน website.example และผู้ใช้มีการสมัครใช้บริการ streaming.example แบบพรีเมียม ซึ่งวิดเจ็ตจำเป็นต้องทราบเพื่อปิดใช้โฆษณา หากต้องมีการเข้าถึงคุกกี้เดียวกันในหลายเว็บไซต์ ให้พิจารณาใช้ Storage Access API หากผู้ใช้เคยเข้าชม streaming.example เป็นระดับบนสุด และชุดเว็บไซต์ที่เกี่ยวข้อง หากชุด website.example เป็นเจ้าของ streaming.example
ตั้งแต่ Chrome 131 เป็นต้นไป FedCM จะผสานรวมกับ Storage Access API เมื่อผสานรวมแล้ว เมื่อผู้ใช้ยอมรับข้อความแจ้งของ FedCM เบราว์เซอร์จะให้สิทธิ์การฝัง IdP เข้าถึงพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชัน
ดูข้อมูลเพิ่มเติมเกี่ยวกับ API ที่ควรเลือกเพื่อจัดการเส้นทางของผู้ใช้ที่เฉพาะเจาะจงซึ่งมีเนื้อหาที่ฝังได้ที่คู่มือการฝัง
เส้นทางของผู้ใช้อื่นๆ
เส้นทางของผู้ใช้ที่ไม่ได้ใช้คุกกี้ของบุคคลที่สามจะไม่ได้รับผลกระทบจากการเปลี่ยนแปลงวิธีที่ Chrome จัดการคุกกี้ของบุคคลที่สาม โซลูชันที่มีอยู่ เช่น การลงชื่อเข้าใช้ การลงชื่อออก หรือการกู้คืนบัญชีในบริบทของบุคคลที่หนึ่ง 2FA ควรทำงานได้ตามที่ต้องการ เราได้อธิบายจุดที่อาจเกิดข้อขัดข้องไปแล้วก่อนหน้านี้ ดูข้อมูลเพิ่มเติมเกี่ยวกับ API หนึ่งๆ ได้ที่หน้าสถานะ API รายงานปัญหาการหยุดทำงานที่พบไปที่ goo.gle/report-3pc-broken นอกจากนี้ คุณยังส่งแบบฟอร์มความคิดเห็นหรือแจ้งปัญหาใน GitHub ได้ที่ที่เก็บข้อมูลการสนับสนุนนักพัฒนาซอฟต์แวร์ของ Privacy Sandbox
ตรวจสอบเว็บไซต์
หากเว็บไซต์ของคุณใช้เส้นทางของผู้ใช้อย่างใดอย่างหนึ่งที่อธิบายไว้ในคู่มือนี้ คุณจะต้องตรวจสอบว่าเว็บไซต์พร้อมใช้งาน โดยตรวจสอบเว็บไซต์เพื่อหาการใช้คุกกี้ของบุคคลที่สาม ทดสอบเพื่อหาข้อบกพร่อง และเปลี่ยนไปใช้โซลูชันที่แนะนํา