Chrome ได้แบ่งพาร์ติชัน API พื้นที่เก็บข้อมูลและการสื่อสารส่วนใหญ่ในบริบทของบุคคลที่สามเพื่อป้องกันการติดตามข้ามเว็บไซต์ของช่องทางข้างเคียงบางประเภท
สถานะการติดตั้งใช้งาน
เราได้เปิดใช้ฟีเจอร์นี้สำหรับผู้ใช้ทุกคนใน Chrome 115 ขึ้นไปแล้ว เราเปิดรับความคิดเห็นเพิ่มเติมเกี่ยวกับข้อเสนอการแบ่งพาร์ติชันพื้นที่เก็บข้อมูล
การแบ่งพาร์ติชันพื้นที่เก็บข้อมูลคืออะไร
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 ไม่ได้อีกต่อไป แต่ข้อมูลจะพร้อมใช้งานสําหรับบริบทที่มีต้นทางเดียวกันและเว็บไซต์ระดับบนสุดเดียวกันเท่านั้น
ก่อน
หลัง
การแบ่งพาร์ติชันพื้นที่เก็บข้อมูลใน iframe ที่ลิงก์กัน
เมื่อ iframe มี iframe อยู่ด้วย ทุกอย่างจะเริ่มซับซ้อนขึ้น โดยเฉพาะอย่างยิ่งเมื่อต้นทางเดียวกันอยู่ในตำแหน่งต่างๆ มากกว่า 1 แห่งในเชน
เช่น A1 มี iframe สําหรับ B ซึ่งมี iframe สําหรับ A2 และทั้ง A1 และ A2 อยู่ในเว็บไซต์เดียวกัน หากเราพิจารณาเฉพาะบริบทระดับบนสุดและระดับปัจจุบันเมื่อแบ่งพาร์ติชัน ระบบอาจถือว่า iframe A2 เป็นบุคคลที่หนึ่งเนื่องจากอยู่ในเว็บไซต์เดียวกับระดับบนสุด (A1) แม้ว่าจะมี iframe ของบุคคลที่สาม (B) แทรกอยู่ก็ตาม ซึ่งอาจทำให้ A2 มีความเสี่ยงด้านความปลอดภัย เช่น การคลิกจากระยะไกล หาก A2 มีสิทธิ์เข้าถึงพื้นที่เก็บข้อมูลที่ไม่ได้แบ่งพาร์ติชันไว้โดยค่าเริ่มต้น
เพื่อแก้ไขปัญหานี้ Chrome จึงเพิ่ม"บิตบรรพบุรุษ" เพิ่มเติมเป็นส่วนหนึ่งของคีย์พาร์ติชันพื้นที่เก็บข้อมูล ซึ่งจะตั้งค่าหากเอกสารระหว่างบริบทปัจจุบันกับบริบทระดับบนสุดอยู่ในเว็บไซต์อื่นกับบริบทปัจจุบัน ในกรณีนี้ เว็บไซต์ B เป็นแบบข้ามเว็บไซต์ ระบบจะตั้งค่าบิตสําหรับ A2 และจัดสรรพื้นที่เก็บข้อมูลของ A2 แยกจาก A1
เมื่อไม่มีบริบทข้ามเว็บไซต์ในเชน ระบบจะไม่แบ่งพาร์ติชันพื้นที่เก็บข้อมูล ตัวอย่างเช่น เว็บไซต์ A1 ที่มี iframe สําหรับ A2 ซึ่งมี iframe สําหรับ A3 จะไม่ได้รับการแบ่งพาร์ติชันสําหรับ 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
- BLOB เป็นออบเจ็กต์ที่มีข้อมูลดิบที่จะประมวลผล และสามารถสร้าง URL ของ BLOB เพื่อเข้าถึงทรัพยากรได้ ระบบจะไม่แบ่งพาร์ติชันที่เก็บ URL ของ BLOB หากต้องการรองรับกรณีการใช้งานสำหรับการไปยังบริบทระดับบนสุดไปยัง URL ของ BLOB ใดๆ (การสนทนา) ระบบอาจแบ่งพาร์ติชันที่เก็บ URL ของ BLOB ตามคลัสเตอร์ของตัวแทนแทนเว็บไซต์ระดับบนสุด ฟีเจอร์นี้ยังไม่พร้อมให้ทดสอบ และกลไกการแบ่งพาร์ติชันอาจเปลี่ยนแปลงในอนาคต
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 API ยังเปลี่ยนแปลงเวลาของคําขอไปยังส่วนต่างๆ ของเว็บไซต์ได้ ซึ่งอาจทําให้ข้อมูลรั่วไหลข้ามเว็บไซต์ เช่น การดักจับประวัติการเข้าชม
ดังนั้น Service Worker ที่ลงทะเบียนจากบริบทของบุคคลที่สามจึงมีการแบ่งพาร์ติชัน
Extension API
ส่วนขยายคือโปรแกรมที่ช่วยให้ผู้ใช้ปรับแต่งประสบการณ์การท่องเว็บได้
หน้าส่วนขยาย (หน้าที่มีรูปแบบ chrome-extension://) สามารถฝังในเว็บไซต์ต่างๆ บนเว็บได้ และในกรณีเหล่านี้ หน้าส่วนขยายจะยังคงเข้าถึงพาร์ติชันระดับบนสุดได้
หน้าเว็บเหล่านี้ยังฝังเว็บไซต์อื่นๆ ได้ด้วย ซึ่งในกรณีนี้ เว็บไซต์เหล่านั้นจะมีสิทธิ์เข้าถึงพาร์ติชันระดับบนสุด ตราบใดที่ส่วนขยายมีสิทธิ์โฮสต์สำหรับเว็บไซต์นั้น
ดูข้อมูลเพิ่มเติมได้ที่เอกสารส่วนขยาย
สาธิต: การทดสอบการแบ่งพาร์ติชันพื้นที่เก็บข้อมูล
เว็บไซต์สาธิต: https://storage-partitioning-demo-site-a.glitch.me/
เดโมนี้ใช้เว็บไซต์ 2 แห่ง ได้แก่ เว็บไซต์ ก. และเว็บไซต์ ข.
- เมื่อคุณเข้าชมเว็บไซต์ ก ในบริบทระดับบนสุด ระบบจะตั้งค่าข้อมูลโดยใช้วิธีการจัดเก็บข้อมูลต่างๆ
- เว็บไซต์ ข ฝังหน้าเว็บจากเว็บไซต์ ก และการฝังดังกล่าวพยายามอ่านตัวเลือกพื้นที่เก็บข้อมูลที่ตั้งไว้ก่อนหน้านี้
- เมื่อฝังเว็บไซต์ ก. ในเว็บไซต์ ข. เว็บไซต์ ก. จะไม่มีสิทธิ์เข้าถึงข้อมูลดังกล่าวเมื่อมีการแบ่งพื้นที่เก็บข้อมูล และทำให้อ่านไม่สำเร็จ
- การสาธิตใช้การอ่านที่สำเร็จหรือไม่สำเร็จแต่ละรายการเพื่อแสดงว่ามีการแบ่งพาร์ติชันข้อมูลหรือไม่
ขณะนี้คุณสามารถปิดการแบ่งพาร์ติชันพื้นที่เก็บข้อมูลใน Chrome โดยใช้--disable-features=ThirdPartyStoragePartitioning สวิตช์บรรทัดคำสั่ง
นอกจากนี้ คุณยังทดสอบเบราว์เซอร์อื่นๆ ในลักษณะเดียวกันเพื่อดูสถานะการแบ่งพาร์ติชันได้ด้วย
มีส่วนร่วมและแชร์ความคิดเห็น
- GitHub: อ่านข้อเสนอฉบับแรก ตั้งคำถามและเข้าร่วมการสนทนา
- การสนับสนุนนักพัฒนาแอป: ถามคําถามและเข้าร่วมการสนทนาในที่เก็บข้อมูลการสนับสนุนนักพัฒนาแอป Privacy Sandbox
- รายงานข้อบกพร่อง: รายงานข้อบกพร่องในเครื่องมือติดตาม Chromium หากเชื่อว่ามีบางอย่างไม่ทำงานตามที่คาดไว้