Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Removing XSLT for a more secure browser

developer.chrome.com

Post reply on HN
Print view View original

71–80 of 352 posts

Re: Removing XSLT for a more secure browser

#71

Post by JimDabell »

simoncion wrote: post #69
JimDabell wrote: post #65

Earlier quoted context omitted.

> It was opened by a Chrome engineer after at least two meetings where a Mozilla engineer raised the topic, and where there was apparently vendor support for it. — https://news.ycombinator.com/item?id=44953349

I don't see any evidence of that claim from the materials I have available to me. [0] is the Github Issue I mentioned. [1] is the WHATNOT meeting notes linked to from that GH Issue... though I have no idea who smaug is. [0] https://github.com/whatwg/html/issues/11523 > [1] https://github.com/whatwg/html/issues/11146#issuecomment-275... >

Smaug is the Mozilla engineer they were talking about:

https://github.com/smaug----

Re: Removing XSLT for a more secure browser

#72

Post by lunar_mycroft »

phendrenad2 wrote: post #32

Unquestionably the right move. From the various posts on HN about this, it's clear that (A) not many people use it (B) it increases security vulnerability surface area (C) the few people who do claim to use have nothing to back up the claim The major downside to removing this seems to be that a lot of people LIKE it. But eh, you're welcome to fork Chromium or Firefox.

Chrome and other browsers could virtually completely mitigate the security issues by shipping the polyfil they're suggesting all sites depending on XSLT deploy in the browser. By doing so, their XSLT implementation would become no less secure than their javascript implementation (and fat chance they'll remove that). The fact that they've rejected doing so is a pretty clear indication that security is just an excuse, IMO.

Re: Removing XSLT for a more secure browser

#74

Post by simoncion »

JimDabell wrote: post #71
simoncion wrote: post #69

Earlier quoted context omitted.

I don't see any evidence of that claim from the materials I have available to me. [0] is the Github Issue I mentioned. [1] is the WHATNOT meeting notes linked to from that GH Issue... though I have no idea who smaug is. [0] https://github.com/whatwg/html/issues/11523 > [1] https://github.com/whatwg/html/issues/11146#issuecomment-275... >

Smaug is the Mozilla engineer they were talking about: https://github.com/smaug----

Ah, that was my problem... I didn't put enough minuses after the nickname. ;)

Re: Removing XSLT for a more secure browser

#75

Post by bawolff »

gdulli wrote: post #38

I don't use XSLT and don't object to this, but seeing "security" cited made me realize how reflexively distrustful I've become of them using that justification for a given decision. Is this one actually about security? Who knows!

Didn't this come pretty directly after someone found some security vulns? I think the logic was, this is a huge chunk of code that is really complex which almost nobody uses outside of toy examples (and rss feeds). Sure, we fixed the issue just reported, but who knows what else is lurking here, it doesn't seem worth it.

As a general rule, simplifying and removing code is one of the best things you can do for security. Sure you have to balance that with doing useful things. The most secure computer is an unplugged computer but it wouldn't be a very useful one; security is about tradeoffs. There is a reason though that security is almost always cited - to some degree or another, deleting code is always good for security.

Re: Removing XSLT for a more secure browser

#76

Post by danielvaughn »

arandr0x wrote: post #55

It's encouraging to see browsers actually deprecate APIs, when I think a lot of problems with the Web and Web security in particular is people start using new technologies too fast but don't stop using old ones fast enough. That said, it's also pretty sad. I remember back in the 2000s writing purely XML websites with stylesheets for display, and XML+XSLT is more powerful, more rigorous, and arguably more performant n…

Agreed on API deprecation, the surface is so broad at this point that it's nearly impossible to build a browser from scratch. I've been doing webdev since 2009 and I'm still finding new APIs that I've never heard of before.

Re: Removing XSLT for a more secure browser

#77

Post by Aurornis »

MarsIronPI wrote: post #22

To 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 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 choice. I’m sorry it doesn’t work for your use case, but having the entire browser ecosystem cater to JS-blocking legitimate users wouldn’t make any sense.

Re: Removing XSLT for a more secure browser

#78

Post by shadowgovt »

righthand wrote: post #50
TingPing wrote: post #46

Earlier quoted context omitted.

I get the frustration but I don’t believe that’s really accurate. It’s not widely used and modern developers don’t see it as valuable.

I’m a modern developer and I see it as valuable. Why side with the browser teams and ignoring user feedback? If “modern developers” actually spent time with it, they’d find it valuable. Modern developers are idiots if their constant cry is “just write it in JS”. No idea what’s inaccurate about this. A billion dollar company that has no problem pivoting otherwise, can’t fund open technology “because budgets” is simply…

The dominant user feedback is the hard statistics on how rarely it's used.

You can't trim the space of "users" to just "people who already adopted the technology" in the context of the cost of browser support.

Re: Removing XSLT for a more secure browser

#79

Post by shadowgovt »

cxr wrote: post #60

> When that solution isn't wanted, the polyfill offers another path. A solution is only a solution if it solves the problem. This sort of thing, basically a "reverse X/Y problem", is an intellectually dishonest maneuver, where a thing is dubbed a "solution" after just, like, redefining the problem to not include the parts that make it a problem . The problem is that there is content that works today that will break a…

> So the Chrome team is going to ship a solution where when it encounters un-un-fucked content that depends on XSLT, Chrome will transparently fix it up as if someone had injected this polyfill import into the page, right?

As with most things on the web, the answer is "They will if it breaks a website that a critical mass of users care about."

And that's the issue with XSLT: it won't.

Re: Removing XSLT for a more secure browser

#80

Post by QuadrupleA »

cxr wrote: post #67
QuadrupleA wrote: post #10

TIL: Chrome supports XSLT. Good riddance I guess - it and most of the tech from the "XML era" was needlessly overcomplicated.

Your response is like seeing the cops going to the wrong house to kick in your neighbors door, breaking their ornaments in their entry way, and then saying to yourself, "Good. I hate yellow, and would never have any of that tacky shit in my house." As your first sentence of your comment indicates, the fact that it's supported and there for people to use doesn't (and hasn't) result in you being forced to use it in you…

Yes but software, and especially browser, complexity has balooned enormously over the years. And while XSLT probably plays a tiny part in that, it's likely embedded in every Electron app that could do in 1MB what it takes 500 MB to do, makes it incrementally harder to build and maintain a competing browser, etc., etc. It's not zero cost.

I do tend to support backwards compatibility over constant updates and breakage, and needless hoops to jump through as e.g. Apple often puts its developers through. But having grown up and worked in the overexuberant XML-for-everything, semantic-web 1000-page specification, OOP AbstractFactoryTemplateManagerFactory era, I'm glad to put some of that behind us.

If that makes me some kind of gestappo, so be it.

Post reply on HN