- การ ยกเลิกการรองรับ XSLT ของ Chrome เป็นมาตรการที่ทำให้เทคโนโลยีแกนหลักของเว็บเปิดอ่อนแอลง โดยแม้จะอ้างเหตุผลด้านความปลอดภัย แต่ก็ ลบความสามารถนี้ออกโดยไม่มีเทคโนโลยีทดแทนให้
- Google เสนอ polyfill ที่อิง JavaScript แทนความสามารถพื้นฐานในเบราว์เซอร์ แต่ไม่ได้ฝังมาในเบราว์เซอร์ และ ผลักภาระการพัฒนาไปให้ผู้พัฒนาแทน
- การตัดสินใจนี้นำไปสู่ การอ่อนแรงของระบบนิเวศเว็บอิสระที่อิง RSS·XML และ Mozilla กับ Apple ก็เคลื่อนไหวไปในทิศทางคล้ายกัน
- บทความวิจารณ์ว่า WHATWG ไม่สามารถทำหน้าที่เป็น ผู้พิทักษ์เว็บเปิดได้อีกต่อไป และกำลังควบคุมมาตรฐานเว็บโดยยึดผลประโยชน์ของบริษัทยักษ์ใหญ่เป็นศูนย์กลาง
- การลดทอนความสามารถในการขยายของเบราว์เซอร์และการทำ DRM ให้เป็นมาตรฐาน กำลังทำให้ โครงสร้างเว็บที่ผู้ใช้มีอำนาจควบคุมน้อยลง ฝังแน่นมากขึ้น และเรียกร้องให้ ใช้และต่อต้านต่อไปด้วยเทคโนโลยีเปิดอย่าง RSS·XSLT·JPEG XL
การยกเลิกการรองรับ XSLT และทิศทางของ Google
- Google ยุติการรองรับ XSLT ใน Chrome โดยอ้างช่องโหว่ด้านความปลอดภัย แต่ ไม่ได้เสนอทั้งไลบรารีทดแทนหรือแนวทางปรับปรุงใด ๆ
- มีการวิจารณ์ว่าใช้ปัญหาความปลอดภัยของไลบรารี FLOSS เดิมมาเป็นข้ออ้าง
- ยังชี้ด้วยว่าแม้แต่โอกาสในการนำ implementation ของ XSLT รุ่นใหม่ที่เขียนด้วยภาษาที่ปลอดภัยกว่ามาใช้ ก็ไม่ได้ถูกหยิบมาใช้ประโยชน์
- JavaScript polyfill ที่ Google เสนอ ถูกให้มาเพียงในรูปแบบการเรียกใช้งานภายนอกโดยไม่ได้ฝังในเบราว์เซอร์ จึงถูกประเมินว่าเป็น ทางแทนที่ที่ไม่เป็นมาตรฐานและไร้ประสิทธิภาพ
- บทความอ้างว่ามาตรการนี้คือ การกระทำโดยตั้งใจเพื่อบั่นทอนฐานของเว็บอิสระที่อิง RSS และ XML
- วิเคราะห์ว่าไม่ว่า polyfill จะไม่เพียงพอ หรือแม้จะเพียงพอแต่ Google ก็ยังไม่ยอมฝังไว้ เหตุผลก็คือ ต้องการยับยั้งการใช้งาน XSLT เอง
“Do. Not. Comply.” — การเรียกร้องให้ต่อต้าน
- ผู้เขียนเน้นว่า อย่ายอมติดตั้ง polyfill หรือแก้ไข XML ตามที่ร้องขอ และควรเรียกร้องให้เบราว์เซอร์คืนการรองรับ XSLT
- มีแผนจะ ใช้งานเทคโนโลยีมาตรฐานต่อไป เช่น XSLT, MathML, SVG, SMIL และคง กล่องคำเตือน (infobox) เพื่อแจ้งผู้ใช้ถึงพฤติกรรมที่ไม่เป็นมาตรฐานของเบราว์เซอร์
- การตัดสินใจของ Google ถูกอธิบายว่าเกิดจาก แรงจูงใจทางการเมืองและการค้า ไม่ใช่เหตุผลทางเทคนิค และเป็นส่วนหนึ่งของความพยายามควบคุมเว็บเปิด
- ยังวิจารณ์ว่า Mozilla และ Apple ก็เคลื่อนไหวไปในทางเดียวกัน โดยออกแบบเบราว์เซอร์ให้เป็น เครื่องมือของทุนนิยมสอดส่อง แทนที่จะเป็น User Agent
WHATWG และความบิดเบี้ยวของมาตรฐานเว็บ
- WHATWG เคยเป็นเวทีหารือเพื่อเว็บเปิดในยุคแรก แต่ปัจจุบันถูกมองว่าเปลี่ยนไปเป็น องค์กรปิดที่มีบริษัทยักษ์ใหญ่เป็นศูนย์กลาง
- กลุ่มนี้กำลังเปลี่ยนเว็บจาก คลังเก็บความรู้ ให้กลายเป็น แพลตฟอร์มแจกจ่ายแอปพลิเคชัน และให้ความสำคัญกับ การเพิ่มรายได้ขององค์กรสูงสุด มากกว่าสิทธิการควบคุมของผู้ใช้
- เบราว์เซอร์จึงไม่ใช่ตัวแทนของผู้ใช้ (User Agent) อีกต่อไป แต่ทำหน้าที่เป็น เครื่องมือควบคุมเพื่อผลประโยชน์ขององค์กร
- บทความชี้ว่าการเปลี่ยนแปลงนี้ ขัดแย้งโดยตรงกับวิสัยทัศน์เว็บเปิดที่ W3C เคยผลักดัน
ความจำเป็นของสงครามเบราว์เซอร์ครั้งใหม่
- ตลาดเบราว์เซอร์ปัจจุบันอยู่ในโครงสร้าง ผูกกับเอนจินของ Google·Apple·Mozilla จนแทบไม่มีทางเลือกอิสระ
- แม้จะกล่าวถึงเบราว์เซอร์ทางเลือกอย่าง Vivaldi, LibreWolf, WaterFox, Pale Moon แต่ส่วนใหญ่ก็ยัง พึ่งพาเอนจิน Blink หรือ Gecko
- Pale Moon ถูกประเมินว่าเป็นหนึ่งในไม่กี่เบราว์เซอร์ที่ยัง คงการรองรับ RSS และ JPEG XL
- บทความจึงเสนอว่าจำเป็นต้องมี สงครามระหว่างผู้ใช้กับองค์กร หรือก็คือ สงครามเบราว์เซอร์ครั้งใหม่เพื่อทวงคืนอำนาจควบคุมเว็บ
ความเป็นไปได้ของเว็บอีกแบบ — Gemini และโปรโตคอลเปิด
- นอกเหนือจากเว็บที่มี HTTP·HTML เป็นศูนย์กลาง ยังมีพื้นที่อินเทอร์เน็ตแบบใหม่อย่าง โปรโตคอล Gemini
- Gemini เป็นโปรโตคอลน้ำหนักเบาที่มีโครงสร้างเรียบง่าย พร้อม ความปลอดภัยและการยืนยันตัวตนที่ฝังมาในตัว และทำงานอยู่นอกอิทธิพลของ Google
- อย่างไรก็ตาม บทความย้ำว่าปัญหาอยู่ที่ โครงสร้างทางสังคม ไม่ใช่ที่ตัวเทคโนโลยี และตัวเทคโนโลยีเองยังคงใช้ได้ดี
- มีข้อเสนอว่าเบราว์เซอร์ ไม่ควรเลือกปฏิบัติตามโปรโตคอลหรือฟอร์แมต และควรรองรับแบบบูรณาการสำหรับ ฟอร์แมตมาร์กอัปน้ำหนักเบา เช่น Markdown, AsciiDoc, Gemtext
การถอดปลั๊กอินและการเสริมอำนาจควบคุมเว็บ
- ในอดีต อินเทอร์เฟซปลั๊กอิน NPAPI รองรับฟอร์แมตและโปรโตคอลได้หลากหลาย แต่ Google ค่อย ๆ ถอดออกตั้งแต่ปี 2013
- ส่งผลให้ เส้นทางของการขยายเว็บและการนำเทคโนโลยีเชิงทดลองมาใช้ถูกปิดกั้น
- Encrypted Media Extensions(EME) ที่เกิดขึ้นหลังการถอดปลั๊กอิน ถูกวิจารณ์ว่าเป็นการทำ DRM ให้เป็นมาตรฐาน และ บ่อนทำลายหลักการเปิดของ W3C
- ส่วนส่วนขยายเบราว์เซอร์ก็เป็นเพียง ของทดแทนที่ถูกจำกัดความสามารถ ภายใต้ข้ออ้างด้านความปลอดภัย โดยเฉพาะ Manifest V3 ที่ทำให้ความสามารถในการบล็อกโฆษณาอ่อนลง
- บทความวิเคราะห์ว่าการเปลี่ยนแปลงเหล่านี้นำไปสู่ การลดอำนาจควบคุมของผู้ใช้และการเพิ่มอำนาจควบคุมขององค์กร
“A mesh of building blocks” — โครงสร้างเว็บในอุดมคติ
- เว็บในอุดมคติควรเป็น โครงสร้างแบบโมดูลาร์ที่อิงปลั๊กอิน ซึ่งสามารถเพิ่มโปรโตคอล·ฟอร์แมต·ภาษาสคริปต์ใหม่ ๆ ได้อย่างอิสระ
- หากเป็นเช่นนั้น RSS·SMIL·XSLT·XQuery·XHTML2 ก็น่าจะยังพัฒนาต่อเนื่องมาจนถึงปัจจุบัน
- แต่ในความเป็นจริง โครงสร้างกลับกลายเป็นแบบที่ Google ผูกขาดการตัดสินทิศทางวิวัฒนาการของเว็บ และผู้เขียนสรุปว่าจำเป็นต้องมี การต่อต้านที่นำโดยผู้ใช้ เพื่อย้อนทิศทางนี้
Resist — คำประกาศแห่งการต่อต้าน
- ภายใต้คำขวัญ “Do not comply. Resist.” มีการเรียกร้องให้ลงมือดังนี้
- คงการใช้งาน RSS ต่อไป
- ใช้ XSLT อย่างต่อเนื่อง
- เลือกใช้ JPEG XL เป็นฟอร์แมตรูปภาพพื้นฐาน
- มองพฤติกรรมที่ไม่เป็นมาตรฐานของเบราว์เซอร์ว่าเป็น ‘ข้อบกพร่องของเบราว์เซอร์’ ไม่ใช่ ‘ข้อผิดพลาดของเว็บไซต์’
- สิ่งนี้ถูกเสนอไม่ใช่แค่ในฐานะการเลือกเทคโนโลยี แต่เป็น การต่อต้านเชิงปฏิบัติเพื่อปกป้องเว็บเปิด
Post Scriptum และปฏิกิริยา
- มีการแนะนำโปรเจกต์ที่เกี่ยวข้องกับ XSLT เช่น xslt.rip และ เว็บไซต์ส่วนตัวของผู้เขียน พร้อมกล่าวถึงความพยายามสร้าง SVG ด้วย XSLT
- แม้จะมีการถกเถียงต่อใน Hacker News และ Lobste.rs แต่ผู้เขียนชี้ว่าความเห็นจำนวนมาก ประเมินความสำคัญของ XSLT ต่ำเกินไป
- ผู้เขียนย้ำว่า XSLT มีประสิทธิภาพกว่าการเรนเดอร์ฝั่งเซิร์ฟเวอร์ และได้เปรียบเป็นพิเศษในสภาพแวดล้อม ขนาดเล็กและโฮสต์เอง
- โดยสรุปแล้ว บทความยืนยันอีกครั้งว่า การใช้งานเทคโนโลยีเปิดอย่าง XSLT ต่อไป คือยุทธศาสตร์สำคัญต่อการอยู่รอดของเว็บเปิด
3 ความคิดเห็น
มีคนถามว่าทำไมไม่ฝังมาให้ในตัว แต่ในอีกมุมหนึ่งก็ดูเหมือนไม่มีเหตุผลจำเป็นอะไรที่ต้องฝังมาให้ในตัวเหมือนกัน..
ความคิดเห็นจาก Hacker News
การ ถอด XSLT ออกจากเบราว์เซอร์ เป็นสิ่งที่ควรทำมานานแล้ว
ในฐานะอดีตผู้ดูแล libxslt ฉันพอรู้ภูมิหลังของการตัดสินใจนี้อยู่บ้าง
ที่น่าสนใจกว่าคือ Chromium มีแผนจะเปลี่ยนไปใช้ ตัวแยกวิเคราะห์ XML ที่เขียนด้วย Rust
ตอนนี้ดูเหมือนจะเลือก xml-rs ซึ่งรองรับ XML เพียงบางส่วน
กล่าวคือ Google ดูเหมือนกำลังจะเลือกการรองรับ XML ที่ไม่เป็นไปตามมาตรฐานอย่างสมบูรณ์
มันทำให้นึกถึง ยุค Internet Explorer 5.1 ที่อาศัยส่วนแบ่งตลาดเพื่อเมินมาตรฐาน
หลังจาก XHTML แพ้ให้กับ HTML5 โค้ดซับซ้อนที่เกี่ยวกับ XML ก็ค่อยๆ หายไปตามธรรมชาติ
การย้ายไป Rust เพื่อ ลดพื้นผิวการโจมตีด้านความปลอดภัย เป็นทางเลือกที่สมเหตุสมผล
การแยกวิเคราะห์ XML ที่เหลือสามารถแทนด้วย polyfill หรือ wasm ใน JS ได้
ฉันทำงานอยู่ในทีม Chrome แต่ไม่ได้มีส่วนเกี่ยวข้องโดยตรงกับงานนี้
ในอดีตเว็บมีผู้ดูแลเว็บไซต์เป็นตัวหลัก และเบราว์เซอร์ทำหน้าที่เป็น เครื่องมือ (ผู้รับใช้) ของพวกเขา
ทิศทางตอนนี้กำลังห่างไกลจากปรัชญานั้น
เพราะ XML เปิดช่องให้เกิดช่องโหว่การระเบิดข้อมูลอย่าง Billion Laughs attack
คำอธิบายที่เกี่ยวข้อง
ข้ออ้างว่าการดู RSS feed ในเบราว์เซอร์จำเป็นต้องมี XSLT นั้นเกินจริง
ทำด้วย JavaScript ก็เพียงพอ และ polyfill ของ Google ก็ทำงานแบบนั้น
ฉันเคยเขียน XSLT ไปหลายพันบรรทัด แต่ คิดว่า JavaScript ดีกว่ามาก
ตอนนี้ XSLT ควรถูกถอดออกด้วยเหตุผลด้านความปลอดภัย
มีการพูดถึงเรื่องนี้ใน OffensiveCon 2025
สิ่งทดแทนด้วย JS นั้นซับซ้อนและมีจุดเริ่มต้นที่ยากกว่า
เมื่อการทำหน้าเว็บส่วนตัวแบบง่ายๆ กลายเป็นเรื่องยากขึ้น จิตวิญญาณของ “เว็บแบบเปิด” ก็อ่อนแอลง
การหายไปของ RSS และการต้องพึ่งพาแพลตฟอร์มอย่าง Facebook คือผลลัพธ์ของเรื่องนี้
ดู เอกสาร Web Components
ฉันจำได้ว่าเบราว์เซอร์อิสระหลายตัวหายไป เพราะตามระบบนิเวศ JS ที่เปลี่ยนเร็วไม่ทัน
คิดถึง Konqueror ในอดีต
document()หลังจากดูแล้ว ฉันก็รู้สึกว่าการถอด XSLT นั้นสมเหตุสมผล
<?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;ก็ควรต้องรองรับรูปแบบประมาณนี้
แต่จากการติดตั้งใช้งานในปัจจุบัน ยังยากที่จะใช้ JS ทดแทนประสบการณ์ระดับเดียวกับ XSLT ได้อย่างสมบูรณ์
ฉันเห็นด้วยกับข้อกล่าวหาว่า Google กำลังฆ่าเว็บแบบเปิด แต่ XSLT เป็นเหตุผลที่ค่อนข้างอ่อน
มันเป็นฟีเจอร์ซับซ้อนที่แทบไม่มีคนใช้ จึงดูเหมือนเป็นการตัดสินใจเพื่อลดทรัพยากรในการบำรุงรักษา
สำหรับการแสดง RSS/Atom feed การ ใส่ความสามารถรองรับโดยตรงในเบราว์เซอร์จะดีกว่า
จึงไม่ควรตัดสินจากความถี่ในการใช้งานอย่างเดียว
ควรร่วมมือกับผู้ใช้กลุ่มสำคัญเหล่านี้และเลิกใช้แบบค่อยเป็นค่อยไป
“เว็บแบบเปิด” กับ XSLT แทบไม่เกี่ยวข้องกัน
เว็บแบบเปิดหมายถึงสภาพแวดล้อมที่ใครก็สามารถรันเซิร์ฟเวอร์ สร้างเว็บไซต์ และพัฒนาเบราว์เซอร์ได้
XSLT เป็นเทคโนโลยีที่ตายไปนานแล้ว และแทบไม่มีเว็บไซต์ไหนพังเพราะการถอดมันออก
ตรงกันข้าม มันยังช่วย กำจัดช่องโหว่ด้านความปลอดภัย ได้ด้วย
ปัญหาไม่ได้อยู่ที่ตัว XSLT แต่อยู่ที่การติดตั้งใช้งาน libxslt ที่มีช่องโหว่
จริงๆ ก็สร้าง implementation อื่นขึ้นมาแทนได้ แต่ ปัญหาคือ Google เลือกที่จะ “ฆ่า” ฟีเจอร์นี้
เพียงแต่ตอนนี้ผู้คนชอบเสพผ่าน ฟีดโซเชียล มากกว่าการติดตามเว็บไซต์รายแห่ง
นี่ไม่ใช่ปัญหาทางเทคนิค แต่เป็น การเปลี่ยนแปลงพฤติกรรมของผู้ใช้
ในบรรดาคนที่บ่นเรื่องการเลิกใช้ XSLT ฉันแทบไม่เห็นใครอธิบายเหตุผลการใช้งานจริงได้ชัดเจน
ส่วนใหญ่พูดถึงมันในฐานะ สัญลักษณ์ของการต่อต้าน มากกว่า
ตลอดเวลากว่า 20 ปีมีความคาดหวังว่า “เว็บเพจจะมองเห็นได้ตลอดไป”
เมื่อผู้ดูแล libxslt ลาออกเพราะภาระจากรายงานด้านความปลอดภัย
ผู้ผลิตเบราว์เซอร์จึงเลือก ถอดฟีเจอร์ออกแทนที่จะจ่ายต้นทุนเพื่อดูแลต่อ
การใช้มันเป็นสัญลักษณ์แห่งการขัดขืนก็เหมือนทรมานตัวเอง
ถ้าจำเป็นจริงก็แทนได้ด้วย polyfill หรือการแปลงฝั่งเซิร์ฟเวอร์
เคยใช้เพื่อแปลง RSS/Atom feed ให้อ่านง่ายขึ้น
คุณเห็นความต่างได้จากเว็บไซต์ rss.style ที่ฉันทำ
ที่ Mozilla ถอด RSS ออก ไม่ใช่เพราะโดน Google กดดัน
แต่เป็นเพราะ ผู้ใช้ไม่ต้องการ RSS
ตรงกันข้าม Google กลับเป็นหนึ่งในบริษัทที่ลงทุนกับการพัฒนาเว็บแบบเปิดมากที่สุด
การที่ WHATWG พยายามเปลี่ยนเว็บให้เป็น แพลตฟอร์มสำหรับแอปพลิเคชัน ก็เป็นผลจากความต้องการของนักพัฒนาและผู้ใช้
Blink เป็น โอเพนซอร์ส จึงยังสามารถดูแล fork ต่อได้
RSS มีความเป็นเทคนิคมากเกินไปสำหรับคนทั่วไป และเมื่อ Google ปิด Reader
โซเชียลมีเดียก็เข้ามาแทนที่
แต่สุดท้ายก็ เสริมโครงสร้างผูกขาด
ความเป็นโอเพนซอร์สของ Blink เพียงอย่างเดียวไม่ได้รับประกันความเปิดกว้างที่แท้จริง
แต่ถ้า การมีอยู่ของมันไม่ได้ก่อโทษ ก็ไม่มีเหตุผลจำเป็นต้องลบออก
ฉันเห็นด้วยกับผู้เขียนบางส่วน
แต่การบอกว่าเบราว์เซอร์ควรต้องรองรับถึงขั้น Gopher ด้วยนั้น ซับซ้อนเกินจำเป็น
ในมุมของโครงการ Chrome มันดูเป็นการตัดสินใจเพื่อทำให้ระบบง่ายขึ้น
การถอดออกจึงสมเหตุสมผล และคนทำงานในอุตสาหกรรมเว็บส่วนใหญ่ก็น่าจะเห็นด้วย
การแยกวิเคราะห์ XML ที่อิง C มักทำให้รู้สึก หวาดกลัวด้านความปลอดภัย เสมอ
การแยกออกไปเป็น ส่วนขยาย (extension) น่าจะดีกว่า
แต่กลับลบฟีเจอร์เก่าโดยอ้างเรื่องความเรียบง่ายนั้น ขัดแย้งในตัวเอง
ไม่ว่าทางไหนก็ต้องมีคนเสียประโยชน์
ฉันกำลังคิดจะเปลี่ยนบล็อกของฉันให้เป็น XML/XSLT
ไม่มีใครอ่านอยู่แล้ว เพราะงั้นต่อไปฉันจะได้ โทษ Chrome เรื่องทราฟฟิกตกต่ำ ได้
ฉันไม่ใช่แฟนของ Google แต่การถอด XSLT ก็เป็น โอกาสในการลดความซับซ้อนของ Web API
สำหรับเบราว์เซอร์อิสระอย่าง Ladybird มันอาจช่วยลดภาระได้
สุดท้ายแล้วอาจทำให้อำนาจผูกขาดของ Google อ่อนลงด้วยซ้ำ
คงพูดไม่ได้ว่ามันดำเนินไปแบบ “แทบไม่มีแรงต้าน”
ในช่วง 10–15 ปีที่ผ่านมา มาตรฐานเว็บมีแนวโน้มจะใส่ ความต้องการเฉพาะทาง เข้าไปในเบราว์เซอร์
การถอด XSLT พร้อมออก polyfill ดูเหมือนเป็น ทิศทางที่ผลักความซับซ้อนออกไปนอกเบราว์เซอร์
บทความที่บอกว่าควรรองรับ XSLT ในปี 2025 นี่สดใหม่ดีนะ... จริงอยู่ว่ามันถูกใช้แวบ ๆ ในการจัดสไตล์อย่าง RSS เป็นต้น แต่ก็คงพูดได้ยากว่าเป็นสิ่งที่ถูกใช้งานอย่างแพร่หลายแบบครอบจักรวาล