- Chrome’da XSLT desteğinin kaldırılması, Google’ın açık webin temel teknolojilerini zayıflatan bir adımı olarak değerlendiriliyor; gerekçe olarak güvenlik sorunları öne sürülse de yerine geçecek bir teknoloji sunulmadan özellik kaldırılıyor
- Google, tarayıcı içindeki yerleşik işlev yerine JavaScript tabanlı bir polyfill önerdi; ancak bunu tarayıcıya gömmek yerine uygulama yükünü geliştiricilere yıktı
- Bu kararın RSS·XML tabanlı bağımsız web ekosistemini zayıflatmaya yol açtığı, Mozilla ve Apple’ın da benzer bir yönde hareket ettiği belirtiliyor
- Yazı, WHATWG’nin artık açık webin koruyucusu rolünü yerine getiremediğini ve web standartlarını büyük şirketlerin çıkarları doğrultusunda kontrol ettiğini eleştiriyor
- Tarayıcı genişletilebilirliğinin daraltılması ve DRM’in standartlaştırılmasıyla kullanıcı kontrolünün zayıfladığı bir web yapısının kalıcı hale geldiği, buna karşı RSS·XSLT·JPEG XL gibi açık teknolojilerin kullanılmaya devam edilmesi ve direnilmesi çağrısı yapılıyor
XSLT desteğinin kaldırılması ve Google’ın yönelimi
- Google, Chrome’da XSLT desteğini sonlandırıyor; gerekçe olarak güvenlik açıklarını gösteriyor ancak alternatif bir kütüphane ya da iyileştirme planı sunmuyor
- Bunun, mevcut FLOSS kütüphanelerindeki güvenlik sorunlarını bahane etmek olduğu eleştiriliyor
- Daha güvenli dillerle yazılmış modern XSLT uygulamalarını devreye alma fırsatının bile kullanılmadığı belirtiliyor
- Google’ın sunduğu JavaScript polyfill, tarayıcıya yerleşik olarak değil yalnızca dış çağrı yöntemiyle sağlanıyor; bu yüzden standart dışı ve verimsiz bir ikame çözüm olarak değerlendiriliyor
- Yazı, bu adımın RSS ve XML tabanlı bağımsız webin temelini zayıflatmaya yönelik kasıtlı bir hamle olduğunu savunuyor
- Polyfill’in yetersiz olması ya da yeterli olsa bile Google’ın bunu yerleşik hale getirmemesi, amaçlarının XSLT kullanımını baştan caydırmak olduğu şeklinde yorumlanıyor
“Do. Not. Comply.” — direniş çağrısı
- Yazar, polyfill kurmaya ya da XML’i değiştirmeye boyun eğilmemesi, bunun yerine tarayıcılarda XSLT desteğinin geri getirilmesinin talep edilmesi gerektiğini vurguluyor
- XSLT, MathML, SVG, SMIL gibi standart teknolojileri kullanmayı sürdürmeyi ve tarayıcıların standart dışı davranışları konusunda kullanıcıları bilgilendiren uyarı kutularını (infobox) korumayı planladığını söylüyor
- Google’ın kararının teknik gerekçelerden değil, politik ve ticari saiklerden kaynaklandığı; bunun açık webi kontrol etme çabasının bir parçası olduğu anlatılıyor
- Mozilla ve Apple’ın da benzer bir yönde ilerlediği, tarayıcıları User Agent olmaktan çıkarıp gözetim kapitalizminin araçları olarak tasarladıkları eleştirisi yapılıyor
WHATWG ve web standartlarının bozulması
- WHATWG’nin başlangıçta açık web için bir uzlaşı platformu olduğu, ancak bugün büyük şirketler merkezli kapalı bir yapıya dönüştüğü ileri sürülüyor
- Bu yapı, webi bir bilgi deposu olmaktan çıkarıp bir ‘uygulama dağıtım platformuna’ dönüştürüyor; kullanıcı kontrolü yerine şirket kârını en üst düzeye çıkarmayı önceliklendiriyor
- Tarayıcıların artık kullanıcı vekili değil, şirket çıkarlarına hizmet eden kontrol araçları gibi işlediği savunuluyor
- Bunun, W3C’nin hedeflediği açık web vizyonuyla doğrudan çeliştiği belirtiliyor
Yeni bir tarayıcı savaşına ihtiyaç
- Günümüz tarayıcı pazarı, Google·Apple·Mozilla merkezli motor bağımlılığı nedeniyle bağımsız alternatiflerin neredeyse kalmadığı bir yapı olarak tanımlanıyor
- Vivaldi, LibreWolf, WaterFox, Pale Moon gibi alternatiflerden söz edilse de bunların çoğu Blink veya Gecko motorlarına bağımlı
- Pale Moon, RSS ve JPEG XL desteğini koruyan az sayıdaki tarayıcıdan biri olarak anılıyor
- Yazı, kullanıcılarla şirketler arasında bir savaş, yani web üzerindeki kontrolü geri almak için yeni bir tarayıcı savaşı gerektiğini savunuyor
Başka bir webin ihtimali — Gemini ve açık protokoller
- HTTP·HTML merkezli webin dışında, Gemini protokolü gibi başka internet alanlarının da var olduğu belirtiliyor
- Gemini, basit yapısı ve yerleşik güvenlik ile kimlik doğrulama özellikleri olan hafif bir protokol; Google’ın etki alanının dışında işliyor
- Ancak asıl sorunun teknoloji değil, toplumsal yapı olduğu; teknolojinin kendisinin hâlâ geçerli olduğu vurgulanıyor
- Tarayıcıların protokol ya da formata göre ayrım yapmaması gerektiği; Markdown, AsciiDoc, Gemtext gibi hafif işaretleme biçimlerine entegre destek verilmesinin arzu edilir olduğu ifade ediliyor
Eklentilerin kaldırılması ve web üzerindeki denetimin güçlenmesi
- Geçmişte NPAPI eklenti arayüzü çeşitli format ve protokolleri destekliyordu, ancak Google bunu 2013’ten itibaren aşamalı olarak kaldırdı
- Bunun sonucunda webin genişletilebilirliği ve deneysel teknolojiler için benimseme kanalları kapatıldı
- Eklentilerin kaldırılmasından sonra gelen Encrypted Media Extensions (EME), DRM’i standartlaştırırken W3C’nin açıklık ilkelerini zedelemekle eleştiriliyor
- Tarayıcı uzantıları, güvenlik gerekçesiyle işlevleri sınırlandırılmış ikame çözümler olarak görülüyor; özellikle Manifest V3’ün reklam engelleme yeteneklerini zayıflattığı söyleniyor
- Bu değişimlerin kullanıcı kontrolünün azalmasına ve şirket denetiminin artmasına yol açtığı öne sürülüyor
“A mesh of building blocks” — ideal web yapısı
- İdeal webin, yeni protokollerin, formatların ve betik dillerinin serbestçe eklenebildiği eklenti tabanlı modüler bir yapı olması gerektiği savunuluyor
- Böyle bir yapıda RSS·SMIL·XSLT·XQuery·XHTML2 gibi teknolojilerin gelişmeye devam edeceği belirtiliyor
- Ancak gerçekte webin evrim yönünü Google’ın tek taraflı biçimde belirlediği bir yapının ortaya çıktığı, bunu tersine çevirmek için kullanıcı öncülüğünde direniş gerektiği sonucuna varılıyor
Resist — direniş bildirisi
- “Do not comply. Resist.” sloganı altında şu eylemler çağrılıyor
- RSS kullanmayı sürdürmek
- XSLT’yi kullanmaya devam etmek
- JPEG XL’i varsayılan görüntü formatı olarak benimsemek
- Tarayıcıların standart dışı davranışlarını ‘site hatası’ değil ‘tarayıcı kusuru’ olarak görmek
- Bunun yalnızca teknik bir tercih değil, açık webi korumaya yönelik pratik bir direniş olduğu ifade ediliyor
Post Scriptum ve tepkiler
- XSLT ile ilgili projeler olarak xslt.rip ve yazarın kişisel sitesi tanıtılıyor; ayrıca XSLT ile SVG üretme girişiminden söz ediliyor
- Hacker News ve Lobste.rs gibi platformlarda tartışmalar sürse de, birçok yorumun XSLT’nin önemini küçümsediği belirtiliyor
- Yazar, XSLT’nin sunucu tarafı render’dan daha verimli olduğunu; özellikle küçük ölçekli ve self-hosted ortamlarda avantaj sağladığını vurguluyor
- Sonuç olarak, XSLT gibi açık teknolojileri kullanmayı sürdürmenin açık webin hayatta kalması için temel strateji olduğu yeniden teyit ediliyor
3 yorum
Neden yerleşik yapmıyorsun deniyor ama tersine, bunu özellikle yerleşik yapmak için de pek bir neden yok gibi görünüyor..
Hacker News görüşleri
Tarayıcıdan XSLT'nin kaldırılması uzun zamandır yapılması gereken bir şeydi
Ben libxslt'nin eski bakımcılarından biri olarak, bu kararın arka planını bir ölçüde biliyorum
Daha da ilginç olan, Chromium'un Rust tabanlı bir XML ayrıştırıcısına geçmeyi planlaması
Şu anda xml-rs tercih ediliyor, ancak bu yalnızca XML'in bir kısmını uyguluyor
Yani Google, standarda tam uymayan XML desteğini seçmeye hazırlanıyor gibi görünüyor
Bu, pazar payına güvenerek standartları yok saydığı eski Internet Explorer 5.1 dönemini hatırlatıyor
XHTML'in HTML5 karşısında geri düşmesinden sonra XML ile ilgili karmaşık kodlar da doğal olarak ortadan kalkıyor
Rust'a taşıyarak güvenlik saldırı yüzeyini azaltmak mantıklı bir tercih
Geriye kalan XML ayrıştırma işi JS tarafında polyfill veya wasm ile ikame edilebilir
Ben Chrome ekibinde çalışıyorum ama bu işe doğrudan dahil değilim
Eskiden webde asıl özne site işletmecileriydi ve tarayıcılar onların aracı (hizmetkârı) rolündeydi
Bugünkü yönelim o felsefeden uzaklaşıyor
Çünkü XML, Billion Laughs saldırısı gibi veri patlaması zafiyetlerine izin veriyor
İlgili açıklama
RSS akışlarını tarayıcıda görüntülemek için XSLT'nin şart olduğu iddiası abartılı
JavaScript ile de fazlasıyla yapılabilir; Google'ın polyfill'i de bu şekilde çalışıyor
Binlerce satır XSLT yazdım ama JavaScript'in çok daha iyi olduğunu düşünüyorum
XSLT artık güvenlik gerekçesiyle kaldırılmalı
İlgili sunum OffensiveCon 2025'te ele alınıyor
JS'deki karşılıkları daha karmaşık ve giriş eşiği daha yüksek
Basit kişisel web sayfaları yapmanın zorlaşması, 'açık web' ruhunu zayıflatıyor
RSS'nin kaybolup Facebook gibi platformlara bağımlılığın artması da bunun sonucu
Web Components belgesi'ne bakılabilir
Hızla gelişen JS ekosistemine ayak uyduramadığı için bağımsız tarayıcıların ortadan kaybolduğunu hatırlıyorum
Eski Konqueror'u özlüyorum
document()fonksiyonunun güvenlik sorunlarını görmek mümkünBunu görünce XSLT'nin kaldırılmasının makul olduğunu düşündüm
<?xml-stylesheet type="application/javascript" href="https://example.org/script.js"?>;gibi bir biçimin desteklenmesi gerekir
Ama mevcut uygulamayla XSLT düzeyindeki deneyimi JS ile tamamen ikame etmek zor
Google'ın açık webi öldürdüğü iddiasına katılıyorum ama XSLT zayıf bir dayanak
Neredeyse hiç kullanılmayan karmaşık bir özellik olduğu için bakım maliyetini düşürmeye yönelik bir karar gibi görünüyor
RSS/Atom akışlarını göstermek için tarayıcıya doğrudan destek özelliği eklemek daha iyi olur
Yalnızca kullanım sıklığına bakarak karar verilmemeli
Önemli kullanıcılarla birlikte kademeli olarak kullanımdan kaldırılmalı
“Açık web” ile XSLT'nin pek ilgisi yok
Açık web, herkesin sunucu işletebildiği, site kurabildiği ve tarayıcı geliştirebildiği bir ortam demek
XSLT zaten uzun zaman önce ölmüş bir teknoloji ve kaldırılmasıyla bozulan site sayısı neredeyse yok
Hatta güvenlik açıklarını azaltma etkisi var
Sorun XSLT'nin kendisi değil, libxslt uygulamasındaki zafiyetlerdi
Alternatif bir uygulama da geliştirilebilirdi ama Google'ın özelliği 'öldürmeyi' seçmesi sorunlu
Ama insanlar artık tek tek site aboneliklerinden çok sosyal akış temelli tüketime yöneliyor
Bu teknik bir sorun değil, kullanıcı davranışındaki değişim
XSLT'nin kaldırılmasına itiraz edenler arasında bunu neden gerçekten kullandığını açıkça anlatabilen neredeyse kimse görmedim
Çoğu, bunu sadece bir direniş sembolü olarak anıyor
20 yılı aşkın süredir “web sayfaları sonsuza kadar görüntülenebilir” beklentisi vardı
libxslt bakımcısı güvenlik raporlarının yükü nedeniyle ayrılınca,
tarayıcı üreticileri maliyeti üstlenmek yerine özelliği kaldırmayı tercih etti
Bunu isyanın sembolü olarak kullanmak insanın kendine eziyet etmesi gibi
Gerekirse polyfill veya sunucu tarafı dönüşümle rahatça ikame edilebilir
RSS/Atom akışlarını daha okunur hâle getirmek için kullanmıştım
Bunun farkını yaptığım rss.style sitesinde görebilirsiniz
Mozilla'nın RSS'yi kaldırması Google'ın baskısı yüzünden değil,
kullanıcıların RSS istememesi yüzündendi
Google, açık webin gelişimine en çok yatırım yapan şirketlerden biri oldu
WHATWG'nin webi bir uygulama platformuna dönüştürmesi de geliştirici ve kullanıcı talebinin sonucu
Blink açık kaynak olduğu için çatallayıp sürdürmek de mümkün
RSS genel kitle için fazla teknikti ve Google Reader kapatılınca
onun yerini sosyal medya aldı
sonunda tekelci yapıyı güçlendirmişti
Blink'in açık kaynak olması tek başına gerçek açıklığı garanti etmiyor
sırf var olması zarar vermiyorsa ille de kaldırılması gerekmez
Yazarın tezine kısmen katılıyorum ama
tarayıcıların Gopher'ı da desteklemesi gerektiği fikri aşırı karmaşıklık olur
Chrome projesi açısından bakınca bu, sadeleştirme adına alınmış bir karar gibi
Kaldırılması makul ve web sektöründe çalışan çoğu kişi buna katılır
C dili tabanlı XML ayrıştırma her zaman güvenlik açısından tedirginlik yaratır
eklenti (extension) olarak ayırmak daha iyi olur
sadeleşme gerekçesiyle eski bir özelliği kaldırması çelişkili
Hangi yol seçilirse seçilsin biri zarar görecek
Blogumu XML/XSLT'ye çevirmeyi düşünüyorum
Zaten kimse okumuyor; artık düşük trafiği Chrome'un suçu diye gösterebilirim
Google hayranı değilim ama XSLT'nin kaldırılması web API karmaşıklığını azaltmak için bir fırsat
Ladybird gibi bağımsız tarayıcıların yükünü hafifletebilir
Sonuçta Google'ın tekel gücünü bile zayıflatabilir
Bunun “büyük tepki olmadan” ilerlediğini söylemek zor
Son 10-15 yılda web standartları, tarayıcıya belirli niş ihtiyaçları yerleştirme yönünde ilerledi
XSLT'nin kaldırılması ve polyfill sağlanması, karmaşıklığı tarayıcı dışına iten bir yönelim gibi görünüyor
2025’te XSLT desteği gerektiğini söyleyen bir yazı ilginçmiş... RSS vb. için stil vermede kısa süreli kullanıldığı doğru ama genel amaçlı olarak yaygın biçimde kullanıldığını söylemek de zor değil mi