คู่มือนักพัฒนาซอฟต์แวร์สำหรับโทเค็นสถานะส่วนตัว

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

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

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

เอกสารนี้ระบุรายละเอียดทางเทคนิคในการใช้งานโทเค็นสถานะส่วนตัว (PST) ดูภาพรวมระดับสูงเพิ่มเติมได้ที่ภาพรวม PST

โทเค็นสถานะส่วนตัวทํางานอย่างไร

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

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

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

โทเค็นสถานะส่วนตัวเหมาะกับฉันไหม

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

ออกและแลกสิทธิ์โทเค็น

การติดตั้งใช้งาน PST แบ่งออกเป็น 3 ระยะ ดังนี้

1. การสร้างโทเค็น
2. การแลกสิทธิ์รับโทเค็น
3. การส่งต่อบันทึกการแลกสิทธิ์

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

กําหนดกลยุทธ์โทเค็น

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

โทเค็นและบันทึกการแลกสิทธิ์มีความสัมพันธ์กันอย่างไร

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

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

1. ระบบจะออกโทเค็นใหม่ (สูงสุด 500 รายการต่อผู้ออก เว็บไซต์ และอุปกรณ์)
2. ระบบจะจัดเก็บโทเค็นทั้งหมดไว้ในที่เก็บโทเค็นในอุปกรณ์ (คล้ายกับที่เก็บคุกกี้)
3. หากไม่พบ RR ที่ใช้งานอยู่ คุณสามารถสร้าง RR ใหม่ได้หลังจากการออก (สูงสุด 2 รายการทุก 48 ชั่วโมง)
4. ระบบจะถือว่า RR ใช้งานได้จนกว่าจะหมดอายุ และจะใช้เป็นแคชในเครื่อง
5. การเรียกใช้การแลกสิทธิ์ใหม่จะเข้าสู่แคชในเครื่อง (ไม่มีการสร้างขึ้นใหม่)

หลังจากกําหนด Use Case แล้ว คุณต้องกําหนดอายุการใช้งานของ RR อย่างรอบคอบ เนื่องจากค่านี้จะเป็นตัวกําหนดจํานวนครั้งที่คุณจะใช้ RR ใน Use Case ได้

โปรดทําความเข้าใจพฤติกรรมและตัวแปรที่สําคัญต่อไปนี้ก่อนกําหนดกลยุทธ์

