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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Storage API
• Communication API
• Service Worker API
• Extension API

Storage API

• ระบบโควต้า

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

  ตอนนี้navigator.storage.estimate()เมธอดจะให้ข้อมูลเฉพาะสำหรับพาร์ติชันพื้นที่เก็บข้อมูล API ที่ใช้ได้เฉพาะใน Chrome เช่น window.webkitStorageInfo และ navigator.webkitTemporaryStorage ถูกเลิกใช้งานแล้ว

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

• Web Storage API

  Web Storage API มีกลไกที่เบราว์เซอร์ใช้ จัดเก็บคู่คีย์-ค่า ซึ่งมี 2 กลไก ได้แก่ พื้นที่เก็บข้อมูลในเครื่อง และ พื้นที่เก็บข้อมูลของเซสชัน โดยจะไม่มีการจัดการโควต้า แต่จะยังคงมีการแบ่งพาร์ติชัน

• ระบบไฟล์ส่วนตัวของต้นทาง

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

• Storage Bucket API

  เรากำลังพัฒนา Storage Bucket API สำหรับ Storage Standard ซึ่งจะรวม API ของพื้นที่เก็บข้อมูลต่างๆ เช่น IndexedDB และ localStorage เข้าด้วยกันโดยใช้แนวคิดใหม่ที่เรียกว่า Bucket ระบบจะแบ่งพาร์ติชันข้อมูลที่จัดเก็บไว้ในที่เก็บข้อมูลและข้อมูลเมตา ที่เชื่อมโยงกับที่เก็บข้อมูล

• ส่วนหัว Clear-Site-Data

  การรวมส่วนหัว Clear-Site-Data ไว้ในการตอบกลับจะช่วยให้เซิร์ฟเวอร์ขอให้ล้างข้อมูลที่จัดเก็บไว้ในเบราว์เซอร์ของผู้ใช้ได้ คุณล้างแคช คุกกี้ และพื้นที่เก็บข้อมูล DOM ได้ การใช้ส่วนหัวจะล้างพื้นที่เก็บข้อมูลภายในพาร์ติชันเดียวเท่านั้น

• ที่เก็บ Blob URL

  URL ของ Blob ให้สิทธิ์เข้าถึง blob ซึ่งเป็นออบเจ็กต์ที่เก็บข้อมูลดิบ หากไม่มีการแบ่งพาร์ติชันพื้นที่เก็บข้อมูล คุณจะใช้ URL ของ Blob ที่สร้างใน iframe ของบุคคลที่สามในเว็บไซต์หนึ่งใน iframe ที่มีต้นทางเดียวกันซึ่งฝังอยู่ในเว็บไซต์อื่นได้ เช่น หากมีการฝัง example.com iframe ทั้งใน a.com และ b.com ระบบจะส่งต่อ URL ของ Blob ที่สร้างใน iframe ที่ฝังใน a.com ไปยัง iframe ที่ฝังใน b.com และใช้ 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) กับ Worker ที่มีต้นทางเดียวกัน

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

• SharedWorker

  SharedWorker API มี Worker ที่เข้าถึงได้ในบริบทการท่องเว็บ ที่มีต้นทางเดียวกัน

• Web Locks

  Web Locks API อนุญาตให้โค้ดที่ทำงานในแท็บหรือ Worker เดียวกันของต้นทางเดียวกันรับล็อกสำหรับทรัพยากรที่แชร์ขณะที่ทำงานบางอย่าง

Service Worker API

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

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

API ของส่วนขยาย

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

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

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

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

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

โดยเดโมนี้ใช้ 2 เว็บไซต์ ได้แก่ เว็บไซต์ A และเว็บไซต์ B

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

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

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

ขอเวลาเพิ่มเติมในการย้ายข้อมูล

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

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

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

• GitHub: อ่านข้อเสนอต้นฉบับ ตั้งคำถามและเข้าร่วมการสนทนา
• รายงานข้อบกพร่อง: รายงานข้อบกพร่องในเครื่องมือติดตาม Chromium หากคุณเชื่อว่ามีบางอย่างทำงานไม่เป็นไปตามที่คาดไว้