[dead]
Removing XSLT for a more secure browser
271–280 of 352 posts
Re: Removing XSLT for a more secure browser
#272This has been chewed on ad nauseum on HN already, to the point I won't even try to make a list of the articles but just link a search result: https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=fal...
Best thread IMHO, lots of thoughtful root-level comments:
"Remove mentions of XSLT from the html spec" https://news.ycombinator.com/item?id=44952185
Re: Removing XSLT for a more secure browser
#273Earlier quoted context omitted.
The license would be relevant if I'd claimed that removing XSLT was illegal or opened them up to lawsuits, but I didn't. The obligation they took on is social/ethical, not legal. By your logic, chrome could choose to stop supporting literally anything (including HTML) in their "browser" and not have done anything that we can object to. iIRC, lack of IE compatibility is fundamentally different, because the IE specific…
> By your logic, chrome could choose to stop supporting literally anything (including HTML) in their "browser" and not have done anything that we can object to. Literally this. Microsoft used to ship a free web browser. Then they stopped. That's not something anybody can object to. > because the IE specific stuff they didn't implement was never part of the open web standards, but rather stuff Microsoft unilaterally c…
> Literally this. Microsoft used to ship a free web browser. Then they stopped. That's not something anybody can object to.
There is a fundamental difference between ceasing to make a browser and continuing to make a browser, while not meeting your expectations as a browser maker.
> If standards are more important that real use cases, then the fact that XSLT has been removed from the html5 standard is enough justification to remove it from Chrome.
Browsers very much have not depreciated support for non-HTML5 markup (e.g. the HTML4 era tag still works). This is because upholding devs and users expectation that standards compliant websites that once worked will continue to work is important.
Re: Removing XSLT for a more secure browser
#274To anyone who says to use JS instead of XSLT: I block JS because it is also used for ads, tracking and bloat in general. I don't block XSLT because I haven't come across malicious use of XSLT before (though to be fair, I haven't come across much use of XSLT at all). I think being able to do client-side templating without JS is an important feature and I hope that since browser vendors are removing XSLT they will add…
I feel like there's a bias here due to XSLT being negletted and hence not receiving the same powers as JS. If it did get more development in the browser I'm pretty sure it would get the same APIs that we hate JS for, and since it's already Turing complete chances are people will find ways to misuse it and bloat websites.
Re: Removing XSLT for a more secure browser
#275Earlier quoted context omitted.
> not that many feeds are actually doing this Isn't this kind of an argument for dropping it? Yeah it would be great if it was in use but even the people who are clicking and providing RSS feeds don't seem to care that much.
You are probably right, but it is depressing how techies don't see the big picture & don't want to provide an on-ramp to the RSS/Atom world for newcomers.
How does displaying XML using a client-side transform provide a better on-ramp compared to displaying XML using a server-side transform?
Re: Removing XSLT for a more secure browser
#276Earlier quoted context omitted.
> I block JS The percentage of visitors who block JS is extremely small. Many of those visits are actually bots and scrapers that don’t interpret JS. Of the real users who block JS, most of them will enable JS for any website they actually want to visit if it’s necessary. What I’m trying to say is that making any product decision for the extremely small (but vocal) minority of users who block JS is not a good product…
I block JS, too. And so does about 1-2% of all Web users. JavaScript should NOT be REQUIRED to view a website. It makes web browsing more insecure and less private, makes page load times slower, and wastes energy.
Blocking first party Javascript is a form of lunacy that is so illogical I can only shake my head. Let's say the site runs XSLT in Javascript. Now what? There's nothing that can be done and yet you would ask for further accommodation.
Here is why this is abusive: You can always restrict the subset of the web platform you demand to a subset that is arbitrarily difficult or even impossible to support. No matter how much accommodation is granted, it will be all for naught, because some guy out there goes even further with blocking things and starts blocking CSS. Next thing you know there's a guy who blocks HTML and you're expected to render out your website as a SVG with clickable links.
Re: Removing XSLT for a more secure browser
#277Earlier quoted context omitted.
The point of the poster you're responding to is that sites are built JS-first for 98-99% of users, and it takes extra work to make them compatible with "JavaScript should NOT be REQUIRED to view a website", and no one is going to bother doing that work for 1-2% of users.
Yeah... or...... maybe they should just build websites the proper way the first time around, returning plain HTML, perhaps with some JS extras. Any user-entered input needs to be validated again on the backend anyway, so client-side JS is often a waste.
This falls apart the moment you need to add rows to a table or show and hide things in response to values selected in a dropdown. Even the lightest JS app centered around a big form is going to become a huge pain in the ass for literally no benefit. In a company of 100 people, that <0.5% of people who disable JS could literally be one guy, or no one at all.
Re: Removing XSLT for a more secure browser
#278Earlier quoted context omitted.
Blame Apple and Mozilla, too, then. They all agreed to remove it. They all agreed because XSLT is extremely unpopular and worse than JS in every way. Performance/bloat? Worse. Security? MUCH worse. Language design? Unimaginably worse. EDIT: I wrote thousands of lines of XSLT circa 2005. I'm grateful that I'll never do that again.
This is only repeated by people who have never used it. XSLT is still a great way of easily transforming xml-like documents. It's orders of magnitude more concise than transforming using Javascript or other general programming languages. And people are actively re-inventing XSLT for JSON (see `jq`).
Who is transforming XML documents on the web? Most people produce HTML to begin with, so XSLT is a solution seeking a problem. If you really insist, you could just use XSLT via server side rendering.
Re: Removing XSLT for a more secure browser
#279Earlier quoted context omitted.
XSLT is being exploited right now for security vulnerabilities, and there is no solution on the horizon. The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators. You imagine that XSLT is more secure but it’s not. It’s never been. Even pure XSLT is quite capable of Turing-complete tom…
> The browser technologies that people actually use, like JavaScript, have active attention to security issues, decades of learnings baked into the protocol, and even attention from legislators. Yes, they also have much more vulnerabilities, because browsers are JIT compiling JS to w+x memory pages. And JS continues to get more complex with time. This is just fundamentally not the case with XSLT. We're comparing a fe…
While JIT exploits represent a large share of vulnerabilities in JS engines, there are enough other classes of vulnerabilities that simply turning JIT off is not sufficient. (The same goes for simply turning JS off, the Web browser internal is complex enough even without JS.)
Re: Removing XSLT for a more secure browser
#280Earlier quoted context omitted.
> I find it so weird that browser devs can point to the existence of stuff like React and not feel embarrassed. Sorry, I don't follow. What's embarrassing about React?
I think in the context of that link, they see React as a failing of the web. If the W3C/WHATWG/browser vendors had done a reasonable job of moving web technology forward, things like React would be far less necessary. But they spent all their time and energy working on things like and web components instead of listening to web developers and building things that are actually useful in a web developer’s day-to-day lif…
One of the biggest flaws of the current web technology stack is the unholy mix of concerns with respect to layout. Layout is handled by CSS and HTML in a way that drives people crazy. I recently wanted to have a scroll bar for super long text inside a table cell. Easy, right? Turns out you need to change the HTML to include a inside the table cell, since there is no way to style the table cell itself and have it do what you expect it to do.
XLST doesn't solve this at all, since you're just generating more of the problem, i.e. more HTML and CSS. It feels like there should have been some sort of language exclusively for layout definition that doesn't necessarily know about the existence of HTML and CSS beyond selector syntax.