- Việc Chrome ngừng hỗ trợ XSLT là một động thái làm suy yếu công nghệ cốt lõi của web mở; dù lấy lý do là vấn đề bảo mật, Google đã loại bỏ tính năng mà không cung cấp công nghệ thay thế
- Google đề xuất polyfill dựa trên JavaScript thay cho tính năng tích hợp sẵn trong trình duyệt, nhưng không nhúng nó vào trình duyệt mà chuyển gánh nặng triển khai sang cho lập trình viên
- Quyết định này dẫn tới sự suy yếu của hệ sinh thái web độc lập dựa trên RSS·XML, và Mozilla cùng Apple cũng đang đi theo hướng tương tự
- Bài viết chỉ trích rằng WHATWG không còn đóng vai trò người bảo vệ web mở, mà kiểm soát các tiêu chuẩn web theo hướng đặt lợi ích của các tập đoàn lớn lên trước
- Việc thu hẹp khả năng mở rộng của trình duyệt và tiêu chuẩn hóa DRM đang cố định hóa một cấu trúc web làm suy yếu quyền kiểm soát của người dùng; để đối phó, bài viết kêu gọi tiếp tục sử dụng và phản kháng để bảo vệ các công nghệ mở như RSS, XSLT, JPEG XL
Chấm dứt hỗ trợ XSLT và bước đi của Google
- Google đã loại bỏ hỗ trợ XSLT khỏi Chrome, viện dẫn các lỗ hổng bảo mật nhưng không đưa ra thư viện thay thế hay phương án cải thiện nào
- Tác giả chỉ trích rằng đây là cái cớ dựa vào các vấn đề bảo mật của những thư viện FLOSS hiện có
- Đồng thời chỉ ra rằng Google thậm chí không tận dụng cơ hội đưa vào một bản triển khai XSLT hiện đại được viết bằng ngôn ngữ an toàn hơn
- Polyfill JavaScript mà Google đưa ra chỉ được cung cấp dưới dạng gọi từ bên ngoài thay vì tích hợp vào trình duyệt, nên bị đánh giá là một giải pháp thay thế phi tiêu chuẩn và kém hiệu quả
- Bài viết cho rằng động thái này là hành vi có chủ đích nhằm làm suy yếu nền tảng của web độc lập dựa trên RSS và XML
- Phân tích cho rằng dù polyfill không đủ tốt, hay kể cả nếu đủ tốt nhưng Google vẫn không tích hợp, thì lý do vẫn là nhằm kìm hãm chính việc sử dụng XSLT
“Do. Not. Comply.” — lời kêu gọi phản kháng
- Tác giả nhấn mạnh đừng chấp nhận việc cài polyfill hay sửa XML, mà hãy yêu cầu khôi phục hỗ trợ XSLT trong trình duyệt
- Tác giả dự định tiếp tục sử dụng các công nghệ tiêu chuẩn như XSLT, MathML, SVG, SMIL, đồng thời giữ lại hộp cảnh báo (infobox) để thông báo cho người dùng về hành vi phi tiêu chuẩn của trình duyệt
- Theo bài viết, quyết định của Google không xuất phát từ lý do kỹ thuật mà từ động cơ chính trị và thương mại, như một phần trong nỗ lực kiểm soát web mở
- Bài viết cũng chỉ trích Mozilla và Apple đang đi theo hướng tương tự, thiết kế trình duyệt không còn như User Agent mà như công cụ của chủ nghĩa tư bản giám sát
WHATWG và sự méo mó của tiêu chuẩn web
- WHATWG ban đầu là một tổ chức thảo luận vì web mở, nhưng nay bị đánh giá đã biến thành một tổ chức khép kín do các tập đoàn lớn chi phối
- Tổ chức này đang biến web từ một kho tri thức thành nền tảng phân phối ứng dụng, ưu tiên tối đa hóa lợi nhuận doanh nghiệp hơn là quyền kiểm soát của người dùng
- Trình duyệt không còn là User Agent đại diện cho người dùng nữa, mà hoạt động như công cụ kiểm soát phục vụ lợi ích doanh nghiệp
- Bài viết cho rằng sự thay đổi này xung đột trực diện với tầm nhìn web mở mà W3C theo đuổi
Sự cần thiết của một cuộc chiến trình duyệt mới
- Thị trường trình duyệt hiện tại có cấu trúc phụ thuộc vào các engine do Google·Apple·Mozilla chi phối, gần như không có lựa chọn độc lập thực sự
- Bài viết có nhắc tới các trình duyệt thay thế như Vivaldi, LibreWolf, WaterFox, Pale Moon, nhưng phần lớn vẫn phụ thuộc vào Blink hoặc Gecko
- Pale Moon được đánh giá là một trong số ít trình duyệt vẫn duy trì hỗ trợ RSS và JPEG XL
- Tác giả cho rằng cần có cuộc chiến giữa người dùng và doanh nghiệp, tức một cuộc chiến trình duyệt mới để giành lại quyền kiểm soát web
Khả năng của một web khác — Gemini và các giao thức mở
- Ngoài web xoay quanh HTTP·HTML, vẫn còn những không gian Internet mới như giao thức Gemini
- Gemini là một giao thức nhẹ với cấu trúc đơn giản cùng các tính năng bảo mật và xác thực được tích hợp sẵn, vận hành ngoài phạm vi ảnh hưởng của Google
- Tuy nhiên, bài viết nhấn mạnh vấn đề không nằm ở công nghệ mà ở cấu trúc xã hội, còn bản thân công nghệ vẫn hoàn toàn có giá trị
- Theo tác giả, trình duyệt không nên phân biệt đối xử theo giao thức hay định dạng, và nên hỗ trợ tích hợp các định dạng markup nhẹ như Markdown, AsciiDoc, Gemtext
Loại bỏ plugin và tăng cường kiểm soát web
- Trước đây, giao diện plugin NPAPI hỗ trợ nhiều định dạng và giao thức khác nhau, nhưng Google đã từng bước loại bỏ từ năm 2013
- Hệ quả là khả năng mở rộng của web và con đường đưa công nghệ thử nghiệm vào sử dụng đã bị chặn lại
- Encrypted Media Extensions (EME) xuất hiện sau khi plugin bị loại bỏ đã tiêu chuẩn hóa DRM, và bị chỉ trích là làm tổn hại các nguyên tắc mở của W3C
- Các tiện ích mở rộng trình duyệt, dưới danh nghĩa bảo mật, chỉ còn là những vật thay thế bị giới hạn chức năng; đặc biệt Manifest V3 làm suy yếu khả năng chặn quảng cáo
- Bài viết phân tích rằng những thay đổi này dẫn tới sự thu hẹp quyền kiểm soát của người dùng và tăng cường kiểm soát của doanh nghiệp
“A mesh of building blocks” — cấu trúc web lý tưởng
- Một web lý tưởng nên có cấu trúc mô-đun dựa trên plugin, nơi người ta có thể tự do bổ sung giao thức, định dạng và ngôn ngữ script mới
- Theo bài viết, nếu cấu trúc như vậy được duy trì, RSS, SMIL, XSLT, XQuery, XHTML2 đã có thể tiếp tục phát triển
- Nhưng thực tế đã trở thành một cấu trúc nơi Google gần như độc quyền quyết định hướng tiến hóa của web, và tác giả kết luận rằng cần sự phản kháng do người dùng dẫn dắt để đảo ngược điều đó
Resist — tuyên ngôn phản kháng
- Dưới khẩu hiệu “Do not comply. Resist.”, tác giả kêu gọi các hành động sau
- Tiếp tục dùng RSS
- Tiếp tục tận dụng XSLT
- Chấp nhận JPEG XL làm định dạng ảnh mặc định
- Xem các hành vi phi tiêu chuẩn của trình duyệt là ‘lỗi của trình duyệt’, không phải ‘lỗi của trang web’
- Theo bài viết, đây không chỉ là lựa chọn kỹ thuật mà còn là một hình thức phản kháng thực tiễn để bảo vệ web mở
Post Scriptum và phản ứng
- Tác giả giới thiệu dự án liên quan đến XSLT là xslt.rip cùng trang cá nhân của mình, đồng thời nhắc tới thử nghiệm tạo SVG bằng XSLT
- Các cuộc thảo luận tiếp tục diễn ra trên Hacker News và Lobste.rs, nhưng tác giả cho rằng nhiều bình luận đã đánh giá thấp tầm quan trọng của XSLT
- Tác giả nhấn mạnh rằng XSLT hiệu quả hơn server rendering, đặc biệt phù hợp trong môi trường nhỏ và tự host
- Cuối cùng, bài viết tái khẳng định rằng việc tiếp tục sử dụng các công nghệ mở như XSLT là chiến lược then chốt để web mở tồn tại
3 bình luận
Mọi người hỏi sao không tích hợp sẵn, nhưng ngược lại thì cũng chẳng thấy có lý do gì bắt buộc phải tích hợp sẵn cả..
Ý kiến trên Hacker News
Việc loại bỏ XSLT khỏi trình duyệt là điều từ lâu đã cần làm
Tôi là cựu maintainer của libxslt nên phần nào biết bối cảnh dẫn tới quyết định này
Điều thú vị hơn là Chromium đang lên kế hoạch chuyển sang trình phân tích XML viết bằng Rust
Hiện họ đang ưu tiên xml-rs, nhưng thư viện này chỉ triển khai một phần của XML
Tức là có vẻ như Google đang chọn hỗ trợ XML không tuân thủ hoàn toàn tiêu chuẩn
Nó gợi nhớ thời Internet Explorer 5.1 khi người ta dựa vào thị phần để bỏ qua chuẩn
Từ sau khi XHTML bị HTML5 lấn át, các đoạn mã XML phức tạp cũng đang dần biến mất một cách tự nhiên
Chuyển sang Rust để giảm bề mặt tấn công bảo mật là lựa chọn hợp lý
Phần phân tích XML còn lại có thể thay bằng polyfill hoặc wasm trong JS
Tôi làm trong nhóm Chrome nhưng không trực tiếp tham gia công việc này
Trước đây web xoay quanh người vận hành website, còn trình duyệt đóng vai trò công cụ (đầy tớ) của họ
Hướng đi hiện nay đang ngày càng rời xa triết lý đó
Vì XML cho phép các lỗ hổng bùng nổ dữ liệu như tấn công Billion Laughs
Giải thích liên quan
Nói rằng XSLT là bắt buộc để xem feed RSS trong trình duyệt là phóng đại
JavaScript cũng hoàn toàn làm được, và polyfill của Google hoạt động theo cách đó
Tôi từng viết hàng nghìn dòng XSLT nhưng vẫn thấy JavaScript tốt hơn nhiều
XSLT giờ nên bị loại bỏ vì lý do bảo mật
Nội dung này được đề cập trong bài trình bày tại OffensiveCon 2025
Các tính năng thay thế bằng JS thì phức tạp và rào cản tiếp cận cao hơn
Khi việc làm một trang web cá nhân đơn giản trở nên khó hơn, tinh thần của 'web mở' cũng suy yếu
Việc RSS biến mất và bị phụ thuộc vào các nền tảng như Facebook là hệ quả của điều đó
Xem thêm tài liệu về Web Components
Tôi còn nhớ các trình duyệt độc lập từng biến mất vì không theo kịp hệ sinh thái JS phát triển quá nhanh
Tôi nhớ Konqueror ngày xưa
document()Sau khi xem, tôi thấy việc loại bỏ XSLT là hợp lý
<?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;cần phải hỗ trợ dạng như vậy
Nhưng với triển khai hiện tại, rất khó để JS thay thế hoàn toàn trải nghiệm cấp độ XSLT
Tôi đồng ý với nhận định rằng Google đang giết chết web mở, nhưng XSLT là ví dụ khá yếu
Đây là tính năng phức tạp hầu như không được dùng, nên quyết định này có vẻ là để giảm tài nguyên bảo trì
Với việc hiển thị feed RSS/Atom, tích hợp hỗ trợ trực tiếp trong trình duyệt sẽ tốt hơn
Không nên chỉ đánh giá theo tần suất sử dụng
Cần phối hợp với các nhóm người dùng quan trọng để loại bỏ dần dần
“Web mở” và XSLT thực ra không liên quan nhiều đến nhau
Web mở là môi trường nơi ai cũng có thể vận hành máy chủ, làm website và phát triển trình duyệt
XSLT là công nghệ đã chết từ lâu, và hầu như không có trang nào bị hỏng vì nó bị gỡ bỏ
Ngược lại còn có tác dụng loại bỏ lỗ hổng bảo mật
Vấn đề không nằm ở XSLT mà là ở triển khai libxslt có lỗ hổng
Hoàn toàn có thể làm một triển khai thay thế, nhưng Google lại chọn 'giết' tính năng mới là vấn đề
Chỉ là giờ mọi người thích tiêu thụ qua feed mạng xã hội hơn là theo dõi từng website riêng lẻ
Đây không phải vấn đề kỹ thuật mà là sự thay đổi trong hành vi người dùng
Tôi hiếm khi thấy ai phàn nàn về việc bỏ XSLT mà giải thích rõ họ thực sự dùng nó để làm gì
Phần lớn chỉ nhắc tới nó như một biểu tượng của sự phản kháng
Hơn 20 năm nay luôn tồn tại kỳ vọng rằng “trang web sẽ hiển thị mãi mãi”
Khi maintainer của libxslt từ chức vì gánh nặng từ các báo cáo bảo mật,
các hãng trình duyệt đã chọn loại bỏ tính năng thay vì trả chi phí để duy trì
Dùng nó làm biểu tượng phản kháng chỉ là tự làm khổ mình
Nếu cần thì hoàn toàn có thể thay bằng polyfill hoặc chuyển đổi phía máy chủ
Trước đây nó được dùng để chuyển feed RSS/Atom thành dạng dễ nhìn hơn
Có thể thấy khác biệt đó trên trang rss.style mà tôi tạo ra
Mozilla gỡ RSS không phải vì áp lực từ Google, mà vì
người dùng không muốn RSS
Ngược lại, Google là một trong những công ty đầu tư nhiều nhất vào sự phát triển của web mở
Việc WHATWG muốn biến web thành nền tảng ứng dụng là kết quả của nhu cầu từ nhà phát triển và người dùng
Blink là mã nguồn mở, nên vẫn có thể duy trì các bản fork
RSS quá kỹ thuật với đại chúng, và khi Google xóa Reader,
mạng xã hội đã chiếm lấy vị trí đó
nhưng cuối cùng lại củng cố cấu trúc độc quyền
Chỉ riêng việc Blink là mã nguồn mở không đảm bảo được tính mở thực sự
nếu bản thân nó không gây hại thì cũng không nhất thiết phải xóa
Tôi phần nào đồng cảm với lập luận của tác giả, nhưng
việc bắt trình duyệt phải hỗ trợ cả Gopher thì đúng là quá tải về độ phức tạp
Từ góc nhìn của dự án Chrome, đây có vẻ là quyết định để đơn giản hóa
Việc loại bỏ là hợp lý, và đa số người làm trong ngành web đều đồng ý
Việc phân tích XML bằng C luôn tạo cảm giác đáng lo về bảo mật
tốt hơn là tách nó thành extension
mà lại nói xóa tính năng cũ vì muốn đơn giản hóa thì rất mâu thuẫn
Dù theo hướng nào cũng sẽ có người chịu thiệt
Tôi đang định chuyển blog của mình sang XML/XSLT
Vì chẳng ai đọc cả nên giờ tôi có thể đổ lỗi lượng truy cập thấp cho Chrome
Tôi không phải fan của Google, nhưng việc bỏ XSLT là cơ hội để giảm độ phức tạp của web API
Với các trình duyệt độc lập như Ladybird, điều đó có thể giảm bớt gánh nặng
Kết quả là thậm chí còn có thể làm suy yếu thế độc quyền của Google
Khó mà nói nó diễn ra 'không gặp phản đối lớn'
Trong 10~15 năm qua, tiêu chuẩn web có xu hướng cố đưa các nhu cầu ngách vào trình duyệt
Việc bỏ XSLT và cung cấp polyfill có vẻ là hướng đẩy độ phức tạp ra ngoài trình duyệt
Việc phải hỗ trợ XSLT vào năm 2025 nghe khá mới mẻ... Đúng là nó có lúc được dùng thoáng qua trong việc tạo kiểu như RSS, nhưng khó mà xem đó là thứ được sử dụng rộng rãi cho mục đích phổ thông.