3

About a decade ago, you could open an XML file locally with IE8, and when that XML file contained a XSLT stylesheet reference:

<?xml-stylesheet href="https://trusted.org/stylesheet.xsl"?>

but then over a few years this stopped working for all browsers. There is an obvious security concern, same-origin policy, and Chrome (and probably by now other browsers) do not even allow a local file: stylesheet reference, even if it is from the exact same directory.

I understand why there may be risks, but I don't understand why XSLT in particular poses such risks as the XSLT 1.0 implemented on browsers cannot even do anything malicious. OTOH, I can source JavaScript scripts from local files just fine, and if I'd be concerned about anything it would be java script doing malicious things, not XSLT!

I think the solution was way too harsh and not even-handedly applied. There should be a way for the user to configure trusted URLs at least trusted HTTPS URLs from where such stylesheets may be loaded. If not, the entire stylesheet feature is essentially killed off.

What is the current status of this? And why is nobody addressing this? Nobody but me seems to even complain or recognize the irony that XSLT is so totally blocked while JavaScript is open? It seems as if it is an act of ignorance or even deliberate attempt to kill XSLT functionality from existence.

I know there are some work-arounds like starting chrome with some special command line option which essentially turns off all such security. But that's just more nonsense in the design of this all if you make a system unusable for purported security concerns and then give only one way to overcome this by turning off all security guards. Makes no sense.

Comments? Solutions?

UPDATE: there seems to be some Windows / Internet Explorer specific way to configure the stylesheet URL as a trusted site, because I heard that it works for someone using a higher version of IE. But I don't know what exact settings they are using. Would be great to hear from someone who has that particular scenario figured out.

Gunther Schadow
  • 1,490
  • 13
  • 22
  • 1
    This could be a solution : https://www.saxonica.com/saxon-js/index.xml – Sebastien Jan 25 '21 at 13:44
  • 4
    It is a deliberate intent to not invest any effort in XML/XSLT related stuff and use security problems as an excuse to cut down on features, HTML5/JSON rules the world of browser vendors and I don't think that will change, the latest restriction for Firefox/Mozilla, for instance, to prevent file URI `` to work, was just reasoned along the lines of "Chrome doesn't support it anyway, new Chromium based Edge neither, so why not cut it for Mozilla as well" instead of finding a fix for the security problem. – Martin Honnen Jan 25 '21 at 14:08
  • @MartinHonnen thanks for validating my suspicion that it's deliberate. JSON isn't doing in any way what XSLT does, so its really a dumb excuse on their part. I feel like they are shooting at people with heir silver bullets and beating their users with their golden hammers. – Gunther Schadow Jan 25 '21 at 14:44
  • 1
    Now let's talk about how web browsers have yet to support XSLT 2.0, forever still on 1.0! – Parfait Jan 25 '21 at 20:26
  • @Parfait, I totally agree with that. Let us think if there isn't some way of doing the entire XSLT processing in javascript instead. One might consider porting Saxon to javascript and run it on the browser. And in the interim one might call the browser's XSLT 1.0 engine from javascript. The question is whether there is some way of breaking out to javascript for handling the xml-stylesheet PI? – Gunther Schadow Jan 28 '21 at 15:43
  • @Parfait to follow up on the javascript breakout idea, there is something here: https://stackoverflow.com/questions/384639/how-to-include-javascript-in-xml-document, now it would be nice if some javascript could be registered as a PI handler in the browser settings. – Gunther Schadow Jan 28 '21 at 15:54
  • I am not a javascript expert to advise. – Parfait Jan 28 '21 at 17:03

0 Answers0