what exactly is the security concern with xslt?
It parses untrusted input, the library is basically unmaintained, it’s not often audited but anytime someone looks they find a CVE.
Removing XSLT for a more secure browser
61–70 of 352 posts
Re: Removing XSLT for a more secure browser
#62Earlier quoted context omitted.
XSLT is really powerful and it is declarative, like CSS, but can both push and pull. It's a loss, if you ask me, to remove it from client-side, but it's one I worked through years ago. It's still really useful on the server side for document transformation.
Imagine a WASM XSLT interpreter wouldn't be to hard to compile?
TFA mentions polyfills and libraries.
Re: Removing XSLT for a more secure browser
#63TIL: Chrome supports XSLT. Good riddance I guess - it and most of the tech from the "XML era" was needlessly overcomplicated.
Perhaps, but isn't the contemporary tech stack orders of magnitude more complicated? Doesn't feel like a strong motivating argument.
Re: Removing XSLT for a more secure browser
#64The "severe security issue" in libxml2 they mention is actually a non-issue and the code in question isn't even used by Chrome. I'm all for switching to memory-safe languages but badmouthing OSS projects is poor style.
Where's the best collection or entry point to what you've written about Chrome's use of Gnome's XML libraries, the maintenance burden, and the dearth of offers by browser makers foot the bill?
Re: Removing XSLT for a more secure browser
#65Earlier quoted context omitted.
Didn't this effort start with Mozilla and not Google? I think you will in fact forget the name Mason Freed, just like most of us forgot about XSLT.
> Didn't this effort start with Mozilla and not Google? Maybe round one of it like ten years ago did? From what I understand, it's a Google employee who opened the "Hey, I want to get rid of this and have no plans to provide a zero-effort-for-users replacement." Github Issue a few months back.
> 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.
Re: Removing XSLT for a more secure browser
#66One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use. I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link. But someone w…
FWIW the original post explicitly mentioned this use case and offered two ways to workaround.
Gotta love the reference to the header element. There used to be an icon in the browser URL bar when a site had a feed, but they nuked that too.
Re: Removing XSLT for a more secure browser
#67TIL: 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 your projects.
Re: Removing XSLT for a more secure browser
#68Earlier 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.
They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons. Only Google is pushing forward and twisting that message.
> They did not agree to remove it. This is a spun lie from the public posts I can see. They agreed to explore removing it but preferred to keep it for good reasons.
Mozilla:
> Our position is that it would be good for the long-term health of the web platform and good for user security to remove XSLT, and we support Chromium's effort to find out if it would be web compatible to remove support.
— https://github.com/mozilla/standards-positions/issues/1287#i...
WebKit:
> WebKit is cautiously supportive. We'd probably wait for one implementation to fully remove support, though if there's a known list of origins that participate in a reverse origin trial we could perhaps participate sooner.
— https://github.com/whatwg/html/issues/11523#issuecomment-314...
Describing either of those as “they preferred to keep it” is blatantly untrue.
Re: Removing XSLT for a more secure browser
#69Earlier quoted context omitted.
> Didn't this effort start with Mozilla and not Google? Maybe round one of it like ten years ago did? From what I understand, it's a Google employee who opened the "Hey, I want to get rid of this and have no plans to provide a zero-effort-for-users replacement." Github Issue a few months back.
> 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...>
Re: Removing XSLT for a more secure browser
#70One extremely important XSLT use-case is for RSS/Atom feeds. Right now, clicking on a link to feed brings up a wall of XML (or worse, a download link). If the feed has an XSLT stylesheet, it can be presented in a way that a newcomer can understand and use. I realize that not that many feeds are actually doing this, but that's because feed authors are tech-savvy and know what to do with an RSS/Atom link. But someone w…
FWIW the original post explicitly mentioned this use case and offered two ways to workaround.
iIRC, all of the proposed workarounds involved updating the sites using XSLT, which may not always be particularly easy, or even something publishers will realize they need to do.