ที่ผ่านมามีการใช้คุกกี้ของบุคคลที่สามเพื่อจัดเก็บและถ่ายทอดข้อมูล เกี่ยวกับสถานะของผู้ใช้ เช่น สถานะการลงชื่อเข้าใช้ ข้อมูลเกี่ยวกับอุปกรณ์ ผู้ใช้ใช้หรือไม่ หรือเป็นที่รู้จักและเชื่อถือ ตัวอย่างเช่น ไม่ว่า ลงชื่อเข้าใช้ด้วย SSO แล้ว ไม่ว่าผู้ใช้จะเป็นประเภทที่มีความเข้ากันได้หรือไม่ หรือไม่ หรือรู้จักและเชื่อถือผู้ใช้ไหม ด้วย เราจะเลิกรองรับคุกกี้ของบุคคลที่สาม กรณีการใช้งานจำนวนมากเหล่านี้ต้องได้รับการสนับสนุนด้วยวิธีอื่น
โทเค็นสถานะส่วนตัวมีวิธีการแชร์ข้อมูลทั่วทั้งเว็บ แต่ แบบรักษาความเป็นส่วนตัวผ่านการควบคุมจำนวนข้อมูลที่สามารถ แชร์ได้
โทเค็นสถานะส่วนตัว (เดิมเรียกว่า Trust Tokens) จะช่วยให้เชื่อถือใน ความถูกต้องในการถ่ายทอดจากบริบทหนึ่งไปยังอีกบริบทหนึ่ง ในขณะเดียวกันก็ช่วยให้เว็บไซต์ ต่อสู้กับการประพฤติมิชอบและแยกบ็อตออกจากมนุษย์ที่มีตัวตนจริง โดยไม่ต้องมีการติดตามเชิงรับ
เอกสารนี้แสดงรายละเอียดทางเทคนิคสำหรับการติดตั้งใช้งานสถานะส่วนตัว โทเค็น (PST) หากต้องการดูโครงร่างระดับสูงเพิ่มเติม โปรดดู ภาพรวม PST
โทเค็นสถานะส่วนตัวทำงานอย่างไร
ความสัมพันธ์หลักที่ต้องทำความเข้าใจใน PST คือระหว่างผู้ออกบัตรกับผู้แลกสิทธิ์ ผู้ออกบัตรและผู้แลกอาจอยู่ในบริษัทเดียวกัน
- ผู้ออกใบรับรอง - เอนทิตีเหล่านี้มีสัญญาณบางอย่างเกี่ยวกับผู้ใช้ (สําหรับ เช่น ผู้ใช้นั้นเป็นบ็อตหรือไม่) และฝังสัญญาณนั้นลงใน โทเค็นที่จัดเก็บในอุปกรณ์ของผู้ใช้ (ดูรายละเอียดเพิ่มเติมในส่วนถัดไป)
- ผู้แลกสิทธิ์ - เอนทิตีเหล่านี้อาจไม่มีสัญญาณเกี่ยวกับผู้ใช้ แต่ จำเป็นต้องทราบบางอย่างเกี่ยวกับผู้ใช้ (เช่น ผู้ใช้รายนั้นเป็นบ็อตหรือไม่ หรือไม่) และขอให้แลกโทเค็นจากผู้ออกเพื่อทำความเข้าใจ ความน่าเชื่อถือของผู้ใช้รายนั้น
การโต้ตอบผ่าน PST ทุกครั้งกำหนดให้ผู้ออกบัตรและผู้แลกสิทธิ์ทำงานร่วมกันเพื่อแชร์ สัญญาณทั่วทั้งอินเทอร์เน็ต สัญญาณเหล่านั้นเป็นค่าคร่าวๆ ที่ไม่มีรายละเอียด ในการระบุตัวบุคคล
โทเค็นสถานะส่วนตัวเหมาะกับฉันไหม
บริษัทที่ทำการตัดสินใจเกี่ยวกับความน่าเชื่อถือและต้องการข้อมูลนั้น ที่มาจากบริบทต่างๆ อาจได้รับประโยชน์จาก PST ดูข้อมูลเพิ่มเติมเกี่ยวกับกรณีการใช้งานที่อาจเกิดขึ้น PST โปรดดูเอกสารประกอบเกี่ยวกับกรณีการใช้งาน PST
ออกและแลกโทเค็น
การใช้งาน PST แบ่งออกเป็น 3 ระยะดังนี้
- โทเค็นการออก
- การแลกสิทธิ์โทเค็น
- การส่งต่อระเบียนการแลกสิทธิ์
ในระยะแรก จะมีการออกโทเค็นไปยังเบราว์เซอร์ (โดยปกติจะเกิดขึ้นหลังจาก การตรวจสอบความถูกต้อง) ในระยะที่ 2 บุคคลอื่นจะส่งคำขอแลกสิทธิ์ โทเค็นที่ออกเพื่ออ่านค่าในโทเค็นนั้น รอบชิงชนะเลิศ เฟส ฝ่ายที่แลกสิทธิ์จะได้รับบันทึกการแลกสิทธิ์ (RR) ที่มีมูลค่า ที่อยู่ในโทเค็น จากนั้นฝ่ายที่แลกสิทธิ์จะสามารถใช้ระเบียนนั้นเป็น เอกสารรับรองของผู้ใช้เพื่อวัตถุประสงค์ต่างๆ
กำหนดกลยุทธ์โทเค็น
หากต้องการกำหนดกลยุทธ์โทเค็น คุณจะต้องทำความเข้าใจแนวคิดหลักของ PST (โทเค็น และบันทึกการแลกสิทธิ์) ตัวแปร ลักษณะการทำงาน และข้อจำกัดต่างๆ เพื่อให้สามารถ คำนึงถึงการใช้งานที่เป็นไปได้ของกรณีการใช้งานของคุณ
โทเค็นและบันทึกการแลกสิทธิ์: แต่ละโทเค็นสัมพันธ์กันอย่างไร
อุปกรณ์แต่ละเครื่องสามารถจัดเก็บโทเค็นได้สูงสุด 500 รายการต่อเว็บไซต์และผู้ออกระดับบนสุด และ โทเค็นแต่ละรายการจะมีข้อมูลเมตาที่แจ้งว่าคีย์ใดที่ผู้ออกบัตรใช้ในการออกโทเค็น นั่น สามารถใช้ข้อมูลที่กำหนดว่าจะแลกสิทธิ์หรือไม่แลกโทเค็นในระหว่างการแลกสิทธิ์ ขั้นตอนได้ ข้อมูล PST จะได้รับการจัดเก็บภายในโดยเบราว์เซอร์ในอุปกรณ์ของผู้ใช้ และ สามารถเข้าถึงได้โดย PST API เท่านั้น
เมื่อแลกสิทธิ์โทเค็นแล้ว ระบบจะจัดเก็บบันทึกการแลกสิทธิ์ (RR) ไว้ในอุปกรณ์ พื้นที่เก็บข้อมูลนี้ทำหน้าที่เป็นแคชสำหรับการแลกสิทธิ์ในอนาคต จำกัดไว้ที่ 2 การแลกสิทธิ์โทเค็นทุก 48 ชั่วโมงต่ออุปกรณ์ หน้าเว็บ และผู้ออก การแลกสิทธิ์ใหม่ จะใช้ RR ที่แคชไว้เมื่อเป็นไปได้ แทนการสร้างคำขอไปยัง ผู้ออกบัตร
- ระบบจะออกโทเค็นใหม่ (สูงสุด 500 รายการต่อผู้ออก เว็บไซต์ และอุปกรณ์)
- โทเค็นทั้งหมดจะจัดเก็บอยู่ที่ที่เก็บโทเค็นในอุปกรณ์ (คล้ายกับการจัดเก็บคุกกี้)
- หากไม่พบ RR ที่ใช้งานอยู่ สามารถสร้าง RR ใหม่หลังจากการออก (สูงสุด 2 ครั้งต่อ 48 ชั่วโมง)
- RR จะถือว่าใช้งานได้จนกว่าจะหมดอายุและจะใช้ RR เป็นแพ็กเกจภายใน แคช
- การเรียกใช้การแลกสิทธิ์ใหม่จะเข้าสู่แคชในเครื่อง (ไม่มีการสร้าง RR ใหม่)
หลังจากกำหนด Use Case แล้ว คุณต้องกำหนดอายุการใช้งานของ RR อย่างละเอียดดังนี้ ซึ่งจะกำหนดจำนวนครั้งที่คุณจะสามารถใช้หน่วยโฆษณา
โปรดทำความเข้าใจพฤติกรรมและตัวแปรที่สำคัญต่อไปนี้ก่อน การกำหนดกลยุทธ์
| ตัวแปร / ลักษณะการทำงาน | คำอธิบาย | การใช้งานที่เป็นไปได้ |
|---|---|---|
| ข้อมูลเมตาของคีย์โทเค็น | แต่ละโทเค็นสามารถออกโดยใช้คีย์การเข้ารหัสได้เพียงหนึ่งคีย์เท่านั้นและ ใน 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 พร้อมธงเพื่อเปิดใช้งานโปรแกรมสาธิต ความมุ่งมั่นที่สำคัญ (ทำตามคำแนะนำในการสาธิต )
การเรียกใช้เดโมนี้แสดงว่าเบราว์เซอร์ของคุณกำลังใช้ผู้ออกเดโมและผู้แลกสิทธิ์ เซิร์ฟเวอร์ในการมอบและใช้โทเค็น
ข้อควรพิจารณาด้านเทคนิค
เดโมจะทำงานได้ดีที่สุดหากคุณทำตามขั้นตอนต่อไปนี้
- อย่าลืมหยุดอินสแตนซ์ของ Chrome ทั้งหมดก่อนที่จะเรียกใช้ Chrome ที่มี Flag
- หากคุณใช้เครื่อง Windows โปรดดูที่ ไว้ใน คู่มือนี้ ในการส่งพารามิเตอร์ไปยังไบนารีที่ดำเนินการได้ของ Chrome
- เปิดเครื่องมือสำหรับนักพัฒนาเว็บใน Chrome ในแอปพลิเคชัน > พื้นที่เก็บข้อมูล > รัฐส่วนบุคคล โทเค็นขณะใช้แอปพลิเคชันเดโมเพื่อดูโทเค็นที่ออก/แลกสิทธิ์แล้ว โดยผู้ออกเดโม
ตั้งค่าเพื่อนำไปใช้
ร่วมเป็นผู้ออก
ผู้ออกใบรับรองมีบทบาทสำคัญใน PST โดยจะกำหนดค่าให้กับโทเค็นเพื่อกำหนด ผู้ใช้เป็นบ็อตหรือไม่ หากต้องการเริ่มต้นใช้งาน PST ในฐานะผู้ออก คุณดำเนินการดังนี้ จะต้องลงทะเบียนโดยกรอก ขั้นตอนการลงทะเบียนผู้ออกบัตร
หากต้องการสมัครเพื่อเป็นผู้ออก ผู้ดำเนินการของเว็บไซต์ผู้ออกบัตรต้องเปิด ปัญหาในGitHub โดยใช้ช่อง "PST ใหม่" ผู้ออกใบรับรอง" เทมเพลต ทำตามคำแนะนำในที่เก็บเพื่อกรอกข้อมูลปัญหา เมื่อยืนยันปลายทางแล้ว ระบบจะผสานรวมปลายทางดังกล่าวเข้ากับที่เก็บนี้และ โครงสร้างพื้นฐานฝั่งเซิร์ฟเวอร์ของ Chrome จะเริ่มดึงข้อมูลคีย์เหล่านั้น
เซิร์ฟเวอร์ผู้ออก
ผู้ออกบัตรและผู้แลกคือผู้ดำเนินการที่สำคัญสำหรับ PST เซิร์ฟเวอร์และโทเค็นคือคีย์ สำหรับ PST แม้ว่าเราจะได้ให้รายละเอียดบางส่วนเกี่ยวกับโทเค็นและใน เอกสารประกอบของ GitHub เราต้องการให้ ให้รายละเอียดเพิ่มเติมเกี่ยวกับเซิร์ฟเวอร์ PST หากต้องการตั้งค่าเป็นผู้ออก PST คุณต้องมีสิ่งต่อไปนี้ เพื่อตั้งค่าเซิร์ฟเวอร์ที่ออกบัตรก่อน
ทำให้สภาพแวดล้อมใช้งานได้: เซิร์ฟเวอร์ของผู้ให้บริการ
หากต้องการใช้เซิร์ฟเวอร์ผู้ออกโทเค็น คุณจะต้องสร้างฝั่งเซิร์ฟเวอร์ของคุณเอง ที่เปิดเผยปลายทาง HTTP
องค์ประกอบของผู้ออกใบรับรองประกอบด้วยโมดูลหลัก 2 โมดูล ได้แก่ (1) เซิร์ฟเวอร์ผู้ออก และ (2) ผู้ออกโทเค็น
เช่นเดียวกับแอปพลิเคชันที่ใช้งานผ่านเว็บทั้งหมด เราขอแนะนำการป้องกันเพิ่มเติมอีกชั้นหนึ่ง ไปยังเซิร์ฟเวอร์ผู้ออกบัตร
เซิร์ฟเวอร์ผู้ออก: ในการใช้งานตัวอย่างของเรา เซิร์ฟเวอร์ที่ออกใบรับรองของเราคือ เซิร์ฟเวอร์ Node.js ที่ใช้เฟรมเวิร์ก Express เพื่อโฮสต์ ปลายทาง HTTP ของผู้ออก ดูโค้ดตัวอย่างใน GitHub
ผู้ออกโทเค็น: คอมโพเนนต์การเข้ารหัสของผู้ออกไม่จำเป็นต้องใช้ ภาษาที่เฉพาะเจาะจง แต่เนื่องจาก ข้อกำหนดด้านประสิทธิภาพของคอมโพเนนต์นี้ เราจะยกตัวอย่างการใช้ C เป็นตัวอย่าง โดยใช้แป้นพิมพ์ลัด ไลบรารี SSL สำหรับจัดการโทเค็น คุณสามารถค้นหาตัวอย่างรหัสผู้ออกบัตรและข้อมูลเพิ่มเติมเกี่ยวกับการติดตั้ง ใน GitHub
คีย์: คอมโพเนนต์ผู้ออกโทเค็นใช้คีย์ EC ที่กำหนดเองเพื่อเข้ารหัสโทเค็น โดยคีย์เหล่านี้ต้องได้รับการป้องกันและจัดเก็บไว้ในพื้นที่เก็บข้อมูลที่ปลอดภัย
ข้อกำหนดทางเทคนิคสำหรับเซิร์ฟเวอร์ผู้ออกบัตร
ตามโปรโตคอล คุณจะต้องใช้ปลายทาง HTTP อย่างน้อย 2 จุดใน เซิร์ฟเวอร์ผู้ออกบัตรของคุณ:
- สัญญาผูกมัดคีย์ (เช่น
/.well-known/private-state-token/key-commitment): ปลายทางนี้คือที่ที่เบราว์เซอร์จะเข้าถึงรายละเอียดคีย์สาธารณะของการเข้ารหัสได้ ว่าเซิร์ฟเวอร์ของคุณถูกต้องตามกฎหมาย - การออกโทเค็น (เช่น
/.well-known/private-state-token/issuance): ปลายทางการออกโทเค็นที่ระบบจะจัดการคำขอโทเค็นทั้งหมด ช่วงเวลานี้ ปลายทางจะเป็นจุดผสานรวมสำหรับคอมโพเนนต์ผู้ออกโทเค็น
ดังที่ได้กล่าวไว้ก่อนหน้านี้ เนื่องจากคาดว่าเซิร์ฟเวอร์นี้จะมีปริมาณการเข้าชมสูง เราขอแนะนำให้คุณทำให้ใช้งานได้โดยใช้ โครงสร้างพื้นฐานของ Google (เช่น ในสภาพแวดล้อมระบบคลาวด์) เพื่อให้สามารถปรับ โดยอิงตามความต้องการที่เปลี่ยนแปลงได้
ส่งการเรียกไปยังเซิร์ฟเวอร์ของผู้ออกบัตร
ใช้การเรียกการดึงข้อมูลเว็บไซต์กับสแต็กผู้ออกบัตรของคุณเพื่อขอ โทเค็น
// issuer request
await fetch("/.well-known/private-state-token/issuance", {
method: "POST",
privateToken: {
version: 1,
operation: "token-request"
}
});
เซิร์ฟเวอร์ผู้แลกสิทธิ์
คุณจะต้องใช้บริการแลกสิทธิ์โทเค็นด้วยการสร้างบริการ แอปพลิเคชันฝั่งเซิร์ฟเวอร์ วิธีนี้จะช่วยให้คุณอ่านโทเค็นที่ผู้ออกบัตร ส่ง ขั้นตอนต่อไปนี้จะสรุปวิธีแลกสิทธิ์โทเค็นและวิธีอ่าน ระเบียนการแลกสิทธิ์ที่เชื่อมโยงกับโทเค็นเหล่านั้น
คุณสามารถเลือกเรียกใช้ผู้ออกบัตรและผู้แลกสิทธิ์ในเซิร์ฟเวอร์เดียวกัน (หรือกลุ่มของ เซิร์ฟเวอร์)
ข้อกำหนดทางเทคนิคสำหรับเซิร์ฟเวอร์ผู้แลกสิทธิ์
ตามโปรโตคอล คุณจะต้องใช้ปลายทาง 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>]
}
});
ติดตั้งใช้งาน
หากต้องการทดสอบการติดตั้งใช้งาน ก่อนอื่นให้ไปที่หน้าเว็บที่ออก และทำการเรียกและยืนยันว่าโทเค็นสร้างขึ้นตามตรรกะของคุณ ตรวจสอบในแบ็กเอนด์ว่าการเรียกเกิดขึ้นตามข้อกำหนด จากนั้นไปที่หน้าเว็บที่มีการโทรเพื่อแลกสิทธิ์ แล้วยืนยันว่า ระบบจะสร้าง RR ตามตรรกะของคุณ
การนำไปใช้งานในชีวิตจริง
เราขอแนะนำให้คุณเลือกเว็บไซต์เป้าหมายซึ่งเป็นส่วนหนึ่งของการใช้งานเฉพาะของคุณ กรณี:
- จำนวนการเข้าชมต่อเดือนน้อย (ประมาณ <1 ล้านครั้ง/เดือน): คุณ ควรเริ่มด้วยการทำให้ API ใช้งานได้กับกลุ่มเป้าหมายขนาดเล็กก่อน
- คุณเป็นเจ้าของและควบคุมทุกอย่าง: หากจำเป็น คุณสามารถปิดใช้งาน การใช้งานโดยไม่ต้องมีการอนุมัติที่ซับซ้อน
- ผู้ออกบัตรไม่เกิน 1 ราย: หากต้องการจำกัดจำนวนโทเค็นเพื่อวัตถุประสงค์ต่อไปนี้ ทำให้การทดสอบง่ายขึ้น
- ผู้มีสิทธิ์แลกสิทธิ์ไม่เกิน 2 ราย: คุณต้องทำให้การแก้ปัญหาง่ายขึ้นใน ให้กับโจทย์
นโยบายสิทธิ์
PST API ต้องพร้อมใช้งานในหน้าระดับบนสุดและทรัพยากรย่อยใดๆ ที่ใช้ API เพื่อให้ทำงานได้อย่างถูกต้อง
การดำเนินการขอโทเค็นควบคุมโดยคำสั่ง private-state-token-issuance การดำเนินการ token-redemption และ send-redemption-record ควบคุมโดยคำสั่ง private-state-token-redemption โดยค่าเริ่มต้น รายการที่อนุญาตสำหรับคำสั่งเหล่านี้จะได้รับการตั้งค่าเป็นด้วยตนเอง ซึ่งหมายความว่าฟีเจอร์นี้ใช้ได้เฉพาะกับหน้าเว็บระดับบนสุด (และ 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
- โครงสร้างพื้นฐานต้องพร้อมรับมือกับปริมาณการเข้าชมที่เปลี่ยนแปลงได้ (รวมถึงช่วงที่เพิ่มขึ้น)
- ตรวจสอบว่าคีย์ได้รับการปกป้องและมีความปลอดภัยและสอดคล้องกับการเข้าถึงของคุณ นโยบายควบคุม กลยุทธ์การจัดการหลัก และแผนความต่อเนื่องทางธุรกิจ
- เพิ่มเมตริกความสามารถในการสังเกตให้กับสแต็กเพื่อให้แน่ใจว่าคุณจะมี การแสดงผลเพื่อทำความเข้าใจเกี่ยวกับการใช้งาน จุดคอขวด และปัญหาด้านประสิทธิภาพหลังจาก สู่เวอร์ชันที่ใช้งานจริง
ข้อมูลเพิ่มเติม
- ดูเอกสารของนักพัฒนาซอฟต์แวร์:
- เริ่มต้นด้วยการอ่าน ภาพรวม เพื่อเตรียมความพร้อมสำหรับ PST และความสามารถของ PST
- ดูวิดีโอแนะนำการเป็นสมาชิก PST
- ลองใช้การสาธิต PST
- อ่าน API เพิ่มเติม explainer เพื่อให้เข้าใจมากขึ้น รายละเอียดเกี่ยวกับเรื่องนี้
- อ่านเพิ่มเติมเกี่ยวกับ ข้อกำหนดของ API
- มีส่วนร่วมในการสนทนาผ่าน GitHub ปัญหาหรือ W3C การโทร
- ในการทำความเข้าใจคำศัพท์ต่างๆ ให้ดียิ่งขึ้น โปรดอ่าน อภิธานศัพท์ของ Privacy Sandbox
- ดูข้อมูลเพิ่มเติมเกี่ยวกับแนวคิดของ Chrome เช่น "ช่วงทดลองใช้จากต้นทาง" หรือ "ธงของ Chrome" ให้รีวิววิดีโอสั้นๆ และบทความจาก goo.gle/cc