ตัวแปร / ลักษณะการทำงาน	คำอธิบาย	การใช้งานที่เป็นไปได้
ข้อมูลเมตาของคีย์โทเค็น	โทเค็นแต่ละรายการจะออกได้โดยใช้คีย์เข้ารหัสเพียง 1 คีย์เท่านั้น และ PST จำกัดคีย์ไว้ที่ 6 คีย์ต่อผู้ออก	วิธีหนึ่งที่ใช้ตัวแปรนี้ได้คือการกำหนดช่วงความน่าเชื่อถือของโทเค็นตามคีย์การเข้ารหัส (เช่น คีย์ 1 = ความน่าเชื่อถือสูง ส่วนคีย์ 6 = ไม่เชื่อถือ)
วันที่หมดอายุของโทเค็น	วันที่หมดอายุของโทเค็นจะเหมือนกับวันที่หมดอายุของคีย์	คุณหมุนเวียนคีย์ได้อย่างน้อยทุก 60 วัน และโทเค็นทั้งหมดที่ออกด้วยคีย์ที่ไม่ถูกต้องจะถือว่าไม่ถูกต้องด้วย
ขีดจํากัดอัตราการแลกสิทธิ์รับโทเค็น	การแลกสิทธิ์รับโทเค็นมีขีดจำกัดอยู่ที่ 2 ครั้งต่ออุปกรณ์และผู้ออกบัตรทุกๆ 48 ชั่วโมง	ขึ้นอยู่กับจำนวนการแลกสิทธิ์โดยประมาณที่ต้องใช้ในแต่ละกรณีทุก 48 ชั่วโมง
จำนวนผู้ออกบัตรสูงสุดต่อต้นทางระดับบนสุด	ปัจจุบันจำนวนผู้ออกบัตรสูงสุดต่อต้นทางระดับบนสุดคือ 2 ราย	กำหนดผู้ออกแต่ละหน้าอย่างละเอียด
โทเค็นต่อผู้ออกบัตรในอุปกรณ์	ปัจจุบันจำนวนโทเค็นสูงสุดต่อผู้ออกบัตรในอุปกรณ์หนึ่งๆ คือ 500 รายการ	ตรวจสอบว่าจำนวนโทเค็นไม่เกิน 500 รายการต่อผู้ออก ตรวจสอบว่าคุณจัดการข้อผิดพลาดในหน้าเว็บเมื่อพยายามออกโทเค็น
การหมุนเวียนความมุ่งมั่นที่สำคัญ	ผู้ออก PST ทุกรายต้องแสดงปลายทางที่มีข้อตกลงเกี่ยวกับคีย์ที่เปลี่ยนแปลงได้ทุก 60 วัน และระบบจะไม่สนใจการหมุนเวียนที่เร็วกว่านั้น	หากคีย์ของคุณจะหมดอายุในอีกไม่ถึง 60 วัน คุณจะต้องอัปเดตความมุ่งมั่นเกี่ยวกับคีย์ก่อนวันที่ดังกล่าวเพื่อหลีกเลี่ยงการหยุดชะงัก (ดูรายละเอียด)
อายุของบันทึกการแลกสิทธิ์	คุณสามารถกําหนดอายุการใช้งานของ RR เพื่อระบุวันที่หมดอายุได้ เนื่องจากระบบจะแคช RR เพื่อหลีกเลี่ยงการโทรขอแลกสิทธิ์ใหม่ที่ไม่จำเป็นไปยังผู้ออกบัตร จึงจำเป็นต้องตรวจสอบว่ามีสัญญาณการแลกสิทธิ์ที่ใหม่พอ	เนื่องจากมีการจำกัดอัตราการแลกสิทธิ์ไว้ที่ 2 โทเค็นทุก 48 ชั่วโมง คุณจึงควรกำหนดอายุของ RR เพื่อให้เรียกใช้การแลกสิทธิ์ได้สําเร็จอย่างน้อยในช่วงเวลานี้ (ควรตั้งค่าอายุของ RR ให้สอดคล้องกัน) ขอแนะนําให้ตั้งค่าอายุการใช้งานนี้ตามลําดับสัปดาห์

ตัวอย่างสถานการณ์

สถานการณ์ #1: อายุ RR น้อยกว่า 24 ชั่วโมง (t=t) และการแลกสิทธิ์เกิดขึ้นหลายครั้งในช่วง 48 ชั่วโมง

สถานการณ์ #2: อายุของ RR คือ 24 ชั่วโมง และมีการแลกสิทธิ์หลายครั้งในกรอบเวลา 48 ชั่วโมง

สถานการณ์ #3: อายุการใช้งานของ RR คือ 48 ชั่วโมง และมีการแลกสิทธิ์หลายครั้งในช่วง 48 ชั่วโมง

เรียกใช้เดโม

ก่อนใช้ PST เราขอแนะนำให้ตั้งค่าการสาธิตก่อน หากต้องการลองใช้การสาธิต PST คุณจะต้องเรียกใช้ Chrome ด้วย Flag เพื่อเปิดใช้ข้อผูกมัดหลักของผู้ออกการสาธิต (ทำตามวิธีการในหน้าการสาธิต)

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

ข้อควรพิจารณาด้านเทคนิค

การแสดงตัวอย่างจะทำงานได้ดีที่สุดหากคุณทำตามขั้นตอนต่อไปนี้

• โปรดตรวจสอบว่าคุณหยุดอินสแตนซ์ Chrome ทั้งหมดแล้วก่อนที่จะเรียกใช้ Chrome ด้วย Flag
• หากคุณใช้เครื่อง Windows โปรดดู คำแนะนำนี้เกี่ยวกับวิธีส่งพารามิเตอร์ไปยังไบนารีที่เรียกใช้งานได้ของ Chrome
• เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ในส่วนแอปพลิเคชัน > พื้นที่เก็บข้อมูล > โทเค็นสถานะส่วนตัวขณะใช้แอปพลิเคชันเดโมเพื่อดูโทเค็นที่ออก/แลกสิทธิ์โดยผู้ออกเดโม

