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

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

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

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

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

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

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

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

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

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

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

ออกและแลกโทเค็น

การใช้งาน PST มี 3 ระยะ ดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ก่อนที่จะใช้ PST เราขอแนะนำให้คุณเริ่มต้นใช้งานเดโม

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

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

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

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

ตั้งค่าเพื่อการนำไปใช้

ส่วนนี้จะอธิบายข้อกำหนดในการเป็นผู้ออกหรือผู้แลกรับ PST

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 // 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: ปลายทางที่จะจัดการการแลกรับโทเค็นทั้งหมด ซึ่งจะเป็นจุดสิ้นสุดที่คอมโพเนนต์ตัวแลกโทเค็นจะผสานรวม
  • โค้ดตัวอย่าง ใน GitHub
  • สาธิต

ส่งการเรียกไปยังเซิร์ฟเวอร์ตัวแลกรับข้อเสนอ

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

    // 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 ใน 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 DevTools

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

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

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

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

หากฟังก์ชันที่สำคัญของเว็บไซต์ขึ้นอยู่กับผู้ออกโทเค็นบางราย ให้จัดลำดับความสำคัญของผู้ออกโทเค็นเหล่านั้น เรียกใช้ 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 เพื่อทำความเข้าใจรายละเอียดเพิ่มเติม
   5. อ่านเพิ่มเติมเกี่ยวกับข้อกำหนดปัจจุบันของ API
2. ร่วมสนทนาโดยใช้ปัญหาใน GitHub หรือการประชุมของ W3C
3. หากต้องการทำความเข้าใจคำศัพท์ใดๆ ให้ดียิ่งขึ้น โปรดดูอภิธานศัพท์ของ Privacy Sandbox
4. ดูข้อมูลเพิ่มเติมเกี่ยวกับแนวคิดของ Chrome เช่น "ช่วงทดลองใช้จากต้นทาง" หรือ "Chrome Flag" ได้จากวิดีโอและบทความสั้นๆ ที่มีให้ที่ goo.gle/cc