การอัปเดต SharedArrayBuffer ใน Android Chrome 88 และ Chrome 92 ในเดสก์ท็อป

Jake Archibald
Eiji Kitamura

เพื่อให้มีเวลามากขึ้นในการผ่อนคลายข้อกําหนดในการเปิดใช้การแยกแหล่งที่มาหลายแหล่งอย่างปลอดภัย

เราขอพูดได้ว่า SharedArrayBuffer เปิดตัวบนเว็บได้ไม่ค่อยราบรื่นนัก แต่ตอนนี้ทุกอย่างเริ่มเข้าที่เข้าทางแล้ว สิ่งที่จำเป็นต้องทราบมีดังนี้

โดยสรุป

  • ขณะนี้ SharedArrayBuffer ใช้งานได้ใน Firefox 79 ขึ้นไป และจะพร้อมใช้งานใน Android Chrome 88 แต่จะใช้ได้กับหน้าที่แยกกันแบบข้ามต้นทางเท่านั้น
  • ปัจจุบัน SharedArrayBuffer พร้อมใช้งานใน Chrome บนเดสก์ท็อป แต่จาก Chrome 92 เป็นต้นไป SharedArrayBuffer จะจำกัดไว้สำหรับหน้าเว็บที่มีการแยกแบบข้ามต้นทางเท่านั้น หากคิดว่าจะทำการเปลี่ยนแปลงนี้ไม่ทัน คุณลงทะเบียนทดลองใช้เวอร์ชันต้นทางเพื่อคงลักษณะการทำงานปัจจุบันไว้ได้จนถึง Chrome 113 เป็นอย่างน้อย
  • หากต้องการเปิดใช้การแยกแหล่งที่มาหลายแหล่งเพื่อใช้งานต่อไป SharedArrayBufferให้ประเมินผลกระทบที่การแยกแหล่งที่มาหลายแหล่งจะมีต่อองค์ประกอบอื่นๆ ของแหล่งที่มาหลายแหล่งในเว็บไซต์ เช่น ตําแหน่งโฆษณา ตรวจสอบว่าทรัพยากรของบุคคลที่สามใช้ SharedArrayBuffer หรือไม่เพื่อทำความเข้าใจผลกระทบและคำแนะนำ

ภาพรวมการแยกแบบข้ามต้นทาง

คุณทําให้หน้าแยกกันแบบข้ามต้นทางได้โดยแสดงหน้าเว็บที่มีส่วนหัวต่อไปนี้

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

เมื่อดำเนินการเสร็จแล้ว หน้าเว็บจะโหลดเนื้อหาข้ามโดเมนไม่ได้ เว้นแต่ว่าแหล่งข้อมูลจะอนุญาตอย่างชัดแจ้งผ่านส่วนหัว Cross-Origin-Resource-Policy หรือส่วนหัว CORS (Access-Control-Allow-* และอื่นๆ)

นอกจากนี้ยังมี Reporting API เพื่อให้คุณรวบรวมข้อมูลเกี่ยวกับคำขอที่ดำเนินการไม่สำเร็จเนื่องจาก Cross-Origin-Embedder-Policy และ Cross-Origin-Opener-Policy

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

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

เรามาถึงจุดนี้ได้ยังไง

SharedArrayBuffer เปิดตัวใน Chrome 60 (เดือนกรกฎาคม 2017 สำหรับผู้ที่คิดถึงเวลาเป็นวันที่แทนเวอร์ชัน Chrome) และทุกอย่างก็ยอดเยี่ยม เป็นเวลา 6 เดือน

ในเดือนมกราคม 2018 มีการเปิดเผยช่องโหว่ใน CPU ยอดนิยมบางรุ่น ดูรายละเอียดทั้งหมดได้ในประกาศ แต่โดยพื้นฐานแล้วหมายความว่าโค้ดสามารถใช้ตัวจับเวลาความละเอียดสูงเพื่ออ่านหน่วยความจำที่ไม่ควรมีสิทธิ์เข้าถึง

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

