เราสามารถพูดได้ว่า SharedArrayBuffer ค่อนข้างมีความคืบหน้าในเว็บอยู่บ้าง แต่สถานการณ์เริ่มผ่อนปรนลง สิ่งที่จำเป็นต้องทราบมีดังนี้
สรุปสั้นๆ
- ปัจจุบัน Firefox 79 ขึ้นไปรองรับ
SharedArrayBufferและจะมีให้บริการใน Android Chrome 88 แต่จะใช้ได้กับหน้าเว็บที่แยกต่างหากแบบข้ามต้นทางเท่านั้น - ขณะนี้
SharedArrayBufferพร้อมใช้งานใน Chrome บนเดสก์ท็อป แต่ใน Chrome 92 จะจำกัดให้ใช้เฉพาะหน้าที่แยกแบบข้ามต้นทาง หากคิดว่าไม่สามารถทำการเปลี่ยนแปลงนี้ได้ทันเวลา คุณสามารถลงทะเบียนทดลองใช้จากต้นทางเพื่อรักษาลักษณะการทำงานในปัจจุบันไว้จนถึง Chrome 113 เป็นอย่างน้อย - หากคุณต้องการเปิดใช้การแยกแบบข้ามต้นทางเพื่อใช้
SharedArrayBufferต่อไป ให้ประเมินผลกระทบที่จะเกิดขึ้นกับองค์ประกอบข้ามต้นทางอื่นๆ ในเว็บไซต์ เช่น ตําแหน่งโฆษณา ตรวจสอบว่าทรัพยากรของบุคคลที่สามใช้SharedArrayBufferหรือไม่ เพื่อทำความเข้าใจผลกระทบและคำแนะนำ
ภาพรวมการแยกแบบข้ามต้นทาง
คุณทำให้หน้าเว็บแยกแบบข้ามต้นทางได้โดยแสดงหน้าเว็บที่มีส่วนหัวต่อไปนี้
Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin
หลังจากดำเนินการแล้ว หน้าเว็บจะโหลดเนื้อหาแบบข้ามต้นทางไม่ได้ เว้นแต่ทรัพยากรจะอนุญาตอย่างชัดแจ้งผ่านส่วนหัว Cross-Origin-Resource-Policy หรือส่วนหัว CORS (Access-Control-Allow-* ฯลฯ)
นอกจากนี้ยังมี 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 เดสก์ท็อปเท่านั้น
- ขอโทเค็นสำหรับต้นทาง
- เพิ่มโทเค็นลงในหน้าเว็บ ซึ่งทำได้ 2 วิธีดังนี้
- เพิ่มแท็ก
origin-trial<meta>ในส่วนหัวของแต่ละหน้า อาจมีลักษณะดังนี้
<meta http-equiv="origin-trial" content="TOKEN_GOES_HERE"> - หากกำหนดค่าเซิร์ฟเวอร์ได้ คุณจะเพิ่มโทเค็นโดยใช้ส่วนหัว HTTP
Origin-Trialได้ด้วย ส่วนหัวการตอบกลับที่ได้ควร มีลักษณะเช่นนี้
Origin-Trial: TOKEN_GOES_HERE
- เพิ่มแท็ก
อ่านเพิ่มเติม
- คำแนะนำในการเปิดใช้การแยกแบบข้ามต้นทาง
- วิธีแยกหน้าเว็บแบบข้ามต้นทาง
- เหตุใดจึงต้องมีการแยกแบบข้ามต้นทาง
รูปแบนเนอร์โดย Daniel Gregoire ใน Unsplash