เข้าร่วมช่วงทดลองใช้จากต้นทางสำหรับการเข้าถึงพื้นที่เก็บข้อมูลที่ไม่ใช่คุกกี้ผ่าน Storage Access API

Helen Cho
Helen Cho
Ari Chivukula
Ari Chivukula
GitHub

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

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

ในฐานะที่เป็นโซลูชันระยะยาวในการรับมือกับกรณีการใช้งานบางที่หยุดชะงักจากการแบ่งพาร์ติชันพื้นที่เก็บข้อมูลที่ไม่ใช่คุกกี้ของบุคคลที่สาม Chrome ได้เสนอความสามารถให้บุคคลที่สามสามารถขอสิทธิ์เข้าถึงพื้นที่เก็บข้อมูล/การสื่อสาร (ทั้งคุกกี้และไม่ใช่คุกกี้) ผ่าน Storage Access API (การจัดส่งใน Chrome 117) ซึ่งอนุญาตให้บุคคลที่สามขอสิทธิ์เข้าถึงคุกกี้อยู่แล้ว

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

รายละเอียดช่วงทดลองใช้จากต้นทาง

ตั้งแต่ Chrome 120 เป็นต้นไป Chrome จะรองรับช่วงทดลองใช้จากต้นทาง StorageAccessAPIBeyondCookies เพื่อเปิดใช้ส่วนขยายที่เสนอของ Storage Access API (เข้ากันได้แบบย้อนหลัง) เพื่ออนุญาตให้เข้าถึงพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชัน (ทั้งคุกกี้และไม่ใช่คุกกี้) ในบริบทของบุคคลที่สาม

เครื่องกล

API สามารถใช้ได้ดังต่อไปนี้ (JavaScript ทำงานใน iframe ที่ฝัง)

// Request a new storage handle via rSA (this should prompt the user)
const handle = await document.requestStorageAccess({all: true});
// Write some 1P context sessionStorage
handle.sessionStorage.setItem('userid', '1234');
// Write some 1P context localStorage
handle.localStorage.setItem('preference', 'A');
// Open or create an indexedDB that is shared with the 1P context
const messageDB = handle.indexedDB.open('messages');
// Use locks shared with the 1P context
await handle.locks.request('example', ...);

หากต้องการเฉพาะการเข้าถึง API ที่เฉพาะเจาะจงแทนการเข้าถึง all ก็ให้ส่งชื่อเฉพาะแฮนเดิล API ที่ต้องการได้ ตัวอย่างเช่น คุณสามารถส่ง {sessionStorage: true} เพื่อเข้าถึงพื้นที่เก็บข้อมูลของเซสชัน หรือ {indexedDB: true, locks:true} เพื่อรับสิทธิ์เข้าถึง IndexedDB และ Web Lock

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

ระยะเวลา

ช่วงทดลองใช้จากต้นทางจะพร้อมให้ใช้งานตั้งแต่ Chrome 120 จนถึง Chrome 125 (หรือหลังจากวันที่ 6 สิงหาคม 2024 ในทุกเป้าหมาย)

ขอบเขต

มีเพียงพื้นที่เก็บข้อมูล DOM (พื้นที่เก็บข้อมูลเซสชันและพื้นที่เก็บข้อมูลในเครื่อง), DB ที่จัดทำดัชนีแล้ว และ Web Lock เท่านั้นที่พร้อมใช้งานใน Chrome 120

มีการเพิ่มพื้นที่เก็บข้อมูลแคช, ระบบไฟล์ส่วนตัวดั้งเดิม, โควต้า, พื้นที่เก็บข้อมูล Blob และช่องการออกอากาศใน Chrome 121

มีการเพิ่มผู้ปฏิบัติงานที่แชร์และการควบคุมการรวมคุกกี้ใน Chrome 123

ผู้ปฏิบัติงานเฉพาะจะได้รับสิทธิ์เข้าถึงคุกกี้ที่ไม่ได้แบ่งพาร์ติชันหากมีการเรียกใช้ requestStorageAccess ก่อนที่จะสร้างผู้ปฏิบัติงานตั้งแต่ Chrome 120 (ซึ่งไม่จำเป็นต้องใช้แฮนเดิล Storage Access API)

