การแบ่งพาร์ติชันพื้นที่เก็บข้อมูล

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

สถานะการติดตั้งใช้งาน

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

การแบ่งพาร์ติชันพื้นที่เก็บข้อมูลคืออะไร

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

หากไม่มีการแบ่งพาร์ติชันพื้นที่เก็บข้อมูล เว็บไซต์จะรวมข้อมูลจากเว็บไซต์ต่างๆ เพื่อติดตามผู้ใช้ในเว็บได้ นอกจากนี้ ยังช่วยให้เว็บไซต์ที่ฝังสามารถอนุมานสถานะบางอย่างเกี่ยวกับผู้ใช้ในเว็บไซต์ระดับบนสุดได้โดยใช้เทคนิคช่องทางด้านข้าง เช่น การโจมตีตามเวลา, XS-Leaks และ COSI

ที่ผ่านมา พื้นที่เก็บข้อมูลจะคีย์ตามต้นทางเท่านั้น ซึ่งหมายความว่าหากฝัง iframe จาก example.com ใน a.com และ b.com เว็บไซต์ดังกล่าวจะเรียนรู้เกี่ยวกับพฤติกรรมการท่องเว็บของคุณใน 2 เว็บไซต์ดังกล่าวได้โดยการจัดเก็บและดึงรหัสออกจากพื้นที่เก็บข้อมูลได้สําเร็จ เมื่อเปิดใช้การแบ่งพาร์ติชันพื้นที่เก็บข้อมูลของบุคคลที่สาม พื้นที่เก็บข้อมูลของ example.com จะอยู่ใน 2 พาร์ติชันที่แตกต่างกัน โดย 1 พาร์ติชันสำหรับ a.com และอีก 1 พาร์ติชันสำหรับ b.com

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

ก่อน

Storage API ที่ไม่มีการจัดสรรพื้นที่เก็บข้อมูล
ก่อนการแบ่งพาร์ติชันพื้นที่เก็บข้อมูล example.com สามารถเขียนข้อมูลเมื่อฝังใน a.com และอ่านข้อมูลเมื่อฝังใน b.com

หลัง

Storage API ที่มีการจัดแบ่งพาร์ติชัน
หลังจากแบ่งพาร์ติชันพื้นที่เก็บข้อมูลแล้ว เมื่อฝังใน b.com ระบบจะไม่อนุญาตให้ example.com เข้าถึงพื้นที่เก็บข้อมูลของ example.com เมื่อฝังใน a.com

การแบ่งพาร์ติชันพื้นที่เก็บข้อมูลใน iframe ที่ลิงก์กัน

ความซับซ้อนของการแบ่งพาร์ติชันพื้นที่เก็บข้อมูลจะเพิ่มขึ้นอย่างมากเมื่อมีการวางซ้อน iframe โดยเฉพาะเมื่อต้นทางเดียวกันปรากฏหลายครั้งในเชน

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

เพื่อแก้ไขปัญหานี้ Chrome จึงเพิ่ม "บิตบรรพบุรุษ" ลงในคีย์พาร์ติชันพื้นที่เก็บข้อมูล ระบบจะตั้งค่าบิตนี้หากเอกสารระหว่าง iframe ปัจจุบันกับเว็บไซต์ระดับบนสุดมาจากต้นทางอื่น (ข้ามเว็บไซต์) ในกรณีนี้ เว็บไซต์ ข. เป็นแบบข้ามเว็บไซต์ ระบบจะตั้งค่าบิตสําหรับ A2 และแบ่งพื้นที่เก็บข้อมูลออกจาก A1

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

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

การเปลี่ยนแปลง API เนื่องจากการแบ่งพาร์ติชัน

API ที่ได้รับผลกระทบจากการแบ่งพาร์ติชันสามารถแบ่งออกเป็นกลุ่มต่อไปนี้

