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

Helen Cho
Helen Cho
Ari Chivukula
Ari Chivukula
GitHub

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

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

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

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

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

ตั้งแต่ 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 (เซสชันและพื้นที่เก็บข้อมูลในเครื่อง), Indexed DB และ Web Lock เท่านั้นที่พร้อมใช้งานใน Chrome 120

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

เพิ่ม Shared Workers และการควบคุมการรวมคุกกี้ใน Chrome 123

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

เข้าร่วม

  1. ประเมินวิธีใช้คุกกี้และพื้นที่เก็บข้อมูลที่ไม่ใช้คุกกี้ในบริบทของบุคคลที่สาม ตัวอย่าง Use Case อาจช่วยให้คุณเข้าใจว่าข้อเสนอนี้เหมาะกับความต้องการของคุณหรือไม่
  2. เปิด Chrome เวอร์ชัน 120 (หรือใหม่กว่า) และตรวจสอบว่าได้เปิดใช้ Flag test-third-party-cookie-phaseout แล้ว
  3. หากต้องการทดสอบฟีเจอร์นี้ในเครื่องโดยไม่ต้องตั้งค่าโทเค็นทดลองใช้ต้นทางก่อน ให้เปิดใช้ #enable-experimental-web-platform-features ในเบราว์เซอร์
    1. เมื่อทดสอบในเครื่องเสร็จแล้ว คุณสามารถลงทะเบียนเพื่อทดลองใช้รุ่นที่ใช้งานจริงของ 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

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