เราขอพูดได้ว่า 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() อย่างไรก็ตาม คุณสามารถcreateตัวจับเวลาความละเอียดสูงได้โดยใช้ 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