ตั้งค่าเพื่อใช้งาน

เป็นผู้ออกบัตร

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

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

เซิร์ฟเวอร์ของผู้ออกใบรับรอง

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

ติดตั้งใช้งานสภาพแวดล้อม: เซิร์ฟเวอร์ผู้ออกบัตร

หากต้องการใช้เซิร์ฟเวอร์ผู้ออกโทเค็น คุณจะต้องสร้างแอปพลิเคชันฝั่งเซิร์ฟเวอร์ของคุณเองที่แสดงปลายทาง HTTP

คอมโพเนนต์ผู้ออกประกอบด้วยโมดูลหลัก 2 รายการ ได้แก่ (1) เซิร์ฟเวอร์ผู้ออก และ (2) ผู้ออกโทเค็น

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

1. เซิร์ฟเวอร์ผู้ออกบัตร: ในตัวอย่างการใช้งาน เซิร์ฟเวอร์ผู้ออกบัตรของเราคือเซิร์ฟเวอร์ Node.js ที่ใช้เฟรมเวิร์ก Express เพื่อโฮสต์ปลายทาง HTTP ของผู้ออกบัตร คุณสามารถดูโค้ดตัวอย่างบน GitHub

2. ผู้ออกโทเค็น: คอมโพเนนต์การเข้ารหัสของผู้ออกโทเค็นไม่จำเป็นต้องใช้ภาษาใดภาษาหนึ่งโดยเฉพาะ แต่เนื่องจากข้อกำหนดด้านประสิทธิภาพของคอมโพเนนต์นี้ เราจึงแสดงตัวอย่างการใช้งาน C ที่ใช้ไลบรารี BoringSSL เพื่อจัดการโทเค็น คุณดูตัวอย่างรหัสผู้ออกบัตรและข้อมูลเพิ่มเติมเกี่ยวกับการติดตั้งได้บน GitHub

3. คีย์: คอมโพเนนต์ผู้ออกโทเค็นใช้คีย์ EC ที่กําหนดเองเพื่อเข้ารหัสโทเค็น คีย์เหล่านี้ต้องได้รับการปกป้องและจัดเก็บไว้ในที่เก็บข้อมูลที่ปลอดภัย

ข้อกำหนดทางเทคนิคสำหรับเซิร์ฟเวอร์ของผู้ออกบัตร

ตามโปรโตคอล คุณจะต้องติดตั้งใช้งานอุปกรณ์ปลายทาง HTTP อย่างน้อย 2 รายการในเซิร์ฟเวอร์ของผู้ออกบัตร

• การคําสัญญาเกี่ยวกับคีย์ (เช่น /.well-known/private-state-token/key-commitment): ปลายทางนี้เป็นปลายทางที่เบราว์เซอร์จะดูรายละเอียดคีย์สาธารณะสําหรับการเข้ารหัสเพื่อยืนยันว่าเซิร์ฟเวอร์ของคุณถูกต้อง
  • ตัวอย่างโค้ด
• การสร้างโทเค็น (เช่น /.well-known/private-state-token/issuance): ปลายทางการสร้างโทเค็นที่จะจัดการคําขอโทเค็นทั้งหมด ปลายทางนี้จะเป็นส่วนที่ผสานรวมสำหรับคอมโพเนนต์ผู้ออกโทเค็น
  • ตัวอย่างโค้ด

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

ส่งการเรียกไปยังเซิร์ฟเวอร์ผู้ออกบัตร

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

 // issuer request
    await fetch("/.well-known/private-state-token/issuance", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "token-request"
      }
    });

ดูตัวอย่างโค้ด

เซิร์ฟเวอร์ Redeemer

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

คุณเลือกที่จะเรียกใช้ผู้ออกบัตรและผู้แลกสิทธิ์ในเซิร์ฟเวอร์เดียวกัน (หรือกลุ่มเซิร์ฟเวอร์) ได้

ข้อกำหนดทางเทคนิคสำหรับเซิร์ฟเวอร์ของผู้แลกสิทธิ์

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

