Not necessarily. The security issues are with the libxml implementation, a different one might be more secure even with JIT. That's part of what makes the whole situation so ridiculous.

▲

whizzter 4 days ago | parent | next [-]

Still, from a security perspective considering the low amount of sites that use it I think a better solution would be to implement it with a JS shim like PDF.js.

JS is already required to have a XML DOM parser, an universal XSLT engine in JS should be a low-effort web to continue supporting XSLT, as for performance the transform could probably be eval'ed and cached to JS snippets so that they in turn become JIT-compiled.

https://developer.mozilla.org/en-US/docs/Web/API/DOMParser

▲

bawolff 4 days ago | parent | prev | next [-]

Whether or not it is actually secure, as a factual matter, has nothing to do with its security footprint.

▲

afavour 4 days ago | parent | prev [-]

Emphasis on might be. Finding out whether it actually is is not a trivial process.

▲

troupo 4 days ago | parent [-]

There are multiple CVEs in multiple Chrome-only non-standards that Chrome spits out by the hundreds in the past few years. They have no issues releasing those, supporting them, and fixing them.

Somehow they have an issue with supporting, fixing (and updating to latest version) this particular one. Possibly because it doesn't result in promotions.

	▲	afavour 4 days ago \| parent [-]
		This often ends up as an anti-Google argument but all the major browser makers agree with this deprecation proposal.