ในการลดปัญหานี้ เราจึงลดความละเอียดของตัวจับเวลาความละเอียดสูง เช่น performance.now() อย่างไรก็ตาม คุณสามารถสร้างตัวจับเวลาความละเอียดสูงได้โดยใช้ SharedArrayBuffer โดยแก้ไขหน่วยความจำในลูปแบบแน่นหนาในเวิร์กเกอร์ และอ่านกลับในอีกเธรดหนึ่ง เราไม่สามารถลดปัญหานี้ได้อย่างมีประสิทธิภาพโดยไม่ส่งผลกระทบอย่างมากต่อโค้ดที่มีเจตนาดี เราจึงปิดใช้ SharedArrayBuffer ทั้งหมด

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

<iframe src="https://your-bank.example/balance.json"></iframe>
<script src="https://your-bank.example/balance.json"></script>
<link rel="stylesheet" href="https://your-bank.example/balance.json" />
<img src="https://your-bank.example/balance.json" />
<video src="https://your-bank.example/balance.json"></video>
<!-- …and more… -->

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

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

เมื่อใช้มาตรการบรรเทาเหล่านี้แล้ว เราจึงนำ SharedArrayBuffer กลับมาใช้ใน Chrome 68 (กรกฎาคม 2018) อีกครั้ง แต่จะใช้ได้เฉพาะบนเดสก์ท็อปเท่านั้น ข้อกำหนดเพิ่มเติมของกระบวนการทำให้เราดำเนินการในลักษณะเดียวกันบนอุปกรณ์เคลื่อนที่ไม่ได้ นอกจากนี้ เรายังพบว่าโซลูชันของ Chrome ยังไม่สมบูรณ์ เนื่องจากเราบล็อกเฉพาะรูปแบบข้อมูลที่ "ไม่ถูกต้อง" เท่านั้น แต่เป็นไปได้ (แม้ว่าจะไม่ค่อยเกิดขึ้น) ที่ CSS/JS/รูปภาพที่ถูกต้องใน URL ที่คาดเดาได้อาจมีข้อมูลส่วนตัว

ผู้เชี่ยวชาญด้านมาตรฐานเว็บได้ร่วมกันหาวิธีแก้ปัญหาที่ครอบคลุมมากขึ้นสำหรับเบราว์เซอร์ต่างๆ ทางออกคือให้หน้าเว็บมีวิธีระบุว่า "ฉันขอยกเลิกสิทธิ์ในการนําเนื้อหาจากแหล่งที่มาอื่นๆ มาใช้ในกระบวนการนี้โดยไม่ได้รับการเลือกใช้จากแหล่งที่มาดังกล่าว" การประกาศนี้ทำได้ผ่านส่วนหัว COOP และ COEP ที่แสดงพร้อมกับหน้าเว็บ เบราว์เซอร์จะบังคับใช้ข้อกำหนดดังกล่าว และในทางกลับกัน หน้าเว็บก็จะได้รับสิทธิ์เข้าถึง SharedArrayBuffer และ API อื่นๆ ที่มีอำนาจในลักษณะเดียวกัน ต้นทางอื่นๆ จะเลือกใช้การฝังเนื้อหาผ่าน Cross-Origin-Resource-Policy หรือ CORS ได้

Firefox เป็นรายแรกที่เปิดตัว SharedArrayBuffer ที่มีข้อจำกัดนี้ในรุ่น 79 (กรกฎาคม 2020)

จากนั้นในเดือนมกราคม 2021 เราเขียนบทความนี้ขึ้นมา และคุณก็อ่านบทความนี้ สวัสดี

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

การเลื่อนการเปลี่ยนแปลง Chrome บนเดสก์ท็อป

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

  1. ขอโทเค็นสำหรับต้นทาง
  2. เพิ่มโทเค็นลงในหน้าเว็บ ซึ่งทำได้ 2 วิธีดังนี้
    • เพิ่มแท็ก origin-trial <meta> ลงในส่วนหัวของแต่ละหน้า ตัวอย่างเช่น
      <meta http-equiv="origin-trial" content="TOKEN_GOES_HERE">
    • หากกำหนดค่าเซิร์ฟเวอร์ได้ คุณยังเพิ่มโทเค็นได้โดยใช้ส่วนหัว HTTP Origin-Trial ส่วนหัวการตอบกลับที่ได้ควรมีลักษณะดังนี้
      Origin-Trial: TOKEN_GOES_HERE

อ่านเพิ่มเติม

รูปภาพแบนเนอร์โดย Daniel Gregoire ใน Unsplash