• /.well-known/private-state-token/redemption: ปลายทางที่จัดการการแลกสิทธิ์รับโทเค็นทั้งหมด ปลายทางนี้จะเป็นส่วนที่จะผสานรวมคอมโพเนนต์โปรแกรมแลกสิทธิ์รับโทเค็น
  • ตัวอย่างโค้ด

ส่งการเรียกไปยังเซิร์ฟเวอร์ของผู้แลกสิทธิ์

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

    // redemption request
    await fetch("/.well-known/private-state-token/redemption", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "token-redemption",
        refreshPolicy: "none"
      }
    });

ดูตัวอย่างโค้ด

หลังจากแลกโทเค็นแล้ว คุณสามารถส่งบันทึกการแลกสิทธิ์ (RR) ได้โดยเรียกใช้การเรียกข้อมูลอีกครั้ง ดังนี้

    // attach redemption records from the issuers to the request
    await fetch("<DESTINATION_RESOURCE>", {
      method: "POST",
      privateToken: {
        version: 1,
        operation: "send-redemption-record",
        issuers: [<ISSUER_DOMAIN>]
      }
    });

ดูตัวอย่างโค้ด

ติดตั้งใช้งาน

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

การใช้งานจริง

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

• การเข้าชมรายเดือนจํานวนน้อย (ประมาณ <1 ล้านครั้ง/เดือน): คุณควรเริ่มด้วยการติดตั้งใช้งาน API กับกลุ่มเป้าหมายจํานวนน้อยก่อน
• คุณเป็นเจ้าของและควบคุมได้: หากจำเป็น คุณสามารถปิดใช้การติดตั้งได้อย่างรวดเร็วโดยไม่ต้องขออนุมัติที่ซับซ้อน
• ผู้ออกบัตรไม่เกิน 1 ราย: เพื่อจํากัดจํานวนโทเค็นเพื่อลดความซับซ้อนในการทดสอบ
• ผู้แลกสิทธิ์ไม่เกิน 2 คน: คุณต้องแก้ปัญหาได้ง่ายในกรณีที่เกิดปัญหา

นโยบายสิทธิ์

PST API ต้องพร้อมใช้งานสำหรับหน้าระดับบนสุดและทรัพยากรย่อยที่ใช้ API เพื่อให้ทำงานได้อย่างถูกต้อง

การดำเนินการตามคำขอโทเค็นจะควบคุมโดยคำสั่ง private-state-token-issuance การดำเนินการ token-redemption และ send-redemption-record ควบคุมโดยคำสั่ง private-state-token-redemption ใน Chrome 132 ขึ้นไป ระบบจะตั้งค่ารายการที่อนุญาตสำหรับคำสั่งเหล่านี้เป็น * (ต้นทางทั้งหมด) โดยค่าเริ่มต้น ซึ่งหมายความว่าฟีเจอร์นี้จะพร้อมใช้งานในหน้าระดับบนสุด, iframe ต้นทางเดียวกัน และ iframe แบบข้ามต้นทางโดยไม่ต้องมีการมอบสิทธิ์อย่างชัดเจน

คุณเลือกไม่ใช้การออกหรือแลกสิทธิ์โทเค็น PST สำหรับหน้าเว็บที่เฉพาะเจาะจงในเว็บไซต์ได้โดยใส่ private-state-token-issuance=() และ private-state-token-redemption=() ในส่วนหัว Permissions-Policy ของแต่ละหน้า

นอกจากนี้ คุณยังสามารถใช้ส่วนหัว Permissions-Policy เพื่อควบคุมการเข้าถึง PST ของบุคคลที่สามได้ด้วย ใช้ self และต้นทางที่ต้องการอนุญาตให้เข้าถึง API เป็นพารามิเตอร์ของรายการต้นทางของส่วนหัว เช่น หากต้องการปิดใช้ PST ทั้งหมดในบริบทการท่องเว็บทั้งหมดยกเว้นต้นทางของคุณเองและ https://example.com ให้ตั้งค่าส่วนหัวการตอบกลับ HTTP ต่อไปนี้

Permissions-Policy:private-state-token-issuance=(self "https://example.com"),private-state-token-redemption=(self "https://example.com")