เข้าร่วม

  1. ประเมินวิธีที่คุณใช้คุกกี้และพื้นที่เก็บข้อมูลที่ไม่ใช่คุกกี้ในบริบทของบุคคลที่สาม ตัวอย่างกรณีการใช้งานอาจช่วยให้เข้าใจว่าข้อเสนอนี้เหมาะกับความต้องการของคุณหรือไม่
  2. เปิด Chrome เวอร์ชัน 120 (หรือใหม่กว่า) และตรวจสอบว่าเปิดใช้ Flag test-third-party-cookie-phaseout
  3. หากต้องการทดสอบฟีเจอร์ในเครื่องโดยไม่ต้องตั้งค่าโทเค็นการทดลองใช้ต้นทางก่อน ให้เปิดใช้ #enable-experimental-web-platform-features ในเบราว์เซอร์
    1. เมื่อทดสอบในเครื่องเสร็จแล้ว คุณสามารถregisterสําหรับช่วงทดลองใช้ StorageAccessAPIBeyondCookies จากต้นทางและรับโทเค็นสําหรับโดเมนของคุณ ดูวิธีการที่ละเอียดยิ่งขึ้นได้ที่หัวข้อเริ่มต้นใช้งานช่วงทดลองใช้จากต้นทาง คู่มือการแก้ปัญหาช่วงทดลองใช้จาก Chrome จากต้นทางมีรายการตรวจสอบที่สมบูรณ์เพื่อให้แน่ใจว่าโทเค็นได้รับการกำหนดค่าอย่างถูกต้อง
    2. ฝังโทเค็นช่วงทดลองใช้จากต้นทางนั้นใน iframe ที่ต้องใช้แฮนเดิล Storage Access API ภายใน โดยใช้ส่วนหัว HTTP, เมตาแท็ก HTML หรือแบบเป็นโปรแกรม โปรดทราบว่าโทเค็นต้องฝังโดยเฟรมที่ต้องการใช้ API นี้ การฝังในเฟรมหลักจะไม่เปิดใช้ API ในเฟรมย่อย
  4. เรียกใช้ document.requestStorageAccess(...) เพื่อรับแฮนเดิล Storage Access API ใน iframe แบบข้ามเว็บไซต์ โปรดดูข้อกำหนดเพื่อทำให้การเรียกใช้นี้สำเร็จในเอกสารประกอบของ Storage Access API
  5. ย้ายข้อมูลพื้นที่เก็บข้อมูลที่เกี่ยวข้องใน iframe ของคุณเพื่อใช้แฮนเดิล Storage Access API (หากมี) เช่น การโทรไปยัง window.sessionStorage.setItem(...) จะกลายเป็น handle.sessionStorage.setItem(...)
  6. เปิดเว็บไซต์และยืนยันว่าแฮนเดิลการเข้าถึงพื้นที่เก็บข้อมูลทำงานตามที่ต้องการ
  7. หากต้องการหยุดเข้าร่วมช่วงทดลองใช้จากต้นทาง ให้นําโทเค็นที่เพิ่มไว้ในขั้นตอนที่ 3 ออก
  8. ส่งความคิดเห็นหรือแจ้งปัญหาที่คุณพบเกี่ยวกับที่เก็บ GitHub ของ Storage Access API ที่ไม่ใช่คุกกี้

การสาธิต: การใช้ Storage Access API เพื่อเข้าถึงพื้นที่เก็บข้อมูลในเครื่องที่ไม่ได้แบ่งพาร์ติชัน

การสาธิตต่อไปนี้แสดงวิธีเข้าถึงช่องออกอากาศที่ไม่ได้แบ่งพาร์ติชันจาก iframe ของบุคคลที่สามโดยใช้ Storage Access API

https://saa-beyond-cookies.glitch.me/

เดโมต้องใช้ Chrome 121 ขึ้นไปที่เปิดใช้ Flag test-third-party-cookie-phaseout

แหล่งข้อมูลเพิ่มเติม