Storage API

  • ระบบโควต้า
    ระบบโควต้าใช้เพื่อกำหนดปริมาณพื้นที่ในดิสก์ที่จัดสรรสำหรับพื้นที่เก็บข้อมูล ระบบโควต้าจะจัดการแต่ละพาร์ติชันเป็นที่เก็บข้อมูลแยกต่างหากเพื่อกำหนดปริมาณพื้นที่เก็บข้อมูลที่อนุญาตและเวลาที่ระบบจะล้างพื้นที่เก็บข้อมูล
    ตอนนี้เมธอด navigator.storage.estimate() จะแสดงเฉพาะข้อมูลของพาร์ติชันพื้นที่เก็บข้อมูล API สำหรับ Chrome เท่านั้น เช่น window.webkitStorageInfo และ navigator.webkitTemporaryStorage เลิกใช้งานแล้ว
    IndexedDB และพื้นที่เก็บข้อมูลแคชใช้ระบบโควตาที่มีการแบ่งพาร์ติชัน
  • Web Storage API
    Web Storage API มีกลไกที่เบราว์เซอร์ใช้จัดเก็บคู่คีย์-ค่าได้ โดยกลไกมี 2 อย่าง ได้แก่ พื้นที่เก็บข้อมูลในเครื่อง และ พื้นที่เก็บข้อมูลเซสชัน บัญชีเหล่านี้ไม่ได้จัดการตามโควต้า แต่ยังคงมีการแบ่งพาร์ติชัน
  • ระบบไฟล์ส่วนตัวของ Origin
    File System Access API ช่วยเว็บไซต์ในการอ่านหรือบันทึกการเปลี่ยนแปลงลงในไฟล์และโฟลเดอร์ในอุปกรณ์โดยตรงหลังจากที่ผู้ใช้ให้สิทธิ์เข้าถึง ระบบไฟล์ส่วนตัวของต้นทางช่วยให้ต้นทางจัดเก็บเนื้อหาส่วนตัวลงในดิสก์ได้โดยตรง ผู้ใช้จะยังคงเข้าถึงเนื้อหานี้ได้ แต่ตอนนี้เนื้อหาดังกล่าวได้รับการแบ่งพาร์ติชันแล้ว
  • Storage Bucket API
    เรากําลังพัฒนา Storage Bucket API สําหรับ Storage Standard ซึ่งจะรวม API พื้นที่เก็บข้อมูลต่างๆ เช่น IndexedDB และ localStorage โดยใช้แนวคิดใหม่ที่เรียกว่าที่เก็บข้อมูล ข้อมูลที่จัดเก็บในที่เก็บข้อมูลและข้อมูลเมตาที่เชื่อมโยงกับที่เก็บข้อมูลจะได้รับการแบ่งพาร์ติชัน
  • ส่วนหัว Clear-Site-Data
    การใส่ส่วนหัว Clear-Site-Data ในการตอบกลับจะช่วยให้เซิร์ฟเวอร์ส่งคำขอล้างข้อมูลที่จัดเก็บไว้ในเบราว์เซอร์ของผู้ใช้ได้ คุณสามารถล้างแคช คุกกี้ และพื้นที่เก็บข้อมูล DOM ได้ การใช้ส่วนหัวจะล้างพื้นที่เก็บข้อมูลภายในพาร์ติชันเดียวเท่านั้น
  • ร้านค้า URL ของ BLOB
    URL ของ Blob ให้สิทธิ์เข้าถึง Blob ซึ่งเป็นออบเจ็กต์ที่เก็บข้อมูลดิบ หากไม่มีการแบ่งพาร์ติชันพื้นที่เก็บข้อมูล คุณจะใช้ URL ของ Blob ที่สร้างขึ้นใน iframe ของบุคคลที่สามในเว็บไซต์หนึ่งได้ใน iframe ต้นทางเดียวกันที่ฝังอยู่ในเว็บไซต์อื่น ตัวอย่างเช่น หากฝัง iframe example.com ทั้งใน a.com และ b.com ระบบจะส่ง Blob URL ที่สร้างขึ้นจาก iframe ที่ฝังใน a.com ไปยัง iframe ที่ฝังใน b.com แล้ว iframe ดังกล่าวจะใช้ URL ดังกล่าวได้โดยไม่มีข้อจํากัด ตั้งแต่ Chrome 137 (เผยแพร่เมื่อวันที่ 27 พฤษภาคม 2025) ระบบจะแบ่งพาร์ติชัน URL ของ Blob สำหรับการนำไปใช้งานทั้งหมดยกเว้นการไปยังส่วนต่างๆ ในระดับบนสุด กรณีที่ระบบจะบล็อกในตอนนี้รวมถึงกรณีที่ใช้ URL ของ BLOB ข้ามพาร์ติชันกับ fetch() หรือใช้เป็นค่าแอตทริบิวต์ src สำหรับองค์ประกอบ HTML ต่างๆ ระบบจะไม่บล็อกการนำทางระดับบนสุด เช่น การเรียกใช้ window.open() หรือการคลิกลิงก์ที่มี target='_blank' ไปยัง URL ของ BLOB หากเป็นพาร์ติชันข้าม แต่จะใช้ noopener หากเว็บไซต์ URL ของ BLOB ข้ามเว็บไซต์จากเว็บไซต์ระดับบนสุดของหน้าที่เริ่มการนำทาง การบังคับใช้ noopener หมายความว่าเอกสารที่เริ่มการนําทางจะไม่ได้รับแฮนเดิลหน้าต่างสําหรับเอกสาร URL ของ Blob ที่เปิดอยู่ ในตัวอย่างก่อนหน้านี้ การแบ่งพาร์ติชันจะป้องกันไม่ให้ iframe ใน b.com ดึงข้อมูลเนื้อหาของ URL ของ BLOB แต่ยังคงwindow.open()เนื้อหานั้นได้

