Your argument here includes that browsers should retain native XSLT implementations because non-browsers have bad XSLT implementations?

▲

dragonwriter 18 hours ago | parent | next [-]

I don’t see anything that looks remotely like a normative argument about what browsers should or should not do anywhere in my post that you are responding to, did you perhaps mean to respond to some other post?

My point was that the decision to remove XSLT support from browsers rather than replacing the insecure, unmaintained implementation with a secure, maintained implementation is an indicator opposed to the claim "XSLT isn’t going anywhere”. I am not arguing anything at all about what browser vendors should do.

▲

tptacek 18 hours ago | parent [-]

Is the idea that if they did so, the insecure non-browser XSLT-users could adopt their implementation?

▲

dragonwriter 17 hours ago | parent [-]

The idea is that if they did so, the people using software running in the browser could continue to use XSLT with just the browser platform because the functionality would still be there with a different backend implementation, but instead that in-browser XSLT functionality is going somewhere, specifically, away.

▲

tptacek 17 hours ago | parent [-]

Right but either way, the vulnerability exists today, and you're saying that whether or not the browser platform supports the functionality that harbors the vulnerabilities, the browser platform should be responsible for resolving those vulnerabilities. That's how I read it.

	▲	dragonwriter 17 hours ago \| parent [-]
		> and you're saying that whether or not the browser platform supports the functionality that harbors the vulnerabilities, the browser platform should be responsible for resolving those vulnerabilities. No, I'm not (and I keep saying this explicitly) saying that browsers should or should not do anything, or be responsible for anything. I’m not making a normative argument, at all. I am stating, descriptively, that browser vendors choosing to remove XSLT functionality rather than repairing it by using an alternative implementation is very directly contrary to the claim made upthread that “XSLT isn’t going anywhere”. It is being removed from the the most popular application platform in existence, with developers being required to bring their own implementation for what was previously functionality supported by the platform. I am not saying that this is good or bad or that anyone should or should not do anything differently or making any argument about where responsibility for anything related to this lies.

▲

AlecSchueler 18 hours ago | parent | prev [-]

What do you find questionable about this being included as part of the broader argument?

	▲	tptacek 18 hours ago \| parent [-]
		I just don't understand it. I don't understand it well enough to call out what's questionable about it.