ใน Chrome เกือบทุกเวอร์ชัน เราเห็นการอัปเดตและการปรับปรุงผลิตภัณฑ์ ประสิทธิภาพ และความสามารถของแพลตฟอร์มเว็บเป็นจำนวนมาก บทความนี้จะอธิบายการเลิกใช้งานและการนำออกใน Chrome 60 ซึ่งอยู่ในรุ่นเบต้าตั้งแต่วันที่ 8 มิถุนายน รายการนี้อาจมีการเปลี่ยนแปลงได้ทุกเมื่อ
ความปลอดภัย
ตอนนี้ crypto.subtle ต้องใช้ต้นทางที่ปลอดภัย
Web Crypto API ซึ่งรองรับตั้งแต่ Chrome 37 ทำงานบนต้นทางที่ไม่ปลอดภัยได้เสมอ crypto.subtle จะปรากฏในต้นทางที่ปลอดภัยเท่านั้นเนื่องจากนโยบายให้ความสำคัญกับต้นทางที่ปลอดภัยสำหรับฟีเจอร์ที่มีประสิทธิภาพซึ่งเป็นนโยบายที่ Chrome ยึดถือมาอย่างยาวนาน
Intent to Remove | ข้อบกพร่องของ Chromium
นำการนำทางเฟรมด้านบนที่เนื้อหาเริ่มต้นไปยัง URL ของข้อมูลออก
เราพบว่ามีการใช้รูปแบบ data: ในการโจมตีแบบสแปมฟิชชิงและฟิชชิงมากขึ้น เนื่องจากผู้ใช้เบราว์เซอร์ที่ไม่ใช่ผู้เชี่ยวชาญทางเทคนิคไม่คุ้นเคยกับรูปแบบนี้ เพื่อป้องกันปัญหานี้ เราจึงบล็อกไม่ให้หน้าเว็บโหลด URL data: ในเฟรมด้านบน ซึ่งมีผลกับแท็ก <a>, window.open,
window.location และกลไกที่คล้ายกัน รูปแบบ data: จะยังคงใช้งานได้กับทรัพยากรที่หน้าเว็บโหลด
ฟีเจอร์นี้เลิกใช้งานแล้วใน Chrome 58 และตอนนี้ก็ถูกนำออกไปแล้ว
Intent to Remove | Chromestatus Tracker | ข้อบกพร่องของ Chromium
ปิดใช้ navigator.sendBeacon() ชั่วคราวสําหรับ Blob บางรายการ
ฟังก์ชัน navigator.sendBeacon() พร้อมใช้งานตั้งแต่ Chrome 39
ตามที่ติดตั้งใช้งานในตอนแรก อาร์กิวเมนต์ data ของฟังก์ชันอาจมี Blob ที่ไม่เจาะจงประเภทใดก็ได้ซึ่งไม่ได้อยู่ในรายการที่ปลอดภัยของ CORS เราเชื่อว่านี่เป็นภัยคุกคามด้านความปลอดภัยที่อาจเกิดขึ้น แม้ว่าจะยังไม่มีผู้พยายามใช้ประโยชน์จากช่องโหว่นี้ก็ตาม เนื่องจากเราไม่มีวิธีแก้ไขที่เหมาะสมในทันที sendBeacon() จึงเรียกใช้กับ Blob ประเภทที่ไม่ใช่รายการที่ปลอดภัยของ CORS ไม่ได้อีกต่อไปชั่วคราว
แม้ว่าการเปลี่ยนแปลงนี้จะมีผลกับ Chrome 60 แต่ก็ได้ผสานรวมกลับไปยัง Chrome 59 แล้ว
CSS
ทําให้คอมบิเนเตอร์ที่เจาะเงาของรายการที่สืบทอดมีลักษณะการทํางานเหมือนคอมบิเนเตอร์ของรายการที่สืบทอด
ตัวรวมองค์ประกอบที่เจาะเงา (>>>) ซึ่งเป็นส่วนหนึ่งของโมดูลการกําหนดขอบเขต CSS ระดับ 1 มีไว้เพื่อจับคู่กับองค์ประกอบย่อยของออบเจ็กต์บรรพบุรุษที่เฉพาะเจาะจง แม้ว่าจะปรากฏภายในต้นไม้เงาก็ตาม ซึ่งมีข้อจํากัดบางอย่าง
ประการแรก ตามข้อกำหนด จะใช้ได้เฉพาะในการเรียกใช้ JavaScript เช่น querySelector() และไม่ทำงานในสไตลชีต และที่สำคัญกว่านั้นคือ ผู้ให้บริการเบราว์เซอร์ไม่สามารถทําให้ Shadow DOM ทํางานได้มากกว่า 1 ระดับ
ด้วยเหตุนี้ เราจึงนําตัวรวมรายการที่สืบทอดมาจากข้อกําหนดที่เกี่ยวข้องออก ซึ่งรวมถึง Shadow DOM v1 แทนที่จะทำให้หน้าเว็บใช้งานไม่ได้ด้วยการนําตัวเลือกนี้ออกจาก Chromium เราเลือกที่จะเปลี่ยนชื่อตัวรวมโค้ดที่เจาะเงาเป็น "ตัวรวมโค้ดที่เจาะเงา" แทน ลักษณะการทำงานเดิมเลิกใช้งานใน Chrome 45 แล้ว วิธีการทํางานแบบใหม่นี้ใช้งานได้ใน Chrome 61
Intent to Remove | Chromestatus Tracker | ข้อบกพร่องของ Chromium
JavaScript
เลิกใช้งานและนํา RTCPeerConnection.getStreamById() ออก
เมื่อเกือบ 2 ปีก่อน getStreamById() ได้ถูกนำออกจากข้อกำหนดของ WebRTC และเบราว์เซอร์อื่นๆ ส่วนใหญ่ได้นำ getStreamById() นี้ออกจากการใช้งานแล้ว แม้ว่าฟังก์ชันนี้จะไม่ค่อยได้ใช้ แต่ก็มีความเสี่ยงเล็กน้อยที่อาจใช้งานร่วมกันไม่ได้กับเบราว์เซอร์ Edge และเบราว์เซอร์ที่ใช้ WebKit นอกเหนือจาก Safari ที่ยังคงรองรับ getStreamById() นักพัฒนาแอปที่ต้องการการติดตั้งใช้งานระบบอื่นสามารถดูตัวอย่างโค้ดในส่วนความตั้งใจที่จะนำออกด้านล่าง
การนําออกจะมีใน Chrome 62
Intent to Remove | Chromestatus Tracker | ข้อบกพร่องของ Chromium
เลิกใช้งาน SVGPathElement.getPathSegAtLength
กว่า 2 ปีที่แล้ว getPathSegAtLength() ถูกนำออกจากข้อกำหนด SVG เนื่องจากมี Hit เพียงไม่กี่รายการสำหรับเมธอดนี้ใน httparchive เราจึงเลิกใช้งานเมธอดนี้ใน Chrome 60 คาดว่าการนําออกจะเกิดขึ้นใน Chrome 62 ซึ่งจะเปิดตัวในช่วงต้นหรือกลางเดือนตุลาคม
ความตั้งใจที่จะเลิกใช้งาน | เครื่องมือติดตามสถานะ Chrome | ข้อบกพร่องของ Chromium
ย้าย getContextAttributes() ไว้หลัง Flag
ฟังก์ชัน getContextAttributes() ได้รับการสนับสนุนใน CanvasRenderingContext2D มาตั้งแต่ปี 2013 อย่างไรก็ตาม ฟีเจอร์นี้ไม่ได้เป็นส่วนหนึ่งของมาตรฐานใดๆ และไม่ได้เป็นส่วนหนึ่งของมาตรฐานใดๆ นับตั้งแต่นั้นเป็นต้นมา ควรจะติดตั้งไว้หลัง Flag บรรทัดคำสั่ง --enable-experimental-canvas-features แต่กลับไม่ได้ติดตั้ง ใน Chrome 60 เราได้แก้ไขข้อบกพร่องนี้แล้ว เราเชื่อว่าการเปลี่ยนแปลงนี้ปลอดภัย เนื่องจากไม่มีข้อมูลว่ามีคนใช้วิธีการนี้
นํา Headers.prototype.getAll() ออก
ระบบจะนำฟังก์ชัน Headers.prototype.getAll() ออกตามข้อกําหนดการดึงข้อมูลเวอร์ชันล่าสุด
Intent to Remove | Chromestatus Tracker | ข้อบกพร่องของ Chromium
นำ indexedDB.webkitGetDatabaseNames() ออก
เราเพิ่มฟีเจอร์นี้เมื่อ Indexed DB ยังเป็นฟีเจอร์ใหม่ใน Chrome และการใช้คำนำหน้ากำลังได้รับความนิยม API จะแสดงรายการชื่อฐานข้อมูลที่มีอยู่แบบไม่พร้อมกันในต้นทาง ซึ่งดูเหมือนจะสมเหตุสมผลดี
ขออภัย การออกแบบมีข้อบกพร่องตรงที่ผลลัพธ์อาจล้าสมัยทันทีที่แสดงผล จึงใช้ได้กับการบันทึกเท่านั้น ไม่ใช่ตรรกะการทํางานของแอปพลิเคชัน ปัญหา github ติดตาม/ลิงก์ไปยังการสนทนาก่อนหน้าเกี่ยวกับทางเลือก ซึ่งต้องใช้แนวทางอื่น แม้ว่านักพัฒนาซอฟต์แวร์จะสนใจบ้างเป็นครั้งคราว แต่เนื่องจากยังไม่มีความคืบหน้าในการทํางานข้ามเบราว์เซอร์ นักเขียนไลบรารีจึงแก้ปัญหานี้ด้วยวิธีอื่น
นักพัฒนาแอปที่ต้องการฟังก์ชันการทำงานนี้ต้องพัฒนาโซลูชันของตนเอง เช่น ไลบรารีอย่าง Dexie.js ใช้ตารางส่วนกลางซึ่งเป็นฐานข้อมูลอีกประเภทหนึ่งเพื่อติดตามชื่อฐานข้อมูล
ฟีเจอร์นี้เลิกใช้งานแล้วใน Chrome 58 และตอนนี้ก็ถูกนำออกไปแล้ว
Intent to Remove | Chromestatus Tracker | ข้อบกพร่องของ Chromium
นํา WEBKIT_KEYFRAMES_RULE และ WEBKIT_KEYFRAME_RULE ออก
นําค่าคงที่ WEBKIT_KEYFRAMES_RULE และ WEBKIT_KEYFRAME_RULE ที่ไม่เป็นไปตามมาตรฐานออกจากกฎ CSS
นักพัฒนาแอปควรใช้ KEYFRAMES_RULE และ KEYFRAME_RULE แทน
Intent to Remove | Chromestatus Tracker | ข้อบกพร่องของ Chromium
อินเทอร์เฟซผู้ใช้
กำหนดให้ผู้ใช้ใช้ท่าทางสัมผัสสำหรับกล่องโต้ตอบ beforeunload
ตั้งแต่ Chrome 60 เป็นต้นไป กล่องโต้ตอบ beforeunload จะปรากฏขึ้นก็ต่อเมื่อเฟรมที่พยายามแสดงได้รับท่าทางสัมผัสของผู้ใช้หรือการโต้ตอบของผู้ใช้ (หรือหากเฟรมที่ฝังอยู่ได้รับท่าทางสัมผัสดังกล่าว) ขออธิบายให้ชัดเจนว่านี่ไม่ใช่การเปลี่ยนแปลงการส่งเหตุการณ์ beforeunload เป็นเพียงการเปลี่ยนแปลงว่าจะแสดงกล่องโต้ตอบหรือไม่
กล่องโต้ตอบ beforeunload คือกล่องโต้ตอบแบบโมดอลของแอป ด้วยเหตุนี้ เนื้อหาจึงไม่เป็นมิตรต่อผู้ใช้โดยเนื้อแท้ ซึ่งหมายความว่าจะตอบสนองต่อการไปยังส่วนต่างๆ ของผู้ใช้โดยตั้งคำถามเกี่ยวกับการตัดสินใจของผู้ใช้ ฟีเจอร์นี้มีประโยชน์ในเชิงบวก เช่น มักใช้เพื่อเตือนผู้ใช้เมื่อข้อมูลจะสูญหายจากการไปยังส่วนต่างๆ
แม้ว่าเราจะนําความสามารถในการระบุข้อความสําหรับกล่องโต้ตอบ beforeunload ออกจากหน้าเว็บไปเมื่อสักพักแล้ว แต่กล่องโต้ตอบ beforeunload ยังคงเป็นเวกเตอร์การละเมิด โดยเฉพาะอย่างยิ่ง beforeunloadกล่องโต้ตอบเป็นองค์ประกอบของเว็บไซต์กลโกง ซึ่งเสียงที่เล่นอัตโนมัติและข้อความที่ข่มขู่จะสร้างบริบทที่ทำให้ข้อความ "คุณแน่ใจไหมว่าต้องการออกจากหน้านี้" ที่ Chromium มีให้น่ากังวล
เราต้องการหาทางออกที่ดีที่สุดและอนุญาตให้ใช้ beforeunload
dialog ในทางที่ถูกต้องเท่านั้น การใช้กล่องโต้ตอบที่เหมาะสมคือกรณีที่ผู้ใช้มีสถานะที่อาจสูญหาย หากผู้ใช้ไม่เคยโต้ตอบกับหน้าเว็บ ผู้ใช้ก็ไม่มีสถานะที่อาจสูญหาย ดังนั้นเราจึงไม่เสี่ยงต่อการสูญเสียข้อมูลผู้ใช้ด้วยการระงับกล่องโต้ตอบในกรณีดังกล่าว