Communication APIs

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

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

  • ช่องออกอากาศ
    Broadcast Channel API ช่วยให้การสื่อสารระหว่างบริบทการท่องเว็บ (หน้าต่าง แท็บ หรือ iframe) กับผู้ปฏิบัติงานในต้นทางเดียวกันเป็นไปได้
    เราไม่แนะนําให้เปลี่ยนแปลงลักษณะการทํางานของ iframe ข้ามเว็บไซต์ postMessage() เนื่องจากความสัมพันธ์ระหว่างบริบทเหล่านั้นได้รับการกําหนดไว้อย่างชัดเจนแล้ว
  • SharedWorker
    SharedWorker API ให้บริการผู้ปฏิบัติงานที่เข้าถึงได้ผ่านบริบทการท่องเว็บของต้นทางเดียวกัน
  • Web Locks
    Web Locks API อนุญาตให้โค้ดที่ทำงานในแท็บหรือผู้ปฏิบัติงาน 1 รายการของต้นทางเดียวกันรับการล็อกสำหรับทรัพยากรที่แชร์ขณะที่ดำเนินการบางอย่าง

Service Worker API

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

ด้วยเหตุนี้ Service Worker ที่ลงทะเบียนจากบริบทของบุคคลที่สามจึงมีการแบ่งพาร์ติชัน

Extension API

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

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

ดูข้อมูลเพิ่มเติมได้ที่เอกสารส่วนขยาย

การสาธิต: การทดสอบการแบ่งพาร์ติชันพื้นที่เก็บข้อมูล

เว็บไซต์สาธิต: https://storage-partitioning-demo-site-a.glitch.me/

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

เดโมนี้ใช้เว็บไซต์ 2 แห่ง ได้แก่ เว็บไซต์ ก. และเว็บไซต์ ข.

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

ขณะนี้คุณสามารถปิดการแบ่งพาร์ติชันพื้นที่เก็บข้อมูลใน Chrome โดยใช้--disable-features=ThirdPartyStoragePartitioning สวิตช์บรรทัดคำสั่ง หมายเหตุ: สวิตช์บรรทัดคำสั่งนี้มีไว้เพื่อการพัฒนาและการทดสอบ และอาจถูกนำออกหรือเปลี่ยนแปลงใน Chrome เวอร์ชันในอนาคต

นอกจากนี้ คุณยังทดสอบเบราว์เซอร์อื่นๆ ในลักษณะเดียวกันเพื่อดูสถานะการแบ่งพาร์ติชันได้ด้วย

มีส่วนร่วมและแชร์ความคิดเห็น