หากต้องการเปิดใช้ API สําหรับทรัพยากรข้ามแหล่งที่มาทั้งหมด ให้ตั้งค่ารายการแหล่งที่มาเป็น *

ดูวิธีควบคุมฟีเจอร์ Privacy Sandbox ด้วยนโยบายสิทธิ์ หรือเจาะลึกนโยบายสิทธิ์

การแก้ปัญหา

คุณสามารถตรวจสอบ PST จากแท็บเครือข่ายและแอปพลิเคชันของเครื่องมือสําหรับนักพัฒนาเว็บใน Chrome

ในแท็บเครือข่าย ให้ทำดังนี้

ในแท็บแอปพลิเคชัน ให้ทำดังนี้

อ่านข้อมูลเพิ่มเติมเกี่ยวกับการผสานรวมกับเครื่องมือสําหรับนักพัฒนาเว็บ

แนวทางปฏิบัติแนะนำสำหรับไคลเอ็นต์

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

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

  // Prioritize your critical token issuer.
  document.hasPrivateToken('https://critical-issuer.example')
    .then(hasToken => {
      if (hasToken) {
        // Use the token or perform actions based on its availability.
      } else {
        // Handle the case where the token is not available.
      }
    });

  // Load third-party scripts or secure another token issuer (up to two in total).

แนวทางปฏิบัติแนะนำและการแก้ปัญหาเกี่ยวกับเซิร์ฟเวอร์

เราขอแนะนําให้ใช้แนวทางปฏิบัติแนะนําต่อไปนี้เพื่อให้เซิร์ฟเวอร์ของผู้ออกบัตรและผู้แลกสิทธิ์ทํางานได้อย่างมีประสิทธิภาพ และเพื่อให้คุณไม่พบปัญหาการเข้าถึง ความปลอดภัย การบันทึก หรือการเข้าชม PST

• อุปกรณ์ปลายทางของคุณต้องใช้วิทยาการเข้ารหัสที่รัดกุมโดยใช้ TLS 1.3 หรือ 1.2
• โครงสร้างพื้นฐานต้องพร้อมรับปริมาณการเข้าชมที่ผันผวน (รวมถึงการเข้าชมที่เพิ่มขึ้นอย่างรวดเร็ว)
• ตรวจสอบว่าคีย์ได้รับการปกป้องและปลอดภัย โดยสอดคล้องกับนโยบายการควบคุมการเข้าถึง กลยุทธ์การจัดการคีย์ และแผนความต่อเนื่องทางธุรกิจ
• เพิ่มเมตริกการสังเกตการณ์ลงในสแต็กเพื่อให้แน่ใจว่าคุณจะมีภาพรวมที่เข้าใจการใช้งาน ปัญหาคอขวด และปัญหาด้านประสิทธิภาพหลังจากเข้าสู่เวอร์ชันที่ใช้งานจริง

ข้อมูลเพิ่มเติม

1. ตรวจสอบเอกสารประกอบสำหรับนักพัฒนาแอป
   1. เริ่มต้นด้วยการอ่านภาพรวมเพื่อทบทวนข้อมูลเกี่ยวกับ PST และความสามารถของ PST
   2. ดูวิดีโอแนะนำ PST
   3. ลองใช้เดโม PST
   4. นอกจากนี้ โปรดอ่านคําอธิบาย API เพื่อให้เข้าใจรายละเอียดเพิ่มเติมเกี่ยวกับ API
   5. อ่านข้อมูลเพิ่มเติมเกี่ยวกับข้อกำหนดปัจจุบันของ API
2. มีส่วนร่วมในการสนทนาผ่านGitHub issues หรือW3C calls
3. หากต้องการทําความเข้าใจคําศัพท์ต่างๆ ให้ดียิ่งขึ้น โปรดดูอภิธานศัพท์ของ Privacy Sandbox
4. หากต้องการดูข้อมูลเพิ่มเติมเกี่ยวกับแนวคิดของ Chrome เช่น "ช่วงทดลองใช้จากต้นทาง" หรือ "Flag ของ Chrome" โปรดดูวิดีโอสั้นๆ และบทความที่มีอยู่ใน goo.gle/cc