เราสามารถพูดได้ว่า SharedArrayBuffer เริ่มมีปัญหาเล็กน้อยในวันที่
เว็บ แต่สิ่งต่างๆ ยังคงลงตัว สิ่งที่จำเป็นต้องทราบมีดังนี้
สรุป
- ขณะนี้
SharedArrayBufferรองรับใน Firefox 79 ขึ้นไปและจะใช้ได้ใน 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